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.
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...ows-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...d-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.
Weiterlesen...