This is an old revision of this page, as edited by Jeh(talk | contribs) at 07:56, 14 June 2009(→Nt and Zw functions: difference between Nt (user mode), Nt (kernel mode), and Zw interfaces). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.Revision as of 07:56, 14 June 2009 by Jeh(talk | contribs)(→Nt and Zw functions: difference between Nt (user mode), Nt (kernel mode), and Zw interfaces)
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows
What the NtXxx things are depends on where you are and what you've linked to, because there are really two sets of callable interfaces called NtXxx. One set, the native API, is exposed in user mode by NTDLL.DLL (you would link to NTDLL.LIB to call these). Most of these put a system service ordinal into EAX, then trap into kernel mode with INT 2E (old) or SYSENTER or SYSCALL (new), thereby passing control to KiSystemService in kernel mode. KiSystemService uses the value in EAX to index into the system service dispatch table. There it finds a) the number of arguments needed by the call, using this to copy that many arguments from the previous stack to the thread's kernel mode stack, and b) a function pointer, which it uses to call the underlying "actual implementation". The tricky part is that the "actual routine" is also called NtXxx, exported by ntoskrnl.exe. There is no name conflict here because ntoskrnl.exe and ntdll.dll are not linked against each other. Accordingly, in kernel mode, say in a driver, if you call NtXxx (having linked to ntoskrnl.lib) you're calling the real thing. If you instead call ZwXxx as the WDK doc says you should, those are simply kernel-mode names for the entry points in ntdll.dll - so you go through the INT 2E or SYSENTER or SYSCALL, and KiSystemService does the arg list copy and function pointer lookup. In this case though it is known that your previous mode was kernel mode so a lot of security access checking that would ordinarily be done very early in the "actual implementation" is skipped. Jeh (talk) 07:56, 14 June 2009 (UTC)[reply]
Native API vs. DDI
There seemed to be some disagreement (hidden HTML comments left ages ago) in the article regarding what is and is not "Native API". It seemed someone objected to the use of the phrase "API" to describe DDIs (Device Driver Interfaces), since user-land applications don't generally call them. That said, kernel-land applications certianly call some of them. Given the API article lists "PC BIOS Call Interface" as an API, I'm inclined to think the API classification is appropriate. Thoughts? Anphanax (talk) 13:37, 13 June 2009 (UTC)[reply]
To me an "application" is not something that can run in kernel mode. To my knowledge you can't create a process and have its initial thread call your 'main' function in kernel mode, only in user mode. In general things in kernel mode do not run as independent "applications" but rather in response to calls from kernel mode or to things like interrupts. The fact that BIOS routines are exposed to applications in something like a DOS environment (but most certainly not under a real OS) does not seem to me to be relevant here. Jeh (talk) 07:44, 14 June 2009 (UTC)[reply]
