back to article Wine pops cork on version 6.0 of the Windows compatibility layer for *nix systems

The compatibility layer for Windows applications, Wine, has celebrated the start of 2021 in the traditional manner – with a substantial update. After spending December and the early part of January going through six release candidates, the stable Wine 6.0 has been rolled out, replete with over 8,300 individual changes and a …

  1. Anonymous Coward

    Technical debt

    When MS (int al) move on, you can rely on Wine and Samba to watch your back.

    Yesterday I set up a Samba daemon that reshares a Windows 10 share for an industrial machine that runs MSDOS 6.22 for its input. It's actually all properly secure - separate VLAN (no in or out by default), Samba only accepts connection from specific IP as well as creds which are laughably easy to crack these days.

    Wine is also a wonder that keeps things running.

    1. DrXym

      Re: Technical debt

      Yes and no. WINE implements almost all of the Win32 programming APIs but it won't help if your application needs MSDE, .NET Framework, IE Explorer (as a control), certain fonts, proprietary drivers or whatever. In those cases you might find the software doesn't run or you're still reliant on big chunks of binaries that have to be sourced from Microsoft to make something run.

      This is probably why it has been most useful for getting games to run because for the most part they are relatively self-contained, They might include distributables for the MSVC runtime and DirectX but otherwise they're just hitting APIs, and mostly APIs belonging to DirectX or OpenGL. The biggest problem for games is probably CDROM protection drivers. WINE does emulate some of those such as SECUROM and Safedisc to make pretend the CD is inserted so the game plays but not all of them.

      1. bombastic bob Silver badge

        Re: Technical debt

        A couple of years ago I experimented with Wine and discovered there are some serious shortcomings. One of the biggest: having BOTH 32-bit AND 64-bit running at the same time. Basically, did NOT work.

        This completely screwed the ability to load things like DevStudio onto a Wine machine, or (for that matter) ANYthing that's "mostly 64-bit" but has some 32-bit executables here and there for some reason.

        I was also disappointed in the *MESS* left behind when I went to uninstall the various wine packages in that particular VM. It wasn't pretty...

        This _was_ more than a couple of years ago, so maybe it's fixed, now? I was actually considering the possibility of contributing to the project at that time. I wanted developer tools up and running for that reason. It was both for this _AND_ for CentOS, actually, but both seem to suffer from the same *kinds* of "Catch 22" level problems, inherent in the very nature of the projects.

        Icon because I like the idea, but am disappointed in how it has dragged along...

    2. jake Silver badge

      Re: Technical debt

      et alia

  2. BenDwire Silver badge

    Don't forget Crossover Office

    Crossover Office is a paid for version of Wine, and makes running Windows Programs* much easier for the uninitiated. I use it for three programs I can't live without, and it "just works".

    The best bit is they contribute a lot of code back to the Wine project, so it's a good way of helping out for the greater good.

    * You can tell my age; They are programs, not apps.

    1. 45RPM Silver badge

      Re: Don't forget Crossover Office

      A program feels substantial. Worth paying for. It might come in a box - but it’s definitely supported.

      An app is fluff. Not really worth paying for - it’s like those wee covered peanuts in a bowl on the bar.

      This appification of software development is my bete noir as a software developer. Is what what we do not worth paying a fair price for because you can’t physically grasp it in your hands?

      And yes, I’m another crossover user. Or rather, I’ve paid for it because I think that they do excellent work, I’ve played with it - but I don’t actually need to use it on a daily basis (mainly, I suppose, because I don’t play games that often)

      1. -bat.

        Re: Don't forget Crossover Office

        Often wondered if the word 'app' is, unfortunately, going to be the most enduring legacy of NeXT. Because you can trace a direct route from the 3 letter directory extension we used for code bundles there, there through to OSX, through to the iPhone, and hence everyone calling mobile phone code 'apps' after Apples advertising campaign of the time. Ho hum.

        1. bombastic bob Silver badge

          Re: Don't forget Crossover Office

          'App' and 'Apple' have something in common, though. I thought maybe it was marketing... "There's an App for that" etc..

      2. Jonathan Richards 1

        It's sort of a low bar...

        ... that has wee-covered peanuts. Please, wash your hands.

      3. jake Silver badge

        Re: Don't forget Crossover Office

        "wee covered peanuts in a bowl on the bar"

        Nice bars you go to. Is it a game they play? Volume, distance or accuracy?

        Concur on apps vs. programs.

    2. John Brown (no body) Silver badge

      Re: Don't forget Crossover Office

      "* You can tell my age; They are programs, not apps."

      What goes around comes around. Back when we first started using MS-DOS based systems (well, not quite, our first PCs ran MS-DOS 2.11 on Tandy 1000 computers) ie MS-DOS 3 with hard disks, we standardised the local hard disk directory structure across the "fleet" of 30 or so PCs to include directories named APPS, TOOLS and UTILS plus others. C:/APPS was where stuff like WordStar, Supercalc and DBase lived.

      1. John Brown (no body) Silver badge

        Re: Don't forget Crossover Office


        Oops, that would be C:\APPS. You can tell I use *nix systems almost exclusively these days :-)

      2. jake Silver badge

        Re: Don't forget Crossover Office

        I put 'em into c:\usr\ws, c:\usr\sc and c:\usr\db (or c:\u\ws etc.)

        Seems I was using *nix systems almost exclusively in those days :-)

      3. Lomax

        Re: Don't forget Crossover Office

        > TOOLS and UTILS

        What is the difference between a "tool" and a "ulility"?

        1. Quando

          Re: Don't forget Crossover Office

          Tool is the whole Swiss Army knife, utility is just one blade.

  3. Jonathan Richards 1
    Thumb Up

    Not always a game, though

    > Most likely a game

    Garmin devices need Windows™ support programs that (AFAIK) have never been ported or implemented on *nix platforms. I have been in the habit of having a VM for this purpose, but will look again at Wine 6.

    1. AndyMTB

      Re: Not always a game, though

      I've managed to get my Edge 705 (a usb device) and an old car GPS unit to connect to Garmin Express running Wine, via this link

      Runs very slow, you may think it's not working but look at "top" to reassure yourself it's winding up. Once displayed it runs ok. I only use it for software or map updates, I upload rides directly into Connect via the "upload" option.

  4. trevorde Silver badge


    A way to run decent software on a Mac!

    1. Woodnag

      Re: Finally!

      VI? EMACS?

      1. jake Silver badge

        Re: Finally!

        vi and EMACS have native Mac ports.

    2. katrinab Silver badge

      Re: Finally!

      I've yet to find anything that you can run on Wine that doesn't have a better native alternative on the Mac.

  5. Henry Wertz 1 Gold badge

    "A way to run decent software on a Mac!"

    To some extent, but there's a big hair in the ointment. There's an ABI incompatibility. It's in Wine's online FAQ (but not any more detail than I give here -- I assume a bug report might have a little more info but I didn't look.)

    MacOS does not store a 64-bit register that Windows does, so 32-bit apps will work (since they don't use the 64-bit registers); a 64-bit app "could" work if it happens to not use that register, but since it's an available register in Windows most 64-bit apps probably do use it.

  6. DrXym

    WINE should run on Windows

    It would be cool to see WINE run natively on Windows, i.e. you run wine.exe <someprogram> and it renders everything to a rendering surface but as far as the software is concerned it is talking to a real Windows. Internally however wine is handling DLL loading, registry, file access etc so the software only sees what it is configured to see. It would enable all kinds of possibilities to chroot jail software, or box it up so it is portable similar to dosbox.

    In a way it is already possible through WSL2 - install WINE on WSL and run the software there. And perhaps when WSL gets Wayland support it will even render into a window on the desktop but I mean genuinely natively.

  7. Sandstone

    Yes, but will it run iTunes?

  8. Anonymous Coward
    Anonymous Coward

    Much as I like and use Linux

    If you want to run a Windows program, just use WIndows or a VM. I've tried Wine over the years and about the only thing that ever ran without problems was Notepad. I realise Windows is a moving target but I just don't see the point trying to run a windows binary native on linux not only because of compatibility problems but also security ones involving networking.

    1. iancom

      Re: Much as I like and use Linux

      LIcensing, especially when you get into the really hairy world of running in hypervisor clusters.

      If all you need is that one service that was written for Windows on one box on your 64-CPU cluster, running it in a Windows VM suddenly means you need to buy 64 Windows Datacenter licences.

      Check the cost on that and then tell me it's not worth using Wine!

      1. whitepines

        Re: Much as I like and use Linux


        This. Relevant to today with remote working, read the Win 10 "Professional" EULA carefully. One user per box if you're using RDP, or pay up for server. And the audits that come with it. And that's not one user at a time, no, it's one specific user only. If anyone else logs on, at any time, it's an automatic license violation. Which is great when the specialty application in question is network licensed, a royal PITA to install, and effectively designed for that instance to be shared among team members as required.

        Given this, as a Linux shop Wine was a no-brainer for that one required application. Even though a couple bugs needed fixing before it was working properly, still came out far ahead on cost. No other Windows software, it's proven cheaper to write replacements or just avoid Windows-specific technology in most cases.

        1. nintendoeats Silver badge

          Re: Much as I like and use Linux

          I was very curious about this, since it could apply in some unexpected situations. I went to the EULA on my work machine and found this:

          Remote access - No more than once every 90 days, you may designate a single user who physically uses the licensed device as the licensed user. The licensed user may access the licensed device from another device using remote access technologies. Other users, at different times, may access the licensed device from another device using remote access technologies, but only on devices separately licensed to run the same or higher edition of this software.

          What I am inferring is that multi-user RDP is only a problem if you are

          A: Using Linux or MacOS to remotely access the machine or

          B: Using something less than Windows 10 Pro to access the machine

          Does that jive with your understanding?

          1. whitepines

            Re: Much as I like and use Linux

            Yes. And since Windows is banished to certain firewalled network segments with no general Internet access, mainly to contain Microsoft's creepy spyware, that clause is a major problem!

    2. Citizen99

      Re: Much as I like and use Linux

      I have a few old Windows programs that work well on Wine, also Kindle-for-PC. Individual installations (like Crossover does 'user-friendly' using GUI with Bottles) ,tar-balled for transportability between OS migrations, backup, whatever.

      Otherwise, using VM goes for some of the rest. Direct running on Windows 7 as a last resort.

    3. Anonymous Coward
      Anonymous Coward

      Re: Much as I like and use Linux

      It's been over 5 years I haven't used MS Windows natively or on a VM. I've been using wine exclusively for all windows applications (90% are games). And almost 95% of games I own run without problems. Wine improvement has increased my list of games that can run in Linux from 65% to 95% in the last decade or so. Probably not buying much of new windows games also helped (many new games I buy are Linux native).

      I transitioned to Linux early on so I don't have a lot of windows applications. If I need content creation I'll probably invest on a Mac, or get by with Linux. I just don't have any need for MS Windows except for games, but even those are now becoming avaiable natively on Linux.

      I really don't miss any of the non-sense clutter of mixed filesystem partitioning, VMs, maintenance headaches, etc. My hard disks are pure Linux all the way, and I don't remember ever having system crash that required re-install in the last decade except for hardware failures (hard disks mostly). Not to mention the pure power of Linux.

  9. Anonymous Coward

    Full circle.

    In 5 years time, when Microsoft has finally thrown their ageing and slow kernel away, and their numerous API layers and frameworks are simply personalities over Linux, I hope they’ll study the Wine code to see how to do the job properly.

  10. inglenook

    Looking forward to better USB support

    I have a need to run a Windows-only program on my MacBook, but this program communicates with some hardware devices via USB.

    I tried Wine and CrossOver last week and neither of them could handle the USB connections. I ended up running the program in a VirtualBox VM - and there the support for USB was exemplary and worked flawlessly.

    Wine and CrossOver need to work harder on the USB support - a lot of hardware companies produce Windows-only support software simply because they don't have the resources to invest in supporting multiple OS and USB is still a very popular choice for hooking up hardware to computers.

    1. Anonymous Coward
      Anonymous Coward

      Re: Looking forward to better USB support

      Are you sure you plugged everything in?

  11. Bill Gray

    Useful to developers

    Starting around 1993, I wrote and sold a desktop planetarium program for DOS, then Windows. (Self-employed, home business.) When the time came to consider a Linux version, I gave Wine a try. Several things broke immediately. Wine appeared to be unsuitable for the job.

    Looking at my source code, I realized that Wine had found bugs. These had slipped by unnoticed on "real" Windows, more through luck than good management. So I not only got my code to work on Linux and Mac; I got bug fixes. There were also a couple of issues where (as best I could tell) it really was Wine's fault, and I had to make some minor workaround to placate it. Not much, though.

    Unfortunately, much Windows code is closed-source and you can't do the sort of fixes/workarounds that I did. But if you do have the source code, I recommend giving Wine a shot.

    1. Anonymous Coward

      Re: Useful to developers

      Wine source code is well worth reading just to get an understanding of what Windows must be doing under the hood. Given the horrors it has to emulate, the code is remarkably good.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon