Microsoft Windows library files: Difference between revisions

Revision as of 23:44, 7 April 2023

Latest revision as of 17:56, 14 August 2025

(44 intermediate revisions by 22 users not shown)

Line 1:

{{Short description|List of main shared-libraries of Microsoft Windows}}

{{multiple issues|

{{lead too short|date=February 2013}}

{{more citations needed|date=February 2013}}

{{Update|date=September 2024}}

}}

The [[Microsoft Windows]] [[operating system]] and [[Microsoft Windows SDK]] supportssupport a formcollection of [[shared libraries]] knownthat as "[[Dynamic-link library|dynamic-link librariessoftware]]", which are code libraries that can beuse usedto byaccess multiple processes while only one copy is loaded intothe [[computerWindows memory|memoryAPI]]. This article provides an overview of the core libraries that are included with every modern Windows [[Installation (computer programs)|installation]], on top of which most Windows [[Application software|applications]] are built.

== Library sources ==

The [[Microsoft Windows]] operating system supports a form of [[shared libraries]] known as "[[Dynamic-link library|dynamic-link libraries]]", which are code libraries that can be used by multiple processes while only one copy is loaded into [[computer memory|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.

The Windows operating system contains [[Compiler|compiled]] versions of these libraries known as [[dynamic-link libraries|dynamically-linked libraries]] ([[.dll]]), which are [[Portable Executable|executable]] libraries that can be used by multiple [[Computer program|programs]] while only one copy of the library is loaded into [[computer memory|memory]]. These are canonically referred to as [[system libraries]] and all programs installed on the system can utilize them.

The Windows SDK additionally distributes compiled versions of these libraries known as [[Statically linked library|statically-linked libraries]] ([[.lib]]), which are non-executable libraries that, in whole or in part, can be embedded into a program when it is compiled.{{disputed inline|talkpage=Talk:Microsoft Windows library files#Do SDKs include statically-linked libraries or import libraries?|date=July 2025}} The most common Windows compilers being [[Visual Studio|Microsoft Visual Studio]] and [[Mingw-w64|MinGW]].

== Internal components ==

HAL.DLL is a kernel-mode library file and it cannot be used by any user-mode program. NTDLL.DLL is only used by some programs, but it is a dependency of most Win32 libraries used by programs.

=== HAL.DLL ===

[[File:Windows_2000_architecture.svg|thumb|The Hardware Abstraction Layer in the [[architecture of Windows NT]]]]

The Windows [[Hardware Abstraction Layer]] (HAL) is implemented in '''hal.dll'''.<ref>{{cite book|author=Blunden, Bill|title=The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System|publisher=Jones & Bartlett Learning|year=2009|isbn=978-1-59822-061-2|page=101|url=https://books.google.com/books?id=DF5AhCOLFrgC&pg=PA101}}</ref> 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|Advanced Programmable Interrupt Controller (APIC)]] than on one without. 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.

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 [[Conventional PCI|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 [[central-processing unit|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 [[Advanced Configuration and Power Interface|ACPI]]-compatible BIOS, the presence of an [[Advanced Programmable Interrupt Controller|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.

HAL is merged (or statically linked) into ntoskrnl.exe<ref>{{cite tweet|number=1154442296391323651|user=PetrBenes|title=Did I miss something? Routines...|date=25 July 2019}}</ref> starting with version 2004 of Windows 10, and the dll only serves as a stub for backwards compatibility.

=== 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), and the majority of exported symbols within these libraries are prefixed '''Nt''', for example '''NtDisplayString'''. Native APIs are also used to implement many of the "kernel APIs" or "base APIs" exported by KERNEL32.DLL.<ref name="Eldad-2011-pp68-69">{{cite book|author=Eilam, Eldad|title=Reversing: Secrets of Reverse Engineering|publisher=John Wiley & Sons|year=2011|isbn=978-1-118-07976-8|pages=68–69|url=https://books.google.com/books?id=_78HnPPRU_oC&pg=PT68}}</ref><ref name="nativeapplications">{{cite web|url=httphttps://wwwlearn.microsoft.com/technet/sysinternals/informationresources/NativeApplications.mspxinside-native-applications|title=Inside Native Windows Applications|website=[[Microsoft Learn]]|archive-url=https://web.archive.org/web/20100912231625/http://technet.microsoft.com/en-us/sysinternals/bb897447.aspx|archive-date=2010-09-12|access-date=20112025-1207-1421}}</ref><ref>{{cite book|author1=Russinovich, Mark A. |author2=Solomon, David A. |name-list-style=amp |title=Windows® Internals|publisher=O'Reilly Media|year=2009|isbn=978-0-7356-3796-2|page=136|url=https://books.google.com/books?id=VgjAQjsc6g8C&pg=PT136}}</ref> The large majority of Windows applications do not call NTDLL.DLL directly.<ref>{{cite bookconference|chaptertitle=Modular behavior profiles in systems with shared libraries|editor=Neng, Peng |display-editors=etal |book-title=Information and Communications Security: 8th International Conference, ICICS 2006{{snd}} Raleigh, NC, USA, December 4–7, 2006{{snd}} proceedings|publisher=Springer|year=2006|isbn=978-3-540-49496-6|page=371|chapter-url=https://books.google.com/books?id=U9pY5GfzqsIC&pg=PA371|author1=Marceau, Carla |author2=Stillerman, Matt |name-list-style=amp }}</ref>

Applications that are [[Linker (computing)|linked]] directly against this library are said to use the '''native subsystem'''; 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 use the native subsystem. [[csrss.exe]] itself is such an application.

Line 31 ⟶ 20:

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"<!--do not link this to "Blue Screen of Death (BSOD)"! This is not it!-->. 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),<ref name="nativeapplications"/> 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 '''NtTerminateProcessRtlExitUserProcess''' (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.<ref>{{Cite web |urlname=https://technet.microsoft.com/en-us/sysinternals/bb897447.aspx"nativeapplications" |title=Inside Native Applications |access-date=2017-08-26 |archive-date=2010-10-23 |archive-url=https://web.archive.org/web/20101023130328/http://technet.microsoft.com/en-us/sysinternals/bb897447.aspx |url-status=dead }}</ref>

Most of the Native API is not publicly documented or supported. This allows the API to evolve without having to guarantee [[backwards compatibility]], and breaking changes are thus possible without notification. Native Applications can be built using the Windows Driver Development Kit.<ref>{{cite web | title=Windows Server 2003 DDK | website=[[Microsoft]] | url=http://www.microsoft.com/whdc/devtools/ddk/default.mspx }}</ref>

Though most of the API is undocumented, Native Applications can be built using the [http://www.microsoft.com/whdc/devtools/ddk/default.mspx 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]].{{Citation needed|date=January 2012}}

== Win32 API ==

Line 40 ⟶ 29:

=== KERNEL32.DLL ===

KERNEL32.DLL exposes to applications most of the Win32 base APIs, such as [[memory management]], [[input/output|input/output]] (I/O)]] operations, [[Process (computing)|process]] and [[Thread (computing)|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.<ref name="VSDC1">[http://msdn.microsoft.com/en-us/library/31d242h4.aspx Visual Studio Developer Center: Identifying Functions in DLLs]</ref>{{failed verification|date=OctoberCite 2016}}web

|url=https://learn.microsoft.com/en-us/dotnet/framework/interop/identifying-functions-in-dlls

|title=Identifying Functions in DLLs

|website=.NET Framework documentation

|via=[[Microsoft Learn]]

|publisher=Microsoft

|date=2022-03-11

}}</ref>

=== GDI32.DLL ===

GDI32.DLL exports [[Graphics Device Interface|Graphics Device Interface (GDI)]] functions that perform primitive drawing functions for output to video displays and printers. It is used, for example, in the XP version of Paint. Applications call GDI functions directly to perform low-level drawing (line, rectangle, ellipse), text output, font management, and similar functions.<ref name="VSDC1" /><ref>See also, the documentation for the [[Wine (emulator)|Wine]] implementation of GDI32.DLL: [http://source.winehq.org/WineAPI/gdi32.html Wine API: gdi32.dll]</ref>

Initially, GDI supported 16 and 256 color [[Enhanced Graphics Adapter|EGA]]/[[VGA]] [[display cards]] and [[monochrome]] printers. The functionality has expanded over the years, and now includes support for things like [[TrueType|TrueType fonts]], [[alpha channels]], and [[multiple monitors]].<ref>{{cite book|author=Yuan, Feng|title=Windows graphics programming: Win32 GDI and DirectDraw|publisher=Prentice Hall Professional|year=2001|isbn=978-0-13-086985-2|page=[https://archive.org/details/windowsgraphicsp00yuan/page/71 71]|url=https://archive.org/details/windowsgraphicsp00yuan|url-access=registration}}</ref>

=== USER32.DLL ===<!-- This section is linked from [[Graphics Device Interface]] -->

Line 55 ⟶ 51:

=== COMCTL32.DLL ===

'''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.

=== COMDLG32.DLL ===

'''COMDLG32.DLL''', the Common Dialog Box Library, implements a wide variety of Windows dialog boxes intended to perform what Microsoft deems 'common application tasks'. Starting with the release of Windows Vista, Microsoft considers the "Open" and "Save as" dialog boxes provided by this library as deprecated and replaced by the 'Common Item Dialog API'.<ref>{{Cite web|url=https://msdnlearn.microsoft.com/en-uswindows/librarywin32/windowsdlgbox/desktop/ms645524(v=vs.85).aspxcommon-dialog-box-library|title=Common Dialog Box Library (Windows)- Win32 apps|website=msdn.microsoft.com|language=en[[Microsoft Learn]]|access-date=20172025-1007-2521}}</ref>

=== WS2_32.DLL ===

Line 63 ⟶ 60:

=== ADVAPI32.DLL ===

'''ADVAPI32.DLL''', the Advanced Windows 32 Base API DLL,<ref>{{cite web|title=How RPC Works: Remote Procedure Call (RPC) {{!}} Microsoft Learn|author=[[Microsoft]]|date=8 October 2009 |url=https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc738291(v=ws.10)|access-date=11 September 2023}}</ref> provides security calls and functions for manipulating the [[Windows Registry]].

=== NETAPI32.DLL ===

Line 73 ⟶ 70:

== Other APIs ==

=== SHSCRAP.DLL ===

'''SHSCRAP.DLL''' is part of the [[Object Linking and Embedding|Object Linking and Embedding (OLE)]] mechanism. It implements support for [[Shell Scrap Object File|shell scrap file]]s, which are automatically created when you drag selected content from an OLE-capable application into an Explorer window or desktop,<ref>{{cite web |url=https://support.microsoft.com/en-us/kb/138275/ |title=WD: What is a Scrap (.shs) file? |work=Microsoft Knowledge Base |url-status=dead |archive-date=2015-08-11 |archive-url=https://web.archive.org/web/20150811125202/https://support.microsoft.com/en-us/kb/138275/}}</ref> 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.<ref name="scrap_the_scraps">{{cite web|url=https://technetlearn.microsoft.com/en-us/previous-versions/technet-magazine/2008.02cc194424(v=msdn.windowsconfidential.aspx10)|title=Windows Confidential: Scrapping the Scraps |author=Raymond Chen |access-date=20112025-1207-1421}}</ref> 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.<ref>{{cite web |url=https://www.symantec.com/security_response/writeup.jsp?docid=2000-121915-4852-99 |archive-url=https://web.archive.org/web/20061110163040/http://www.symantec.com/security_response/writeup.jsp?docid=2000-121915-4852-99 |url-status=dead |archive-date=November 10, 2006 |title=VBS.Stages.A |website=symantec.com[[Broadcom#Symantec enterprise security|Symantec]]}}</ref> The functionality can be restored by copying registry entries and the [[Dynamic-link library|DLL]] from a [[Windows XP]] system.<ref name="scrap_restore_hack">{{cite web|url=https://answers.microsoft.com/en-us/office/forum/office_2010-word/how-to-open-shs-files/c4618ebd-e248-4340-ab6a-1b79fd808c46|title=How to open SHS files|access-date=2011-12-14}}</ref>

=== WINMM.DLL ===

Line 91 ⟶ 88:

It has shipped with Windows versions since Windows 95 OSR2.5 for use by other Windows components; earlier versions shipped with the '''CRTDLL.DLL''' library instead. 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]] because many installers failed to check the library version against the installed version before replacing it.

Versions of MSVC before 4.0 and from 7.0 to 1312.0 used differently named DLLs for each version (MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL, etc.). Applications are required to install the appropriate version,<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.71).aspx|archive-url=https://web.archive.org/web/20111207093317/http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.71).aspx|archive-date=2011-12-07|title=C Run-Time Libraries|access-date=2011-12-14}}</ref> and Microsoft offers '''Visual C++ Redistributable''' packages for this purpose, though Windows typically comes with one version already installed.

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.

=== HAL.DLLUCRT ===

With Version 14.0 ([[Visual_Studio|Visual Studio 2015]]), most of the C/C++ runtime was moved into a new DLL, UCRTBASE.DLL, which conforms closely with C99.<ref name="upgrade your code">{{cite web | title=Upgrade your code to the Universal CRT | url=https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt?view=msvc-170 }}</ref> '''Universal C Run Time''' ('''UCRT''') from Windows 10 onwards become a component part of Windows,<ref name="upgrade your code" /> so every compiler (either non MS, like [[GNU_Compiler_Collection|GCC]] or [[Clang]]/[[LLVM]]) can link against UCRT.<ref>{{cite web | title=MSYS2 - Environments | url=https://www.msys2.org/docs/environments/ }}</ref> HoweverAdditionally, C/C++ programs using UCRTBASE.DLL are forcedneed to link against another new DLL, the VCRuntimeVisual C++ Runtime. At Version 14.0, this was VCRUNTIME140.DLL.<ref>{{cite web | url=https://docslearn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170 | title=C++ binary compatibility 2015-2022 | date=30 January 2025}}</ref> The name has the potential to change at future versions, but has not done so as far as of Version 17.0.

Source code for runtime libraries is included in Visual C++<ref>{{cite web | url=httphttps://msdnlearn.microsoft.com/en-us/libraryprevious-versions/visualstudio/visual-studio-6.0/aa296413(v=vs.60).aspx | title=Source Code for the C Run-Time Functions | date=15 September 2006 }}</ref> for reference and debugging (e.g. in <code>C:\Program Files\Microsoft Visual Studio 11.0\VC\crt\src</code>).

=== Other runtime libraries ===

Line 104 ⟶ 102:

* '''MSVBVM60.DLL''' &ndash; [[Visual Basic]] 6.0 Virtual Machine ([[Visual Basic.NET]] programs require [[.NET Framework]] instead)

* '''VCOMP*.DLL''' &ndash; Microsoft [[OpenMP]] runtime

* '''VCRUNTIME*.DLL''' &ndash; Microsoft VCRuntimeVisual C++ Runtime, for MSVC 14.0+

* '''MSVCIRT.DLL''' &ndash; Microsoft C++ Library, contains the deprecated C++ classes from '''<iostream.h>''' (note the file extension) for MS C 9 and 10 (MSVC 2.x, 4.x) (Back then, the draft C++ Standard Library was integrated within MSVCRT.DLL. It was split up with the release of Visual C++ 5.0)

=== .NET Framework libraries ===

Programs written in [[C Sharp (programming language)|C#]], [[Visual Basic.NET]], [[C++/CLI]] and other .NET languages require the [[.NET Framework]]. It has many libraries (one of them is '''mscorlib.dll'''{{snd}} Multilanguage Standard Common Object Runtime Library, formerly Microsoft Common Object Runtime Library<ref>{{Cite web|url=http://weblogs.asp.net/mreynolds/archive/2004/01/31/65551.aspx|title = What does the "ms" in "mscorlib" stand for - hint: It's not "Microsoft"| date=31 January 2004 }}</ref>) and so-called [[Assembly (CLI)|assemblies]] (e.g. '''System.Windows.Forms.dll''').

== See also ==

* [[Architecture of Windows NT]]

* [[WindowsBooting NTprocess startupof processWindows]]

* [[List of Microsoft Windows components]]

* [[Windows API]]

* [[Dynamic -link library]]

== References ==

Line 126 ⟶ 124:

* [https://web.archive.org/web/20060315213024/http://www.sysinternals.com/Information/NativeApi.html Native API reference]

* [http://undocumented.ntinternals.net/ Unofficial website that documents most of the Native API methods]

* [httphttps://uberskill.blogspot.com/2012/07/retrieving-kernel32dll-base-address.html Retrieving the KERNEL32.DLL base address]

{{Windows Components}}