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

Quoting: ShmerlThis 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

Quoting: ShmerlThis 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 March 2022 at 11:24 pm UTC

Quoting: ShmerlWhat'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 March 2022 at 12:48 pm UTC

Quoting: kokoko3kwine 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 March 2022 at 5:00 pm UTC