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 …
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.
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.
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...
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.
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)
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.
"* 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.
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 https://christitus.com/garmin-express-linux/.
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.
"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.
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.
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.
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!
LIcensing,
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.
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?
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.
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
