Object-Pascal on TurboVision

Turbo Pascal Toolchain, Part 6: Object Pascal, TPW, and the Windows Transition

Fri, 13 Mar 2026 00:00:00 +0000

Parts 1–5 mapped the DOS-era toolchain: workflow, artifacts, overlays, BGI, and the compiler/linker boundary from TP6 to TP7. This part crosses the platform divide. Object Pascal extensions, Turbo Pascal for Windows (TPW), and the move to message-driven GUIs forced a different kind of toolchain thinking. Same language family, new mental model.

This article traces that transition from a practitioner’s perspective: what stayed familiar, what broke, and what had to be relearned. We cover the historical milestones (TP 5.5 OOP, TPW 1.0, TPW 1.5, BP7), the technical culprits that bit migrating teams, debugging and build/deploy workflow differences, and the mental shift from sequential to event-driven execution.

Version timeline (conservative): TP 5.5 (1989) introduced Object Pascal. TPW 1.0 appeared in the Windows 3.0 era (c. 1991). Borland Pascal 7 (1992) offered unified DOS and Windows tooling including DLL support. TPW 1.5 followed TP7 (c. 1993). OWL matured alongside these releases. Exact dates for some variants vary by region and packaging; the sequence is well established. The transition spanned roughly four years; many teams maintained both DOS and Windows targets during that period.

Structure map (balanced chapter plan)

Before drilling into details, this article follows a fixed ten-chapter plan so the narrative stays balanced rather than front-loaded:

Object Pascal in TP 5.5
TPW 1.0 and first Windows workflow shock
TPW 1.5 in the post-TP7 landscape
BP7 as dual-target toolchain
OWL and message-driven architecture
migration culprits and pitfalls
debugging model changes (DOS vs Windows)
build/deploy pipeline changes
team workflow and review-model changes
synthesis and transfer lessons

Each chapter carries similar depth: technical mechanism, failure mode, and practical operator/developer workflow.

Object Pascal arrives: TP 5.5 and the OOP extensions

Turbo Pascal 5.5, released in 1989, introduced Object Pascal: the object type with inheritance, virtual methods, and constructors/destructors. The additions were substantial for the language, but the toolchain remained essentially the same. Compile, link, run. .TPU units still carried compiled code; the linker still produced .EXE. What changed was what you expressed in those units and how you structured larger programs.

The object keyword (distinct from the later class keyword in Delphi) defined a type with a hidden pointer to its virtual method table (VMT). Inheritance was single; you could not inherit from multiple base objects. Virtual methods required the virtual directive and had to be overridden with the same signature. The compiler emitted the VMT layout; if you got the inheritance hierarchy wrong, the wrong method could be invoked at runtime—a form of bug that procedural Pascal had never had.

unit Shapes;

interface

type
  TShape = object
    X, Y: Integer;
    procedure Move(Dx, Dy: Integer);
    procedure Draw; virtual;
    constructor Init(AX, AY: Integer);
    destructor Done; virtual;
  end;

  TCircle = object(TShape)
    Radius: Integer;
    procedure Draw; virtual;
    constructor Init(AX, AY, ARadius: Integer);
  end;

implementation

constructor TShape.Init(AX, AY: Integer);
begin
  X := AX;
  Y := AY;
end;

destructor TShape.Done;
begin
  { cleanup }
end;

procedure TShape.Move(Dx, Dy: Integer);
begin
  Inc(X, Dx);
  Inc(Y, Dy);
end;

procedure TShape.Draw;
begin
  { base: no-op or default behavior }
end;

constructor TCircle.Init(AX, AY, ARadius: Integer);
begin
  TShape.Init(AX, AY);
  Radius := ARadius;
end;

procedure TCircle.Draw;
begin
  { draw circle at X,Y with Radius }
end;

end.

For DOS projects, this was still a single-threaded, linear-control-flow world. The object model improved structure and reuse; it did not yet change the execution paradigm. Overlays, BGI, and conventional memory limits applied unchanged. Teams adopting Object Pascal in the late 1980s learned inheritance and polymorphism while keeping familiar toolchain habits.

Constructor and destructor discipline mattered. In the early object model (pre-class syntax), you called Init explicitly and Done before disposal. Forgetting Done on objects that held resources (handles, memory) leaked. The toolchain did not enforce this; it was a coding discipline. Virtual method tables added a small runtime cost and one more thing to get wrong when mixing object types—passing a TShape where a TCircle was expected could produce subtle bugs if the receiver assumed the concrete type.

The important point for the Windows transition: Object Pascal gave developers the vocabulary (inheritance, virtual dispatch, encapsulation) that OWL and later frameworks would use. Learning OOP in DOS was preparation for OWL’s message-handler hierarchy.

Toolchain impact was minimal. TP 5.5 still produced .TPU units; the compiler emitted VMT layout for object types; the linker resolved virtual calls at link time. Debugging object hierarchies required understanding the VMT structure, but Turbo Debugger could display object instances and their fields. Migration from procedural to object-based code was incremental: one unit at a time, starting with leaf modules that had no dependencies. A common path: introduce a single object type to encapsulate a record and its operations, compile and test, then add inheritance where it simplified structure. Big-bang rewrites to “full OOP” were rare and risky; most teams evolved their codebases gradually.

Turbo Pascal for Windows 1.0: the first wave

Turbo Pascal for Windows 1.0 arrived in the Windows 3.0 era, commonly cited as around 1991. The toolchain surface looked familiar: blue IDE, integrated compiler, linker. Underneath, the target was completely different. Instead of DOS .EXE and real-mode segments, you produced Windows .EXE binaries that linked against the Windows API, expected a GUI entry point (WinMain), and ran inside a message loop.

First-time TPW users discovered that a “Pascal program” was no longer a straight-line script. The main block ran once to register the window class, create the main window, and enter GetMessage/DispatchMessage. After that, everything happened inside the window procedure (WndProc) in response to messages. A typical beginner error: putting “real” logic in the main block, wondering why it never ran, and only later realizing the block had already exited into the message loop. Another: assuming that WndProc would be called once per “event.” In fact, Windows sends many messages—WM_CREATE, WM_SIZE, WM_PAINT, WM_COMMAND, and dozens more—and the order and timing depend on user actions and system behaviour. Learning which messages mattered for a given task was part of the ramp-up.

program HelloWin;

uses
  WinTypes, WinProcs;

const
  IDC_BUTTON = 100;

function WndProc(Window: HWnd; Message, WParam: Word; LParam: LongInt): LongInt;
  far;
begin
  case Message of
    wm_Command:
      if WParam = IDC_BUTTON then
        MessageBox(Window, 'Hello from TPW', 'TPW', mb_Ok);
    wm_Destroy:
      PostQuitMessage(0);
    else
      WndProc := DefWindowProc(Window, Message, WParam, LParam);
      Exit;
  end;
  WndProc := 0;
end;

var
  Msg: TMsg;
  WndClass: TWndClass;
  hWnd: HWnd;

begin
  WndClass.style := 0;
  WndClass.lpfnWndProc := @WndProc;
  WndClass.cbClsExtra := 0;
  WndClass.cbWndExtra := 0;
  WndClass.hInstance := HInstance;
  WndClass.hIcon := LoadIcon(0, idi_Application);
  WndClass.hCursor := LoadCursor(0, idc_Arrow);
  WndClass.hbrBackground := GetStockObject(white_Brush);
  WndClass.lpszMenuName := nil;
  WndClass.lpszClassName := 'HelloWin';

  RegisterClass(WndClass);
  hWnd := CreateWindow('HelloWin', 'TPW Hello', ws_OverlappedWindow,
    cw_UseDefault, 0, cw_UseDefault, 0, 0, 0, HInstance, nil);
  ShowWindow(hWnd, sw_ShowNormal);
  UpdateWindow(hWnd);

  while GetMessage(Msg, 0, 0, 0) do
  begin
    TranslateMessage(Msg);
    DispatchMessage(Msg);
  end;
end.

The shift was conceptual: instead of “run from top to bottom,” you “register a window class, create a window, then sit in a message loop.” Event handling was reactive. The toolchain still produced .EXE, but the runtime contract was Windows API calls, far procs, and GetMessage/DispatchMessage.

TPW 1.0 shipped with WinTypes and WinProcs units (API bindings) and optionally WinCrt for console-style apps. The IDE looked like the DOS Turbo Pascal IDE but targeted a different runtime. Keyboard shortcuts and menu structure were familiar, which eased the transition. The debugger, however, had to handle a different execution model: breakpoints in message handlers fired when messages arrived, not when you single-stepped through a linear flow. Setting a breakpoint in WndProc and running would eventually stop there—but only when a message was dispatched to that window. First-time TPW users often hit: wrong library linking (mixing DOS and Windows units), missing far on WndProc, and confusion about when their code actually ran—the main block sets up and enters the loop; the rest happens inside WndProc when messages arrive. That inversion was the core mental break.

Linker differences mattered. TPW produced Windows executables with a different header format, different segment layout, and different startup code. You could not link a DOS object file into a Windows executable or vice versa. Mixed projects—e.g. a shared algorithm library—had to compile the same source twice, once for each target, with target-specific uses and possibly {$IFDEF} guards. The idea of “one binary runs everywhere” did not exist; you had DOS binaries and Windows binaries.

Understanding the message loop was essential. GetMessage blocks until a message is available; TranslateMessage converts keystrokes to WM_CHAR when needed; DispatchMessage invokes the window procedure for the target window. Every GUI action in a Windows app flows through this pipeline. A handler that did too much work (e.g. a long computation) would block the loop and freeze the UI. DOS programs could ReadKey and wait indefinitely; Windows programs had to return from handlers quickly and defer heavy work (e.g. via timers or background processing) to avoid stalling the whole application. Developers coming from DOS often wrote handlers that performed synchronous file I/O or lengthy calculations, then wondered why the window would not repaint or respond to input until the operation finished. The fix was to break work into smaller chunks or use PeekMessage-based cooperative multitasking—a technique that required unlearning the “run until done” habit.

TPW 1.5 and the post-TP7 landscape

TPW 1.5 followed TP7 and appeared in the early 1990s (often cited around 1993). It brought the TP7-era language and tooling to the Windows target. Better integration with Windows APIs, improved resource tooling, and alignment with the Borland Pascal 7 family. By this point, DOS and Windows were parallel targets within the same product family, not separate products with different pedigrees.

Build workflows diversified. A team might maintain both a DOS and a Windows configuration: different compiler switches, different libraries, different entry points. Shared units had to stay abstract enough to compile for both.

{ Conditional compilation for dual-target units }
unit SharedCore;

interface

procedure DoWork(Data: Pointer);

implementation

{$IFDEF MSWINDOWS}
uses WinTypes, WinProcs;
{$ENDIF}
{$IFDEF MSDOS}
uses Dos;
{$ENDIF}

procedure DoWork(Data: Pointer);
begin
  {$IFDEF MSWINDOWS}
  { Windows-specific implementation }
  {$ENDIF}
  {$IFDEF MSDOS}
  { DOS-specific implementation }
  {$ENDIF}
end;

end.

The {$IFDEF} pattern became standard for code shared across targets. Not all logic could be shared; APIs differed. But data structures, algorithms, and business rules could live in common units with thin platform-specific wrappers. Teams learned to minimize {$IFDEF} surface and push platform branches to dedicated units.

A common layout: a Core unit with pure logic (no uses of platform units), a CoreDOS unit that implemented Core for DOS (overlays, BGI, Dos unit), and a CoreWin unit that implemented Core for Windows (handles, WinProcs). The program or a top-level unit chose which implementation to use. This kept the conditional compilation at a few strategic points rather than scattered throughout.

TPW 1.5 also improved the resource workflow. Earlier TPW had resource support, but the integration was rougher. By 1.5, the path from dialog design to linked .EXE was more streamlined, and teams doing serious Windows development could rely on it.

A practical consideration: machine requirements. DOS Turbo Pascal ran on an 8088 with 256 KB of RAM. TPW and Windows 3.x demanded more—typically a 286 or 386, 1 MB or more of RAM, and a graphics display. Teams developing on higher-end machines had to remember that target users might have minimal configurations. Testing on a “cramped” setup (e.g. 1 MB RAM, 640×480) caught memory pressure and layout bugs that did not appear on development hardware.

BP7: unified DOS and Windows toolchain

Borland Pascal 7, released in 1992, provided a single box with DOS and Windows support. You could build:

DOS executables (with overlays, EMS, real-mode semantics)
Windows executables
Windows DLLs

DLL building introduced a new artifact type and a new linkage model.

library MyLib;

uses
  WinTypes, WinProcs;

exports
  MyExportProc index 1,
  MyExportFunc index 2;

procedure MyExportProc(P: PChar); far;
begin
  { DLL-exported procedure }
end;

function MyExportFunc(I: Integer): Integer; far;
begin
  MyExportFunc := I * 2;
end;

begin
  { DLL entry/exit handling if needed }
end.

The toolchain produced .DLL instead of (or in addition to) .EXE. Callers used LoadLibrary and GetProcAddress. Version coupling and calling conventions mattered more: a Pascal DLL had to match what the caller expected. Teams learned to isolate DLL interfaces and treat them as stable ABI boundaries.

DLL entry and exit ran at load/unload. If a DLL’s initialization touched other DLLs or global state, load order could cause subtle failures. Export by name vs. by ordinal had tradeoffs: ordinals were smaller and faster to resolve but fragile if the export table changed. Many teams standardized on name-based exports for maintainability and reserved ordinals for performance-critical paths. The exports section in the library block was the contract; changing it broke any caller that relied on it. Adding new exports was usually safe; removing or reordering required coordinated updates to all clients. Teams that treated the DLL interface as a stable API and versioned it explicitly (including in documentation) had fewer integration surprises.

Calling a Pascal DLL from C or another language required matching conventions: pascal vs. cdecl, near vs. far, and structure layout. Teams building mixed- language systems documented the ABI explicitly. A small test program that called each exported function and verified return values caught many integration bugs before they reached production.

BP7’s value was consolidation: one purchase, one documentation set, one support channel for both DOS and Windows. Teams could prototype on DOS (faster iteration, simpler debugging) and port to Windows when the design stabilised, or maintain both targets from a shared codebase from the start.

The DLL workflow itself took time to internalise. A library program had no main loop; it exported entry points. Callers loaded it, resolved exports, and called. The DLL’s initialization block ran at load; its finalization (if any) ran at unload. Thread safety was not a primary concern in 16-bit Windows, but DLL global state was shared across all callers. A bug in one executable’s use of a DLL could corrupt state for another. Documentation and code review had to cover “who loads this DLL, when, and what do they assume about its state?” DLLs also changed the testing matrix: a fix in a shared DLL required re-testing every application that used it. Versioning the DLL (e.g. embedding a version resource) and checking it at load time caught many “wrong DLL” deployment bugs before they manifested as mysterious crashes.

Importing a DLL from Pascal required matching the export signature exactly. A common pattern:

{ In unit that uses the DLL }
procedure MyImportProc(P: PChar); far; external 'MYLIB' index 1;
function MyImportFunc(I: Integer): Integer; far; external 'MYLIB' index 2;

If the DLL used pascal convention (Borland default) and the caller did too, calls worked. Mixing cdecl and pascal caused stack corruption. Teams building reusable DLLs often documented the calling convention in the header or in a separate ABI document.

OWL and message-driven architecture

Object Windows Library (OWL) and similar frameworks wrapped the raw Windows API in an object-oriented, message-handler style. Instead of a giant case statement in a single WndProc, you subclassed window types and overrode message handlers.

unit MyWindow;

interface

uses
  Objects, WinTypes, WinProcs, OWindows;

type
  PMyWindow = ^TMyWindow;
  TMyWindow = object(TWindow)
    procedure WMCommand(var Msg: TMessage); virtual wm_First + wm_Command;
    procedure WMPaint(var Msg: TMessage); virtual wm_First + wm_Paint;
  end;

implementation

procedure TMyWindow.WMCommand(var Msg: TMessage);
begin
  if Msg.WParam = 100 then
    MessageBox(HWindow, 'Button clicked', 'OWL', mb_Ok)
  else
    inherited WMCommand(Msg);
end;

procedure TMyWindow.WMPaint(var Msg: TMessage);
var
  PS: TPaintStruct;
  DC: HDC;
begin
  DC := BeginPaint(HWindow, PS);
  { draw using DC }
  EndPaint(HWindow, PS);
end;

end.

The pattern: each message maps to a virtual method; inherited propagates to the default handler. Toolchain-wise, you still compiled units and linked, but the design idiom was “object per window, method per message.” This influenced how teams structured code and how they debugged: failures showed up as wrong message routing or missing overrides.

OWL abstracted the raw RegisterClass/CreateWindow/message-loop boilerplate. You derived from TApplication and TWindow, filled in handlers, and the framework dealt with registration and dispatch. The tradeoff: learning OWL’s object graph and lifecycle. Windows created by OWL were owned by the framework; manual CreateWindow calls mixed with OWL could bypass that ownership and cause duplicate destruction or leaked handles. Teams that went “all OWL” had fewer ownership bugs than those that mixed raw API and OWL freely.

The virtual wm_First + wm_Command syntax mapped a Windows message ID to a method. When a message arrived, OWL’s dispatch logic looked up the method and called it. If you did not override a message, the base class handled it (or passed to DefWindowProc). This was a clean separation of concerns: each window class handled only the messages it cared about.

{ OWL: creating a custom control by inheritance }
type
  PMyEdit = ^TMyEdit;
  TMyEdit = object(TEdit)
    procedure WMChar(var Msg: TMessage); virtual wm_First + wm_Char;
  end;

procedure TMyEdit.WMChar(var Msg: TMessage);
begin
  { Filter or transform input before default handling }
  inherited WMChar(Msg);
end;

This pattern—override, do something, call inherited—became the standard for extending OWL controls. The toolchain compiled and linked the same way; the design vocabulary had expanded.

Choosing between raw API and OWL was a real decision. Raw API gave full control and smaller binaries but required more boilerplate and discipline. OWL added framework overhead but let teams ship Windows apps faster. Many TPW projects started with raw API for learning, then switched to OWL once the team understood the message model. Hybrid approaches existed but demanded careful ownership rules for window handles and resources.

OWL also provided standard dialogs, common controls wrappers, and application lifecycle management. Reinventing these with raw API was possible but time- consuming. Teams that adopted OWL early often had a working prototype in days instead of weeks. The tradeoff was dependency on Borland’s framework and its design decisions; customising behaviour sometimes required diving into OWL source or working around framework limitations. For teams building multiple Windows applications, OWL’s consistency across projects was valuable: once you learned the patterns, new apps came together faster. The investment in learning the framework paid off over several products.

Technical culprits and pitfalls

Several failure modes were common when moving from DOS to Windows. Experienced DOS developers often hit these first; the habits that worked in real mode backfired in Windows.

Far-call discipline. Windows callback procs (WndProc, dialogs, hooks) must be far. The Windows kernel and USER module invoke your code through function pointers; in the segmented 16-bit model, a near call to a callback caused immediate corruption when the system tried to return. Missing far or wrong declaration led to crashes that were hard to reproduce—sometimes only when a particular code path was taken. The compiler did not always catch it; runtime did, and not always with a clear message.

Resource coupling. Windows apps depend on .RC resources (dialogs, menus, icons). Wrong paths, missing resources, or mismatched IDs produced obscure startup failures. The linker or resource compiler had to be in the loop, and the resulting .RES had to link into the .EXE. A dialog defined in .RC with control ID 100 had to match the wm_Command handler that checked for 100. Typos or reuse of IDs across dialogs caused wrong controls to be identified. Teams learned to centralize ID constants in a shared include or unit. Some teams used a naming scheme (e.g. IDC_BUTTON_SAVE, IDC_EDIT_NAME) to make the link between resource and handler obvious during code review.

Segment and memory model. Windows 3.x used segmented memory. Large allocations, wrong segment assumptions, or stack overflow in message handlers could corrupt the heap or cause intermittent faults. DOS habits (assume sequential execution, small stack) did not translate. In DOS, you often knew exactly when a procedure returned; in Windows, a message handler could call SendMessage and re-enter the same or another handler before returning. Recursive message handling required care with stack depth and static state.

String interop. Pascal String[N] vs. C null-terminated. Windows API expects PChar and length conventions. Conversion bugs caused truncation, buffer overrun, or wrong display. Teams needed explicit conversion layers and disciplined use of buffers.

DLL load order and initialization. DLLs had init/exit sequences. Circular dependencies or incorrect load order led to startup hangs or access violations. Build order and uses discipline mattered.

String conversion and buffer safety. Windows API calls often expect null-terminated PChar. Pascal String is length-prefixed. Passing a raw String variable where PChar was expected could work by accident (many implementations had a trailing zero) but was undefined. Correct pattern:

{ Safe Pascal-to-Windows string passing }
procedure ShowText(const S: String);
var
  Buf: array[0..255] of Char;
  I: Integer;
begin
  for I := 0 to Length(S) - 1 do
    Buf[I] := S[I + 1];  { Pascal 1-based indexing }
  Buf[Length(S)] := #0;
  MessageBox(0, Buf, 'Title', mb_Ok);
end;

Teams built small conversion units and used them consistently. Ad-hoc StrPCopy calls scattered across codebases were a maintenance hazard. A StrUtils or WinStrings unit with PascalToPChar, PCharToPascal, and perhaps PCharBuf for temporary buffers reduced copy-paste errors and gave a single place to fix bugs when a new Windows version changed length semantics.

{ Common mistake: forgetting far on Windows callbacks }
procedure BadProc(Window: HWnd; Msg: Word; W, L: LongInt);  { WRONG }
procedure GoodProc(Window: HWnd; Msg: Word; W, L: LongInt); far;  { CORRECT }

Debugging workflows: DOS vs Windows

DOS debugging was relatively direct. Single process, linear execution, predictable crash locations. Turbo Debugger could single-step, set breakpoints, inspect memory. Overlay and BGI issues were usually reproducible. If a crash happened at a fixed address, you set a breakpoint there, ran again, and examined the call stack. Deterministic replay was the default.

Windows debugging was harder. Message-driven execution meant control flow jumped between handlers. A bug might only appear when a specific message arrived in a specific order. Reproducing required driving the UI in a particular way. Crashes could occur in system code invoked via callback; the immediate cause might be bad parameters passed from your handler. Null pointer dereferences, wrong handle usage, and stack corruption in message handlers produced intermittent failures that did not correlate with “run it again.”

{ Diagnostic: log message flow to understand ordering }
procedure TMyWindow.DefaultHandler(var Msg: TMessage);
begin
  WriteLn(DebugFile, 'Msg=', Msg.Msg, ' W=', Msg.WParam, ' L=', Msg.LParam);
  inherited DefaultHandler(Msg);
end;

Practitioners used:

OutputDebugString and a monitor (e.g. Turbo Debugger for Windows or third-party tools) to capture log output
Conditional breakpoints in the debugger on message IDs (e.g. break when Msg.Msg = wm_Paint)
Small harness programs that sent specific messages via SendMessage to isolate behavior without manual UI interaction
Map files to correlate addresses with symbols when analyzing postmortem dumps

The mental shift: from “re-run until it crashes” to “instrument and trace message flow.” Debugging became hypothesis-driven: which message, which window, which order?

Another technique: build a minimal reproduction. If the bug appeared when clicking a specific button after resizing the window, create a tiny app with only that button and that resize logic. Isolating the failure often revealed that the cause was not where intuition suggested—e.g. a WM_PAINT handler that assumed state set up in WM_SIZE, but WM_PAINT could arrive before WM_SIZE in certain scenarios. Understanding Windows’ message ordering and reentrancy was as important as knowing the API. A handler that called SendMessage to a child window could find itself re-entered if the child’s handler did something that triggered another message to the parent. Careful design avoided such cycles; when they occurred, stack overflow or corrupted state often resulted.

Build and deploy: DOS vs Windows

DOS deployment was simple: .EXE, optionally .OVR, and .BGI/.CHR in a known directory. Batch files or simple install scripts sufficed. A typical release package: one folder, a few files, run the EXE. Path assumptions (e.g. .\BGI for drivers) had to be correct, but the surface was small. Floppy distribution was common: a single disk for the program, optionally a second for BGI drivers or overlay files. Users understood “copy to C:\MYAPP and run.”

Windows deployment added:

Multiple DLLs (Windows system DLLs plus any you shipped)
Resource files (icons, dialogs) embedded or alongside
INI files or registry for configuration
Different machine profiles (video drivers, memory)

The resource pipeline was new. You authored .RC files, compiled them with BRC.EXE (Borland Resource Compiler) to .RES, and linked the .RES into the .EXE. Forgetting the resource step produced a binary that ran but showed no icon, wrong menu, or broken dialogs. Dialog editor output and hand-written .RC had to stay in sync; ID collisions caused mysterious behavior. A small convention helped: define all resource IDs in a single $I-included file or a dedicated unit, and reference them from both .RC and Pascal. Changing an ID in one place without the other was a frequent source of “the button does nothing” bugs that took hours to track down.

REM DOS build
tpc -B main.pas
copy main.exe dist\
copy *.ovr dist\ 2>nul
copy bgi\*.bgi dist\bgi\

REM Windows build (conceptual)
tpw main.pas
brc main.res main.exe
copy main.exe dist\
copy mylib.dll dist\ 2>nul

Build scripts had to branch by target. Release builds often required separate configurations for DOS and Windows, with different linker options and runtime selection. Teams documented “DOS build checklist” vs. “Windows build checklist” and treated them as separate pipelines. A dual-target product meant two release builds, two test passes, and two support matrices (e.g. “runs on DOS 5.0+” vs. “runs on Windows 3.1+”).

Versioning of deliverables also changed. A DOS product might ship “v1.2”; a Windows product might need “v1.2 for Windows 3.1” vs. “v1.2 for Windows 3.11” if patch-level differences mattered. Installer design entered the picture: copying files into the right place, registering extensions, and creating program group icons. Teams that had never needed an “install” step had to learn one. Early Windows installers were often batch files or simple scripts; later, dedicated installer tools (e.g. Borland’s own offerings) became part of the release workflow. The transition from “copy to floppy and run” to “run setup and follow the wizard” was another incremental change that accumulated over the early 1990s.

Team collaboration and mental model shift

DOS-era teams had a shared mental model: one process, one flow, predictable artifacts. Code reviews focused on logic, overlays, and memory. A developer could read a program from top to bottom and follow execution. Ownership of “the main loop” was clear.

Windows-era teams dealt with:

Split expertise: some people owned dialog layout (.RC and resource editor), others message handlers, others DLL interfaces. The “GUI person” and the “engine person” became distinct roles.
Asynchronous feel: events could arrive in varied order; testing had to cover combinations. “Click A then B” vs. “Click B then A” could expose different bugs.
Toolchain fragmentation: resource compiler, different linker flags, different debugger workflows. Build breaks could occur in the resource step, which DOS-only developers had never seen.

Documentation shifted. Instead of “run main, then X, then Y,” teams wrote “on WM_COMMAND with ID Z, the flow is…”. Architecture diagrams showed window hierarchies and message flow, not just procedure call graphs. Onboarding documents included “Windows messaging basics” and “OWL object lifecycle.”

New joiners needed to internalize the event loop and the idea that “your code runs when Windows says so.” That was a larger conceptual jump than learning Object Pascal syntax. Experienced DOS Pascal developers sometimes struggled more than newcomers—unlearning “I control the flow” was harder than never having assumed it.

Code review practices adapted. DOS reviews often traced “what happens when we run.” Windows reviews asked “what happens when the user does X, and in what order do messages arrive?” Test plans shifted from “run through the menu” to “for each dialog, test each control, test tab order, test keyboard shortcuts.” The surface area of “things that can go wrong” grew substantially. Senior developers who had debugged DOS programs for years sometimes needed mentoring from junior developers who had started with Windows—not because the seniors were less skilled, but because the younger developers had never internalised the sequential model and adapted to event-driven design more quickly.

A practical collaboration upgrade in that period was formal handoff contracts between UI and engine work. In DOS-only projects, one developer could often own everything from input parsing to rendering. In TPW projects, that approach scaled poorly because message handlers, dialog resources, and shared core logic changed at different speeds. Teams that stayed healthy wrote explicit contracts:

which messages a form handled directly versus delegated
which unit owned validation rules
which module owned persistence and file I/O
which callbacks were synchronous, and which were deferred

Without this, “small UI tweaks” frequently broke core behavior because a developer moved logic into a handler that now ran under a different timing context.

Windows handoff note (example)
-----------------------------
Form: CustomerEdit
Owner: UI team

Incoming messages of interest:
  WM_INITDIALOG      -> initializes control state
  WM_COMMAND(IDOK)   -> calls ValidateCustomer, then SaveCustomer
  WM_CLOSE           -> prompts if dirty flag set

Engine callbacks:
  ValidateCustomer(Data): owned by core unit UCustomerRules
  SaveCustomer(Data): owned by storage unit UCustomerStore

Invariants:
  - SaveCustomer must never run before ValidateCustomer success
  - Dirty flag set only by control-change events
  - Cancel path must not mutate persisted data

This kind of document looked heavy for small teams and saved debugging days. It made expectations executable in reviews and reduced arguments about “who owns this behavior.” It also improved onboarding because a new developer could read one page and understand the current flow before touching code.

Another change was review vocabulary. DOS reviews asked, “Does this procedure return the right value?” Windows reviews increasingly asked, “In what callback context does this run?” and “What other message paths can trigger this state change?” That second question caught an entire class of defects: duplicated state transitions caused by one logic block being reachable through both menu commands and control notifications.

Teams that developed this callback-context discipline were already preparing for Delphi’s event model, even before switching products. The names changed (OnClick instead of WM_COMMAND branches), but the design concern stayed the same: keep state transitions explicit, idempotent where possible, and reviewable under multiple event paths.

Synthesis: what the toolchain taught

The transition from DOS Turbo Pascal to Object Pascal and TPW was not a language change alone. The Pascal syntax, unit system, and compilation model persisted. What changed was the execution environment, the artifact graph, and the problem-solving strategies. It was a shift in:

Control flow: from sequential to event-driven. Your code became a set of handlers invoked by the runtime, not a script you controlled from start to finish.
Artifacts: from .EXE+.OVR to .EXE+.DLL+resources. The artifact graph grew; build and deploy had more moving parts.
Debugging: from reproducible traces to message-flow analysis. Crashes became context-dependent; instrumentation and hypothesis replaced simple replay.
Deployment: from single-directory to multi-component, multi-profile. “Works on my machine” expanded to “works on which video driver, which memory configuration, which Windows patch level.”

The compiler and linker remained recognizable. The surrounding workflow— resources, callbacks, DLLs, deployment—became the new complexity. Teams that succeeded treated the Windows toolchain as a different system with different rules, not “Turbo Pascal with a new UI library.” The language carried forward; the problem-solving model had to adapt. Developers who made that mental shift were well positioned for Delphi and the 32-bit Windows world that followed. The lessons—event-driven design, resource pipelines, DLL boundaries—carried forward. Delphi refined the language and tooling, but the conceptual bridge from DOS to Windows had already been crossed.

Practical migration: DOS to Windows checklist

For teams porting an existing DOS application to Windows, a disciplined sequence reduced risk:

Isolate platform-dependent code. Identify all Dos, Crt, Graph, and overlay usage. Move them behind abstraction layers or {$IFDEF}-guarded units.
Verify string handling. Audit every place that touches filenames, user input, or API parameters. Introduce conversion routines and use them consistently.
Add the resource pipeline. Create a minimal .RC, link it, verify the app still runs. Add dialogs and menus incrementally.
Replace the main loop. The DOS “repeat until done” loop becomes “register, create, message loop.” Ensure no logic assumed it ran “at startup” in a single pass.
Test on multiple configurations. Different video drivers, different memory, and different Windows versions surfaced bugs that did not appear in development.

Not every DOS app was worth porting. Those that were tightly coupled to hardware (TSRs, direct port I/O, mode-X graphics) required substantial redesign or remained DOS-only. Business logic and data-heavy applications were better candidates.

A phased approach often worked: first a Windows shell that displayed data (perhaps read from a file format shared with the DOS version), then incremental feature parity. Trying to port everything at once usually led to long integration branches and merge pain. Teams that shipped a minimal Windows version early, then iterated, had better feedback and morale.

Full series index

Part 1: Anatomy and Workflow
Part 2: Objects, Units, and Binary Investigation
Part 3: Overlays, Memory Models, and Link Strategy
Part 4: Graphics Drivers, BGI, and Rendering Integration
Part 5: From 6.0 to 7.0 - Compiler, Linker, and Language Growth
Part 6: Object Pascal, TPW, and the Windows Transition (this article)
Part 7: From TPW to Delphi and the RAD Mindset

Turbo Pascal Toolchain, Part 7: From TPW to Delphi and the RAD Mindset

Fri, 13 Mar 2026 00:00:00 +0000

The transition from Turbo Pascal for Windows (TPW) and Borland Pascal 7 to Delphi was not merely a product upgrade. It was a mindset shift: from procedural resource wrangling and manual message dispatch to a visual, component-based, and event-driven workflow. Developers who had mastered TPW’s message loops and resource scripts found themselves in a different world—one where the form designer and object inspector replaced the resource editor, and where component ownership and event handlers replaced explicit handle management.

This article traces that transition from the perspective of a practitioner who lived it. It covers workflow changes, delivery model shifts, debugging adaptations, and team process evolution. The goal is not nostalgia but practical guidance: what to watch for when migrating, what patterns hold, and what pitfalls to avoid. The TPW-to-Delphi path was well-traveled in the mid-to-late 1990s; the lessons learned then remain applicable to any transition from low-level, imperative UI development to a higher-level, component-based framework. This article assumes familiarity with TPW or BP7; readers new to that era may find Part 5 and Part 6 of this series useful for context.

Structure map (balanced chapter plan)

To keep chapter quality even, the article uses a fixed ten-part structure before going deep into each topic:

historical grounding and chronology boundaries
what was at stake in workflow terms
form/resource workflow changes
component model and package mechanics
common migration culprits
build/release pipeline changes
testing/debugging mindset shift
architecture consequences
team-process and delivery-model changes
migration pattern playbook

Each chapter is intentionally expanded with similar depth: mechanism, pitfalls, and practical migration guidance.

Historical grounding: 1993–1996

Delphi development started internally at Borland around 1993. The first public release shipped in February 1995. That release introduced the Visual Component Library (VCL), which became the central framework for visual, event-driven Windows development in Object Pascal. Delphi 2 arrived in 1996 with a strong focus on 32-bit Windows, consolidating the shift away from 16-bit TPW.

These dates matter because they bound the technical assumptions. TPW and BP7 targeted 16-bit Windows. Delphi 1 supported 16-bit; Delphi 2 and later targeted 32-bit. Anyone migrating in that window faced both paradigm and platform shifts.

The competitive landscape also shaped expectations. Visual Basic had established a visual-design paradigm; Borland’s Object Windows Library (OWL) offered an object-oriented wrapper over the Windows API but remained close to the message model. Delphi positioned itself between the two: more structured than VB, more visual than raw OWL. The VCL was the differentiator—a single framework that unified visual design, component reuse, and compiled performance. Delphi 1 supported 16-bit Windows; migration from TPW could proceed without an immediate 32-bit requirement. Delphi 2’s 32-bit focus, arriving in 1996, aligned with Windows 95’s dominance and made the 16-bit path a legacy concern for most new development. The choice of Object Pascal rather than C++ for the VCL reflected Borland’s heritage and the language’s suitability for rapid development: a simpler object model, predictable destruction, and strong typing reduced certain classes of bugs. The trade-off was less low-level control than C++; for most business applications, that trade-off was acceptable. The result was a tool that appealed to both former TPW developers and newcomers from VB or other environments.

What was at stake: from resource wrangler to form designer

In TPW, you typically:

hand-authored or used resource editors to produce .RC and .RES files
wrote WndProc handlers and message-case logic
managed child window placement and styling via API calls
linked and loaded resources explicitly

The mental model was imperative: you told Windows what to do, step by step. Delphi replaced that with a declarative model: you placed components on forms, set properties, and responded to events. The form became the primary unit of design, not the resource file.

// TPW-era: manual dialog creation and message handling
function DlgProc(Dlg: HWND; Msg: Word; WParam: Word; LParam: LongInt): Bool;
begin
  Result := False;
  case Msg of
    WM_INITDIALOG: begin
      SetWindowText(GetDlgItem(Dlg, ID_EDIT), '');
      Result := True;
    end;
    WM_COMMAND:
      if LoWord(WParam) = IDOK then begin
        GetDlgItemText(Dlg, ID_EDIT, Buffer, SizeOf(Buffer));
        EndDialog(Dlg, IDOK);
        Result := True;
      end;
  end;
end;

In Delphi, the same interaction is expressed as component events:

procedure TMainForm btnOKClick(Sender: TObject);
begin
  // Edit1.Text is directly available; no GetDlgItemText
  ProcessInput(Edit1.Text);
  ModalResult := mrOK;
end;

The shift is not cosmetic. Ownership, lifecycle, and coupling all change. In TPW, you were responsible for ensuring that every control you created was eventually destroyed and that no dangling handles survived. In Delphi, the component tree and ownership model handle that—provided you used Create with the correct owner. The mental load shifted from “did I free everything?” to “did I wire the right events and set the right properties?”

A TPW developer who had internalized the message loop could predict exactly when WM_PAINT would fire and in what order. Delphi’s OnPaint and Invalidate abstracted that; the framework decided when to paint. That abstraction was liberating for routine UI work but could be frustrating when squeezing out performance or debugging flicker. Knowing when to drop to WndProc or CreateParams for low-level control became a mark of seniority. Double-buffering, which reduced flicker in TPW by managing WM_ERASEBKGND and paint regions, had VCL analogs (DoubleBuffered, TBitmap offscreen drawing), but the control points were different. Migration often required re-learning where the levers were. Developers who had tuned TPW apps for smooth animation or rapid repaints often needed to re-profile in Delphi: the VCL’s paint sequence and invalidation semantics were not identical to raw WM_PAINT handling. In most cases the default behavior was sufficient; for performance-critical paths, measuring before optimizing remained the rule.

Form and resource workflow changes

TPW projects combined Pascal sources with resource scripts. A typical layout:

MAIN.RC defined menus, dialogs, string tables
BRCC.EXE produced MAIN.RES
$R MAIN.RES pulled resources into the executable

Form layout was encoded in dialog templates. Moving a button meant editing coordinates in the .RC file or using a separate resource editor. Visual feedback was indirect. A typical TPW session might involve: edit .RC, run BRCC, recompile, run, discover the button was two pixels off, repeat. The compile-run cycle was fast, but the layout iteration was tedious.

Delphi introduced the .DFM (Delphi Form) file: a textual or binary representation of the form’s component tree and properties. The form designer and the form’s object inspector became the primary interface for layout and configuration. The .DFM is paired with a .PAS file that defines the component event handlers.

// Delphi unit: MainForm.pas (conceptual)
unit MainForm;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls;

type
  TMainForm = class(TForm)
    Edit1: TEdit;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  MainForm: TMainForm;

implementation

{$R *.DFM}

procedure TMainForm.Button1Click(Sender: TObject);
begin
  ShowMessage('Value: ' + Edit1.Text);
end;

end.

The {$R *.DFM} directive embeds the form’s binary resource. No separate .RC file is needed for the form itself. Dialogs, menus, and layout live in the form file; the Pascal unit owns the behavior.

Early Delphi used binary .DFM by default. The format was compact but opaque; merging conflicts in version control were difficult. Later versions offered text-based .DFM, which improved diffability. Teams doing collaborative form work learned to prefer textual form storage where possible.

The form designer also changed the workflow for alignment and layout. Delphi provided alignment tools, snap-to-grid, and the ability to select multiple controls and align them as a group. This reduced the tedium of pixel-perfect placement and made iteration faster.

The object inspector and design-time behavior

A TPW developer edited resources in one tool and wrote Pascal in another. Delphi unified these: selecting a control in the form designer populated the object inspector with that control’s properties and events. Changing Caption or Enabled took effect immediately in the designer. Double-clicking an event slot (e.g. OnClick) created a stub handler and jumped to the code. This tight loop—design, set property, wire event, run—defined the RAD experience.

Design-time behavior rested on the same component instances that would run at runtime. A form loaded in the designer was a real TForm descendant with real children. Code that assumed a full application context (e.g. Application.MainForm) could fail in the designer. The csDesigning in ComponentState check became a standard guard for code that should run only at runtime. Custom components that performed I/O, showed dialogs, or accessed the network in their constructor needed such guards—otherwise the designer would hang or error when the component was dropped on a form.

The component model and packages

VCL is built on TComponent, which extends TPersistent and introduces ownership, naming, and streaming. Components can contain other components; they participate in design-time and runtime property streaming.

// Minimal custom component skeleton
unit MyButton;

interface

uses
  Classes, Controls, StdCtrls;

type
  TMyButton = class(TButton)
  private
    FClickCount: Integer;
  protected
    procedure Click; override;
  public
    constructor Create(AOwner: TComponent); override;
  published
    property ClickCount: Integer read FClickCount;
  end;

procedure Register;

implementation

constructor TMyButton.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FClickCount := 0;
end;

procedure TMyButton.Click;
begin
  Inc(FClickCount);
  inherited Click;
end;

procedure Register;
begin
  RegisterComponents('Samples', [TMyButton]);
end;

end.

Packages (.DPK) emerged as the unit of distribution for components and optional runtime modules. A package lists units and required packages; it can be design-time only, runtime only, or both. This allowed teams to ship component libraries without recompiling the main application. Design-time packages extended the IDE with new components and editors; runtime packages shipped as .BPL files and reduced application size when shared. The split meant that a bug fix in a shared component could be deployed by updating the BPL—if versioning was under control.

Third-party components and the ecosystem

Delphi’s component model encouraged a market for third-party controls: grids, charting, reporting, database-aware widgets. TPW had little equivalent; you built or hand-rolled most UI. Adopting a commercial component library accelerated development but introduced dependency risk. Components that assumed specific VCL versions, or used undocumented interfaces, could break on upgrade. Teams learned to evaluate components for stability and source availability, not just features. When a critical component was abandoned by its vendor, having the source often meant the difference between a fix and a rewrite.

// Example package source (.DPK)
package MyComponents;

{$R *.RES}
{$DESCRIPTION 'Custom component library'}

requires
  vcl;

contains
  MyButton in 'MyButton.pas';

end.

The component model also introduced the published keyword: properties declared published appear in the object inspector and are streamed to the .DFM. This is where design-time configuration meets runtime behavior.

Understanding the VCL hierarchy helped when extending or debugging components. TObject roots the tree; TPersistent adds streaming and ownership hooks; TComponent adds the component container model and design-time support; TControl adds visual representation and parent-child layout; TWinControl adds the Windows handle. When a form failed to paint or a control behaved oddly, tracing up this chain often revealed where the contract was violated.

// TForm inherits Handle, Parent, BoundsRect, Paint from TWinControl chain
// Override CreateParams, CreateWnd, WndProc for low-level customization
procedure TMyForm.CreateParams(var Params: TCreateParams);
begin
  inherited CreateParams(Params);
  Params.Style := Params.Style or WS_CLIPCHILDREN;
end;

Culprits and pitfalls during migration

Migration from TPW to Delphi was rarely a clean mechanical translation. The syntax was similar; the runtime model was not. Teams moving in that period encountered several recurring failure modes. Recognizing them early saved significant debugging time. What worked in TPW could fail subtly in Delphi, and the failures were often intermittent—dependent on timing, handle state, or initialization order.

Resource and handle confusion. TPW code often stored HWND or HMenu values and passed them to API calls. Delphi wraps these in component properties. Accessing the raw handle is still possible (Handle, Menu.Handle), but component lifetime now governs when that handle is valid. Code that cached handles across form recreate or destroy cycles could break.

Message loop assumptions. TPW applications sometimes relied on custom message loops or PeekMessage/GetMessage patterns. The VCL provides its own application message loop. Bypassing it or mixing models led to inconsistent behavior and hard-to-reproduce bugs.

String and type mismatches. TPW used ShortString by default. Delphi introduced AnsiString as the default string type (in 32-bit Delphi), with automatic memory management. Code that relied on length-byte semantics or passed strings to legacy APIs without conversion could fail.

// Pitfall: assuming ShortString semantics with AnsiString
procedure LegacyInterop;
var
  S: string;  // AnsiString in 32-bit Delphi
  Buf: array[0..255] of Char;
begin
  S := Edit1.Text;
  // Wrong: AnsiString is null-terminated, not length-prefixed
  // Right: StrPLCopy(Buf, S, High(Buf)); then use Buf for API calls
end;

Unit initialization order. Delphi units have initialization and finalization sections. Dependency order affects startup and shutdown. Circular unit references, or initialization that assumed a specific load order, could cause subtle crashes. A unit that allocated resources in initialization and freed them in finalization was generally safe—unless another unit’s initialization ran later and expected those resources to exist. Debugging startup crashes often meant tracing the unit load order in the project’s uses clause and the uses clauses of each unit. Circular references between units caused compile errors; circular logic in initialization (A init calls B, B init calls A) caused runtime failure. Breaking cycles by extracting shared code into a third unit, or deferring init to a later phase, was the standard fix.

Over-reliance on global state. TPW code often used global variables for form references and shared data. Delphi encourages form instances and component ownership. Migrating without refactoring globals led to re-entrancy and lifetime bugs.

Modal vs modeless confusion. TPW used DialogBox for modal dialogs and CreateWindow for modeless. Delphi’s ShowModal and Show map to that, but the timing of OnShow, OnActivate, and OnCreate differs from the raw API sequence. Code that assumed a specific order (e.g. painting before data load) could break. Testing both modal and modeless code paths was essential.

Integer and pointer size changes. In 16-bit TPW, Integer and Pointer were both 2 bytes (or 4 for far pointers). In 32-bit Delphi, Integer stayed 4 bytes but Pointer became 4 bytes in a flat address space. Code that stuffed pointers into Word or Integer for storage could truncate or corrupt. Using LongInt or Pointer explicitly for pointer-sized values avoided surprises.

RecreateWindow and handle invalidation. When a form’s RecreateWnd or similar mechanism ran (e.g. after changing BorderStyle or BorderIcons), the underlying HWND was destroyed and recreated. Code that cached the handle in a variable held a stale value. The pattern if HandleAllocated then before using Handle became a habit.

Build and release workflow

TPW builds were typically driven by the IDE or a small batch script that invoked the compiler and linker. Output was a single .EXE or .DLL. Delphi preserved that simplicity for many projects but added:

project files (.DPR) as the entry point
form units and {$R *.DFM} as first-class build inputs
package builds for component libraries
conditional compilation and build configurations

The project file (.DPR) replaced the old “main program” as the coordination point. It listed form units, marked which forms were auto-created (and thus loaded at startup), and could embed conditional compilation for different build targets. Auto-created forms simplified startup but could slow launch when many forms were created eagerly. Teams learned to create forms on demand (Form2 := TForm2.Create(Application); Form2.Show;) when memory or startup time mattered.

A minimal Delphi project:

program MyApp;

uses
  Forms,
  MainForm in 'MainForm.pas' {Form1};

{$R *.RES}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Command-line builds became DCC32.EXE (32-bit) or DCC.EXE (16-bit in Delphi 1). The linker (ILINK32 in 32-bit) consumed object files from the compiler; package references and external object modules were configured in the project or unit sources. Release builds often disabled debug info ($D-), local symbol info ($L-), overflow checking ($Q-), range checking ($R-), and stack checking ($S-). Teams learned to freeze these settings per configuration. Enabling checks in debug builds caught many bugs before they reached production; disabling them in release improved performance. The discipline was to fix any violation exposed by checks rather than disabling checks to silence the error. A build that succeeded with $R+ in one configuration and failed with it in another indicated a latent bug. Treating such failures as “the check is wrong” rather than “we need to fix the code” was a common but costly mistake. Range and overflow checks were cheap enough in debug that the performance argument against them rarely held.

The shift to 32-bit also meant larger executables and different deployment considerations—no more overlays, but more reliance on DLLs and packages for modular delivery. A typical build script might invoke DCC32 with -B (build all), -$D- (no debug info), and -$R- (no range check) for release. Staging the correct runtime packages (VCL*.BPL, RTL*.BPL) alongside the .EXE became part of the release checklist. The build pipeline itself was similar in spirit to TPW: compile units to object files, link to executable. The difference was scale—more units, form resources, and optional packages. Automated builds that had been simple batch files grew into scripts with conditional compilation, path setup, and post-build steps (e.g. version stamping, resource injection). Teams that delayed automation paid a tax during release cycles when manual steps were forgotten or executed in the wrong order.

// Project options often embedded in .DPR or a separate .CFG
// Conditional defines for build variants
{$IFDEF RELEASE}
{$D-} {$L-} {$Q-} {$R-} {$S-}
{$OPTIMIZATION ON}
{$ELSE}
{$D+} {$L+} {$Q+} {$R+} {$S+}
{$OPTIMIZATION OFF}
{$ENDIF}

Testing and debugging mentality shift

TPW debugging was breakpoint-and-inspect. You set breakpoints, stepped through WndProc and message handlers, and used the CPU view when things went wrong. The event model was explicit; you could trace from message to handler.

Delphi’s event-driven model changed the mental model. A button click did not map to a single linear path. Events could be chained (e.g. OnChange triggering further updates), and the call stack often included VCL framework code. Debuggers gained form-aware inspection: you could inspect the live form, its components, and their properties at breakpoints.

// Event-driven debugging: understand the call chain
procedure TForm1.Button1Click(Sender: TObject);
begin
  // Set breakpoint here; Sender tells you which button fired
  UpdateStatus;  // May trigger other events
end;

procedure TForm1.UpdateStatus;
begin
  // Breakpoint here to see who called UpdateStatus
  Label1.Caption := ComputeStatus;
end;

A recurring debugging scenario was “why did my form not update?” In TPW, you traced WM_PAINT or InvalidateRect. In Delphi, you checked whether Invalidate or Repaint was called, whether the control was visible, and whether OnPaint was overridden correctly. The data window (inspecting component properties at breakpoints) became as important as the watch window. Seeing that Label1.Caption was empty when you expected text, or that Edit1.Visible was False, often explained the bug without stepping through framework code.

The shift also encouraged a different testing approach: rather than exercising raw message paths, tests targeted event handlers and component state. Unit testing frameworks were rare in the mid-1990s, but the separation of event handlers from UI layout made it easier to reason about behavior in isolation.

When debugging failed, the CPU view remained the fallback. Crashes in VCL internals or third-party components often required setting a breakpoint on exceptions, then inspecting the call stack and registers. The “Evaluate/Modify” dialog let you execute expressions and change variables at breakpoints—useful for testing fixes without recompiling. Teams developed a habit of creating minimal reproduction cases: a blank form with one or two controls that exhibited the bug, stripped of application-specific logic.

Architecture implications

RAD and the VCL did not mandate architecture, but they pushed architects toward certain patterns. Teams that resisted sometimes paid a maintenance tax; teams that embraced them could scale. The framework rewarded specific ways of organizing code and penalized others.

Persistence and streaming. The VCL’s streaming system allowed forms and components to be saved and loaded without hand-written serialization. The TReader/TWriter and DefineProperties mechanism supported custom data in components. Component authors who needed to store non-published state could override DefineProperties to read and write their data. This was powerful but easy to get wrong—version mismatches between stored and current property semantics could corrupt form files. Defensive readers that checked version numbers or used try/except around property reads were common. Custom components that stored complex data (e.g. tree structures, graphs) had to decide whether to use DefineProperties or separate files. Embedded storage simplified deployment; separate files allowed formats that could be edited independently.

Event-driven design. Logic moved from a central message pump into distributed event handlers. This improved locality (each component owned its responses) but could scatter business logic across many handlers. Disciplined teams extracted core logic into service units or classes, keeping handlers thin. The Sender parameter in events allowed one handler to serve multiple controls (e.g. several buttons sharing an OnClick), but that pattern could obscure which control actually fired. Using separate handlers or if Sender = Button1 kept intent clear. The balance between DRY and readability was project-specific.

Threading and the main thread. The VCL was not designed for multi-threaded UI updates. Modifying control properties or calling UI methods from a worker thread could cause unpredictable crashes. The rule was: all UI updates must happen on the main thread. Synchronize and Queue (in later Delphi versions) marshaled work from background threads to the main thread. TPW code that had used worker threads for long operations had to be adapted to this model; the logic could stay in the thread, but any UI feedback had to go through Synchronize.

Separation of concerns. The form file (.DFM) held layout and property defaults; the Pascal unit held behavior. That split made it easier to version-control and merge changes, though .DFM binary format could be opaque. Later Delphi versions supported textual .DFM for clearer diffs. The separation also meant that a designer could adjust layout without touching code, and a developer could change behavior without risking layout. In practice, the split was porous—event handlers often reached into control properties, and layout could affect behavior (e.g. tab order, focus). But the ideal was clear: form for structure, unit for logic. Tab order in particular caused headaches: the designer set it visually, but adding or removing controls could scramble the intended flow. Using TabOrder explicitly, or the tab-order dialog, was part of the polish that separated finished applications from prototypes.

Component reuse and ownership. The Owner parameter in TComponent.Create established parent-child relationships. Destroying a form destroyed its components. This eliminated many manual cleanup bugs but required understanding ownership when creating components dynamically. Creating a control with nil as owner meant you were responsible for freeing it—a common source of leaks when the pattern was forgotten. The rule “always pass an owner when you have one” became second nature.

// Ownership: Created edit is owned by Form1, freed when Form1 is freed
procedure TForm1.AddDynamicEdit;
var
  E: TEdit;
begin
  E := TEdit.Create(Self);  // Self = Form1 = owner
  E.Parent := Self;
  E.Top := 10;
  E.Left := 10;
  E.Text := 'Dynamic';
end;

Dependency direction. Well-structured Delphi projects kept business logic in units that did not depend on Forms or Controls. UI units depended on business units, not the reverse. This preserved testability and reuse.

// Good: business logic unit has no UI dependency
unit OrderLogic;

interface
function ValidateOrder(const OrderId: string): Boolean;

implementation
// No Forms, Controls, or Graphics
end.

// UI unit depends on OrderLogic
unit OrderForm;

uses
  ..., OrderLogic;

procedure TOrderForm.btnValidateClick(Sender: TObject);
begin
  if ValidateOrder(edtOrderId.Text) then
    ShowMessage('Valid');
end;

Form bloat. A common anti-pattern was the “god form”: one form with dozens of controls and thousands of lines. Splitting into sub-forms, frames (when available), or tabbed interfaces required discipline. The RAD temptation was to keep adding controls; the architectural response was to extract coherent panels into separate units.

Data binding and the missing link. Early Delphi did not ship a formal data-binding framework. Developers manually moved data between controls and business objects in event handlers. The pattern “read from controls, validate, update model, write back to controls” was common. This worked but scattered synchronization logic. Third-party data-aware controls and later framework additions addressed some of this; disciplined teams often built thin adapter layers to centralize the binding logic.

Delivery model and team process changes

The RAD promise was faster delivery. The reality was more nuanced.

TPW projects often had a single developer or a small team with clear handoffs: one person owned resources, another owned logic. Delphi’s RAD workflow encouraged faster iteration. A developer could design a form, wire events, and see results without leaving the IDE. That accelerated prototyping but also tempted teams to skip design—“we’ll fix it later” became a common anti-pattern.

Delivery cycles shortened. Demo builds could be produced in hours. The flip side was technical debt: forms with hundreds of controls, event handlers doing too much, and little automated testing. Teams that adopted coding standards (handler size limits, mandatory extraction of business logic) fared better.

When RAD went wrong, the symptoms were familiar: a form that “worked” until you changed one thing and then everything broke; event handlers that called each other in circular ways; business logic embedded in OnClick that could not be tested without spinning up the full form. The remedy was the same as in non-RAD projects—extract, decompose, test—but the temptation to stay in “fast mode” was stronger because the IDE made it easy to keep adding. Senior developers learned to recognize the moment when a form or handler had crossed the complexity threshold and needed refactoring.

Distribution also changed. TPW produced a standalone .EXE plus any DLLs. Delphi could do the same, but package-based deployments (runtime packages like VCL50.BPL) allowed smaller executables and shared framework updates. The trade-off was versioning: mismatched package versions caused load failures. “DLL hell” extended to packages: installing a new application could overwrite shared BPLs and break existing ones. Many teams chose static linking for distribution to avoid that risk.

Team roles shifted. The “resource person” role diminished; the “form designer” and “component author” roles emerged. Code reviews began to ask “is this handler too large?” and “should this logic live in a service unit?” Pair programming, where it existed, often involved one person driving the form designer while the other focused on event logic and backend integration. The division was natural: layout and property wrangling on one side, data flow and validation on the other. Teams that formalized this split—e.g. “form designer” and “form programmer” roles—sometimes produced cleaner boundaries than those where one person did everything. The risk was handoff friction when the designer’s intent was not clear from the form alone.

Practical migration patterns

When porting TPW code to Delphi, these patterns proved reliable.

Extract message handlers into event-like procedures. Wrap the core logic in a procedure with clear parameters; call it from both the old WndProc path and the new event handler during transition.

procedure DoProcessInput(const AText: string);
begin
  if Trim(AText) = '' then Exit;
  // Core logic here
end;

// TPW: call from WM_COMMAND handler
// Delphi: call from Button1Click with Edit1.Text

Introduce form classes gradually. Start with a blank form, add controls one at a time, and move logic from global procedures into form methods. This avoids big-bang rewrites. Resist the urge to convert all dialogs in one pass. Pick the simplest dialog first, migrate it, validate, then proceed. Each successful migration builds confidence and surfaces patterns that apply to the next.

Create a compatibility shim for shared code. If both TPW and Delphi executables need to call the same business logic during transition, extract that logic into a unit with no UI dependencies. Both projects can use it. Pass data via parameters, not globals. This keeps the migration reversible and reduces the risk of fork drift. The shim unit should avoid VCL-specific types where possible; use plain Pascal types (string, Integer, records) for interfaces that cross the TPW/Delphi boundary.

Verify string and API compatibility. Use StrPLCopy and StrPCopy when passing strings to Windows API. Check PChar vs PAnsiChar in 32-bit Delphi. Test with empty strings and long strings; ShortString and AnsiString differ at the boundaries.

// Safe API string passing
procedure SafeAPICall(const S: string);
var
  Buf: array[0..259] of AnsiChar;
begin
  StrPLCopy(Buf, AnsiString(S), High(Buf));
  SomeAPI(@Buf[0]);
end;

Lock build configuration early. Decide debug vs release, range check on/off, and optimization level. Document and automate. Avoid ad hoc changes during release crunches.

Migration checklist. A practical sequence:

1. Inventory TPW dialogs and main windows; map each to a target form.
2. Create empty forms, add controls to match layout, wire stub events.
3. Move message-handler logic into event handlers; extract shared logic.
4. Replace global form references with Application.FindComponent or parameters.
5. Audit string types at API boundaries; add StrPLCopy/StrPCopy where needed.
6. Run under range checking and overflow checking; fix violations first.
7. Test modal/modeless behavior; verify focus and activation order.
8. Freeze build options; document and script the release build.

Use Application.OnMessage sparingly. The global message hook can help during migration to intercept specific messages, but it runs for every message and can obscure the event-driven flow. Prefer component-level overrides or message handlers (TForm supports WM_* procedure declarations) for targeted handling.

// Form-level message handler: more targeted than Application.OnMessage
type
  TMainForm = class(TForm)
  private
    procedure WMUserMsg(var Msg: TMessage); message WM_USER;
  end;

procedure TMainForm.WMUserMsg(var Msg: TMessage);
begin
  // Handle custom message; call inherited for default behavior if needed
  ProcessCustomMessage(Msg.WParam, Msg.LParam);
end;

Preserve TPW project artifacts during transition. Keep a known-good TPW build and its sources in version control. If a Delphi regression appears, you can compare behavior and isolate whether the bug is in migrated logic or the new framework. When the migration is complete, archive rather than delete—historical reference has value for onboarding and retrospective analysis.

Treat the first migrated dialog as a prototype. Use it to establish conventions: naming (e.g. btnOK not Button1), handler structure, where validation lives. Document those conventions and apply them consistently. The first migration is always the hardest; later ones benefit from the patterns you extract. Skipping the documentation step means each developer reinvents the approach, and inconsistency makes maintenance harder.

Expect a learning curve for the form designer. TPW developers who had never used a visual designer faced new concepts: alignment palettes, tab order, anchor and alignment properties (in later Delphi versions), the difference between selecting the form and selecting a control. Spending a few hours on throwaway forms to learn alignment, anchoring, and the property inspector paid off before tackling a real migration. Misunderstanding the designer led to layout bugs that were hard to fix by hand-editing .DFM.

First 90-day Delphi adoption cadence

Teams that transitioned cleanly usually followed a staged first-quarter plan, not an all-at-once rewrite:

Days 1-30:
  - pick one medium-complex form
  - define naming/event conventions
  - establish build options and debug baseline

Days 31-60:
  - migrate 3-5 related dialogs/forms
  - extract shared non-UI logic into units
  - add regression checklist for core user flows

Days 61-90:
  - package reusable controls/components
  - document standard form lifecycle hooks
  - formalize release checklist and rollback criteria

This cadence solved two chronic problems: premature abstraction and duplicated mistakes. Premature abstraction happened when teams designed a full internal “framework” before they had migrated enough screens to understand recurring patterns. Duplicated mistakes happened when each developer migrated forms in isolation with personal conventions. A short, staged cadence turned both into manageable process work.

A practical metric during this period was “time from UI change request to tested build.” If that time dropped while defect rate stayed stable, Delphi adoption was producing value. If the time dropped but defect rate climbed, the team was moving too fast without enough shared conventions.

Summary and outlook

The TPW-to-Delphi transition was more than a product upgrade; it was a paradigm shift in how Windows UI was built: from imperative, resource-centric Windows development to a visual, event-driven, component-based model. VCL and the form designer changed how developers conceived of UI, and the RAD mindset changed delivery expectations. Teams that understood both the gains (faster iteration, clearer ownership, component reuse) and the pitfalls (handle lifetime, string types, over-coupled forms) navigated the transition successfully.

Delphi’s influence extended beyond Borland. The component model, property inspector, and form designer pattern appeared in other tools and languages. The Object Pascal language evolved but remained recognizable to TPW practitioners. For those tracing the Turbo Pascal toolchain into the Windows era, Delphi is the natural continuation—and the RAD mindset it introduced still shapes how many think about UI development today. The move from “write code that creates UI” to “design UI and write code that responds” has informed every major GUI framework since.

The transition also illustrated a recurring tension in tool evolution: each abstraction layer buys productivity at the cost of opacity. TPW developers could read the SDK and understand every message; Delphi developers relied on the VCL to do the right thing. When the abstraction leaked—handle lifetime, recreate behavior, focus management—the ability to reason about the lower level became valuable. The best Delphi practitioners kept that mental model intact. They knew when to use Sender in an event to identify the originating control, when to override WndProc versus using OnMessage, and how to trace from a visible bug back through the message or event chain. That knowledge, built during the TPW-to-Delphi transition, remained valuable for as long as Windows and the VCL evolved together.

Object-Pascal on TurboVision

Turbo Pascal Toolchain, Part 6: Object Pascal, TPW, and the Windows Transition

Structure map (balanced chapter plan)

Object Pascal arrives: TP 5.5 and the OOP extensions

Turbo Pascal for Windows 1.0: the first wave

TPW 1.5 and the post-TP7 landscape

BP7: unified DOS and Windows toolchain

OWL and message-driven architecture

Technical culprits and pitfalls

Debugging workflows: DOS vs Windows

Build and deploy: DOS vs Windows

Team collaboration and mental model shift

Synthesis: what the toolchain taught

Practical migration: DOS to Windows checklist

Related reading

Full series index

Turbo Pascal Toolchain, Part 7: From TPW to Delphi and the RAD Mindset

Structure map (balanced chapter plan)

Historical grounding: 1993–1996

What was at stake: from resource wrangler to form designer

Form and resource workflow changes

The object inspector and design-time behavior

The component model and packages

Third-party components and the ecosystem

Culprits and pitfalls during migration

Build and release workflow

Testing and debugging mentality shift

Architecture implications

Delivery model and team process changes

Practical migration patterns

First 90-day Delphi adoption cadence

Summary and outlook

Related reading