Wine disassembly and reverse engineering rules.
Peter Dons Tychsen
donpedro at tdcadsl.dk
Sat Aug 4 21:23:15 CDT 2007
I noticed your comment the forums here:
It was regarding the fact that it is not allowed to disassemble and
reverse engineer Microsoft DLLs. I understand this part, as their
license prohibits it (EULA).
However, i would be more clear if someone would make these rules
commonly available on the WineHQ website. I tried to search for it but
all i could find was:
"Disassembling native Windows DLLs is virtually always useless, as a
technique disassemly is usually used to find out why the application is
crashing in an otherwise unexplainable way."
This text does not make it sound prohibited (some might read is as an
actual encouragement - (useless != probited)).
This should probably be fixed. It should make it crystal clear was is
allowed and what is not. This would help avoid situation like the one
Another problem is that i want to introduce something which i am not
sure is covered or not by what is "not allowed".
I want to introduce a function which can check if SendMessage() or
PostMessage() was the reason a message ended up in a Proc handler.
By browsing MSDN, i found out that i can accomplish this by using the
documented function StalkWalk64(), which can examine the call stack. I
would then introduce this into the test system for DLLs like "user32".
By running the test on original Windows we could know which messages we
are incorrectly "posting" or "sending" where it should have been the
opposite. This could fix some vital issues.
I don't think there is a problem as i am just using documented APIs from
MSDN, but since it includes looking at the call stack, i was curious if
there might be a legal problem.
I don't want to put the idea to use or release it if it in any way is
Please think long and hard before you reply.
Thanks for your time,
More information about the wine-devel