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.
They 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
No Wine is not reverse engineered. One of the reasons behind the Wine Is Not an Emulator is that they don't emulate Windows behaviour, what they have done is to write their own versions of "all" the public WIN32 functions and DLL:s and since those are public there are no need for any reverse engineering.
All you have to do is e.g to look here: [https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile) and there you can see what ReadFile expects as arguments and what the replies will be.
The Wine devs then did this for each and every public function that exists. Their early work was the windows loader which they didn't have to reverse engineer either since the .exe format for Windows is also public information.
Now there are some quirks and bugs in the WIN32 API that they have to replicate but that is also not done by reverse engineering, instead its simply done by calling the same function on a real Windows install and see what the function returns, and of course based on bug reports from end users.
Sometimes this approach is called black-box reverse engineering but that is kind of a misnomer since it's too easy to conflate with actual reverse-engineering where you do peek inside. Far better term is black-box testing since that is what is actually done.
Last edited by F.Ultra on 16 Mar 2022 at 1:41 pm UTC
They 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
No Wine is not reverse engineered. One of the reasons behind the Wine Is Not an Emulator is that they don't emulate Windows behaviour, what they have done is to write their own versions of "all" the public WIN32 functions and DLL:s and since those are public there are no need for any reverse engineering.
All you have to do is e.g to look here: [https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile) and there you can see what ReadFile expects as arguments and what the replies will be.
The Wine devs then did this for each and every public function that exists. Their early work was the windows loader which they didn't have to reverse engineer either since the .exe format for Windows is also public information.
Now there are some quirks and bugs in the WIN32 API that they have to replicate but that is also not done by reverse engineering, instead its simply done by calling the same function on a real Windows install and see what the function returns, and of course based on bug reports from end users.
And what you just said is a long winded paragraph describing "clean room" reverse engineering... the very meaning of it. all emulators that are legal do it.. they write their own code to do the same things as what they are trying to emulate. I know WINE is not an Emulator but the acronym isn't telling you its not an emulator cause they write their own code but the fact its a translation layer
They 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
No Wine is not reverse engineered. One of the reasons behind the Wine Is Not an Emulator is that they don't emulate Windows behaviour, what they have done is to write their own versions of "all" the public WIN32 functions and DLL:s and since those are public there are no need for any reverse engineering.
All you have to do is e.g to look here: [https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile) and there you can see what ReadFile expects as arguments and what the replies will be.
The Wine devs then did this for each and every public function that exists. Their early work was the windows loader which they didn't have to reverse engineer either since the .exe format for Windows is also public information.
Now there are some quirks and bugs in the WIN32 API that they have to replicate but that is also not done by reverse engineering, instead its simply done by calling the same function on a real Windows install and see what the function returns, and of course based on bug reports from end users.
And what you just said is a long winded paragraph describing "clean room" reverse engineering... the very meaning of it. all emulators that are legal do it.. they write their own code to do the same things as what they are trying to emulate. I know WINE is not an Emulator but the acronym isn't telling you its not an emulator cause they write their own code but the fact its a translation layer
With Clean Room one usually means the process where one team does look inside, docuements that they see and then you have another team reading that documentating and doing the actual implementation. This is how Phoenix Technologies claimed that they cloned the IBM BIOS, but it's not how Wine is implemented.
With Clean Room one usually means the process where one team does look inside, docuements that they see and then you have another team reading that documentating and doing the actual implementation. This is how Phoenix Technologies claimed that they cloned the IBM BIOS, but it's not how Wine is implemented.
Clean room simply means having no access to the original source code therefore avoiding issues with copyright. Documentation or lack of it is irrelevant to this.
"Clean room reverse engineering" =/= "reverse engineering".
And it totally is reverse engineering. What's with all this pointless mental gymnastics and arguing semantics for nothing?
Last edited by Shmerl on 16 Mar 2022 at 4:47 pm UTC
With Clean Room one usually means the process where one team does look inside, docuements that they see and then you have another team reading that documentating and doing the actual implementation. This is how Phoenix Technologies claimed that they cloned the IBM BIOS, but it's not how Wine is implemented.
Clean room simply means having no access to the original source code therefore avoiding issues with copyright. Documentation or lack of it is irrelevant to this.
"Clean room reverse engineering" =/= "reverse engineering".
And it totally is reverse engineering. What's with all this pointless mental gymnastics and arguing semantics for nothing?
Because we grumpy old timers do not agree with this new floating definition of reverse engineering.
To quote Wikipedia:
Reverse engineering (also known as backwards engineering or back engineering) is a process or method through which one attempts to understand through deductive reasoning how a previously made device, process, system, or piece of software accomplishes a task with very little (if any) insight into exactly how it does so.
None of this matches reading documentation and public include files, unless people now want to claim that every time I type say "man nanosleep" to remind myself of which arguments it uses is reverse engineering and not plain development.
Wikipedia again:
There is a case-law mechanism called "clean room design" that is employed to avoid copyright infringement when reverse engineering a proprietary driver.
It involves two separate engineering groups separated by a Chinese wall. One group works with the hardware to reverse engineer what must be the original algorithms and only documents their findings. The other group writes the code, based only on that documentation. Once the new code begins to function with tests on the hardware, it is able to be refined and developed over time.
To me (and others apparently) this have always been the definition of clean-room reverse engineering since the days of Phoenix Technologies.
Last Wikipedia quote I promise:
Black-box testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance. It is sometimes referred to as specification-based testing.
Besides being old and grumpy, it could also be the fact that I have worked as a reverse engineer some 10+ years ago and among my colleges (and competitors, and attorneys) at the time these terms where defined very hard so I find it kinda strange that it has become so loose over the years.
In any case, I will not pursue this any more since arguing terms and semantics that also happens to be somewhat off topic can only lead to unnecessary misery. So I'll drop this topic completely now and will put my blinders on.
Reverse engineering (also known as backwards engineering or back engineering) is a process or method through which one attempts to understand through deductive reasoning how a previously made device, process, system, or piece of software accomplishes a task with very little (if any) insight into exactly how it does so.
This matches perfectly what Wine does. Arguing against it is just some ridiculous demagoguery I think, especially when this negative argument is hinged on vague criterion of "very little".
There is a case-law mechanism called "clean room design" that is employed to avoid copyright infringement when reverse engineering a proprietary driver.
This idea matches Wine case as well. Particulars like groups in two rooms are the literal source of the term, but it's irrelevant to the concept behind it - avoiding copyright infringement. Are you going to argue you also literally need two rooms to fit it? It would be on the same level as a previous argument.
Last edited by Shmerl on 16 Mar 2022 at 10:10 pm UTC
This matches perfectly what Wine does. Arguing against it is just some ridiculous demagoguery I think, especially when this negative argument is hinged on vague criterion of "very little".actually, it really do! o.o
This idea matches Wine case as well. Particulars like groups in two rooms are the literal source of the term, but it's irrelevant to the concept behind it - avoiding copyright infringement. Are you going to argue you also literally need two rooms to fit it? It would be on the same level as a previous argument.
if wine was working direct on binaries to reverse then, we wouldnt have trouble running things like anti cheat , or any other thing that use hidden apis.
I'm not really familiar with anti-cheat issues, besides that some of them are kernel level rootkits, so you simply can't implement that in userspace which Wine does.
Last edited by Shmerl on 16 Mar 2022 at 11:24 pm UTC
wine devs don't need to deduce anything
Having an API (description of behavior) and implementing it without having the source is still called reverse engineering, even if they don't need to deduce the required behavior outside of it.
That's what black box idea implies. You can observe the behavior, but you don't know the implementation. So you can implement similar behavior to the best of your ability. It's not a guarantee you won't encounter a case where black box will behave differently, but you are getting close enough to be similar in cases you tested.
Last edited by Shmerl on 17 Mar 2022 at 5:00 pm UTC
See more from me