マウスを例に見る
OSによるハードウェアの抽象化
マウスを例に挙げよう。世の中には非常に多くの種類のマウスがある。最近はほとんどがUSBに接続するものばかりだが、Bluetooth経由で接続するものもあれば、今ではほとんど見かけないPS/2ポートやシリアルポートに接続するもの、さらには専用のインターフェースカードを持つマウスさえ過去にはあった。
マウス自体もボタンが多数あったり、ホイールの有無など、さまざまなバリエーションがある。しかしそのマウスが「Windows用」と謳っていれば、対応するWindowsでどれも同じように利用できる。これは、OSがマウスというデバイスを「抽象化」して、どれも同じようなやり方で扱えるようにしているからである(図3)。
だからアプリケーションを作る際に、そのパソコンにつながっているマウスのボタンがいくつあるのかを基本的には考える必要はないし、動作するときにどんなマウスがつながっていても、それがマウスであるかぎり問題なく利用できる。さらに言えば、アプリケーションは必要がなければ、マウスの存在自体を考慮することなく作れるが、それでもマウスを使って操作できる。
マウスの役割のひとつは、ユーザーの操作に従って画面上の位置を指定することだが、マウス自体はディスプレーとは無関係に動き、元あった位置からの相対的な動きしか報告しない。OSはこうしたマウスの特性を考慮しながら、「マウスポインター」(マウスカーソル)を画面上に表示して、ユーザーの操作に従いこれを動かす。
マウスは「ポインティングデバイス」と呼ばれる種類のデバイスとして管理されていて、絶対的な座標を扱う「タブレット」や、「トラックボール」などの他のポインティングデバイスも同じように利用できる。OSはデバイスがどのようなやり方でユーザーの操作をパソコンに伝えるかに関わらず、どれもがポインティングデバイスとして使えるように、個々の違いを「隠蔽」しているのである。
では、どうやってアプリケーションはマウスを使うのか? Windowsの場合、ポインターの位置やボタンを押したことを、OSから「報告」してもらうという仕組みになっている(図4)。Windowsでは、これをAPI(Application Program Interface)という、OSがアプリケーションに対して提供している「機能」の中に持っている。
どのようなポインティングデバイスがパソコンに接続されていても、また接続方法がどのようなものであろうと、アプリケーションがAPIを使うことで、カーソルの位置を取得したり、ボタンが押されたという報告を待てばいい。細かくマウスの動きに追従したければ、そのためのAPIも用意されているので、これを使って位置やマウスボタンの状態を取得できる。
また、ポインティングデバイスで操作する画面上の「ボタン」を扱うには、マウス自体をアプリケーションが意識する必要はない。ユーザーがボタンを押せば、アプリケーションには、「ボタンが押された」ことが報告される。
ユーザーは実際にはタブレットを使っているかもしれないし、実はタブレットPCを使い、ペンで画面上のボタンをタップしたのかもしれない。あるいはカーソルキーでボタンを選択してスペースキーを押したのかもしれないし、ボタンに定義してあるショートカットをキーボードから入力したのかもしれない。
画面上の「ボタンを押す」にはさまざまな手段があるが、OSはどれも同じように、「ボタンが押された」ことをアプリケーション報告するだけだ。アプリケーションはポインティングデバイスの存在自体を意識する必要すらない。
この連載の記事
-
第13回
PC
ARM版Windows 8実現の布石となったWindows 7の「MinWin」 -
第12回
PC
アプリがWindowsの機能を使うには? APIとDLLの仕組み -
第11回
PC
マルチコアCPUの消費電力はスケジューリングで変わる? -
第10回
PC
AMD FX向けにパッチで修正 スケジューラーが抱える難題 -
第9回
PC
マルチコアCPUを賢く使いこなす スケジューリングの秘密 -
第8回
PC
意味の違いがわかる? タスクとプロセスとスレッド -
第7回
PC
Windowsのメモリー管理をx86の仕組みから読み解く -
第6回
PC
メモリー不足を根本的に解決する64bit OSの仕組み -
第5回
PC
Windows 8でMetro Styleアプリを動かす「WinRT」 -
第4回
PC
Windowsを動かすデバイスドライバーの仕組み 前編 - この連載の一覧へ