Google talk about their 'Windows emulator' for Stadia and they use DXVK already

Google does not know what WINE means

why 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?

But 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?

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.

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

"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 Mar 2022 at 1:58 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?


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 don't remember the exact example off hand, but I think they did handle some cases of "hidden features" or even bugs that they had to reverse engineer to make things work.

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

What's with all this pointless mental gymnastics and arguing semantics for nothing?

Since F.Ultra is M.I.A., but I still think we need a recap, here it is:
* tohur says google can't do it because it is not possible to do reverse engineering in so little time, so they are using wine.
* mirv disagrees.
* elmapul says wine devs states they didn't reverse engineering windows
* mirv expresses that reverse engineering means disassembling, not reimplementing public interfaces
* f.ultra agrees that wine is not reverse engineering
* tohur insists in saying that wine is reverse engineering, specifically "clean room reverse engineering"
* f.ultra insists in saying wine is not reverse engineering and seems to give another definition of "clean room reverse engineering": "black-box reverse engineering"
* tohur specify that "black-box reverse engineering" = "clean room reverse engineering":
* F.Ultra explains that "clean room reverse engineering" is really different from "reverse engineering" and even different from "black box reverse engineering"
(My note: and he is actually/formally right: https://ethics.csc.ncsu.edu/intellectual/reverse/study.php even if it is a bit borderline IMHO, it may depends on the abstracion level used.)

* kokoko3k fails miserably and confuses "Clean room reverse engineering" with "black-box reverse engineering", but states: "apart from definitions, I think the concept seems clear to everyone." (please note: "apart from definitions")
* Shmerl directed to kokoko3k: "What's with all this pointless mental gymnastics and arguing semantics for nothing?"
...which is exactly what i said, so i don't have an answer for you, obviously, since my intent was to bypass the definitions and focus on the facts.

Facts are that wine is not built empirically. And apart from some minor, but still unintended and undocumented behaviour, wine devs don't need to deduce anything.
This is because they don't target a specific software, but the whole operating system so they don't need nor care to understand what functions are called by a specific software.
Given their goal, they know that they need to implement the whole thing, all of the public interfaces/functions available by using the available documentation.

To Over-simplify the process:

Microsoft Windows:
For every f function implemented in Windows, Microsoft tells you that given certain parameters and types, you have to expect his return vaule(s) to be in a certain way, but don't tells you how it arrives to the results.

Wine:
For every f function implemented in windows, I am free to implement it in whatever way i think is the best so that given the same parameters, the return value(s) will be the expected ones.

Since deduction is needed when you don't know something that has to be deduced, you are still free to call the wine development as you like, but rest sure that there's no deduction involved, and if there is, is by mistake, in the sense that it means Microsoft failed to document something, which is a corner case that also means that the return values of the above function are undetermined, which is obviously an unintended mistake/defect.

And here we can finally return to the cause of the dispute with a reasoned answer:
* tohur says google can't do it because they can't do reverse engineering in so little time, so they are using wine.

On the contrary, they can, in so little time, because they can:
1) use a "-insert something here- reverse engineering" to discover the windows subset of functions they need to implement
2) just use public available definitions of what they discovered in #1 to reimplement them as they please,as long as the documentation is not unintentionally lacking, hopefully, without deducing anything.


Last edited by kokoko3k on 17 Mar 2022 at 12:48 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