14 ms·

Convert Linux to Windows

• petepete 2y ago
  Sounds like someone wants Lindows/Linspire. https://www.linspirelinux.com/ https://www.linspirelinux.com/
  • jcmfernandes 2y ago
    I thought the same while reading it and... I felt old.
  • Jolter 2y ago
    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.
    • petepete 2y ago
      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.
  • bambax 2y ago
    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...
  • GoblinSlayer 2y ago
    Huh? Linux Mint looks more like Lindows than Linspire.
    • n3storm 2y ago
      I guess you haven't used windows 11 yet, luckily.
• TacticalCoder 2y ago
  [dead]
• d3Xt3r 2y ago
  Zorin OS supports running .exes directly (via Wine of course). https://help.zorin.com/docs/apps-games/windows-app-support/ https://help.zorin.com/docs/apps-games/windows-app-support/
  • rkagerer 2y ago
    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.
    • d3Xt3r 2y ago
      My mum was using it as a daily-driver for all your average user PC stuff. It was decent, easily to use and more user-friendly than Mint, IMO – until an update borked it completely, after two years of running. Unfortunately post-update-breakages is something that's typical of Ubuntu and most Ubuntu-based distros, so it's not really surprising [1]. I've since switched her to an immutable distro (Aurora [2]) and it's been rock solid. [1] https://ounapuu.ee/posts/2025/02/05/done-with-ubuntu/ https://ounapuu.ee/posts/2025/02/05/done-with-ubuntu/ [2] https://getaurora.dev/en https://getaurora.dev/en
• devit 2y ago
  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).
  • api 2y ago
    > 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. True, but sad. The way to achieve compatibility on Linux is to distribute applications in the form of what are essentially tarballs of entire Linux systems. This is the "fuck it" solution. Of course I suppose it's not unusual for Windows stuff to be statically linked or to ship every DLL with the installer "just in case." This is also a "fuck it" solution.
    • grandiego 2y ago
      > to distribute applications in the form of what are essentially tarballs of entire Linux systems. No so bad when Linux ran from a floppy with 2Mb of RAM. Sadly every library just got bigger and bigger without any practical way to generate a lighter application specific version.
      • nine_k 2y ago
        Also, 64-bit code and especially data are just larger, because every address is 8 bytes, and data has to be aligned on at least 4-byte boundary. You can still have very tiny Linux with a relatively modern kernel on tiny m0 cores, and there's ELKS for 16-bit cores.
• mappu 2y ago
  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.
  • cyberax 2y ago
    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.
    • kccqzy 2y ago
      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.
      • cyberax 2y ago
        I have flatpaks from several years ago that no longer work (Krita) due to some GL issues.
        • GoblinSlayer 2y ago
          I heard OpenGL has a bad compatibility story, which was the reason games used DirectX.
    • mappu 2y ago
      In 2005 the hot new Windows technology was .NET Framework 1.1 or 2.0. You can't just dump Framework 1.1's libraries next to the binary and expect it to work either, it needs to be installed properly.
      • 2y ago
• ranger_danger 2y ago
  > 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.
  • voidspark 2y ago
    Yes it's a value judgement by the author. Maximizing profit by any means necessary is pathological. Many here would agree with that.
  • hagbard_c 2y ago
    > Is it "improper" to maximize profit per their own board's guidelines? From the standpoint of the end user the incentives are improperly aligned. If they had made hammers they would have included licence agreements for their use with specific types of nails and actively prevented users from using competitor's nails. They also would have made sure yesterday's hammer would not be sufficient to hammer in today's nail, they would have added camera's to observe what the user was doing so as to sell 'targeted' advertising - during which the hammer would not strike any nails but would sing like the singing sword in Who Framed Roger Rabbit - and they would have made sure that no matter how agile the user was with his hammer the thing would never be 100% reliable. Of course hammers are far less complex than computers and operating systems. Maybe this is because they're made by tool manufacturers and not by tech companies, maybe it is because they're old tech. A modern hammer is what Ford would have produced if he had listened to his customers who asked him for a faster horse so maybe there is a whole world of construction efficiency waiting for the Henry Ford of Hammersmiths. Or, maybe - probably - sometimes it is better to get that faster horse, that titanium hammer or that free software operating system which works for you and nobody else.
    • cratermoon 2y ago
      Worth reading: Unauthorized Bread. https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-tale-of-refugees-and-sinister-iot-appliances/ https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-...
• pizlonator 2y ago
  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.
  • Spivak 2y ago
    This would be an option if the Linux userland wasn't a mish-mash of unconnected developers with their own practices and release cadence. It's why we have LTS distros where the company will put in the massive amount of work to preserve binary compatibility. But the trade-off is that the software you have in your repos will be really old. At the end your RHEL support cycle libs will be a decade out of date.
  • GoblinSlayer 2y ago
    OpenSSL
    • pizlonator 2y ago
      What about it
      • avodonosov 2y ago
        Breaks compatibility. They remove or rename functions often and openly say they are not going to maintain compatibility.
        • pizlonator 2y ago
          There are lots of alternative ssl libraries. Point still stands: fixing the situation with these libraries seems like less fuss than turning Linux into windows.
• olddustytrail 2y ago
  > 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.
  • stevage 2y ago
    That is the weirdest thing to take exception to.
• delusional 2y ago
  > 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.
  • hagbard_c 2y ago
    Fairly simple for the end user, not simple in its implementation.
    • keyringlight 2y ago
      Like a lot of things in any OS it depends how far off the beaten track you go. I think there's a lot of gaming newcomers to linux where their main exposure for wine is via steam, which generally wraps things up for them and hides the details behind their launcher. If you need to go diving into the details for compatibility or you'd like to separate things out with prefixes then it's definitely much less polished and elegant, but I'd argue you could say the same thing about windows for compatibility with some old games or sites like PCGamingWiki.com would be a lot smaller as the combinations of windows (or DOS)+drivers+hardware over the years hasn't resulted in perfect consistent compatibility.
  • trelane 2y ago
    Depends. Proton and CrossOver are dead easy, especially for the supported apps.
    • 3np 2y ago
      Easy to use? Sure. Simple? No way.
      • trelane 2y ago
        https://support.codeweavers.com/en_US/2-getting-started/2-installing-a-listed-application https://support.codeweavers.com/en_US/2-getting-started/2-in... Seems easy to me
• subjectsigma 2y ago
  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.
  • skissane 2y ago
    > > 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.
• nneonneo 2y ago
  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 2y ago
  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.
  • Spivak 2y ago
    How they do it is by shipping a franken-ubuntu14 as the "steam runtime" for native Linux games. Not a terrible solution but not exactly ideal for general purpose software where games mostly keep to themselves. Their work on Proton is amazing though.
    • andrewclunn 2y ago
      Wait, isn't Steam OS Arch based now?
      • yesco 2y ago
        There is three things here: - Steam Runtime: A set of common libraries Linux native games target for multi-distro compatibility, I believe this still uses Ubuntu as the upstream - Steam OS: An arch based distro pre-configured to run Steam out of the box, used by the Steam Deck, comes with extra stuff like gamescope to smooth over various issues other distros have with VRR, HDR, etc. - Proton: Runs Windows games on Linux
  • win32lover 2y ago
    Steam OS is clearly not what the blog is proposing, I can't just pop over the desktop mode and install Firefox via a MSI.
    • ajross 2y ago
      No[1], but you can launch a windows executable natively, link against DLLs in a compatible way, thunk between 32 and 64 bit as needed, access the Linux filesystem, network and IPC environment using native APIs, integrate with things like .NET and msvc runtimes, access native-speed DirectX emulation, etc... Yes, you'd have to buff and polish it. But "paint some chrome on it" is hardly much of a blog post. [1] Actually, are you sure the answer is "no" here? I wouldn't be at all shocked if some enterprising geek had source on github implementing a MSI extractor and installer
• lucasoshiro 2y ago
  > 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?
  • linguae 2y ago
    Linux has far greater hardware support than ReactOS does.
    • okanat 2y ago
      Maybe we should fund ReactOS for end-user applications. Win32 is well established and isn't going anywhere. So why not take advantage of Microsoft's API design effort
      • squiggleblaz 2y ago
        But who is "we"? It might have been valuable to games makers, but Wine/Linux based systems seems to be adequate for them. So who is left?
        • DeathArrow 2y ago
          >So who is left? People who like and need Windows apps, people who want to have an out of the box experience when running those apps, people who don't like the loss of performance when using Wine, people who generally like Windows but want to have an alternative in case that dislike where Microsoft is heading with Windows development. That is a lot of people, me included. But since Windows experience is somehow still tolerable, there aren't many willing to invest time or money into ReactOS. There are no corporate sponsors since you don't make money from desktop OS-es unless you use them to sell expensive hardware like Apple did. Someone like Valve could have sponsored it but they though they can reach their goals with Wine while spending much less money. Another sponsor for ReactOS can be a state actor like China or EU, somebody with deep pockets who wants and needs to run Windows software but don't want their desktop to be under US control.
• titaphraz 2y ago
  [flagged]
• coderenegade 2y ago
  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.
  • trelane 2y ago
    The concept of containers for Windows applications running in WINE is called "bottles." https://support.codeweavers.com/en_US/2-getting-started/2-installing-an-unlisted-application 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.
    • coderenegade 2y ago
      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.
      • csdvrx 2y ago
        It's extremely efficient: cold starting Word from an old Office suite is much faster than starting Libreoffice. It also uses less RAM. A few years ago I purchased a few shrink-wrapped Office on ebay for each of the versions Wine claimed to support best, tested then with wine32 and wine64, and concluded the "sweet spot" was Office 2010 in wine32 (it may have changed, as wine keep evolving) Yes, it's 15 years old software, but it works flawlessly with Unicode xkb symbols! Since it doesn't have any network access, and each app is isolated in a different user id, I don't think it can cause any problem. And Ii I can still use vim to do everything I need and take advantage of how it will not surprise me with any unwanted changes, I don't see why I couldn't use say an old version of Excel in the same way!
• mrbluecoat 2y ago
  > The Linux Environment is Unstable How many missiles do you know that run Windows?
  • okanat 2y ago
    How many do you know running Linux? Most of them are either specialized bare-metal OS and the rest is VxWorks.
    • mrbluecoat 2y ago
      https://search.brave.com/search?q=missiles+running+Linux https://search.brave.com/search?q=missiles+running+Linux
      • okanat 2y ago
        There are actually no direct results that prove an actual missile running Linux. Simulations yes. Linux running a missile itself no.
• win32lover 2y ago
  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 2y ago
  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.
  • aaomidi 2y ago
    Windows does a lot of sandboxing in this space though what do you mean?
  • mjevans 2y ago
    Every Application should be it's own 'user' (sub user) while the login-user / manager should be the group leader of all those 'sub users' / 'agents'. A change in security model from the 1970s/1980s might help with security and isolation. However that same security would also generally be a pain without really smooth management in the desktop environment / shell.
  • JanisErdmanis 2y ago
    The Windows MSIX also does sandboxing.
• nxobject 2y ago
  A reverse OS X/Classic transition, if you will…
• xtracto 2y ago
  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.
  • throwaway48476 2y ago
    What hardware isn't compatible?
  • trelane 2y ago
    If you're not buying a laptop with Linux preinstalled and supported by the hardware vendor, you're going to have a hard time. You might get lucky, but it sounds like you've not been lucky.
    • tombert 2y ago
      I’ve never bought one of the dedicated Linux laptops, but I’ve had pretty good luck with AMD stuff. My current laptop, Thinkpad P16s AMD Gen 2, was pretty straightforward to get working with NixOS. No special drivers, and everything, including WiFi and function buttons on the keyboard, worked fine without any kind of special concessions. This was also the case for my last non-Mac, from 2017-2020, I got Ubuntu installed on there without many headaches, and it wasn’t a specific Linux laptop, though again it was AMD.
  • DeathArrow 2y ago
    Doesn't WSL do that?
    • magicalhippo 2y ago
      WSL 1 did, WSL 2 runs in a VM.
  • p_ing 2y ago
    You can resurrect SFU and build a replacement GUI for Explorer. You can't get rid of Win32, but you can cover up most of it. Implementing a Personality would be the Windows-way of doing this as it is designed for just what you ask.
• adamtaylor_13 2y ago
  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.
  • sevensor 2y ago
    My experience is that a 20 year old exe file has a greater chance of running in wine than it would in windows, and a 20 year old Linux executable is going to fail because the shared libraries it depends on are unobtainable
    • o11c 2y ago
      In my experience: 20-year-old exe files can fail on both Windows and WINE if they touch something relatively obscure. It's easier to throw files at the problem under WINE though (you can just throw away the prefix if you break something). The single biggest mistake WINE makes is defaulting to a single shared prefix (and the second sin is similar - trying to integrate folders and menus naively). 20-year-old dynamic binaries on Linux can almost always work today; snapshot.debian.org has all the old libraries you'll ever need. The potential exception is if they touch something hardware-ish or that needs exclusive access, but this is still better than the situation on Windows. 20-year-old static binaries on Linux will fail surprisingly often, since there have been changes in filesystem and file layout.
  • cratermoon 2y ago
    I use Nikon Scan 4.0.0. It was released in either 2008 or 2004.
  • GoblinSlayer 2y ago
    You can have an Electron app with the same features, but an older program likely can do it without being Electron or webapp.
  • DrFalkyn 2y ago
• timeon 2y ago
  Three days early?
• Perenti 2y ago
  Both Corel and Lindows tried this 25 years ago. People did not like it.
  • int_19h 2y ago
    Wine was in a much worse shape back then.
  • DeathArrow 2y ago
    I did like them both. They felt much more polished that other Linux distros at that time.
• pdonis 2y ago
  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.
  • trelane 2y ago
    There's also flatpak and friends
  • johnea 2y ago
    Thank you very much! I was about to post almost the same thing, so I'll reply to your post instead (and upvote): It's pretty funny to read a critisism of linux s/w distribution along the lines of the dificulty of distributing binaries. This is one of the biggest security vulnerabilities of windows. 3rd parties distributing binary executables. At least in a typical linux distro the binary is built by the distributing org, with some review of where the source comes from. Downloading a windows app from the internet one has no idea what source is included in that binary. I'm also not a fan of non-distro based systems such as flatpack. Again, I would prefer my binaries built by the distribution, or if need be, locally.
    • nice_byte 2y ago
      explain to me why the HELL should i be limited to only running binaries that my distro vendor has deigned to provide, or jump through endless hoops to obtain and build source code (which by the way might not even be obtainable OR buildable). if i have a binary from 5, 10, 15 years ago i should just be able to fucking run it on my fucking computer.
      • johnea 2y ago
        Then run your "fuzzy kitty plays on your desktop" binary executable, downloaded from we-swear-we-wont-hack-you.com, and live with the consequences. In fact this is the way 3rd party windoze executables are typically distributed. Nobody's stopping you... p.s. The above seems like a trolling reply, but I always play the straight man...
• magackame 2y ago
  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.
  • p_ing 2y ago
    I play Silent Hunter III which was released in 2005. Also Half-Life sometimes. Everything older is going to be console games. Businesses run the old stuff.
  • Saris 2y ago
    Lots of embedded stuff will have control software that's very old.
  • zdragnar 2y ago
    Is this sarcasm? Some of my favorite games are 20 years old. Windows is popular in a lot of manufacturing spaces because the equipment software doesn't get updated and only connects to old programs over 16 bit serial ports. There's a whole world out there of legacy software that is happily churning along, and doesn't need to be updated.
    • tormeh 2y ago
      Okay, but then you could also keep it running on an old OS. Fork out the money for a RHEL license, and just never upgrade.
      • Dylan16807 2y ago
        But I don't want to run a separate machine with 15, 20, 25 year old hardware to keep that OS working.
  • tobinfekkes 2y ago
    I still play Total Annihilation, from 1997. Great game.
  • 2y ago
• II2II 2y ago
  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.
  • bitmasher9 2y ago
    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.
  • deleted 2y ago
    [deleted]
• cyp0633 2y ago
  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.
  • d3Xt3r 2y ago
    Have you checked out OnlyOffice recently? If so, I'm curious what are the deal-breaking features you find that it lacks compared to M365.
    • tuananh 2y ago
      why am i getting the vibe that onlyoffice is closed-source. it's actually open https://github.com/ONLYOFFICE https://github.com/ONLYOFFICE
• bentt 2y ago
  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.
  • DeathArrow 2y ago
    >What it really needs is Ubuntu tier branding and UX work. That means somebody paying for the work. Designers and UX specialists don't care about free work like many programmers do.
    • bentt 2y ago
      Yeah Blender might be a good model here.
• James_K 2y ago
  Surely one could design a library in Linux which makes syscalls and dynamically link to it.
• Levitating 2y ago
  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/ https://sta.li/
  • samtheprogram 2y ago
    Yes. It’s the same reason AppImage could work — if the licensing allows for the all libraries to be included in the image, because the Linux syscall interface is generally stable. “We do not break userspace”
    • Levitating 2y ago
      AppImages have a few problems. Ever seen how much dependencies you need installed to execute an AppImage? You also need to be in an environment where you can create FUSE filesystems. And iirc the reference implementation requires the deprecates fuse2 library to work. Snaps, Flatpaks, AppImages and static linking are all solutions to a real problem. But I don't think AppImages are an especially good solution. I talked a bit with Richard Brown about supporting AppImages in Aeon, the OpenSUSE immutable distro. But he believed the base system would need far too much dependencies specifically to support the AppImage runtime including deprecated fuse2 support.
      • account42 2y ago
        Snaps and Flatpaks have many more dependencies than AppImage, they are just not deprecated YET.
        • Levitating 2y ago
          True, but I believe Flatpaks offer more than just "single executable applications". In the case of Aeon it's the primary way of installing additional software.
• kazinator 2y ago
  > 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.
  • marticode 2y ago
    I really don't see Microsoft blocking unsigned exe. There's just too much old Windows/DOS software out there still in use, sometimes running critical infrastructure.
    • SunlitCat 2y ago
      Like someone already said somewhere, it will come in steps. Windows S Mode was already a test. The nagging, warning and outright "blocking" (while hiding the "run anyway" button under "more info") is the first step. This already is a warning to software vendors that something will come. The next step will be blocking unsigned exes on Home Editions (not on Pro or Enterprise), so that software vendors and most of places depending on unsigned old software can move on to signed software. Then Home and Pro Editions of windows wont be able to run unsigned software anymore and if you need unsigned software to run you'll have to use an Enterprise Edition. The last step would be no windows can run unsigned software anymore and if you need unsigned software running, you'll need to run that one on an Azure instance of Windows which can still run unsigned software or (if you can't / don't want to run your software in the cloud) you will have to contact Microsoft for a special Windows version, costing lots of money. But if your business depends on that one single unsigned exe file, you might be ready to pay for that one.
• James_K 2y ago
  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.
  • 6483974564 2y ago
    [flagged]
  • robocat 2y ago
    > dubious blobs I think you are just suggesting to replace binary blobs with other binary blobs e.g. CLR/.NET assemblies/executables or WebAssembly files. Or do it the JavaScript way: distribute compressed minified (kinda compiled) source code and the runtime JIT compiles it at runtime (e.g. V8 engine Turbofan compiler).
    • James_K 2y ago
      I'm trying to replace platform dependant and easily breakable binary files with platform independent and change resistant files. Yes, those files are still in binary, but this is true of all files on a computer. What's useful about these new formats is that they retain a greater degree of information about the source code.
  • wyldfire 2y ago
    > Shipping binary files is just plain bad in every way. Aren't .class and .jar files "binaries"? > Java already solved this problem, for the most part Maybe, just maybe, there are some drawbacks that mean that in fact it's not solved. Otherwise perhaps Java would've completely obsoleted C, C++. Some of us design applications which can't tolerate the worst case GC pauses, for example. Some of us design applications which we can't afford to spend extra time heap-allocating nearly everything.
• shmerl 2y ago
  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.
  • jillesvangurp 2y ago
    Exactly, wine is all that's needed here for windows stuff. And we have snap, flatpak, docker, and a few other things for Linux stuff. We'll probably get a bit of irony in a few years when somebody at MS realizes that they can just use wine on top of their Linux emulation layer to run any old MS legacy software from the past three decades+ and then cleans up the rest of windows to not have any support for legacy APIs. Because having that is redundant. Emulators are great. There's no need to run ancient software natively.
• alphazard 2y ago
  > 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.
  • squiggleblaz 2y ago
    It's not "some c library on top of them", it's glibc. You can use another libc, but that means you're going to be incompatible with the distro expectations in terms of configuration, because that's handled by glibc, so you just push off the instability to a different part of your system.
• notfed 2y ago
  > Thesis: We should create a distro of Linux that runs Windows binaries by default via Wine. On Debian you're one package away: sudo apt install wine-binfmt Otherwise you're still pretty close: 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/register
  • pbohun 2y ago
    This is great! Someone else mentioned binfmt_misc. I didn't know about that.
    • csdvrx 2y ago
      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. 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_wayab_hyprland_animated_background_forest/ https://www.reddit.com/r/unixporn/comments/11w3zzj/hyprland_...
      • sureglymop 2y ago
        What would be the latest usable office version recommended for this?
      • eitland 2y ago
• nurettin 2y ago
  > 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.
  • panzi 2y ago
    Yeah, just my thought. Instead of all the effort and overhead and awful API of Win32 just statically link musl. Still, there are of course downsides and limitations to either approach.
  • amavect 2y ago
    I really want to statically link OpenGL and Vulkan for exactly this purpose, but neither use a wire protocol (unlike X11 or Wayland). The whole "loading library" scheme feels like hazing for any beginner graphics programmer on top of the already complex graphics APIs.
    • DrFalkyn 2y ago
      I know at least for OpenGL, not all graphics cards/drivers would implement the entire featureset. So there was a reasonable justification for the dynamic linking and bringing in functions one by one.
      • amavect 2y ago
        I think that a wire protocol could support that with a query response for supported versions and functions. The decision of dynamic linking removes the overhead of serialization, but removes the option of static linking.
• caspper69 2y ago
  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 2y ago
  > 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.
  • zitsarethecure 2y ago
    Adobe Reader for Linux hasn't been updated since 2013 but the flatpak still works fine.
• timewizard 2y ago
  > 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 2y ago
  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.
  • DeathArrow 2y ago
    I do not care about access to source code or not. I use apps, I do not want to look at their source code or compile them. So open/close, I do not care as long as it does what I need, how I need. And I feel I am not the only one thinking like this.
    • worthless-trash 2y ago
      You sure are not alone, your mindset is that of a user, not a developer. Its like expecting people who only eat food to understand how its made.. You're just not the target.
      • DeathArrow 2y ago
        I am both. But I do not feel the need to look at the source code of all software I use or tinker with it.
        • worthless-trash 2y ago
          I didnt see all in your original post.
• feverzsj 2y ago
  Wine/Proton is basically Linux Subsystem for Windows.
  • throwaway48476 2y ago
    WSL1, WSL2 is Hyper-V virtualization.
• 999900000999 2y ago
  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 2y 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.
  • andai 2y ago
    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...)
    • therein 2y ago
      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.
  • jchw 2y ago
    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.
    • 2y ago
• foxes 2y ago
  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.
  • tombert 2y ago
    I recently played Sinistar Unleashed on my Linux laptop. I was never able to get this game working on regular Windows hardware, even when I bought the game brand new and tried running it on a contemporary computer, but it runs fine with Wine and Proton. I decidedly could not get it working on a dual boot of Windows 10 (that I installed just to play to it). Granted, even with Wine it wasn’t trivial to get working, but it wasn’t that bad. The game is actually not bad, I would have loved playing it as a kid, but I had to wait 25 years for Wine to let me play it, apparently.
    • throwaway48476 2y ago
      Do you use CD drive emulation with wine?
      • tombert 2y ago
        I actually didn't for this, I was able to mount the ISO with linux and then run the executable directly to install it, then futz around with Wine settings on the install path to eventually get the game launching.
  • int_19h 2y ago
    It really depends on the game, but generally speaking, 20 year old games (that would be from 2005) work on modern Windows just fine. Games developed back in Win9x era are usually more troublesome.
• pjmlp 2y ago
  Adopt GNU/Windows, problem solved.
• pkulak 2y ago
  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 2y ago
  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 https://github.com/zeeeroos
• darkwater 2y ago
  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 2y ago
  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 2y ago
  Or just statically compile all binaries like a (useful) madman
• throwaway48476 2y ago
  Virtualization works far better than wine. Just copy the window frame buffer to the linux host.
  • mdaniel 2y ago
    As someone stuck in macOS trying to run docker, I can tell you that the impedance mismatch between a what a "file" is, and its "location", and the meaning of "listen on localhost", and how much "memory" an application has makes virtualization absolutely horrible for trying to run just one program on a different OS (or arch) than the rest of your day to day
• DeathArrow 2y ago
  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 2y ago
  https://xkcd.com/927/ https://xkcd.com/927/
• DeathArrow 2y ago
  Is there a Wine like library that helps running macOS apps on Linux?
  • Cu3PO42 2y ago
    It's called Darling [0], but is not nearly as far along as Wine is. [0] https://www.darlinghq.org/ https://www.darlinghq.org/
  • xyproto 2y ago
    yes, whisky https://github.com/Whisky-App/Whisky https://github.com/Whisky-App/Whisky
    • mdaniel 2y ago
      > A modern Wine wrapper for macOS built with SwiftUI I think you misunderstood GP's request of "running macOS apps on Linux" so you swapped the host and guest OS, and then transposed the guest OS under "emulation"
      • xyproto 2y ago
        Dang, you're right, I was a bit quick there and misread. Sorry about that.
• DeathArrow 2y ago
  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.
• DeathArrow 2y ago
  I wouldn't be surprised if Microsoft does something to that effect in the future. Have Win 32 as a layer on top of Linux. 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.
• teo_zero 2y ago
  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.
  • idiotsecant 2y ago
    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.
  • maccard 2y ago
    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.
  • taskforcegemini 2y ago
    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.
  • 1970-01-01 2y ago
    Because they just work. Nobody cares if their MRI machine runs Win2000, they care if the machine reveals brain cancer.
• tex0 2y ago
  That is pretty much what I'm doing with Steam, Proton and my Game Library. 99% the time it works just great.
  • lvturner 2y ago
    Sadly a few sim racing games don't run at all and VR is a bit hit and miss (though the Quest3 with either WiVRN or ALVR seems to work well) Still I'd rather this than deal with daily driving Windows! I'm amazed at how good Gaming on Linux has gotten over the past few years.
  • int_19h 2y ago
    If you mostly do singleplayer, sure. Anything online with anti-cheat is usually broken.
    • akimbostrawman 2y ago
      >usually broken The working number is usually around 40-50% see areweanticheatyet.com
• notorandit 2y ago
  > 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. How this can be considered a good thing?
  • darknavi 2y ago
    Backwards compatibility is generally a good thing. It certainly has its downsides (like security) which can be more or less of a concern depending on backwards compatibility techniques.
    • notorandit 2y ago
      20 yo backwards compatibility in IT technology is impossible.
• amelius 2y 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. 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?
• flohofwoe 2y ago
  > In Linux, you can make system calls directly... > 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.
  • maccard 2y ago
    > Isn't the actual problem glibc since the Linux syscall interface is stable? Yes > 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? You’re right. But those apps are simple enough that we could probably compile them quicker than they actually run. > I expect that Windows is full of application specific hacks under the hood to make specific old applications work. Yes [0]! > 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 Yes, but. Windows is the user space and kernel for the most part. So the windows back compat extends to both the desktop runtime and the kernel. You might argue it’s a false equivalence, and you’re technically correct. But that doesn’t change the fact that my application doesn’t work on Linux but it does on windows. [0] https://news.ycombinator.com/item?id=35203390 https://news.ycombinator.com/item?id=35203390
    • flohofwoe 2y ago
      I'm not trying to defend Linux btw, and I appreciate Microsoft's approach to backward compatibility (some of the Windows games I play regularly hail from the late 90s). Just wanted to point out that ABI stability alone probably isn't the reason why Windows is so backward compatible, there's most likely a lot of 'boring' QA and maintenance work going on under the hood to make it work. Also FWIW some of the early D3D9 games I worked on no longer run on out of the box on Windows (mostly because of problems related to switching into fullscreen), I guess those games were not popular enough to justify a backward compatibility workaround in modern Windows versions ;)
• a3w 2y ago
  > I can pull down a 20 year old exe and still run it today on Windows 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.
  • Gormo 2y ago
    > Also, around 2001 was the big architectural change for desktop from DOS to NT, so this might seem like cherry-picking the timeframe selected. It's true that the entire Windows product family converged onto the NT codebase with the release of Windows XP, but this isn't really relevant -- Windows executables and DOS executables were always different things, and despite being built on top of a DOS-based kernel, Windows 9x still supported the same Win32 binaries that ran under NT. There was even an extension called Win32S that allowed Win32 executables to be run under Windows 3.1. The Win32 API dates to the early '90s, and modern implementations do support executables dating all the way back to the beginning.
• leni536 2y ago
  How often does glibc introduce a breaking change?
• graemep 2y ago
  There are multiple distros that make it very easy - as in download a .exe or .msi and click on it: https://help.zorin.com/docs/apps-games/windows-app-support/ https://help.zorin.com/docs/apps-games/windows-app-support/ Some of these have a long history: https://en.wikipedia.org/wiki/Linspire 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.
• t43562 2y ago
  Dancing to a proprietary tune is risky - they can decide to change the API or go after you with lawsuits if it becomes too competitive. 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.
• hnlmorg 2y ago
  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.
  • boricj 2y ago
    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.
• feelamee 2y ago
  > 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: - distribute the same as on Windows - link statically
  • Onavo 2y ago
    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.
  • elmo2you 2y ago
    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.
    • csdvrx 2y ago
      > 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.
• hugo1789 2y ago
  Why so complicated? Wine is cool if you need to run an existing binary but when you're writing your own software, why not just compile the platform independent part into a binary and make the platform dependent part a little library (open-source)?
• neiesc 2y ago
  I sugest https://archcraft.io https://archcraft.io
• thatjazz 2y ago
  > I can pull down a 20 year old exe and still run it today on Windows. 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...
  • WorldPeas 2y ago
    and you could! all if you could find the right DLLs
  • bobsmooth 2y ago
    Compatibility mode usually solves those problems.
• Asooka 2y ago
  I have had the same idea for a while, honestly. Yeah you can install wine and binfmt_misc, but it doesn't come by default. It should be the default. Nobody should be distributing binary Linux applications in this day and age, especially not for the desktop. Win32 is just so much better designed from the ground up for desktop apps, it's not even funny. As a simple example - a Win32 .exe has an icon to tell the user immediately what it is, but Linux apps need a ton of hacks and extra files (wtf is a .desktop) which can get out of sync at the drop of a hat. Also the ABI is indeed stable. You don't have to worry about the graphics and audio APIs disappearing etc. 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.
• 1970-01-01 2y ago
  >Imagine we made a new Linux distro Imagine we made a new shade of brown Seriously, this is the most cliché thing you could do with Linux.
• adham-omran 2y ago
  It is not just _running_ things that's the problem, authentication and authorization are massive, I've attempted to run various Audio plugins with Wine which either do not run at all or they run on a one-time basis which is not feasible for any long term setup. Oh if only you could run them under a vm..
• 0xDEAFBEAD 2y ago
  How about packaging Linux apps as Windows apps so they can take advantage of the stability of the Win32 ABI? Is there a way to do this automatically, possibly using AI?
• quotemstr 2y ago
  > In Windows, you do not make system calls directly. Instead, you dynamically link to libraries that make the system calls for you. This allows Microsoft to do all sorts of shenanigans at the kernal level while providing a stable API to userspace. This little stroke of genius allows us to have both Linux and Windows on the same machine at the same time. Precisely correct. Linux should never have allowed system calls from outside libc or a big vdso.
• jabedude 2y ago
  > MacOS has a feature called Gatekeeper, which limits what software you can run on your Mac to only those applications that Apple approves 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.
• evanextreme 2y ago
  To add some validity here, I think to an extent we already see distributions aimed at converting Windows users moving in this direction. Zorin OS has Wine support for .exe's almost out of the box, and there's Steam OS / Proton, where (if I recall correctly) the official guidelines for the Steam Deck state that developers should NOT create native Linux ports for new games, but rather optimize around Proton itself.
• nunobrito 2y ago
  He is not wrong. My software compiled with Borland Delphi 1.0 works beautifully with Wine under Linux and works just good as well under Windows. 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.
• artemonster 2y ago
  > "In Windows, you do not make system calls directly. Instead, you dynamically link to libraries that make the system calls for you. This allows Microsoft to do all sorts of shenanigans at the kernal level while providing a stable API to userspace." Or, in other words, "We can solve any problem by introducing an extra level of indirection."
• blueflow 2y ago
  > 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. 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.
  • bobsmooth 2y ago
    99% of Windows users don't even know what compiling is, nevermind compiling from source themselves.
• avodonosov 2y ago
  "The Looming Future" chapter of the article. I didn't know all those hortiboe things are planned.
• zoezoezoezoe 2y ago
  > 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. 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.
• DrNosferatu 2y ago
  Doesn’t Zorin Linux already sort of does this?
• DrNosferatu 2y ago
  A major problem is that Microsoft fundamentally torpedoed Wine by blocking MsOffice compatibility with Wine for quite a while now. (ie.: only fairly old versions of MsOffice work on Wine)