Ah, I understand now. Thank you for the clarification.

On Tue, 9 Sept, 2025, 2:30 am Stefan Dösinger, <stefandoesinger@gmail.com> wrote:
Am Sonntag, 31. August 2025, 05:38:58 Mitteleuropäische Sommerzeit schrieb
Barath Rk:
> Is it alright to RE Windows applications as long as you are not trying to
> RE MS API implementations or MS applications? I do not quite understand the
> "Clean Room Guidelines" in this regard and would like some clarification.

Try to avoid disassembling applications, even non-MS ones. It is is usually
not necessary or a good way to figure out what is going on. In my 20 years of
working on Wine I've solved only two bugs by reading an application's assembly
(*) - I find it a lot more useful to look at Wine logs or other more API-
specific tools like RenderDoc (for 3D stuff). That said, it is a legitimate way
to understand an application's behavior (but *not* the Windows API behavior)
and on occasion the only feasible way. Check if either the application license
allows reverse engineering or the law of your country allows reverse
engineering for compatibility purposes (e.g. the DMCA does allow this).

Any implementation in Wine should be based on what tests show that Windows
does though. So don't make API Foo() do something because FoozleWare expects
this behavior. Find out what FoozleWare expects, write a test for Foo(), then
write/change the implementation based on the test findings. Often it turns out
that the initial conclusions from debugging were not entirely right.

*: Those bugs were a buffer overflow triggered in Half Life 2 due to bigger than
expected font metrics and a weird combination of DDCAPS/D3DCAPS flags expected
by some Win95 game.