Don't want to see articles from a certain category? When logged in, go to your User Settings and adjust your feed in the Content Preferences section where you can block tags!
We do often include affiliate links to earn us some pennies. See more here.

Stadia is something we don't really talk about here too much now, as Google has let it slide considerably from the original aim but it's still going and it seems Google still has some interesting plans for it.

There's an upcoming Google For Games Dev Summit on March 15, which includes Android and Stadia. For the Stadia service that runs on Debian Linux, Google has a few talks including "Play Testing Made Easy on Stadia", "Stadia Adventures in slow server code on Unity" and "Profiling on Stadia" but the perhaps bigger one is titled "How to write a Windows emulator for Linux from scratch?" that notes:

Detailed overview of the technology behind Google's solution for running unmodified Windows games on Stadia. This is a deep technical walkthrough of some of the core concepts with the goal to allow curious programmers to better understand such technologies and potentially to build their own.

We don't know yet if it will be open source but the bigger question perhaps is why they didn't go with all the existing code that has already proven itself? We are of course talking about Wine / Proton, DXVK and VKD3D-Proton which powers Windows games on Linux desktop and the Steam Deck. It's already shown to have great performance.

It's an obvious move for Stadia though to help increase the game library, the same reason Valve created Proton from Wine to bring more games to Linux systems. We'll be taking a look over the talk on March 15 and will make some notes for you.

Article taken from GamingOnLinux.com.
18 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. You can also follow my personal adventures on Bluesky.
See more from me
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
56 comments
Page: «3/3
  Go to:

Shmerl Mar 11, 2022
I recommend you to move along together with those who didn't like Wine being called an emulator. I see no point in any of your arguments above. I called Wine an emulator and will continue calling it so.


Last edited by Shmerl on 11 March 2022 at 9:15 pm UTC
F.Ultra Mar 11, 2022
View PC info
  • Supporter
You've got the whole thread at your disposal to cite all those. Nobody here was defining it this way,

And I'm not talking about people here, but about those who were originally annoyed at Wine calling itself an emulator, causing it to be rebranded as "not an emulator". So not sure what your point is exactly. None of these people are here I presume.

But that never happened, Wine "never" called it self an emulator (except in some parts of the old FAQ). In fact the naming came not as a response to "is this an emulator or not", instead it was triggered by SUN having just released Wabi and suddenly renamed it that from WABI and although they had announced it like this prior they now refused to acknowledge that it stood for "Windows Application Binary Interface", one would imagine that the layers at SUN got cold feet and wanted to put restrictions on their engineers.

So people where joking on Usenet in August of 1993 (the initial release of WINE came in July 1993 which only consisted of a simple loader, hence the project was named the Windows Loader at the time) that the "Linux guys" should call their software "WAW" ("WAW ain't Windows(tm)") to which David C. Niemi (then kernel hacker from Red Hat) famously wrote:
How about "Wine Is Not an Emulator"?

The entire discussion is preserved thanks to Google Groups: https://groups.google.com/g/comp.os.linux.misc/c/_g3F2H4ieDc/m/n5FE_ygtpdoJ?pli=1

Official WINE timeline:
 
June 26, 1993 Wine 0.0.2 basic loader by Bob Amstadt and Eric Youngdale
July 1 Wine 0.0.3
July 5 Wine 0.0.4
July 6 Wine+TCL (tcl code by Peter MacDonald)
July 8 Wine 0.1.0 using tcl/tk
July 15 Wine 0.2.0 using Xt/Xlib
July 28 Upload directory renamed from Wabi to Wine
August Naming discussion, “Wine Is Not an Emulator” first suggested by David Niemi



Last edited by F.Ultra on 11 March 2022 at 11:54 pm UTC
tpau Mar 12, 2022
Google has deep pockets and I think Upstream wine could benefit from it.
I don't like the idea of having another fork besides Proton as that would mean duplicated work and people missing bugfixes if they choose the wrong edition.
Shmerl Mar 13, 2022
Wine "never" called it self an emulator (except in some parts of the old FAQ).

If the FAQ references it, it clearly was meant to be called an emulator.
F.Ultra Mar 13, 2022
View PC info
  • Supporter
Wine "never" called it self an emulator (except in some parts of the old FAQ).

If the FAQ references it, it clearly was meant to be called an emulator.

An old FAQ that was written by P. David Gardner who according to his own words in the FAQ:
who is not otherwise involved in Wine
. I don't see him as an authority on this matter at all, he was simply a nice guy who decided to write a FAQ back in 1995 to help the project.
Shmerl Mar 13, 2022
I don't see him as an authority on this matter at all, he was simply a nice guy who decided to write a FAQ back in 1995 to help the project.

Then why a sudden need to emphasize "not an emulator" at one point? Today Wine kind of stopped doing it, which is a good thing.
F.Ultra Mar 13, 2022
View PC info
  • Supporter
I don't see him as an authority on this matter at all, he was simply a nice guy who decided to write a FAQ back in 1995 to help the project.

Then why a sudden need to emphasize "not an emulator" at one point? Today Wine kind of stopped doing it, which is a good thing.

There where never "a sudden need" when it was done two months into development of the project back in 1993 long before Wine could even run a single .exe, didn't you even read the post that you replied to?

edit:

And we have this post to Usenet in Aug 1993 by the lead dev (or should we say one of the two only devs at the time):
It should be pointed out that the Windows binary will be
running directly - there will be no need for machine level emulation
of the instructions. Sun has reported better performance with their
version of WABI than is actually achieved under MS-Windows -
theoretically the same result is possible under linux.

The word to look for here is "running directly".


Last edited by F.Ultra on 13 March 2022 at 5:02 am UTC
Shmerl Mar 13, 2022
You didn't really answer the question focusing on the wrong part. The main point is - why even bother with explicit negative phrasing "not an emulator"? How sudden it was is not really relevant to that.

Saying it was just a joke kind of doesn't explain the motivation behind it if it was put into the official name of the project. Also, Wine developers aren't Sun, so why would they care about what Sun lawyers were worried about?


Last edited by Shmerl on 13 March 2022 at 5:09 am UTC
F.Ultra Mar 13, 2022
View PC info
  • Supporter
You didn't really answer the question focusing on the wrong part. So I can simplify it - why the need for explicit negative phrasing "not an emulator"? How sudden it was is not really relevant to the main point.

So it looks like I didn't understand your question, since you used the word "sudden" it looked like you put emphasis on that.

Ok, so the need to explicitly phrasing it as not being an emulator was an early attempt at clearly show that it wasn't an emulator, something that clearly didn't work considering that we still 29 years later are talking about it.

One also needs a bit of history here. There had been prior attempts at running Windows applications, all those where based on emulation and required you to install msdos since they where written for non x86 hardware. Then SUN came up with WABI which could run Windows applications faster on SunOS due to WABI instead of being an emulator being a reimplementation of the Windows DLLs that applications used. This was the inspiration behind Wine, hence why it was first called Wabi internally.

Or to quote one of the two devs at the time (aug 1993)
It should be pointed out that the Windows binary will be
running directly - there will be no need for machine level emulation
of the instructions. Sun has reported better performance with their
version of WABI than is actually achieved under MS-Windows -
theoretically the same result is possible under linux.
Shmerl Mar 13, 2022
Well, I mean why did Wine developers need to bother about some Sun lawyers being scared calling their tools emulators? I don't really get that part. For all intents of the dictionary meaning, I see no issue with calling Wine an emulator. No one claimed it emulates everything from Windows. It does emulate what it provides, quite clearly.


Last edited by Shmerl on 13 March 2022 at 5:15 am UTC
RichardYao Mar 14, 2022
And no WINE is not a OS emulator, it's a reimplementation of the Windows API. Not really sure how a emulator for a modern OS would look like but perhaps this one from Google is. Perhaps they emulate it down to how e.g the Windows Scheduler works to make games get the 100% Windows experience that WINE can never do.

It is a Windows emulator just like OS/2's DOS program support was a DOS emulator. In computer science, the notion of OS emulation is well established and predates WINE's creation.


Last edited by RichardYao on 14 March 2022 at 9:36 pm UTC
F.Ultra Mar 15, 2022
View PC info
  • Supporter
And no WINE is not a OS emulator, it's a reimplementation of the Windows API. Not really sure how a emulator for a modern OS would look like but perhaps this one from Google is. Perhaps they emulate it down to how e.g the Windows Scheduler works to make games get the 100% Windows experience that WINE can never do.

It is a Windows emulator just like OS/2's DOS program support was a DOS emulator. In computer science, the notion of OS emulation is well established and predates WINE's creation.

OS/2 contained a proper emulator for MS-DOS (just like DOSBox), it did not simply reimplement the MS-DOS API due to how MS-DOS works this couldn't be done so they had to perform a real emulation.

The CS definition of emulation is "the use of an application program or device to imitate the behaviour of another program or device", Wine does no such imitation. An application running under Wine does not get an imitated Windows environment except for the file-system which is the single thing that Wine emulates, for everything else the Windows application runs in a Linux environment which have it's pros (performance) and cons (compatibility).

Had Wine been an emulator then things like EAC would have worked out of the box.
Shmerl Mar 15, 2022
The CS definition of emulation is "the use of an application program or device to imitate the behaviour of another program or device", Wine does no such imitation. An application running under Wine does not get an imitated Windows environment except for the file-system which is the single thing that Wine emulates, for everything else the Windows application runs in a Linux environment which have it's pros (performance) and cons (compatibility).

This is incorrect, or at best not a strictly defined idea to claim that you can't interpret it differently. Using dictionary definition of emulation, it means imitation. The rest is a stretch that no one can claim is the only way to stretch it.

Wine totally imitates Windows in some ways. Running in the Linux environment doesn't preclude that fact. These ways include providing ABIs that Windows program expects to behave in the same way Windows does.

Meaning, you can even write a test of behavior, and at least in ideal case of Wine reaching its goal for that particular component, it should produce the same result in Windows and in Wine.


Last edited by Shmerl on 15 March 2022 at 2:15 am UTC
F.Ultra Mar 15, 2022
View PC info
  • Supporter
The CS definition of emulation is "the use of an application program or device to imitate the behaviour of another program or device", Wine does no such imitation. An application running under Wine does not get an imitated Windows environment except for the file-system which is the single thing that Wine emulates, for everything else the Windows application runs in a Linux environment which have it's pros (performance) and cons (compatibility).

This is incorrect, or at best not a strictly defined idea to claim that you can't interpret it differently. Using dictionary definition of emulation, it means imitation. The rest is a stretch that no one can claim is the only way to stretch it.

Wine totally imitates Windows in some ways. Running in the Linux environment doesn't preclude that fact. These ways include providing ABIs that Windows program expects to behave in the same way Windows does.

Meaning, you can even write a test of behavior, and at least in ideal case of Wine reaching its goal for that particular component, it should produce the same result in Windows and in Wine.

Does Musl emulate glibc according to you?
Shmerl Mar 15, 2022
I don't really see a point in arguments about semantics of dictionary words. I'm not on board with those who try to limit the meaning of emulates without a real reason.


Last edited by Shmerl on 15 March 2022 at 2:54 pm UTC
Shmerl Mar 15, 2022
To use more computing science related idea - "if it walks like a duck and it quacks like a duck, then it must be a duck" (also called duck typing). Meaning imitation of behavior in computing can be seen as equivalence, becasue in the end of the day we care about computation result, not necessarily about particulars of the implementation of it.

I have no issue calling this emulation, it perfectly fits the dictionary meaning of the word.


Last edited by Shmerl on 15 March 2022 at 3:01 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.