4 ms·

> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade. You can on Windows. Microsoft has shown us what

> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade. You can on Windows. Microsoft has shown us what a three decades of maintaining an OS to that standard will do to a platform and its software ecosystem. There are definitely pros and cons to taking that approach. These days, as a user I'd much rather have decent emulators of older platforms and operating systems, rather than rely on the current OS to be completely and forever backwards compatible. But that doesn't seem like a good solution for mobile platforms or their app stores.

kitsunesoba 5y ago
Windows really is the exception and not the rule, though. In fact in the free and open world of Linux, backwards compatibility is even worse… a binary compiled a year ago has a good chance of no longer working. Stuff like Flatpak is improving that situation a bit, but it’s still nowhere as backwards compatible as Windows.
- wila 5y ago
  > In fact in the free and open world of Linux, backwards compatibility is even worse… I have linux binaries from 2001 that still work fine on recent Linux kernels.
  - berkut 5y ago
    If they're CLI C ones, or statically link all deps: sure.... If they link against libstdc++, Qt or Python, good luck...
    - seba_dos1 5y ago
      Games usually bundle or statically link their dependencies (just like most software on Windows).
    - kitsunesoba 5y ago
      Those three you listed have definitely been the most problematic by far when trying to run things on Linux.
- noobermin 5y ago
  An amazing sentiment calling the operating system used the most across the entire world an exception rather than it being a standard. And I don't know how you envoke the problem (yes problem) of broken dependencies on linux and think it adds to your argument on why this is a good move by Apple.
  - kitsunesoba 5y ago
    Windows may be the most commonly used OS, but nevertheless it is just one OS among many and the others have worse backwards compatibility… most considerably so.
- edflsafoiewq 5y ago
  Linux has excellent backwards compatibility if you bundle your dependencies the same way you do on Windows. Most low-level interfaces - the kernel, libc, X, GL - pay close attention to backwards compatibility.
- nezirus 5y ago
  It is actually the oposite on Linux. You compile on older distro (e.g. CentOS 6), and it will work on later versions, (CentOS 7). https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...
scarface74 5y ago
And Windows also shows you what happens when you have layers upon layers of compatibility hacks and the security nightmares it brings. One of the first major IIS security issues happened because of the eight different string types and conversions between them to work with the various APIs. You could “hack” a Windows server running IIS just by encoding DOS commands in the URL bar. http://cd.textfiles.com/hmatrix/Tutorials/hTut_0239.htm http://cd.textfiles.com/hmatrix/Tutorials/hTut_0239.htm Also, by Apple eventually abandoning backwards compatibility, it was able to migrate Macs to different better processors four times. By abandoning 32 bit software support, it was able to save space on its processors.
- rvense 5y ago
  > Also, by Apple eventually abandoning backwards compatibility, it was able to migrate Macs to different better processors four times. 68k -> PPC actually did not break backwards compatibility at all. They realized it they had to make it good for the transition to work, so they built emulation right into the OS. A well-behaved app made for a 1984 Mac will run unmodified on the last version of old Mac OS, and on Mac OS X up to 10.4 under the Classic environment, that's over 20 years of compatibility. Apple could have maintained this level of compatibility until today, but they choose not to.
  - scarface74 5y ago
    This is definitely not true. The 68K emulator didn’t support any 68K apps that required a floating point unit, apps that were not “32 bit clean”, or apps that used self modifying code. Even the introduction of the MultiFinder broke many old 68K apps. Apple couldn’t maintain 32 bit app support with newer processors without wasting die space.
- justin66 5y ago
  Gesturing towards an IIS bug discovered twenty years ago does not bolster your argument.
  - scarface74 5y ago

kitsunesoba 5y ago

Windows really is the exception and not the rule, though. In fact in the free and open world of Linux, backwards compatibility is even worse… a binary compiled a year ago has a good chance of no longer working. Stuff like Flatpak is improving that situation a bit, but it’s still nowhere as backwards compatible as Windows.

wila 5y ago
> In fact in the free and open world of Linux, backwards compatibility is even worse… I have linux binaries from 2001 that still work fine on recent Linux kernels.
- berkut 5y ago
  If they're CLI C ones, or statically link all deps: sure.... If they link against libstdc++, Qt or Python, good luck...
  - seba_dos1 5y ago
    Games usually bundle or statically link their dependencies (just like most software on Windows).
  - kitsunesoba 5y ago
    Those three you listed have definitely been the most problematic by far when trying to run things on Linux.
noobermin 5y ago
An amazing sentiment calling the operating system used the most across the entire world an exception rather than it being a standard. And I don't know how you envoke the problem (yes problem) of broken dependencies on linux and think it adds to your argument on why this is a good move by Apple.
- kitsunesoba 5y ago
  Windows may be the most commonly used OS, but nevertheless it is just one OS among many and the others have worse backwards compatibility… most considerably so.
edflsafoiewq 5y ago
Linux has excellent backwards compatibility if you bundle your dependencies the same way you do on Windows. Most low-level interfaces - the kernel, libc, X, GL - pay close attention to backwards compatibility.
nezirus 5y ago
It is actually the oposite on Linux. You compile on older distro (e.g. CentOS 6), and it will work on later versions, (CentOS 7). https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...

scarface74 5y ago

And Windows also shows you what happens when you have layers upon layers of compatibility hacks and the security nightmares it brings. One of the first major IIS security issues happened because of the eight different string types and conversions between them to work with the various APIs. You could “hack” a Windows server running IIS just by encoding DOS commands in the URL bar. http://cd.textfiles.com/hmatrix/Tutorials/hTut_0239.htm http://cd.textfiles.com/hmatrix/Tutorials/hTut_0239.htm Also, by Apple eventually abandoning backwards compatibility, it was able to migrate Macs to different better processors four times. By abandoning 32 bit software support, it was able to save space on its processors.

rvense 5y ago
> Also, by Apple eventually abandoning backwards compatibility, it was able to migrate Macs to different better processors four times. 68k -> PPC actually did not break backwards compatibility at all. They realized it they had to make it good for the transition to work, so they built emulation right into the OS. A well-behaved app made for a 1984 Mac will run unmodified on the last version of old Mac OS, and on Mac OS X up to 10.4 under the Classic environment, that's over 20 years of compatibility. Apple could have maintained this level of compatibility until today, but they choose not to.
- scarface74 5y ago
  This is definitely not true. The 68K emulator didn’t support any 68K apps that required a floating point unit, apps that were not “32 bit clean”, or apps that used self modifying code. Even the introduction of the MultiFinder broke many old 68K apps. Apple couldn’t maintain 32 bit app support with newer processors without wasting die space.
justin66 5y ago
Gesturing towards an IIS bug discovered twenty years ago does not bolster your argument.
- scarface74 5y ago