Native Windows is Back to Center Stage
With the downplay of UWP, native development is again the primary Windows development model, after 20 years (given we had .NET in between). Native is what Delphi does at its best, so this is great news for us. Over the last couple of weeks there have been several announcements from Microsoft that partially reverse past directions in terms of Windows development. In short, Microsoft is downplaying (if not fully deprecating) the Universal Windows Platform model. Here are some relevant links: UWP has been the application development focus for Microsoft since Windows 8 was released, and it was replacing a focus on .NET architecture as the Windows development platform. Now this is a very interesting evolution from the perspective of developers (and development tools vendors like Embarcadero) who have remained focused on the classic native Windows development model, as we are first class citizens again after a very long time. From Native to .NET and UWP For many years, the native development model based on involving the classic Windows API and leveraging the three core Kernel/User/GDI libraries and all of their extensions has been considered an old-style, deprecated approach that would soon be abandoned. This is the classic model used by Delphi and C++Builder (with the VCL library), but also by Visual C++ (with the MFC library). Windows developers were first encouraged to move to .NET (with the idea that the future platform APIs would require .NET and classic applications at some point would stop running on Windows). Over time, it became clear this wasn’t going to be the case. As the .NET-centric focus slowed down, Microsoft started pushing the next idea: the Universal Windows Platform. This was primarily driven by two ideas: one, the ability to run the same application on a desktop PC, but also a Windows phone, a gaming console and a visor technology; two, a more secure platform with limited access to the underlying operating system. At the API level, supporting UWP implied using the WinRT platform APIs, which were different and incompatible with the classic APIs. UWP was slow to catch up. For Delphi and RAD Studio there wasn’t an option, but also migration from Visual C++ and .NET and C# would imply using different runtime libraries and different UI controls — accounting for a large rewrite of an existing application. When Windows 8 first shipped (still allowing classic API applications) there were very few UWP apps available, including from Microsoft. However, some of the new platform features were only available via the WinRT APIs, which is why developers and tools (RAD Studio included) came up with options to call WinRT APIs from within a classic application. RAD Studio Windows notifications support, for example, is implemented with this approach. While Microsoft kept pushing for UWP, indicating classic apps were going to be deprecated, developers didn’t really listen. The next step was promoting the so-called “Desktop Bridge”, that is, the ability for native applications to leverage more of the WinRT APIs and to be “packaged” in a light container for extra security. This last feature was achieved by packaging an application as an APPX and later MSIX. Again, RAD Studio has long offered this support directly in the IDE. Microsoft initially described the bridge as a way to help migrate applications to UWP, which was still the […]
