4 ms·

The most underrated feature of windows probably ever.

Dalewyn 3y ago
It really is mindblowing that Windows 11 is still capable of running 32-bit programs written for Windows 95, that's 28~29 years of backwards compatibility and environmental stability. If we look back to programs written for Windows NT 3.1, released in 1993, and assume they run on Windows 11 (because why not?) then that's 30 years of backwards compatibility. Did I say mindblowing? It's downright mythological what Microsoft achieves and continues to do.
- EvanAnderson 3y ago
  NTVDM could have been ported to 64-bit Windows, but MSFT declined to do so. Leaked Windows source code shows it would have worked[0]. That would have given 16, 32, and 64 bit compatibility. [0] https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64
  - FirmwareBurner 3y ago
    I don't get it. Would NTVDM have been better than say, using DOS-box?
    - userbinator 3y ago
      Yes, because it's integrated far more closely with the system.
    - mkup 3y ago
      Yes, it would allow to create pipes between 16-bit NTVDM processes and native 64-bit processes.
- FirmwareBurner 3y ago
  There's no guarantee that all the older apps from the Windows 9x/XP days will work today, as some apps back then, especially games, made use of non-public/undocumented APIs or just straight up hacked the OS with various hooks for the sake of performance optimizations. Those are the apps guarantee not to work today even if you turn on compatibility mode.
- SubjectToChange 3y ago
  Personally I've had little luck with even running XP applications on Windows 7. More generally, going by the difficulties experienced by many companies and organizations in the transition from XP->7, it's hardly an isolated problem. Perhaps Windows maintains the best backwards compatibility of any mainstream OS, however I would hardly describe it as "mythological".
- johannes1234321 3y ago
  The most fascinating example for that is SimCity: They noticed it didn't run under Windows 95 as Windows 95 reused freed memory pages, but SimCity did a lot of use-after-free. This would have been aborted by Win95. Microsoft developers however knew that people would blame Microsoft not Maxis, thus added an extra routine I. The memory manager, which detected SimCity and then didn't reuse memory as much. I don't want to estimate how much such hacks they accumulated over time to keep things as compatible as they could.
- Zambyte 3y ago
  > It's downright mythological what Microsoft achieves and continues to do. This seems like it was meant in a positive way, but I really don't think that if compatibility with your system requires "mythological" efforts, that should be seen as a good thing for your system. It's also worth noting that backwards ABI compatibility only masters when people limit their software by not distributing the source. Early UNIX software can run fine on modern GNU by just compiling it. API Compatibility Is All You Need ;)
  - userbinator 3y ago
    Early UNIX software can run fine on modern GNU by just compiling it. ...providing you can find a suitable compiler that isn't obsessed with exploiting undefined behaviour.
  - penteract 3y ago
    > It's also worth noting that backwards ABI compatibility only masters when people limit their software by not distributing the source. Early UNIX software can run fine on modern GNU by just compiling it. Have you ever tried building decades old programs from source? It's not as easy as you claim. Here's source for grep from v6 unix. I'd be interested to know the smallest set of changes (or flags to gcc) needed to get it to compile under gcc on linux and work. https://github.com/takahiro-itazuri/unix-v6/blob/0316b457acba0fc5ca18e454e55dd398f9e9e1e5/v6root/usr/source/s1/grep.c#L4 https://github.com/takahiro-itazuri/unix-v6/blob/0316b457acb...
    - joveian 3y ago
      Note that this is not a fair comparison since that code is almost 50 years old, predating ANSI C and before even the 8088 existed. Still, there is only one actual error in gcc 13.2.1 which is the use of =| instead of the later standardized |=. I'm not sure if that was a common thing back then or if it was specific to their C compiler. Either way, I don't think gcc has a switch to make it work. Switching that around in the source gives linker errors since it seems back then the way to print to or flush a particular file descriptor was to set a libc variable and then call flush or printf. If you had the right libc to use with it that one tiny change might be all you need. But you would likely need to set up a cross compile to be able to use the right libc. My understanding is that most of the compatability issues on Linux are due to not having the right libraries rather than the kernel not supporting older system calls. It is just a lot of not that fun work to keep things working and no one is that interested (instead, some people just use decade old versions of Linux :/ and the rest use package systems to recompile stuff). NetBSD had better practical binary compatability for a long time, although I think some of it was remove fairly recently since there isn't much commercial NetBSD software (there was one lisp binary from 1992ish IIRC that some people were still using and I think that compat was kept).
- arp242 3y ago
  Linux can do this; binaries from the 90s work today. Something like xv (last release: 1994, although the binaries were built against Red Hat 5.2 from 1998) still work today, and the source still builds with one very minor patch last time I tried it. The problem running the binaries is: % ldd ./usr/X11R6/bin/xv linux-gate.so.1 (0xf7f82000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7e22000) libjpeg.so.62 => not found libpng.so.2 => not found libz.so.1 => /usr/lib32/libz.so.1 (0xf7e08000) libm.so.6 => /usr/lib32/libm.so.6 (0xf7d0b000) libc.so.6 => /usr/lib32/libc.so.6 (0xf7a00000) libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7cde000) /lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xf7f84000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7cd8000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7cd1000) And Windows has exactly the same problem, but the tradition is to ship these things with the application rather than just assume they're present on the system. And you can "fix" it by getting old versions, or even: % ln -s /usr/lib/libjpeg.so.8 libjpeg.so.62 % ln -s /usr/lib/libpng16.so.16 libpng.so.2 You'll probably run in to trouble with PNG and JPEG files, but e.g. loading/saving GIF and whatnot works fine. Note how libc and libX* work out of the box. tl;dr: much of the "Windows compatibility" is just binaries shipping with all or most dependencies. Try it yourself: http://www.trilon.com/xv/downloads.html http://www.trilon.com/xv/downloads.html
  - mkup 3y ago
    Much of the Windows compatibility is "just" stable API for Windows controls, GUI event handling loops, 3D graphics and sound (DirectX). Linux has stable API for files and sockets (POSIX), but that's all.
    - pjmlp 3y ago
      This is also the biggest different between proper desktop operating systems since forever, and the fragmented Linux distributions. Available API means the whole stack, everything needed to write applications end to end, regardless of their purppose, not CLI and daemons.
      - arp242 3y ago

It really is mindblowing that Windows 11 is still capable of running 32-bit programs written for Windows 95, that's 28~29 years of backwards compatibility and environmental stability. If we look back to programs written for Windows NT 3.1, released in 1993, and assume they run on Windows 11 (because why not?) then that's 30 years of backwards compatibility. Did I say mindblowing? It's downright mythological what Microsoft achieves and continues to do.

EvanAnderson 3y ago
NTVDM could have been ported to 64-bit Windows, but MSFT declined to do so. Leaked Windows source code shows it would have worked[0]. That would have given 16, 32, and 64 bit compatibility. [0] https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64
- FirmwareBurner 3y ago
  I don't get it. Would NTVDM have been better than say, using DOS-box?
  - userbinator 3y ago
    Yes, because it's integrated far more closely with the system.
  - mkup 3y ago
    Yes, it would allow to create pipes between 16-bit NTVDM processes and native 64-bit processes.
FirmwareBurner 3y ago
There's no guarantee that all the older apps from the Windows 9x/XP days will work today, as some apps back then, especially games, made use of non-public/undocumented APIs or just straight up hacked the OS with various hooks for the sake of performance optimizations. Those are the apps guarantee not to work today even if you turn on compatibility mode.
SubjectToChange 3y ago
Personally I've had little luck with even running XP applications on Windows 7. More generally, going by the difficulties experienced by many companies and organizations in the transition from XP->7, it's hardly an isolated problem. Perhaps Windows maintains the best backwards compatibility of any mainstream OS, however I would hardly describe it as "mythological".
johannes1234321 3y ago
The most fascinating example for that is SimCity: They noticed it didn't run under Windows 95 as Windows 95 reused freed memory pages, but SimCity did a lot of use-after-free. This would have been aborted by Win95. Microsoft developers however knew that people would blame Microsoft not Maxis, thus added an extra routine I. The memory manager, which detected SimCity and then didn't reuse memory as much. I don't want to estimate how much such hacks they accumulated over time to keep things as compatible as they could.
Zambyte 3y ago
> It's downright mythological what Microsoft achieves and continues to do. This seems like it was meant in a positive way, but I really don't think that if compatibility with your system requires "mythological" efforts, that should be seen as a good thing for your system. It's also worth noting that backwards ABI compatibility only masters when people limit their software by not distributing the source. Early UNIX software can run fine on modern GNU by just compiling it. API Compatibility Is All You Need ;)
- userbinator 3y ago
  Early UNIX software can run fine on modern GNU by just compiling it. ...providing you can find a suitable compiler that isn't obsessed with exploiting undefined behaviour.
- penteract 3y ago
  > It's also worth noting that backwards ABI compatibility only masters when people limit their software by not distributing the source. Early UNIX software can run fine on modern GNU by just compiling it. Have you ever tried building decades old programs from source? It's not as easy as you claim. Here's source for grep from v6 unix. I'd be interested to know the smallest set of changes (or flags to gcc) needed to get it to compile under gcc on linux and work. https://github.com/takahiro-itazuri/unix-v6/blob/0316b457acba0fc5ca18e454e55dd398f9e9e1e5/v6root/usr/source/s1/grep.c#L4 https://github.com/takahiro-itazuri/unix-v6/blob/0316b457acb...
  - joveian 3y ago
    Note that this is not a fair comparison since that code is almost 50 years old, predating ANSI C and before even the 8088 existed. Still, there is only one actual error in gcc 13.2.1 which is the use of =| instead of the later standardized |=. I'm not sure if that was a common thing back then or if it was specific to their C compiler. Either way, I don't think gcc has a switch to make it work. Switching that around in the source gives linker errors since it seems back then the way to print to or flush a particular file descriptor was to set a libc variable and then call flush or printf. If you had the right libc to use with it that one tiny change might be all you need. But you would likely need to set up a cross compile to be able to use the right libc. My understanding is that most of the compatability issues on Linux are due to not having the right libraries rather than the kernel not supporting older system calls. It is just a lot of not that fun work to keep things working and no one is that interested (instead, some people just use decade old versions of Linux :/ and the rest use package systems to recompile stuff). NetBSD had better practical binary compatability for a long time, although I think some of it was remove fairly recently since there isn't much commercial NetBSD software (there was one lisp binary from 1992ish IIRC that some people were still using and I think that compat was kept).
arp242 3y ago
Linux can do this; binaries from the 90s work today. Something like xv (last release: 1994, although the binaries were built against Red Hat 5.2 from 1998) still work today, and the source still builds with one very minor patch last time I tried it. The problem running the binaries is: % ldd ./usr/X11R6/bin/xv linux-gate.so.1 (0xf7f82000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7e22000) libjpeg.so.62 => not found libpng.so.2 => not found libz.so.1 => /usr/lib32/libz.so.1 (0xf7e08000) libm.so.6 => /usr/lib32/libm.so.6 (0xf7d0b000) libc.so.6 => /usr/lib32/libc.so.6 (0xf7a00000) libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7cde000) /lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xf7f84000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7cd8000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7cd1000) And Windows has exactly the same problem, but the tradition is to ship these things with the application rather than just assume they're present on the system. And you can "fix" it by getting old versions, or even: % ln -s /usr/lib/libjpeg.so.8 libjpeg.so.62 % ln -s /usr/lib/libpng16.so.16 libpng.so.2 You'll probably run in to trouble with PNG and JPEG files, but e.g. loading/saving GIF and whatnot works fine. Note how libc and libX* work out of the box. tl;dr: much of the "Windows compatibility" is just binaries shipping with all or most dependencies. Try it yourself: http://www.trilon.com/xv/downloads.html http://www.trilon.com/xv/downloads.html
- mkup 3y ago
  Much of the Windows compatibility is "just" stable API for Windows controls, GUI event handling loops, 3D graphics and sound (DirectX). Linux has stable API for files and sockets (POSIX), but that's all.
  - pjmlp 3y ago
    This is also the biggest different between proper desktop operating systems since forever, and the fragmented Linux distributions. Available API means the whole stack, everything needed to write applications end to end, regardless of their purppose, not CLI and daemons.
    - arp242 3y ago