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.
Quoting: F.UltraAnd 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
Quoting: RichardYaoQuoting: F.UltraAnd 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.
Quoting: F.UltraThe 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
Quoting: ShmerlQuoting: F.UltraThe 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