Windows library files

Like most modern operating systems, Microsoft Windows supports shared libraries, collections of code which can be used by multiple processes while only being loaded once into memory. Windows terms its shared libraries Dynamic-link libraries (DLLs).
Most core Windows functionality is contained within Native Applications and a set of DLLs, which together provide the various subsystems in which code can run (Win32, SUA, Virtual DOS machine, etc.).
Hal.dll
Hal.dll is the core of Windows' Hardware Abstraction Layer, which allows applications to access devices in the system without knowledge of the specific protocol used by any one device.
Although drivers for most hardware are contained in external files, core drivers (which are required to support the kernel) are compiled into Hal.dll. Different sets of drivers may be selected depending on whether the system uses multiple processors, the presence of an ACPI-compatible BIOS or an Advanced Programmable Interrupt Controller (APIC), etc.
Msvcrt.dll
Msvcrt.dll (the Microsoft Visual ) provides basic services, such as string comparison, memory allocation, etc., to programs compiled with , versions 4.2 to 6.
In older versions of Windows, programs which linked against Msvcrt.dll were expected to install a copy in the System32 folder, but this contributed to DLL Hell. Newer versions of the operating system include the file to circumvent this problem.
Ntdll.dll
Ntdll.dll exports the Windows Native API.
The Native API is the interface used by user-mode components of the operating system that must run without support
from Win32 or other API subsystems.
Most of this API is implemented in ntdll.dll and at the upper edge of ntoskrnl.exe (and its variants); the majority of exported symbols within these libraries are prefixed Nt, e.g., NtDisplayString.
Native APIs are also used to implement many of the "kernel APIs" or "base APIs" exported by Kernel32.dll.
Applications that are linked directly against this library are known as native applications; the primary reason for their existence is to perform tasks that must run early in the system startup sequence before the Win32 subsystem is available.
An obvious but important example is the creation of the Win32 subsystem process, csrss.exe.
Before the csrss.exe process exists, no Win32 processes may be created, therefore the process that creates it
(Smss.exe, the "session manager") must be a native application.
csrss.exe is itself a native application.
Despite having a ".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". Other prominent examples are the services that implement the various subsystems, such as csrss.exe.
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)
Kernel32.dll
Exposes to applications most of the Win32 base APIs, such as memory management, input/output operations, (process and thread) creation, and synchronization functions. Many of these are implemented within Kernel32.dll by calling corresponding functions in the native API, exposed by Ntdll.dll.
Shscrap.dll
shscrap.dll implements support for shell scrap files. These are automatically created when you drag selected content from an OLE-capable application into an Explorer window (or onto the Desktop), but you can also use the Object Packager to create them. They can then be dragged into another OLE-capable application. Scrap (.shs) files are sometimes used by viruses because they can contain a wide variety of files (including executable code), and the file extension is not shown even when "Hide file extensions from known file types" is disabled.
User32.dll
user32.dll implements the Windows User API client library.
It allows programs to implement a graphical user interface using the standard elements of the Windows UI.
It exports functions to perform such tasks as window management,
user input, text display, and so on.
Programs call many of these functions directly to create and manage windows,
receive window messages (including user input such as mouse and keyboard events, as well as notifications from the
operating system).
Many of the functions in User32.dll call upon GDI functions exported by Gdi32.dll to do the actual rendering of the various elements of the user interface.
Comctl32.dll calls functions from User32.dll to implement standard Windows controls, such as File Open, Save, and Save As dialogs, progress bars, and list views.

Main Menu

See Also

Main Menu