Re: Clarification about Reverse Engineering Windows applications

Stefan Dösinger <[email protected]> Mon, 08 Sep 2025 23:00:07 +0200

Newsgroups	gmane.comp.emulators.wine.devel
Message-ID	<[email protected]>

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.

signature.asc (application/pgp-signature, 833 B)