API （Application Programming Interface，简称API），
Windows应用程序接口（Windows API），是微软对于Windows操作系统中可用的内核应用程序编程接口的称法。它设计为由C/C++程序调用，而且它也是应用软件与Windows系统最直接的交互方式。而大多数驱动程序所需要的对Windows系统的更底层次访问接口，由所用版本的Windows的Native API来提供接口。
Windows有一个软件开发包（SDK, software development kit）提供相应的文档和工具，以使程序员开发使用Windows API的软件和利用Windows技术。
Windows API所提供的功能可以归为七类：
- 基础服务（Base Services） kernel32.dll
提供对Windows系统可用的基础资源的访问接口。比如象：文件系统（file system）、外部设备（device）、, 进程（process）、线程（thread）以及访问注册表（Windows registry）和错误处理机制（error handling）。这些功能接口位于，16位Windows下的kernel.exe、krnl286.exe或krnl386.exe系统文件中；以及32位Windows下的 kernel32.dll和advapi32.dll中。
- 图形设备接口（GDI） gdi32.dll
提供功能为：输出图形内容到显示器、打印机以及其他外部输出设备。它位于16位Windows下的gdi.exe；以及32位Windows下的gdi32.dll。
- 图形化用户界面（GUI） comctl32.dll
提供的功能有创建和管理屏幕和大多数基本控件（control），比如按钮和滚动条。接收鼠标和键盘输入，以及其他与GUI有关的功能。这些调用接口位于：16位Windows下的user.exe, 以及32位Windows下的user32.dll。从Windows XP版本之后, 基本控件和通用对话框控件（Common Control Library）的调用接口放在comctl32.dll中。
- 通用对话框链接库（Common Dialog Box Library） comdlg32.dll
为应用程序提供标准对话框，比如打开/保存文件对话框、颜色对画框和字体对话框等等。这个链接库位于：16位Windows下的commdlg.dll中，以及32位Windows下comdlg32.dll中。它被归类为User Interface API之下。
- 通用控件链接库（Common Control Library） comctl32.dll
为应用程序提供接口来访问操作系统提供的一些高级控件。比如像：状态栏（status bar）、进度条（progress bars）、工具栏（toolbar）和标签（tab）。这个链接库位于：16位Windows下的commctrl.dll中，以及32位Windows下comctl32.dll中。. 它被归类为User Interface API之下。
- Windows外壳（Windows Shell） shell32.dll
作为Windows API的组成部分，不仅允许应用程序访问操作系统shell提供的功能，还对之有所改进和增强。它位于16位Windows下的shell.dll中，以及32位Windows下的shell32.dll中（Windows 95则在 shlwapi.dll中）。 它被归类为User Interface API之下。
- 网络服务（Network Services）
为访问操作系统提供的多种网络 功能提供接口。它包括NetBIOS、Winsock、NetDDE及RPC等。
Web相关API
Internet Explorer网页浏览器也提供许多程序接口 ，它将不会在Windows Vista中集成，特别提供以下接口：
- 可嵌入的网页浏览器控件，位于shdocvw.dll和mshtml.dll之中。
- urlmon.dll中的命名服务（URL moniters service），利用COM对象为应用程序提供解析URL服务。应用程序也可以为其他程序提供自己的URL处理程序。
- 一个支持多种语言文本的链接库（mlang.dll）。
- DirectX Transforms，一组图像过滤组件。
- XML支持（MSXML组件）。
- 访问Windows Address Book。
多媒体相关API
自从Windows 95 OSR2以来，Microsoft把DirectX API 作为Windows安装的一部分。DirectX提供一组松散相关的多媒体和游戏服务。
DirectX API 包括：
- Direct3D可以作为OpenGL的替代，来访问3D加速硬件。
- DirectDraw提供硬件加速2D framebuffer（帧缓冲）访问接口。自DirectX 9以来，相比Direct3D更倾向于后者，因为Direct3D提供更全面的高性能图形功能（毕竟2D渲染只是3D渲染的子集）。
- DirectSound提供底层次的硬件加速声卡访问。
- DirectInput用来与输入设备（摇杆和gamepad）进行通信。
- DirectPlay提供一个多人游戏的架构（multiplayer gaming infrastructure）。它已经被DirectX 9所替代，Microsoft不建议用它进行游戏开发。
- DirectShow可以创建和运行一般的多媒体管道（generic multimedia pipelines）。它可以与GStreamer框架相媲美，并且经常被用来渲染游戏视频和创建media players（Windows Media Player正是基于此）。DirectShow不被建议进行游戏开发。
- DirectMusic
程序通信API
Windows API的功能主要通过使操作系统和应用程序之间的交互来实现。为了实现不同Windows应用程序的通信，微软随着主要Windows API，推出一系列的技术。最初的DDE（Dynamic Data Exchange）升级为对象连接与嵌入（Object Linking and Embedding），再后来是组件对象模型（COM）。
封装库
微软利用许多更底层的Windows API函数，开发出许多封装库（wrapper），让应用程序以更抽象的方式与Windows API进行交互。
- MFC（Microsoft Foundation Class Library）用C++ 类来封装Windows API的功能，因而允许用更为面向对象的方式与API进行交互。
- ATL（Active Template Library）是对COM的面向模板（template oriented）的封装。
- WTL（Windows Template Library）作为ATL的增强，被用来作为MFC的轻型的替代物。
其他著名的封装库是Borland公司的产品，为了与MFC竞争而推出的OWL（Object Windows Library）提供了类似的面向对象封装。
不久Borland又推出VCL（Visual Component Library）来取而代之。
大多数的Windows 程序框架（application framework）是对Windows API的封装，因而.NET Framework、Java以及其他在Windows下的程序语言，都是（或者包含）封装库。
其它实现
尽管微软的Windows API实现有版权保护，但被普遍认可的是，根据美国的法律先例，其他厂商仍然可以通过提供一致的API来模拟Windows，而不会侵犯版权。
- Wine是为Unix类平台提供Win32 API兼容层的尝试。
- ReactOS走得更远，提供了整个Windows操作系统的模拟，与Wine项目紧密结合，以便促进代码重用和兼容。
- HX DOS-Extender是另一个模拟Windows API的项目，允许通过DOS命令行来运行简单的Windows程序。
编译器支持
为了开发使用 Windows API的软件，编译器必须能处理和导入微软相关的DLLs和COM对象。编译器必须接受一种C或C++方言，并处理揭示了内部API函数名称的接口定义语言（Interface description language）文件和头文件。概括而言，这些预备条件（编译器、开发工具、库和头文件）被统称为Microsoft Platform SDK。很长时间以来，包含了编译器和开发工具的专利产品如Microsoft Visual Studio系列和Borland编译器（尽管至少在Windows下，SDK是可以从整个IDE环境中剥离出来单独免费下载的，据 Microsoft Platform SDK Update），是仅有的能提供整套开发环境的选择。如今MinGW和Cygwin也能提供一套这样的开发环境——是基于采用一种独立头文件集合来保证能与微软DLL连接的GCC。LCC-Win32是由Jacob Navia维护的一种“非商业用途免费”的C编译器。Pellesc是由Pelle Orinius维护的一种免费C编译器。MASM32是一个成熟的项目，它通过自制或由SDK平台转换的头文件和库，并利用32位微软汇编器来实现支持Windows API。
微软相关的编译器支持也是异常处理（Structured Exception Handling）特性所需要的。这个体制有双重目的：它提供了语言相关的异常处理赖以实现的基础，同时也是内核藉以通知程序发生诸如解除一个非法指针的引用或堆栈溢出之类异常状况的渠道。甫一被引入Windows 95和NT，微软/Borland C++编译器就有使用这种体制的能力，然而实际实现未被公开，而且必须经过反向工程方可用于Wine项目和免费编译器。SEH的运行机制是先把异常的句柄推入堆栈，继而将它们添加到存储于线程本地资源（即线程环境块的首字段）的一个链表里。事实上，每一个未有程序本身处理的异常，都将由会弹出常规Windows崩溃对话框的默认backstop处理器处理。
