日々の破片

_ マイクロソフトは何か勘違いをしている

Windowsの開発をすることを考える。スタンドアローンのWindowsアプリケーションではなく、クライアント＋サーバのシステムだ。

組み合わせは次のいずれかとなる。

1. クライアント＝Windows7(x64)＋サーバ＝Windows Server 2008(x64)

2. クライアント＝Windows7(x86)＋サーバ＝Windows Server 2008(x64)

3. クライアント＝Windows7(x86)＋サーバ＝Windows Server 2008(x86)

4. クライアント＝Windows7(x64)＋サーバ＝Windows Server 2008(x86)

で、問題は、1と2の場合だ。

この場合、開発環境は次の組み合わせが考えられる。

1. クライアント(x64)PC + サーバー用(x64)PC

2. クライアント(x86)PC + サーバー用(x64)PC

3. クライアント(x64)PC + 仮想PCサーバー(x64)

4. クライアント(x86)PC + 仮想PCサーバー(x64)

5. サーバー(x64)PC + 仮想PCクライアント(x64)

6. サーバー(x64)PC + 仮想PCクライアント(x86)

このうち、1と2はどうでも良い。どうでも出来るからだ。

問題は、上記の組み合わせのうち3と4が純正な環境では構築できないことにある。でも、4は直観的にできなくてもしょうがないなぁとは考えられるので、問題は3だ。

3と5,6の違いは明らかで、グラフィック処理とか細かいところが（DirectXもそうだし、Silverlightグリングリンとかいくらでもある）、サーバWindowsとクライアントWindowsではクライアントWindowsのほうが使い勝手が良い点にある。気分の問題かも知れないがVisual Studioもサーバで実行するよりクライアントで実行するほうが高速に動作するように感じる（JITがWindows Froms最適化しているのではないかとかいろいろ要因もありそうだ）。つまり、ホストをWindowsサーバにして、仮想マシンでクライアントを動かすという運用はまったく魅力がない。（とは書いているが、勤め先ではグラフィックがしょぼいマシンを開発用に利用しているのでホストがWindows Server 2008なので気づいていなかった。昨日、家のマシンにサーバ環境を入れようとして気付いたのだった。）

したがって、開発以外での利用も考慮すると、ベストな選択肢は3となるのだが、問題は、純正な環境ではこれが作れない点にある。

具体的には、Windows7組み込みのWindows Visrtual PCがCPUをx86に固定しているからだ。Windows Server 2008(x64)をインストールしようとすると、すぐさまサポートされていないハードウェアとしてはねられてしまう。

ではどうすれば良いかというと、どうしても純正環境でやりたければ、クライアントPCの利点を捨てて、5や6でやる（Hyper-Vなら何でもできる）か、あるいはデュアルブート以上にする（だが、これはすごく負けた感がするし、ブートし直すというのは現在のコンピュータの運用から言えば最悪だ。環境構築の都度、マシンが占有されるのもたまらない。ただ、世の中には、開発者全員が同一のイメージで利用できるように、あらかじめ仕込んだサーバ上の開発環境をVHDで渡して、VHDブートして開発環境へ移るという運用をしているところもあるようだ。それはそれで良さげではある）。

さもなければサードパーティ仮想マシンを利用することになる。VirtualBoxならばっちりだ（ちゃんとマウスキャプチャの仮想ドライバや、NATで外に出られるネットワーク仮想ドライバも提供されているので、使い心地も良い）。

でも、それっておかしくないか？ Hyper-Vのように、当然といえば当然だが、マイクロソフトは使えるx64の仮想マシンを持っているのだ。

というわけで、マイクロソフトは、Visual Studio 2010 Pro以降のSP2以降では、Virtual PC for X64を開発者に提供すると良いと思う。

Microsoft Visual Studio 2010 Professional with MSDN(-)

（MSDN更新の時期だが、今年からはProにして、Officeは別に買うことにするかな。どうせInfoSetとか使ってないし)

【旧商品】Microsoft Office Home and Business 2010 通常版 [パッケージ](-)