by pbohun on 3/29/25, 9:34 PM with 452 comments
by notfed on 3/30/25, 3:52 AM
On Debian you're one package away:
sudo apt install wine-binfmt
echo 'none /proc/sys/fs/binfmt_misc binfmt_misc defaults 0 0' >> /etc/fstab
mount -a
echo ':DOSWin:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/registerby coderenegade on 3/30/25, 12:11 AM
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.
by feelamee on 3/30/25, 11:13 AM
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
by subjectsigma on 3/29/25, 11:24 PM
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.
by petepete on 3/29/25, 10:44 PM
by CrossVR on 3/30/25, 5:04 AM
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.
by hnlmorg on 3/30/25, 10:55 AM
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.
by teo_zero on 3/30/25, 8:49 AM
by evanextreme on 3/30/25, 4:45 PM
by mappu on 3/29/25, 10:58 PM
by nneonneo on 3/29/25, 11:29 PM
by II2II on 3/30/25, 1:48 AM
I think it's fair to say that OS/2 had better Windows compatibility (for it's era) than Wine offers (in this era). The problem was that Microsoft introduced breaking changes with the introduction of Windows 95. While old Windows applications would continue to run under OS/2, IBM felt that it would take too much effort to introduce a compatability layer for Windows 95. If I recall correctly, it involved limitations with how OS/2 handled memory.
Besides, binary compatibity has never really been a big thing in Linux since the majority of software used is open source. It is expected to compile and link against newer libraries, but there is no real incentive for existing binaries to remain compatible. And if the software doesn't compile against newer versions of libraries, well, Windows has similar issues.
by ajross on 3/29/25, 11:42 PM
by devit on 3/29/25, 10:57 PM
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).
by win32lover on 3/30/25, 12:23 AM
by 999900000999 on 3/30/25, 5:02 AM
You can run non games on Proton. Most things work.
by d3Xt3r on 3/29/25, 10:53 PM
by thatjazz on 3/30/25, 1:11 PM
Why, oh why, I have to deal with exe files that are not even 5 years old and don't work on my windows laptop after update... I wish I lived in Author's universe...
by flohofwoe on 3/30/25, 10:06 AM
> In Windows, you do not make system calls directly, Instead, you dynamically link to libraries that make the system calls for you.
Isn't the actual problem the glibc shared library since the Linux syscall interface is stable? (as promised by "don't break user space") - e.g. I would expect that I can take a 20 years old Linux binary which only does syscalls and run that on a modern Linux, is that assumption wrong?
ABI stability for Windows system DLLs is also only one aspect, historically Microsoft has put a ton of effort into preserving backward compatibility for popular applications even if they depend on bugs in Windows that had been fixed in later Windows versions.
I expect that Windows is full of application specific hacks under the hood to make specific old applications work.
E.g. just using WINE as the desktop Linux API won't be enough, you'll also have to extend the "don't break user space" promise from the kernel to the desktop runtime environment, even if it means "bug-by-bug-compatibility" with older versions.
by lucasoshiro on 3/29/25, 11:59 PM
Why not use ReactOS?
by hugo1789 on 3/30/25, 11:47 AM
by bentt on 3/30/25, 2:11 AM
I am hopeful SteamOS will bring us something very similar.
by foxes on 3/30/25, 5:49 AM
by jchw on 3/30/25, 7:17 AM
However, I also think that we could "solve" a lot of the compatibility problems.
There are tons of old Linux binaries that don't work anymore. But... They could. A lot of old binaries, surely the vast majority, could absolutely run on a modern kernel. The problem is the userspace. The binaries themselves contain oodles of information that could be used to figure out what they need to run, it's just that there's nothing in place to try to make sure that stuff is available.
I really believe we could make it possible for a distro, out of the box, to make old binaries "just work", double-click and run. Want to install an old game from an .rpm or .deb you have? The system could identify what base OS that is and install it into it's own chroot with its dependencies, then create desktop icons for it. Execution failures? Missing libraries? Xlib errors? Let's have a graphical error message with actionable help.
Well, it could be done, anyway. If you wanted to follow the spirit of Windows here, it would be the right thing to do, and it'd help users who found a thing that says it supports "Linux" run that thing the way they would hope and expect it to run. Will it actually happen? Not unless someone makes it happen, and convinces distros, desktops and all other stakeholders it's worth shipping, then maintains and improves it going forward. It's a bit depressing when you realize that the technical part of implementing this is basically the least challenging part, at least for a proof of concept.
by t43562 on 3/30/25, 10:53 AM
You can provide backwards compatibility in Linux - you can keep old versions of libraries installed. The more commercial distros do this to a greater degree. It's roughly what windows is doing to achieve the same result.
It's just a cost to arrange and since most distros aren't making billions in licensing they choose not to pay it.
Obviously I have nothing against a wine-focused distro but I wouldn't myself waste a fraction of a second writing code against the windows API by choice.
by Levitating on 3/30/25, 2:12 AM
Doesn't static compilation solve quite a few of the problems states here?
by cyp0633 on 3/30/25, 1:53 AM
by 1970-01-01 on 3/30/25, 2:12 PM
Imagine we made a new shade of brown
Seriously, this is the most cliché thing you could do with Linux.
by delusional on 3/29/25, 11:23 PM
Are you high? There is nothing simple about Wine. It's at once a kludgy mess and a technical masterpiece, what it isn't is simple.
by marcodiego on 3/30/25, 4:36 AM
AppImages are very close to fixing this. I'm not sure if it is already solved or very close to.
by nunobrito on 3/30/25, 4:54 PM
I'm saying this as Java developer. Delphi eventually proved itself to be the true "compile once, run everywhere". Can imagine others who wrote executables for Windows before the .NET times can relate to similar experiences.
by a3w on 3/30/25, 10:07 AM
Barely - most bigger programs did not adhere to all standards, but got custom fixes under the hood in follow-up windows versions.
Also, around 2001 was the big architectural change for desktop from DOS to NT, so this might seem like cherry-picking the timeframe selected.
by nurettin on 3/30/25, 4:01 AM
I do that all the time. Just link to a static glibc or musl.
by alphazard on 3/30/25, 3:34 AM
Maybe just don't use that library then? Or don't do that ridiculous thing where you fumble around at runtime desperately looking for executable pages that should just be included in your binary.
by graemep on 3/30/25, 10:43 AM
Some of these have a long history: https://en.wikipedia.org/wiki/Linspire
They have never been all that successful.
I suspect there is not enough overlap between people who want to use Linux and people who need to run Windows apps that badly for it to be viable.
The biggest problem is games, and even with Steam's best efforts not all Windows games will run on Linux, AFAIK.
by xtracto on 3/30/25, 12:52 AM
I run Mint as my main OS, but hardware compatibility is still a headache in Linux for me.
by DeathArrow on 3/30/25, 8:26 AM
Just transforming Windows syscalls into Linux syscalls is not enough. There should be some form of emulation involved.
Many apps, like games are using hardware, that means some additional layers of emulation.
>Imagine we made a new Linux distro. This distro would provide a desktop environment that looks close enough to Windows that a Windows user could use it without training. You could install and run Windows applications exactly as you do on Windows; no extra work needed.
I a rough user experience, some loss of performance and many bugs.
But I hope I am wrong, because the idea sounds really promising.
by James_K on 3/30/25, 2:18 AM
by quotemstr on 3/30/25, 3:56 PM
Precisely correct. Linux should never have allowed system calls from outside libc or a big vdso.
by DeathArrow on 3/30/25, 8:48 AM
They seem to not be interested in locking the hardware and they don't make much money from selling Windows and it shows. There aren't many strong improvements in Windows and it feels like Windows is a platform they use to sell other stuff they make money with - they are with Windows in a similar position Google is with Android.
by amelius on 3/30/25, 9:50 AM
Can't we freeze the functionality of libc? Why does it need to be updated so frequently?
And even if we make changes to its implementation, why do we need to bump the version number if the underlying API is still the same?
by kazinator on 3/30/25, 2:14 AM
Sure, but for how much longer will Microsoft allow this unsigned ancient binary?
Using Linux for runing Windows programs is going to be desperately needed as Microsoft enshittifies Windows going forward.
by shmerl on 3/30/25, 2:45 AM
Someone should develop an analog for Linux itself. I.e. support for older / historic ABIs that would be translated into whatever modern Linux has.
Some isolated example of that is SDL 1.x translated to SDL 2.
Wine itself already exists, you don't need to develop any new distro for running Windows programs on Linux. Just improve Wine if anything is missing.
by artemonster on 3/30/25, 6:23 PM
Or, in other words, "We can solve any problem by introducing an extra level of indirection."
by pizlonator on 3/29/25, 11:17 PM
by blueflow on 3/30/25, 7:44 PM
On Linux, you are supposed to share the source code, not the binaries. FOSS source is easier to fix than a binary blob. This is why the FSF exists.
by adham-omran on 3/30/25, 3:07 PM
by pkulak on 3/30/25, 5:57 AM
by tex0 on 3/30/25, 8:59 AM
by vednig on 3/30/25, 6:40 AM
I've also reached a similar conclusion while building ZeeeroOS from scratch.
There's also Fat binaries(arch independent) that should be considered but no one does when building for Linux.
by DrNosferatu on 4/3/25, 9:26 AM
(ie.: only fairly old versions of MsOffice work on Wine)
by DeathArrow on 3/30/25, 8:35 AM
by DeathArrow on 3/30/25, 8:33 AM
by 0xDEAFBEAD on 3/30/25, 3:41 PM
by darkwater on 3/30/25, 6:55 AM
by avodonosov on 3/30/25, 11:16 PM
by pjmlp on 3/30/25, 5:45 AM
by neiesc on 3/30/25, 11:53 AM
by throwaway48476 on 3/30/25, 8:16 AM
by jabedude on 3/30/25, 4:17 PM
This is a lie. Gatekeeper in no way limits the software you can run. It presents an easier experience to launch software downloaded from a browser if the developer chose to submit it to apple for a malware scan.
by James_K on 3/30/25, 2:12 AM
by Asooka on 3/30/25, 1:35 PM
Like just for the audio stack we had: OSS is deprecated so use ALSA actually direct ALSA device access is deprecated use this special ALSA config with a bunch of plugins actually directly calling ALSA is deprecated use aRts actually aRts only works on KDE use ESD actually ESD is deprecated use pulseaudio actually pulseaudio uses too much CPU rewrite everything to use JACK actually JACK is only for audio workstations go back to pulseaudio actually pulseaudio is deprecated switch to pipewire... I am pretty sure in 6 months I will be reading how pipewire is deprecated and the new definitely final form of the Linux audio stack will be emerging (written in a combination of Rust and Emacs Lisp).
In short, Linux binary compatibility is a clownshow and the OS itself isn't engineered for developing graphical desktop applications. We should stop pretending it is and compile everything user-facing for Win32 ABI, with maybe a tiny extension here and there.
by DrNosferatu on 4/3/25, 9:22 AM
by caspper69 on 3/30/25, 4:13 AM
I use Windows. In fact, I like Windows. I know lots of (ok, more than 5) greybeards who feel exactly the same way. I don't want Linux to be Windows, but I also don't want Linux on my personal desktop either.
I have a Mac Mini M1 on my desk, and I use that for the things it's good for, mainly videoconferencing. It's also my secondary Adobe Creative Suite machine.
On my Win11 desktop, I have WSL2 with Ubuntu 24.04 for the things it is good for- currently that's Python, SageMath, CUDA, and ffmpeg. For my Unix fix, I use Git Bash (MSYS2) for my "common, everyday Unix-isms" on Windows.
I also use PowerShell and Windows Scripting on my box when I need to.
Why? Well, firstly, it's easy and I've got stuff to do. Secondly, cost is not really an issue- I bought my Windows Pro license back with Win7, and it was about $180. That was maybe 15 years ago. They have graciously upgraded me at every step- Win7 -> Win10 -> Win11, all at no cost. Even if I had had to buy it, my Taco Bell tab is higher in any given month than a Windows license (love that inflation).
Why else? Everything works. I get no annoying popups, and I really no longer sweat garbage living on my drive, because that ship has sailed; wanna waste 50GB? Sure, go ahead.
But the most important reason? My hardware is supported. My monitors look great; printers, scanners, mice and USB drives & keys all work. In fact, >90% of the time, everything just works. Further, I can share effortlessly with my Mac, all my Linux servers speak SMB (CIFS), Wireshark works, and my programs are all supported including most open source software. And I do run apps that are 20+ years old from time to time.
Truth be told, I have tried the dance of daily driving Linux, and it's a laundry list of explanations to others why my stuff is different or deficient in some way. The kicker is that my clients don't care about purity or coolness factors.
Linux has its place. But please don't put in on my main machine, and please don't give it to my family members. They're only being nice by living with a sub-par desktop experience. It will always take a herculean effort to stay on par with Windows or MacOS, and no one really wants to put their money where their mouth is.
Please don't misunderstand. I admire and respect authors of open source software, and my servers thank them. But being a contrarian and dogfooding what KDE and GNOME put out, fighting with Nvidia and AMD, dealing with constant driver interface changes, and not having proper commercial software support is not my idea of fun. It was 30 years ago. Today? I'd rather hang with my daughter or write some code.
These distros have had 35 years. I don't know what else to say.
by Perenti on 3/30/25, 1:28 AM
by prkl on 3/30/25, 7:41 AM
by feverzsj on 3/30/25, 4:51 AM
by nxobject on 3/30/25, 12:50 AM
by leni536 on 3/30/25, 10:19 AM
by notorandit on 3/30/25, 9:24 AM
How this can be considered a good thing?
by zoezoezoezoe on 4/1/25, 3:51 PM
What?? I've used Linux for quite a while, and I've had a very good experience with software. I struggle to follow what they're talking about, Linux works just fine. Using Windows software is also pretty easy and like many people have already mentioned wine-binfmt is basically what this article is describing.
by gmuslera on 3/30/25, 12:41 AM
by adamtaylor_13 on 3/30/25, 12:53 AM
Sure I believe backwards compatibility is a nice to have feature, but I have never, nor do I think I will ever, have a need to run 20-year-old software.
by worthless-trash on 3/30/25, 4:44 AM
Good luck with the hellscape you're building.
by frackintoaster on 3/30/25, 8:27 AM
by timeon on 3/30/25, 1:15 AM
by mrbluecoat on 3/30/25, 12:13 AM
How many missiles do you know that run Windows?
by timewizard on 3/30/25, 4:44 AM
I do it all the time. Works fine. Do you have a specific example or is this just a hastily constructed strawman?
by ranger_danger on 3/29/25, 10:59 PM
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.
by pdonis on 3/30/25, 1:29 AM
by olddustytrail on 3/29/25, 11:18 PM
"We should"? Do you mean me? I have a ton of my own projects I'm busy with.
Why didn't you say "I should create..."? There's nothing stopping you implementing this if you think it's a good idea. Do the work yourself.
by magackame on 3/30/25, 1:37 AM