ntdll.dll vs. ntoskrnl.exe
Casper Hornstrup
chorns at users.sourceforge.net
Sun Sep 15 03:47:35 CDT 2002
> -----Original Message-----
> From: wine-devel-admin at winehq.com
> [mailto:wine-devel-admin at winehq.com] On Behalf Of Francois Gouget
> Sent: 15. september 2002 05:05
> To: Jan Kratochvil
> Cc: wine-devel at winehq.com
> Subject: Re: ntdll.dll vs. ntoskrnl.exe
>
>
> 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?
>
>
> --
> Francois Gouget fgouget at free.fr http://fgouget.free.fr/
> Broadcast message : fin du monde dans cinq minutes,
> repentez vous !
>
>
Yes, they are not supposed to be imported by user-mode applications
and user-mode applications cannot access them directly. Ntoskrnl.exe
(and all kernel-mode drivers) are mapped above 0x80000000
(or above 0xc0000000 depending on the /3GB address space switch).
Applications will cause an exception if they touch this memory.
The only way to access the ntoskrnl.exe APIs (on the x86) is
through a call gate (int 0x2e on Windows NT). If applications
could touch ntoskrnl.exe directly, then it would be a huge
security risk. Eg. an application could overwrite some parts of an
ntoskrnl.exe data section and bring down the system.
Casper Hornstrup
More information about the wine-devel
mailing list