Windows To Goのまとめ

Windows To Goの最終的な姿がWindows 8 RTMとともに明らかになったので、まとめておこうと思う。

1. 条件

使用条件は以下のとおり。狭き門となっている。

1.1. 対象ユーザー

ソフトウェアアシュアランス（SA）プログラムに入った、ボリュームライセンスのユーザー向けのEnterprise版のみ。つまり企業ユーザーの下でその社員が使う場合のみで、個人ユーザーには提供されない。

[参考]
TechNet: Windows To Go Frequently Asked Questions

1.2. ハードウェア

PC本体側の条件はWindows 7かWindows 8の動作条件を満たしていればいいので問題にはならないが、USBメモリというか、USBドライブ側の条件は厳しい。

8月15日現在、MicrosoftがWindows To Goが使えると認定した（certified）USBドライブは、以下の2機種のみ。

• Kingston: DataTraveler Ultimate (Workspace)（プレスリリース）
• Super Talent: USB3.0 Express RC8（プレスリリース）

[参考]
TechNet: Windows To Go: Feature Overview: Hardware considerations for Windows To Go
Kurt Shintaku's Blog: INFO: A word about Windows-to-Go for Windows 8 Enterprise & Certified Hardware

いずれも一般的なUSBメモリとは違って、内部的にはSSDにUSBインターフェイスチップを付けてUSB接続にした製品で、ランダムライトが高速なのが特長だが、それ以上に門を狭くしているのはPCに接続した際にリムーバブルディスクではなく、ローカルディスクとして認識されなければならないという点。

RPまでのWindows To Goではリムーバブルディスクの場合はWindows Updateが不可という問題があったが、結局リムーバブルディスクは対象外と整理されたことになる。いずれにせよ、USBメモリでローカルディスクと認識される製品は例外的なので、ほとんどのUSBメモリは対象から外れることになる。

一方、SSDをUSBケースに収めたUSB SSDであるところのUSBドライブでも、ローカルディスクと認識されるものなら可なので（サポート外だが）、その手を厭わなければこの条件をクリアするのは難しくはない。

なお、DataTraveler Ultimateについては、既存のG1のコントローラはJMicron、G2はPhisonと判明しているが、このWindows To Go用のDataTraveler WorkspaceはLSI、つまりSandForceのようなので、中身は別物らしい。

[追記1] DataTraveler Workspaceのデモ

IDFでKingstonからDataTraveler Workspaceのデモがあった。コントローラはやはりSandForce。筐体はUltimateからデザインが変更されているが、丸く寸胴な基本形状は変わっていない。

[関連]
engadget: Kingston DataTraveler Workspace hands-on

[追記2] DataTraveler Workspaceの中身

The SSD ReviewによるDataTraveler Workspaceの記事（Kingston Data Traveler Workspace Windows To Go Flash Drive Review）によると、DataTraveler Ultimateと同様にPCBを2枚重ねにした構造で、コントローラはSandForceのSF-2241。チップと筐体との間に熱伝導シートがべったり挟まれている当たり、発熱はそれなりにありそうではある。性能的には期待どおりといったところ。

[追記3] Express RC8との比較

同じThe SSD ReviewによるExpress RC8の記事（Super Talent USB3 Express RC8 100GB Flash Drive Review）によると、コントローラはSF-1222で古いにもかかわらず、同じ環境でのCrystalDiskMarkなどベンチマークの結果はDataTraveler Workspaceより上だったりして、少し意外なことになっている。

2. Express RC8

この2機種のうちDataTraveler Ultimateは限定販売なので、普通に入手できるのはExpress RC8のみとなる。このExpress RC8は1年ぐらい前から存在する製品だが、流通が限られていて影の薄い存在だったところで、いきなり抜擢された感がある。

ということで、この機会に25GBモデルを買ってみた。

SunDiskのCruzer Titanium、Green HouseのPicoDrive F3と並べてみたところ。

厚みは同じぐらいだが、面積は二回りは大きい。日本での取扱元となるらしいアーキサイトのページを見ると、この中にSandForceのSF-1222が入っている。

初接続時にCrystalDiskInfo（5.0.3）で見たところ。使用歴は検査時のものか。

ThinkPad X61sのUSB2.0ポートに差した場合の性能をCrystalDiskMark（3.0.2 Beta）で確認した。テストサイズは1000MB。シーケンシャルアクセスはPC側にボトルネックがあるので、注目するのはランダムアクセス。

やはりランダムライトは別世界の速さ。比較のためにMSD6000をUSBケースに入れた場合が以下。

MSD6000でもWindows To Goは何の支障もなく動作することが分かっているので、Express RC8の性能は十分以上ということが分かる。

性能とは関係ないが、例によって青色LEDが眩しいのは何だかな。

[追記] USB3.0との関係

自分がUSB2.0ポートで試してきた経験から断言するが、Windows To Goの動作の軽さとUSB2.0かUSB3.0かは関係ない。関係があるのは主にランダムライトである。

ここで問題はランダムライトの高速なUSBメモリがごく限られていることで、世代が進むにつれてランダムライトの激しく遅い製品が主流になってきているらしい。

[参考]
忘却の彼方: USBメモリの書き込み速度が遅い（USB3.0対応）

で、メーカーはUSB3.0のシーケンシャルアクセスの速度を前面に出し、ランダムライトにはあえて触れないようにしているようなので、何も考えずにUSBメモリを買ってきたらランダムライトの激しく遅い製品だった、ということが普通に起こると思われるので、（認識の問題とは別に）注意が必要。

3. Windows To Go ワークスペースの作成

Windows 8 RTM評価版はEnterprise版で、Windows To Goの作成ツールがコントロールパネルにあるので、RPまでのような手順を踏まずとも簡単にWindows To GoのUSBドライブが作成できる。

[参考]
Kurt Shintaku's Blog: HOWTO: Create a Windows-to-Go bootable USB stick with the Windows 8 Enterprise (RTM/Release)

Express RC8、MSD6000、PicoDrive F3を差した状態（すべてUSB2.0ポート）で、先に認識のされ方を確認しておくと、Express RC8（USB3.0_RC8と表示）はローカルディスクの認識で間違いはない。

この状態で作成ツールを起動すると、自動的に検索されて表示される。

Express RC8が選択された状態ではリストの下に何も出てないが、MSD6000（MSD-SATA6025と表示）に移動すると、「このドライブを使用すると、Windowsのパフォーマンスに影響する可能性があります。最適な結果を得るには、Windows To Go対応のUSB3.0ドライブを使用してください。」と出る。

検索した際に何らかの確認をした結果だと思うが、検索はすぐに終わったし、何を確認したのかは分からない（実は上の参考ではExpress RC8の50GBモデルを使っているが、これと同じメッセージが出ている）。この状態でも問題なく作成はできる。

さらに下のPicoDrive F3に移動すると、今度は「これはリムーバブルドライブで、Windows To Goに対応していません。必要なハードウェア仕様を満たすデバイスを選択してください。」となる。こうなると先には進めない。

この後はイメージファイルを選択して（インストール用のISOファイルをマウントし、そのドライブを検索先に指定した）進めば、何事もなく作成は終了する。

結果は、まあ当然のごとく快適に動作するWindows To GoのUSBドライブが出来た。使用容量は約10GBだったので（イメージファイル次第で変わる）、25GBの容量で問題はなかった。

4. 終わりに

割と便利に使えそうな機能なので、昨年来追いかけてきたが、条件的に個人ユーザーには縁遠いものになってしまったのは勿体ないと思う。が、元からライセンス的には扱いが難しそうだったので、そこは何とも言えない。

まあ自分のExpress RC8はOS起動用として十分な性能があることが分かったので、RTM評価版の期限が終わったら他のOSで使ってみようかと思う。

High DPI Windows 8 Cursor Set

Windows 8のDPIを200%に設定した場合の問題は、結局RTMでも修正されてなかった。それはさて置き、そもそもこの問題はプログラムに問題があるというより、アイコンあるいはカーソルの画像リソースが足らないだけということに気づいた。

以下はRTM評価版のエクスプローラを見たところだが、ウィンドウのデザインは変わったが、カーソルと上向き矢印の問題は変わってない。

リンクなど他の状態のカーソルも同様。

この問題は実際にMacBook Pro RetinaにWindows 8 RTMをインストールし、DPIを200%にしたときにも確認されている。

[参考] 例
TechRepublic: Combining Windows 8 and a Retina MacBook

で、Windows 8でアイコンの表示を確かめていたときに、この輪郭が汚くなった状態は、アイコンファイルに現在のDPIで表示されるべきサイズの画像が含まれておらず、それより小さなサイズの画像が引き伸ばされて表示されたときの状態と同じことに気づいた。

いや、引き伸ばされたからといって直ちに形状が崩れる必然性はないが、引き伸ばす際に縦横比が微妙に狂ったりして、一言でいえばOSによる画像の拡大が下手なのだと思う（縮小する方は上手なのだが）。

ともかく、そういうことなら本来表示されるべきサイズ（200%なら64x64）の画像をファイルに含めてやればいいわけで、そういうカーソルファイルを作成してみた（エクスプローラの上向き矢印の方は、システムファイルに埋め込まれたリソースを使っているようで、これをいじるのは面倒なので諦めた）。

以下は作成したカーソルに変えた場合の表示。

輪郭がこのDPIにしては少し細いような気もするが、とりあえずこんなところ。

[追記1] Animated Cursor Packer

3つ以上のサイズを持つアニメーションカーソルファイルを作成できる既存のアプリがなかったので、作成したもの。サイズ別に分かれていたものを統合できれば、DPIによってファイル指定を変える必要もなくなるので。

アニメーションカーソルはRIFFファイル形式の一種だが、複数のサイズを持たせる方法が見つからなかったのでOS標準のものを覘いたところ、ファイル構造は単一のサイズだけのアニメーションカーソルと変わらず、中に含まれる個々のカーソルデータが複数のサイズの画像を持っているかどうかの違いだけのようだった。

それならと、カーソルデータの作成は他のアプリに任せ、カーソルデータ（実際はアニメーションなしのカーソルファイルそのまま）をまとめてアニメーションカーソルファイルにする部分だけを作ったのがこのアプリ。元のカーソルファイルの中身は関知しないので、単一のサイズだけのカーソルファイルを元にすれば単一のサイズのアニメーションカーソルファイルが出来、複数のサイズのカーソルファイルを元にすれば同じ複数のサイズのアニメーションカーソルが出来るという具合い。

アニメーションカーソルを作成できる既存のアプリは、カーソルデータの作成とアニメーションカーソルファイルにまとめることの両方をやるわけだが、これを分離することで、複数のサイズのカーソルファイルを用意すれば同じ複数のサイズのアニメーションカーソルファイルが作成できるようになり、サイズの数に制限がなくなるというのがポイント。

……と書きつつ、Microsoftの資料にないことなので確証はないが（アニメーションカーソルに関する情報はWin95の頃で止まっていて、その後複数のサイズを持つアニメーションカーソルが出てきてもアップデートされておらず、複数のサイズを持たせるための情報がない状態）、とりあえずうまく行っているようだからよしとする。

[参考] アニメーションカーソルのRIFFファイル形式に関する数少ない包括的な説明
O'Reilly: Microsoft RIFF
("Size is the number of bytes in the subchunk that appear after the Size field. This value is always 32."にある32は、36の間違いだと思う。この10進数に対応する位置の16進数は24なので)

[追記2]

High DPI Cursor Changerの方に統合した。

Metroアプリ

デモとして作っていたMetroアプリが一応形になったので。

1. Raidar Metro Demo

Windows 8 RP上のVisual Studio 2012 RCで作ったが、もうWindows 8もVisual Studio 2012もRTMが一般の開発者向けに出る直前で、RTMでまた動作に変更がある可能性があるが……。言語はC#とXAML。

機能的にはNAS Herderのモニター機能のサブセットで、ロジック部分はVisual BasicからC#に大体そのまま移植。このメインページと設定ページの構成で、この間のページ遷移は本来スワイプで出すNavigationBarかAppBarを使うべきだが、とりあえずAppBar用のSettingsのアイコンを置いている。

対象のNASを指定する方法はHost NameかIP Addressの選択式。Scanで見つかったNASを表示する部分はGridViewで、唯一Metroらしい見た目。トースト通知はStatusにWarningが出た場合か温度が閾値を上回った場合に出るが、音声設定がうまく行かないのでデフォルト音声のまま。

これらの設定項目は、変更がある度にApplicationData.LocalSettingsに保存するようにしているので、このアプリのサスペンド時には何もしない。

Metro特有の要求の一つが4つのレイアウト（デフォルトの全画面横長のFullScreenLandscape、Snappedになった別のアプリが横に入って幅が狭まったFilled、全画面縦長のFullScreenPortrait、横に寄せたSnapped）への対応だが、とくにSnappedは要素の配置を大きく変える必要がある。

ちなみに、このレイアウト遷移をアニメーションと呼んでいるが、実際にはアニメーションするわけでも何でもなく、ただ配置が切り替わるだけ（XAMLのアニメーション機能で、いきなり最終値に変えるメソッドを待ち時間0で実行）という。

メインページを左側にSnappedにすると、こうなる。右側はデスクトップ。

やっていることは、

• タイトルのアイコンを非表示にする。
• Ping NASのButtonの列は、各要素を入れたGridをStackPanelに入れているが、この配置方向を横にしていたものから縦にし、サイズも合わせて変える。
• Settingsのアイコンを非表示にする。
• StatusのTextBoxの位置を下げる。
• CPUなどの各項目は、各要素を3つに分けて入れたGridをStackPanelに入れているが、これも配置方向を横から縦にし、サイズを変えて位置を下げる。
• WarningのTextBoxのサイズを変えて位置を下げる。
• 一番下のRaw responseのTextBoxを非表示にする。

なお、このページは基本ページ（Basic Page）のテンプレートから作ったもので、タイトルのフォントが小さくなっているのはテンプレートによるもの。また、タイトルのアイコンの位置に、元のページに戻るbackButtonのアイコンが要素として存在する。これは最初のページの場合は実際には表示されないが、不要かといえばそうでもなく、ページ履歴の管理に関係しているようで、削ってしまうとSnapped状態のときにこのページに戻れなくなる。

ついでに、デスクトップの壁紙を見ていて気づいたが、Filled状態になったデスクトップは、アイコンは移動しても壁紙は移動しないらしい。

次にSnapped状態の設定ページ。Snappedになったら自動的にメインページに遷移することも考えたが、一応用意した。

やっていることは、

• Scan NASのButtonの列も、同じくStackPanelの配置方向を横から縦にし、サイズを変える。
• 見つかったNASを表示するGridViewは、実は同じ内容のListViewも要素として存在していて、このGridViewを表示にしてListViewを非表示にしていたものを逆にする。
• Ping Intervalなどの各項目も、同じくStackPanelの配置方向を横から縦にし、サイズと位置を変える。
• 一番下のRaw responseのTextBoxを非表示にする。

このGridViewとListViewを両方持っていて切り替えるという方法は、非効率な気もするが、Grid AppとSplit Appのテンプレートでやっている方法なので。なお、これらの中のGridはItemTemplateでサイズを指定しているが、実際に表示されるサイズは外のGridViewとListViewのサイズにも影響される模様。

以上、このプロジェクトファイルはNAS Herderのプロジェクトサイトに置いてある。ただし、Microsoftの審査は受けてないので開発者ライセンスのあるPCでしか実行できない。そもそも常駐できない監視アプリに何の意味があるのか、という致命的問題があるが……。

2. プロジェクトのテンプレート

アプリを作り始めるのに、どのテンプレートをベースにするのがいいのか、ということを調べるのに時間を食ったので、そのメモ。

新しいプロジェクトをWindows Metro styleで作成するときは、Blank App、Grid App、Split Appのテンプレートから選ぶわけだが、アプリの内容的にGrid AppでもSplit AppでもないとなるとBlank Appになる。ただ、Blank AppにはMetroアプリとして必須のレイアウト切り替え機能なども入ってないので、あまりベースとして使えない。

そこで、プロジェクト作成後に追加できる基本ページ（Basic Page）のテンプレートにはこれらの機能が入っているので、最初のページをこれに差し替える手順。に、プロジェクト作成時に入る、XAMLのテンプレートの大元たるStandardStyles.xamlには後々にBlendで開いたときにエラーを出す問題があるので、これをMSDNのサンプルのものに差し替えることを含めた手順が以下。

1. Visual Studioで、ファイル -> 新規作成 -> プロジェクト -> テンプレート -> Visual C# -> Windows Metro style -> Blank App (XAML) を選び、プロジェクトを作成したら一旦終了。
2. 作成されたプロジェクトフォルダーのCommonフォルダーを開き、StandardStyles.xamlを、MSDNのいずれかのサンプルにある同名ファイルで上書き。
3. Visual Studioでこのプロジェクトを開き、プロジェクト -> 新しい項目の追加 -> Visual C# -> Windows Metro style -> 基本ページ を選び、追加（名前はここではBasicPage1.xamlとする）。
4. App.xamlのコードの表示を開き（C#）、 if (!rootFrame.Navigate(typeof(MainPage))) 中の MainPage を BasicPage1 に修正し、ビルドして最初にBasicPage1が表示されることを確認。（ファイルの差し替えまでしない場合は、ここまで。）
5. ソリューションエクスプローラーで（元の）MainPage.xamlを削除。
6. BasicPage1.xamlのデザイナーの表示を開き（XAML）、 x:Class="[名前空間名].BasicPage1" 中の BasicPage1 を MainPage に修正。
7. 同じくBasicPage1.xamlのコードの表示を開き（C#）、 public sealed partial class BasicPage1 中の BasicPage1 を MainPage に修正し、 public BasicPage1() 中の BasicPage1 も MainPage に修正。
8. ソリューションエクスプローラーでBasicPage1.xamlの名前をMainPage.xamlに変更。

ただ、Visual Studio 2012もRTMで変わるだろうから、この手順もたぶん変わる。

3. よしなしごと

本格的にXAMLを使ったアプリは初めてで、最初は「何かややこしいことしてるな」という印象だったが、慣れてくるとこれはこれで合理的で面白い。スタイルやテンプレートのかけ方は、CSSを多重にかけたウェブページに似ている。

一方で、Metroアプリ作成のガイドラインなど改めて読んでいると、Metroはやはりタブレット向けのUIとの印象を強くした。その辺り、Microsoftの偉い人が話すことと、実際のMetroにはズレがある感じがする。

Metroでは比較的狭いタブレット画面でタッチ操作するために色々なガイドラインがあって、一言でいうと画面が窮屈になりがちだが、そこを（タッチ操作を駆使して）使いやすいUIにデザインすることが求められる。

また、Metroアプリの重要な方針として、「Content not Chrome」がある。つまり、従来のウィンドウの枠部分（Chrome）は表示せず（必要なときだけ出す）、ユーザーを内容（Content）に集中させよ、というものだが、これにはそもそもの前提として窮屈になりがちな画面の有効活用という要求があると思う。

これは見方を変えると、ユーザーに（OSの存在を意識させず）シングルタスクをさせろ、ということでもある。Metroではユーザーが同時に見られるアプリは基本的に1つで、Snappedで他のアプリも出しておけば一応2つになるが、まあシングルタスク＋のUIといえる。

で、従来どおりのPCでは当然にウィンドウを幾つも開いてマルチタスクで使えるわけで（大型化するディスプレイを使えばなおさら）、それをシングルタスク＋で使えと言われても無理がある。例えば、よく例に出る旅行サイトを使うアプリの場合、1つのアプリで見るより、色々な会社の旅行サイトを開いて見比べたり、Google Street Viewで現地の写真を見たり、交通の便を確かめたり、他の人の体験を読んだり、そういうことが同時にできた方が効率がいい。

いや、そんなことは当然で、リラックスしながらタブレットで見られることに価値がある、という言い方もできる。実際、従来はPCでやっていたがタブレットでも可能で、むしろそちらの方が便利という作業はあって、そこはタブレットが伸していくのだと思う。

ただ、そうすると対立軸はデスクトップかMetroかではなく、従来のPCかタブレットかになると思うので、それはつまり、従来のPCではデスクトップを使い、タブレットではMetroを使えばいい、という面白くも何ともない話に落ち着く。一周回って「元々そういう話だったのでは」という地点に戻るというか。

したがって、使う人、使う場面を考えて、タブレットがよければMetroアプリで行き、従来のPCがよければデスクトップアプリで行く、ということでいいのではないか、と改めて思う。