Sounds like someone wants Lindows/Linspire. https://www.linspirelinux.com/
I thought the same while reading it and... I felt old.
Convert Linux to Windows
11–20 of 459 posts
Re: Convert Linux to Windows
#12Seems like it would be easier to identify and fix cases of ABI compat breakage in the Linux userland than to convert Linux to Windows.
Re: Convert Linux to Windows
#13> 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.
Re: Convert Linux to Windows
#14That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do. It can also be achieved with static linking and by shipping all needed library and using a shell script loader that sets LD_LIBRARY_PATH. Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in p…
> shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux
That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific.
In contrast, it’s impossible to run modern Windows without working Direct3D 11.0 because dwm.exe desktop compositor requires it. If a software consumes Direct3D 11.0 and doesn’t require any optional features (for example, FP64 math support in shaders is an optional feature, but sticking to the required set of features is not very limiting in practice unless you need to support very old GPUs which don’t implement feature level 11.0), will run on any modern Windows. Surprisingly, it will also run on Linux systems which support Wine: without Vulkan-capable GPU will be slow but should still work due to Lavapipe, which is a Linux equivalent of microsoft’s WARP they use on Windows computers without hardware 3D GPU.
Re: Convert Linux to Windows
#15I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.
There are few issues: 1. GNU libc is an exception in the world of compatibility. 2. You can't just dump a bunch of GTK libraries next to the binary and expect it to work. These libraries often expect very specific file system layouts.
That is solved by containerization (cgroups and namespaces), which is initially popularized by docker, which appeared about 12 years ago. And newer things like flatpak and snap are just bells and whistles over this.
Re: Convert Linux to Windows
#16Zorin OS supports running .exes directly (via Wine of course). https://help.zorin.com/docs/apps-games/windows-app-support/
This is the first time I've heard of that [Ubuntu?] distro. Would be curious to hear how it's working out, from anyone using it as their daily driver, and how it compares to Mint etc. on the Linux side of things.
Re: Convert Linux to Windows
#17> 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.
Re: Convert Linux to Windows
#18The 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.
Re: Convert Linux to Windows
#19FYI: 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.
Re: Convert Linux to Windows
#20That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do. It can also be achieved with static linking and by shipping all needed library and using a shell script loader that sets LD_LIBRARY_PATH. Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in p…
> shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific. In contrast, it’s impossible…
Note that this also underlines that the post's premise of Windows having a simple stable ABI - win32 sure is stable, but that's not what applications are coded against anymore.
Sure, you can run a 20 year old app, but that is not the same as a current app still working in 20 years, or even 5.