4 ms·

I have written desktop applications for Windows, OS X, and Linux, and before WebGL was a thing, I took the Win32 source code for Google Earth, made it portable,

I have written desktop applications for Windows, OS X, and Linux, and before WebGL was a thing, I took the Win32 source code for Google Earth, made it portable, made a Mac version and then others built on top of that to make a Linux version. I will second everything that this slashdot comment says. The WIN32 version, all that we've ever released, still work. Some of the older ones may not find old servers, but the code itself is functional. None of the older linux versions work on a modern linux distribution. In fact, we gave up maintaining the Linux version because it was too much work to keep up with the drift in LSB, OpenGL, libc, and when you put in man-months to get the latest version working on the main distributions, you had the Gentoo users screaming bloody murder that we can't support every combination of compile flags they used. LSB was supposed to fix this, but it was a dumpster fire. Mac is somewhere in between. Apps run for a while, but the deprecation of 32-bit apps broke older Google Earth binaries. On OS X, you need to recompile and re-distribute your software every 2-3 years, would be my rough guess. Windows has backward compatibility solved better than anyone. I can still run 1990's code on Windows 10.

znpy 6y ago
> The WIN32 version, all that we've ever released, still work. Some of the older ones may not find old servers, but the code itself is functional. I feel you. I made pretty much this argument to a fellow GNU/Linux user (arch Linux user, if that adds anything). He started saying that syscalls are stable and that it's a gtk/GUI library problem and that if you were to, say, if you somehow loaded all the old libraries, it would work. Which might be true and everything, but come on. That's the equivalent of pushing your hands on your ears and shouting. Quite frankly, the thing that saves GNU Linux a bit is that windows is basically getting shittier and shittier at user experience.
- loopz 6y ago
  I recently compiled linux code from late 90s on Ubuntu. Apart from having to apt-get make utils and deprecated libs, it still worked, though with wrong server hosts. You may run into glibc, 64 bit vs 32 bit issues and the like, but lots of it is pretty compatible. Windows has its own legacy compatibility layers, though it is questionable if that's really a great idea.
  - znpy 6y ago
    Yes, indeed, I do believe it's both feasible and true, but let's keep the discourse in the context of desktop usage and desktop users: could you really advice a regular user to go through all those steps? That's the point. In windows 99 times out of 100 you can just run the binary.
- andor 6y ago
  > He started saying that syscalls are stable and that it's a gtk/GUI library problem and that if you were to, say, if you somehow loaded all the old libraries, it would work. That's because no single organization can be blamed for the mess that is "GNU/Linux" ;-) Binary compatibility is very important for the kernel folks, but apparently much less so for maintainers of glibc and other libraries. As a workaround, binaries can be statically compiled, or bundled with all their dependencies. Flatpak and Snappy are two projects addressing this issue by packaging applications as containers.
  - znpy 6y ago
    Congrats you missed the point too. When it comes to backward compatibility nobody cares what projects are starting today (and would care even less considering how many projects die). It matters what you've been doing in the last 10-15 years. It's not about whose fault is or is not. It's about the state of things.
timbit42 6y ago
It's not that Windows has backward compatibility solved better than anyone. It's that they don't remove the old stuff. They only removed Win16 in the 64-bit versions of Windows so it was around for 20 years. Perhaps they will leave Win32 in until they come out with Win128.
- tomnipotent 6y ago
  > It's that they don't remove the old stuff What do you think backwards compatibility is?
nix23 6y ago
>Windows has backward compatibility solved better than anyone. I can still run 1990's code on Windows 10. Naa, especially old games work often better with wine then with Win10. I even can run DOS code from 1990 without any problems (trough dosbox)
- phendrenad2 6y ago
  That's true, games are the one area where Windows backward compatibility fails. Still much better than Linux overall though.
Ace17 6y ago
Backward compatibility isn't a technical issue, it's a political one. If only GNU/Linux systems have had half of Windows' marketshare, obviously some choices about breaking app-level compatibility would have been very different.

znpy 6y ago

> The WIN32 version, all that we've ever released, still work. Some of the older ones may not find old servers, but the code itself is functional. I feel you. I made pretty much this argument to a fellow GNU/Linux user (arch Linux user, if that adds anything). He started saying that syscalls are stable and that it's a gtk/GUI library problem and that if you were to, say, if you somehow loaded all the old libraries, it would work. Which might be true and everything, but come on. That's the equivalent of pushing your hands on your ears and shouting. Quite frankly, the thing that saves GNU Linux a bit is that windows is basically getting shittier and shittier at user experience.

loopz 6y ago
I recently compiled linux code from late 90s on Ubuntu. Apart from having to apt-get make utils and deprecated libs, it still worked, though with wrong server hosts. You may run into glibc, 64 bit vs 32 bit issues and the like, but lots of it is pretty compatible. Windows has its own legacy compatibility layers, though it is questionable if that's really a great idea.
- znpy 6y ago
  Yes, indeed, I do believe it's both feasible and true, but let's keep the discourse in the context of desktop usage and desktop users: could you really advice a regular user to go through all those steps? That's the point. In windows 99 times out of 100 you can just run the binary.
andor 6y ago
> He started saying that syscalls are stable and that it's a gtk/GUI library problem and that if you were to, say, if you somehow loaded all the old libraries, it would work. That's because no single organization can be blamed for the mess that is "GNU/Linux" ;-) Binary compatibility is very important for the kernel folks, but apparently much less so for maintainers of glibc and other libraries. As a workaround, binaries can be statically compiled, or bundled with all their dependencies. Flatpak and Snappy are two projects addressing this issue by packaging applications as containers.
- znpy 6y ago
  Congrats you missed the point too. When it comes to backward compatibility nobody cares what projects are starting today (and would care even less considering how many projects die). It matters what you've been doing in the last 10-15 years. It's not about whose fault is or is not. It's about the state of things.

timbit42 6y ago

It's not that Windows has backward compatibility solved better than anyone. It's that they don't remove the old stuff. They only removed Win16 in the 64-bit versions of Windows so it was around for 20 years. Perhaps they will leave Win32 in until they come out with Win128.

tomnipotent 6y ago
> It's that they don't remove the old stuff What do you think backwards compatibility is?

nix23 6y ago

>Windows has backward compatibility solved better than anyone. I can still run 1990's code on Windows 10. Naa, especially old games work often better with wine then with Win10. I even can run DOS code from 1990 without any problems (trough dosbox)

phendrenad2 6y ago
That's true, games are the one area where Windows backward compatibility fails. Still much better than Linux overall though.

Ace17 6y ago

Backward compatibility isn't a technical issue, it's a political one. If only GNU/Linux systems have had half of Windows' marketshare, obviously some choices about breaking app-level compatibility would have been very different.