Windows NTやWindows 95といった32ビット版Windowsが登場してから約17年が経つ。Windows 98、2000、XP、Vistaなどを経て、現在のWindows 7に至るまで、その見た目はずいぶん変わったように思えるが、ほとんど変わらずに維持されているものがある。それはC/C++などのプログラムからWindowsの各機能にアクセスするためのAPIである「Win32 API」だ。

　筆者は先ごろ、過去に日経ソフトウエアに掲載したWin32 API関連の特集や連載記事を収録したムック「APIで学ぶWindowsプログラミング」の編集作業を担当した。その作業の一環として、当時の記事で解説に使ったC言語サンプルプログラムのプロジェクト（プログラムのソースコードや関連ファイルを集めたもの）を、Windows 7（32ビット版）で動作する最新の開発ツール「Visual C++ 2010」に読み込み直して動作を確認した。その結果、プロジェクトの設定ファイルを修正しなければならないものはあったが、Cプログラムのソースコードはすべて、全く手を入れることなく動作した。

　これらのサンプルプログラムはWin32 APIの基本的な機能しか使っていない簡単なものなのでこの結果は当然であり、もっと複雑なプログラムでは違った結果になるかもしれない。しかし、マイクロソフトがWin32 APIのような低水準のインタフェースを17年の長きにわたって維持していること、あるいは維持しようとしていることにはある種の感銘を受ける。

　実は2003年にマイクロソフトは、2005年以降に出荷予定の次世代OS「Longhorn（開発コード名）」でWin32 APIの後継となる新APIとして「WinFX」を採用する旨を発表した（関連記事：さらばWin32 API、ついに姿を見せたLonghorn）。マイクロソフトの思惑通りに事が運べば、Win32 APIはLonghornの製品化に合わせてWinFXにその座を譲るはずだった。

　しかし、そうはならなかった。Longhornが「Windows Vista」として2007年1月にようやく発売になったときには、WinFXと呼ばれていた新APIは「.NET Framework 3.0」と名称が変更され、Win32 APIは引き続きサポートされることになっていた（参考：WinFXから .NET Framework 3.0への名前変更について）。

　かくして、Win32 APIは生き永らえている。今後はWin64 APIを実装する64ビット版Windowsが普及していくだろうが、Win32 APIとWin64 APIの間には互換性が確保されていることに加えて、64ビット版Windows上でWin32 APIをエミュレーションする「WOW64（Windows on Windows 64）」技術もある。.NET Frameworkの利用が広がるにつれて徐々に地位は低下するかもしれないが、Win32 APIが当分の間、Windowsアプリケーション開発者にとって重要であり続けることは間違いない。