6 ms·

I had read somewhere that Win32 (via Wine or Proton) is the most stable target for Linux right now.

zer0zzz 3y ago
Yeah exactly!
FirmwareBurner 3y ago
>Win32 (via Wine or Proton) is the most stable target for Linux right now Tangential, Winamp 2.xx from the '90s runs and plays MP3s just fine on Windows 11 today. There are better apps for that today, but I still use it because nostalgia really whips the llama's ass. Pretty wild that the same thing is not the norm in other OSs. Even wilder is that I still have my installed copy of Unreal Tournament 99 from my childhood PC copied over to my current Win 11 machine, and guess what, it just works out of the box, 3D graphics, sound, everything. That's nearly 25 years of backwards compatibility at this point. If that's not stable, I don't know what is.
- zer0zzz 3y ago
  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
- pizza234 3y ago
  > If that's not stable, I don't know what is. What is? An immense amount of resources (developers) poured into developing live patches to make applications work on each newer version of Windows (or helping the application developers fix their applications). It's an interesting conceptual grey area - I don't consider it backward compatibility in a strict sense. This is documented in the book "The old new thing" by Raymond Chen (it's possible also to read the blog, but the book gives an organic view). It's fascinating how far-sighted Microsoft was; this approach, clearly very expensive, has been fundamental in making Windows the dominant O/S (for desktop computers).
  - Dalewyn 3y ago
    It's because Microsoft understands and respects that computers and operating systems exist to let the user achieve things. The user ultimately doesn't care if his computer is an x86 or an ARM or a RISC-V, or if it's running Windows or Mac or Linux or Android. What the user cares about is running Winamp to whip some llama's ass, or more likely opening Excel to get work done or fire up his favorite games to have fun. Microsoft respects that, and so strives to make sure Windows is the stepping stone users can (and thusly will) use to get whatever it is they want to do done. This is fundamentally different to MacOS, where Apple clearly dictates what users can and cannot do. This is fundamentally different to FOSS, where the goal is using FOSS and not what FOSS can be used for. It's all simple and obvious in hindsight, but sometimes it's the easiest things that are also the hardest.
    - eternityforest 3y ago
      It's amazing how people don't want Linux to "Be like Windows"... but as far as I'm concerned windows is close to ideal, just with a few flaws and places where FOSS can do better...
    - pizza234 3y ago
      This has very severe drawbacks, so it's not unambiguously desirable. Windows APIs are probably a mess because of this (also ignoring the fact that only company with extremely deep pockets can afford this approach). There is at least one extreme case where Windows had to keep a bug, because a certain program relied on it, and couldn't be made to work otherwise.
- cout 3y ago
  In a world where security flaws are so common, I'm not sure I want to run old software outside a virtual machine. I also wish I could agree that win32 is a stable target on Linux; it may run old software, but in my experience it is often quirky. It's usually a better use of my time to just boot windows thanks to figure out how to get software to run under wine.
nmz 3y ago
Which is quite something considering I can't have foobar running for more than an hour before it crashes.
m463 3y ago
This might be true. Another abi I see games target are ubuntu... 14.04, 16.04, 18.04, etc Ubuntu seems to be stable enough for the corporate world. I think things like flatpack or snap add bloat and behave in ways you don't want.
amadeuspagel 3y ago
Actually, web standards are.

Yeah exactly!

>Win32 (via Wine or Proton) is the most stable target for Linux right now Tangential, Winamp 2.xx from the '90s runs and plays MP3s just fine on Windows 11 today. There are better apps for that today, but I still use it because nostalgia really whips the llama's ass. Pretty wild that the same thing is not the norm in other OSs. Even wilder is that I still have my installed copy of Unreal Tournament 99 from my childhood PC copied over to my current Win 11 machine, and guess what, it just works out of the box, 3D graphics, sound, everything. That's nearly 25 years of backwards compatibility at this point. If that's not stable, I don't know what is.

zer0zzz 3y ago
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
pizza234 3y ago
> If that's not stable, I don't know what is. What is? An immense amount of resources (developers) poured into developing live patches to make applications work on each newer version of Windows (or helping the application developers fix their applications). It's an interesting conceptual grey area - I don't consider it backward compatibility in a strict sense. This is documented in the book "The old new thing" by Raymond Chen (it's possible also to read the blog, but the book gives an organic view). It's fascinating how far-sighted Microsoft was; this approach, clearly very expensive, has been fundamental in making Windows the dominant O/S (for desktop computers).
- Dalewyn 3y ago
  It's because Microsoft understands and respects that computers and operating systems exist to let the user achieve things. The user ultimately doesn't care if his computer is an x86 or an ARM or a RISC-V, or if it's running Windows or Mac or Linux or Android. What the user cares about is running Winamp to whip some llama's ass, or more likely opening Excel to get work done or fire up his favorite games to have fun. Microsoft respects that, and so strives to make sure Windows is the stepping stone users can (and thusly will) use to get whatever it is they want to do done. This is fundamentally different to MacOS, where Apple clearly dictates what users can and cannot do. This is fundamentally different to FOSS, where the goal is using FOSS and not what FOSS can be used for. It's all simple and obvious in hindsight, but sometimes it's the easiest things that are also the hardest.
  - eternityforest 3y ago
    It's amazing how people don't want Linux to "Be like Windows"... but as far as I'm concerned windows is close to ideal, just with a few flaws and places where FOSS can do better...
  - pizza234 3y ago
    This has very severe drawbacks, so it's not unambiguously desirable. Windows APIs are probably a mess because of this (also ignoring the fact that only company with extremely deep pockets can afford this approach). There is at least one extreme case where Windows had to keep a bug, because a certain program relied on it, and couldn't be made to work otherwise.
cout 3y ago
In a world where security flaws are so common, I'm not sure I want to run old software outside a virtual machine. I also wish I could agree that win32 is a stable target on Linux; it may run old software, but in my experience it is often quirky. It's usually a better use of my time to just boot windows thanks to figure out how to get software to run under wine.

nmz 3y ago

Which is quite something considering I can't have foobar running for more than an hour before it crashes.

m463 3y ago

This might be true. Another abi I see games target are ubuntu... 14.04, 16.04, 18.04, etc Ubuntu seems to be stable enough for the corporate world. I think things like flatpack or snap add bloat and behave in ways you don't want.

amadeuspagel 3y ago

Actually, web standards are.