The next step is to isolate the Windows applications: you could use different WINEPREFIX, but I think the better way is to do it like android: one "user" per application.
It's not just to prevent applications to read other applications files, but also to firewall each application individually
For example, if you don't want the application you've mapped to user id 1001 to have any networking, use iptables with '-m owner --uid-owner 1001 -j DROP'
I moved from Windows to Linux a few years ago, I have a few Windows apps I still love a lot (mostly Word and Excel) and thanks to wine I will always be able to use them.
They are also extremely fast: cold starting Word (or Excel) on my laptop takes less than a second, and use far less RAM
Personally, I'd rather purchase a few shrink wrapped old versions of Office from ebay than bother with LibreOffice, Abiword or the online version of Office.
Is it just me or wine needs a bit more polish? Dialogs and menus are rendered with some weird microscopic font. GDI text rendering seemingly doesn't use font fallbacks, so even something like Scintilla or ebook reader don't quite work under wine.
Many commonly used Windows fonts are licensed under proprietary terms, preventing their inclusion with Wine.
Winetricks[1] can be used to acquire and install a set of default fonts directly from Microsoft.
Furthermore, Windows font fallback differs substantially from that of Linux and similar systems, which generally utilize Fontconfig and FreeType with font relationships defined in configuration files. In contrast, Windows (and consequently Wine) employs a font linking mechanism[2]. Windows handles font linking natively, whereas Wine requires manual registry configuration[3].
I don't think a new distro is needed. Most commonly used windows apps can be made to work through wine, but the hacks used to make one app work can break others and vice versa. Similarly, everyone needs to play around with settings individually to get things to work. What works on one person's machine might not work on another's, because there's no consistency in, effectively, configuration.
The simplest solution, to me, is to just distribute containers (or some other sandbox) with wine in it, and the necessary shenanigans to get the windows program (just the one) working in the container, and just distribute that. Everyone gets the same artifact, and it always works. No more dicking around with wine settings, because it's baked in for whatever the software is.
Yes, this is tremendously space inefficient, so the next step would be a way of slimming wine down for container usage.
The only real barrier to this system is licensing and software anti patterns. You might have to do some dark magic to install the software in the container in the first place.
TIL. I'm gonna check this out. It's good to see that people are already working on this, because it's one of those things that, to me, just makes a lot of sense. You'd think that with the all of the layers of abstraction we have nowadays, it should be possible to run software on any underlying system in an ergonomic fashion, even if it's not necessarily efficient.
I really like the idea of bottles. I wish there was a way to bundle that up into a distro and make it invisible to the user so I could setup my friends and family with it.
If you change a lot of things about a Linux system, then you're making a new distro.
Half of this incompatibility is because Linux is flexible, anyway. My system is different from your system, and did anyone test on both? If you want a more stable ABI then you need a more stable system.
You wouldn't have to change anything about the underlying system, which is the point. Containers work the same regardless of the underlying system, so they get around the various differences in everyone's individual machine. I use identical containers routinely on Fedora and Ubuntu systems at home without any issue, and I produce containers for RHEL and various other systems at work. Half the point of containers is eliminating the variability between dev systems and deployment.
Rather than everyone having to get the software working on their machine, you would get it working once in the container, and then just distribute that.
You could distribute Wine as a Flatpak platform. Flatpaks are already containers that run the same on all distros. Making a Win32 base that works in this same way using the same tooling would not be difficult.
>I don't think a new distro is needed. Most commonly used windows apps can be made to work through wine
I think the idea is to provide a seamless Windows like experience so the user works exact how he expects to work under Windows. Without having to fiddle, modify configurations, wrestle with different settings. Just click and run.
Yes, which is what I mentioned in the rest of the post. You could distribute a container that has wine in it, with just the configuration necessary to get the software working in the container. It would be straightforward to write a thin abstraction layer that pulls the container (installation) and gives you an executable that you can double click on and launch.
An end user wouldn't need to modify configs or wrestle settings, because that's already done for you upstream. You just get an artifact that you can click and run. From the other posts, Proton and Steam Deck already do something similar, and this is also conceptually similar to the way AppImages, Flatpaks etc. work.
It's possible to use docker as a package manager. I worked jobs where did exactly that, because we needed to compile certain dependencies for our application, and it streamlined the whole process.
There's zero reason you couldn't create a small abstraction layer around docker so you can install "executables" that are really just launching within a container. I mean, isn't that the whole idea behind flatpak, snaps, and appimages?
The point is to leverage modern abstraction techniques so that people don't need to learn a new system.
> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. There's no guarantee that it will be able to run based off some update that has happened
IMHO, you just compare two different things.
Traditional method of installing apps on Windows is packing all dynamic dependencies with it.
While on linux dynamic dependencies are shared between apps. So, there is nothing surprising that when you change the dependencies of the app, it stops working.
There are few ways to solve this and your are free to choose:
Aside from comparing two different things, as you correctly identify, I believe that even the author's original assertion just isn't true. Maybe for some exe files, but I doubt for all or even most.
I was involved in replacing Windows systems with Linux + Wine, because (mission-critical industrial) legacy software stopped working. No amount of tweaking could get it to work on modern Windows system. With Wine without a hitch, once all the required DLL files were tracked down.
While Wine may indeed be quite stable and a good solution for running legacy Windows software. I think that any dynamically linked legacy software can cause issues, both on Windows and Linux. Kernel changes may be a problem too. While Windows is often claimed to be backwards compatible, in practice your mileage may vary. Apparently, as my client found out the hard/expensive way.
> I was involved in replacing Windows systems with Linux + Wine, because (mission-critical industrial) legacy software stopped working. No amount of tweaking could get it to work on modern Windows system. With Wine without a hitch, once all the required DLL files were tracked down.
I moved from Windows 11 to Linux for the same reason: I was using an old version of Office because it was faster than the included apps: the full Word started faster than Wordpad (it was even on par with Notepad!) The Outlook from an old Office used less ram and was more responsive than the one included with Windows!
When I got a new laptop, I had problems with the installation of each the old versions of Office I had around, and there were rumors old versions Office would be blocked.
I didn't want to take the risk, so I started my migration.
> While Windows is often claimed to be backwards compatible, in practice your mileage may vary
It was perfectly backwards compatible: Windows was working fine with very old versions of everything until some versions of Windows 11 started playing tricks (even with a Pro license)
I really loved Windows (and AutoHotKey and many other things), but now I'm happy with Linux.
Well, there's always LD_PRELOAD and LD_LIBRARY_PATH on Linux. My experience has been that most of the time when older binaries fail to run, it's because they are linked against old versions of libraries, and when I obtain those library versions -- exactly the same as obtaining the DLLs for the Windows executable -- things usually work just fine.
You don't need to bundle anything from the system layer on Windows programs distributed as binaries. On Linux there is no proper separation of system libraries or optional libraries, everything could be both and there are no API / ABI guarantees. So "just bundle your dependencies" simply doesn't work. You cannot bundle Mesa, libwayland or GTK but you cannot fully depend them not breaking compatibility either.
On Windows side nobody bundles Windows GUI libraries, OpenGL drivers or sound libraries. On Linux side, system libs have to be somewhere in the container and you have to hope that it is still compatible.
You cannot link everything statically either. Starting with Glibc, there are many libraries that don't work fully or at all when statically linked.
I am sure this is true. But I seem to have had good results building static executables and libraries for C/C++ with cmake (which presumably passes -static to clang/gcc). golang also seems to be able to create static executables for my use cases.
Unless static linking/relinking is extremely costly, it seems unnecessary to use shared libraries in a top-level docker image (for example), since you have to rebuild the image anyway if anything changes.
Of course if you have a static executable, then you might be able to simplify - or avoid - things like docker images or various kinds of complicated application packaging.
Except that the "you" is different on each case. You're offering options for the distributor. The quote is talking about options for the user, who has to deal with whatever the distributor landed on. From the point of view of the user at the point of need, a distributor having choices that could have made their lives easier if they'd been picked some time in the past is completely useless.
I think it's not quite simple though. For one, I think the opengl driver situation is complex, where I hear you need userland per-hardware libraries which basically require dynamic linking. From that perspective windows binaries are the de-facto most stable way of releasing games on linux.
I'm not sure about linux syscall ABI stability either, or maybe other things that live in the kernel?
> I think the opengl driver situation is complex, where I hear you need userland per-hardware libraries which basically require dynamic linking
Yes. OpenGL driver is loading dynamically, but..
Are you sure that there are any problems with OpenGL ABI stability?
I have never hear about breaking changes in it
I was thinking the same thing. I've had loads of issues over the years when I have an archived EXE that gets angry about a missing DLL.
Likewise, as the author states, there's nothing intrinsic to Linux that makes it have binary compatibility issues. If this is a problem you face, and you're considering making a distro that runs EXEs by default through an emulation layer, you are probably much better off just using Alpine or one of the many other musl-based distros.
I need to buckle down and watch a YouTube video on this that gives examples. It obviously comes up in computer engineering all the time, but it's something I've been able to skate by without fully understanding; from time to time I see comments like this one that seem perfectly clear, but I'm sure there's still quite a lot of nuance that I could benefit from learning.
This is like the in-soviet-union joke about shouting "down with the US president" in front of the Kremlin. In this case, I too can run a 20 year old Windows binary on Linux wine.
The article's main premise isn't bad, but it's full of weird technical inaccuracies.
At certain points he talks about syscalls, libc (I'm assuming glibc), PE vs. ELF, and an 'ABI'. Those are all different things, and IIUC all are fairly stable on Linux, what isn't stable is userspace libraries such as GTK and QT. So, what are we talking about?
There's also statements like this, which, I'm not a kernel developer but they sound a little to good to be true:
> A small modification to the "exec" family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
He goes on to talk about Gatekeeper (which you can disable), Recall (which is disabled by default), and signing in with a Microsoft account (which can be easily bypassed, though he linked an article saying they might remove it). He also talks about "scanning your computer for illegal files", I don't know what this is referring to, but the only thing I could find on Google was Apple's iCloud CSAM scanning thing. That's not on your computer, and it got so much backlash that it was cancelled.
There's plenty of stuff to criticize about these companies and their services without being dramatic, and the idea of Linux having more compatibility with Win32 via Wine isn't bad.
> > There's also statements like this, which, I'm not a kernel developer but they sound a little to good to be true:
> A small modification to the "exec" family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
That isn't "too good to be true", it's so good it is false – no kernel modification is required because the Linux kernel already supports this via binfmt_misc. You just need to configure it. And depending on how you installed Wine, you may find it has even already been configured for you.
Lindows made a splash in 2001-2002 and its purpose was to bridge the gap and offer proper support for Windows applications on Linux via a 'click and run' service.
After Microsoft sued them and they changed their name, the bubble was burst and when Ubuntu appeared its niche as a beginner distro ebbed away.
I was surprised to hear it was still alive via a Michael MJD video a month or two ago.
> While the Linux syscalls themselves are very stable and reliable, the c library on top of them is not. Practically all of userland is based on libc, and therefore by proxy Linux itself has a binary compatibility problem.
People who primarily use Linux often forget that Windows has the exact same problem. In the case of Windows libc is distributed as part of the Visual C++ runtime. Each version of Visual Studio has its own version of the VC++ runtime and the application is expected to redistribute the version of VC++ it needs.
The only thing Windows does better is ensuring that they maintain backwards compatibility in libc until they release a new version of Visual Studio.
In Winapi land, the equivalent of "the c library" is NTDLL,its wrappers and other supporting libs (advapi32,userenv,etc... and Win32 specific libs which I consider equivalent to X11 libs). MSVCR in my opinion is there to provide the stdlib for C/C++ programs. In Linux land, the library that provides the C stdlib also wraps syscalls, in Windows, the C stdlib is a wrapper/interface for Windows api's.
My opinion is that they're both great. I really like how clean and well thought out the Windows API's are. Compared to Linux equivalents they're very stable and easier to use. But that doesn't mean there is anything wrong with C stdlib implementation on either OS. But for system API's, Linux is a bit messy, that mess is the result of having so many people have strong opinions, and Linux trying to adhere to the Unix principle of a modular user-space ecosystem.
For example, there is no "Linux graphics api", there is X11 and Wayland and who knows what else, and neither have anything to do with the Linux project. There are many highly opinionated ways to do simple things, and that is how Linux should be. In the same vein, installing apps on Linux is simply querying your package manager, but on Windows there is no "Microsoft package repo" where everyone dumps their apps (although they are trying to fix that in many ways), and that's how Windows should be.
Let Linux be Linux and Windows be Windows. They're both great if you appreciate them for what they are and use the accordingly.
>There are many highly opinionated ways to do simple things, and that is how Linux should be
I still believe we would be in a better place had BSD was ready for adoption before Linux. Linux is a kernel and a wide family of operating systems assembled from the kernel and different bits and pieces while BSD tried to be a very coherent operating system from the start.
I remember trying to get a program installed on Windows. It complained that I didn't have the right VC redistributable.
I had like ten of them installed — I think several from the same year! — cause every program usually bundles its own.
I found the exact version of vcredist installer I needed but then that one refused to install because I already had a slightly newer version. So I had to uninstall that first.
As far as I'm aware this problem still exists in Wine, I installed something in Wine yesterday and I had to use winetricks commands to get the vcredist installers from Microsoft's servers. (Also illegally download some fonts, otherwise my installer refused to start...)
Next time that happens, search "vcredist aio". I can't endorse any of the scripts that are out there but there are many scripts that will pull them from Microsoft and install them all with the unattended flag.
Is libc updates really the primary problem with the ABI breaks on Linux? Glibc isn't perfect but it has versioned symbols going back a long time now. My guess would be the problem is actually abandoned versions of other libraries (e.g. SDL1, old versions of gtk2?) and maybe a handful of other things.
Yeah, glibc is extremely stable and you can be sure that an app compiled against it now will work well into the future. People just completely ignore that fact based on hearsay, and that the removal of a unused symbol hashing table from the glibc binary broke a few anticheat systems that were attempting to parse it.
Other libraries are the problem, usually. People are generally really good about changing the .so version of a library when the ABI changes in a backwards-incompatible way. Usually distributions ship both versions until everything they ship either has upgraded or been removed. Solutions like appimage can allow you to ship these libraries in your app.
Someone comes along and builds their software on the latest bleeding-edge Linux distro. It won't run on older (or even many current) Linux desktops. People curse Linux ABI instability because new binaries aren't supported by an older operating system. It is in fact the opposite to the Windows situation, in which older software continues to run on newer operating systems, but good luck getting the latest Windows software to run on a Windows 95 desktop. People are very quick to conflate the two situations so they can score more fake internet points.
The situation is not limited to desktops. For example, a very popular commercial source forge web service does not work on browsers released more than about 10 weeks ago. The web itself has become fantastically unstable and almost unusable for anything except AI bots consuming what other AI bots spew.
This problem is related to the fact that Linux distos typically dynamically link executables and don’t retain older versions of those libraries vs Windows which does.
It’s on of the many reasons Windows base install is so much heavier than a typical Linux base install.
The reason Windows retains older versions of executables while Linux doesn’t is because Windows doesn’t have a package manager like Linux distros. Ok, there’s now Windows Store plus a recent-ish CLI tool that was based on one of the many unofficial package managers, but traditionally the way to install Windows application was via manual downloads and installs. So those installers would typically come bundled with any shared libraries they’d need and often have those shared libraries in the application directory. Leading to lots of duplication of libraries.
You could easily do the same thing in Linux too but there’s less of a need because Linux distribution package managers are generally really good. But some 3rd party package managers do take this kind of approach, eg Nix, Snap, etc.
So it’s not that Linux is “unstable” but more that people have approached the same problem on Linux in a completely different way.
The fact that drag-and-drop installs work on macOS demonstrates that there isn’t really a UNIX-like limitation preventing Windows-style installs. It’s more that Linux distributions prefer a different method for application installation.
It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades.
As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. To run this on a modern Linux system, you need to:
- Bump vm.mmap_min_addr from 65536 down to 4096, a privileged operation ;
- Use an a.out loader because the Linux kernel dropped support for a.out back in 2022 ;
- Possibly use qemu-user if your system doesn't support 32-bit x86.
That's the best-case scenario, because some of the old Atari Jaguar SDK Linux binaries are dynamically-linked a.out executables and you're basically stuck running ancient Linux kernels in a VM. It's at a point where someone at the AtariAge forums was seriously considering using my delinking black magic to port some of these old programs to modern Linux. It's quite telling when reverse-engineering an executable with Ghidra in order to export relocatable object files to relink (with some additional steps I won't get into) is even an option on the table.
Sure, given enough determination and piles of hacks you can probably forcefully run any old random Linux program on modern systems, but odds are that Windows (or Wine or ReactOS) will manage to run a 32-bit x86 PE program from thirty years ago with minimal compatibility tweaks. Linux (both distributions and to a lesser degree the kernel) simply don't care about that use-case, to the point where I'd be pleasantly surprised if anyone manages to run Tux the Penguin: A Quest for Herring as-is on a modern system.
> It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades.
That’s exactly what dynamically linked executables are: user land
> As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable.
That’s not a user land problem. That’s a CPU architecture problem. Windows solves this WOW64 which provides a compatibility layer for 32bit pointers et al.
There are 32bit compatibility layers for Linux too but they’re. It going to be going to help if you’re running an a.out file because it’s a completely different type of executable format (ie not equivalent to a 32bit statically compiled ELF).
Windows has a similar problem with COM files (the early DOS executable format). And lots of COM executables on Windows don’t work either. Windows solves this problem with emulation, which you can do on Linux too. The awkward part of Linux here is that it doesn’t ship those VMs as part of its base install, but why would it because almost no one is trying to run randomly downloaded 32bit a.out files.
To be clear, I’m not arguing that Linuxes backwards compatibility story is as good as Windows. It clearly isn’t. But the answer to that isn’t because Linux can’t be backwards compatible, it’s because Linux traditionally hasn’t needed to be. However all of the same tools Windows uses for it’s compatibility story are available to Linux for Linux executables too.
I never suggested it was a bad thing. I was just explaining the differences.
However to answer your question:
Storage hasn’t always been cheap. So it used to be a bad thing. Theses days, as you rightly said, it’s less of an issue.
But if you do want to focus on present day then it’s worth noting that these days FOSS does ship a lot of dependencies as part of their releases. Either via Docker containers, Nix packages, or static binaries (eg Go, Rust, etc). And they do this precisely because the storage cost is worth the convenience.
I've read the article and the comments with interest. I just have a question: if Windows ABI is so stable that 20-year-old programs are guaranteed to run, why are there computers with Win95 or NT that nobody dares touching lest some specific software stops working? I see plenty of these in industrial environments, but also in public libraries, corporate databases, etc.
In practice most of those machines are an environment in and of themselves. It’s not that they can’t be upgraded, it’s that they likely couldn’t even be rebuilt if they had a hardware failure. The risk they’re taking is that the system is more likely to break due to being touched than it is to suffer a hardware failure. Which as most of us can attest to, is true until it’s not.
Relatedly, at a previous job we ran an absolutely ancient piece of software that was critical to our dev workflow. The machine had an issue of some sort, so someone imaged the hard drive, booted it as a VM and we resumed business as usual. Last I heard it was still running untouched, and unmaintained.
> if Windows ABI is so stable that 20-year-old programs are guaranteed to run
That's not actually true; there are no guarantees. Microsoft does a best effort to ensure the majority of applications continue to work. But there are billions of applications, they're not all going to work. Many applications don't even adhere to the Win32 API properly. Microsoft will sometimes, if the app is important enough, ensure even misbehaving applications work properly.
I know in my use case all these ancient machines are nessessary for interacting with some ancient hardware, not a case where wine is particularly useful.
why touch it? these are usually not directly connected to the internet. some possibly virtualized. "updating" to use wine on linux is a ton of work on its own, you will run into unforseeable issues. nobody wants to pay for that and nobody wants to be responsible for the problems when the net benefit is zero.
but a real update/replacement of all these systems is too expensive, hence the status quo.
They care to a certain degree, and that degree is the size of the carefully-tuned payment that Trend Micro extract for the firewall product that lets the Windows 2000 MRI machine safely co-exist on the network with the hospital DC.
Readit News
On Debian you're one package away:
Otherwise you're still pretty close:It's not just to prevent applications to read other applications files, but also to firewall each application individually
For example, if you don't want the application you've mapped to user id 1001 to have any networking, use iptables with '-m owner --uid-owner 1001 -j DROP'
I moved from Windows to Linux a few years ago, I have a few Windows apps I still love a lot (mostly Word and Excel) and thanks to wine I will always be able to use them.
They are also extremely fast: cold starting Word (or Excel) on my laptop takes less than a second, and use far less RAM
Personally, I'd rather purchase a few shrink wrapped old versions of Office from ebay than bother with LibreOffice, Abiword or the online version of Office.
EDIT: I can't find the old recording I made showing how fast it was, but here's what it looks like on my hypland desktop: you can see in btop it doesn't take much resources https://www.reddit.com/r/unixporn/comments/11w3zzj/hyprland_...
Winetricks[1] can be used to acquire and install a set of default fonts directly from Microsoft.
Furthermore, Windows font fallback differs substantially from that of Linux and similar systems, which generally utilize Fontconfig and FreeType with font relationships defined in configuration files. In contrast, Windows (and consequently Wine) employs a font linking mechanism[2]. Windows handles font linking natively, whereas Wine requires manual registry configuration[3].
[1] https://github.com/Winetricks/winetricks
[2] https://learn.microsoft.com/en-us/globalization/fonts-layout...
[3] https://stackoverflow.com/questions/29028964/font-recognitio...
It's just you. I set up the DPI and high res option to run old Office apps, and they have very nice fonts both on my 2k laptop 4k screen.
Try `xprop -root -f _XWAYLAND_GLOBAL_OUTPUT_SCALE 32c -set _XWAYLAND_GLOBAL_OUTPUT_SCALE 2`
The simplest solution, to me, is to just distribute containers (or some other sandbox) with wine in it, and the necessary shenanigans to get the windows program (just the one) working in the container, and just distribute that. Everyone gets the same artifact, and it always works. No more dicking around with wine settings, because it's baked in for whatever the software is.
Yes, this is tremendously space inefficient, so the next step would be a way of slimming wine down for container usage.
The only real barrier to this system is licensing and software anti patterns. You might have to do some dark magic to install the software in the container in the first place.
https://support.codeweavers.com/en_US/2-getting-started/2-in...
I believe it started with Cedega, but I could be wrong. That's where I first recall encountering it.
Half of this incompatibility is because Linux is flexible, anyway. My system is different from your system, and did anyone test on both? If you want a more stable ABI then you need a more stable system.
Rather than everyone having to get the software working on their machine, you would get it working once in the container, and then just distribute that.
I think the idea is to provide a seamless Windows like experience so the user works exact how he expects to work under Windows. Without having to fiddle, modify configurations, wrestle with different settings. Just click and run.
An end user wouldn't need to modify configs or wrestle settings, because that's already done for you upstream. You just get an artifact that you can click and run. From the other posts, Proton and Steam Deck already do something similar, and this is also conceptually similar to the way AppImages, Flatpaks etc. work.
> but the hacks used to make one app work can break others and vice versa
I think a lot of these problems could be avoided with a singular OS with the sole goal to support windows exes.
There's zero reason you couldn't create a small abstraction layer around docker so you can install "executables" that are really just launching within a container. I mean, isn't that the whole idea behind flatpak, snaps, and appimages?
The point is to leverage modern abstraction techniques so that people don't need to learn a new system.
IMHO, you just compare two different things. Traditional method of installing apps on Windows is packing all dynamic dependencies with it. While on linux dynamic dependencies are shared between apps. So, there is nothing surprising that when you change the dependencies of the app, it stops working.
There are few ways to solve this and your are free to choose:
- distribute the same as on Windows
- link statically
I was involved in replacing Windows systems with Linux + Wine, because (mission-critical industrial) legacy software stopped working. No amount of tweaking could get it to work on modern Windows system. With Wine without a hitch, once all the required DLL files were tracked down.
While Wine may indeed be quite stable and a good solution for running legacy Windows software. I think that any dynamically linked legacy software can cause issues, both on Windows and Linux. Kernel changes may be a problem too. While Windows is often claimed to be backwards compatible, in practice your mileage may vary. Apparently, as my client found out the hard/expensive way.
I moved from Windows 11 to Linux for the same reason: I was using an old version of Office because it was faster than the included apps: the full Word started faster than Wordpad (it was even on par with Notepad!) The Outlook from an old Office used less ram and was more responsive than the one included with Windows!
When I got a new laptop, I had problems with the installation of each the old versions of Office I had around, and there were rumors old versions Office would be blocked.
I didn't want to take the risk, so I started my migration.
> While Windows is often claimed to be backwards compatible, in practice your mileage may vary
It was perfectly backwards compatible: Windows was working fine with very old versions of everything until some versions of Windows 11 started playing tricks (even with a Pro license)
I really loved Windows (and AutoHotKey and many other things), but now I'm happy with Linux.
On Windows side nobody bundles Windows GUI libraries, OpenGL drivers or sound libraries. On Linux side, system libs have to be somewhere in the container and you have to hope that it is still compatible.
You cannot link everything statically either. Starting with Glibc, there are many libraries that don't work fully or at all when statically linked.
Unless static linking/relinking is extremely costly, it seems unnecessary to use shared libraries in a top-level docker image (for example), since you have to rebuild the image anyway if anything changes.
Of course if you have a static executable, then you might be able to simplify - or avoid - things like docker images or various kinds of complicated application packaging.
I'm not sure about linux syscall ABI stability either, or maybe other things that live in the kernel?
Yes. OpenGL driver is loading dynamically, but.. Are you sure that there are any problems with OpenGL ABI stability? I have never hear about breaking changes in it
Likewise, as the author states, there's nothing intrinsic to Linux that makes it have binary compatibility issues. If this is a problem you face, and you're considering making a distro that runs EXEs by default through an emulation layer, you are probably much better off just using Alpine or one of the many other musl-based distros.
At certain points he talks about syscalls, libc (I'm assuming glibc), PE vs. ELF, and an 'ABI'. Those are all different things, and IIUC all are fairly stable on Linux, what isn't stable is userspace libraries such as GTK and QT. So, what are we talking about?
There's also statements like this, which, I'm not a kernel developer but they sound a little to good to be true:
> A small modification to the "exec" family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
He goes on to talk about Gatekeeper (which you can disable), Recall (which is disabled by default), and signing in with a Microsoft account (which can be easily bypassed, though he linked an article saying they might remove it). He also talks about "scanning your computer for illegal files", I don't know what this is referring to, but the only thing I could find on Google was Apple's iCloud CSAM scanning thing. That's not on your computer, and it got so much backlash that it was cancelled.
There's plenty of stuff to criticize about these companies and their services without being dramatic, and the idea of Linux having more compatibility with Win32 via Wine isn't bad.
> A small modification to the "exec" family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
That isn't "too good to be true", it's so good it is false – no kernel modification is required because the Linux kernel already supports this via binfmt_misc. You just need to configure it. And depending on how you installed Wine, you may find it has even already been configured for you.
https://www.linspirelinux.com/
After Microsoft sued them and they changed their name, the bubble was burst and when Ubuntu appeared its niche as a beginner distro ebbed away.
I was surprised to hear it was still alive via a Michael MJD video a month or two ago.
People who primarily use Linux often forget that Windows has the exact same problem. In the case of Windows libc is distributed as part of the Visual C++ runtime. Each version of Visual Studio has its own version of the VC++ runtime and the application is expected to redistribute the version of VC++ it needs.
The only thing Windows does better is ensuring that they maintain backwards compatibility in libc until they release a new version of Visual Studio.
My opinion is that they're both great. I really like how clean and well thought out the Windows API's are. Compared to Linux equivalents they're very stable and easier to use. But that doesn't mean there is anything wrong with C stdlib implementation on either OS. But for system API's, Linux is a bit messy, that mess is the result of having so many people have strong opinions, and Linux trying to adhere to the Unix principle of a modular user-space ecosystem.
For example, there is no "Linux graphics api", there is X11 and Wayland and who knows what else, and neither have anything to do with the Linux project. There are many highly opinionated ways to do simple things, and that is how Linux should be. In the same vein, installing apps on Linux is simply querying your package manager, but on Windows there is no "Microsoft package repo" where everyone dumps their apps (although they are trying to fix that in many ways), and that's how Windows should be.
Let Linux be Linux and Windows be Windows. They're both great if you appreciate them for what they are and use the accordingly.
> Let Linux be Linux and Windows be Windows. They're both great if you appreciate them for what they are and use the accordingly.
What if you technically prefer the Windows way, but are worried about Microsoft's behavior related to commercial strategy, lock-down, privacy...?
The author envisions a system that's technically stable as Windows, yet free as Linux.
I still believe we would be in a better place had BSD was ready for adoption before Linux. Linux is a kernel and a wide family of operating systems assembled from the kernel and different bits and pieces while BSD tried to be a very coherent operating system from the start.
I had like ten of them installed — I think several from the same year! — cause every program usually bundles its own.
I found the exact version of vcredist installer I needed but then that one refused to install because I already had a slightly newer version. So I had to uninstall that first.
As far as I'm aware this problem still exists in Wine, I installed something in Wine yesterday and I had to use winetricks commands to get the vcredist installers from Microsoft's servers. (Also illegally download some fonts, otherwise my installer refused to start...)
Other libraries are the problem, usually. People are generally really good about changing the .so version of a library when the ABI changes in a backwards-incompatible way. Usually distributions ship both versions until everything they ship either has upgraded or been removed. Solutions like appimage can allow you to ship these libraries in your app.
Someone comes along and builds their software on the latest bleeding-edge Linux distro. It won't run on older (or even many current) Linux desktops. People curse Linux ABI instability because new binaries aren't supported by an older operating system. It is in fact the opposite to the Windows situation, in which older software continues to run on newer operating systems, but good luck getting the latest Windows software to run on a Windows 95 desktop. People are very quick to conflate the two situations so they can score more fake internet points.
The situation is not limited to desktops. For example, a very popular commercial source forge web service does not work on browsers released more than about 10 weeks ago. The web itself has become fantastically unstable and almost unusable for anything except AI bots consuming what other AI bots spew.
But they are installed side-by-side, major versions at least.
Deleted Comment
Falling that, run inside a container
It’s on of the many reasons Windows base install is so much heavier than a typical Linux base install.
The reason Windows retains older versions of executables while Linux doesn’t is because Windows doesn’t have a package manager like Linux distros. Ok, there’s now Windows Store plus a recent-ish CLI tool that was based on one of the many unofficial package managers, but traditionally the way to install Windows application was via manual downloads and installs. So those installers would typically come bundled with any shared libraries they’d need and often have those shared libraries in the application directory. Leading to lots of duplication of libraries.
You could easily do the same thing in Linux too but there’s less of a need because Linux distribution package managers are generally really good. But some 3rd party package managers do take this kind of approach, eg Nix, Snap, etc.
So it’s not that Linux is “unstable” but more that people have approached the same problem on Linux in a completely different way.
The fact that drag-and-drop installs work on macOS demonstrates that there isn’t really a UNIX-like limitation preventing Windows-style installs. It’s more that Linux distributions prefer a different method for application installation.
As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. To run this on a modern Linux system, you need to:
- Bump vm.mmap_min_addr from 65536 down to 4096, a privileged operation ;
- Use an a.out loader because the Linux kernel dropped support for a.out back in 2022 ;
- Possibly use qemu-user if your system doesn't support 32-bit x86.
That's the best-case scenario, because some of the old Atari Jaguar SDK Linux binaries are dynamically-linked a.out executables and you're basically stuck running ancient Linux kernels in a VM. It's at a point where someone at the AtariAge forums was seriously considering using my delinking black magic to port some of these old programs to modern Linux. It's quite telling when reverse-engineering an executable with Ghidra in order to export relocatable object files to relink (with some additional steps I won't get into) is even an option on the table.
Sure, given enough determination and piles of hacks you can probably forcefully run any old random Linux program on modern systems, but odds are that Windows (or Wine or ReactOS) will manage to run a 32-bit x86 PE program from thirty years ago with minimal compatibility tweaks. Linux (both distributions and to a lesser degree the kernel) simply don't care about that use-case, to the point where I'd be pleasantly surprised if anyone manages to run Tux the Penguin: A Quest for Herring as-is on a modern system.
That’s exactly what dynamically linked executables are: user land
> As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable.
That’s not a user land problem. That’s a CPU architecture problem. Windows solves this WOW64 which provides a compatibility layer for 32bit pointers et al.
There are 32bit compatibility layers for Linux too but they’re. It going to be going to help if you’re running an a.out file because it’s a completely different type of executable format (ie not equivalent to a 32bit statically compiled ELF).
Windows has a similar problem with COM files (the early DOS executable format). And lots of COM executables on Windows don’t work either. Windows solves this problem with emulation, which you can do on Linux too. The awkward part of Linux here is that it doesn’t ship those VMs as part of its base install, but why would it because almost no one is trying to run randomly downloaded 32bit a.out files.
To be clear, I’m not arguing that Linuxes backwards compatibility story is as good as Windows. It clearly isn’t. But the answer to that isn’t because Linux can’t be backwards compatible, it’s because Linux traditionally hasn’t needed to be. However all of the same tools Windows uses for it’s compatibility story are available to Linux for Linux executables too.
Is that a bad thing if it means a seamless experience for users? Storage is cheap.
However to answer your question:
Storage hasn’t always been cheap. So it used to be a bad thing. Theses days, as you rightly said, it’s less of an issue.
But if you do want to focus on present day then it’s worth noting that these days FOSS does ship a lot of dependencies as part of their releases. Either via Docker containers, Nix packages, or static binaries (eg Go, Rust, etc). And they do this precisely because the storage cost is worth the convenience.
Relatedly, at a previous job we ran an absolutely ancient piece of software that was critical to our dev workflow. The machine had an issue of some sort, so someone imaged the hard drive, booted it as a VM and we resumed business as usual. Last I heard it was still running untouched, and unmaintained.
That's not actually true; there are no guarantees. Microsoft does a best effort to ensure the majority of applications continue to work. But there are billions of applications, they're not all going to work. Many applications don't even adhere to the Win32 API properly. Microsoft will sometimes, if the app is important enough, ensure even misbehaving applications work properly.