Steven Edwards wrote:
Hello this line:
"However, disassembling NT implementation (WIN32K.SYS) reveals that........." in http://source.winehq.org/source/windows/win.c#L845
was introduced in to winehq by the following patch: http://cvs.winehq.com/cvsweb/wine/windows/win.c.diff?r1=1.61&r2=1.62
Does this not violate a clean rooming the implementation?
I'll remind you that the term "clean room" applies specifically to reverse engineering. "Clean room" means that you reverse engineer the specs out of an existing product, and then use those specs to write a new implementation, without copyright interfering (i.e. - without code being copied as derived work).
I'll also remind you that the case that coined the term "clean room", the Olivetty BIOS clone, was 100% disassembly, and was deemed legal.
The ReactOS code is a derived work of the Wine code in the case and if soon then we have to remove it.
If these are the standards you set (i.e. - higher than your own courts), you may have to remove the whole of the wine code altogether. Then again, there is no other way for you to reimplement Win32 code. The only standard Win32 adhers to is set to be "whatever Windows does". Whenever MSDN and Windows disagree, Windows is, per definition, the correct party. How can you find that out?
Now, in this case it's a single parameter interpretation that was disassembled out of the code. I don't think that's cause for concern. If large scale disassembly takes place, we try to have the disassembler write the specs in human interpreted language, and then have someone else do the actual implementation. This is, AFAIK, what happened with cards.dll, for example. This follows the clean room doctrine to the letter.
Shachar