Tainted code in User32?

[Steven Edwards]

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? The ReactOS
code is a derived work of the Wine code in the case and if soon then we
have to remove it.

Thanks
Steven

__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/

[Abby Ricart]

> "However, disassembling NT implementation (WIN32K.SYS) reveals
> that........."

...
> Does this not violate a clean rooming the implementation? The ReactOS
> code is a derived work of the Wine code in the case and if soon then we
> have to remove it.

Whoa! Slow down there John Wayne! Disassembly is another healthy part of 
reverse engineering. And without reverse engineering, you wouldn't have the 
beautiful thing known as WINE here before you. There were no algorithms 
lifted from the Windows "code", just the discovery of some undocumented 
functionality.

[Shachar Shemesh]

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

[Dmitry Timoshkov]

"Steven Edwards"  wrote:
> "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? The ReactOS
> code is a derived work of the Wine code in the case and if soon then we
> have to remove it.

You didn't provide full comment and some minds on ros-kernel list already
started to distort the meaning of the comment. That patch was a part of
the effort running calc.exe from Windows98 under Wine, not just pulling
an arbitrary code from MS implementation. And since it was back in old
Wine days (commit date: Sat Jun  5 15:23:20 1999) Wine didn't have any
testing framework at that time.

Here is full changelog for the change:

* windows/win.c: Slava Monich 
 o check for both CW_USEDEFAULT and CW_USEDEFAULT16.
 o if x is CW_USEDEFAULT (or CW_USEDEFAULT16) and y is *not*
   CW_USEDEFAULT (or CW_USEDEFAULT16) then use y as a second
   parameter to ShowWindow(). Some apps (CALC.EXE for Win98
   is one of them) use this undocumented feature to create
   hidden window with WS_VISIBLE style set.