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.
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Direct Link
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.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
spacemonkey Mar 16, 2022
Google does not know what WINE means
1 Likes, Who?
Quoting: Liam DaweQuoting: elmapulwhy the Meta tag?It covers everything not solely about a specific game.
i think this may worth covering
https://www.reddit.com/r/OdinHandheld/comments/tesr4r/retrogamedb/
anyone knows if there is an project like this in an more advanced state?
0 Likes
Quoting: ShmerlQuoting: Purple Library GuyBut anyway, now the only people learning anything about Linux will be three guys at Google developing a compatibility layer. Game developers will just be targeting Windows as usual. So who gives a damn? And since they're inventing their own little wheel (again), they won't be contributing much upstream . . . maybe a bit to DXVK.
What feels even worse here, that they benefit from the work that already went into faudio, dxvk (I assume also vkd3d-proton, since I doubt they don't care about DX12 games) and other similar important projects. Yet they don't give their project back to FOSS at large and Linux gaming in particular. It's Google we are talking about with their money. When they act in parasitic manner while benefiting from open source projects, it just starts feeling disgusting.
Apple, in summary. So much potential to spend a tiny, tiny fraction of their resources for the betterment of everyone, but they won't, because they can't see a dollar in it for them.
I don't use Microsoft products. I don't use Apple products. Sadly, I do use Google still, but I only use their free products. Google have my data, but that's all they have. Even there, I'm slowly disengaging from their services.
Does a big company even exist that isn't inherently despicable?
5 Likes, Who?
Quoting: tohurQuoting: 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
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 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 March 2022 at 1:41 pm UTC
4 Likes, Who?
Quoting: F.UltraQuoting: tohurQuoting: 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
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 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
0 Likes
Quoting: tohurQuoting: F.UltraQuoting: tohurQuoting: 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
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 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.
2 Likes, Who?
Quoting: tohurQuoting: F.UltraQuoting: tohurQuoting: 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
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 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
"Clean room reverse engineering" =/= "reverse engineering".
"Clean room reverse engineering" cannot even be seen as a subset of "reverse engineering", because the former treats the target as a black box to reimplement, while the latter explicitely disassebles it to understand how it works from the inside.
So Wine is NOT a reverse engineering attempt of the Windows executables and libraries.
Btw, apart from definitions, I think the concept seems clear to everyone.
Last edited by kokoko3k on 16 March 2022 at 1:58 pm UTC
2 Likes, Who?
Quoting: F.UltraWith 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.
Quoting: kokoko3k"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 March 2022 at 4:47 pm UTC
0 Likes
Quoting: ShmerlQuoting: F.UltraWith 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.
Quoting: kokoko3k"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:
QuoteReverse 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:
QuoteThere 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:
QuoteBlack-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.
6 Likes, Who?
QuoteReverse 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".
QuoteThere 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 March 2022 at 10:10 pm UTC
0 Likes
Patreon
PayPal
See more from me