When the Default String Changed Everything
Delphi 2009, released in August 2008, carried a change that no Embarcadero press release could fully soften: the default string type became UnicodeString, a UTF-16 reference-counted type, replacing the AnsiString that had served as Delphi's native string since the mid-1990s. Every line of code that passed a string to the Windows API, compared string buffers, or assumed one character equalled one byte became a candidate for silent misbehaviour. The installed base of Delphi applications — accumulated over thirteen years of commercial and enterprise development — faced a migration of genuine scope.
The rationale was unambiguous and, to Embarcadero's credit, stated plainly. Windows itself had moved to UTF-16 as its native text encoding with Windows NT, and modern Win32 API calls expected wide-character strings. Wrapping every API call with an AnsiToWide conversion was a workaround that had aged badly by 2008, and the rise of internationalised applications made the workaround visible in ways it had not been earlier. Embarcadero's engineering teams described the change as aligning the language with the operating system's own native string representation — a description that was accurate, if bracing for anyone holding a large codebase.
The VCL's depth is the point: a form arrives with several generations of ancestor behaviour already linked into it.
The Shape of the Migration Burden
The breakage was not dramatic in any single file; it was distributed. Code that passed a PChar pointer expected an array of AnsiChar; after Delphi 2009, PChar mapped to PWideChar. String literals fed directly into byte-level parsing routines now carried two bytes per character. Third-party component libraries — those from DevExpress, TMS Software, and independent authors — all required updates before they compiled cleanly under the new model. The VCL (Visual Component Library) itself was revised throughout, with property types audited and streaming code amended to handle the wider character set.
Mid-1990s PC hardware is what the size argument was made against: a machine measuring its memory in megabytes, not gigabytes.
Photo: Nicolas Foster / Pexels
The compiler did not reject old source silently; it issued warnings and, in certain cases, errors where the type system could detect the mismatch. But warnings in a project with hundreds of units accumulate quickly, and each one demanded a decision — whether the code was genuinely broken, whether an explicit AnsiString annotation would preserve the old behaviour, or whether the logic itself needed rethinking. Embarcadero provided a migration guide and added distinct typed-string aliases — AnsiString, RawByteString, UTF8String — so that developers who needed to preserve byte semantics could annotate rather than rewrite. RawByteString in particular became a useful escape hatch for binary and protocol-level code where encoding was irrelevant.
The community response, recorded in newsgroups, on the Embarcadero developer forums and in The Delphi Magazine's later retrospectives, divided roughly along application-domain lines. Developers writing new greenfield software or working with database front-ends welcomed the change; Unicode had been a chronic source of workarounds in that space. Developers maintaining legacy systems, serial-port drivers, embedded communication layers, or anything that treated strings as byte arrays regarded the migration as an unbudgeted tax. The JEDI component library community undertook its own sustained audit to bring the JVCL and JCL up to Delphi 2009 compatibility.
The Tradeoff Embarcadero Named
What made Delphi 2009's Unicode shift historically notable was the explicitness of the acknowledgement. Embarcadero did not present the migration as painless. Its documentation and developer-relations communications named the compatibility break directly, framed it as the cost of correctness, and offered migration documentation ↗ alongside the new typed aliases as the mechanism for managing it. That posture — naming the tradeoff rather than obscuring it — was itself a departure from the kind of release communication that had become routine during the later Borland years.
The longer consequence was a cleaner compiler, better aligned with the direction Windows applications had been heading since Windows 2000. Delphi's string handling was, after 2009, genuinely Unicode-first rather than Unicode-by-negotiation. The cost was real: developers who had standardised on Delphi 7 precisely because of its stability found one more reason to defer migration past that version. The string change did not cause the installed-base split on its own — Delphi 7's long shadow predated it — but it sharpened the line between those who had moved forward and those who had not.
More in Delphi