Despite all the push for web and mobile development, which are certainly growing a lot, Windows desktop development is far from death. In fact, at the recent Build 2018 conference Microsoft reported that over the last year the developers using Visual Studio for building desktop applications has doubled. On our side, we know the the majority of the RAD Studio customers are still maintaining a lot of Windows applications and building many new ones.
Table of Contents
Windows Desktop: A Moving API Target
Over the years, Microsoft has been shifting the Windows platform. The original C-language API (often indicated as Win32, even if a Win64 counterpart exists), was augmented many years back with COM interfaces (mostly around desktop and shell integration). This never fully took off. At one point, it seems the “object-oriented Windows core” was going to be based around .NET, but that never happened either, as the core Windows OS remains written in C/C++ and fully native.
Starting with Windows 8, and more fully in Windows 10, Microsoft has added a new core to Windows, known as WinRT. This is a complete overhaul of the system API, with an OOP layer (almost binary compatible with COM), covering applications management, the file system, integrated devices, desktop integration, a complete new set of platforms controls (the first one after the original Windows 1 user.dll controls like edits and buttons). While this is a big leap forward, adoption has been tepid, as regardless of your current language and development tools you’d have to do an almost complete rewrite — and the resulting applications won’t run on the still popular Windows 7.
Seeing the limited adoption of WinRT, Microsoft has decided to improve the compatibility of the old and new world, introducing the Desktop Bridge (aka Centennial) and at the last Build conference highlighting a plan of full integration, with the ability for Win32 applications to host WinRT UI controls. This technology is called UWP XAML Islands and will become available in future versions of Windows.
The Confusing Microsoft Stack for Desktop UI
Along the same period of time, Microsoft has introduced several different UI libraries. With .NET they first introduced WinForms (which offers a layer on top of the Win32 API, similarly to the VCL). After that, they started pushing .NET developers towards XAML markup in WPF (Windows Presentation Framework) and its light, web-oriented twin, Silverlight. These are .NET libraries in which controls are painted on screen using optimized graphic libraries, in a fashion similar to what FireMonkey does.
As mentioned, more recently Microsoft has been pushing the WinRT UI, which differently from WinForms and WPF is not a .NET library, but a core platform library written in C++ library. You can program for WinRT with C# and .NET, but also in JavaScript, directly in C++ and in Delphi, as we’ll see. However, again, this new platform requires an almost complete rewrite of your applications.
When I ask the many friends I have on the Microsoft side, the question: which UI framework to target is the one with the most diverse answers, and many “don’t know for sure”. This is a summary from Tim Anderson, a very good observer of the Microsoft development stack: https://www.itwriting.com/blog/10182-which-net-framework-for-windows-uwp-wpf-or-windows-forms.html.
After the Build conference, Tim was very happy to see a new focus on desktop and wrote:
“With Windows 10 and changes like these Microsoft is acknowledging that Win32 is still hugely important to developers, the industry, and to their platform. They are making Win32 a first class citizen on Windows again. Basically we held the course of what developers wanted, and now Microsoft is finally acknowledging that and circling back around. This does represent a good sized R&D investment to take full advantage of these new APIs and controls. In the short term developers can use the APIs and controls manually, but ideally we should update our shipping controls to “light up” automatically with these new features on Windows 10.”
You can find the full text, a very interesting read for anyone doing Windows development, at https://www.itwriting.com/blog/10687-what-is-happening-with-desktop-development-on-windows-and-will-wpf-be-upgraded-at-last.html
And Where is the Delphi and the VCL in All This?
Now comes the interesting part, at least for me. Delphi started in the native camp, was lured into the temptation of shifting to .NET, and got back squarely into the native world — which is now becoming fashionable again (see the push towards C++, even on desktop). In terms of UI libraries, the VCL has always been considered the best wrapper on top of the native Windows API. Compared to MFC and WinForms, there was never really a context. Moreover, Delphi and VCL offer a much better encapsulation of the COM layer on Windows, both for consuming objects and publishing them. And recently Delphi started offering a great and smooth encapsulation of the WinRT APIs, directly mapped to interfaces and other core language features.
Among all of the libraries mentioned (with the exception of the very limited MFC) only the VCL offers long term support for your code investments. An application build 15 or 20 years ago can still be maintained and updated for Windows 10, while someone following Microsoft trends would have rewritten it 3 or 4 times with WinForms, WPF, Silverlight, and WinRT.
Compatibility with old code is nice, but that’s true also for legacy libraries and tools. But that’s not the case for VCL. The library has a styling architecture to modernize the UI, it offers new UI controls mimicking the WinRT look and feel (written in pure VCL, so you can use them also on Windows 7), and it offers WinRT API encapsulation and ready to use components for Windows 10 only features like notifications and sharing. This means that with a limited effort you can make sure your application looks modern and behaves properly on Windows 10. While there are still gaps, Embarcadero has been also investing in layout management, HighDPi support, multi-monitor support, and many other features that are becoming increasingly important on today’s desktop Windows computers. We can certainly do more (and have new features and more quality in the works right now), but we are ahead most other solutions.
Finally, Delphi (and C++Builder) VCL applications support APPX format deployment via Desktop Bridge, so you can publish them on the Windows Store (the RAD Studio IDE integrated support for Desktop Bridge is still much easier to sue than the Visual Studio counterpart).
Is VCL Today the Best Windows Desktop Library?
I really think it is, but I fully understand your mileage might be different. Native optimized applications, very fast to load, with multi-core CPUs support, integration with all Windows APIs, not to mention the large number of great third party VCL UI controls. There are a lot of reasons start new desktop applications development in VCL today, maybe even more than in the past given Microsoft renewed focus on native desktop applications.
