Re: [ros-dev] Bye bye

[Steven Edwards]

Hi,

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

On 1/18/06, Alex Ionescu <ionucu(a)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