CESネタ第二弾。相変わらずtwitterで呟いたネタと被りながら。
◇
MSがまた衝撃的な発表を。次のWindowsでARM SoCをサポートするって？！
何というか、正直「どうするのよソレ」という点が山積みの気がするのだが。
取り敢えず並べてみるか。
1・ARM SoCに一体どれだけのメモリを積ませる気？
2・ARM Coreで性能足りるの？
3・非互換バイナリの扱いどうするの？
4・Windowsの値段どうするの？
結構ある気がするなぁ、問題が。
順番に行きまっか。
◇
まず、最初の疑問。ARM SoCに一体どれだけメモリ積ませる気なのかということ。
現行のWindows 7 x86をベースにするなら、最低でも1GBはメモリを積んでいないと使い物にならない。
快適さを語りたければ2GBは無いと厳しい。
一方で現行のARMベースの機器、その中でも低価格志向のいわゆる中華Padなんかでは、メモリ128MBなんてのも珍しくない。高性能クラスのAndroidケータイでも512MBぐらいなので、少なくとも現在ではGB単位なんて夢のまた夢。
それに一般論として、ARMベースの機器では全体の消費電力が少ない分、メモリが使用する消費電力の大きさが問題になることが少なくない。これも一般論だが、メモリは容量が大きい程電気を喰うので、大容量メモリの搭載はそれだけで全体の消費電力の上昇につながりかねない。
◇
次、根本的にパフォーマンス足りるんかい、ということ。
確かに最新のDual Core ARMなんて、ヘタすりゃSingle Core Atomより演算性能は高い。が、それは演算性能での話。
システムのパフォーマンスは演算性能だけではとても語れない。バス帯域、メモリ帯域、VGA性能、その辺りが全部積み重なってシステムパフォーマンスを構成している。
一方で、特にVista以降のWindowsはこういうCPU演算速度以外のリソースについては非常に多くを要求するようになって来ている。Intelは当初この辺りを軽く見ていた為にAMDがシェアを伸ばせたというのは誰が見ても事実だし。
そして悪いことに、この辺りのリソースというのは一般的にコストも高いし電気も喰う。CPUが低消費電力で低価格であっても、周辺が電気とコストを喰いまくってしまえば意味が無い。
ついでにこの辺りの「PCとしての部品一式パッケージ」については、現時点ではIntelやAMDの方が一日の長がある、という気がする。
◇
三つめ、バイナリ非互換性の問題。その運用をどうするか、ということ。
知っている人は少数派かも知れないが、複数のアーキテクチャで動いていたWindows CE系のソフトでは、CEのバージョンやアーキテクチャの違いで、一つのソフトでも4種類も5種類もバイナリがあったのが当たり前だったのであり。こんな状態を許容出来たのは、ぶっちゃけユーザがヲタクだからとしか言い様がない。
現在でもWindowsではIA64というx64とは別のアーキテクチャが存在するが、IA64なんてServer向けで且つ基本的に技術者以外触らないので特に問題にはなってない。
が、コンシューマに触らせるとなるとこの辺りをどうするかというのか大問題の筈。
現在のWindowsではFAT Binaryの仕組みは持っていないと思ったので、このままではインストールパッケージ自体を複数に分けて大不評を買う羽目になる。駄目だこりゃ。
とはいえMSもそこまで馬鹿じゃないだろうから、大慌てでFAT Binaryの仕組みを導入して、インストーラがバイナリを選んで導入するようにするのかね、やっぱり。
・・・さて、FATバイナリ インストーラの作成とARM用バイナリのクロスコンパイラが入るのはVS2011になるのか、それとも2012か。
◇
最後、Windowsの値段どうするの、と。
既にx86でも問題になっているが、Windowsがハードの値段に対して高過ぎるんですな、真面目な話。
ARMのハードウェアならハードウェアの値段は高くとも現在の「ネットブック」程度に収まるだろうから、それに見合うとなると一番高くともWindows 7 Starterと同程度の値段付けしか出来ない筈。
そしてMSがx86向のフル機能Windowsの値段を現在より下げるというのは非常に考えにくいので、そうなると機能的にも現在のStarterと同程度に絞られる筈。
但しこれ、逆に言うとARMのハードウェアパフォーマンス的にもStarter相当で相応、ということになるのかも知れない。
どちらにしろ、ARM版Windowsはx86フル版と同一Edition同一価格、とはいかないのでは。
◇
以上で散々うだうだ言ったように、全体として当方はフル機能Windows on ARMには懐疑的。少なくとも現時点のARMなCPUやARM採用ハードウェアの数々を見ている限り、ARM版Windowsが発売されても非常に限定的な場所でしか採用されないようにしか見えないのですよ。
但し、MSがこのARM版を現在Windows XP EmbbedやWindows Embedded Standard 7辺りが動いている、いわゆる組み込みやThin Clientというジャンルに向けるなら話は別。
この辺りを相手にするならメモリもパフォーマンスも（コンシューマ相手のフル機能品よりも）少なくて済むし、ついでにこの辺りの製品では通常競合は「ARM＋Linux」という構成。メモリやCPUクロックに差分があったとしても、基本同一のARMハードウェアでWindowsもLinuxも動かせるというなら、ハード供給側にもメリットは少なくないのでは。
とまぁ、こんな感じで。
インストールパッケージをアーキテクチャごとに分けずに済ますことは、Windows Installer (.msi)でも可能です。msiに各アーキテクチャごとのバイナリファイルを同梱し、インストール時にコンピュータのアーキテクチャに合う1つだけをインストールするというつくりで十分だと思います。
（この意味でFATバイナリと称しているのではあれば、失礼しました）
もちろん、msi自身は基本的にネイティブな実行コードでできているわけではありませんのでポータブルです。
ただ、ファイルサイズの問題で、各アーキテクチャごとに別のインストーラを用意するのがあいかわらず主流になると思います。今のx86とx64の2種でさえ、インストーラを別ファイルにしているアプリばかりのように感じます。
御指摘の通り、msi使えば共通インストーラが作れますね。すっかり失念しておりました。
その場合はアーキテクチャ識別IDが追加されてWindows Installerのバージョンが上がるのでしょう。
但しこの場合、インストーラを使わない小さなtoolなんかはやはりアーキテクチャ別にバイナリを用意する羽目になるワケでして。ん～～～。
個人的にはMSがイロイロと覚悟を決めてFAT Binaryの仕組みを導入するのが一番だと思ってます。
御指摘のようにファイルサイズ肥大化の問題はありますが、現在のストレージ容量を考えれば、利便性と天秤にかけて「アリ」だと思いますし。
♯FAT Binaryを導入したら、ついでにMS純正の「他アーキテクチャ用バイナリの切り落としツール」なんてのをSupportTools辺りにこっそり入れておいてくれたりすると幸せになれる人も多いでしょうし。