5 ms·

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

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

RedShift1 4y ago
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!!!
- kristopolous 4y ago
  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 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-intergraph-clipper-c4-mcm/ https://www.cpushack.com/2011/01/16/cpu-of-the-week-intergra... Again, all this shit I know? totally useless.
  - rlkf 4y ago
    > 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.
    - stuaxo 4y ago
      Would love to see that demonstrated, maybe it will be on virtuallyfun.com one day.
    - kristopolous 4y ago
      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 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.
      - stuaxo 4y ago
        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/ 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 https://github.com/dosemu2/dosemu2/issues/606 In some more years it will probably be working fine there.
        LeFantome 4y ago
        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.
- asveikau 4y ago
  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.
  - JohnFen 4y ago
    > 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.
    - asveikau 4y ago
      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.
      - 4y ago
- rodgerd 4y ago
  > 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.
NullPrefix 4y ago
How many games designed for windows 7 can run on windows 11?
- fredoralive 4y ago
  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?
  - tom9729 4y ago
    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!
  - jamesfinlayson 4y ago
    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.
dblohm7 4y ago
Yes! A lot of people don't realize that Windows compatibility is not just about binary compatibility, but source compatibility.
- yjftsjthsd-h 4y ago
  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.
molticrystal 4y ago
>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 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.
- kristopolous 4y ago
  "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.
  - djur 4y ago
    Which part are you objecting to?
    - speed_spread 4y ago
      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.
      - guipsp 4y ago
        Windows NT is 3.1 and above
johannes1234321 4y ago
> 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.
- omoikane 4y ago
  SimCity's use-after-free bug: https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii-chicken-and-egg-problems/ https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...
JohnFen 4y ago
> 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.
makeitdouble 4y ago
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.
- revelio 4y ago
  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.
  - makeitdouble 4y ago
    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.
pjmlp 4y ago
Only up to when WinRT got introduced, now it is a mess.

RedShift1 4y ago

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

kristopolous 4y ago
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 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-intergraph-clipper-c4-mcm/ https://www.cpushack.com/2011/01/16/cpu-of-the-week-intergra... Again, all this shit I know? totally useless.
- rlkf 4y ago
  > 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.
  - stuaxo 4y ago
    Would love to see that demonstrated, maybe it will be on virtuallyfun.com one day.
  - kristopolous 4y ago
    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 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.
    - stuaxo 4y ago
      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/ 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 https://github.com/dosemu2/dosemu2/issues/606 In some more years it will probably be working fine there.
      - LeFantome 4y ago
        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.
asveikau 4y ago
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.
- JohnFen 4y ago
  > 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.
  - asveikau 4y ago
    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.
    - 4y ago
rodgerd 4y ago
> 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.

NullPrefix 4y ago

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

fredoralive 4y ago
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?
- tom9729 4y ago
  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!
- jamesfinlayson 4y ago
  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.

dblohm7 4y ago

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

yjftsjthsd-h 4y ago
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.

molticrystal 4y ago

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

kristopolous 4y ago
"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.
- djur 4y ago
  Which part are you objecting to?
  - speed_spread 4y ago
    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.
    - guipsp 4y ago
      Windows NT is 3.1 and above

johannes1234321 4y ago

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

omoikane 4y ago
SimCity's use-after-free bug: https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii-chicken-and-egg-problems/ https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

JohnFen 4y ago

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

makeitdouble 4y ago

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.

revelio 4y ago
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.
- makeitdouble 4y ago
  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.

pjmlp 4y ago

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