Comment by iforgotpassword
3 years ago
Agree. Had a few games on Steam crap out with the native version, forced it to use proton with the Windows version, everything worked flawlessly. Developers natively porting to linux seem to be wasting their time.
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.
> 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.
24 replies →
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".
13 replies →
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.
1 reply →
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.
5 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.
1 reply →
> 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.
4 replies →
Wine Is Not an Emulator
Sure, but it's also WINdows Emulator
5 replies →
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
I've been using wine and glibc for almost 20 years now and wine is waaaay more unstable than glibc.
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.
As someone who's been gaming on Proton or Lutris + Raw Wine, I'm not sure I agree. I regularly update Proton or Wine without seeing major issues or regressions. It certainly happens sometimes, but I'm not sure it's any worse of a "version binding" problem than a lot of stuff in Linux is. Sure, sometimes you have to specifically use an older version, but getting "native" linux games to work on different GPU architectures or distros is a mess as well, and often involves pinning drivers or dependencies. I've had games not run on my Fedora laptop that run fine on my Ubuntu desktop, but for the most part, Wine or Proton installed things work the same across Linux installs, and often with better performance somehow.
I specifically mentioned the sims3. That one is constantly broken by updates.
Also age of empires2 hd, after working fine with wine/proton for a decade, doesn't work with the latest proton for me.
6 replies →
I used to say that Wine makes Linux tolerable, but after using it for several years I've concluded that Wine makes Windows tolerable.
Absolute opposite experience for me. The native versions of Half-Life, Cities: Skylines and a bunch of other games refuse to start up at all for me for a few years now. Meanwhile I've been on the bleeding edge of Proton and I can count the number of breakages with my sizeable collection of working Windows games within the last couple of years on one hand. It's been a fantastic experience for me with Proton.
Mind saying what the error is? Linker problem?
2 replies →
Half life works fine for me on latest kernel, latest glibc.
Probably you have different unrelated issues.
> Please use wine for more than a few months before commenting on how good it is.
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.
But not sims 3
Age of empires DE will not work with proton. And it's not really a top notch graphics game.
3 replies →
> Every new release of wine breaks it.
Is there any way to easily choose which Wine version you use for compatiblity? Multiple Wine versions without VMs etc?
Steam lets you do that, but I think it's a global setting and not per game.
Debian normally keeps 2 versions of wine in the repositories, but if none of those 2 work, you're out of luck.
2 replies →
> Developers natively porting to linux seem to be wasting their time.
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.
Isn’t part of the original point not just that Wine is a perfect (dubious, imo) compatibility layer, but that distributing a native port is cumbersome on the Linux ecosystem?
I don't buy the cumbersomeness argument for Linux games. A lot of games in the past and today has been distributed as Linux binaries. Most famously Quake and Unreal Tournament series had native Linux binaries on disks and they worked well until I migrated to 64 bit distributions. I'm sure they'll work equally fine if I multi-arch my installations.
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.
25 replies →
FWIW, targeting proton is likely the best platform target for future Windows compatibility too.
There are plenty of examples of things being the other way around. For example, heavily modding Kerbal Space Program basically necessitated running Linux because that's the only platform that had a native 64-bit build that was even remotely stable (this has since been fixed, but for the longest time the 64-bit Windows version was horrendously broken) and therefore the only platform wherein a long mod list wouldn't rapidly blow through the 32-bit application RAM ceiling.
This wasn't a problem with the game itself. It's their anti-cheat malware that stopped working. On Windows these things are implemented as kernel modules designed to own our computers and take away our control so we can't cheat at video games.
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.