The Overhead That Started the Argument
Every Delphi developer in the late 1990s knew the number: a "Hello, World" application compiled against the VCL weighed somewhere between 200 kilobytes and half a megabyte depending on version and whether runtime packages were in use. For most commercial work, that was irrelevant — disk and RAM were cheap, and the Visual Component Library delivered a genuinely productive abstraction over the Win32 API. But a minority of developers found the number intolerable, and one of them was Vladimir Kladov, a Russian programmer who began publishing KOL — the Key Objects Library — in the late 1990s as a direct technical counterproposal.
The VCL's size came from its design goals. TObject sat at the root of every class hierarchy; TWinControl and TControl added owner-draw, anchoring, and the full published-property machinery; the streaming system that made DFM files work required RTTI embedded in every binary. None of that was waste given the VCL's intended purpose, which was to make the Object Inspector work, to make visual inheritance possible, and to make component packages drop into an IDE at design time. But those goals carried a fixed cost whether or not a given application ever opened a form, streamed a component, or exposed a published property.
Kladov's objection was precise: the VCL paid that cost unconditionally. A utility that managed files or read from the registry paid for the entire streaming substrate, the RTTI tables, the BPL infrastructure — none of which it used. His alternative was to ask what the absolute minimum framework for a Win32 GUI application actually looked like, and then to build only that.
What KOL Was, Technically
KOL replaced the VCL's class hierarchy with a much flatter structure built around a single core record type — PControl, a pointer to a record rather than a class instance — and a set of procedural wrappers over Win32 API calls. The design rejected Delphi's object model as its primary organizational tool not out of hostility to objects but because the VCL's inheritance chains were themselves a source of code pulled into the linker's reach. Where the VCL encouraged deep inheritance — TForm descended from TScrollingWinControl, which descended from TWinControl, which descended through several more generations to TObject — KOL kept the hierarchy shallow enough that the compiler's dead-code elimination could strip anything the application did not reference.
This mattered because Delphi's linker had always been a smart-linker in principle: it included only units and routines that were actually referenced from the compiled binary. The VCL's architecture worked against this in practice. A reference to TForm pulled in TApplication, which pulled in message-dispatch infrastructure, which pulled in further dependencies, until a substantial fraction of the framework was in the binary regardless of intent. KOL's record-and-procedure architecture kept those dependency chains short and auditable.
A working records desk of the kind Delphi was bought to build software for — the business applications that made the compiler its market.
Photo: Pavel Danilyuk / Pexels
The result was executables in the tens of kilobytes. Applications with genuine functionality — a window, menus, a list, file I/O — compiled to under 100 KB as a routine matter. Kladov published benchmark comparisons on his site demonstrating the gap; the figures were not marginal. A KOL application doing the same visible work as a VCL application was typically five to ten times smaller. For developers distributing over dial-up connections in the early 2000s, or targeting embedded Windows CE devices where flash storage was measured in megabytes rather than gigabytes, the difference was not aesthetic — it was a deployment constraint.
MCK: Giving KOL a Designer
The technical objection to KOL's model was immediate and fair: the VCL's size was not merely the cost of RTTI and streaming; it was the price of the visual form designer. Drag a component onto a form, set its properties in the Object Inspector, and Delphi generated the DFM and the constructor calls automatically. KOL's procedural creation model required hand-written code for every control. That was acceptable for small utilities but became onerous for anything with a non-trivial interface.
Kladov's answer was the Mirror Classes Kit — MCK — a companion library that provided a parallel set of pseudo-components visible only inside the Delphi IDE at design time. MCK components mirrored the KOL control set: there was a MCK equivalent for each KOL window, button, list, and so forth. At design time, a developer placed MCK components on a form and set their properties in the Object Inspector exactly as with ordinary VCL development. MCK then generated the corresponding KOL procedural code as an {$include} file, which the production build compiled against KOL rather than the VCL. The design-time binary used the VCL; the shipped binary did not.
It was a genuinely clever sleight of hand. The workflow looked like standard Delphi RAD development from the inside, and the output was a KOL executable with none of the VCL's runtime footprint. The MCK components were themselves VCL descendants — they had to be, to live in the Delphi component palette — but they existed only to drive code generation, not to appear in the deployed application. The two libraries were thus architecturally separate: VCL for the design surface, KOL for the binary.
The Community and the Argument It Was Making
KOL and MCK attracted a specific kind of developer: one who regarded binary size not as a vanity metric but as a correctness criterion. The community that formed around Kladov's work — active on forums and through his own published documentation throughout the 2000s — shared the conviction that a program's weight should be proportional to what it actually did. This was an old argument in software, traceable to the culture of assembly-language programming and to the constraints of early microcomputers, but it had particular force in the Delphi world because the VCL made the overhead so visible and so measurable.
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 argument was also implicitly a critique of the direction commercial Delphi development was taking. Each successive Delphi release through the Borland and later Embarcadero eras added framework capability — generics, FireMonkey, mobile targets, enterprise connectivity — and each addition widened the gap between what KOL developers considered necessary and what a standard VCL application pulled in. KOL stayed anchored to Win32 and to the premise that the platform's own API was a sufficient foundation if the wrapper over it was thin enough.
Free Pascal support followed, extending KOL's reach beyond the Delphi compiler and giving the library a second life as the commercial Delphi market consolidated toward larger teams and larger applications. Kladov continued maintaining and extending KOL well into the 2010s, adding Windows Unicode support, additional control types, and documentation in both Russian and English. The library remained what it always was: a working demonstration that the overhead a developer accepted was a design choice, not a physical law.
The VCL was not wrong to cost what it cost — its feature set justified its weight for the applications it was designed to support. But KOL was right that a substantial class of programs did not need that feature set, and that for those programs the cost was simply waste. That is the argument Kladov published in code, and it remains legible in every sub-hundred-kilobyte executable the library ever produced.
More in Delphi