Convert Linux to Windows

This is great! Someone else mentioned binfmt_misc. I didn't know about that.

Yeah, that has been the default for a lot of Linux distributions for quite some time now (if you install wine).

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.

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.

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.

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 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 concept of containers for Windows applications running in WINE is called "bottles."

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.

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 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.

Flatpak could work better because it already knows how to factor out common parts, so it could bring in only one (or just few) version of Wine.

At this point nobody is going to learn a new system. People already know how to write and package exes which is the whole point.

> 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.

This is how Proton from Steam works

>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.

> > 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.

I thought the same while reading it and... I felt old.

Yes, I remember this! At some point they even claimed the term "Windows" was too generic to be protected, and they wanted to use it for the project...

A vendor that has to write a news item on their front page that their product is not dead? Maybe not the most attractive look.

Huh? Linux Mint looks more like Lindows than Linspire.

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 on of the many reasons Windows base install is so much heavier than a typical Linux base install.

Is that a bad thing if it means a seamless experience for users? Storage is cheap.

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.

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...)

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.

> The only thing Windows does better is ensuring that they maintain backwards compatibility in libc until they release a new version of Visual Studio

But they are installed side-by-side, major versions at least.

A big difference is that you can easily install an up-to-date MSVCRT. How do I upgrade glibc on RHEL 8? As far as I can tell you basically can't.

Windows made its libc stable in Win10 (ucrt.dll aka "universal CRT"). Only the C++ runtime must still be redistributed.

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.

This is usually about drivers, not applications. The Windows driver model didn’t maintain long-term compatibility.

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.

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.

Because they just work. Nobody cares if their MRI machine runs Win2000, they care if the machine reveals brain cancer.

I hit quirks with glib semi-regularly (~1/year)

For example, recently I tried to run Emacs' Appimage and it has a glib issue

https://github.com/probonopd/Emacs.AppImage/issues/22#issuec...

Thankfully gtk2 is now stable too.

> Glibc has great backwards compatibility

We're clearly not living in the same universe here.

glibc backward compatibility is horrible.

Every. Single. Time. I try to use an old binary on a modern distro, it bombs, usually with some incomprehensible error message with GLIBC in all caps in it.

And these days, you can't even link glibc statically, when you try it barks at you with vehemence.

As a matter of fact, as pointed out in the article, this particular shortcoming of glibc completely negates the work done by Linus to keep userland backward compatible at all cost.

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.

A windows95 compatibility layer would have been feasible if OS/2 had more sales volume.

The latest multi-platform packaging systems like Nix or Flatpak have largely solved the binary compatibility problem but providing some guarantees of library versions. This approach makes more sense in modern contexts with cheap storage and fast bandwidth.