Mastering Delphi 5 2025 Annotated Edition Is Now Complete
blog.marcocantu.com
blog.marcocantu.com
While I get the aversion, HTML+CSS is a pretty good combination for layout and there are efforts towards application tooling for other languages. That said, I don't dislike JS/TS nearly as much as some on here. It's a highly expressive language that's flexible enough to get things done in a number of ways. And yeah, the overhead is kind of crazy, especially when devs bring in massive dependency chains. As a whole, it's still one of the better options for getting an application "everywhere".
It is incredible that given its heritage, we have had to wait 25 years for .NET to finally provide a similar experience, and there are still some rough edges.
While it offered a way to perform AOT compilation, NGEN was only meant for fast startup and nothing else.
It's even the same person: Microsoft poached Anders Hejlsberg, creator of both Turbo Pascal and Delphi, to architect .net.
If anyone poached Anders Hejlberg, it was the ex-Borland friends working at Microsoft, under the usual referral program many companies have.
Actual history behind on what happened,
"Anders Hejlsberg: A craftsman of computer language"
https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-c...
And yes that is why .NET not having proper AOT in 2001 was such a disappointment.
For example, all layout was pixel based. Making windows resizable required much complex ad-hoc code, and internationalization was hard as well. Very early in my career, I have spent person months clicking through every single screen in a large desktop application to find words cut off due to words having different lengths (measured in pixel) in different languages. I knew what "Ok" and "Cancel" meant in half a dozen languages. At the time, Java was really breaking ground with container based layouts in Swing. Delphi and Visual Basic caught up only in the .NET era.
Back in the day, JBuilder offered a Delphi like experience.
What I would agree is that the thing that actually made Swing hard are the defaults, which required books like "Filthy Rich Clients" as gate into making wow Swing applications.
> All layout was pixel based.
I'd say that was a very reasonable trade-off at the time, when most screens were somewhere between 640x480 and 1024x768 resolutions at 72 DPI. This simplified UI design sufficiently enough that VB/Delphi provided an optimal solution that, yes in hindsight, would most accurately be described as a "local maxima" for the environment and the time.
> Making windows resizable required much complex ad-hoc code
I remember there were ActiveX controls one could drop onto their form that would attempt to derive the layout based on initial positioning of controls, i.e. that a lower row of buttons should be anchored to the bottom of the window, while textboxes are took up a larger area would automagically resize with the window.
(it has been a very long time, but I think those only handled internal composition and not overall window size.. so you'd still need some custom code if you wanted dialogs as compact as possible. But as long as you never missed setting Align property, you did _not_ have to manually resize every control for different text/font size).
https://web.archive.org/web/20160406102051/http://vbrad.com/...
Oh my was I amazed.
https://docs.oracle.com/javase/8/docs/api/java/awt/class-use...
Believe that was there from the beginning, mid 90s.
Microsoft has been pushing XAML for long enough that it could drink, drive and vote in my country
These sort of excuses always come up when Delphi and its insane productivity is mentioned. The same thing happens in conversations about how slow software has gotten.
High-DPI displays, internationalization, and accessibility are a pain but don't introduce enough complexity to hand-waive away the criticism.
Going a bit off-topic, but the browser is carrying around so many legacy concepts and ideas - it's a complete disaster - but it's the only option. The document object model is slow and weird to use to build reactive user interfaces.
We should demand something better. The browser is a local maximum as an application platform, and we should stop defending it.
Both had layout managers, they just required a bit more effort to use, and developers as we know are all lazy.
Unfortunately "dependency hell" was very real -- it was super-easy to download ActiveX controls, install on the system, and then depend on them in the apps. Worse, Windows had a single ActiveX database per computer, and an control installed by a completely unrelated app would appear in the Delphi's palette, ready to be placed on a form. After having a few apps that would not work on friends' computers, I've mostly gave up on ActiveX components completely.. luckily third-party Delphi components were better - at least the compiled binaries would work. Source code still required system-wide install though...
If you think that "pip install", or "npm install", or even "apt-get install" on a Linux system is bad, you haven't seen what Delphi world was like. But to be fair, it's not really Delphi's fault - all Windows development was like that, full of bespoke settings that need to be set on each PC. For a complex software, it was normal to spend a few days just setting up the system so you can do initial build.
Another Delphi-specific issue was that by default forms were specified in pixels, and were hard-coded to specific font sizes; and color pickers had hardcoded colors (as opposed to system theme colors) prominently displayed. Unless you were very careful, it was very easy to make an app that could not handle different font or screen theme. And many apps that would benefit greatly from being resizable were non-resizeable instead, just because it was easier.
In fact AFAIK ActiveX support in Delphi was implemented by generating a wrapper component that converted the ActiveX control stuff to what Delphi "naturally" speaks.
For forms, even in Delphi 2 you can use the "align" property in several controls to automatically position them inside a container using the top, bottom, left, right and client area. The areas also stack so you can, e.g., position several controls at the top area and you'd get an effect similar to what a VBox container would provide in other toolkits. Though the initial versions of Delphi did not have this available everywhere, it was added to various controls over time.
Later versions also added "anchors" so that you can drag-drop stuff visually to the form but also have them resize automatically based on the parent's size. Lazarus (sort of open source Delphi-like IDE) extended this to allow anchoring stuff related to other control (so, e.g., you could have a button's right side a few pixels from another button's left side and that button's right side be a few pixels from the container's right side, or have a label be placed at the middle of an input box, or other stuff like that).
Maybe, but Delphi had anchor fields that you could use to make everything resize nicely.
The problem with that time period was that most applications were designed to not be resizeable, including most of the ones that came with Windows itself.
We still have that - some of the Windows programs right now can't be resized (Thinking specifically of dialogs and windows for device manager->driver details, or explorer->options).
This wasn't a Delphi problem at all; it was a Windows problem because that was the convention on Windows at the time.[1]
[1] EDIT: s/Windows/GUI systems/g
And I don't think other GUI systems were all that much better. Eg MacOS has plenty of fixed size stuff right now.
It was convention across all GUI systems.
As far as COM and ActiveX, though, the ability to package them side by side in the app install folder and describe them using XML (in the app manifest) rather than registry has been around since WinXP.
I also feel like this created a kind of positivity at the time rarely experienced today. I remember these Delphi conferences I used to go to as a teenager with my dad with many of the names Marco mentioned in his acknowledgments present, including himself. It was really rapid application development (RAD) without many of the stuff that parent mentions that brings so much struggle today (frontend) software development. People were having fun building software.
I’m happy to see that most of these names still seem to be able to make a living off Delphi. There’s probably still a lot of critical Windows enterprise software being maintained that needs consulting and support. Including my dad’s software he wrote 30 years ago which is still being maintained and used daily.
At my old company, it took 2 years and $2 million to re-write an application in Java. That's the cheapest project that Accenture would take.
So as long as you keep your legacy service contracts under that, you're fine. It might even be $3 million now with the new Java licensing terms.
For online I don't think Borland, or whoever owned Delhi back then, really had the resources to keep up with everything else. Even today it's pretty expensive to buy the tooling from Embarcadero to keep projects alive, but probably cheaper and less risky that porting to another language.
My day job involves working with PeopleTools, which basically does this. Draw forms (and build all of the supporting objects), save them, and they're accessible through a web browser. You don't need to know HTML, CSS, JS, etc (though it can help), and you can knock out a very based CRUD form in no time without writing any code.
I think the Microsoft Power Platform has features similar to this as well.
But neither of these options are very accessible to regular folks. Something that has the ease of development of Delphi, the deployment simplicity that comes with presenting the application via a web browser, and is accessible to regular folks would be incredible.
This is truly interesting, and the description on that wiki page suggests that it might be exactly what I'm looking for, but it seems like any concrete information about it has vanished.
https://xojo.com/products/web.php
I haven't really used it - I'm just a hobbyist coder who enjoys the VB6 style development of the desktop version of Xojo.
I find myself waffling between "This is too expensive for me to play around with at home" and "Considering what this does, $399 really isn't that bad..."
I'm still tempted...
It failed within a year or two.
However I feel like the current paradigm of declarative ui, with automatic re-render, like React (and what I actually use: Compose Multiplatform) is very good for producing maintainable applications and encourages UI decoupling.
I agree that the dependency hell and project setup parts on the web are horrible, but I wouldn't say it's part of "UI Development".
First time someone used “grandparent” and I could relate :-)
What's wrong with Lazarus, compared to Delphi?
I'd like to know more about this. Any links to the discussions? My google-fu is failing me right now.
So, even though Android and iOS modules could be more thoroughly integrated into Lazarus or they putting forth an integrated LCL based solution, they're not. That's very weird. From the perspective of how much more useful Lazarus can be, and from their users asking for it.
[1] https://github.com/jmpessoa (LAMW)
> Especially on the web side, where even a single view sometimes requires having multiple unrelated dependencies (packers, builders, transpilers, etc.),
... is only true if you jumped on the SPA bandwagon. Things don't have to be this complicated.
These web apps show tables with data, images with figures, and some controls to request calculations or data from a server. jQuery is used to update the drop-down list according to previous choices.
You are not tied to Visual Studio or Windows (as in, you can target Windows and Linux when using macOS, or Windows and macOS when using Linux).
Rust is generally anemic if you need a visual editor. Go and Python are in even worse state (there are no production-ready frameworks for Go to do cross-plat GUI app dev).
The biggest alternative so far is Flutter.
The Free Pascal language used by Lazarus is very similar to Delphi's Object Pascal[1], and the Lazarus Component Library[2] is modeled to closely match Delphi's Visual Component Library.
What's D365?
Microsoft, on the other hand, is severely underrated for its ability to just not fuck up too often.
They drank every last drop of the enterprise kool-aid, and put Delphi on life support when spinnig it off failed[1], just as Microsoft got some .Net momentum going.
A lot of Delphi developers saw the signs and jumped ship during those years.
As in Borland Delphi 5 "Argus" released in August 1999 which introduced XML support and ADO databases?
I like Delphi and FreePascal and Lazarus and have used all of them a little, now and then, to create some small personal and paid business apps, Delphi in multiple versions with gaps between versions, from 2 onwards until the 'Berlin' version, IIRC.
And yes, thanks, Marco, for making this book available. I had bought a copy of one of your Delphi books around the 3 to 5 version timeframe, cannot remember which version right now.
Also, I had downloaded your Object Pascal Handbook a few years ago, which is a great resource, because we devs need to know our programming language well too, not just the IDE or the libraries, which is what some book authors focus on. Thanks for that too.
Need to set aside some time to do some more Pascal work for fun and profit.
The same goes for Eiffel.
Lazarus:
FPC:
Cost: $0.
On the other hand, I'd also be surprised if the code couldn't be ported as-is, with just some minor tweaks if any, to the latest Delphi release (released this month).
The transition to Unicode strings was a breaking change that did have some impact, but if the code used string manipulation routines instead of direct byte manipulation it should work without any change.
I'd be surprised if it didn't. Not Delphi, but I've been helping a client update their Windows program, from a compiler which shipped in 1998. Their program, with that compiler, runs just fine on Windows 11.
The backward compatibility of the Win32 API is such that I regularly use programs last compiled 20 years or more ago.
I suppose if you run it as admin and/or install it outside Program Files it'll make it a lot less troublesome.
So, not unexpected, but I'd still be mildly surprised.
Now that's rattling a thing in my brain. I recall disabling UAC was one of the more consistent ways to get Delphi 6 to even run on Windows 7, and even then it wasn't a guarantee.
Yeah, I had the displeasure around 2009-2011 of trying to get an old IDE version running on then-current versions of Windows, with multiple Vista and 7 computers in the office. It ran fine on Windows XP, but newer OSes were not so lucky.
Perhaps the solution was to purchase a newer Delphi, but that avenue wasn't sought after.
The fall off occurs as you veer off into deeper holes:
- Multimedia software and games tend to hit on areas of Windows where compatibility is far from perfect.
- Even 32-bit software would sometimes have random Win16 binaries, and those are not emulated; I don't blame Microsoft or anything, but they could support it if they wanted to. (Understandably, they do not.)
- Software that uses truly obsolete Windows components may no longer work. AFAIK .NET Framework 1.1 hasn't been supported since Windows 8. Old ActiveX and COM components can also be a problem.
This has led to some situations where you might actually have better luck running the old software under Wine and Linux than modern Windows, especially for some older games.
It's not that Microsoft didn't do immense amounts of work here, but in practice there are some holes I've run into.
InstallShield being a common one in that regard. So common that 64-bit Windows, which doesn't support 16-bit binaries, contains code to handle specifically[1] InstallShield and Acme 16-bit binaries[2].
[1]: https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=27...
[2]: https://learn.microsoft.com/en-us/windows/win32/winprog64/ap...
Here is a screenshot from ~5 years ago when i was playing around writing a Quake 1 level editor in Delphi 2 under Windows 10[0] (i switched to using Linux as my main OS soon after and converted it to Lazarus[1]).
Did a bit of search, is it QuARK?
It is not QuArK, though AFAIK QuArK was made in Delphi too. There have been a few other Quake editors made in Delphi, like the qED Quake Editor which was one of the earlier Quake editors (the author wrote a book about quake mapping too[2]).
[0] http://runtimeterror.com/tech/dglvp/
[1] http://runtimeterror.com/tech/bcbgl/
[2] https://archive.org/details/unofficial-quake-level-design-ha...
I believe the community is still thriving.
It's been a long enough time that the details have left my brain, but the feelings of pain have not been forgotten :-)
Like many of the other commenters here, I use Lazarus for Delphi projects in 2025 (Not just personal projects, but business projects too).
I don't really like the language too much, but:
1. Pascal (or Object Pascal) is very readable compared to almost anything else I've used[1]. I can come back to code from 2 years ago and spend a few minutes to context switch back into the language.
2. The language gotcha's are a small enough pain point that they are outweighed by the advantages of the type creation. I like being able to create a ranged integer type, which is then enforced by the compiler.
3. For most stuff, the majority of my logic is written using opaque types in C and then simply linked into the Lazarus GUI. I originally started using strong isolation and decoupling in C to enforce typing guarantees, but a side-effect of this is that it makes it exceptionally easy for other languages to reuse the program logic.
[1] I've been programming for money since the mid-90s, so you can assume that I've used almost everything that was mainstream (or top 10 in terms of popularity) each year since 1995.