Windows API をひとことで言う気にはあまりなれないのです。Windows API は、「もの」 という感覚ではないし、簡単に説明できるのは、必然的に、製作者か、準じて相当使い込んだ人しかありえないからです。

以下では、できる範囲で解説していきます。

これから扱う、Windows プログラミング とは、C/C++ と、Windows API を使ったプログラミングです。

Windows API は、C言語からでなくたって、Visual Basic からでも、他の言語からでも「利用」することができます。API は、「利用するもの」 です。ものと言っていますが念のため、そうではなくて、言ってみればサービス、オペレーティングシステムの提供するサービスです。それはまた、具体的には OS に組み込まれた形で提供されているから、「OS に組み込まれた仕組み」 ということにもなります。 それを「利用する」と言っています。
( API を使えば使うほど、よくできていると感心するし、結局「マイクロソフト」デザインのボタンやらフレームを利用していることになるので、ついついサービスといってしまうのですが、それではますますわかりにくくなるだけです )

Windows API は、Windows Application Programmer Interface の略で、この場合 Windows だけれども、"Windows" を取り除いた "API" は、マックOS にもあります。

そしてこれは、「OS (または マイクロソフト)が、ユーザがプログラム開発を容易に行えるように準備、整備した仕組み」です。C 言語をはじめ機械語、アセンブラ、またはほかの言語だけでプログラムを組むのが基本ですが、それだけではシステムやデバイスにアクセスしたりするのに非常に手間がかかるのです。その手間、面倒さゆえのサービス、仕組みです。

つまり、API がなかったらどうなるのかというと、結局、コンピュータに何かさせるには、「全て」、メモリやファイルに書き込めばなにかをしてくれるから、C言語なり他の言語なりでも、メモリに書き込むプログラムを書けばいいのです。メモリに書き込むこと自体は、どの言語でもできる「単純」なことで、それ一回の動作はたかだか一行の記述で済みます。ところが、例えば画面に描画したかったら、

コンピュータ内(システム)の、デバイス(名)の取得とか割り当てられたアドレスはどこなのか、とかをマイクロソフトの(技術)資料その他などからまず調べ(しかもその資料がどこに行けばあるのかさえわからない、プロフェッショナルな情報で、しかもアクセスの仕方だって単純じゃない)、_{次に、オペレーションコードみたいなのも、しかもさしあたってマイクロソフトにあたればいいのかディスプレイメーカーに聞けばいいのかわからない、}

どんな手間かよくわからなかったとしても、API があれば、それらの手間が、ときには関数の一つや二つで済む。それだけの違いがあります。その関数が、先の調べる手間を、システム内を調べることによって、自動的に行います。マイクロソフトが、自分の作るシステムにあらかじめデータベースを作って、あとはそれを調べるモジュールを作ってシステムに組み込めば、あとは利用者に API を使ってくださいよという仕組みにすれば、技術資料の請求の電話に出る必要もないし、私たちも情報がどこの会社にあるか、更にはコンピュータ内のどこにあるのか、を求めて駆けずり回らなくても済むのです。API は、そういう位置づけです。プログラミング言語を拡張したもの、ということもできます。まるでインターネットが発達したように、API も発達した、そんなふうにも言えないでしょうか。

( Windows API 関数の一つ、CreateWindow() 関数を使えば、ブラウザに部品としてついているような 「ボタン」や「コンボボックス」、「ステータスバー」 といったアイテムを、自分のプログラムでも使うことができます。これも仕組みの一部です。CreateWindow() 関数で作成するだけのことです。[ファイル(F)] [編集(E)] などと並んでいるものは 「メニュー」 ですが、それもあつかえます。メニューをあつかうには、 リソーススクリプト、CreateMenu() 関数等。 )

このように、API は仕組み、サービスです。このサービスを仮に、「もの」 としてとらえるなら、それは、「Windows API 関数、DLL、それの利用に伴う構造体、定数、型、(ヘッダファイル、重複するけど SDK )、レジストリも含むでしょうか」、といった具合に挙げることもできます。より集約すると、「DLL と SDK」 とで完結するかもしれません。ヘッダファイルに定義されている「定数」など考えると、これは「定義すること自体」も API という「サービス」に入る、と考えることが出来るでしょう。API を利用している立場から、仮に「定義」がされていないことを想像してみると、定義あってこその API なんだ、と考えざるを得ないのです。定数を種類ごとに分類して、全体的な定数群を構成していくというのは、なかなかに手間のかかることだろうと思うことではあります。 なんというか、その「価値」は、OS の常識、にゆだねられるとしても、「知的財産」のようなものを考えざるをえなくなります。あいまいな 「もの」 となるわけで、それがおそらく説明のしづらさの本質的な部分なのだと思います。ただ、OS 製作者もあまりユーザー泣かせなことはやめて、これからの OS には API を標準装備してください。

API の利用にかかわる処々の煩雑さの点においては、リソースエディタ(リソーススクリプトなど API としてはもはやかすっているくらいのものだと思うのでここで含めなくて良いくらいかもしれませんが) あたりを除くと、IDE があってもなくても、さほどかわらないことも言っておきます。　

コンパイラは普通、「Ｃ言語のコンパイラ」なので Ｃ言語しかコンパイルできないはずですが、Windows 用の Cコンパイラだと、Windows API を使ったプログラムでも特別にコンパイルしてくれます。言ってみれば、「拡張」されています。拡張されていないコンパイラが仮にあるとすれば、その場合は Platform SDK の利用を考えます。

API のおかげで、Ｃ言語のみの学習的なプログラムを組むよりは遥かに素直な形で、プログラムを組んで、実行した結果をわかりやすく、自分の目で確かめながら、プログラムを組むことを始めていくことができます。併行して C言語の習得を兼ねることだって、まったくもって無理のないこと、むしろ自然なこと、当然に可能なことであることを言っておきます。

補足 :　「なんとかプログラミング」 と名の付くものも あれこれ見かけるにつけ、Windows API というのがなんなのか気になるところだと思います。そのことに関しては次のことを参考にしてください。 コンソールで動くコンソールアプリケーション (をつくるプログラミング) の場合は、C/C++ とか、Fortran とか、"言語名"プログラミング、の形で区別すれば、これらの言語は教科書にも出ていることだし、混乱はないと思います。一方の、32 ビットの GUI、「ウィンドウズアプリケーション」 ( をつくるプログラミング) の場合、MFC や、VCL 、VB などの場合では、これらの根底には 「Windows API」 がかかわっている、と思ってください (Java や、C## は、この際除外して考えます)。 ただしこれらではほとんどの場合、「C/C++ と Windows API を使ったプログラミング」にとっては参考になりません。蛇足ですが、OS 製作側 (マイクロソフト) 次第で 、Windows API に依存しないプログラミングスタイルは増やすことができるのだ、ということを付け加えておきます。

補足 : COM も、Application Programmer Interface の一部のように考えることもできますが、もはや API として提供しきれない部分、量的にも整理のためにもまた、汎用性のことを考えても、もはや、API 関数のように使いやすい形で提供するのが困難な部分を、それよりは少し使いにくい形、COM Interface とか、guid とか、で、やっぱり提供しているサービスだと、いえなくもないんではなからうか。けれども API ほど、API と言えるほど、サービスとして確立できていない、と。そして、われわれから利用できるからサービスではあるけれども、これは OS 側の都合、みたいなところもあるんじゃないでしょうか。COM は ATL を使うことにより、利用できます。ATL は、Platform SDK のものを、利用します。

　この文書に参考文献はありません。すべて自分の言葉で書いています。

本文書の意味が分からない方は、ぜひ軽々しく転用することをおさけください。

本文書の一部または全部の無断の転用は、これを禁じます。2004/12/25

[another バージョン]

さて、例えばブラウザにはボタンやらアドレス入力欄やら、いろいろな部品がついています。ボタンは「ボタン」ですが、アドレス入力欄は、部品名を、「コンボボックス」 といいます。ほかにも下には、「ステータスバー」 がついていて、いたるところどの部分も、なにかの 「部品」 です。これらの部品は、マイクロソフト の作ったものであることはわかりますよね。そして、OS の 「部品」 です。

Windows API とは、これらもともとは OS 製作者が開発して、使ってきたのもを、普通にプログラムを組む側にも、同じようにこれらを使えるように、システムに組み込む形で提供 ( あるいは公開、開放ともいえます ) している、その「組み込まれた」 「仕組み」 のことです。開発者は、もちろん自分でも使いやすいように Windows API を作っていくに違いありません。そして、関数の豊富さにも、関数のネーミングにしても、そのことが現れているような気がしてならないのです。( new ! )

例えばこれらのウィンドウは、Windows API 関数 「CreateWindow() 関数」 を使うことで出すことができます。

CreateWindow() 関数は Windows API の一例にすぎず、本当は、Windows API は、ウィンドウを出すためだけにあるのではなくて、「プログラマーがプログラムを組むのを容易にする」 ため全般にあります。C/C++ や、Fortran、アセンブリといった言語で、Windows API を使わずにプログラムを組んでいくと、非常にやっかいな、システムへのアクセスやデバイスの操作といったことも、API を利用すると遥かに楽になります。この手間は実のところ非常にやっかいなのです。

これ以上の具体的なことを知るには、使ってみるほかはありません。また、Windows API を一番よく説明できるのは、ほんとうは開発者たち本人において他にないと思っています。以下は、Windows API をどう見るか、です。

視点によって、この仕組みは、提供しているサービスと言うこともできるし、また実際には、OS に組み込まれる形で提供されているから、 「OS に組み込まれた仕組み」 とも言うことができます。

API は、この GUI の時代に威力を発揮しています。マイクロソフトにしてみれば、必ずしも提供する「必要」はないから、そう考えれば「サービス」と言ってふさわしいかもしれません。しかしやがて、API が常識的に OS に組み込まれる時代に、もしも仮になったとすれば、特にそれをサービスと呼ぶことがなくなり、シェル、やカーネル、と同じように、OS を構成する要素として、普遍的なものして定着するのかもしれません。ただ、使っているとほんとうによくできていると感じることもあり、ついつい、「サービス」 と呼びたくなります。それに、マイクロソフトデザインの「ボタン」をいつも CreateWindow() するのだから、もしかしたらずっとサービスと呼ぶことになるのかもしれません。ただ、「サービス」 と説明していてはますますわかりにくくなります。

では、「OS に組み込まれた仕組み」 の視点からつまり、 Windows API はどこに組み込まれているのか、というと、それは、「システムを構成する DLL 」 に組み込まれています。あるいは それらの DLL は、Windows API にあたります (の一部です)。ところが、Windows API は DLL だ。とはいえません。このことは間違っています。

「もの」 のようにとらえる場合、システムを構成する DLL と、Microsoft SDK とで Windows API は完結します。Windows API は、 「Windows API を提供する DLL」 と、 「(MS) SDK」 です。Windows API 定数群の存在は Windows API の利用には欠かすことができないところ、それらの開発者による構築と、それらの具体的な形である ヘッダファイルのことは考えないわけにはいきません。それらの所在は SDK です。と、これ以上は、どんなコンパイラのどんな WinAPI ヘッダファイルを使っていても、結局 OS 開発者(MS) の知的財産を使っているのだということとか、そういうことだからせいぜい、コンパイラのヘッダファイルを使っていても勘違いすることに気をつけましょうとか、SDK をダウンロードして「所持」さえしていれば厳格な意味で正式な開発者として・・・とか、話のもって行きいようがないし、結論もありませんので、失礼しました、以上、この部屋は、Windows API について知識を拾っていってもらうページです。きちんと説明できるのは開発者だけですが、参考にしてください、あと、「Windows API」 と 「Windows API 関数」 はごっちゃごちゃに使われてしまうことが多いので注意してくださいね。本でさえそんな間違いがあって、そんな人でも本が書けるなんて・・・

だから、Windows API とは、「システムを構成する DLL の中の、Windows API を提供する DLL」 と、「Microsoft SDK の中の、Windows API の提供を目的とした部分」 です。