Talk:Windows Native API

	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 articles
???	This article has not yet received a rating on the project's importance scale.

Microsoft Windows: Computing Mid‑importance

	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 articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

Nt and Zw functions[edit]

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)[reply]

Nt functions are the actual implementation. --wj32 ^t/c 07:54, 28 January 2009 (UTC)[reply]

See URL http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=257. It sounds like in User Mode, it doesn't matter. It Kernel Mode, The Zw variants set kernel mode and the Nt ones do not. The article currently claims there is a lookup table. The branch table article makes more sense to use, unless I'm not understanding something correctly. Anphanax (talk) 13:12, 13 June 2009 (UTC)[reply]

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[edit]

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"[edit]

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\^talk 15: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\^talk 16: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\^talk 18:26, 27 September 2016 (UTC)[reply]

Done. – Smyth\^talk 15:45, 30 September 2016 (UTC)[reply]

External links modified (February 2018)[edit]

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:

Added archive https://www.webcitation.org/6D0rHn1dU?url=http://netcode.cz/img/83/nativeapi.html to http://netcode.cz/img/83/nativeapi.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:02, 14 February 2018 (UTC)[reply]