[ros-dev] Bye bye

Steven Edwards winehacker at gmail.com
Thu Jan 19 07:28:18 CET 2006


Speaking as someone that is mostly ignorant of kernel internals, lets
pretend I am a judge....

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?

> 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.

> 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...

    /* 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?

Steven Edwards - ReactOS and Wine developer

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

More information about the Ros-dev mailing list