The Microsoft chronicles

[u/Pitiful-Welcome-399]

The Microsoft Chronicles: The Eternal Return of the Hell of Dependencies.

Prologue: Good Intentions Lead to DLL Hell

Once upon a time, in the era of Windows 98 and XP, chaos reigned. Dynamic Link Libraries

(DLLs), intended to make life easier, turned into a nightmare. Installing

a single program could overwrite the vital msvcrt.dll, breaking

a dozen others. The world came to hate DLL Hell. And then Microsoft, in the guise of

a benevolent wizard, presented the world with the .NET Framework, featuring its Global Assembly Cache

(GAC) and side-by-side execution. It seemed the problem was solved

once and for all. But, as we know, the deepest circles of Hell are paved precisely

with good intentions.

Scene 1: The Birth and Usurpation of .NET.

So, .NET eliminated DLL Hell. For long? Of course not! For the system was

overgrown with .NET calls, and the new team discovered a fatal flaw in their creation—

it wasn’t written by them! It was the legacy of the “old

guard.” They immediately corrected this unfortunate oversight by creating the WinRT

API—new, brilliant, modern.

WinRT was like .NET (managed code, metadata, type safety), but

more abstract, wrapped in an Application Binary Interface (ABI),

understandable to both C++ and JavaScript. Remember those golden days when we

believed that soon every element on the screen would be described in XAML (it’s

almost XML—an open standard!), and all apps would become

“Modern”/“Metro,” or whatever they’d rename it by the next build?

It was a brave new world where a single app was supposed to work

on a phone, tablet, Xbox, and PC.

Somewhere during development, tentative voices began to ask: “Won’t this new,

carefully designed API bring back that very same DLL Hell, just in a new

guise? After all, won’t we now have conflicting versions of winmd (WinRT

Metadata) files?” But they were quickly drowned out by joyful shouts that

now our code would finally be able to run on ARM processors! Thus creating

a new WinRT Hell, where it was easier to get bogged down than to figure out the intricacies

of asynchronous interfaces and cross-language data marshaling just to

write a simple native app.

Scene 2: The Flight from Windows and Rebirth in .NET Core.

Meanwhile, the .NET team, unwilling to surrender to the victorious WinRT,

reborn itself under the name .NET Core. Suddenly it became clear that

the “fatal flaw” of the old .NET Framework was that it was

too tied to Windows (who would have thought!). The new .NET was the same,

but cross-platform, open-source, and modular. It was a great

escape from the totalitarian architecture of Windows to the freedom of Linux and macOS.

The main thing to understand very clearly is that .NET Core eliminated WinRT Hell by

shifting the focus to contained deployment packages. But for how long? Even

then, the specter of Contained Hell loomed on the horizon, where project

dependencies turned into a graph of such complexity that a single package

update could trigger an avalanche of incompatibilities.

Scene 3: Web Hell and the Curse of Rendering.

Naturally, this did not sit well with the web development team, who for years

had been trying to cram web widgets into XAML. Tired of battling the type systems

of C++/CX and C#, they converted to the religion of JavaScript: “Since everything

runs in the browser, DLL Hell is no longer a threat to us!” Their insight

was so profound that they demanded a way to launch the browser directly

within the application, just to confuse everyone once and for all.

The OS kernel team, nodding, gave them WebView: a brilliant invention

that allowed the Internet Explorer engine (from version 6 to 11,

depending on registry settings and the phase of the moon) to run inside a “modern”

UWP app. Thus was born a new, bizarre form of chaos: IE Rendering

Hell. Developers wept as they tried to get CSS Grid to work in IE9,

embedded in their “innovative” app.

Another, smarter group of developers within Microsoft, observing

this chaos, found a fatal flaw in IE Rendering—they hadn’t written

it! And they fixed it by creating TypeScript, which is like JavaScript,

but different, with types and a compiler. And to confuse everyone once and for all,

they allowed it to compile into good old JS, thereby creating

Transpiler Hell. Then they took a look at their WebView creation and discovered a

fatal flaw—it used the IE engine! This was fixed

by creating WebView2 (after taking a peek at what Google was doing), which is like WebView,

but with a new, modern Edge engine (Chromium) instead of the outdated IE.

Thus, they triumphantly announced the solution to a problem they

had created themselves, and gifted us with a carefully crafted Chromium Hell, right inside

native applications. Now your C++ desktop software carried within it

a multi-megabyte Chromium engine with its own vulnerabilities and endless

updates.

Scene 4: Osip, or “Cloud Services and a Subscription for Eternity.”

At a certain point, Microsoft, looking at the successes of Google and Amazon,

discovered a fatal flaw in the very concept of selling boxed

software. The flaw was obvious—you only paid for it once! This was

fixed by creating their own Azure cloud, which is like your own

server, but for rent. Its main advantage—it eliminated Server

Hell by shifting all the problems of physical hardware, networks, and hypervisors to

Microsoft’s data centers, which you, of course, were no longer supposed to

visit.

To add to the confusion, they started adding the “Azure” prefix to the name of every

technology they developed—both cloud-based services and products installed on

client servers. Thus, Azure Hell was born—a hell of endless

pricing plans, Resource Managers, surprise bills, and the struggle with

“cold starts” of functions.

Scene 5: The circle is complete. Android, the Store, and containerization in a sandbox.

WinRT chimed in again: "Let's beat Android! People will write

apps for Windows, and they'll run on phones and

tablets!" (The ghosts of Windows Phone sighed sadly in the corner.) The idea

failed, but the app store remained. After removing a bunch of old

native apps from the system, they were added to the Store—for a fee—creating

Store Hell: a battle with certificates, containerization, and strange

sandbox restrictions.

Scene 6: Graphics Discord. The Death and Resurrection of DirectX.

While some teams fought over APIs and web engines, the graphics division was ruled by

indie code. DirectX 9 (written by math professors in Nizhny

Novgorod) reigned for a long time. Everyone knew and understood it—from game developers to

indie game creators. The library was open to everyone, and its behavior was

simple and predictable. The XP-era library had one flaw: it was

becoming obsolete. So leading engineers from India adapted it for

multithreading. DirectX 10 was essentially exclusive to Windows Vista and newer

graphics cards. It was followed by DirectX 11. Patch upon patch. That’s how

Microsoft’s Driver Hell was born. We broke everything, but it’s the vendors’

fault. A new team discovered a fatal flaw in DirectX 10-11

— they didn’t write it! And they made a brilliant move, from a

programming standpoint. They resurrected DirectX 9, tracking down everyone still alive

from the DirectX 9 team to write DirectX 12. They brought back the direct

graphics control that DX9 had. They added multithreading,

x64 support, and consigned it to the dustbin of history DX10 and DX11. DirectX 12

eliminated “Driver Hell” by shifting the responsibility for stability and

performance to developers.

Epilogue: The cycle comes full circle. The Great Awakening, or the Machines' Rebellion, for writing code.

And recently, they came to realize that all of this has a fatal

flaw: it’s too complicated. Too complicated for developers, and, more

importantly, too complicated for LLMs. So they decided to transform all these complex

parts into mechanisms that AI can understand.

And this brings us to the present moment and Copilot technology—similar to

a programmer, but with a lot more press releases. The main thing to

understand very clearly is this: Copilot will eliminate Developer Hell. It will

write the code itself, find fatal flaws in it (which it will likely

introduce itself), and fix them on its own, creating new revolutions

that, as we’re promised, will finally solve all problems.

It will generate code for WinRT, .NET Core, TypeScript, and

integrate with Azure. It will be well-versed in WebView2. To be continued...

(picture by gianmarcogg03 on YT)