Microsoft Windows library files: Difference between revisions

Revision as of 21:40, 16 January 2007

Revision as of 05:42, 21 January 2007

Line 21:

Applications that are [[linker|linked]] directly against this library are known as '''Native Applications'''; the primary reason for their existence is to perform low-level tasks such as direct disk [[Input/output|I/O]] that cannot be achieved through the documented Windows API. An example is the '''autochk''' binary that runs '''[[chkdsk]]''' during the system initialisation "[[Blue_Screen_of_Death#Windows_NT|Blue Screen]]". Unlike [[Win32]] Applications, Native Applications instantiate within the Kernel runtime code ([[ntoskrnl.exe]]) and so must manage their own memory using the '''Rtl''' heap API, obtain their command-line arguments via a pointer to an in-memory structure, and return execution with a call to '''NtProcessTerminate''' (as opposed to just terminating). They also have a different entry point of '''NtProcessStartup''' as opposed to '''main/winmain''' to distinguish them from normal Windows binaries - '''main''' is normally a stub that causes Windows to display a warning message, such as "The %PATH% application cannot be run in Win32 mode."<ref name="nativeapplications"/>

Despite being their API being undocumented, Native Applications can be built using the [http://www.microsoft.com/whdc/devtools/ddk/default.mspx Windows Driver Development Kit]; many [[AntiVirus]] and other utility software vendors incorporate Native Applications within their products, usually to perform some boot-time task that cannot be carried out in [[Userspace]].

Ordinary Windows applications are not linked directly against this library, but to one or more of the "client" libraries with well-documented APIs; This is to retain portability across Windows Platforms among other reasons.