Convert Linux to Windows
2025-03-29
Thesis: We should create a distro of Linux that runs Windows binaries by default via Wine.
The Linux Environment is Unstable
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.
There’s also no guarantee that a binary produced today on Linux will even work on the various distributions of Linux today due to the same installed library version problem.
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.
Binary Distribution is a Problem
Because of the problems listed above (and more), there is no good way to distribute binaries for Linux.
There are four (yes four!) major ways to distribute binaries, and they all have problems:
- The raw binary. If this worked, we wouldn’t need the other solutions.
- AppImage. Completely self-contained artifact that bundles all dependencies in with the binary.
- Flatpak. A package manager that provides a sandbox for each application.
- Snaps. Yet another package manager that runs applications in a sandbox.
There are even more ways of distributing binaries, but these are the major ones.
What’s crazy is that all four methods can be used at once on a system, each with their own methods of installing, updating, and deleting applications.
I won’t go into the pros and cons of each method here, but there are arguments about each.
A major downside for all these methods is that application preservation is esse
55 Comments
petepete
Sounds like someone wants Lindows/Linspire.
https://www.linspirelinux.com/
TacticalCoder
[dead]
d3Xt3r
Zorin OS supports running .exes directly (via Wine of course). https://help.zorin.com/docs/apps-games/windows-app-support/
devit
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).
mappu
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.
ranger_danger
> 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.
pizlonator
Seems like it would be easier to identify and fix cases of ABI compat breakage in the Linux userland than to convert Linux to Windows.
olddustytrail
> Thesis: We should create a distro of Linux that runs Windows binaries by default via Wine.
"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.
delusional
> We also already have a simple way to run Windows applications, Wine.
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.
subjectsigma
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.
nneonneo
FYI: a kernel patch to run exes isn’t needed. binfmt_misc can handle this, and wine-binfmt already exists to automatically run PE files through Wine.
ajross
So… this already exists. Valve already essentially sells this as a product. Folks know that, right? The Steam Deck is a linux box running wine executables as the native app environment. The fact that the money apps are all "games" doesn't change the technology.
lucasoshiro
> 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.
Why not use ReactOS?
titaphraz
[flagged]
coderenegade
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.
mrbluecoat
> The Linux Environment is Unstable
How many missiles do you know that run Windows?
win32lover
I'm not sure why there are so many naysayers. I've been having the same thought ever since the initial release of the steam deck and think it's a great idea.
In my vision no trace of Linux is discoverable by the user.
gmuslera
He is missing the point. Flatpak/Snap are not just an alternative way to ship binaries. They are way to isolate applications and what they can do. Landscape has moved from protecting the system or an user from another to protect the same user applications and their data from each other, specially for desktop environments. That is not even in the map for Windows, its security model and its applications. It is a big jump backwards.
nxobject
A reverse OS X/Classic transition, if you will…
xtracto
I want the opposite: id like a way to run the windows kernel, drivers and most low level OS stuff by windows, but with a Linux user Interface: Cinammon, apt and all the debian stuff.
I run Mint as my main OS, but hardware compatibility is still a headache in Linux for me.
adamtaylor_13
People always talk about this “I can run a 20 year .exe file” situation but when I tell you that I have never, in 30+ years, EVER had a need to run a 20+ year executable, it just makes me go… yeah, and?
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.
timeon
Three days early?
Perenti
Both Corel and Lindows tried this 25 years ago. People did not like it.
pdonis
To the extent binary distribution is "unstable" on Linux, it's because users aren't expected to just download random binaries from wherever, as is normal on Windows (and Mac, for that matter). Users are expected to either obtain binaries from their distro, or compile them from source. In either case, all of the issues about binary distribution being "unstable" are invisible to users. Which is the point. People who want the broken Windows software model can just..run Windows. The last thing any sane Linux user wants is to make Linux into Windows. I run Linux to avoid Windows.
magackame
What's up with all this "My 20 year old software still works!!!". Who actually runs unmaintained abandonware? I would rather prefer OS devs not wasting time maintaining legacy cruft and evolve with the times.
II2II
Ask IBM how well that idea worked.
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.
cyp0633
I still can't get MS Office 365 working on Linux over Wine, while no alternatives make me comfortable. Comparing Linux and Win32 ABI on Linux is nonsense without talking about Wine compatibility.
bentt
This is a wonderful idea and could succeed if the creator could rally the right devs and users. What it really needs is Ubuntu tier branding and UX work. This has been a rarity in the Linux desktop space.
I am hopeful SteamOS will bring us something very similar.
James_K
Surely one could design a library in Linux which makes syscalls and dynamically link to it.
Levitating
The suckless project gave us stali linux, a statically compiled linux distribution.
Doesn't static compilation solve quite a few of the problems states here?
https://sta.li/
kazinator
> I can pull down a 20 year old exe and still run it today on Windows.
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.
James_K
Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to compile software into dubious blobs and ship those to users. You could get rid of an awful lot of malware and massively simplify software distribution if you were to distribute a platform agnostic intermediary representation of source code that preserves enough semantic meaning to eliminate ABI issues, then leaves the last step of compilation to the operating system. Shipping binary files is just plain bad in every way.
shmerl
By the way, Wine is more stable than Windows itself in supporting older Windows ABIs.
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.
alphazard
> While the Linux syscalls themselves are very stable and reliable, the c library on top of them is not.
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.
notfed
> Thesis: We should create a distro of Linux that runs Windows binaries by default via Wine.
On Debian you're one package away:
Otherwise you're still pretty close:
nurettin
> Try doing the same with a Linux binary that's just a year old.
I do that all the time. Just link to a static glibc or musl.
caspper69
I have points to burn, so I'll post, because I know this will scratch some folks the wrong way- apologies in advance.
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.
marcodiego
> Try doing the same with a Linux binary that's just a year old.
AppImages are very close to fixing this. I'm not sure if it is already solved or very close to.
timewizard
> Try doing the same with a Linux binary that's just a year old.
I do it all the time. Works fine. Do you have a specific example or is this just a hastily constructed strawman?
worthless-trash
The shitty thing is, this just encourages closed source software on the open platform, giving vendors another reason not to port natively.
Good luck with the hellscape you're building.
feverzsj
Wine/Proton is basically Linux Subsystem for Windows.
999900000999
Valve's Steam OS( and inspired distros) already basically does this. It's centered around games, but everything else( if your lucky) is natively supported in Linux.
You can run non games on Proton. Most things work.
CrossVR
> 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.
pjmlp
Adopt GNU/Windows, problem solved.
foxes
20 year old games don’t work on modern windows that well at all, so that’s one counter example, so not sure where the point comes from.
pkulak
How much more of this opinion should I read when it’s established in the third paragraph that the author doesn’t realize that AppImage does not bundle a libc? Flatpaks do, and Snaps are a closed system that bundles _Ubuntu_, so really the answer is Flatpaks. And the rest of the world has also come to that conclusion.
vednig
Thank you for writing these thoughts.
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.
[1] https://github.com/zeeeroos
darkwater
Everybody is commenting on possible implementations or how similar solutions already exist.
I would like to focus on an overlooked but very important fact: most of the important software in the Linux ecosystem is opensource. Yeah, the ELF binary from 20 or 25 years ago might not run anymore out of the box but you have the source code, access to the whole history of source code of needed libraries. It will for sure not be a 0-effort adventure and it will not work with proprietary and closed source software, but it's doable for most of Linux old abandoned software.
jchw
First-class support for Windows applications might just become doable, if Wine continues to progress and Win32 doesn't accelerate. There were a handful of quality of life improvements in previous Windows releases, but the biggest Win32 changes feel like they happened quite a while ago by now, and for good reason: Win32 is stable and mature. It's still a moving target, but not by nearly as much, and even if Microsoft wanted to move it for the sake of moving it, they might find more resistance than they can completely overcome. For now, I think Wine is still not good enough to recommend people just use for everything, though. It's incredible, but incredible doesn't make Photoshop install.
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.
prkl
Or just statically compile all binaries like a (useful) madman
throwaway48476
Virtualization works far better than wine. Just copy the window frame buffer to the linux host.
DeathArrow
This is a wonderful idea. I have some doubts, though. It might not provide a seamless experience.
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.
frackintoaster
https://xkcd.com/927/
DeathArrow
Is there a Wine like library that helps running macOS apps on Linux?
DeathArrow
Every year or two I check the status of ReactOS hoping that some day I will have a good alternative to Windows. After checking the project status today, it seems that day is still far off.