From the June 2015 Issue of Prestwood eMag
Delphi for Win32:
The Case for Delphi (On the Desktop)
Posted 6/10/2014 on 6/10/2014
Take Away:

In 1995 Borland revolutionized the world of software development when they introduced Delphi.

It had the distinction of being the first integrated development environment (IDE) featuring a fully object-oriented language and a blazing-fast compiler that produced highly optimized, native Intel machine code. Programs written in Delphi were among the fastest in existence – and still are.

After all these years, is Delphi still relevant?

You bet it is! (And, in many cases, it is still your best bet.)

Here's why...


After all these years, is Delphi still relevant?

You bet it is! (And, in many cases, it is still your best bet.)

Here's why...

For the Windows Desktop, Delphi is the superior tool for application development. It absolutely excels in all these areas:

  • ·         Performance,
  • ·         Productivity,
  • ·         Security,
  • ·         Cost of Deployment,
  • ·         And More.

First, a little history

Using Delphi’s highly visual work surface, developers could build forms visually by dragging components (building blocks, if you will) from a well-organized tool palette and dropping them on the form – right where they wanted each component to be.

As the developer designed his application’s forms, under the covers, Delphi was already “writing” much of the code needed to make things work.

For each component on a form, Delphi exposed a list of “events,” things that could happen to each component, including end user interaction. With a simple double-click, Delphi would take the developer into a pre-written code block in which the developer could write code in response to the event.

And the developer needed to pay attention to only the events that interested him.

Developer productivity shot through the roof!

From that moment on, every serious development tool on the market had to strive to match Delphi’s mind-blowing IDE (integrated develop environment). Few succeeded – and it took them several years to do it.

Another first was the manner in which Borland architected Delphi to play nice with most of the important databases of the time. This theme has persisted through every subsequent version of Delphi and now, Delphi can work with virtually any database under the sun.

Another architectural coup for Borland was making it easy for third parties to create new components and code libraries and those people came rushing to the game. Never before had any development system been so enthusiastically supported by legions of eager developers.

Another feature, great for developers that needed to get “down to the metal,” or squeeze the last drop of performance from their applications, Delphi was happy to let them write critical parts of their applications in assembly language – the language of the machine itself.

Through, oh, about version 7, Delphi was king of the Windows desktop.

There came an “iffy” period in which two unfortunate things happened:

In 1996.Microsoft hired Delphi’s inventor and chief scientist, Anders Heilsberg, away from Borland. It’s not as if he was the only man that could write great compilers but, nevertheless, many Delphi users became nervous that the departure of Heilsberg would mean the death of Delphi.

That demise never happened

Then Borland started fiddling with their branding, which is often the beginning of the end for successful businesses. For reasons I’ll probably never understand, Borland’ chose to reinvent itself as Inprise and promote its ALM tools more than Delphi

A little farther down the road, Borland/Inprise decided to create a new division/brand called CcodeGear and place Delphi under its mantle.  It’s no wonder that a lot of people got nervous about Delphi’s future. Delphi finally found a healthy new home under the ownership of Embarcadero, where it now thrives.

Mind you that, during all this time, Delphi was steadily improved.

Then Microsoft introduced their .NET (dot net) initiative.  Many seasoned Delphi developers, upon first seeing and using MS Visual Studio .NET, recognized its strong resemblance to Delphi. Which should have come as no surprise because of Heilsberg’s influence at Microsoft.

To further ensure its success, Microsoft gave .NET a huge boost by providing “Express” versions of Visual Studio .NET for free.

Many developers were pulled into the .NET fold. Actually, it’s more probable that management forced developers to use .NET because they believed all the hype about .NET, but turned a blind eye to its shortcoming.

Back in the days when mainframes ruled, there was a saying, “Nobody ever got fired for buying IBM.” In the PC world that’s morphed into “Nobody ever got fired for buying Microsoft.” You can be sure that that’s the mindset of many an MBA or product manager – especially those lacking technical expertise.

Nevertheless, you can rest assured that Delphi is still alive and well, and more relevant to today’s development of desktop and mobile platforms than ever before.

Over the years, Delphi has acquired a number of different data-access models, and its quest for database supremacy has never stopped.

With last most recent few releases of Delphi, Embarcadero introduced a new data-access package called FireDAC.  FireDAC is a product made by DevArt, arguably the world’s best maker of database access technologies and tools. Coupled with Delphi, it completely bypasses the usual requirement to provide an ODBC link to the database, whether it’s MS SQL Server, MySQL, PostgreSQL, DB2, Interbase and others.

I’ve only used FireDAC with MS SQL Server databases and I must say that I’m mightily impressed.

In fairness to Microsoft, I must say than when .NET is used for web development, it is stellar. That’s its ASP .NET personality on the Web.

On the desktop, however, .NET has some severe drawbacks where Delphi does not.


This is an almost age-old story. Back in the days of C/PM (just prior to DOS), there was an oft-used dialect of Pascal that did things a lot like MS Visual Studio classic (VB 6 and earlier) and .NET. When you compiled your program, this old Pascal didn’t really compile it. Instead it produced so-called “P-Code,” an intermediate form of your program.  To run the program, you had to install a “run time” on the target machine and it would do the last part of the job; compiling the P-Code to machine code – the only code that your microprocessor understands.

Meanwhile, there were compilers for the C language that did produce native machine code. And guess which was faster, the Pascal program or the C program? The C program won that race, hands down, because it was already machine code.

It’s important to stop here and make this one truth crystal clear: No matter what language is used to write a program, your machine’s microprocessor can only execute (run) instructions that are provided in its native machine language.  If the programming language didn’t compile the program to machine code, then something else must.  We generally refer to those somethings else as “interpreters.”

Similar to the old Pascal, to deploy a program written in VB 6 (and earlier), the developer had to deploy, not only the intermediate code incarnation of his program, but also the VB Runtime – a maze of DLL files that finally interpreted the intermediate code into machine code.

Decades later, .NET brings us back to something very like that old Pascal and VB systems. When used for desktop development, a .NET program is semi-compiled into an intermediate form (IL). The target machine must have the appropriate version of the .NET framework installed to run your program because it’s the framework that provides that last part – the part that takes the IL file and finally compiles it to machine code.

Delphi has never suffered the kind of overhead imposed by VB classic, or by .NET. It does, and always has, produced highly-optimized, native, Intel machine code. Only one file needs to be deployed, the EXE file produced by Delphi’s compiler.

More files than just that might be deployed as well, like help files, but the program itself is very much a stand-alone entity.


Call this one man’s opinion because I haven’t done a scientific comparison. But many of my colleagues agree with me. It is easier, and faster to write a Delphi program, and it’s easier to debug it, too, than to write and debug the same program in .NET.  In my own programming, I find that one component in Delphi, which .NET doesn’t have, makes a large difference in programming effort. That is Delphi’s TActionList. I won’t go into all the techie details of why that component makes programming easier; it just does.


This is something I just don’t get. It used to matter – a lot.

Bright people have always written “de-compilers,” so they can explore the innards of a program.  As a community, we developers used to be very concerned about that and, even though a Delphi exe is pretty inscrutable, we used to pay good money to third parties for add-ons that would frustrate the hackers that might want to decompile and explore our Delphi programs.

The same was true of developers that coded in C, C++, Visual Basic, and just about every other significant language.

With the advent of .NET, all of a sudden that concern for securing our intellectual property has virtually disappeared.  Yes, there are programs for .NET that “obfuscates” the IL code, yet, the world of .NET is full of “de-obfuscators” that can read .NET IL code and render it as human-readable source.  Not pretty source, perhaps, but source code just the same. That depends on the de-obfuscator.

Worse, most of the de-obfuscators are free!

Low Cost Deployment

When it comes time to deliver your finished product to your client, or to the market, some work is involved in creating the “setup.exe,” or “setup.msi.”

As I mentioned earlier, the deployable for a Delphi program is a single file, the .EXE itself. If the project includes an integrated help system, you have to include the help file in your deployment. So the deployable for a full-blown Delphi application involves only one or maybe two files. There can be more, but if there are, they are part of the developer’s vision of what the project needs.

What a Delphi setup does not need is an internet connection!

With a .NET program, there could also be a single “.EXE” file or two files if help is involved, but that EXE is not a stand-alone entity.  It was written for a particular version of the .NET framework, and that framework must be installed on the target machine(s).

Microsoft has done a pretty good job of keeping Windows machines updated with the latest .NET framework, but you can’t count on it.  So your installer had better check for it and, if absent, make provision for installing it before the actual program is installed.

Again, Microsoft has taken most of the pain of that out of the equation, if you use Microsoft’s tools for creating the Setup.exe/msi.

For that part of the setup to work, though, the client machine will need a network connection so the appropriate framework can be “pulled own” from Microsoft’s web site.

That can be avoided, too, if the developer includes the entire framework in his setup.exe, but that is extra work and will seriously bloat the setup file.

And More

I love my iPad and iPhone. Others love their Android or Windows 8-bases tablet or phones. Tablets and “smart” phones are all the rage today and I don’t expect that trend to slow down any time soon.

Once again, Delphi is the winner.

With the current version of Delphi, XE5, Delphi provides a way to use a single code base to generate programs for:

·         Windows Desktop

·         Mac Desktop

·         Windows Tablet devices

·         Windows Phones

·         iPads and

·         iPhones

·         Android Devices

Yes, the latest version of MS Visual Studio promises to do some of these things, but only by buying a ~$1,000 add-on. And that add-on can’t be installed in Visual Studio Express (the free version)

With all of these things going for Delphi, I cannot fathom why any programmer would start a new Windows desktop project with anything but Delphi.

Well, there may be one reason: Management decree.

Article Contributed By Wes Peterson:

Wes Peterson is a Senior Programmer Analyst with Prestwood IT Solutions where he develops custom Windows software and custom websites using .Net and Delphi. When Wes is not coding for clients, he participates in this online community. Prior to his 10-year love-affair with Delphi, he worked with several other tools and databases. Currently he specializes in VS.Net using C# and VB.Net. To Wes, the .NET revolution is as exciting as the birth of Delphi.

Visit Profile For service: 916-726-5675
Copyright (C) Prestwood IT Solutions.
All Rights Reserved.
Printed 8/16/2022