Construction of Windows NT: compatibility mechanisms that work to this day

Windows NT was supposed to be a system capable of imitating each of the three main systems from the late 80s. It ensured the ability to run Windows, OS/2, and Unix applications. Not much remains of these plans today, although Windows 11 offers numerous programming platforms.

The popularity of Windows does not come from it being a fantastic operating system. After all, it is not: Windows 11 has become cumbersome, patched, and impossible to renovate at lower levels. Its ubiquity is due to the maintenance of compatibility and the inertia of hardware manufacturers writing drivers. If it weren't for a detail called "software", Windows would have long been replaced by one of many competitors. But arguments citing Microsoft Office and Photoshop are still valid.

How does Windows ensure compatibility? First and foremost, it gradually parts ways with old libraries. It only lost support for 16-bit applications in 2021. It eliminated Internet Explorer only by removing the most superficial layer: MSHTML, HTA, VBS and BHO are still present in the system. And when introducing new versions of libraries, it keeps the old ones: using the SXS mechanism and compatibility modes, it offers earlier versions of DLL files to older applications. This causes programs to not directly use files from the SYSTEM32 catalog. Each request is initially intercepted by the compatibility mechanism (shim), which selects the appropriate version for the application. This significantly increases complexity and overhead. But it pays off.

This is a significant investment in compatibility. The compatibility mechanism is vast and constantly being developed. One of the stages of telemetry collection in Windows (CompatTelRunner) is updating and reporting the local compatibility database, which contains information about which installed programs requested which libraries. The WinSxS folder contains thousands of directories. And when an API appears in the system, it very rarely leaves. That's why we can find in Windows drawing engines Trident (Internet Explorer) and EdgeHTML, Visual Basic, Outlook MAPI mechanism, WinRT (Metro, known from Windows 8), .NET Framework 2.0, DirectPlay, fax service, and SMB 1.0. These files do not appear in old versions: they are regularly rebuilt. They are an integral part of the system and are the reason why an uncompressed source of Windows installation today takes up 16 gigabytes (approx. 17.6 GB).

Although the C language system library is considered internal only for system needs, its structure maintains high compatibility over the years. Visual Studio insists on compiling to the dedicated MSVCRT, which should then be distributed together with the application (which has been significantly simplified in recent years), but even this proceeds in a trouble-free manner. .NET Framework libraries are also present in Windows, and when some ancient application (pre-2010) requires version 2.0 CLR, Windows Update will download the older one. The new .NET already offers the possibility of bundling the runtime environment in the redistributable form of the application. This probably ensures compatibility with Windows for the coming years.

Something like this is absent among competitors. Android 14 removes compatibility with applications for Androids older than 6.0 (this change more related to security than with ABI, but the effect counts). In macOS, unsigned and 32-bit applications don't work at all, and the most popular programs ensure compatibility with only a few versions back. Linux, on the other hand, doesn't care much about this issue. Everything depends on the number of dependencies. We can successfully run into a twenty-year-old application that will work right away. Or a thirty-year-old one that will only require rebuilding. There will be applications in which there will be no chance of running, for example, sound. But we can also encounter problems with just a few-year-old program, due to changes in GTK or libraries not built for the newer version.

The creators of NT dreamed that this system would be able to "pretend" to be Unix and Windows equally - with the help of a "personality" subsystem and implementing reference "userland" POSIX and Win32, NT was supposed to ensure "eternal" compatibility. Updates were meant to add a new personality. This compatibility has long been removed. Today's WSL is not it, for example. Win32 undoubtedly prevailed. But in itself, the Windows programming environment is not a technical miracle.

In the IT market, they are mainly driven by business decisions, in the form of a huge number of compliance mechanisms. Theoretically, they could be embedded in any system - but that's just theory. There is no sign of moving Windows API to any other system. As long as the NT foundations do not collapse under the weight of additions, thirty years of compatibility will continue to make money in Redmond.