Convert Linux to Windows

That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do.

It can also be achieved with static linking and by shipping all needed library and using a shell script loader that sets LD_LIBRARY_PATH.

Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an older Debian/Fedora that ships the needed libraries to the packaging repositories and running apt/dnf should work in theory, although unfortunately might not in practice due to the general incompetence of programmers and distribution maintainers.

Win32 is obviously not appropriate for GNU/Linux applications, and you also have the same dependency problem here, with the same solution (ship a whole Wine prefix, or maybe ship a bunch of DLLs).

Re: Convert Linux to Windows

#6

Post by mappu » Sat, Mar 29, 2025, 10:58 PM UTC

I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.

Re: Convert Linux to Windows

#7

Post by ranger_danger » Sat, Mar 29, 2025, 10:59 PM UTC

> NOTE: I am not against Apple or Microsoft. They have amazing engineers! I don't think they're being malicious. Rather, I think the incentives for these companies are improperly aligned.

Improperly aligned incentives? Who gets to say what that is?

Is it "improper" to maximize profit per their own board's guidelines?

I have a feeling OP has some predefined notion of nobility they expect people to somehow operate under.

Re: Convert Linux to Windows

#8

Post by voidspark » Sat, Mar 29, 2025, 11:05 PM UTC

ranger_danger wrote: post #7

> NOTE: I am not against Apple or Microsoft. They have amazing engineers! I don't think they're being malicious. Rather, I think the incentives for these companies are improperly aligned. Improperly aligned incentives? Who gets to say what that is? Is it "improper" to maximize profit per their own board's guidelines? I have a feeling OP has some predefined notion of nobility they expect people to somehow operate unde…

Yes it's a value judgement by the author. Maximizing profit by any means necessary is pathological. Many here would agree with that.

Re: Convert Linux to Windows

#9

Post by cyberax » Sat, Mar 29, 2025, 11:07 PM UTC

mappu wrote: post #6

I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.

There are few issues:

1. GNU libc is an exception in the world of compatibility.

2. You can't just dump a bunch of GTK libraries next to the binary and expect it to work. These libraries often expect very specific file system layouts.

Re: Convert Linux to Windows

#10

Post by api » Sat, Mar 29, 2025, 11:16 PM UTC

devit wrote: post #5

That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do. It can also be achieved with static linking and by shipping all needed library and using a shell script loader that sets LD_LIBRARY_PATH. Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in p…

> That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do.

True, but sad. The way to achieve compatibility on Linux is to distribute applications in the form of what are essentially tarballs of entire Linux systems. This is the "fuck it" solution.

Of course I suppose it's not unusual for Windows stuff to be statically linked or to ship every DLL with the installer "just in case." This is also a "fuck it" solution.