Windows API（ウィンドウズ エーピーアイ）とは、Microsoft WindowsのAPIのことである。特に32ビットプロセッサで動作するWindows 95以降やWindows NTで利用できるものはWin32 APIと呼ばれる。また、それらのWindowsにおけるWin32 APIの実装をWin32と呼ぶ。Windows上で動作するアプリケーションにとって、Windows APIはWindowsの各機能にアクセスするための接点である。そのため、Windows上で動作するアプリケーションを作成できる様々なプログラミング言語・開発環境においてWindows APIを使用する手段が提供されている。特にCとC++では、Windows SDKにより、をはじめとする多数のヘッダーファイルが公開されている。また、多くの開発環境で、Windows APIを基にしたより高水準のフレームワークが構築されている。これらを通じて、直接・間接にすべてのWindowsアプリケーションはWindows APIを使用している。Windows APIに属する各APIは、主にDLLからの関数またはCOMインターフェイスとして機能を公開している。関数の呼出規約は原則としてstdcallを採用する (Win32の場合) など統一されたインターフェイスで多数のプログラミング言語からの使用を容易なものとしている。Windows APIの中核となる機能はKernel、User、GDIに分けられる。当初は、それぞれKERNEL.EXE (モードによってはKRNL286.EXE、KRNL386.EXE)、USER.EXE、GDI.EXEに実装されていた。32ビット化されて以降は、KERNEL32.DLL、USER32.DLL、GDI32.DLLに実装されている。Windows 7の新カーネル、では、"Virtual DLL"の仕組みが導入され、インターフェイス互換性を維持したうえで実装の整理が行なわれている 。現在では、これだけに留まらず、多数のDLLから無数の機能が公開されている。現在、マイクロソフトのドキュメントでは次のように分類している。なお、この分類では、KernelはDiagnosticsとSystem ServicesそしてSecurityに跨って属し、UserはWindows User Interface、GDIはGraphics and Multimediaに属する。マイクロソフトはWindows 95/Windows NT 4以降、全てのWindowsにDirectXを用意している。DirectXは主にゲームとマルチメディアのためのAPIであるが、Windows Vista以降はDirectX GraphicsがGDIに代わってOSのグラフィックス描画の基盤として昇格されている。DirectX APIのうちのいくつかは、ゲームコンソールであるXbox、Xbox 360、Xbox Oneと共通になっている。DirectX APIはWindows APIの中でも変化が激しいAPIのひとつで、Direct3D RM、DirectDraw、DirectSound、DirectInput、DirectPlay、およびDirectMusicはWindows Vista以降完全な互換機能が用意されず、一部を除いて廃止あるいは代替APIに吸収されている。ネイティブAPIは、Windows NT系においてWindows APIより下位層のAPIである。NT系では、NTネイティブAPI上にサブシステムとしてWin32 APIが実装されている。ただし、DirectXやGDIなどは、ネイティブAPIを介せずに、より下位に位置するカーネルと直接やり取りを行う。Windowsで動作する.NET Frameworkは、基本的にWin32 APIを用いて実装されている。例えばWindows FormsおよびWindows Presentation Foundation (WPF) はそれぞれGDI/GDI+あるいはDirect3Dを利用したGUIアプリケーションのフレームワークでり、Win32 APIとの相互運用性も確保されている。かつて、「Windows Vista以降、WinFX (.NET Framework 3.0) がWindows APIに代わってネイティブAPIになる（WinFXが最も低水準なAPIとなりWindows APIはそのラッパーとなる）」とアナウンスされたことがあったが、結局撤回され、Windows Vista製品版では従来通りWindows APIがネイティブなAPIとなっている。Windows APIは名前からも類推できるとおり、主にMicrosoft Windowsに実装されている。その実装はWindowsのバージョン毎に少なからず違いが存在する。たとえばWin32の場合、Win32c、Win32sではごく一部を除きUnicodeに対応していない、セキュリティ対策のアクセス制限が実装されていないなどといった違いが挙げられる。そしてそれは大きく次のように分類することができる。Win16は、16ビットプログラム用の実装である。ただし、Win16という語自体はWin32が登場してから用いられるようになったレトロニムである。Win16は大きく2種類に分けられる。Win32は、32ビットプログラム用の実装である。次のように分けられる。Windows NTがx86以外のアーキテクチャに移植されたことに伴い、Win32は各種アーキテクチャ向けに移植されている。また、Windows NTではないが、かつてMacintosh用のWin32も存在し、Microsoft Visual C++ 4.0 Cross-Development Edition for Macintoshとしてクロスコンパイラとともに発売されていた。これらアーキテクチャの異なるWin32の間にはソースコード上での互換性がある。Win64は、64ビットプログラム用の実装である。、IA-64及びx64用の2種類の実装が存在する。Windows 10ではARM64の将来的なサポートが計画されている 。Windows 8で導入されたWindowsストアアプリ (Modern UIアプリケーション) を開発するためのCOM拡張による高レベルAPI。後継となるWindows 10で導入されたユニバーサルWindowsプラットフォーム (UWP) アプリケーションの開発におけるベースAPIにもなっている。Windows APIの仕様はWindows SDKのドキュメントやMSDN ライブラリで公開されており、それを基にしたMicrosoft Windows以外のWindows APIの実装が存在する。Windows NT系では当初からUnicodeが用いられている一方、Unicodeに対応していないWin16と互換性を取るために、Win32 APIから同じAPIに対してマルチバイト文字版とUnicode版の2つを用意し、C/C++のマクロを駆使してコンパイル時にどちらを使うか選択できる仕組みが採用されている。なお、Unicodeの符号化には当初UCS-2、Windows 2000から正式にUTF-16が用いられている。具体的には、文字および文字列の関わる関数・構造体について、マルチバイト文字（Windowsコードページに基づく、日本語環境であればコードページ932）とUnicode (UTF-16) のどちらを与えることもできるように、2つの関数・構造体などが準備されている。その場合、マルチバイト文字列を与えるべき関数・構造体は末尾に「A」を付け、ワイド文字列を与えるべき関数・構造体は末尾に「W」を付けて区別している。例えば、Win16のMessageBox関数に対して、Win32ではMessageBoxAとMessageBoxWという2つの関数が用意されている。そして、プリプロセッサ識別子UNICODEの定義の有無によって切り替えが行われる。さらに、文字型に対しても同様にCHAR (charのtypedef) とWCHAR (wchar_tのtypedef) をUNICODEの定義で切り替えるTCHAR型などや、ナロー文字列定数・リテラルとワイド文字列定数・リテラルを切り替えるTEXTマクロが存在する。これらを適切に用いると、1つのソースコードからコンパイル時のオプションによってマルチバイト文字を用いる実行プログラムとワイド文字を用いる実行プログラムの2種類が作成できる。以下はその例である。なお、Windows NT系におけるA版のAPI関数は、Unicodeとの変換を行いW版を呼び出すラッパーとなっている。このプレフィックスのAはANSI、WはWideを意味する。ANSIは、Windowsコードページの一部がANSI規格のドラフトを元にしたことに由来する。ワイド文字 (wchar_t) はC/C++の用語であるが、Windows用のC/C++処理系において、ワイド文字は大抵UCS-2またはUTF-16として実装されている。また、OLE関係では、Win32ですべてUnicode化され、A/Wの区別が存在しない。なお、Windows 9x系では、Unicode版APIは一部しか実装されていない。ただし、Microsoft Layer for Unicodeを利用することにより、ほぼすべてのUnicode版APIが使用可能になる。また、Windows CEでは、逆にUnicode版APIしか実装していない。NT系でも、Unicodeを前提とした仕様変更が行われたり、Theme APIなど新しいAPIでA/Wの2種を用意せずUnicodeを用いるものだけを用意したりするなど、徐々にUnicodeへ傾斜する傾向にある。Windows APIの歴史は、もちろんWindows自体の歴史と切り離せない関係にある。常に、Windowsに新機能が搭載されれば、それをアプリケーションソフトウェアから使用するための新しくAPIが追加され、新しいSDKが公開されることの繰り返しである（もちろん、デバイスドライバーらに対応を迫るものは、DDK/WDKで公開される）。Windows APIの歴史上、最も大きな変革はWindows NTに伴うWin32の登場だった。ポインタとハンドルも32ビット化されたこと、Unicodeへの対応が図られたことが大きな変化である。なお、は緩やかに64ビットへの移行が進んでいる。Win64では、ポインタおよびハンドルは64ビット化されているが、それ以外では16ビットから32ビットへの移行時のような大きな変化はない。なお、64ビット版Windowsでは32ビットアプリケーションとの相互運用性を確保するため、ハンドルの上位32ビットを使用する仕組みとなっており、ウィンドウ (HWND) などのユーザーオブジェクトハンドル、ブラシ (HBRUSH) やペン (HPEN) などのGDIオブジェクトハンドル、そしてミューテックス、セマフォ、ファイルなどの名前付きオブジェクトハンドルを32ビット/64ビットアプリケーション間で共有し、プロセス間通信に利用することができる。また、64ビット版WindowsではWOW64により32ビットアプリケーションを実行できるが、16ビットアプリケーションを実行することはできない 。Windows APIはWin16を拡張して32ビット、64ビット化されたという歴史がある。そのため度重なる機能の追加により、高度に複雑化しその習得が困難と化しているという問題がある。また、度重なるバージョンアップによりコンポーネントの互換性を失ってしまうことによるDLL地獄 (DLL Hell) の発生を招いている。Windows APIは比較的低水準であるため、高水準なインターフェイスを持たせるための様々なラッパーが数多く存在する。主なものは次のとおり。.NET FrameworkにもWindows APIをラップした部分が存在する。

出典:wikipedia