Re: Wine policy question: What is considered "reverse engineering"/what is acceptable?

[Daniel Santos]

Thank you all very much for the clarification, it is exceedingly helpful!  I don't care to look at microsoft's code because I doubt I have the stomach for it!  But now I feel much better, that I wasn't doing anything wrong by examining the program state of the misbehaving app (it was on wine anyway).  I don't mind jumping through hoops of various sizes to isolate a problem, but to have to do that without debugging, yikes!, that's like having both hands tied behind your back!

--- On Wed, 5/13/09, Roderick Colenbrander  wrote:

From: Roderick Colenbrander 
Subject: Re: Wine policy question: What is considered "reverse  engineering"/what is acceptable?
To: "Jerome Leclanche" 
Cc: [e-mail], [e-mail]
Date: Wednesday, May 13, 2009, 3:11 PM

On Wed, May 13, 2009 at 10:02 PM, Jerome Leclanche  wrote:
> I thought reverse engineering was only relevant to MS code? As in
> reverse engineering of windows dlls and so on; another application
> would be irrelevant.
>
> That's what I understood from it anyway.

First of all I'm not a lawyer ;)

Correct you should avoid looking at windows code. Regarding Microsoft
code we only allow black box reverse engineering, so you feed the dll
with some input and check the outcome without looking what happens
inside (so without checking debug logs of MS dlls). Looking at
Microsoft debug traces should be avoided as it is similar to
disassembling a program IF it is for the purpose of figuring out what
the black box is doing.

Looking at debug traces of programs is fine and as I said it is
similar to looking at the output of a disassembler. Sure it can happen
that you are looking at calls made by Microsoft code since some
Microsoft dlls are being used but you are not aware of that and you
are not trying to reverse engineer the particular Microsoft dll, so
that would also be fine (though it is a gray area).

Roderick