The Full Wiki

Windows library files: Wikis


Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.


From Wikipedia, the free encyclopedia

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 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 (the Microsoft Visual C++ Run-Time) provides basic services, such as string comparison, memory allocation, etc., to programs compiled with Visual C++, 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 (Native API)

The Native API is the interface used by user-space components of the NT kernel and programs requiring low-level access to hardware.[1] Most of this API is implemented in ntdll.dll and ntoskrnl.exe (and its variants); the majority of exported symbols within these libraries are prefixed Nt, e.g., NtDisplayString.

Applications that are 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 I/O that cannot be achieved through the documented Windows API. 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 initialisation "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)[1], obtain their command-line arguments via a pointer to an in-memory structure, manage their own memory using the Rtl heap API, and return execution with a call to NtTerminateProcess (as opposed to ExitProcess). A common library linked with Native applications is nt.lib, which contains startup code for Native applications, similar to how the C runtime provides startup code for Win32 apps.

Though most of the API is undocumented, Native Applications can be built using the 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 can not be linked directly against this library, but rather to one or more of the well-documented "client" libraries; this allows portability across Windows platforms and prevents ordinary programs from violating security restrictions or damaging the system.


Graphics Device Interface (GDI) functions for device output, such as those for drawing and font management.[2]


Low-level operating system functions for memory management and resource handling.[3]


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)[4], 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.[5]


user32.dll allows programs to implement a graphical user interface. It contains basic functions, such as window management, user input, text, etc. comctl32.dll uses these functions to implement other standard Windows controls, including progress bars and list views

See also


External links



Got something to say? Make a comment.
Your name
Your email address