Windows Development: A Delphi Developers Perspective

As a software developer with over 30 years in the industry, 25 of those years invested in Microsoft Windows, the choice of development tools have been paramount. For us developers, the right tools can literally make or break your career; so this is a topic of some importance.

“Millions of developers over 25 years can’t be wrong.
If Delphi didn’t positively rock as a development platform,
none of us would be here today”

Trying to take stock of the languages and frameworks I have used, spanning decades no less, is out of scope for this post. It’s safe to say that I have at least used 10 different development tools; from native Basic compilers meant for embedded, to C, Java, Pearl, and C# under various regimes. On top of my head I can name six Pascal compilers (my favorite language): TMT, HiSoft, Turbo Pascal, Freepascal, Oxygene Pascal, and Delphi.

Back in 2010 I even created my own development platform together with members of the Delphi community. So, programming languages and compilers, as a topic, is something I have spent a considerable amount of time researching.

But as exotic as the alternatives might have been, productive even, when it comes down to brass tacks of delivering reliable software on time and on budget, nothing beats Delphi.

Above: One of the benefits of tight integration with WinAPI, are ultra fast, lightweight visual controls

You might write that off as spin or marketing, but if you have followed my blog or frequented one of my user-groups on Facebook – my dedication to Delphi is hopefully unquestionable. I have worked with many programming languages and technologies over the years, but Delphi has always remained a constant in my life as a developer.

In this article I want to outline why Delphi is awesome for Windows development. What is Windows development from a Delphi developer’s point of view? Just what does it involve and what should be your criteria?

Finding your way

I have to admit, I don’t necessarily envy young men and women that are diving into native software development today. As a child of the 70s and 80s I have had the luxury of living an inch ahead of the curve. No matter what standard or technique became the norm, I was right there when it happened. The newest thing was always the next logical step from what you were already doing, so I didn’t have to catch up or immerse myself in past technologies to find my footing.

“[Delphi] does this through linear and successive inheritance
that is elegant and easy to understand”

Young developers that want to write high performance, native applications in 2020 are faced with a bewildering, perhaps even intimidating amount of standards and frameworks. I can imagine that telling the difference between WinAPI, UWP, and WinRT won’t be easy. And that’s before we take on ActiveX, COM, COM+, DirectX, GDI, GDI+ (to name a few). Technologies that have all had their names changed more than once in the past.

Now I’m not going to exhaust the subject, but consider the following: what we know as ActiveX today was first called COM (there was no clear distinction between visible and non-visible objects at first), and before that the exact same system was marketed as Microsoft OLE (Note: technically ActiveX is COM, since COM is a component object model and implementation standard).

I’m sure you get my point. If you were there when OLE was the bomb, the transition to COM and further distinction of ActiveX for visual objects was natural.

Thankfully, we have development systems that greatly simplify all of this. And this is where Delphi stands out as the number one option.

Why chose native programming?

This confusion that I mention above is something everyone has to go through. One of the wonderful aspects of programming, is that you are never done learning; nobody can say “now I have nothing more to learn” in our line of work. There will always be new technologies, new ideas, new ways of solving problems – and most likely new languages to go with them.

But native software development rests on a foundation that hasn’t really changed since the first home computer came out. And this is one of the most important things I try to teach, because once you understand why, you will be able to make better choices. You will also spot the difference between a solid foundation and temporary popularity (when it comes to languages and techniques).

Above: Delphi and C++Builder is ideal for native software development on a number of platforms, but nothing beats Delphi on Windows.

A computer is 100% at the mercy of physics. It is an electrically driven, logically bound machine. And the laws of physics bubble up into how processors and memory operates, which in turn affect how instructions (machine code) is expressed. This might sound very complex, but all you have to take away from this subject, is that things are the way they are for a reason.

Languages come and go, but languages that adhere to the underlying laws of computing (native programming languages) will never go away. They exist because those languages are responsible for everything else.

In other words, learning Object Pascal or C/C++ will give you an advantage, because the knowledge and skill you accumulate with these languages is universal, timeless and translate directly to every other aspect of software development.

Windows: the layers of technology

So what exactly should the criteria be for a Windows developer? Windows is a large system that covers hundreds, if not thousands, of technologies. What are the objects and entities that you need to master in order to write great Windows software?

In short, they are as follows:

• Desktop applications
• System services
• System libraries
• COM and Active X modules

Microsoft Windows has several layers that each expose different functionality, so let’s jump straight in and look at these briefly one by one.

Kernel level drivers

At the very bottom of the Windows ecosystem you have mission critical technology like kernel level drivers. Personally, I feel C++Builder is better suited to deal with that type of coding.
Not because Object Pascal cannot be used, but because most drivers are written in C/C++, so the amount of source material available will mostly be in the form of C source-code.

Delphi was designed for predominantly system software, and Kernel level drivers don’t fall under that category by any stretch of the imagination. I mention it here purely for context since it represents the fundamental level of the Windows architecture.

So while I have had projects that demanded such drivers, for example custom file systems that integrate directly with the kernel – such tasks are rare exceptions. In my case we wrote the driver with C++Builder and used it from Delphi.

Shared libraries

The next layer is where Delphi comes into play, namely that of libraries (dll files). As an archetypal native development system, Delphi produces fast and reliable code; making it optimal for building shared libraries (dll files). Delphi also has its own object model (a part of the VCL, the Delphi runtime library), which means that you can take full advantage of the thousands of non-visual components available. So while libraries are ultimately low-level entities, there is nothing in the way of using components inside them to deliver complex and elaborate functionality for your application.

Libraries are typically used to isolate common behavior, or unique behavior, that your applications can use. Separating work in libraries helps save time, and if used with discipline it helps you write software that is easier to maintain.

Service stack

Immediately above the library level, is the service layer (often called “a stack” since services depend on each other in a vertical fashion). A Windows service application is a special program that has no visual output. There are no forms, buttons or user interface elements involved. This type of program is meant to run silently in the background, and usually supply special functionality to desktop applications or other services.

Delphi is without a doubt one of the best solutions for service authoring. Since Delphi’s run-time library integrates so closely with Windows, yet provides a flexible and mature component model – there really is no limit to the service types you can write.

Need a web server? Drop a server component on the project data module and voila, you have created your own web server. Need database connectivity? Same thing. Drop the components on the data module for the service project, and now your service can connect to a database.

There are even databases written from scratch in nothing but Delphi, which means your service will have no dependencies on external libraries or drivers. This is extremely powerful in a large network centric environment where an error elsewhere can have catastrophic consequences. The less dependencies your software has, the fewer factors can affect its operation.

Desktop environment

On top of all these layers of technology comes the actual user experience, namely the desktop environment. And this is where Delphi really is second to none.
Delphi makes it so easy to create fast, modern and good looking desktop applications. Sure, there are other systems out there – but Delphi’s RAD (rapid application development) formula, the way it interfaces directly with WinAPI (the central Windows API) is so refined and polished after decades in production, that I have yet to find anything that can match it.

To understand why, let’s have a look at the framework that helped make Delphi a household name, namely the VCL.

The VCL

One of the things I love about Delphi is that it operates with it’s own, separate component model, commonly referred to as the VCL (the visual component library). The VCL is a brilliantly engineered, easy to use and powerful object oriented framework; one that stretches from assembly language and all the way to the visual components you can drag & drop on a form. And it’s this depth that ultimately makes it so powerful. Other languages might have some of the component features – but the underlying mechanics and code that makes it all happen, is typically shielded or hidden.

Above: One of the benefits of the VCL is theme support. Just like FireMonkey, Delphi’s platform-independent framework, the VCL allows you to give your Windows applications a distinct look without loss of behavior or integration.

So while you are learning Delphi and exploring it’s options, you can start where you are, and then gradually refine your skills as your understanding grows.
The VCL is wonderful because it wraps the entire scope of Windows, from libraries to services and services to desktop – all of it from a single framework. And it does this through linear and successive inheritance that is elegant and easy to understand. It literally builds up more and more complex behavior and functionality for each descendant.

The VCL starts with the most basic and essential nonvisual classes and components, and then works its way into the visible spectrum; culminating in TCustomControl which is the ancestor that most visual elements derive from.

The difference (or advantage) between manually calling WinAPI for everything or using the VCL, is that the VCL takes care of everything for you. Or should I say, as much as you would like it to handle. From dealing with fonts, color encoding, scaling options, device independent graphics, composition and layout -all that nitty gritty that is so incredibly time consuming. But the most awesome feature is that the VCL doesn’t force you. If you need to alter a behavior, you can override the functionality and write your own adaptation. The VCL ships in source-form as a part of Delphi, so you can quickly locate the method you need to change. Having the source-code available is also great for learning since you dont have to constantly search through the documentation. The VCL makes native Windows programming sane. Plain and simple.

The VCL methodology, or recipe if you will, has been in active use for 25 years.

And during its long life it has been (and continues to be) refined, improved upon and adjusted; evolving side by side with Windows. The amount of products the VCL is directly responsible for, is in the millions. Some of the biggest and most successful applications around are made with Delphi. They might not advertise that fact, but you would be surprised just how instrumental Delphi and C++Builder have been for the Windows platform (!).

Whenever Microsoft adds new and interesting features to WinAPI, Embarcadero absorbs these into the VCL and makes them easy to use (wrapping them into a class or an easy to use function, or adopting the functionality into one of the many components Delphi ships with). RAD (rapid application development) is a unique methodology that millions of developers rely on, one that has stood the test of time.

I can’t think of a single Windows oriented framework, one that was written especially for the Windows ecosystem that has endured for so many years – yet it’s just as effective today as it was 25 years ago. And the reason is that it’s not as affected by changes as other languages and frameworks are – because it talks directly with Windows. It’s the same principle I mentioned at the beginning of this post, namely that beneath the visual surface, computing remains much the same as it was 20 years ago.

It is a remarkable achievement in it’s own right.

Talking to the world

I have never been a fan of limiting my options. There are many developers who swear to just one language, one platform and so fourth; but I believe all developers should keep a well stocked toolbox. In some business sectors scripting will play a large role, in other sectors bytecodes might be more important. What I feel is important is to pick a language that can play well with its neighbours, interface with the underlying infrastructure – and provide clear benefits for all.

Windows is an awesome platform. But it’s important to understand that Windows is not just visual desktop applications. Beneath the visual surface is where most of the activity takes place, in the service layer – or further down, on library level.

Being able to talk directly with these layers is of utmost importance, and the less boilerplate code that stands between your application and the underlying APIs the better. I feel that Delphi both as a language and development system checks the most boxes on my list. I have yet to find a technology Delphi can’t talk to or work with.

Delphi also enjoys a rich and highly productive third-party component community, which delivers some impressive expansion packages. You can interface with COM and Active X libraries without problems (and also write such libraries). Integrating with Active Directory is likewise easy and straightforward, as is working with medical standards like FHIR. The FHIR standard was actually invented in Delphi by well known Delphi enthusiast Graham Grieve

If you use a package like CrossTalk (produced by AToZed Software) you can even load and work directly with .Net assemblies. So you get to enjoy the speed and performance of native code, without any loss of integration with other technologies.

Reflections

Delphi is a product that has great depth. I could probably have drawn in various technologies, techniques and freely available packages and add-ons, but Delphi ultimately stands on it’s own merit. Like C/C++, Object Pascal is an archetypal language, which means it was designed to interact with the computer – as a computer works (i.e you work with memory and pointers and addresses exactly like you do under C). The number of archetypal languages is slim, but they represent a fundamental aspect of computing that is responsible for everything else. Delphi as a product delivers that scope and depth, but in a way that allows you to start where you are. You are not shielded from the underlying layers, but can approach these at your own pace.

There is so much I want to share about Delphi and Windows development in general, and I will no doubt keep returning to this subject again and again, because there is an almost inexhaustible source of material to choose from.

Millions of developers over 25 years can’t be wrong. If Delphi didn’t positively rock as a development platform, none of us would be here today.