Rendered at 15:04:56 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
fao_ 3 hours ago [-]
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.
jdsnape 3 hours ago [-]
I agree, another example is the line ‘lots of things had to be done by hand’. I think a more human narrative would be describing the discovery that thing X that we take for granted was missing and tell the story of figuring it out.
Giving them the benefit of the doubt though, perhaps they were aiming for brevity.
glimshe 2 hours ago [-]
I respect your tastes but, as a human, I like the objectivity in the article. I actually couldn't care less about the backstory and I tend to skip articles that wander around without getting to the point. I prefer to read a book when I want that.
In other words, different people sometimes want different things...
el_peaton 3 hours ago [-]
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.
shakna 2 hours ago [-]
Some games that ran on Vista, can run under Wine, but not on Windows 11. The backwards compatibility story has changed in the last few years.
Asmod4n 1 hours ago [-]
Games for Windows, can’t play any of those anymore without cracking them since the severs got turned off.
pathartl 31 minutes ago [-]
I'd like to know which ones you've had issues with. I've compiled a collection of hundreds of Windows games from ~96-2006 and I've only run into one that's required an appcompat flag (carmageddon 2).
GeekyBear 22 minutes ago [-]
Heroes of Might and Magic 3
zabzonk 3 hours ago [-]
> I had never run into compatibility issues with programs or games built for older Windows version
Try running a real-mode Windows program on a modern version of Windows.
dwattttt 2 hours ago [-]
Intel backwards compatibility has meant that real mode is still with us more of less, but to give context to people who aren't as familiar: real mode was superseded by protected mode with the introduction of the 80286, in 1982.
EvanAnderson 37 minutes ago [-]
For sure.
Not building NTVDM for 64-bit Windows was a major departure from previous strategy and marks a clear regression in Microsoft's attitudes toward backwards compatibility.
mschuster91 6 minutes ago [-]
> and marks a clear regression in Microsoft's attitudes toward backwards compatibility.
Yeah... but for what purpose should it have been kept? Anyone with a legitimate need to run 16 bit software on a modern Windows machine can always go for virtualization or emulation. The effort required in supporting that technology is far from zero, and old code to work with legacy stuff - no matter in which project - is always a fruitful source of security exploits.
rvnx 2 hours ago [-]
You just need to install 86Box as a compatibility layer. Everything runs perfectly.
You only have to copy-paste one .exe file and then you can launch your app from Windows, that’s it. Sounds perfectly reasonable.
Narishma 2 hours ago [-]
86box is a PC emulator, not a compatibility layer.
rvba 2 hours ago [-]
Lots of old games dont work anymore, but you can still run them by compabtibility modes.
16 bit programs dont seem to work at all though - you need wine or dosbox
Dwedit 2 hours ago [-]
16-bit windows applications aren't supported natively by 64-bit windows, but OTVDM (based on Wine code) will run most of them fine.
masfuerte 30 minutes ago [-]
I've been using otvdm (aka winevdm) and it is very good. It works like the original ntvdm did when running on non-x86 platforms. It emulates the processor and translates 16-bit api calls into 32-bit api calls so things work as you'd expect.
Just fwiw, it built and ran ok on windows 10, with tcc. 64 bit exe...
Dwedit 2 hours ago [-]
The game is known as Qix, Xonix (title of a clone) is not a common name for the game.
wiseowise 2 hours ago [-]
Yet whenever I take a look at some random React/mobile project it is impossible to build after upgrade.
PaulHoule 1 hours ago [-]
So em dash.
fithisux 2 hours ago [-]
Winapi has exploded the last years in terms of functionality, still it was never sanitized to follow any C standard in terms of types.
Dwedit 2 hours ago [-]
To be fair, the C standard for types is pretty dreadful. How big is an int? A long? Want an integer type that matches the size of a pointer? <stdint.h> did fix a lot of the issues, but people targeting an early C version don't have this header available.
Windows type names have stayed mostly stable since Win32, but some of them are still misleading. DWORD, UINT and ULONG are all 32-bit unsigned integer types. But in C#, "ulong" is a 64-bit type despite having the same name, this leads to making mistakes when transcribing Win32 type names into C# code.
Windows came up with its type names before <stdint.h> existed, so you won't see any uint32_t in there, just DWORD.
It's not (reasonably) possible to do so though, because it would break so, so much legacy code. The only thing you can do is to add new functionality (e.g. the difference between A and W APIs - A is ASCII, W is UTF-16) or to shoehorn crap onto existing interfaces (again, A APIs to which you pass UTF-8 and pray for the best), but you cannot delete any publicly exposed API or modify existing types.
Asooka 2 hours ago [-]
> 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.
ezst 17 minutes ago [-]
Who exactly in the Linux world is supposed to get paid wonderfully to keep mountains of old cruft and technical debt in working order? Not to say I'm insensitive to your point, but when whole UI frameworks are amateurs' passion-projects, the practical burden of maintenance has very real implications. That's essentially the whole story behind the Linux desktop losing Xorg.
56 minutes ago [-]
velcrovan 2 hours ago [-]
Ah but what about (dun dun dun) “innovation”
londons_explore 2 hours ago [-]
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.
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.
Giving them the benefit of the doubt though, perhaps they were aiming for brevity.
In other words, different people sometimes want different things...
Try running a real-mode Windows program on a modern version of Windows.
Not building NTVDM for 64-bit Windows was a major departure from previous strategy and marks a clear regression in Microsoft's attitudes toward backwards compatibility.
Yeah... but for what purpose should it have been kept? Anyone with a legitimate need to run 16 bit software on a modern Windows machine can always go for virtualization or emulation. The effort required in supporting that technology is far from zero, and old code to work with legacy stuff - no matter in which project - is always a fruitful source of security exploits.
You only have to copy-paste one .exe file and then you can launch your app from Windows, that’s it. Sounds perfectly reasonable.
16 bit programs dont seem to work at all though - you need wine or dosbox
https://github.com/otya128/winevdm
Windows type names have stayed mostly stable since Win32, but some of them are still misleading. DWORD, UINT and ULONG are all 32-bit unsigned integer types. But in C#, "ulong" is a 64-bit type despite having the same name, this leads to making mistakes when transcribing Win32 type names into C# code.
Windows came up with its type names before <stdint.h> existed, so you won't see any uint32_t in there, just DWORD.
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.
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.