During the ongoing Google for Games Developer Summit 2022 Keynote, one of the Google team just did a talk on "How to write a Windows emulator for Linux from scratch" to help Stadia.
They already have some existing work available to developers who want it, including their "Stadia Porting Toolkit" which actually uses DXVK to translate Direct3D to Vulkan (since Stadia is a Linux system). However, this translator seems to be their newer approach to running Windows games on Stadia.
With only three people working on it, presenter Marcin Undak said they were able to get some games to run but it's still in the R&D phase and not production ready yet with it taking considerable time to work per-game. However, work is ongoing to hook it all up together with Wine and Proton (for 32-bit games specifically they said) which is one of the paths they will be considering going forwards.
There's already Wine and Proton, which are mentioned in the talk as well but it seems Google wanted something different. Why though? One major reason is how thin Stadia is as a platform. While it is Linux, it's stripped down to the core and doesn't have everything Wine needs to build. There's also a ton of things they don't have to care about that normal desktops do and so "90%" of Wine is simply not needed they said. Additionally, Wine is also apparently challenging when it comes to the build system and debugging.
Quite a technical talk but it's quite nicely presented, to give you a basic overview of what they're doing without going into super tech-heavy details to fry your brain if you're not a developer.
Direct Link
They are also finally about to open the Stadia store without the need to be signed in, so you will be able to actually look around. Incredible it took them this long to do such a basic thing, I can't imagine how many people that put off. Just think if Steam didn't let you view store pages or anything without a login.
Quoting: elmapulanother thing to consider is, unlike wine and most open source projects that are made mostly by volunteers after work in their spare time, this one is made by full time employees.Far as I can tell, Wine is majority made by Codeweavers and has been for years and years, and I'm pretty sure they have more than three full time coders.
I love my 3rd party tools for games I play; would never give them up.
Quoting: Purple Library GuyQuoting: elmapulanother thing to consider is, unlike wine and most open source projects that are made mostly by volunteers after work in their spare time, this one is made by full time employees.Far as I can tell, Wine is majority made by Codeweavers and has been for years and years, and I'm pretty sure they have more than three full time coders.
i was thinking about the first few years of wine development
Last edited by elmapul on 15 March 2022 at 10:42 pm UTC
Quoting: Purple Library GuySome people much more knowledgeable about such matters than me are saying that doing what's needed for making games run is really a very small subset of what Wine has to do, and so the task is feasible. I'm kind of surprised that games only use such a small subset of what software more broadly uses; I guess if I thought about it I would have figured that games do the kinds of things programs generally do, except with more demanding graphics, and so making games work would need a fairly large subset of what Wine does.This sounds like a very targeted approach, supporting a specific title or game engine. For any given game, sure 90% of the API is probably unnecessary- But if you want to support every title from the Win95 era up to the as of yet unreleased title that requires Windows 11 I would guess much of the API is necessary.
Also. as TheRiddick pointed out, this effort doesn't need to concern itself with DRM, anti-cheat, launchers. game store fronts and all the other stuff.
- Windows is well documented and for the fiddly bits you certainly can refer to Wine. As longs as you don't Ctrl-C and Ctrl-V I'm sure the Wine devs would be fine with someone else reading the code. If not, you just use as chinese wall technique and have a third party write documentation from the Wine sources.
- Wine was MIT licensed up to 2002 so that's a good starting point for the basic bits if you want to build something proprietary.
- Making a targeted effort, like a specific game, or game engine is much easier than providing support for the whole Windows ecosystem.
- There's something of a mono-culture when it comes to game engines. Bringing up the first UE game is presumably hard, the second one probably a lot easier. Most older games used custom engines.
- They are using DXVK which is a pretty major building block for any game. Likewise, bringing up a Vulkan or OpenGL game would not be too hard.
Also, efforts like these tend to get easier with time. People learn, share experience, develop better tools. To quote Terry Pratchett:
"No matter how hard a thing is to do, once it has been done it'll become a whole lot easier and will therefore be done a lot. A huge mountain might be scaled by strong men only after many centuries of failed attempts, but a few decades later grandmothers will be strolling up it for tea 'and then wandering back afterwards to see where they left their glasses."
Quoting: elmapulQuoting: Purple Library GuyQuoting: elmapulanother thing to consider is, unlike wine and most open source projects that are made mostly by volunteers after work in their spare time, this one is made by full time employees.Far as I can tell, Wine is majority made by Codeweavers and has been for years and years, and I'm pretty sure they have more than three full time coders.
i was thinking about the first few years of wine development
Well truth be told they tried to implement the Windows 3.11 API (16-bit as well) at the time and then just two years later Windows 95 came and they had to start all over by implementing WIN32. Google also have the benefit of coming to this 29 years later when lots of "this works but this doesn't" have already been settled.
On the other hand Google could very well be at the "how hard can it be" stage only to figure out soon that the answer is "very".
Last edited by F.Ultra on 15 March 2022 at 11:25 pm UTC
Quoting: GuestThey are not reverse engineering Windows. They are implementing specific interfaces - probably all of which are well documented (Microsoft documentation is generally pretty good as it turns out).
Well Microsoft really don't have any alternative, if they don't document it then application and games developers cannot write software for Windows :)
In any case, yes neither Wine nor this new attempt (I highly assume) is done via reverse engineering. Even the slightest wink in that direction would kill Wine legally, that Microsoft haven't gone after Wine in all of these years speaks volumes about how legally sound Wine is developed.
Quoting: Purple Library GuySome people much more knowledgeable about such matters than me are saying that doing what's needed for making games run is really a very small subset of what Wine has to do, and so the task is feasible. I'm kind of surprised that games only use such a small subset of what software more broadly uses; I guess if I thought about it I would have figured that games do the kinds of things programs generally do, except with more demanding graphics, and so making games work would need a fairly large subset of what Wine does.
Yep this is something I think some people loose track of when it comes to Wine. Hell if it wasn't for Wine audio production on Linux would be in a much worse spot, many of the people that do use Linux for audio work tend to end up using some kind of Wine bridge for plugins that don't have a Linux native version.
Quoting: F.UltraQuoting: GuestThey are not reverse engineering Windows. They are implementing specific interfaces - probably all of which are well documented (Microsoft documentation is generally pretty good as it turns out).
Well Microsoft really don't have any alternative, if they don't document it then application and games developers cannot write software for Windows :)
In any case, yes neither Wine nor this new attempt (I highly assume) is done via reverse engineering. Even the slightest wink in that direction would kill Wine legally, that Microsoft haven't gone after Wine in all of these years speaks volumes about how legally sound Wine is developed.
WINE is windows reversed engineered. It is called "clean room" reverse engineering thus they reimplement the windows api without ever decompiling nor seeing windows source code but regardless its reverse engineering if it wasn't it wouldn't be the windows api and windows apps wouldn't even be able to run
Last edited by tohur on 16 March 2022 at 2:10 am UTC
See more from me