There’s been a small flurry of articles from a variety of sources, all talking about more or less the same thing: Microsoft is trying to explain why Windows 11 is as difficult to develop as it is, in turn justifying why it’s become such a mess over the years. I’m picking this one from Windows Central, which is an interview with Microsoft’s CVP of Design and Research for Windows and Devices, Marcus Ash. Taking the long, still ongoing transition from the Control Panel to the Settings application as an example, Ash explains why this is such a long and difficult process.
Unsurprisingly, Ash says that the reason this has taken so long is that Microsoft prides itself on compatibility with legacy tooling and workflows, so it can’t just rush in and modernize everything without first ensuring the modern replacements maintain functionality with what came before.
↫ Zac Bowden at Windows Central
This isn’t really news to anyone. One of Windows’ prized strong points is its often excellent backwards compatibility. This doesn’t just apply to individual applications, but also to things like software makers adding settings panels to Control Panel, or complex business applications expecting certain entry points into the Control Panel to exist – and much, much more, all over the operating system. I’m exaggerating, but you can’t so much as move a single pixel in the taskbar without breaking some component of some obscure corporate middleware suite from 1999 that somehow still functions as the beating heart of like 187 Fortune 500 companies.
Sometimes I wonder if Microsoft is going about this the wrong way entirely. Of course, I have no idea what I’m talking about, but I feel like Microsoft has so man tools at its disposal to deal with this issue that it’s not really using to their fullest potential. Specifically, Windows itself has a number of incredibly capable tools in its toolbox to make sure any application ever written for Windows and even DOS, regardless of how many bits it requires, can run. Windows has advanced and highly capable tools for virtualisation and containerisation, and on top of that, Windows NT has a very capable personalities system that feels underutilised, too.
Couldn’t these tools be harnessed to effectively isolate the entire backwards compatibility problem from the actual Windows operating system people use, and turn them into optional components installed and activated when required by an older application? Isolating backwards compatibility this way would then leave the Windows team much less shackled and more free to improve Windows at every level without having to worry so much about maintaining backwards compatibility. If the components an older application needs are virtualised, containerised, or part of a Windows NT personality and thus frozen in time, the Windows team would be free to work on the “current” version of said component without breaking the application in question.
I feel like Microsoft has tried to use these technologies to address backwards compatibility in the past, but in true Microsoft fashion, it always seems to do so halfheartedly, without any real coherent vision behind it. Again, I wish to reiterate I’m by no means qualified enough to make any definitive statements about this, but it sure does feel like Microsoft is underutilising a lot of the tools it already has at its disposal.
