[PATCH 2/2] wdscore: Add CurrentIP stub.

[Saulius Krasuckas]

(I am not an I.P. lawyer and certainly not a binary reverser, and long 
time Wine non-contributor already, but just my .02 €¢)

* On 2021-12-28 07:50, Mohamad Al-Jaf wrote:

> How can you see the stack entries if you don't disassemble the file?
> The only way I know of is through WineDbg and that does not seem to be
> correct. The method on that wiki page appears to require looking at the
> assembly code.

(1) The stack doesn't belong to a binary file, it's an ephemeral, 
entirely runtime entity.  So looking at it is safe.

(2) A binary file saved onto disk and the one loaded into memory as 
executable image are already a bit different things, IMO.

Differences are introduced at least during runtime relocations of (the 
position-dependent) sections of an executable image.

(3) Actually there are two methods here:
- 3a, creating the wrapper + looking at the stack pointer change after 
the call, and
- 3b, finding the function epilogues [1], the `ret` instructions.

(3a) It doesn't require disassembly of the function, reading an ESP 
value just before the call and after it.

As this is not a low-level dll (like `ntdll.dll`), there would be 
probably no BSODs during the wrapper run.

It even could be done using `winedbg` and the `br` + `next` commands, 
IIRC, in debug session of the Media Creation Tool.

Maybe it would just do for you. (ie. maybe you'll see that the ESP 
register remains the same right before and just after the call)

(3b) The epilogue reflects only a small, non-core part of the function 
implementation.  It merely shows how the interface between caller (an 
app) and callee (native lib) is organized.

And as the saying goes, 
https://www.google.com/search?q=interfaces+cannot+be+copyrighted

(4) Main concern here seems to be about "submitting disassembled or 
decompiled code" + "what the code does generally". [2]

--- quote ---
While in theory it is still possible for someone that has disassembled 
Microsoft code to document what the code does generally, in their own 
words, this can become a legal grey area.
--- quote ---

> Specifically, it says "ret hhll (where hhll is the number of bytes to
> remove, i.e. the number of arguments times 4)". As far as I know, ret 
> is
> assembly code. So the method listed requires disassembly, no?

Umm, yes and no.  My summary would be following:

By looking at the disassembled calling points of the function and its' 
epilogues [1] _and_ by avoiding to memorize what does core of the 
function do (particularly which other WinAPI functions does it call), 
you stay safe and in compliance with copyrights and other stuff of 
Intellectual Property law.

This is my personal interpretation.

S.

[1] 
https://en.wikipedia.org/wiki/Function_prologue_and_epilogue#Epilogue
[2] 
https://wiki.winehq.org/Disassembly#:~:text=While%20in%20theory,legal%20grey%20area.