Hi,
On Sun, 15 Sep 2002 05:05:25 +0200, Francois Gouget wrote:
On Sun, 15 Sep 2002, Jan Kratochvil wrote: [...]
Some W32 binary wants to import functions from "ntoskrnl.exe" from me, should I make an alias of Wine "ntdll.dll" to "ntoskrnl.exe" and try to fill the missing funcs? I have never seen W32 programming before as I am *IX coder.
From what has been said in other posts, ntoskrnl.exe is not meant to be accessed from user space. Which Win32 binary is accessing it?
Some system driver (.SYS) and I hope I will be able to satisfy its requirements as it just imports "ntoskrnl.exe" and exports some own Wine-callable functions. Exact details not yet available - sorry (my own NDA), to be disclosed later.
Currently I am happy with your perfect information - "ntoskrnl.exe" is vmlinuz with its "int 0x80" (NTKERNELAPI / NTSYSAPI - differences?) while "ntdll.dll" is the userland-callable glibc. "ntdll.dll" does the "ntoskrnl.exe" syscalls by some own jumptable with syscall # in %eax and calls always some indirection point *0x7ffe0300 - probably some fixed address as it was outside of all my mapped modules. Also I found out some fixed address access of %ds:0xffdff020 being stored to by "ntoskrnl.exe", some kernel variable block?
Anyway I found out that probably it isn't much possible to run native "ntoskrnl.exe" inside Wine emulation sandbox and thus it is better to try to provide builtin emulation despite "ntoskrnl.exe" is not much documented. :-(
My first W32 code ever written was "hal.dll". My second one will be thus probably "ntoskrnl.exe" and I hope this will be really the last one. :-)
Regards, Jan Kratochvil