On 2021-12-28 18:22, Alexandre Julliard wrote:
Saulius Krasuckas saulius2@ar-fi.lt writes:
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.
No, you should never look at a disassembly of a Windows dll, period.
Please read https://wiki.winehq.org/Clean_Room_Guidelines for details.
Alexandre, I have read it before my answer and I found it to be contradicting other documentation page. So I had to interpret this contradiction.
Do you and other folks agree that part of the documentation is misleading or even incorrect in that regard?
Namely this block: https://wiki.winehq.org/Wine_Developer%27s_Guide/Other_Debugging_Techniques#...
--- quote --- Another method that has been much more successful is to attempt to figure out how many arguments each function is removing from the stack. This instruction, ret hhll (where hhll is the number of bytes to remove, i.e. the number of arguments times 4), contains the bytes 0xc2 ll hh in memory. It is a reasonable assumption that few, if any, functions take more than 16 arguments; therefore, simply searching for hh == 0 and ll < 0x40 starting from the address of a function yields the correct number of arguments most of the time.
Of course, this is not without errors. ret 00ll is not the only instruction that can can have the byte sequence 0xc2 ll 0x0; for example, push 0x000040c2 has the byte sequence 0x68 0xc2 0x40 0x0 0x0, which matches the above. Properly, the utility should look for this sequence only on an instruction boundary; unfortunately, finding instruction boundaries on an i386 requires implementing a full disassembler -- quite a daunting task. Besides, the probability of having such a byte sequence that is not the actual return instruction is fairly low.
Much more troublesome is the non-linear flow of a function. For example, consider the following two functions:
somefunction1: jmp somefunction1_impl
somefunction2: ret 0004
somefunction1_impl: ret 0008
In this case, we would incorrectly detect both somefunction1 and somefunction2 as taking only a single argument, whereas somefunction1 really takes two arguments. --- quote ---
That would help to answer the original question by Mohamad. And would indicate the page to be fixed.
Sadly the content seems to be imported into Wiki on 13:47, 3 February 2016 from the static docs, and now I am not sure how to trace back author of the quoted lines.
S.