It's not an emulator
I'd like to see the copy of this article before it was edited.
I bet the author wrote "WINE is not an emulator ... "
Fans of Apple's M1 silicon have some more code to play with as the Wine team emitted version 6.0.1 of the Windows-running platform with support for wine64 on the new chippery. The maintenance release has been a while coming, although support has been lurking in the development branches for a while. Wine is a neat solution to …
Valve are basically using it commercially, (as part of Proton) for their Linux version of Steam, as a means of allowing Linux users to play Windows games, i.e. those without a native version.
I've also seen other people using it to let them use applications like Notepad++ on Linux, as it doesn't have a native version there.
... salute the folk who've worked on it ...
... is it necessary any more?
For me, the answer is a resounding yes.
Wine and to a lesser extent, Judd Montgomery's J-Pilot, were the two applications that enabled me to finally open the Linux door for me.
Keeping my Pegasus email client, which at the time I had been using for almost 20 years, was the dealbreaker.
Although I tried many native Linux options, I wasn't able to find one that checked all the boxes.
Wine enabled me to use Pegasus Mail under Linux and I'm very happy with it.
As always, YMMV.
Fair enough. Thanks for the info.
I switch to pure Mac some years back and never looked back. Most people I know just run pure windows or pure Linux and rarely bridge the divide.
My original post read more confrontational than I’d meant it to be (which was zero).
"... but is it necessary any more?"
As the sub-heading says, "For that one weird app..."
In my case, a program called Logic Friday.
I not only need to run it on WINE, I have to download it from Internet Archive now, as its creators seem to have vanished.
(Link, for those whose curiosity is piqued: Logic Friday.)
I suspect you mean the rig couldn't run Windows, which post XP was a memory hog.
Done correctly, the guest OS should be able to have nearly all the resources of the machine with the host OS just managing the VM. I know I was able to run Windows XP multiple VMs on a MacBook with 4 GB RAM in 2008 and as I was remote controlling InDesign this was a godsend.
... mean the rig couldn't run Windows ...
I meant exactly what I wrote: at the time my rig had more than enough power/memory but did not have a VT-x/VT-d enabled processor.
Now I host two VMs, one being XPSP3 to run the local IRS' application, the other is a test version of Devuan Linux.
Eh? VMs existed on x86 CPUs before those ISAs included virtualization extensions. Do none of the various hypervisors support those CPUs any more? (I don't pay a lot of attention to this area.)
There are still good use cases for WINE rather than a VM, of course. Running an entire VM for one application that will run well under WINE is an absurd waste of resources on a smaller system.
Someone else downvoted you, I can't speak for them, but you are wrong on two counts. (1) If Windows software works both in a VM and under Wine (or CrossOver), then Wine is far easier, a beginner can do it. (2) While it's true not all Windows software runs well or at all under Wine, equally it's far from true all Windows software runs well or at all in a VM. Usually the reason why it won't work in a VM is different. One application I have tried fails under Wine because the registry is not perfect, and fails in a VM for some DRM reason, and probably the developers like it that way. I will grant that *more* software works in a VM than under Wine, just don't say guaranteed.
I've been running Windows VMs for over a decade and have yet to come across software that won't run in them. But in any case, if something won't run in a Windows VM (and you can choose your pick) then it almost certainly won't run in Wine. The overheard on modern CPUs with hypervisors is trivial.
Wine was a nice idea at the time and is a great demonstration of technology but it's also fatally flawed. Virtualisation of the hardware supplanted emulation of the sofware around the time IBM added support for Windows to OS/2. This is why there are virtualised mainframes out there running code for which the source code no longer exists.
If you're only using it for one application then fine, but switching between programmes and maintaining a second login are all a bit of a pain. I use Windows in a VM fairly regularly and would prefer to run applications as if they were native (however because other people need windows too, and it's not just for one or two applications that can be made to work with WINE the VM is the better option in this case).
> Wine was a nice idea at the time and is a great demonstration of technology but it's also fatally flawed. Virtualisation of the hardware supplanted emulation of the sofware around the time IBM added support for Windows to OS/2. This is why there are virtualised mainframes out there running code for which the source code no longer exists.
The number of users running WINE is rocketing skyward, especially in the guise of Valve's Proton which is opening the horizon for a lot of people that do not run Windows to run Windows-only games and it is doing it extremely acceptably.
I used to have a separate boot partition for Windows 7 to run games but since Windows 7 support was dropped and I upgraded my hardware to something that didn't really work well on it, I realised that for most things I just didn't need Windows any more. I've been running AAA games on a separate Linux partition ever since. It used to be that most games had big problems running on WINE. That hasn't been true for quite a while.
There are also a growing number of people that just don't want to run Windows with its increasingly aggressive tracking and profiling, something that I can sympathise with.
it is doing it extremely acceptably.
I think you win the prize for oxymoron of the week!
The Valve reference is interesting but should, I think, be qualified in that most users probably don't know that Wine's being used nor do they care. And Valve is probably in a position to ensure that all the relevant APIs are available.
I suspect that the majority of usages of WINE in one way or another are game-related.
The WINE team have been making a lot of progress over the years but Valve's recent involvement has accelerated that somewhat in terms of progress and exposure. The recent Vulkan support is certainly welcome.
I had some old Siemens software for my PBX. It required XP - this was Windows 7 time frame, through Windows 10.
It wouldn't install on 7, 8 or 10, it had to be XP. XP Mode on Windows 7 didn't work - no direct hardware access. Likewise, in a VM, with USB passthru, it still wouldn't work. It had to be a physical XP machine.
I didn't try it with WINE, but that probably wouldn't have helped either, in this particular case.
I just kept an old XP laptop in a cupboard for those rare times I needed to change settings or export the call logs.
Perhaps I could add to that, that not all Windows applications run under a recent version of Windows.
WINE has compatibility layers so it can emulate previous versions fairly well.
I know some versions of Windows also do but it doesn't always work, especially if the application is a bit naughty.
This post has been deleted by its author