Factorio runs so much better than any of this emulationware, it's one of the reasons I love the game so much and gifted licenses for friends using Windows.
Some software claims to support Linux but uses some tricks to avoid recompiling and it's always noticeable, either as lag, as UI quirks, or some features plainly don't work because all the testers were windows users.
Emulating as a quick workaround is all fair game but don't ship that as a Linux release. I appreciate native software (so long as it's not java), and I'm also interested in buying your game if you advertise it as compatible with WINE (then I'm confident that it'll work okay and you're interested in fixing bugs under emulation), just don't mislead and pretend and then use a compatibility layer.
The whole point of wine is to take a native Windows app, only compiled for Windows and translate its Windows calls to Linux calls.
Ehhh. I know it’s in the name, but I feel like the significance is debatable. It’s not a CPU emulator, true. It is emulating calls, which is emulation of a sort.
Related note: if WINE is an emulator why isn't Linux or GNU? They both reimplement parts of UNIX, which was even more proprietary than Windows is today.
On most of these architectures the software eventually executes as x86 machine code, and the distance between x86 machine code and the actual processes inside a modern CPU implementing the x86 code set is so vast you can call a modern CPU an "x86 emulator built in hardware."
I mean, it depends on the context. I don't think it would be wrong to say that Linux "emulates a UNIX environment" or some such, which is closer to what OP actually wrote about Wine.
You've probably used a "terminal emulator" at some point today. ;)
They... are? I mean for that matter Intel/AMD instruction sets are CISC emulators on top of RISC silicon.
Exactly the same way as wine. Wine does not translate the calls, it for most part actually implements the underlying logic.
Win32 is just a bunch of shared libraries: https://en.wikipedia.org/wiki/Microsoft_Windows_library_file...
> That said, Wine can be thought of as a Windows emulator in much the same way that Windows Vista can be thought of as a Windows XP emulator: both allow you to run the same applications by translating system calls in much the same way. Setting Wine to mimic Windows XP is not much different from setting Vista to launch an application in XP compatibility mode.
> [...]
> "Wine is not just an emulator" is more accurate. Thinking of Wine as just an emulator is really forgetting about the other things it is. Wine's "emulator" is really just a binary loader that allows Windows applications to interface with the Wine API replacement.
People who came into using the term earlier tend to think of it more narrowly, but colloquial use of the term has drifted to mean something more generic, e.g. "emulation" used to mean "making one piece of hardware pretend to be another", but now can sometimes just mean, "when one thing acts like another at all".
"Emulator" might be a more recent term—it would be interesting to see the etymology, actually—but it's reasonable to conclude that anything which "emulates" must be an "emulator". (Also, OP didn't actually use the word "emulator".)
Edit: Nope, the word "emulator" dates back to at least the 1800s (although it has certainly grown in usage more recently): https://books.google.com/ngrams/graph?content=emulator&year_...
Aha! It was Apple's Macintosh release, which included an Apple II emulator built-in: https://books.google.com/books?id=Ti8EAAAAMBAJ&pg=PA13&lpg=P...
I do assume most of the increase in usage was related to computers/software, however. The timing is right.
> emulate (transitive verb)
> To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
It's the exact same way its used by FreeBSD for its linux compatibility layer. It's the same way that Wine even uses in their FAQ.
> That said, Wine can be thought of as a Windows emulator in much the same way that Windows Vista can be thought of as a Windows XP emulator: both allow you to run the same applications by translating system calls in much the same way. Setting Wine to mimic Windows XP is not much different from setting Vista to launch an application in XP compatibility mode.
> [...]
> "Wine is not just an emulator" is more accurate. Thinking of Wine as just an emulator is really forgetting about the other things it is. Wine's "emulator" is really just a binary loader that allows Windows applications to interface with the Wine API replacement.
Even your own quote reveals the issue:
> > That said, Wine can be thought of as a Windows emulator in much the same way that Windows Vista can be thought of as a Windows XP emulator
Yet nobody talks about the latest Windows as being an emulator for older windows …
In short, this definition is akin to defining humans as “bipeds without feather”, we definitely fit this definition but it's way too broad to be useful.
Dolphin can run Wii binaries on top of Linux, by emulating a Wii.
Wine can run Windows binaries on top of Linux, by emulating Windows Userspace.
Why would one be an emulator, and the other is not?
Is there some distinction in what an emulator is that goes against common sense?
This reminds of the Transpiler/Compiler "debate." They're both still compilers. They're both emulators (VMs & Compatability Layers).
What the creators meant to say, IMO, is WINVM, "Wine is not a Virtual Machine".
Since the hardware is all the same, there is nothing to emulate or compile.
Or from the other direction - windows NT contains a re-implementation of the win16 API. Is that an emulator?
Except the people actually writing or talking about real “emulators”. You know, for things like NES or Gameboy on x86, x86 on WASM, etc.
Sure, you can argue that VMs or Wine are emulators in the broadest sense, but then I could argue that your CPU is an emulator too since it doesn't really runs ASM, and with that very loose meaning almost anything computers related is an emulator. And in practice that's never what people mean when we're talking about an emulator. (Even this thread started with the wrong postulate that WINE must have incurred a performance penalty because the commented believed it was an emulator).
When I was at Interactive Systems Corporation in the mid to late'80s and we were porting System V Release 3 to the 386 for AT&T, we wrote a Wine-like program called i286emul to run 286 System V Release 2 binaries. We and AT&T called it an emulator [1].
Later AT&T and Microsoft and Sun were involved in various projects to merge features from System V R3, BSD, SunOS, and XENIX into System V R4. As part of that they wanted a way to run 286 XENIX binaries, and Microsoft contracted with Interactive for that. We wrote another Wine-like program for that called x286emul. We and Microsoft called it an emulator too [2]
The XENIX emulator led to the stupidest meeting I have ever had to attend. Microsoft said there was an issue with the kernel that could not be resolved over the phone or email. So me and the other guy working on x286emul had to go to Microsoft for a meeting.
A flag needed to be added to the process data structure that would tell the kernel to make some slight changes to a system call or two, due to some differences between System V and XENIX. It was something like XENIX having separate error codes for some things System V rolled into one, or something like that.
The meeting was about how to set/clear that flag. Microsoft wanted to know if we preferred that it be done as a new flag to an existing system call or if a new system call should be added. I looked at the other guy from Interactive and said something like "A flag's fine for me", he said he agreed. We said "flag" to Microsoft, and the meeting ended.
That couldn't have been handled by phone or email?
And even the starting comment on that thread seems to abide by this definition, as it complains about some (imaginary) emulation overhead when using Wine.
Languages changes overtime as usages evolve: when 80286 was released, the French word «baiser» still meant “to kiss” for most people, now it means “to fuck”.
I especially don't know who's calling Rosetta 2 "not an emulator," given that it's software-emulating x86 arch and actually comes with a noticeable slowdown, not that emulators need to have big overhead.
Most new linux users think that Linux=Ubuntu, does that make it correct? Beginners comes with misconceptions and are then being corrected during their learning process, that's how it works.
> Maybe if that many people are mistaken, they're actually right.
This argument is fabulous, it's like fractally broken, let's have a little bit of fun with it:
I'm pretty sure Wine is niche enough that there's more flat-earthers on this planet than people believing wine to be an emulator, does that number makes them right?
And how about the other people, the majority who know Wine isn't an emulator, would you say “maybe if that many people are correct they're actually wrong”?
> I especially don't know who's calling Rosetta 2 "not an emulator,"
Well, Apple.
You're correct though that Rosetta is arguably an emulator (except, a really sophisticated one, with hardware support, to makes it fast enough) unlike all the other (that interestingly enough you don't address) but if you read my comment again you'll see no contradiction (hint: the key word in that sentence is “market”).
As for my Intel CPU, it isn't pretending to be another kind of CPU. Intel makes a leading implementation of x86. Wine follows Microsoft's Windows implementation and translates to Linux calls, and the entire point is so you can run programs intended for Windows on Linux instead. You can get relative about it, but it's not really, they're clearly different. Either way, doesn't support WINE's acronym.
They're the only kind that doesn't involve a super broad definition of what the word “emulation” means (so broad that most computing actually fits in this definition).
> As for my Intel CPU, it isn't pretending to be another kind of CPU.
Until one day you realize that you can run an x86 program on a 64 bit CPU (but fortunately, this isn't done through “emulation” proper either).
It's reasonable to call that emulation if there's a separate layer for it translating to/from x86-64, rather than the hardware specifically supporting -32. My CPU isn't doing that cause I'm not running 32-bit software on macOS.
(I'm not 100% sold on this; I think "CPU emulator" and "ABI emulator" are both reasonable descriptions, albeit of different things, but that's the distinction that the WINE folks are making.)
WINE should simply stand for WINdows Emulator.
Wine does not aim to emulate a "Windows computer system" (aka a machine which booted into Windows). For instance, it doesn't allow one to run windows device drivers. WINE is taking an approach that ultimately means it is doing a subset of what is possible with full emulation (hopefully in return going much faster).
To put it another way, a mobile phone app with a HP49 interface that understands RPN is not necessarily a calculator emulator. It could just be an app that draws a calculator interface and understands RPN and some drawing commands. It doesn't necessarily have the capability to run firmwares or user binaries written for the Saturn processor.
The "Wine is not an emulator" suggestion was first made in 1993, not because Wine is not an emulator but because there was concern that "Windows Emulator" might run into trademark problems.
Eventually that was accepted as an alternative meaning to the name. The Wine FAQ up until late 1997 said "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".
The release notes called it an emulator up through release 981108: "The is release 981108 of Wine, the MS Windows emulator".
The next release changed that to "This is release 981211 of Wine, free implementation of Windows on Unix".
As far as I've been able to tell, there were two reasons they stopped saying it was an emulator.
First, there were two ways you could use it. You could use it the original way, as a Windows emulator on Unix to run Windows binaries. But if you had the source to a Windows program you could you could compile that source on Unix and link with libraries from Wine. That would give you a real native Unix binary. In essence this was using Wine as Unix app framework.
Second most people who would be likely to use Wine had probably only ever encountered emulators before that were emulating hardware. For example there was Virtual PC from Connectix for Mac, which came out in 1997, and there were emulators on Linux for various old 8-bit systems such as NES and Apple II.
Those emulators were doing CPU emulation and that was not fast in those days. It really only worked acceptably well if you were emulating hardware that had been a couple of orders of magnitude slower than your current computer.
Continuing to say that Wine is an emulator would likely cause many people to think it must be slow too and so skip it.
I'm using an accepted definition of emulation:
> emulate (transitive verb)
> To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
This usage is pretty common, for example FreeBSD has a linux emulation layer that takes Linux syscalls and translates them into FreeBSD syscalls. WINE saying it stands for "Wine Is Not an Emulator" is irrelevant to the fact that it is blatantly is one.
That says very little about whether there'd be a noticeable slowdown compared to running a Linux-native version on Linux natively, though.
But there almost always are problems in that area. I've never had a game run with the same FPS and stability in Wine vs natively in Windows.
But phoronix has tons of benchmarks showing that WINE/proton are in the same ballpark as the native windows version, sometimes a bit slower but as many times a bit faster as well.
Sounds like Wine.
Just like Linux isn't a Unix emulator.
Linux was never designed to be the same as Unix, just similar. But it's more popular now, so Unix users found utility in pretending to run Linux.
Yes, wine is an Windows binary executor with library translation.
https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_see...
Wine is nice until you try to play with sims3 after updating wine. Every new release of wine breaks it.
Please use wine for more than a few months before commenting on how good it is.
It's normal that every new release some game stops working. Which is why steam offers the option to choose which proton version to use. If they all worked great one could just stick to the last.
Also age of empires2 hd, after working fine with wine/proton for a decade, doesn't work with the latest proton for me.
The advantage is that the Wine Ecosystem seems to realize this more than the Linux ecosystem at large, and specifically makes it easy to pin versions and never update. If it worked, why update? Or why not roll back? I'm already used to having to do that with every other part of linux gaming including my graphics drivers...
For multiplayer games, which nowadays get updated every day or something, and old versions are incompatible.
It's one thing if the game keeps updating and then you have to hope it works on the same version of Wine or re-find which version of Wine the new version of the game works with, but presumably that's a problem that the OP isn't happening with The Sims 3.
If the game works on a specific version of Wine, why would you mess with it? Or if you are, then treat it like any major OS update and back up/be ready to roll back if it breaks something. Wine is especially good at letting you make multiple sub-environments, so it's not like your whole system has to be on the same version of Wine.
I could see it being an issue if you were managing your Wine prefixes by hand, but that's like deciding to install your OS dependencies without apt or dnf and then complaining that Linux has bad packages because you chose not to use a package manager.
I literally play multiple online games in Wine/Proton on a daily basis, including Path of Exile, FF14, WoW, and Payday 2. The only one I've had major issues outside of general performance with is FF14 and that's because it integrates closely with Steam and their launcher uses a super outdated version of .NET that Wine hasn't worked out how to emulate. It's been broken for years, and is a known and documented issue with Wine.
Probably you have different unrelated issues.
I’ve used it for several years, and even to play Sims 2 from time to time, and while I’ve had issues the experience only gets better over time. It’s gotten to the point where I can confidently install any game on my Steam library and expect it to run. And be right most of the time.
Age of empires DE will not work with proton. And it's not really a top notch graphics game.
Is there any way to easily choose which Wine version you use for compatiblity? Multiple Wine versions without VMs etc?
Debian normally keeps 2 versions of wine in the repositories, but if none of those 2 work, you're out of luck.
That's not true. There are multiple tools for managing multiple versions of Wine and Wine-related tools for gaming, the oldest one being PlayOnLinux. Lutris is the most widely used one, and works great in my experience.
Initial port of Valve's source engine ran 20% faster without any special optimizations back in the day. So I don't see why the effort is wasted.
Many of the games bundled by HumbleBundle as downloadable setups have Linux binaries. Some are re-built as 64 bit binaries and updated long after the bundle has closed.
I still play Darwinia on my 64 bit Linux system occasionally.
Most of these games are distributed as .tar.gz archives, too.
I can accept and respect not creating Linux builds as engineering (using Windows only APIs, libraries, etc.) and business (not enough market) decisions, but cumbersomeness is not an excuse, it's a result of the other related choices.
In my book, if a company doesn't want to support Linux, they can tell it bluntly, but telling "we want to, but it's hard, and this is Linux's problem" doesn't sound sincere even remotely.
In January, HumlbeBundle removed Linux support from their Trove [1].
HumbleBundle support points out that it's not simple [2]:
> While it is entirely possible to install and run games and programs from the Linux GUI, implementation across distros can be wildly different. For this reason, this guide will explain how to install and launch games using the Terminal.
And, usually, only a small list of distributions are supported, like Ubuntu or Mint. For example, Bundle 9 [3].
All of the above seems to supports the "cumbersomeness argument for Linux games".
1. https://kotaku.com/latest-humble-bundle-change-leaves-mac-li...
2. https://support.humblebundle.com/hc/en-us/articles/219377857...
3. https://support.humblebundle.com/hc/en-us/articles/115011722...
Their contribution easily made up to half of all sales money wise.
I'm not sure I can find the charts now (they were live and per bundle), but I track Humble since day 1. I remember it well.
Yet, I have downloaded all new builds for a couple of games for amd64 from one of their oldest bundles.
It's not as clear cut as it seems.
Yep, and if somebody made your game work under Wine/Proton or Bottles/Heroic, just pay them to support it or create an AppImage/Flatpak and that's the easiest way to get compatibility.
They'd need to do some learning and don't want to. They might have superficially read something about distributions and think that a software cannot run on two different distributions.
I've read this excuse time and time again. And saying it tells me that the person never actually tried to compile anything on linux.
Yet porting to GNU/Linux is not worthwhile.
Even the Linux binaries of then AAA titles are ported by some talented developers, sometimes out of the studio.
I remember porting of Unreal Tournament to Linux was an official effort, but a work of a single guy.
So, I don't expect studio-wide POSIX knowledge on game studios.
No gamer uses that OS. If you think it's hard on linux, it's much harder on osx.
android is not posix, that is completely hidden from the developer.
chromeos is just linux + google tracking.
consoles are a complete separate world.
Please let's try to have a serious conversation. Game developers that use frameworks such as unreal are often unaware of how the underlying system works.
You are conflating "gamer" with "game developer". Don't forget that millions of game devs successfully build and launch games for iOS.
>consoles are a complete separate world.
The PS4 is literally FreeBSD.
With XCode, and tons of visual tools which abstract the OS and device to a great extent, making it almost invisible.
> The PS4 is literally FreeBSD.
Which is also shipped with nice SDKs for everything and anyhting related to PS4.
Win-Win for Microsoft and NVIDIA.
Again, it's just market powers and path of least resistance. It's not technical.
It's always great when stuff like that breaks on Linux. I'm of the opinion it should be impossible for them to even implement this stuff on Linux but broken and ineffective is good too.
Funnily enough with wine we kinda recreated the model of modern windows, where Win32 is a personality on top of the NTAPI which then interfaces with the kernel. Wine sits between the application and the zoo of libraries including libc that change all the time.