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.
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.
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.
-
Barath Rk -
Stefan Dösinger