Microsoft Windows library files
||This article has multiple issues. Please help improve it or discuss these issues on the talk page.
The Microsoft Windows operating system supports a form of shared libraries known as dynamic-link libraries, which are code libraries that can be used by multiple processes while only being loaded once into memory. This article provides an overview of the core libraries that are included with every modern Windows installation, on top of which most Windows applications are built.
Internal components 
The library files in this section are not used directly by most programs; however, they do help implement functions in other libraries that are so used.
The Windows Hardware Abstraction Layer (HAL) is implemented in Hal.dll. The HAL implements a number of functions that are implemented in different ways by different hardware platforms, which in this context, refers mostly to the Chipset. Other components in the operating system can then call these functions in the same way on all platforms, without regard for the actual implementation.
For example, responding to an interrupt is quite different on a machine with an Advanced Programmable Interrupt Controller (APIC) than on one without. The HAL abstracts such differences so that nothing outside the HAL need be concerned with them.
The HAL is loaded into kernel address space and runs in kernel mode, so routines in the HAL cannot be called directly by applications, and no user mode APIs correspond directly to HAL routines. Instead the HAL provides services primarily to the Windows executive and kernel and to kernel mode device drivers. Although drivers for most hardware are contained in other files, commonly of file type .sys, a few core drivers are compiled into Hal.dll.
Kernel mode device drivers for devices on buses such as PCI and PCI Express directly call routines in the HAL to access I/O ports and registers of their devices. The drivers use HAL routines because different platforms may require different implementations of these operations. The HAL implements the operations appropriately for each platform, so the same driver executable file can be used on all platforms using the same CPU architecture, and the driver source file can be portable across all architectures.
On x86 systems 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. Among the criteria for this selection are the presence of an ACPI-compatible BIOS, the presence of an APIC, and whether or not multiple processors are present and enabled. (The multiple cores of a multi-core CPU, and even the "logical processors" implemented by a hyperthreading CPU, all count as "processors" for this purpose.) On x86-64 and Itanium platforms there is just one possible Hal.dll for each CPU architecture.
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. The large majority of Windows applications do not call ntdll.dll directly.
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), 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.
Win32 API 
The libraries in this section each implement various subsets of the Win32 API.
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.
Gdi32.dll exports Graphics Device Interface (GDI) functions that perform primitive drawing functions for output to video displays and printers. Applications call GDI functions directly to perform low-level drawing, text output, font management, and similar functions.
Initially, GDI started out as a simple driver for 16 or 256 color EGA/VGA display cards and monochrome printers. The functionality of GDI has expanded over the years, and now includes support for things like TrueType fonts, alpha channels, and multiple monitor support.
user32.dll implements the Windows USER component that creates and manipulates the standard elements of the Windows user interface, such as the desktop, windows, and menus. It thus enables programs to implement a graphical user interface that matches the Windows look and feel. Programs call functions from Windows USER to perform operations such as creating and managing windows, receiving window messages (which are mostly user input such as mouse and keyboard events, but also notifications from the operating system), displaying text in a window, and displaying message boxes.
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. Some types of programs will also call GDI functions directly to perform lower-level drawing operations within a window previously created via User32 functions.
comctl32.dll implements a wide variety of standard Windows controls, such as File Open, Save, and Save As dialogs, progress bars, and list views. It calls functions from both User32.dll and Gdi32.dll to create and manage the windows for these UI elements, place various graphic elements within them, and collect user input.
Other APIs 
shscrap.dll is part of the Object Linking and Embedding (OLE) mechanism. It 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.
This functionality was removed from Windows Vista (and therefore later versions) to improve security and rid the operating system of generally unused functionality. Scrap (.shs) files have been 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. The functionality can be restored by copying registry entries and the DLL from a Windows XP system.
Runtime libraries 
Msvcrt.dll and Msvcpp.dll 
Msvcrt.dll is the Microsoft Visual C Run-Time Library (and Msvcpp.dll is the standard C++ library) for Visual C++ version 4.2 to 6.0. It provides programs compiled with these versions of Visual C++ a typical set of library functions required by C and C++ programs. These include string manipulation, memory allocation, C-style input/output calls, etc.
It has also shipped with Windows versions since Windows 2000 for use by other Windows components. In older versions of Windows, programs which linked against Msvcrt.dll were expected to install a compatible copy in the System32 folder, but this contributed to DLL Hell.
Versions of Visual C++ before 4.0 and since 7.0 have used differently named DLLs for each version (msvcr20.dll, msvcr70.dll, msvcr71.dll, msvcp110.dll etc.). Applications are required to install the appropriate version.
Microsoft Visual C++ Run-Time is included in Windows. Runtimes newer than installed OS are available in packages called Visual C++ Redistributables.
Source code for runtime libraries is included in Visual C++ for reference and debugging (e.g. in
C:\Program Files\Microsoft Visual Studio 11.0\VC\crt\src).
This runtime library is used by programs written in Visual C++ and a few other compilers (e.g. MinGW). Some compilers have their own runtime libraries.
Other runtime libraries 
- atl*.dll — Active Template Library
- mfc*.dll — Microsoft Foundation Classes
- msvbvm60.dll — Visual Basic 6.0 Virtual Machine (Visual Basic.NET programs require .NET Framework instead)
.NET Framework libraries 
Programs written in C#, Visual Basic.NET, C++/CLI and other .NET languages require the .NET Framework. It has many libraries (one of them is mscorlib.dll — Multilanguage Standard Common Object Runtime Library, formerly Microsoft Common Object Runtime Library) and so-called assemblies (e.g. System.Windows.Forms.dll).
See also 
- Architecture of Windows NT
- Windows NT startup process
- List of Microsoft Windows components
- Windows API
- Dynamic link library
- Blunden, Bill (2009). The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System. Jones & Bartlett Learning. p. 101. ISBN 978-1-59822-061-2.
- Eilam, Eldad (2011). Reversing: Secrets of Reverse Engineering. John Wiley & Sons. pp. 68–69. ISBN 978-1-118-07976-8.
- "Inside Native Windows Applications". Archived from the original on 2010-09-12. Retrieved 2011-12-14.
- Russinovich, Mark A. & Solomon, David A. (2009). Windows® Internals. O'Reilly Media. p. 136. ISBN 978-0-7356-3796-2.
- Marceau, Carla & Stillerman, Matt (2006). "Modular behavior profiles in systems with shared libraries". In Neng, Peng et al. Information and communications security: 8th international conference, ICICS 2006 [...] proceedings. Springer. p. 371. ISBN 978-3-540-49496-6.
- Visual Studio Developer Center: Identifying Functions in DLLs
- See also, the documentation for the Wine implementation of gdi32.dll: Wine API: gdi32.dll
- Yuan, Feng (2001). Windows graphics programming: Win32 GDI and DirectDraw. Prentice Hall Professional. p. 71. ISBN 978-0-13-086985-2.
- WD: What is a Scrap (.shs) file? - Microsoft Knowledge Base
- "Windows Confidential - Scrapping the Scraps". Retrieved 2011-12-14.
- VBS.Stages.A - Symantec.com
- "How to open SHS files". Retrieved 2011-12-14.
- "C Run-Time Libraries". Retrieved 2011-12-14.
|Wikibooks has a book on the topic of: Windows Programming/GDI and Drawing|
- API calls list - USER32.DLL - Tips for using the User API Client Library with Visual Basic
- API calls list - Kernel32.dll - Tips for using the Kernel API Client Library with Visual Basic
- Native API reference
- Unofficial website that documents most of the Native API methods
- Retrieving the kernel32.dll base address