Microsoft Windows library files
Other components in the operating system can then call these functions in the same way on all platforms, without regard for the actual implementation.
The HAL provides a single function for this purpose that works with all kinds of interrupts by various chipsets, so that other components need not be concerned with the differences.
On x86 systems prior to Windows 8, there are several different HAL files on the installation media.
The Windows installation procedure determines which ones are appropriate for the current platform and copies it to the hard drive, renaming it to hal.dll if necessary.
HAL is merged (or statically linked) into ntoskrnl.exe[2] starting with version 2004 of Windows 10, and the dll only serves as a stub for backwards compatibility.
Most of this API is implemented in NTDLL.DLL and at the upper edge of ntoskrnl.exe (and its variants), and the majority of exported symbols within these libraries are prefixed Nt, for example NtDisplayString.
Despite having an ".exe" file extension, native applications cannot be executed by the user (or any program in the Win32 or other subsystems).
An example is the autochk.exe binary that runs chkdsk during the system initialization "Blue Screen".
Unlike Win32 applications, native applications instantiate within the Kernel runtime code (ntoskrnl.exe) and so they must have a different entry point (NtProcessStartup, rather than (w)(Win)MainCRTStartup as is found in a Win32 application),[4] obtain their command-line arguments via a pointer to an in-memory structure, manage their own memory using the Rtl heap API, (which the Win32 heap APIs are just wrappers around—no real difference there) and return execution with a call to RtlExitUserProcess (as opposed to ExitProcess).
[7] Though most of the API is undocumented, Native Applications can be built using the Windows Driver Development Kit; many antivirus software 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.
KERNEL32.DLL exposes to applications most of the Win32 base APIs, such as memory management, input/output (I/O) operations, process and thread creation, and synchronization functions.
[8][9] Initially, GDI supported 16 and 256 color EGA/VGA display cards and monochrome printers.
The functionality has expanded over the years, and now includes support for things like TrueType fonts, alpha channels, and multiple monitors.
It thus enables programs to implement a graphical user interface (GUI) that matches the Windows look and feel.
[15] The functionality can be restored by copying registry entries and the DLL from a Windows XP system.
It provides programs compiled by these versions of MSVC with most of the standard C library functions.
With Version 14.0 (Visual Studio 2015), most of the C/C++ runtime was moved into a new DLL, UCRTBASE.DLL, which conforms closely with C99[1].
