Re: Clarification about Reverse Engineering Windows applications

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

On Tue, 9 Sept, 2025, 2:30 am Stefan Dösinger, <[email protected]>
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.
>
>