Live data from Hacker News

Windows 1.0 and the WinAPI, 40 Years Later

medium.com

31–40 of 55 posts

Re: Windows 1.0 and the WinAPI, 40 Years Later

#31
post #15

> 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 shin…

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.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#32
post #5

Earlier quoted context omitted.

> 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.

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.

> 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.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#33
post #15

> 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 shin…

OSS is essentially more chaotic as everyone as his/her own ideas. It’s not too different in a corporation but when someone is in control it’s easier to centralize things.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#34

Earlier quoted context omitted.

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.

> 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…

My observation is the "old Microsoft" would have kept it in and supported it because that's how they rolled. The lack of NTVDM in x64 Windows signaled a change that the commitment to compatibility is now on shaky ground.

Whether it should have been kept for a technical reason is secondary, in my mind, to eroding the confidence their Customers had that old software would continue to work.

The market doesn't seem to give a damn so I guess they made the right call.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#35
post #31
post #15

> 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 shin…

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.

In the end, it's always the old problem, how to properly fund open source projects.

Maybe with the current political events and subsequent changes in priorities we'll see EU governments ponying up some money under "digital sovereignty" programs - but given the rabid opposition to systemd (funded by RedHat), I fear that any attempt by the EU to get some order into the chaos will be met with just the same toxicity.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#37
post #8

Earlier quoted context omitted.

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.

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).

My dad had trouble getting the Panzer General / other General Series to run.

iirc, the installer is 16-bit, there's problems with too much disk space and/or too much ram, and then there's cryptic error messages. Oh and the please don't run this on WindowsNT message.

We did find something 3rd party that uses the assets, so all wasn't lost, but ...

Windows has a reputation for amazing back compat, and it's pretty good, but it's not really surprising to find things that don't work. Especially games from that era, there are common issues that come up a lot, but afaik, there's no microsoft compat option to lie about disk space, ram, or vram ... or it doesn't automatically trigger at least.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#38
post #5

Earlier quoted context omitted.

> 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.

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.

I believe Microsoft removed support for 16bit Windows applications some time ago.

The hardware may be willing but the software is now incapable.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#39
post #15

> 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 shin…

Thanks, we (Linux/BSD) users cannot bring up this topic often enough.

I totally understand, that it cannot work unless money is there, which simply is not, in the Linux desktop world. Compatibility is expensive, hard work and not much fun.

I do not think, this will ever change, in the end, the web/Electron has won, desktop operating systems are less important compared to mobile, so who should invest in a stable GUI platform for Linux?

By now, basically all applications I rely on are CLI programs (posix), web or Electron and a few simple GUI tools (PDF viewer, ...) which can easily replaced.

How is the saying: If you want a portable GUI application for Linux, target Win32 and run it via Wine.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#40
post #19
post #2

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, e…

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...

Ok, but brevity is the soul of wit. That's part of my point, this is a long form article with no content. If a human had written it, it would simply have been two to four paragraphs instead! "I made a thing, and it was cool the api stayed the same" rather than this really long winded article saying nothing at all.
Post reply on HN