Hacker News Reader

Comment by kristopolous | Hacker News Reader

Windows backwards compatibility is also pretty phenomenal if you know what you're doing.

There was an article a couple of years ago about taking binaries from either windows 1 or 2, changing a few bits of the header and it would run fine.

Edit: actually it's covered in the Wikipedia article https://en.m.wikipedia.org/wiki/Windows_1.0x

It's an old citation but here's the snippet:

"Due to Microsoft's extensive support for backward compatibility, it is not only possible to execute Windows 1.0 binary programs on current versions of Windows to a large extent but also to recompile their source code into an equally functional "modern" application with just limited modifications"

I haven't touched windows in probably 15 years though so I can't speak for any of this. Funny, I was a Windows software developer for a decade and now I know nothing about it. I don't even know if the debug tools I used to use made the leap to 64 bit

View on HN

IMO it's not phenomenal, it's the job of an operating system! Something seemingly lost to many new devs. I'm pretty convinced by now the reason the win32 API is so stable because no developer is interested in "the old stuff", so nobody tinkers with it, hence stuff doesn't break. I'm fully with Linus Torvalds on this one, DON'T break userspace!!!

It's actually work IIRC. Again, out of the game for 15 years but they used to be subsystems - these ABI compatibility layers

Windows had one for DOS, Windows 16, "posix" and "os/2" with the last two in air quotes because it was only a subsection and they claimed mission accomplished - I think it was specifically to satisfy some government requirement but don't use me as a reference here. I don't think it could do os/2 "Presentation Manager" for instance. And there was a reason that cygwin was still a thing. I used it for an actual production project maybe 22 years ago. Wow, you've never seen slow until you run cygwin bash scripts on windows 2000.

Regardless, it didn't come free - there's people up in Redmond who had that as part (or maybe all) of their job. I would have done that - maintain an esoteric part of Windows for a Microsoft salary? That's the kind of job where you have almost no boss. Sign me up.

They had a bunch of weird projects like that. IE for Unix which ran on Solaris and HPUX (evolt has them: https://browsers.evolt.org/browsers/archive/ie you can probably QEMU that if you want). They also had Alpha, MIPS and I believe PPC versions of windows. There were a lot of other things that never got done. Like Windows for Intergraph Clipper, a fact that someone somewhere has decided to vouch for me on 12 years ago over yonder: https://www.cpushack.com/2011/01/16/cpu-of-the-week-intergra...

Again, all this shit I know? totally useless.

> I don't think it could do os/2 "Presentation Manager" for instance.

There was a Presentation Manager subsystem for NT that could run 16-bit OS/2 graphical programs, but it was about as hard to come by as buying a single LTSC license is today.

That's absurd. It's almost as silly as Quarterdeck's DESQview/X product that ran win-16 binaries. I ran it for laughs once in 2001, it worked. Motif, X, remote X, and 16 bit Windows --- it's everything you never wanted. http://toastytech.com/guis/dvx.html of course has a gallery. Quarterdeck - thanks for the memories, and also, the memories

The lesson of DESQ is to design software to run on the computers of tomorrow and don't worry so much about the computers of today. That sounds stupid to me as well but neither of us have yachts or private jets so what do we know. It's about colonizing the future.

I wouldn't be surprised if FreeDOS could spin this up.

Virtuallyfun has a go at running DesqView/X... and now I'm shocked to see it was all the way back in 2011 !

https://virtuallyfun.com/2011/03/27/desqviewx/

There's also a long running ticket in dosemu2 around some issues with DesqView/X https://github.com/dosemu2/dosemu2/issues/606

In some more years it will probably be working fine there.

2011? Try 1992!

DesqView/X was graphically multi-tasking DOS programs and running X applications the year after Linux was released. This was the Windows 3.1 era ( no cooperative multitasking ) and before OS/2 2.0 was out. Amazing.

Like everything else at the time though, it could not run Windows applications ( Microsoft Office ) and so it was doomed.

Would love to see that demonstrated, maybe it will be on virtuallyfun.com one day.

There's kind of a tension between new Microsoft and old Microsoft.

Old Microsoft put lots of thought into extensibility of APIs and makes it so that the old interfaces still work when they introduce new functionality.

New Microsoft rewrites components from scratch and deprecates the old one every few years, and doesn't bother to shim over the old interface.

The former group has it such that if your app was well written circa 1997-2001, it works well on the current release.

The latter group has it so that you have several different copies of .NET on your hard drive and the "recommended" UI libraries for new applications has changed a lot, and the new hotness from a few years ago is deprecated.

> New Microsoft rewrites components from scratch and deprecates the old one every few years, and doesn't bother to shim over the old interface.

This seems to be a trend across the industry, not just Microsoft. And it's a real shame. It makes it too risky to use a lot of shiny new things in real projects.

I agree it's an industry wide thing.

The Microsoft-specific variant of it is something I've seen up close. One of the issues always struck me as confusing interface and implementation. There isn't a good recognition of the fact that when you write against an API, you code against an abstraction, not a particular implementation. If your interface is good enough, you can do the rewrite treadmill thing to justify your current bonus or whatever, but you can point the old interface at a new implementation without most callers knowing the difference.

So, I think a good example of this working relatively well would be Windows audio. The WinMM API still works. They rewrote the audio stack a couple of times, and introduced new APIs such as WASAPI and I forget the newer one. Winmm isn't broken. It may not have access to all the latest features, but it works.

In contrast, all too often they discard an entire API because they want to rewrite the components underneath. But the I in API stands for interface. A good interface can survive rewrites of what's underneath.

An interface is how you connect your own code to the other code. There is a large interface design space spanning from extremely minimal and simple, to extremely detailed, flexible, giving control over performance etc.

Interfaces that are very simple tend to allow a broad range of implementations but may fail to make accessible all the capabilities of the implementation. On the other hand, interfaces that provide good control over runtime characteristics etc. tend to already give away the implementation.

If "API" were primarily about abstraction, it would be called APA.

I disagree with most of this, but everyone is entitled to their opinion.

One point I'll offer is that ability to shim an old interface onto a new implementation validates the design of the new thing. If you can't shim them, chances are there's some necessary problem you aren't solving, and possibly aren't aware of.

Concrete details of all these things will alter the discussion. I think my example of audio is a good one for the strength of "the old way". The old interface works, even though it does vastly different things than it did in 1995. Like you say, maybe there are some features you can't get with the old interface -- that can be OK. But they didn't break it.

The Win32 subsystem on NT-based Windows began as such a shim too. The NT native APIs sometimes look very very different. Most people don't know this. eg. Most people don't know that renaming things isn't its own syscall that operates on a source filename a la unix rename(2), which is what Win9x did -- that there's transparently an NtCreateFile() call that happens inside MoveFile() ... Philosophically, the NT API "hates" doing things based on filenames, most operations that Unix or Winapi have as filenames operate on handles... But nobody needs to know, the Win9x API is the public API.

> But the I in API stands for interface. A good interface can survive rewrites of what's underneath.

Absolutely!

But a good interface is also a really difficult thing to engineer, in part because it seems like a relatively easy thing. The gotchas don't become apparent until long after you ship.

Sometimes I wonder if some of this is just cost-cutting. A difficult task is an expensive task. Other times, I wonder if it's because API design is an actual specialty, and there are too many devs doing it who don't have the chops for it.

Also add the WinRT folks into the New Microsoft.

Deprecated C++/CX and .NET Native, while neither Native AOT nor C++/WinRT are proper replacements in capabilities, replaced UWP/WinUI 2.0 with WinAppSDK/WinUI 3.0 with lots of missing capabilities.

> Something seemingly lost to many new devs. I'm pretty convinced by now the reason the win32 API is so stable because no developer is interested in "the old stuff", so nobody tinkers with it, hence stuff doesn't break.

I highly encourage you to take a look at the work Microsoft did with the XBox backwards compatibility for the XBox One X/S; unlike their naming teams, MS have people who care deeply about this stuff. Not only did they spend a lot of time making sure that most games work on the One X, they spent time doing things like having the newer platform upgrade the games on the fly where possible.

MS absolutely has people tinkering with their old APIs, sometimes to quite good effect.

> Windows backwards compatibility is also pretty phenomenal if you know what you're doing.

Windows backwards compatibility is also pretty phenomenal if you DON'T know what you're doing and are important enough.

There is the famous case about Windows 95 detecting SimCity and then switching to a more careful memory manager as SimCity had quite some use after free problems, which would crash otherwise.

SimCity's use-after-free bug:

https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

> Windows backwards compatibility is also pretty phenomenal

This is a point on which I give Microsoft high praise, and they have my great sympathy.

The issue for Windows is existential -- a large percentage (perhaps a majority) of people would ditch Windows in a heartbeat if they had to replace their software because of a new Windows version. Backward compatibility is Microsoft's moat.

It has been worth it to Microsoft to put serious resources toward that end, and they've worked miracles in terms of backward compatibility. It really is amazing.

And I have sympathy for them about it, too, because I guarantee that Microsoft would rather be able to run without carrying that burden too much.

I think this is the main reason why they are extremely forceful about updates. If everyone is using the same version, backward compatibility becomes easier because you don't have to keep it for as long.

I was super impressed by Windows' efforts on the backwards compatibility part, in particular with all the legendary articles on them testing specific apps and leaving alternate modes reproducing the bugs so the apps can continue working.

And then I opened again a windows laptop...and the words than came to mind were "missing the forest for the trees".

Like, I feel that Microsoft really cares a lot about each and every tree, and went above and beyond to make the most trees happy and cut down as few trees as they could at every iteration. And we lauded then for that, cheering at every tree that could stay alive.

Except now the forest is really badly planned, it grew and expanded a lot but without enough prunning really, each user has to carve a path with a chainsaw to get anywhere livable, we regularly fall into forgotten valleys with runes to unlock lost technology.

I won't argue it needs to be a walled garden breaking new at every release, but there must be a better middle-ground for all of this.

The basic problem is that they didn't provide a proper evolution for Win32. So yes, Win32 apps still "work" if you can tolerate tiny, non scaled 1995 era UI. If you want a modern looking UI that properly scales then they said rewrite it all in WPF. And then WinUI. And then JS/HTML. And then WinUI2. And then WinUI3. At no point was there a smooth upgrade path.

It's hard, really hard, so I don't really blame them for failing. But, Apple mostly managed it. AppKit/UIKit is pretty much a direct path from NeXTStep in the 1980s. 30+ years of evolution, without breaking the whole API until SwiftUI came along. Pretty impressive. Apple should get more credit for that.

Yes. To note, Apple still had its arm wrestling moments, famously with Microsoft and Adobe, where Apple wanted the apps devs to move on and got a resounding "nope" in return. That resulted in the Carbon API for instance lingering on for a while, but they could still manage a transition and deprecate it.

Just thinking about the two processor architecture transitions and the whole OS7 -> OSX switch, they really have an expertise no other company seems to even get close to.

Offering emulation where compatibility is broken definitely helps.

The current upgrade path from Win32 is Win32, I think. Microsoft now present it alongside WPF, WinForms and UWP as an option for developing new apps in the "get started" guide [1]. They have also added (or restored?) lots of useful documentation [2] on Win32, including how to handle UI scaling [3].

[1] https://learn.microsoft.com/en-us/windows/apps/get-started/#...

[2] https://learn.microsoft.com/en-us/windows/win32/

[3] https://learn.microsoft.com/en-us/windows/win32/hidpi/high-d...

The third link says:

"if you're creating a new Windows app from scratch, it is highly recommended that you create a Universal Windows Platform (UWP) application. UWP applications automatically—and dynamically—scale for each display that they're running on."

but no fault on you for being confused, Microsoft announces changes in strategy so fast they can't update their docs to keep up, so their once great MSDN has become a rats nest of contradictory advice and recommendations.

At any rate if you've tried to do Win32 hidpi you will know that it hardly works and this represents defeat by Microsoft. For example hidpi is only even attempted for windows created from dialog resources, but most aren't, so if you run any classical win32 apps they still have tiny 16x16 icons everywhere, tiny fonts, basically unusable on modern screens. Apple went through this pain with the original Retina transition where icons were blurry on old apps for a while, but they updated all their own apps and brought the ecosystem with them on that journey. Microsoft never did.

And it's all like that. Win32 has barely evolved for decades. There are occasional new magic flags and an ever-greater pile of hacks, but there's been no serious attempt to keep it competitive. The assumption was that everyone would migrate to .NET and WinForms but that didn't happen for various reasons. By then, Win32 - never a particularly well designed or well loved API even inside MS - was so aged that they felt it'd be easier to start over from scratch. And once that Rubicon was crossed, they did it again and again.

Apple managed it by using hacks such as forced integer upscaling. It works reasonably well for them because they mostly control the hardware. Windows needs to be able to deal with scaling factors like say 150% to accommodate all that it runs on, which is quite a bit harder.

Yup. And yet, they managed it.

>It's an old citation but here's the snippet:

Really old citation, 1995...

>There was an article a couple of years ago about taking binaries from either windows 1...

The below article seems to go more indepth and was written in 2020, might even be the one you were thinking of:

https://soylentnews.org/article.pl?sid=20/05/10/1753203

>As previously noted, Windows 95 dropped support for 1.x and 2.x binaries. The same however was not true for Windows NT, which modern versions of Windows are based upon. However, running 16-bit applications is complicated by the fact that NTVDM is not available on 64-bit installations.

>After letting NTVDM install, a second attempt shows, yes, it is possible to run Windows 1.x applications on Windows 10 [32-bit].

>FONTTEST also worked without issue, although the TrueType fonts from Windows 3.1 had disappeared.

There's even a way to run 16-bit Windows binaries on 64-bit Windows now.

https://github.com/otya128/winevdm

Oh my gosh. That screenshot of the Calculator alone brought back memories from my childhood.

Oh neat, I might need to try this on Wolfenstein 3D.

"As previously noted, Windows 95 dropped support for 1.x and 2.x binaries. The same however was not true for Windows NT, which modern versions of Windows are based upon."

No way. I'll need major citations on that. Wikipedia for one, firmly disagrees as does every book I've read on that history.

edit: I quoted it and still misread it. I thought it said windows nt was based on windows 1&2.

Which part are you objecting to?

I object to NT natively supporting 16 bit apps. I think they dropped that in Win7 or before. Of course with VMs everything is possible but it's no longer built-in.

32 bit Windows NT supported 16 bit Windows apps (and DOS) right until 32 bit Windows was dropped with Windows 11. 64 bit Windows has never supported them. As 64 bit Windows became commonly installed around Windows 7, you might get the impression it was dropped then, but it was still around if you really wanted it.

Windows NT is 3.1 and above

Eh, not quite. 3.1 ran on DOS, there was an NT 3.1 (separate OS) that was NT. NT and legacy Windows ran in parallel for a while, up through Windows 2000/Windows ME. That ended with Windows XP, the first consumer Windows NT release.

I misread it. I thought it said windows nt is based on windows 1 and 2. carry on

Yes! A lot of people don't realize that Windows compatibility is not just about binary compatibility, but source compatibility.

I feel like culturally speaking that's fair? The Windows ecosystem expects closed-source programs that are purely given to users as binaries, the ecosystem around FOSS operating systems expects most programs to be published as source code and then compiled by users or distros.

Only up to when WinRT got introduced, now it is a mess.

How many games designed for windows 7 can run on windows 11?

I think those that have a dependency on Games for Windows Live are screwed, so not Microsoft first party games, but most should? Isn’t it more XP and earlier stuff that has a reputation for being finicky, not DX9/10 stuff?

Anything that depends on Safedisc is also screwed because Microsoft pulled the driver for security reasons. This includes a lot of first-party stuff like Mechwarrior 4 and Freelancer. Really wish they would put those up on GOG!

I think the only game I ever had trouble running on a newer version of Windows was James Bond 007 Nightfire but compatibility mode seemed to work okay. I haven't played heaps of games in the last decade but any issues have been more with getting the right version of the Visual C++ runtime or PhysX (which Steam usually handles for you anyway) rather than the underlying operating system.

Reply on news.ycombinator.com