Comment by Aachen
3 years ago
> Developers natively porting to linux seem to be wasting their time.
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.
In case you weren't aware Wine is not an emulator, it is 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.
> In case you weren't aware Wine is not an emulator, it is a compatibility layer.
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.
Usually when you say "emulator" people think there's an inherent performance hit because of a fetch-decode-execute interpreter loop somewhere. Reimplementations of things don't have that performance hit even though they are lumped under the same umbrella as actual interpreters and recompilers.
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.
7 replies →
It’s a reimplementation of the APIs rather than an emulation. Same as how Linux reimplemented UNIX APIs, but it’s not a UNIX emulator.
12 replies →
I think most people interpret emulation as CPU emulation, not a compatibility layer otherwise .NET core is probably just one fat emulator.
1 reply →
By that definition, wouldn't the whole of POSIX simply be an "emulation layer" ;-)
It is not a "Windows Emulator", but it is certainly a "Windows Userspace Emulator"
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".
Wine is more like a re-implementation of windows Userland using a different kernel (and graphics libraries).
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?
The creators also would not call virtual machines emulators because they don't translate CPU instructions, which is their narrow criteria for "emulator" that nobody else seems to use.
10 replies →
The Wii emulator is emulating the whole system including the CPU; WINE describes itself as not an emulator specifically because it's not doing anything about the CPU (hence not working on ARM Linux without extra work).
(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.)
By any well-known definition of an emulator, like https://en.wikipedia.org/wiki/Emulator, Wine is an emulator. It's emulating a Windows system to Windows programs. It's not emulating hardware is all. That WINE acronym, other than being a slightly annoying way to correct people, is wrong. Reminds me of Jimmy Neutron smartly calling table salt "sodium chloride" when really he's less correct than the layman he's talking to, since there are additives.
WINE should simply stand for WINdows Emulator.
According to the Wikipedia link given, emulation is for host and target computer systems. In a computing context, 'emulate' is not a synonym for 'impersonate' - it describes an approach for a goal.
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 people who wrote Wine thought it was an emulator. Their first idea for a name was "winemu" but they didn't like that, then thought to shorten it to "wine".
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.
One might say it emulates windows library and system calls.
Or they might say that it translates windows library and system calls.
1 reply →
Much like one could say it internets Windows userland and system calls with Linux and its userland.
2 replies →
A lot of high level emulation works this way as well. And, similarly, FPGA cores often aren't "simulating game hardware" either.
Surely you see that this is a slight semantic distinction, unless you consider Wine apps to be Linux native?
Have you actually tried to run the Windows version of Factorio through Proton and experienced slowdowns? In my experience, WINE doesn't result in a noticeable slowdown compared to running on Windows natively (without "emulationware" as you call it), unless there are issues related to graphics API translation which is a separate topic.
I believe OP is referring to the fact Factorio has some optimization on Linux such as using fork() to autosave (which is copy-on-write unlike its Windows counterpart), which result in zero-stuttering during auto-save for large-SPM bases.
I’m a huge fan of Wine, but there’s no reason to run Factorio under it. The native Linux version works flawlessly from my experience, and I’m even using a distro where problems with native binaries are common.
> WINE doesn't result in a noticeable slowdown compared to running on Windows natively (without "emulationware" as you call it)
That says very little about whether there'd be a noticeable slowdown compared to running a Linux-native version on Linux natively, though.
> unless there are issues related to graphics API translation
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.
My point was it's not inherent to WINE. There's a lot of Windows games which support Vulkan or OpenGL, those work excellently.
2 replies →
Exactly the same fps, unlikely.
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.
Wine Is Not an Emulator
Sure, but it's also WINdows Emulator
No, it's not, because it's not a emulator
3 replies →
Well you know.. I guess I'm OG when it comes to naming.
I believe it now actually is again, or was, or something. It's a question when dealing with Win16 and now Win32 (Windows-on-Windows).
Ha Perfect!
Yes, wine is an Windows binary executor with library translation.
https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_see...
Except sometimes on aarch64