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.
Last edited by Shmerl on 11 March 2022 at 9:15 pm UTC
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
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.
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.
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.
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.
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
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
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.
Last edited by Shmerl on 13 March 2022 at 5:15 am UTC
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
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.
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
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?
Last edited by Shmerl on 15 March 2022 at 2:54 pm UTC
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
See more from me