I immediately wondered about macOS, which is dropping 32-bit support as well. One of the first links I found[1] seems to say that there is no 64-bit wine on macOS regardless of library issues, due to an ABI incompatibility. So on the surface it seems like the world is shifting under wine's feet, and they are going to need to do a second level of emulation eventually to keep 32-bit stuff running.
The change Ubuntu is proposing is far less harsh than what macOS is doing. Unlike macOS, Ubuntu will still run 32-bit processes, you just have to provide all of the userspace libraries. Applications like Steam for Linux already do this for binary compatibility reasons, so their usecase won't change much.
Wine's official Ubuntu packages currently rely on the OS to provide these userspace libraries. They would "only" need to change to also build and ship the rest of the libraries, instead of relying on the OS to provide them. Meanwhile on macOS, you can't even run 32-bit binaries, working around that is a much, much larger task.
Remember, though, that the hardware-specific OpenGL library for the user's specific graphics hardware is also a userspace library that has to be provided in a 32-bit version. Even Steam doesn't bother shipping that because it's just not feasible. Without at least some library support from distros it's just not practical to continue 32-bit compatibility.
You can have a little 64 bit process which communicates with the 32 bit process with a named pipe, and acts as a proxy and makes all the syscalls and loads and calls the 64 bit libraries and returns the responses.
Obviously it adds extra context switches and will reduce performance, but if you're running ancient legacy 32 bit code, you can probably afford that.
I believe this is how things like 32lives [1] work.
32/64 bit bridges are really critical when you rely on abandonware, like in media production. I know the classic response is "don't use abandonware" but a lot of that stuff is the equivalent of vintage amplifiers/effects - it has a particular sound to it that doesn't have an equivalent.
The performance impact makes this a no-go for graphics drivers. Lots of games are 32 bits, even recent ones, because they don't need the large address space and don't want to pay the overhead of 64 bits.
Really, this is an incredibly stupid move that has a high likelihood of killing Linux gaming on Ubuntu.
I wonder why Wine doesn't have those libraries on standby. I can understand keeping installer/total install size and footprint down for any application but especially emulation which is already complex and going to push hardware. If Wine includes the right components, what performance hit may be suffered? Or maybe I have this wrong and it won't really matter.
Yeah, it doesn't really matter as wine would just have to load the 32 bit libraries from a different location (say, /usr/lib/wine/lib32 instead of /usr/lib32).
Also, Wine is not that kind of emulator. It provides windows-compatibile libraries but does not do CPU emulation so there's no real significant performance hit. [0]
64-bit WINE exists on macOS now, I have it installed on my MacBook Air. But 64-bit WINE can't run 32-bit Windows apps because it's not an emulator, it's a binary loader and a set of system libraries.
This is really frustrating to me because I am dependant on a small handful of 32 bit Windows Apps, and happily run them in Wine on my Mac currently.
I've been wondering what the solution would be after Catilina dropped 32 bit support and I guess the answer is I'll probably have to start launching an entire VM.
It's not that you can't find modern replacements for them, it's not wanting/needing to if you've got something that already works for you. Some of that crusty stuff from the 1990's and earlier works just fine and the 'modern' replacements bring nothing new to to table for many use cases. So why bother upgrading to a version that phones home and/or is tied to a subscription to accomplish performing the same task in a less streamlined way? Do I do this with most of my software? Absolutely not... generally, but not always, the newer stuff does the job better for me.
You wanted an example, so I'll provide one: I have an ancient version of MathCAD (from 1994 or so) that I still fire up once or twice a year for some computer algebra tasks. Could I upgrade or switch to another application? Sure, but why bother when what I have does the job? (I've even got a 'modern' version of Mathematica but prefer the MathCAD UI from the 1990s... ah, progress!)
> But 64-bit WINE can't run 32-bit Windows apps because it's not an emulator, it's a binary loader and a set of system libraries
The history of the "wine is not an emulator" thing is interesting, since the name originally in fact meant "WINdows Emulator".
As far as I have been able to dig up, the first suggestion to change the meaning to "Wine Is Not an Emulator" came up on Usenet in 1993 [1], when there was some concern that "Windows Emulator" might run into trademark problems.
Bob Amstadt responded to that [2] telling how the name "wine" came about:
> My orignal line of thinking was "winemu", but I didn't like that. Then
I thought of shortening it to "wine". This led me to think of "whine"
and "whinny". I liked "whine", but felt that it was too long.
As far as I have been able to tell, nothing further came of the "not an emulator" suggestion at that time. Sometime over the next four years, it did become an alternative meaning of the name, but I'm not sure exactly when or why. From the FAQ in late 1997 [3]
> 1.2: Why call it 'Wine'?
> The word Wine stands for one of two things: WINdows Emulator, or Wine Is Not an Emulator. Both are right. Use whichever one you like best.
They didn't stop calling it an emulator until the end of 1998. The release notes for 981108 [4] described at thusly:
> This is release 981108 of Wine, the MS Windows emulator
The release notes for 981211 said [5]:
> This is release 981211 of Wine, a free implementation of Windows on Unix
I've not been able to find for sure why they stopped calling it an emulator, but it looks like there were two things. I don't have cites for these because I didn't save links. I apparently though they were somewhere I'd be able to easily find again, and was evidently wrong.
One of the reasons is that Wine can be used for more than just taking a Windows binary and running it on Unix. It could also be linked with native Unix code to make it easier to produce native Unix ports of Windows programs.
The other reason is that computers were getting fast enough that emulators of older hardware were starting to get useful enough for people to be aware of them, but were slow. Most users of Macs and DOS or Windows PCs only ever heard of emulation in that context. Tell them that they can run Unix and keep using their old Windows programs via the "WINdows Emulator" on Unix, and they were going to think that would be very slow.
It was a lot easier to simply stop calling Wine an emulator than try to explain to people that it was just emulators that had to emulate a CPU that were inherently slow at that time, and that since Wine just has to emulate Windows interfaces, which for most programs most of the time will map in a fairly straightforward way to Unix interfaces, it is very low overhead.
Could this be as “simple” (I am aware significant work would be required) as bolting qemu onto the backend of WINE? It’s also becoming more common for OS vendors to ship virtualization toolkits (Hypervisor.framework for instance), could those be an option?
WINE needs 32 bit support. The bulk of windows programs that people still care about are from the 32 bit era, and as they point out many 64 bit apps use 32 bit installers. Maybe it's time for x86 box like DOSbox.
What's interesting about this is... doesn't WINE also support Win16 applications? My understanding was that it does, yet it doesn't seem to require 16 bit libraries from the host OS...
One of the little quirks of x86 is that you can run 16-bit code just fine within an otherwise 32-bit process, and the Win16 API is small enough that it's practical to write wrappers for all of it that just call into the 32-bit functions. This isn't feasible for 32-bit code on 64-bit systems for a whole bunch of reasons.
You're suggesting an emulator, which is absolutely correct and a worthwhile reminder that we can emulate 32bit without any problem.
It's also worth considering the context, WINE (WINE Is Not an Emulator) provides an abstraction layer that doesn't require the overhead of an emulation layer.
DOSbox is similar. (EDIT: apparently it's not, and is actually an emulator. TIL.)
Which is one of its big selling points - old DOS games were used to direct hardware access. Some of them even depend on the clock rate of the PC they're running on. So an emulator that can convert Roland and Soundblaster to modern sound and such is necessary for making old DOS games playable.
I'm curious about Wine's usage and relevance at this point in the Linux desktop story. My assumption is that Linux users(myself included) that use Windows applications(not games), tend to just run a VM in seamless mode for Windows functionality.
I would be curious if others had any insight(anecdotal or otherwise) about Wine usage these days.
Fantasy Grounds is virtual tabletop RPG software, for doing things like playing D&D or Call of Cthulhu with friends over the internet. It's a desktop application which all participants install, and the players' computers connect to the computer of the person running the game. It has features to handle various polyhedral dice and modifiers, character sheets and stats, maps, etc.
A full discussion of FG or a comparison vs the browser-based competitor Roll20 would be off-topic, but the company behind FG officially supports Windows, Mac, and Linux.
Their app is a Windows app on all platforms. For Linux, they test and document Wine, and I can confirm firsthand that it works.
For Mac, I think Wine is involved too, but although they do have documentation about that case, I think most of FG's Mac users (and many of their Windows users) install it via Steam without having to care about Wine. They don't have a version packaged through Steam for Linux.
This example may go away in 2019 or in an upcoming year: they're working on a rewrite to be based on Unity. But this isn't a case where they can just use Unity for the next game in a series. They have a long-standing product with a lot of features and users that shouldn't be broken in the transition, and a small staff that has other priorities alongside the rewrite. The product just happens to be a tool for gaming. So the rewrite has understandably been a slow years-long background effort.
I use Wine from time to time, because some vendors (especially hardware vendors) still expect you to have Windows for silly reasons (eg. to write an update file on an USB key for a car GPS — I'm looking at you, Renault — or to unlock a phone bootloader — I'm looking at you, Xiaomi). That's a life saver in such cases and I can't state how grateful I am for Wine to exist.
And no, I won't run Windows in a VM as I refuse to pay the “Windows tax”.
(Also for games, I still rely a lot on Wine — even if mostly hidden behind Lutris these days.)
You can grab free Windows VMs that Microsoft provides for browser testing. They expire after 90 days, but they are usable for the purposes you mention (except gaming).
Okay, I'll be that guy this time: Why the downvotes? This is a bit hacky and only allows temporary systems, but it appears to be functional, free-as-beer, and works fine for these random one-off cases.
You may use the software for testing purposes only. You may not use the software for commercial purposes. You may not use the software in a live operating environment.
Apart from this being essentially an EULA an therefore not necessarily binding in your country, I don't think that doing the stuff described in the OP would violate these terms.
Don't worry about the downvotes friend, they are merely silly internet points. Someone might come across the comment in the future and find it helpful, and that's all that matters.
Used this to run some Windows-only NES Classic / SNES Classic "hacking" program thingy (hakchi2? Something like that) to add more games to those two devices. Worked great. Wine was a no-go because the program itself did some stuff with (Windows) drivers when needed. VirtualBox. Worked great. I have a Win10 license and could have dug it out but this was easier.
Amusingly enough, all of the low-level hardware access stuff in hakchi2 seems to be done through Windows ports of various Linux-based libraries and tools. The Windows drivers are just there to emulate the normal Linux APIs for low-level USB access. In principle, it would be possible to just chop out all the layers of emulation and drop in the original Linux USB access library using the actual Linux APIs (compiled as a Wine-style DLL so the Windows code could use it) and everything should work fine.
> some vendors (especially hardware vendors) still expect you to have Windows for silly reasons (eg. to write an update file on an USB key for a car GPS — I'm looking at you, Renault — or to unlock a phone bootloader — I'm looking at you, Xiaomi).
Does this kind of stuff work in Wine for you? I generally need to use a VM, because if it needs to talk to another device drivers are involved.
I used to run foobar2000 in wine, because no other linux media player scratched some of the itches foobar covered. There is even a foobar2000 package in the arch aur so it simply installs like any other pacman managed program.
However, once I learned of the wine interface that is available on flathub (for flatpak) I immediately removed wine and its 32 bit components from my system- now that untidyness is neatly contained within flatpak dependencies.
Correct me if I'm wrong, but doesn't flatpak'd wine solve this issue?
Yes, fb2k is the one Windows-only app I just can't let go. The library management, plugins, UI, extensibility, and configurability are just simply unmatched by anything else out there. I likes my music the way I likes it.
I was sure that was a placeholder for you to avoid naming the program until one of the other replies to this comment seemed to confirm that it was in fact an actual name of a program.
A lot of people are extremely dependent on Wine (myself included) to run Steam games through Proton. I have a VFIO-enabled VM reserved for games that don't work, but it's much more convenient to be able to just play games on Linux.
> My assumption is that Linux users(myself included) that use Windows applications(not games), tend to just run a VM in seamless mode for Windows functionality.
Running in a VM requires an additional Windows license. I'm not even sure if you're allowed to use an OEM license for a VM, or if you need proper retail or even one of those "VDA licenses". It's precisely this kind of stuff why I still use Wine.
> Running in a VM requires an additional Windows license. I'm not even sure if you're allowed to use an OEM license for a VM, or if you need proper retail or even one of those "VDA licenses".
Of I understand correctly, and I might not, you either need an Enterprise license or a VDA subscription and you need the user PC that will access the VM to also have its own desktop (pro or enterprise) license if you aren't using a VDA subscription x (that it, it is a license precondition for the VM license that the PC has its own license in addition to any licenses for VMs.) Windows desktop VM licensing seems to be oriented around corporate VDI setups, not desktop-on-desktop local VM use.
I think you are most definitely correct when you are running Windows on a remote VM, like on an ESX. But I always thought that things would be more lenient when you're running it locally, but I might be mistaken. I'm pretty sure though that an OEM will definitely not be OK.
If you're running it in a VM locally on a desktop, my understanding is that you're fine with a normal every-day OS license because the machine itself is what the license applies to. However, MS licensing is needlessly obtuse and, in my experience, nothing short of consulting with about a dozen different "specialists" will even approximate a correct answer, if one even exists.
I couldn't live without Wine (or Crossover). I develop web apps for a small company, and Ubuntu Mate is my primary development environment. A lot of our software relies heavily on Word and Excel because that's what our customers use. And Wine does a superb job of integrating Word and Excel into the Ubuntu desktop. Hats off the the Wine developers for the amazing job they've done.
I'm primarily a Mac user rather than a Linux user. Occasionally there is an app I want to use that just doesn't have a macOS version, so I use WINE because then I can run it nearly-seamlessly. A Windows VM can't conveniently access my files, takes up 20GB of disk space, needs regular updating, takes time to boot and shut down, takes up more screen space than the app window itself, requires a license fee, needs its own 2GB of RAM, etc. If and when WINE works, it “just” runs the app for me.
> My assumption is that Linux users(myself included) that use Windows applications(not games), tend to just run a VM in seamless mode for Windows functionality.
Not really nowadays. The seamless mode tends to be broken so hard with Windows 10 guest in Virtualbox, and VMWare's seamless mode (Unity mode) on a Linux host is dropped a few years ago.
Most importantly, I don't want to run a full Windows VM in my low-powered laptop just to use KakaoTalk, the dominant messenger app in Korea.
> My assumption is that Linux users(myself included) that use Windows applications(not games), tend to just run a VM in seamless mode for Windows functionality.
No, the overhead of a VM is way too much for a single application. This is actually a disaster in the making.
I know, I know, there are plenty of Linux native IRC clients. In fact, mIRC has been quite stagnant lately. But to me, its UI is still unsurpassed (20 years of muscle memory also help), and it has less latency than alternatives (even with Wine).
mIRC is the first client I ever used and I tried other ones (XChat, BitchX since running irc in a terminal sounded appealing, Konversation) and they just felt wrong so I stuck with mIRC.
It's been running perfectly in WINE since the late '90s.
I'm surprised that nobody's made an open source clone, since it's a long-standing app, apparently better than the available alternatives, and fundamentally IRC just isn't that hard.
I exclusively use Linux for work and personal use, and I only use Wine for games. It works surprisingly well, but sometimes requires some arcane tweaking (which you can google, thankfully). I can't see myself using Wine for anything else.
Hi! I really only use Wine for games. I wouldn't use Wine to run any other kind of software, but that might just be prejudice on my part.
I can't point you to an exact tutorial. I usually just google "[name of game] wine ubuntu how to" or occasionally "[name of game] [problem I'm experiencing] wine ubuntu" :) I suppose you could follow the same procedure to install arbitrary software.
Yesterday, I urgently needed to run a piece of software on one of my systems. I had two versions of that software on hand: One for linux and one for windows.
The linux version flat-out refused to run. In my desperation, I installed wine and (to my surprise and the surprise of my coworkers) the windows version ran flawlessly.
Granted, the specifics surrounding my situation was far from typical, but I wouldn't be surprised that the majority of wine usage is also atypical in one way or another. Measuring wine's relevance by your own (or my own) use cases will likely only lead to inaccurate conclusions.
I've heard some people use Wine to run VST plugins under Linux DAWs, because most professional audio plugins only support Mac or Windows unfortunately. Some (older) plugins are only available as 32-bit.
many of the applications for which you would want to run wine (e.g. gaming, the primary use) are performance-heavy. adding a layer of a vm is substantially more performance overhead.
That is much more difficult, might require various unsupported hacks and for a truly robust solution you'd need two GPUs. For games having a Vulkan or DX12 (via DXVK) renderer, wine can be as fast as native Windows with almost none of the hassle. DOOM(2016) is a very good example.
Wine is an incredible peice of software. I tried it for the first time recently and I was deeply impressed. To the point I said to a friend “just write your apps Windows first and deploy with wine!”
Yeah - me too. As someone who's always needed Photoshop and Illustrator in my workflow I have tried to use wine on multiple occasions with no success. Never once was I able to get it configured to the point of usability/stability. VMware Workstation is the only thing that's ever scratched the itch.
I've always thought that Wine is just a compatibility layer for games and entertainment because actual professional software can't run on it without crashing every 30 minutes.
I find asking these kinds of questions to people using professional software like that is akin to asking a professional c++ programmer "why not lisp?".
Imagine you spend a career training on something and random people just tell you to do something else.
Err ... yeah - now you make it sound like I'm incapable of learning/trying new software.
Yes I've tried those alternative solutions and they don't have the same sort of polish and workflow as everything else. Find me ONE professional graphics designer who works 100% in GIMP and Inkscape - they just don't have the same feature set. If you do find people using GIMP and Inkscape in the professional world they almost always use them in conjunction with Adobe tools.
I have a specific list of needed features that do not have parity. "Doing something else" isn't an option when you don't have the tools to do your job/can't deliver for the customer because the software can't support what the printer needs...
In all reality I'm constantly adding new capability to my gfx workflow via software/hardware. I've switched completely over to Procreate on an iPad to do illustration. "Doing something else" is something I'm willing to do if it has value.
GIMP and Inkscape provide zero value to me - they're 100% neutered solutions/"toys" in the professional world. Open source folks (as much as I am one myself) want to think that there's a 1:1 tool for every piece of pro-level software out there and it's simply not the case =|
> Find me ONE professional graphics designer who works 100% in GIMP and Inkscape
My partner does, as do a number of studios and collectives I know in Rotterdam, Brussels, Paris and Porto. They use of course way more tools than Gimp and Inkscape, but work on Linux and exclusively with Free and Open Source software.
For them I feel it’s both about the philosophy, the challenge, and discovering new ways of working. Trying to reproduce an Adobe way of working will always feel lacking. Yet working in a free software ecosystem will make you also discover new tools (Latex, Graphviz etc.) and new ways of working (a lot of people are experimenting with doing print layout with HTML for example).
Of course sometimes it is painful--preparing for print production and especially spot colours without Adobe Acrobat is difficult and requires a a collaborative process with your printer. But it also comes with the thrill of trying a different creative model and the exchange with a small but thriving community of people who are excited about these things.
EDIT: This is not to say that it would be a viable approach for everyone. It’s just to say that such designers do exist, and to try to make their motivations more clear!
Sure - somewhere they exist. But I have yet to run into one in my career. Real question: are they doing paid production work?
I just simply cannot fathom passing off the cost of using buggy/incomplete tooling to my customer so I'm curious if it's people just producing for the open source community using open source tools?
Not trying to rip on your statement, but that's the only reason I can fathom using these tools in any professional context.
The problem is that everyone has their favorite tools, and a barrage of "what about <X>" when you are in no mood to invest the significant time and effort on a standing start for <X> when you've got your existing toolset warmed up already.
> when you are in no mood to invest the significant time and effort on a standing start for <X> when you've got your existing toolset warmed up already
Sure, and on the contrary I've added Procreate on an iPad as my new illustration workflow because it absolutely kills vs. my old Photoshop/Wacom technique.
This isn't a "I'm not willing to try new tools/invest time into learning because I'm comfortable" thing... it's a GIMP/Inkscape are not capable thing.
I use Inkscape and Gimp at work, very tiny minor part of a small part of my workflow.
Today Inkscape was crashing when I tried to rotate a spline with six nodes in an otherwise empty workspace.
I’m probably going to buy a commercial vector graphics app even though my employer won’t pay for it because that sort of bug is a show stopper right when I need the program most.
> Today Inkscape was crashing when I tried to rotate a spline with six nodes in an otherwise empty workspace.
Yep - similar experience with Inkscape. I mean - yeah it's fun and it's pretty capable but it's just really not capable of real work. It's a toy/open source "entry-level" piece of software.
Now imagine someone who needs to crank out 40 unique pieces of vector art within 4-5 days. There's NO WAY they can AFFORD to use Inkscape with those sort of stability issues.
You might as well ask: why not use hobbyist tools with a subset of the features and a tiny fraction of development time and UX work, that basically nobody else in your industry uses?
In a professional setting you can't even think about replacing the established tools with the open source equivalents in the majority of scenarios.
Not sure why you're being downvoted. This is a legitimate question. Although my sibling comment might offer an explanation to your downvotes.
Edit: HN's really gone downhill. I thought we didn't downvote with feelings around here? All I did was point out that it's a legitimate question for people who don't have much experience with Photoshop, GIMP, etc.
Sincerely,
Person who has spent ~2-3x as much time in The Gimp as in Photoshop, and first learned image editing on Paint Shop Pro, not Photoshop, but would still choose PS if you told me to edit some images and my life depended on it, especially if I also couldn't use Google to look up how to do basic freakin' things.
People downvote when they disagree - plain and simple.
If you're suggesting GIMP and Inkscape to someone coming from a pro-level career/background it shows complete ignorance on the topic.
Lots of the time I see this sort of brazen opensource can replace anything/everything attitude - it's simply not true + very idealist. It's likely a ton of pros who use graphics software are coming through and expressing similar thoughts through the downvote button... which in some ways is a "don't take this seriously" button.
Anywho - I agree that the parent comment shouldn't be downvoted, it's a legitimate question to ask if you have no experience in graphics.
Inkscape just released their 1.0alpha. You can argue about naming conventions all you want but here's the reality. It is just not a mature professional product in the same category as Illustrator.
Similarly GIMP has a lot of oddities that Adobe would have found unacceptable in Photoshop versions released 25 years ago. You can do real work in GIMP, but the polish just isn't there.
Since the release of Valve's proton fork wine has gained a massive amount of relevance. Since 2018 it is possible to play thousands of steam games that are windows only on linux.
I use Wine to run Adobe Digital Editions because the proprietary DRM is the only way to get library epub files onto my eReader.
It's very valuable to me for this use case, and AFAIK, there is no viable alternative on Linux (other than cracking the epub DRM, which I really don't want to do and risk giving publishers an argument against public libraries.)
15 years ago I considered switching to Linux. I depend on some Windows applications and, above all, I want to play games. Wine looked like it was almost there, so I intended to give it another try next year.
Year by year I've been trying Wine again and again. As of today, it's still almost there. So, maybe in 2030? By now, I'll stay using Windows.
For years, I've been reluctant to use Wine wrappers like PlayOnLinux, for no reason other than I don't like wrappers. I always ended up getting everything working with bare Wine, but at the cost of long hours (sometimes even days) of experiments.
I've started using Lutris a few months ago (I gave up on getting Wine and DXVK play well together) and, well, that's a life changing experience so far: everything works out of the box. I has taken all the fun out of Wine configuration for me ;)
If all your games are available in Steam, I see no advantage in using Lutris: in my experience, Proton works very well out of the box.
For games that aren't available in Steam, Proton is of little help AFAIK, and that's where Lutris shines.
Also, some people like having all their games in a single place, in which case Lutris may be a solution too, even for Steam games. As my “single place for games” is my shell, I usually skip Lutris and Steam GUIs to start games directly anyway, so…
12 years ago I considered using Windows. I liked some Windows applications and, above all, I wanted to play games. Windows looked like it was almost there, so I intended to give it another try next year. Then Vista happened.
As of present day I am a happy Linux and Wine user and don't plan on switching to anything else.
You keep changing the goalpost. Odds are if you were willing to live with the versions you were using 15 years ago you would find Wine works just fine. Probably even if you just stuck with the versions you were using 5 years ago.
If someone wants to use Windows applications to interact with other users, using a 15-year-old version is really not going to cut it. Office, Photoshop... all of those big ticket Windows apps have added a lot of things in 15 years. You could get that level of compatibility from Libre Office and GIMP.
Some even earlier directx games are damn near unplayable anywhere but real hardware, last time I checked. Heavily tied to a handful of video cards from a span of just a few years. Looking at you, Mechwarrior 2: Mercenaries. I don't think VirtualBox even works in those cases.
I only use Wine indirectly, but I use it frequently because a ton of Steam games that run on Linux use Wine under the hood.
I just don't buy/play games that don't have a Linux version, as a VM was historically (maybe still?) too much hassle in terms of getting GPU to work, etc.
I use wine so that I don't have to spin up a VM for just one application. VMs also involve a lot of overhead.
It seems a little silly to boot an entire OS and have that entire infrastructure just so I can use a Notepad++ plugin I wrote 5 years ago.
I still run LTSpice on Linux using Wine. That's about it though.
With the advent of WSL on Windows and my professional need to use both Linux and Windows, I don't have a lot of reasons to use Wine anymore, or desktop Linux for that matter. Windows + WSL is good enough, and better than the other way around of Linux + Wine or a VM. I fear Wine will become more and more irrelevant as time passes. Killing 32bit support doesn't help them any.
For work in Windows shop,sure, until I need Docker, although I could with faster I/O!
For home and companies that don't architect themselves around specific workstation OS, Linux all the way. I personally rarely use Wine, if ever, but had to use it for my kids requiring software that was available on Windows only.
Yes, and you need to run the Insiders edition of Windows, which is not a good idea to do on your main computer. Most people will expect until WSL2 is available in the standard Windows version.
I had assumed that because 64-bit wine did the “Program Files (x86)” thing, it ran 32-bit Windows apps in a 64-bit process. But now that I think about it, that doesn't make sense.
WINE needs kernel and userland support for running 32-bit x86 code unless it adds an emulator, because WINE actually loads the Windows executable's binary code into the current process (I assume exec() is a good comparison?) together with OS shared libraries. Maybe relevant for understanding this: https://wiki.winehq.org/Wine_Developer%27s_Guide/Kernel_modu...
This will make me more likely to spin up a ReactOS VM if I really want to run any Windows only software, since running Windows in a VM is very resource consuming.
I was looking at computers at Walmart with only 4GB of RAM, the task manager said 3 GB out of 4 GB were being used, and it was just on standby. I don't know what happened around Windows 8 to 10 but having 8 GB of RAM is too little for Windows, the OS takes up half of it out of the box whilst idle.
Can confirm, had a huge "WTF?" on installing Win8 on an HDD and seeing the friggin' OS UI pause constantly for no obvious reason. It was like running Win98 on a 75Mhz Pentium with 16MB of RAM. On my beefy quad-core Intel with 16GB of RAM. Added an SSD, problem went away. They're relying on the SSD to make up for some really lazy crap in their code.
This actually seems like a GREAT thing to untangle all the otherwise useless? 32bit support from the underlying filesystem.
Why have windows apps accessing your 32 bit libraries in /usr (which only the Windows apps need at this point) and instead just a flatpak library of sandboxed 32 libraries?
My steam install is already flatpaked, I'd be much happier if the community just moved this way -
Lots of people in my company use Ubuntu and Wine...
Those news indeed are concerning, specially because a lot of "bureacracy" related software is win32 only for stupid reasons (there is even one company that purchases from us, that only negotiate the actual deals using a online platform that only runs on IE6 and needs some Win32 plugins...)
I use Ubuntu, but should I switch to Debian or something else? What do I get with Ubuntu that I don't get with Debian? The ability to run Windows binaries is important to me.
The biggest difference is probably the desktop UI. After that Ubuntu has a bit more of a unified experience. Part of that is because Ubuntu tends to make a lot more decisions for you, whereas Debian gives you more options upfront. There is a nice integrated GUI(I know Debian has one but its less integrated) for installing packages. Online resources tend to discuss Ubuntu specifically due to its larger market share on the desktop. There is the Ubuntu PPA(Personal Packaged Archives) which don't always work easily in Debian.
They are both fairly similar internally. I have been a long term Debian user(decades), and I never feel out of place working with Ubuntu. That is not always the case when I'm working with Red Hat or Arch or some other distributions. Debian probably requires a bit more fiddling and a bit more general Linux and computing knowledge, but if you have been using Linux for a bit, I think you would be just fine.
Presumably, the kernel will continue to support 32-bit, it's just that Ubuntu won't package various 32-bit libraries anymore. But, can't Wine just bundle any library dependencies itself?
But why not just do a translation — 32bit x86 to 64bit x86 doesn’t meaningfully restrict available instructions, then just* plant a bunch trampolines in the low 4gig to the real implementations in the 64bit adds space.
* I know this isn’t a trivial “just” but it seems like a plausibly achievable approach to me
I wonder if it'd be easier to use qemu's binary compatibility features? Granted, I've only seen that used in Linux, but it's an existing layer that supports running code for another processor as if it were native.
That qemu mode requires a full set of libraries compiled for the processor the code you want to run executes on, so it doesn't help here - if you've got that you can just use the Linux kernel's built-in 32 bit compatibility layer which isn't going away any time soon and get better performance.
32-bit binaries have a different ABI. I think you could put 32-bit code in a 64-bit process and have it use the 32-bit API, but then you still need a set of libraries that work with the 32-bit ABI. Ubuntu is just discontinuing packaging their own copies of the 32-bit ABI compatible libraries. Projects like Wine will just need to distribute that on their own.
The PPC emulator, Rosetta, also required a full compliment of PowerPC libraries and frameworks installed. Though 10.6 did not support booting on PPC and only included Intel drivers, the basic system frameworks were still Universal Binaries — PPC code was included.
A Rosetta-like approach won't work on Ubuntu 19.10 as there will be no 32-bit packages, hence no libraries/frameworks in the appropriate architecture for the Rosetta-like layer to call into.
It seems to me, we'll probably wind up with a base linux container for 32-bit wine support... now, what that is based on, and how well it's maintained is another issue entirely.
By comparison there's DosEMU, DosBox and others for DOS, but Windows/Wine is a much larger surface. I can only hope there's enough community to create effectively a "virtual distro base" that's 32-bit so that said apps can continue to run.
Should be fairly similar to the effort on windows for WSL2 ... Would be interesting to see MS take a similar approach for DOS/Win32 support. Given the changes in MS, would actually be VERY interesting to see MS support Wine32 under WSL2 so that they could remove the 32bit support from windows as well. Unlikely, but one can dream.
I agree that a virtual 32 bit distro is probably the only way this makes sense. I can't imagine that a project like wine has any capacity to do all the security updates and dealing with all of multi distro complexities to work around the fact that they could have wildly different library sets to stand on. It could potentially be done as part of a distro package for Ubuntu but it would be a single person replicating the effort of the core libs for ubuntu over again, just for this one corner project.
Either that or someone's going to have to rebuild WOW64 on top of wine? I guess that could happen.
Alot of non-technical people use (mostly closed source) 32bit windows apps/games through wine on Ubuntu(the most popular desktop linux) - some without equivalents/alternatives.
The only result of this is ubuntu usage share dropping - people run Operating Systems for Apps/Games/Software, not the other way around.
I'll admit I'm a very fringe case, but I loved the ability to play the original Microsoft Entertainment Packs on my Mac using WINE. There's just something about how simple and clean those games are, and people actually like to see them when I have a paused game of rodent's revenge on one of my screens.
I would be concerned about the stability of mixing distros like that, even within a family. If nothing else, those packages are built against different versions of libraries.
Which is one of the many reasons I think package managers are awful. If we lived in a sane world this sort of thing would be a simple matter for any and all distros. In fact, you wouldn't even need distros because you could trivially mix and match the software you wanted without concern for this garbage.
I took Ubuntu's dropping of 32-bit support to only apply to the machine itself, like how openSUSE Leap only supports running on 64-bit hardware but still supports 32-bit libraries[1]. Sounds like Ubuntu's taking it to an even greater extreme.
Regardless, I can think of a couple ways around this:
- Build the 32-bit versions of the relevant libraries and ship them in a third-party PPA (or - ideally - convince Canonical to do this for Ubuntu, thus doing what openSUSE Leap is doing)
- Ship Wine in a snap or AppImage or flatpak or what have you with the relevant 32-bit (and 64-bit) libraries
Almost all Windows installers are 32-bit, even if the application installed is 64-bit. This is so the installer can do something elegant when run on a 32-bit-only system. While this might be changing, 32-bit support is effectively required for almost every Windows application ever released.
How different is the 32-bit Windows application environment from the 64-bit Linux application environment on x64 systems, as far as how system calls are invoked goes, and how memory is accessed?
We had a somewhat similar issue of wanting to run code from a different, narrower, system, although the systems involved were not anywhere near as different as Windows and Linux, back in the mid '80s at ISC. We were doing the 386 port of System V Release 3 under contract from AT&T. Part of the contract required that we add the ability to run binaries from the 286 ports of System V Release 2 and System V Release 3 [1].
The approach was similar to what Wine does, if my limited understanding of Wine is correct. We wrote a program, i286emul, which could be pointed at a 286 program. It would allocate memory for the 286 program and load the program into that memory.
386 Unix was using a simple paging memory model. The 386 still used the selector/offset system even when using paging, but the selectors were loaded once when a program started and not touched again. I think it was using what, in 16-bit land, would be called "small model" (one code segment, one data/stack segment), but with all the segments set to 4 GB, and the real memory management done via that paging system that operated below the output of the selector/offset system.
We had to add a system call (or maybe it was a new command added to an existing ioctl...I don't remember for sure) that allowed i286emul to ask the kernel to set up some 16-bit selectors referencing the parts of the i286emul 32-bit address space at which it had loaded the 16-bit program, or at which it had allocated memory for the 16-bit program's data and stack.
That let i286emul load a 16-bit program into i286emul's address space, get the selectors set up, and then it could load the selectors and jump into the 16-bit program.
Eventually, the 16-bit program would try to do a system call. Fortunately, 16-bit 286 Unix and 32-bit 386 Unix happened to use different mechanisms for invoking system calls, so that when 16-bit tried to do a 286 Unix system call it would be an illegal instruction or a segfault or something like that (I don't remember the exact mechanism it used), instead of something that would try to invoke a 386 Unix system call. (As far as I know, this was pure luck that the people who decided on the 386 system call interface mechanism picked something different from the 286 system call interface mechanism).
So, to handle system calls we just had to have i286emul handle the fault, recognize that it was caused by the 286 program trying to do a system call, and emulate that call. I don't remember if that was as simple as installing a signal handler for the fault, or if we needed some kernel help.
The only other kernel change I remember was making exec recognize 286 binaries, and turn the exec into an i286emul exec, with the path to the 286 program passed as an additional argument.
Later, when AT&T and Microsoft made a deal to add Xenix binary compatibility to 386 Unix, we got the contract for that, leading to x286emul, which was very similar to i286emul. There were a couple of minor areas in which Xenix and Unix differed that we could not take care of in user mode, so had to add a kernel flag [2] to have it slightly change some behavior for x286emul.
How hard would it be to take a similar approach with 32-bit Windows on 64-bit Linux? That is, make it so that a Linux process can reasonably mix 32-bit and 64-code, and give it some control over how 32-bit code sees the processes address space, and then implement a version of Wine that can handle 32-bit Windows programs translating their system calls to 64-bit Linux calls? The issues I can see include:
1. What is actually different between 32-bit code execution and 64-code execution as far as the kernel goes? Is there some flag that marks 32-bit/64-bit, or is it mostly that 32-bit code is simply going to use addressing mode that refer to the double word registers instead of the quad word registers?
2. We greatly benefited on i286emul/x286emul by the very different memory models of the two systems. I'd expect 32-bit Windows and 64-bit Unix to have very similar models which could be a problem...but I'd expect 32-bit Windows and 32-bit Linux to be even closer, and Wine dealt with that, so I'm not sure 32-bit/64-bit would add much difficulty.
3. We also benefited from 286 Unix and Xenix being similar to 386 Unix, so mostly 286 system calls mapped directly to corresponding 386 system calls, with just a little translation of arguments and return codes. Windows and Linux are very different. But Wine is already dealing with that, so as with memory model it is not obvious that 32-bit vs. 64-bit makes much difference.
[1] ...not that there were actually any System V Release 3 on the 286 programs anyone cared about, because as far as I know that port was never completed. We were doing that one for AT&T, too, but there were too many assumptions about memory management baked into the 3B2 source that were not right for the very different memory environment of the 286, and maybe halfway through the port AT&T realized that Release 3 on the 286 was going to suck unless we did some major rewriting rather than just porting, and the 386 was so much better than on one was going to give a damn about running Release 3 on a 286 even if it did not suck, and dropped the port.
[2] That stupid flag led to the most annoying meeting I have ever attended. For x286emul, we were just doing the user mode code. Microsoft was doing any kernel changes we needed. They said an issue arose with our request for this flag that could not be resolved by email or phone. Me and the other guy who were writing x286emul had to fly from LAX to SEATAC, go all the way over to Redmond, to resolve this thing in person.
We got to the meeting, and they presented the issue: should controlling the flag be via a new system call, or via a flag on the system call (or ioctl...I never can remember which it was) that is used for some of the other 286 emulation control? We gave out preference on that, and were sent home. How the heck could that not have been handled by email or phone?
I do use Wine (and Steam with it's various levels of Windows API calling), and I am happy about this.
Sure, it will create some issues during the first stages of this migration, but, more than once, I botched my system in the past with the needed i386 libraries (it didn't happen lately, can't tell if because I finally got my head around it of because they improved the tooling).
Still, in the end, we will all have a "cleaner" system. Either because they migrate parts of the Windows calling to 64bit or because they will keep everything neatly in containers, or, probably, due to a mix of both. But it's high time we improve the current state of these tools.
P.S.: Still trying to get WINASIO to work properly with Wine using one of the latest versions (I am trying to run Ableton in Wine, but the latency is just too high). If anyone has experience doing this, any tips would be apreciated.
I'm so happy that Bitwig is supporting Linux as a first class platform, but it's still unstable enough on Linux that I would never consider using Bitwig on Linux for, e.g., a live performance.
I'm sure they consider crashes on Linux real bugs, so hopefully it's just a few more years of work to have a rock solid DAW on Linux. Super excited about the future of Bitwig.
I tried the preemptive kernel and didn't make a difference.
I also tried Bitwig and it's great, but I use a Push I. That creates an issue (Bitwig support for Push fails in 2 major points: note repeat, and delete functionality... and they keep making changes without adding something as simple as that to the devices API).
There are thousands and thousands of applications available for Linux, and even more being developed as you read this. As much as I love Linux and Open Source, sometimes you happen to love a Windows application so much that you wonder if only this was available on Linux I would completely switch
I doubt that's the case. Everything they've been doing with WSL is precisely to keep you inside the Windows OS. It doesn't make sense to go the other way and give you a reason to use Linux instead.
> It doesn't make sense to go the other way and give you a reason to use Linux instead.
It makes sense for every business unit except Windows to make it easier to run their software on Linux/MacOS (for desktop software, more the latter, for server software, more the former.) A common shim that lets you so that with the same codebase rather than maintaining separate Linux and MacOS versions or porting the whole existsling software to a cross-platform base rather than a Windows base makes some sense.
Of course it doesn't make sense for the Windows unit to promote Linux, but Windows isn't all of Microsoft.
I could be wrong, but I think the overlap of people who use Linux but would also pay for Microsoft software like Office is small enough to not justify the engineering effort.
This makes no sense. Microsoft is on the way to bring Linux inside Windows. They have zero competitive advance, fomenting another system at this moment.
In the current state of technology, wine doesn’t make sense anymore.
20-ish years ago was impossible to have an interchangeable application between two OS, without a huge effort on porting and adaptations trade off. Now we have the web applications running in a handful of different systems. We’re also watching the people theorizing supporting webassembly binaries directly in the kernel. If you don’t want to run a webapp you have virtualization to rescue you.
My last straw with Wine was when I bought navicat for Linux and they shipped a wine wrapped windows app. Really, some tech should just retire.
First off, there are plenty of older Windows applications that currently exist that aren't going to get a port to a modern web app any time soon that work perfectly fine with Wine; even Microsoft doesn't support running Windows 3.1 programs anymore. You could argue that nothing from that era is worth preserving, but are you saying that applications like DOSBox, Snes9X, or UAE aren't useful?
Second, while I definitely support the push to web technology, I'd still rather have something on Linux or Mac than nothing, and often times Wine is the only realistic way of doing that. I agree it's a little annoying when you buy a "Linux" app, and it's just a wine wrapper, but at the same time, at least it's officially supported and works. I didn't get upset with SEGA when I bought the Sega Genesis collection and it used emulation instead of native ports.
[1]: https://forum.winehq.org/viewtopic.php?f=9&t=23005