Are you sure the Zw functions are the actual implementations? As far as I remember it's the other way around... NegativeIQ (talk) 22:33, 1 January 2008 (UTC)Rep
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:
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 project which is currently considered to be inactive.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows
Nt and Zw functions
Latest comment: 17 years ago4 comments4 people in discussion
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
Latest comment: 17 years ago4 comments2 people in discussion
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
The vast majority of consumers are drivers, but the functionality isn't there just for drivers. I believe the following are native-mode applications (NT Kernel intentionally excluded): autochk.exe, autoconv.exe, autofmt.exe, autolfn.exe, csrss.exe, smss.exe, and sprestrt.exe. I wouldn't consider NTDLL.DLL's relationship with the NT Kernel a driver one either. I'm not sure about WIN32K.SYS (many moons and NTs ago a lot of it was in WINSRV.DLL). Anphanax (talk) 03:15, 4 July 2009 (UTC)Reply
I think you are confusing "kernel mode" with "native." Yes, all of the exe's you mentioned are native-mode images: They don't depend on the Win32 subsystem. But they run in user mode and so none of them call DDIs directly; they can't. ntdll.dll's job is to expose the user mode native API. It is user mode also. Win32K.sys is in kernel mode and can interact with kernel mode components like any other driver, and it calls a lot of things out of ntos that ordinary drivers aren't allowed to call as well.
By "DDIs" we do not mean native APIs like NtReadFile. DDIs in Windows are things like ExAllocatePoolWithTag, MmBuildMdlForNonpagedPool, IoCallDriver, IoCompleteRequest... These are documented in the Windows Driver Kit. They are not callable by applications, not even native applications. Hence they are not A(pplication)PIs. There are a few native APIs like NtReadFile that are exposed to kernel mode drivers as e.g. ZwReadFile. That does not mean that DDIs are APIs. No, ntdll.dll is absolutely not a driver and does not call e.g. IoCompleteRequest - it runs in user mode and if it tried to call IoCompleteRequest or any other DDI it would hit an access violation, as IoCompleteRequest's entry point is not accessible from user mode. I see no justification at all for calling this an API, or for calling the set of interfaces it belongs to APIs. It is certainly not part of the Windows native API. Jeh (talk) 06:51, 4 July 2009 (UTC)Reply
"More wrong"
Latest comment: 9 years ago6 comments2 people in discussion
The main thing I think is wrong with the current wording is "there is no one answer". I'm sure there is an answer, it's just not publicly documented. What was wrong with my wording? – Smyth\talk15:45, 27 September 2016 (UTC)Reply
Many callable routines of many of the groups mentioned such as Io, Mm, Cc, Le, Ob, Ps, Ke, etc., are documented... as part of the WDK. What matters for "part of native API" is whether or not there's an entry point in ntdll.dll (the "nt" there means "native"), which is exposed to user mode, not whether it's documented. If something is only exposed to kernel mode then it is flatly not part of the native API. Jeh (talk) 15:54, 27 September 2016 (UTC)Reply
If that's true, then my wording is wrong, but only because the original wording which I rephrased was wrong in exactly the same way. So how did I make the article worse (and why didn't you just correct it)? – Smyth\talk16:08, 27 September 2016 (UTC)Reply
"more wrong" because you added an implication that "publically documented" has anything to do with "part of native API". As for why not fix it myself, the coverage on WP of Windows internals is a great morass of both mistaken and obsolete ideas and I just don't have time to fix it all, particularly not for the disputes that would inevitably arise. But I can keep it from getting worse. Jeh (talk) 16:15, 27 September 2016 (UTC)Reply
I didn't intend to imply that at all, though I see how you could take it that way. I was only trying to to rephrase the previous text which stated that since they aren't documented then we just don't know whether they are part of the Native API or not. But you say they are documented and they're not part of the Native API, so shouldn't we just delete the whole paragraph for being irrelevant to this article? – Smyth\talk18:26, 27 September 2016 (UTC)Reply
Latest comment: 8 years ago1 comment1 person in discussion
Hello fellow Wikipedians,
I have just modified one external link on Native API. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.
The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.