Windows API
これらを適切に用いると、1つのソースコードからコンパイル時のオプションによってマルチバイト文字を用いる実行プログラムとワイド文字を用いる実行プログラムの2種類が作成できる。以下はその例である。
なお、Windows NT系におけるA版のAPI関数は、内部的にW版を呼び出すラッパーとなっている。A版APIに入力されたマルチバイト文字列はUnicode文字列に変換されてからW版APIに入力され、W版APIから出力されたUnicode文字列はマルチバイト文字列に変換されてA版APIの出力となる。
このプレフィックスの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へ傾斜する傾向にある。
Video for Windows、Media Control Interface(英語版) (MCI) やWinMMなどのWindowsマルチメディアAPI
DirectShow
Media Foundation
Core Audio
公開APIを正しく利用して開発されたアプリケーションやドライバーであれば、旧バージョンのOSで正常に動作していたものは、ほとんどのケースにおいて修正することなく動作する。セキュリティ対策のためにWindows Vistaで導入されたユーザーアカウント制御 (UAC) に関しても、通常権限のアプリケーションが直接アクセスできないディレクトリに対する読み書きを仮想化してリダイレクトする仕組みが救済策として用意されている。しかし、アプリケーションやドライバーが特定のバージョンのWindowsでしか動かないような設計になっていた場合、アプリケーションが起動できない、正常に動作しないなどの互換性問題が発生することがある。この問題の回避策のひとつとして、Windowsには、旧バージョンのOSの動作をある程度エミュレートする「互換モード」が用意されている。例えばバージョン番号を取得するためのWindows APIにおいて旧バージョンのOSを偽装した値を返すようにすることで、これらに依存したアプリケーションへの影響を低減する。
Windowsで動作する.NET Frameworkは、基本的にWin32 APIを用いて実装されている。例えばWindows FormsおよびWindows Presentation Foundation (WPF) はそれぞれGDI/GDI+あるいはDirect3Dを利用したGUIアプリケーションのフレームワークであり、Win32 APIとの相互運用性も確保されている。
かつて、「Windows Vista以降、WinFXと呼ばれる新しいAPIがWindows APIに代わってネイティブAPIになる(WinFXが最も低水準なAPIとなりWindows APIはそのラッパーとなる)」とアナウンスされたことがあったが、結局撤回され、Windows Vista製品版では従来通りWindows APIがネイティブなAPIとなっている。WinFXの計画は方針転換され、予定されていた機能は.NET Framework 3.0としてリリースされた。