[ros-dev] Bye bye
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 */
/* Skip the other registers */
sub esp, 0x48
/* Hack: it seems that on VMWare someone damages ES/DS on exit.
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