[ros-dev] Bye bye

WaxDragon waxdragon at gmail.com
Thu Jan 19 15:47:42 CET 2006

On 1/19/06, Steven Edwards <winehacker at gmail.com> wrote:
> Hi,
> Speaking as someone that is mostly ignorant of kernel internals, lets
> pretend I am a judge....

You are not a judge with years of experience in law. Whether or not
you have any kernel internal knowledge is also irrelevant to this
thought experiment.

> On 1/18/06, Alex Ionescu <ionucu at videotron.ca> wrote:
> > Yes, when I analyzed the fast call code (yes I looked at disassembly) I
> > saw that check, and I copied it.
> Why did you have to do this? Is it not possible to write a driver that
> abuses fastcall to make a mostly working implementation without having
> to 1. look at and 2. copy the existing object code of Windows?

Alex clearly stated that there is only one way to perform that stack
check, let's quote him properly:

"Note however, that there is only one way to check the stack: cmp ebp,
esp. Unless you want to consider cmp esp, ebp as an alternate method."

As Casper said, it is legal to use that information, but not legal to
*copy/paste* it into ReactOS.  Alex clearly comprehends what that bit
of assembly does.

> > I would also like to point out that unlike certain code which I've found
> > in ReactOS (The old ftol implementation comes to mind) which comes from
> > assembly, my code is clearly commented, organized and structured, and
> > shows that I know what I was doing any not merely copy/pasting some
> OK so someone else sneaked something in that violates the rules and it
> was not caught. Lets just check your argument for a moment and say you
> could be wrong about your development methods. Being ..."clearly
> commented, organized and structured..." does not amount to a hill of
> beans if I am violating the law and or project rules. I can make bank
> robbing plans that are "...clearly commented, organized and
> structured..." I don't think that will gain me much ground in court.

This analogy is invalid.  The legality of this issue stems directly
from whether or not he wrote the code.  Robbing a bank is _always_
illegal, writing code is only illegal if you copy/paste it from a
legitimate author, or implement a patented method.

Alex's structured and commented code demonstrates comprehension.  In
this case, where the code's function is clear, and constrained by
implementation details, the code will be similar by anyone who
implements it.  Alex's comments and code structure shows that he
understands what is going on in the assembly, and most likely shows
that he wrote the code, as opposed to just copy/pasting existing code.

> > assembly. This is much unlike the old ftol code, which was simply an
> > exact 100% duplicate of the windows code, with 0 comments and using
> > hardcoded values which were not explained (clearly showing that the
> > implementer had no idea of what the code did).
> Can you explain to me why the magic numbers match Windows in
> ke/i386/trap.s? Like I said I am mostly ignorant of kernel internals
> but this was asked of me...
> The code in ke/i386/trap.s looks kind of suspicious, because it uses
> alot of magic numbers...

It only looks suspicious since you are not a kernel developer.  Again,
not something a judge would concern himself with.  Now the

>     /* Push previous mode */
>     push UserMode
>     /* Skip the other registers */
>     sub esp, 0x48
>     /* Hack: it seems that on VMWare someone damages ES/DS on exit.
> Investigate! */
>     mov dword ptr [esp+KTRAP_FRAME_DS], KGDT_R3_DATA + RPL_MASK
>     mov dword ptr [esp+KTRAP_FRAME_ES], KGDT_R3_DATA + RPL_MASK
>     /* Make space for us on the stack */
>     sub ebp, 0x29C
> ie.  why 0x29C, why 0x48?

Since he is making room on the stack for another frame, this is a
predefined size.

> --
> Steven Edwards - ReactOS and Wine developer

Alex's explanation (in conjunction with Casper's clarification of our
rules) was enough to satisfy me. I do not think Alex violated the
project rules, and the legality of his code can only be decided in a
court of law, so we are just wasting our time talking about it any
further.   Now, I do agree he could have used the safer "clean-room"
method, but I'm not convinced that it would have yielded a
significantly different implementation, and we might still be in the
same position.

(but I play one on IRC) ;0)

More information about the Ros-dev mailing list