第3回 ARMアーキテクチャのWindows RTファースト・プレビュー：Windows 8レボリューション（3/3 ページ）
ARM対応の新Windowsがいよいよデビュー。Windows RTとは何か、IntelアーキテクチャのWindows 8とはどう違うのかを実機で検証した。
それでは、.NET FrameworkやVBScriptなど、プロセッサのアーキテクチャに依存しないアプリケーションは動作するのだろうか、いくつか試してみた。
Windows RTで.NET Frameworkのアプリケーションは動作しない
.NET Frameworkのランタイム向けに作られたマネージ・コードはプロセッサに依存しない中間言語（MSIL）で記述されており、.NET Frameworkは実行直前にネイティブ・コードに変換することで、マネージ・コードを実行する。もしWindows RTが.NET Frameworkを搭載していれば、マネージ・コードが動作する可能性がある。
Windows RTのWindowsフォルダには「Microsoft.NET」というサブフォルダがあり、「v1.0.3705」「v2.0.50727」「v4.0.30319」といったバージョンごとのフォルダが確認できた（同様のフォルダはx86／x64版のWindows 8にもあるが、その内容などは異なる）。
Windows RTの.NET Framework 4フォルダ
C:\Windows\Microsoft.NETフォルダの下には、.NET Frameworkのバージョンごとのフォルダがあり、関連するファイルやツールなどが保存されている。
そこで、試しに.NET Frameworkで作ったWindowsフォーム・アプリケーションを実行してみたところ（このアプリケーションは手元のx86版のWindows環境で作成したもの） 、「This application could not be started. It relies on a .NET Framework version that is not supported on this device.（このデバイスがサポートしていないバージョンの.NET Frameworkに依存しているため、起動できない）」というエラーが表示され、動作しなかった。.NETのバージョンについては、2.0、3.0、3.5、4.0、4.0 Client Profileを試したが、いずれも同じ結果となった。
なお、Windows 8には.NET Frameworkの一部のバージョンがインストールされておらず、コントロール・パネルから追加インストールできるものがある。しかしWindows RTではこの画面がWindows 8とは異なり、選択可能なWindowsの機能が大幅に減っていた。
「Windowsの機能の有効化または無効化」画面
Windows 8（左）とWindows RT（右）では、「Windowsの機能の有効化または無効化」画面の項目数が大きく異なる。Windows 8では.NET Framework 2.0／3.0／3.5 を追加できるが、Windows RTには該当する項目が存在しない。
興味深い点として、前述のx86ネイティブ・アプリケーションを実行したときのエラーと、.NET Frameworkによるマネージ・コードのアプリケーションを実行したときのエラーは異なっている。これは、Windows RTがマネージ・コードの実行を検出し、専用のエラー・メッセージを表示していることを意味する。
.NET Frameworkの利点として、プラットフォームの違いをCLR（Common Language Runtime）が吸収することにより、さまざまなバージョンのWindows OSで同じマネージ・コードを動作させることができる点があった。そういう意味では、Windows RT上で.NET Frameworkのマネージ・コードが動作しないのは残念な仕様という印象を受ける。
どうしてもこれらのアプリを利用する必要がある場合、MicrosoftはWindows RTから別のWindows 8やWindows 7マシンにリモート・デスクトップ接続するという方法を推奨している。
Windows RTでC#ソース・コードのコンパイルはできない
Windows RTで.NET Frameworkのマネージ・コードは動作しなかったが、Windowsフォルダには.NET Frameworkの一部ファイルが存在することが分かった。
Windowsフォルダ下の「Microsoft.NET」フォルダ下には、各バージョンに対応した「csc.exe」というC#のコンパイラが存在する。これを用いれば、Visual Studioや.NET Framework SDKを別途インストールすることなく、Windowsだけでコンパイルを実行することができる（C#のコンパイル方法などについては関連記事参照）。
そこで、Windows RT上で非常にシンプルなC#のソース・コードをコンパイルしてみた。すると次のようなエラーが発生した。
using System;
public class CSharpTest
{
public static void Main()
{
Console.WriteLine("CSharpTest");
}
}
これを例えばMain.csというファイルに保存し、「csc Main.cs」のように実行してコンパイルする。
Windows RT上でコンパイルする
C#のソース・コードをMain.csというファイルに保存し、Windows RT上で「csc Main.cs」のようにしてコンパイルすると、このようにDLLファイルが見つからないとうエラーになる。
エラー・メッセージによれば、「System.Data.Linq.dll」などを始めとするいくつかのDLLが見つからないとのことだ。これらのファイルはx86／x64版のWindows 8のMicrosoft.NETフォルダには存在するが、Windows RTには存在しなかった。
今回は試行できなかったが、csc.exeが参照する設定ファイルを編集することにより、これらの依存関係を変更することで、コンパイルが成功する可能性がある。
しかし、デフォルトの状態でエラーが発生するということは、Windows RTがユーザーによるC#コンパイラの利用を想定していないことを意味している。また、EXEファイルの出力に成功したとしても、それを実行したときには前述した.NET Frameworkアプリの実行時エラーにより起動できない可能性が高いと考えられる。
Windows RTでもPowerShellやVBScript（WSH）は実行可能
C#のコンパイル時にも利用したが、Windows RTではコマンド・プロンプトやバッチ・ファイルといったコマンドライン環境もサポートされている。さらにはWindows PowerShellも利用できる。
実際にWindows PowerShellを起動してGet-Commandコマンドを実行してみたところ、使用可能なコマンドレットの一覧を取得することができた。
また、Windowsフォルダの下にはWindows Scripting Host（WSH）関連のファイルも存在している。そこでVBScriptファイルを作成し、MsgBox関数を実行してみたところ、これも正常に動作した。ほかにもZIP.VBS（「コマンドラインでZIPファイルを作成/追加/置換/削除/展開/表示するVBScript（Vector）」参照）を用いたZIPファイルの作成や、WMIによるシステム情報の取得を試したところ、問題なく動作した。
このことから、Windows RTにはPowerShellで利用できる基本的な.NET Frameworkのライブラリに加え、WSHやVBScriptから利用できる基本的なCOMコンポーネントも搭載されていることが推測できる。
これらのスクリプティング環境は、EXEファイルほど自由度の高い処理を記述することはできないが、Windows RTの運用におけるさまざまな処理を自動化することができそうだ。
今回は、展示されていた実機を基にWindows RTとはどういうものか、互換性はどうかなどについて簡単に見てきた。Windows RTについては、正式販売開始後に改めて詳細に解説する予定である。
Copyright© Digital Advantage Corp. All Rights Reserved.