ARM版のWindowsを作るためには
MinWinが必要だった
Windows 7でAPIが整理分類され、最低限必要なAPIセットが定義されてMinWinが作られたのは、Windows 8への準備でもあり、今後のWindowsの発展に必要だったからだ。MinWinは、起動してコンソールアプリケーションが動く程度の、最低限の要素からなるWindowsの根幹部分である。まず、最低限必要な部分を確定させることにより、ほかのCPUアーキテクチャー(そうARMだ)への移植作業が簡略化できる。
すべてのAPIを分類整理したことで、新しいアーキテクチャーのプロセッサーへ移植すべきAPIを確定できた。過去との互換性のために残されるOSのプログラムコードの大部分は、APIに関連するものだ。古いアプリケーションが古いAPIを使っているから、それを処理するプログラムコードが必要になる。だがOSが新しいプロセッサーアーキテクチャーに対応する場合、そこには古いアプリケーションは存在しないため、互換性維持のためだけのコードは不要になる。
Windowsではこれらを排除するためには、APIを分類整理したうえで、古いAPIと必要なAPIを実装しているDLL部分を、分離する必要があった。Windows 7はその準備を行なったわけだ。Virtual DLLにより、実際にAPIを提供するDLLをアプリケーションからは見えなくしたことで、APIとDLLの関係を自由に変更できるようになった。
Windows 7と開発中のWindows 8の構成を見るに、マイクロソフトはWindowsのAPIセットを切り替えるというWindows Vista開発時の方向性は完全に放棄した。従来からのWin32 APIセットは整理しつつ継続する一方で、同時にMetro環境を導入し、複数のAPIセットと実行環境を維持するという方向に切り替えたようだ。
実行環境が違い、ユーザーインターフェースも違うため、Metro StyleとWindowsデスクトップの両方で動作するアプリケーションというのはありえない。今後のWindows 8対応アプリケーションは、このどちらかひとつを対象に開発される。しかし、アプリケーション開発の基本技術としては「.NET Framework」があり、アプリケーションのロジック部分を共有することは可能だ。ユーザーインターフェースは異なっても、開発言語や開発環境は単一のもので開発できる、という理論なのだと考えられる。

この連載の記事
- 第12回 アプリがWindowsの機能を使うには? APIとDLLの仕組み
- 第11回 マルチコアCPUの消費電力はスケジューリングで変わる?
- 第10回 AMD FX向けにパッチで修正 スケジューラーが抱える難題
- 第9回 マルチコアCPUを賢く使いこなす スケジューリングの秘密
- 第8回 意味の違いがわかる? タスクとプロセスとスレッド
- 第7回 Windowsのメモリー管理をx86の仕組みから読み解く
- 第6回 メモリー不足を根本的に解決する64bit OSの仕組み
- 第5回 Windows 8でMetro Styleアプリを動かす「WinRT」
- 第4回 Windowsを動かすデバイスドライバーの仕組み 前編
- 第3回 OSの仕事はハードウェアをアプリから「隠す」こと?
- この連載の一覧へ