- 06, Mar 2020
- #1
Windows Development: A Delphi Developers Perspective
"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"
does this through linear and successive inheritance
that is elegant and easy to understand"[/I]
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.
[B]Why chose native programming?[/B]
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).
[IMG alt="Delphi and C++Builder is optimal for a number of platforms"]https://community.idera.com/resized-image/__size/640x480/__key/communityserver-blogs-components-weblogfiles/00-00-00-03-37/4150.Delphi_5F00_multidevice.png
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.
[B]Shared libraries[/B]
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.
[B]Service stack[/B]
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.
[B]Desktop environment[/B]
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.
[/SHOWTOGROUPS]
![[Боровикова Лада] Питание по системе Пяти Элементов. Сезонное питание и лечебное питание](/assets/images/icons/forum0.png){kind=icon}
![[3dsmarket] Сборник PRO 3d моделей кроватей (2019)](/assets/images/icons/forum7.png){kind=icon}
