Why Windows must die. For the third time Microsoft knows Windows is obsolete. Here’s a sneak peek at its replacement.
Article from Zd Net
In order for the Windows brand and Microsoft’s software business to live, Windows — as it exists today — must die.
The first of Windows’ lives occurred in the period between 1985 and 1995. During this time, Windows was a bolt-on application execution environment that ran on top of the 16-bit DOS operating system, which was introduced with the original IBM PC in 1981.
That OS “died” in 1995, when Windows 95 — the first 32-bit version of the OS — was released.
From 1989 to 2001, on a separate track, Microsoft also developed Windows NT, a 32-bit, hardware-abstracted, full pre-emptive, protective memory, multi-threaded multitasking OS designed for high-performance RISC and x86 workstations and servers.
The commonality that the consumer version of Windows and Windows NT had was that they shared many of the same APIs, which are collectively known as Win32.
Largely implemented using the C programming language, Win32 became the predominant Windows application programming model for many years. The majority of legacy Windows applications that exist in the wild today still use Win32 in some form. (This is an important takeaway that we will return to shortly.)
In 2001, Windows NT (at that time branded as Windows 2000) and the consumer version of Windows (Windows ME) merged into a single product: Windows XP.
Thus, the second generation of Windows technology descended from Windows 95 “died” at this time.
Shortly after the release of Windows XP, in 2002, Microsoft introduced the .NET Framework, which is an object-oriented development framework that includes the C# programming language.
The .NET Framework was intended to replace the legacy Win32. It has continued to evolve and has been slowly adopted by third-party ISVs and development shops. Over the years, Microsoft has adopted it internally for the development of Office 365, Skype, and other applications.
That was 16 years ago. However, Win32 still is the predominant legacy programming API. More apps out in the wild use it than anything else. And that subsystem remains the most significant vector for malware and security threats because it hosts desktop-based browsers, such as Internet Explorer and Chrome.
A lot has changed in the technology industry in 16 years, especially the internet. Web standards have changed, as have the complexity and sophistication of security threats. More and more applications are now web-based or are hosted as SaaS using web APIs.
Microsoft introduced a new programmatic model with the introduction of the Windows 8 OS. That framework, which is now commonly known as Universal Windows Platform (UWP), is a fully modernized programming environment that takes advantage of all the new security advancements introduced since Windows 8 and that are in the current Windows 10.
While Windows 8 was not well-received in the marketplace because of its unfamiliar full-screen “Metro” UX, the actual programmatic model that it introduced, which was greatly improved for desktop-style windowing in Windows 10, is technically sound and much more secure than Win32 due to its ability to sandbox apps.
Microsoft Edge, the completely re-designed browser that was introduced in Windows 10, is a native UWP application with none of the security drawbacks of Internet Explorer. Other native UWP applications include Windows Mail, Skype for Windows 10, and some of the applications in the Windows Store.
It could be said that the third Windows death, the end of the Win32 API, is long overdue. It has existed in some form or another since at least the late 1980s. But what has been keeping it alive?
Some of it is developer laziness. It’s not like they haven’t had 15 years to learn and adopt .NET and the past five years to adopt Metro/Modern/UWP.
To be fair, many of them have incorporated certain aspects of .NET into their apps as they kicked the can with their legacy codebase down the road, such as with the use of Windows Presentation Foundation (WPF) in .NET 3.0. But in a lot of cases, fully migrating code bases to UWP from Win32 would mean complete re-implementation.
That takes time and money.