This article has the bones of something interesting, but the style is too barren and the content really needs to be fleshed out more. I feel like if a human had written it, they would have thought of more to write. Like a human wouldn't be content with two paragraph section about K&R C without actually writing about difficulties encountered with this, parts that were interesting to implement and parts that weren't, et cetera. A human would look at that and go "ok but, what is the point to this, what makes this interesting?"

It is not enough to simply say you have done something interesting (which is all that this blog post amounts to), we as humans want to know the story of it, it's that that makes it interesting. You can't get that story if you're just vibecoding it, much like how the one person involved in Wolfram Alpha spent a lot of tokens on an LLM that constructed alternative forms of logic, and came away from it thinking that it was worthless, the entire time wasted, because there was absolutely no way for a human to interact with it, those logics had no story or analogies or anything for a human to latch on to.

While I haven't daily driven Windows in years and am usually the first to criticize Microsoft. You have to give credit where credit is due; Windows backwards compatibility is simply nuts. I had never run into compatibility issues with programs or games built for older Windows version, nor have I heard of anyone who did.

Winapi has exploded the last years in terms of functionality, still it was never sanitized to follow any C standard in terms of types.

The game is known as Qix, Xonix (title of a clone) is not a common name for the game.

16-bit windows applications aren't supported natively by 64-bit windows, but OTVDM (based on Wine code) will run most of them fine.

Yet whenever I take a look at some random React/mobile project it is impossible to build after upgrade.

> That was probably the most surprising part of the entire experiment: internally, Windows has changed enormously over the decades, yet the application interface has stayed so stable that code written in the mid-1980s still looks completely familiar.

Imagine if Linux stuck to that same level of interface compatibility. Think of the thousands of man-hours lost to rewriting perfectly good code just chasing the new shiny thing. In an OS built by volunteers we're wasting all developers' time to rebuild their software for the new interface, instead of having on developer spend time to keep the old interface working with the new implementation. And don't try to go "uhm akchyually Linux is the kernel and the kernel is stable", nobody cares. I mean the whole OS, from the kernel to the GUI layer. Is it any surprise that the best tools on Linux are all console programs using the POSIX interface, which has remained stable for the lifetime of the OS? I would go as far as to say that GTK is the Linux Desktop's original sin (followed closely by Qt). Motif and CDE were already established as the Unix GUI API, they should have been reimplemented with an optional separate GTK-native API. Maybe the next generation will learn from our mistakes.

The M6 Bolt has been around since it was first standardized in 1898.

An M6 nut from then will fit a bolt made today, and vice versa.

Compatibility over a long time period isn't hard to achieve. Simply don't mess with the standard - don't break what doesn't need fixing.