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