DPIを200%にしたときの見た目はこんな感じです。標準のカーソルに似せていますが、全てスクラッチで、個人的に気になった点は変えたりもしているので、微妙に違いがあります。
現状、DPIを200%以上にしている人は少ないかもしれませんが、おいおい需要が増えてくるものと予想して。
プロジェクトサイト: High DPI Cursor Changer 英語 / 日本語 at SourceForge.net
実行ファイル from SourceForge.net
2012/12/29
High DPI Cursor Changer
High DPI Windows 8 Cursor Setで作成したカーソルファイルの導入と設定を自動化するツールとして、High DPI Cursor Changerを作成しました。Windows 8でDPIを200%以上に上げたときにカーソルの輪郭が汚くなる問題に対応するものです。
DPIを200%にしたときの見た目はこんな感じです。標準のカーソルに似せていますが、全てスクラッチで、個人的に気になった点は変えたりもしているので、微妙に違いがあります。
現状、DPIを200%以上にしている人は少ないかもしれませんが、おいおい需要が増えてくるものと予想して。
プロジェクトサイト: High DPI Cursor Changer 英語 / 日本語 at SourceForge.net
実行ファイル from SourceForge.net
DPIを200%にしたときの見た目はこんな感じです。標準のカーソルに似せていますが、全てスクラッチで、個人的に気になった点は変えたりもしているので、微妙に違いがあります。
現状、DPIを200%以上にしている人は少ないかもしれませんが、おいおい需要が増えてくるものと予想して。
プロジェクトサイト: High DPI Cursor Changer 英語 / 日本語 at SourceForge.net
実行ファイル from SourceForge.net
2012/11/14
AppUserModelIDをC#から操作する
Windows 7以降で利用されるAppUserModelIDを含んだショートカットをC#から操作するコードを書いてみた。
Windows 8のWindowsストアアプリでは常駐型アプリは難しいので、常駐型の監視アプリを使おうとする場合、（x86版であれば）デスクトップアプリを動かしておいて何かあればWindowsストアアプリの画面にトースト通知を出すのが一つの解になると思うが、このトースト通知をデスクトップアプリから送るにはAppUserModelIDを含んだショートカットがスタートメニューにあることが条件になっている。
このAppUserModelIDは普通に張ったショートカットには含まれないもので、これを含むショートカットの作成はアプリのインストーラにやらせることをMicrosoftは推奨している。が、そうは言ってもインストーラの作ったショートカットをユーザーが消してしまう可能性もあるので確実性に欠けるし、常にインストーラを必要とするのはあまり便利ではない。
一方で、AppUserModelIDを含んだショートカットを読み書きする方法は.NET Frameworkでは提供されておらず、ショートカットでよく使われるWSHのWshShortcutオブジェクトでもAppUserModelIDは対象に入っていない。一応C++での方法は示されているので、であればと、これに沿ってC#からWin32とCOMを使って操作するコード（ラッパークラス）を書いた次第。
C#あるいはVBからCOMのIShellLinkインターフェイスを使ってショートカットを読み書きする例は既に幾つかあって、これをベースにさせていただいた。
ただ、プロパティの値を格納するPROPVARIANT構造体が複雑で、これに難儀していたところ、そもそものデスクトップアプリからトースト通知を送るサンプルに（正確には、その利用するWindows API Code Packに）答えがあった。
IPropertyStoreに必要なコードを整理すると、まずIPropertyStore自体は以下のとおり。
アプリの見た目は以下のようなもので、ショートカット先のターゲットファイルのパス、実行時のオプション、AppUserModelIDの読み書きが可能。
実際に使うには作り込みの必要があると思うが、叩き台としてはこんなものかと。
1. 背景
Windows 8のWindowsストアアプリでは常駐型アプリは難しいので、常駐型の監視アプリを使おうとする場合、（x86版であれば）デスクトップアプリを動かしておいて何かあればWindowsストアアプリの画面にトースト通知を出すのが一つの解になると思うが、このトースト通知をデスクトップアプリから送るにはAppUserModelIDを含んだショートカットがスタートメニューにあることが条件になっている。
このAppUserModelIDは普通に張ったショートカットには含まれないもので、これを含むショートカットの作成はアプリのインストーラにやらせることをMicrosoftは推奨している。が、そうは言ってもインストーラの作ったショートカットをユーザーが消してしまう可能性もあるので確実性に欠けるし、常にインストーラを必要とするのはあまり便利ではない。
一方で、AppUserModelIDを含んだショートカットを読み書きする方法は.NET Frameworkでは提供されておらず、ショートカットでよく使われるWSHのWshShortcutオブジェクトでもAppUserModelIDは対象に入っていない。一応C++での方法は示されているので、であればと、これに沿ってC#からWin32とCOMを使って操作するコード（ラッパークラス）を書いた次第。
2. コーディング
C#あるいはVBからCOMのIShellLinkインターフェイスを使ってショートカットを読み書きする例は既に幾つかあって、これをベースにさせていただいた。
- smdn: ショートカットファイル(.lnkファイル)を作成する
- vbAccelerator: Creating and Modifying Shortcuts
- .netPlus: ShellLink
- MSDN: How to enable desktop toast notifications through an AppUserModelID (Windows)
- アプローズの日記: System.ApplicationUserModel.ID
- win7appid
ただ、プロパティの値を格納するPROPVARIANT構造体が複雑で、これに難儀していたところ、そもそものデスクトップアプリからトースト通知を送るサンプルに（正確には、その利用するWindows API Code Packに）答えがあった。
- MSDN: Sending toast notifications from desktop apps sample
- MSDN: Windows API Code Pack for Microsoft .NET Framework
IPropertyStoreに必要なコードを整理すると、まずIPropertyStore自体は以下のとおり。
// IPropertyStore Interface
[ComImport,
InterfaceType(ComInterfaceType.InterfaceIsIUnknown),
Guid("886D8EEB-8CF2-4446-8D02-CDBA1DBDCF99")]
private interface IPropertyStore
{
uint GetCount([Out] out uint cProps);
uint GetAt([In] uint iProp, out PropertyKey pkey);
uint GetValue([In] ref PropertyKey key, [Out] PropVariant pv);
uint SetValue([In] ref PropertyKey key, [In] PropVariant pv);
uint Commit();
}
この中でプロパティのキーを格納するPropertyKey構造体。// PropertyKey Structure
// Narrowed down from PropertyKey.cs of Windows API Code Pack 1.1
[StructLayout(LayoutKind.Sequential, Pack = 4)]
private struct PropertyKey
{
#region Fields
private Guid formatId; // Unique GUID for property
private Int32 propertyId; // Property identifier (PID)
#endregion
#region Public Properties
public Guid FormatId
{
get
{
return formatId;
}
}
public Int32 PropertyId
{
get
{
return propertyId;
}
}
#endregion
#region Constructor
public PropertyKey(Guid formatId, Int32 propertyId)
{
this.formatId = formatId;
this.propertyId = propertyId;
}
public PropertyKey(string formatId, Int32 propertyId)
{
this.formatId = new Guid(formatId);
this.propertyId = propertyId;
}
#endregion
}
で、プロパティの値を格納するPropVariantクラス（とそれに必要な関数）。// PropVariant Class (only for string value)
// Narrowed down from PropVariant.cs of Windows API Code Pack 1.1
// Originally from http://blogs.msdn.com/b/adamroot/archive/2008/04/11
// /interop-with-propvariants-in-net.aspx
[StructLayout(LayoutKind.Explicit)]
private sealed class PropVariant : IDisposable
{
#region Fields
[FieldOffset(0)]
ushort valueType; // Value type
// [FieldOffset(2)]
// ushort wReserved1; // Reserved field
// [FieldOffset(4)]
// ushort wReserved2; // Reserved field
// [FieldOffset(6)]
// ushort wReserved3; // Reserved field
[FieldOffset(8)]
IntPtr ptr; // Value
#endregion
#region Public Properties
// Value type (System.Runtime.InteropServices.VarEnum)
public VarEnum VarType
{
get { return (VarEnum)valueType; }
set { valueType = (ushort)value; }
}
// Whether value is empty or null
public bool IsNullOrEmpty
{
get
{
return (valueType == (ushort)VarEnum.VT_EMPTY ||
valueType == (ushort)VarEnum.VT_NULL);
}
}
// Value (only for string value)
public string Value
{
get
{
return Marshal.PtrToStringUni(ptr);
}
}
#endregion
#region Constructor
public PropVariant()
{ }
// Construct with string value
public PropVariant(string value)
{
if (value == null)
throw new ArgumentException("Failed to set value.");
valueType = (ushort)VarEnum.VT_LPWSTR;
ptr = Marshal.StringToCoTaskMemUni(value);
}
#endregion
#region Destructor
~PropVariant()
{
Dispose();
}
public void Dispose()
{
PropVariantClear(this);
GC.SuppressFinalize(this);
}
#endregion
}
[DllImport("Ole32.dll", PreserveSig = false)]
private extern static void PropVariantClear([In, Out] PropVariant pvar);
また、AppUserModelIDのキーはFormatIDとPropIDからPropertyKeyを使って以下のように定義できる。// Name = System.AppUserModel.ID
// ShellPKey = PKEY_AppUserModel_ID
// FormatID = 9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3
// PropID = 5
// Type = String (VT_LPWSTR)
private readonly PropertyKey AppUserModelIDKey =
new PropertyKey("{9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}", 5);
これらを使ってAppUserModelIDをShellLinkクラスのプロパティとして加えた。なお、VerifySucceededは戻り値を見て失敗なら例外を出すメソッド。ショートカットにAppUserModelIDのプロパティが存在しない場合、Valueはnullとなる。// AppUserModelID to be used for Windows 7 or later.
public string AppUserModelID
{
get
{
using (PropVariant pv = new PropVariant())
{
VerifySucceeded(PropertyStore.GetValue(AppUserModelIDKey, pv));
if (pv.Value == null)
return "Null";
else
return pv.Value;
}
}
set
{
using (PropVariant pv = new PropVariant(value))
{
VerifySucceeded(PropertyStore.SetValue(AppUserModelIDKey, pv));
VerifySucceeded(PropertyStore.Commit());
}
}
}
このShellLinkクラスを使うアプリも合わせた全体のコードはこちらに載せた。なお、IShellLink自体の機能は本題ではないので、最低限必要なものに絞ってある。アプリの見た目は以下のようなもので、ショートカット先のターゲットファイルのパス、実行時のオプション、AppUserModelIDの読み書きが可能。
実際に使うには作り込みの必要があると思うが、叩き台としてはこんなものかと。
2012/10/31
CrystalDiskMarkとTrim
SSDの速度を測る場合、その前の使い方（とくにライト）が影響するのはよく知られていて、Secure EraseやTrimでクリーンな状態にした後、ライトを繰り返して乱れた状態が一定以上に達すると速度低下が起こったりする。
そうした影響をなるべく防ぐための工夫は色々あり得るが、理由あって同じSSDを連続して計測する場合、その間にTrimをかけるのはどうかというアイデアを持っていた。で、最近はTrimもすっかり一般化したことだし、CrystalDiskMarkを使って試してみた（結果的には不発）。
CrystalDiskMarkを連続して実行し、その実行間にTrimをかける場合とかけない場合で差が出るかを見る。
環境
また、こういう計測をきっちり進めていくのは結構面倒なものだが、そこはDiskMarkStreamで楽々（自画自賛）、というよりDiskMarkStreamがあったからやる気になったというべきか。
先にどれぐらいのライト量になったかを確認すると、まずTrimをかけなかった場合の実行前と実行後のCrystalDiskInfoの結果。
次にTrimをかけた場合の実行前と実行後。
一番最初のHost Writesの生の値は76752で、この16進数を10進数に換算すると485202になる。この値は65536セクタ、すなわち65536×512÷1024^2＝32（MiB）ごとに1増えていくので、容量としては以下のようになる。
485202×32＝15526464（MiB）≒14.807（TiB）
同様にそれぞれの値を計算し、実行前と実行後の差から増加量を求めると、
これらの増加量はそれぞれ9×30＝270回分のテストによるものなので、1回のテストの増加量は約3.54～3.56GiBとなるが、これはテストサイズが2GBということを考えるとこんなものかと思う。どちらも全増加量は1TiB近くに上っている。
ここで、X25-M G2で速度低下を起こした後にTrimで回復した例（SSDの性能低下とTrimの効き具合を大検証）を見ると、一旦容量の90%までライトで埋めている。
方法は違うが、この全増加量は全容量80GBの12倍に当たるので、変化を起こさせるに十分なライト量ではないかと思う。というか思った、が……。
結論から言うと、CrystalDiskMarkの結果は不発だった。
まずTrimをかけなかった場合、30回の実行中、ばらつきは多少あるが、有意な変化といえるものはなかった。以下は1回目、15回目、30回目のもの。
一応、次にTrimをかけた場合、同様に以下。
こちらも有意な変化はない（Trimが効果を発揮していれば変化はなくて問題ないわけだが）。
1TiB近くのライトをもってして速度低下を起こせなかったのは誤算だったが、CrystalDiskMarkを連続実行しても再度Trimが必要になるような速度低下は起こらないことが確認できたので（X25-M限定でだが）、それはそれでよしとする。
しかし……、この結果を見るに、実使用でもTrimを頻繁にかける必要はない気がしてきた。1TiBなんて普通に使う限り数箇月たっても到達しない量だと思うし。
そうした影響をなるべく防ぐための工夫は色々あり得るが、理由あって同じSSDを連続して計測する場合、その間にTrimをかけるのはどうかというアイデアを持っていた。で、最近はTrimもすっかり一般化したことだし、CrystalDiskMarkを使って試してみた（結果的には不発）。
1. 計測方法
CrystalDiskMarkを連続して実行し、その実行間にTrimをかける場合とかけない場合で差が出るかを見る。
環境
- PC: ThinkPad X61s
- SSD: Intel X25-M G2 80GB（OSなどで全容量の60%が埋まった状態）
- OS: Windows 8 Pro 64bit（ドライバーはすべてOSの自動インストール）
- CrystalDiskMark（3.0.2）を4GBで空のNTFSのパーティションに対し、テスト種類All、テスト回数9、テストサイズ2000MBの設定で30回実行。
- 実行間には1分の間隔を挟み、Trimをかける場合は前回の実行直後にこのパーティションを対象に実行（先に示した方法で）。
- どちらの場合も最初の実行前にTrimをかける。
- ライト量の確認のため、一連の実行の直前と直後にCrystalDiskInfo（5.1.0 RC2）でHost Writes（総書き込み量）を取得する。Host Writesはあくまでホスト側（PC本体側）から見たライト量なので、SSD内部のライト量には直結しないが、参考にはなる。なお、この間は他のライトを伴う作業はしない（OSが勝手に行うものは除く）。
また、こういう計測をきっちり進めていくのは結構面倒なものだが、そこはDiskMarkStreamで楽々（自画自賛）、というよりDiskMarkStreamがあったからやる気になったというべきか。
2. 計測結果
先にどれぐらいのライト量になったかを確認すると、まずTrimをかけなかった場合の実行前と実行後のCrystalDiskInfoの結果。
次にTrimをかけた場合の実行前と実行後。
（注）E9が96から95に落ちているが、96になったのはかなり以前のことなので、意味はない。
一番最初のHost Writesの生の値は76752で、この16進数を10進数に換算すると485202になる。この値は65536セクタ、すなわち65536×512÷1024^2＝32（MiB）ごとに1増えていくので、容量としては以下のようになる。
485202×32＝15526464（MiB）≒14.807（TiB）
同様にそれぞれの値を計算し、実行前と実行後の差から増加量を求めると、
生の値 | 換算後 | 増加量 | ||||
|---|---|---|---|---|---|---|
16進数 | 10進数 | (MiB) | (TiB) | (MiB) | (GiB) | |
| Trimをかけなかった場合 | ||||||
| 実行前 | 76752 | 485202 | 15526464 | 14.807 | 984320 | 961.25 |
| 実行後 | 7DF7A | 515962 | 16510784 | 15.746 | ||
| Trimをかけた場合 | ||||||
| 実行前 | 7E15F | 516447 | 16526304 | 15.761 | 978496 | 955.56 |
| 実行後 | 858D1 | 547025 | 17504800 | 16.694 | ||
これらの増加量はそれぞれ9×30＝270回分のテストによるものなので、1回のテストの増加量は約3.54～3.56GiBとなるが、これはテストサイズが2GBということを考えるとこんなものかと思う。どちらも全増加量は1TiB近くに上っている。
ここで、X25-M G2で速度低下を起こした後にTrimで回復した例（SSDの性能低下とTrimの効き具合を大検証）を見ると、一旦容量の90%までライトで埋めている。
方法は違うが、この全増加量は全容量80GBの12倍に当たるので、変化を起こさせるに十分なライト量ではないかと思う。というか思った、が……。
結論から言うと、CrystalDiskMarkの結果は不発だった。
まずTrimをかけなかった場合、30回の実行中、ばらつきは多少あるが、有意な変化といえるものはなかった。以下は1回目、15回目、30回目のもの。
一応、次にTrimをかけた場合、同様に以下。
こちらも有意な変化はない（Trimが効果を発揮していれば変化はなくて問題ないわけだが）。
3. まとめ
1TiB近くのライトをもってして速度低下を起こせなかったのは誤算だったが、CrystalDiskMarkを連続実行しても再度Trimが必要になるような速度低下は起こらないことが確認できたので（X25-M限定でだが）、それはそれでよしとする。
しかし……、この結果を見るに、実使用でもTrimを頻繁にかける必要はない気がしてきた。1TiBなんて普通に使う限り数箇月たっても到達しない量だと思うし。
2012/10/27
CrystalDiskMarkと雫ちゃんと
Windows 8発売の26日（というか25日深夜）にCrystalDiskMarkにも3.0.2で
Shizuku Editionが登場したので、早速、当然にDiskMarkStreamで対応。
通常版との違い、サイズなどは自動で判別する。
しかし、この麗しい姿といい、青白基調の流麗なデザインといい、これを目にすると、殺伐としたベンチマークの世界（ついあれもこれもとデータを取ろうとして、環境を整えて計測しているうちに消耗戦になってきて、あまり美しい状況にはなり難い）に涼風が吹き込まれる、というより、まとめて毒気を飛ばされてしまう危険性がある……。
その意味では機械的なマクロツールであるDiskMarkStreamはそぐわない気もするが、多少矛盾をはらんでいた方が面白い、ということにしておこう。
なお、通常版のテーマのShizukuでもエッセンスは共通。
ちなみに、Windows 8ではSSDのドライブに対してコマンドプロンプトから簡単にTrimを発行できるので（Defragの/Lオプション）、DiskMarkStreamのバッチ実行機能を使えばテスト間にTrimをすることができる。
このためのバッチファイルの内容は以下のようなもの。対象のドライブはDで、結果は後から確認するためにresult.txtというファイルに出力している。
ただし、Windows 8が64bit版の場合、このパスではDefrag.exeがDiskMarkStreamから見えない問題がある。これは32bitのソフト（DiskMarkStreamは32bit）を64bitのWindows上で実行するときに起こり得る問題で、この場合は以下のようになる。
どちらの場合もDefragは管理者として実行する必要があるので、DiskMarkStreamも起動時に管理者として実行する必要がある（DiskMarkStream自体は管理者として実行される必要はないが、バッチ実行を管理者として行うトリガーとし、かつバッチ実行の度にUACの承認を求められるのを避けるため）。
[追記]
Windows 8におけるTrimについて、Microsoftの担当者（Kiran Bangalore）が答えていた（Defragging SSDs a default?）。Windows 8では（Windows 7と同様に）ファイルの削除、移動の際にTrimを発行しているが、SSDの方がリアルタイムに処理できない場合を考えて、「ディスクの最適化」で定期的にTrimを発行するようになっている（これがデフォルト）とのこと。
Shizuku Editionが登場したので、早速、当然にDiskMarkStreamで対応。
通常版との違い、サイズなどは自動で判別する。
しかし、この麗しい姿といい、青白基調の流麗なデザインといい、これを目にすると、殺伐としたベンチマークの世界（ついあれもこれもとデータを取ろうとして、環境を整えて計測しているうちに消耗戦になってきて、あまり美しい状況にはなり難い）に涼風が吹き込まれる、というより、まとめて毒気を飛ばされてしまう危険性がある……。
その意味では機械的なマクロツールであるDiskMarkStreamはそぐわない気もするが、多少矛盾をはらんでいた方が面白い、ということにしておこう。
なお、通常版のテーマのShizukuでもエッセンスは共通。
ちなみに、Windows 8ではSSDのドライブに対してコマンドプロンプトから簡単にTrimを発行できるので（Defragの/Lオプション）、DiskMarkStreamのバッチ実行機能を使えばテスト間にTrimをすることができる。
このためのバッチファイルの内容は以下のようなもの。対象のドライブはDで、結果は後から確認するためにresult.txtというファイルに出力している。
C:\Windows\System32\Defrag.exe D: /L >> C:\Work\result.txt
ただし、Windows 8が64bit版の場合、このパスではDefrag.exeがDiskMarkStreamから見えない問題がある。これは32bitのソフト（DiskMarkStreamは32bit）を64bitのWindows上で実行するときに起こり得る問題で、この場合は以下のようになる。
C:\Windows\Sysnative\Defrag.exe D: /L >> C:\Work\result.txt
どちらの場合もDefragは管理者として実行する必要があるので、DiskMarkStreamも起動時に管理者として実行する必要がある（DiskMarkStream自体は管理者として実行される必要はないが、バッチ実行を管理者として行うトリガーとし、かつバッチ実行の度にUACの承認を求められるのを避けるため）。
[追記]
Windows 8におけるTrimについて、Microsoftの担当者（Kiran Bangalore）が答えていた（Defragging SSDs a default?）。Windows 8では（Windows 7と同様に）ファイルの削除、移動の際にTrimを発行しているが、SSDの方がリアルタイムに処理できない場合を考えて、「ディスクの最適化」で定期的にTrimを発行するようになっている（これがデフォルト）とのこと。
2012/08/31
Windows To Goのまとめ
Windows To Goの最終的な姿がWindows 8 RTMとともに明らかになったので、まとめておこうと思う。
使用条件は以下のとおり。狭き門となっている。
ソフトウェアアシュアランス（SA）プログラムに入った、ボリュームライセンスのユーザー向けのEnterprise版のみ。つまり企業ユーザーの下でその社員が使う場合のみで、個人ユーザーには提供されない。
PC本体側の条件はWindows 7かWindows 8の動作条件を満たしていればいいので問題にはならないが、USBメモリというか、USBドライブ側の条件は厳しい。
8月15日現在、MicrosoftがWindows To Goが使えると認定した（certified）USBドライブは、以下の2機種のみ。
いずれも一般的な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からデザインが変更されているが、丸く寸胴な基本形状は変わっていない。
[追記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機種のうち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メモリがごく限られていることで、世代が進むにつれてランダムライトの激しく遅い製品が主流になってきているらしい。
で、メーカーはUSB3.0のシーケンシャルアクセスの速度を前面に出し、ランダムライトにはあえて触れないようにしているようなので、何も考えずにUSBメモリを買ってきたらランダムライトの激しく遅い製品だった、ということが普通に起こると思われるので、（認識の問題とは別に）注意が必要。
Windows 8 RTM評価版はEnterprise版で、Windows To Goの作成ツールがコントロールパネルにあるので、RPまでのような手順を踏まずとも簡単にWindows To GoのUSBドライブが作成できる。
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の容量で問題はなかった。
割と便利に使えそうな機能なので、昨年来追いかけてきたが、条件的に個人ユーザーには縁遠いものになってしまったのは勿体ないと思う。が、元からライセンス的には扱いが難しそうだったので、そこは何とも言えない。
まあ自分のExpress RC8はOS起動用として十分な性能があることが分かったので、RTM評価版の期限が終わったら他のOSで使ってみようかと思う。
1. 条件
使用条件は以下のとおり。狭き門となっている。
1.1. 対象ユーザー
ソフトウェアアシュアランス（SA）プログラムに入った、ボリュームライセンスのユーザー向けのEnterprise版のみ。つまり企業ユーザーの下でその社員が使う場合のみで、個人ユーザーには提供されない。
[参考]
TechNet: Windows To Go Frequently Asked Questions
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
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
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メモリがごく限られていることで、世代が進むにつれてランダムライトの激しく遅い製品が主流になってきているらしい。
で、メーカーは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)
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で使ってみようかと思う。
2012/08/26
High DPI Windows 8 Cursor Set
Windows 8のDPIを200%に設定した場合の問題は、結局RTMでも修正されてなかった。それはさて置き、そもそもこの問題はプログラムに問題があるというより、アイコンあるいはカーソルの画像リソースが足らないだけということに気づいた。
以下はRTM評価版のエクスプローラを見たところだが、ウィンドウのデザインは変わったが、カーソルと上向き矢印の問題は変わってない。
リンクなど他の状態のカーソルも同様。
この問題は実際にMacBook Pro RetinaにWindows 8 RTMをインストールし、DPIを200%にしたときにも確認されている。
で、Windows 8でアイコンの表示を確かめていたときに、この輪郭が汚くなった状態は、アイコンファイルに現在のDPIで表示されるべきサイズの画像が含まれておらず、それより小さなサイズの画像が引き伸ばされて表示されたときの状態と同じことに気づいた。
いや、引き伸ばされたからといって直ちに形状が崩れる必然性はないが、引き伸ばす際に縦横比が微妙に狂ったりして、一言でいえばOSによる画像の拡大が下手なのだと思う（縮小する方は上手なのだが）。
ともかく、そういうことなら本来表示されるべきサイズ（200%なら64x64）の画像をファイルに含めてやればいいわけで、そういうカーソルファイルを作成してみた（エクスプローラの上向き矢印の方は、システムファイルに埋め込まれたリソースを使っているようで、これをいじるのは面倒なので諦めた）。
以下は作成したカーソルに変えた場合の表示。
輪郭がこのDPIにしては少し細いような気もするが、とりあえずこんなところ。
[追記1] Animated Cursor Packer
3つ以上のサイズを持つアニメーションカーソルファイルを作成できる既存のアプリがなかったので、作成したもの。サイズ別に分かれていたものを統合できれば、DPIによってファイル指定を変える必要もなくなるので。
アニメーションカーソルはRIFFファイル形式の一種だが、複数のサイズを持たせる方法が見つからなかったのでOS標準のものを覘いたところ、ファイル構造は単一のサイズだけのアニメーションカーソルと変わらず、中に含まれる個々のカーソルデータが複数のサイズの画像を持っているかどうかの違いだけのようだった。
それならと、カーソルデータの作成は他のアプリに任せ、カーソルデータ（実際はアニメーションなしのカーソルファイルそのまま）をまとめてアニメーションカーソルファイルにする部分だけを作ったのがこのアプリ。元のカーソルファイルの中身は関知しないので、単一のサイズだけのカーソルファイルを元にすれば単一のサイズのアニメーションカーソルファイルが出来、複数のサイズのカーソルファイルを元にすれば同じ複数のサイズのアニメーションカーソルが出来るという具合い。
アニメーションカーソルを作成できる既存のアプリは、カーソルデータの作成とアニメーションカーソルファイルにまとめることの両方をやるわけだが、これを分離することで、複数のサイズのカーソルファイルを用意すれば同じ複数のサイズのアニメーションカーソルファイルが作成できるようになり、サイズの数に制限がなくなるというのがポイント。
……と書きつつ、Microsoftの資料にないことなので確証はないが（アニメーションカーソルに関する情報はWin95の頃で止まっていて、その後複数のサイズを持つアニメーションカーソルが出てきてもアップデートされておらず、複数のサイズを持たせるための情報がない状態）、とりあえずうまく行っているようだからよしとする。
[追記2]
High DPI Cursor Changerの方に統合した。
以下はRTM評価版のエクスプローラを見たところだが、ウィンドウのデザインは変わったが、カーソルと上向き矢印の問題は変わってない。
リンクなど他の状態のカーソルも同様。
この問題は実際にMacBook Pro RetinaにWindows 8 RTMをインストールし、DPIを200%にしたときにも確認されている。
[参考] 例
TechRepublic: Combining Windows 8 and a Retina MacBook
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なので)
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の方に統合した。
2012/06/17
Windows 8はRetinaレディか
MacBook ProにRetinaモデルが出たことで、PCでもRetina（に相当する高解像度）が現実のものとなってきたが、Windows 8はそれにレディなのかをチェック。
MacBook Proが発表された日に早速BootCampでWindows 8 RP（Release Preview）をインストールした記事（Retina MacBook ProにWindows 8インストール成功、しかも簡単だった）が出ていたが、その早業には敬意を表する一方、「細かすぎてウインドーの内容は全然見えない。ごみ箱が極小サイズ（笑）。」の文には「バカっぽい」と思った。WindowsでもMicrosoft、あるいは開発者は高解像度への準備を進めてきているわけで、それを試してもらわないと。
というわけで、Windows 8を高DPI、Appleのやり方にならって200%に設定するとどうなるかを見てみた。解像度は1680×1050なので、やや窮屈だが。
大体は問題ないが、おかしい箇所もある。
標準のカーソルと、新しいエクスプローラの、上の階層に移る矢印がおかしい。縦横比が微妙に狂って輪郭が崩れた感じがする。
その他、ざっとOSと標準アプリを見て回ったが、とくにおかしい箇所は見当たらなかったので、あと少し作り込みをがんばってくれという感じ。
それはそれとして、100%のときとは各パーツの余白や位置関係が違っていたり（少々詰まり気味）、輪郭線が相対的に細くなったりして、気にならないでもなかったが、そこは慣れの問題か……。
[追記1]
Microsoft Answersに報告したところ、フィードバックとして受けてもらった（Win8RPで高DPIに設定するとマウスカーソルの輪郭とエクスプローラにある矢印の輪郭が汚くなる）。
[追記2]
結局RTMでも修正されてなかったので、代わりになるカーソルを作成してみた。
実のところ、問題はサードパーティのアプリやハードウェア関係のユーティリティにある気がする。例えばGoogle Chrome（19.0.1084.56）をインストールしたままの状態。
ぼやけている。というより、DPI仮想化が効いている。これは一旦100%（96DPI）で描画した後で引き延ばして表示する機能で、高解像度に対応していないアプリでも最低限表示できるようにするものだが、自動的にかかったりかからなかったりするので（標準アプリも含めて）、法則性がよく分からない。
この状態だと高解像度の意味がないので、明示的にDPI仮想化を無効にするにはその実行ファイルのプロパティで「高DPI設定では画面のスケーリングを無効にする」にチェックする。
で、無効にすると、今度はこうなる。
このタブ部分を見ると、テキストは大きくなっているが、タブとツールバーのサイズは元のままでDPIに従って拡大されていない。
まあGoogleのことだから、必要と認めればすぐ修正してくるだろうが。それから、これはサイト側の問題だが、Faviconはどうするのだろう。現在はjpgかpngを使っているサイトが多いと思うが、色々な解像度に対応するにはサイズ別の画像を持てるicoの方が便利ではある。
また、ハードウェア関係としては、ThinkPadではTrackPointのドライバが自動的にインストールされ、マウスのプロパティにそのタブが現れる。
テキストが切れている。これはラスターフォントで指定されていたものが、拡大されたときにベクターフォントに置き換えられたせいで指定されたスペースに収まらなくなるという、古いソフトにありがちな問題。修正は難しくないはずだが、今更修正してくれるのか……。
かようにアプリによるところが大きいが、ユーザーは意識してなくてもアプリにも種類があって（ネイティブ、Windowsフォーム、WPFなどなど、実は複雑）、それによって表示方法も違っていて、最終的には開発者の作り込み度による。
というわけで、実際に試すしかないわけだが……例えばCrystalDiskInfo（5.0.0）はこうなる。
フォントも配置もきれいに整っていて、何もいうことはない。
一応、自分のNAS Herderはどうかというと、こんな感じ。
何ということはなくて、.NETのWindowsフォームアプリなので基本的に実行環境にお任せなのだが、動的に生成しているパーツのサイズや位置はがりがり計算していたりする。アイコンはまだ手抜きなので、小さい画像が拡大されて表示されているが。
ちなみに、Apple StoreでMacBook ProのRetinaモデルを見てきたが、標準アプリの精細さにはすごいものがあったが、Retinaに対応していない（と思う）Microsoft Officeはメニューのフォントがぼわっと引き延ばされてかえって汚くなっていて、あの縦横2倍引き延ばし作戦も万能ではないと思った。
1. Windows 8 RP
MacBook Proが発表された日に早速BootCampでWindows 8 RP（Release Preview）をインストールした記事（Retina MacBook ProにWindows 8インストール成功、しかも簡単だった）が出ていたが、その早業には敬意を表する一方、「細かすぎてウインドーの内容は全然見えない。ごみ箱が極小サイズ（笑）。」の文には「バカっぽい」と思った。WindowsでもMicrosoft、あるいは開発者は高解像度への準備を進めてきているわけで、それを試してもらわないと。
というわけで、Windows 8を高DPI、Appleのやり方にならって200%に設定するとどうなるかを見てみた。解像度は1680×1050なので、やや窮屈だが。
大体は問題ないが、おかしい箇所もある。
標準のカーソルと、新しいエクスプローラの、上の階層に移る矢印がおかしい。縦横比が微妙に狂って輪郭が崩れた感じがする。
その他、ざっとOSと標準アプリを見て回ったが、とくにおかしい箇所は見当たらなかったので、あと少し作り込みをがんばってくれという感じ。
それはそれとして、100%のときとは各パーツの余白や位置関係が違っていたり（少々詰まり気味）、輪郭線が相対的に細くなったりして、気にならないでもなかったが、そこは慣れの問題か……。
[追記1]
Microsoft Answersに報告したところ、フィードバックとして受けてもらった（Win8RPで高DPIに設定するとマウスカーソルの輪郭とエクスプローラにある矢印の輪郭が汚くなる）。
[追記2]
結局RTMでも修正されてなかったので、代わりになるカーソルを作成してみた。
2. アプリ
実のところ、問題はサードパーティのアプリやハードウェア関係のユーティリティにある気がする。例えばGoogle Chrome（19.0.1084.56）をインストールしたままの状態。
ぼやけている。というより、DPI仮想化が効いている。これは一旦100%（96DPI）で描画した後で引き延ばして表示する機能で、高解像度に対応していないアプリでも最低限表示できるようにするものだが、自動的にかかったりかからなかったりするので（標準アプリも含めて）、法則性がよく分からない。
[参考]
MSDN: 高DPI対応の Win32アプリケーションを記述する
MSDN: 高DPI対応の Win32アプリケーションを記述する
この状態だと高解像度の意味がないので、明示的にDPI仮想化を無効にするにはその実行ファイルのプロパティで「高DPI設定では画面のスケーリングを無効にする」にチェックする。
で、無効にすると、今度はこうなる。
このタブ部分を見ると、テキストは大きくなっているが、タブとツールバーのサイズは元のままでDPIに従って拡大されていない。
まあGoogleのことだから、必要と認めればすぐ修正してくるだろうが。それから、これはサイト側の問題だが、Faviconはどうするのだろう。現在はjpgかpngを使っているサイトが多いと思うが、色々な解像度に対応するにはサイズ別の画像を持てるicoの方が便利ではある。
また、ハードウェア関係としては、ThinkPadではTrackPointのドライバが自動的にインストールされ、マウスのプロパティにそのタブが現れる。
テキストが切れている。これはラスターフォントで指定されていたものが、拡大されたときにベクターフォントに置き換えられたせいで指定されたスペースに収まらなくなるという、古いソフトにありがちな問題。修正は難しくないはずだが、今更修正してくれるのか……。
かようにアプリによるところが大きいが、ユーザーは意識してなくてもアプリにも種類があって（ネイティブ、Windowsフォーム、WPFなどなど、実は複雑）、それによって表示方法も違っていて、最終的には開発者の作り込み度による。
というわけで、実際に試すしかないわけだが……例えばCrystalDiskInfo（5.0.0）はこうなる。
フォントも配置もきれいに整っていて、何もいうことはない。
一応、自分のNAS Herderはどうかというと、こんな感じ。
何ということはなくて、.NETのWindowsフォームアプリなので基本的に実行環境にお任せなのだが、動的に生成しているパーツのサイズや位置はがりがり計算していたりする。アイコンはまだ手抜きなので、小さい画像が拡大されて表示されているが。
ちなみに、Apple StoreでMacBook ProのRetinaモデルを見てきたが、標準アプリの精細さにはすごいものがあったが、Retinaに対応していない（と思う）Microsoft Officeはメニューのフォントがぼわっと引き延ばされてかえって汚くなっていて、あの縦横2倍引き延ばし作戦も万能ではないと思った。
3. まとめ
- Windows 8そのものは、少々の点を除けば高DPIへの対応を完了している。
- 問題はアプリだが、それは個々のアプリ次第（当たり前）。あえて言えば、ウェブアプリを含めてブラウザの中には関係ないし、古くてメンテナンスされてないソフトを使い続けているという事情でもなければ大きな問題にはならないのではないかと思う。
2012/06/06
Windows 8 RPにおけるフォローアップ
Windows 8 Release Preview（RP）が出たので、Consumer Preview（CP）から気になっていた点についてフォローアップ。
CPのときから状況は変わらず。USBメモリのGH-UFD3-32GFではWindows Updateができない。
USBケースに入れたMSD6000のようにローカルディスクとして認識されるか、リムーバブルディスクとして認識されるかの違いなのかもしれない。これはもうこのままなんだろうな、という気がしてきた。
いずれにしてもWindows To Go自体は非常に便利な機能なのだが、発表のあったエディションでは言及されてないので（Announcing the Windows 8 Editions）、どのエディション、ライセンスなら使えるのかという点が未だはっきりしない。法人向けライセンスのみという可能性もあるが、そうなるとBYODの場合に面倒になったりしないか、という気がする。
5日間使ったところでは、CPまでのようなCHKDSK問題には遭遇していない。同じパーティションにWin7とWin8の双方からCHKDSKをかけてみてもとくに問題になってなかったので、とりあえず忘れてよさそうである。
この問題自体はWin8でNTFSの管理が変更されたこと（chkdskの刷新と新しいNTFS正常性モデルの追加）に関係していそうではあったが。
[追記]
その後、Win7をリカバリーした際にWin8のパーティションをCHKDSKの対象から外し忘れていたら、何かの拍子にWin7のCHKDSKの自動実行がかかってWin8のパーティションが壊れた。このこと自体は仕方ないとして、やはりWin7のCHKDSKからWin8のパーティションは外しておいた方がいいとは思う。
この先、タブレットが伸していくことは確実で、色々なデバイスの関係をリシャッフルしていくのだと思う。となると、当然にPCとタブレットをどう融合させるのか、あるいは使い分けるのかが課題になってくる。
もちろんWin8はタブレット市場にMicrosoftが切り込んでいくための武器なわけだが、頑なにスタートメニューを排除しようとするのには、おそらく不利を覚悟の上での（たぶんスティーブン・シノフスキーの）信念のようなものを感じる。
といっても、それをユーザーが受け入れるかは別問題で、既に慣れてしまったPCの使い方をわざわざ勉強し直したい人は少ないと思うので、純粋なデスクトップ機で成功するかは懐疑的。自分はこういうチャレンジは好きだが、それでもこれがPCとタブレットの融合に対する答えかとなると、一歩引いて考えて、まだ足りてない感は否めない……が、後はハードウェアを含めたパッケージ次第かなと。
とにかくMicrosoftが当面の答えを見せたところで、Appleは同じ課題にどういう答えを持ってくるのか、そこに興味がある。
1. Windows To Go
CPのときから状況は変わらず。USBメモリのGH-UFD3-32GFではWindows Updateができない。
USBケースに入れたMSD6000のようにローカルディスクとして認識されるか、リムーバブルディスクとして認識されるかの違いなのかもしれない。これはもうこのままなんだろうな、という気がしてきた。
いずれにしてもWindows To Go自体は非常に便利な機能なのだが、発表のあったエディションでは言及されてないので（Announcing the Windows 8 Editions）、どのエディション、ライセンスなら使えるのかという点が未だはっきりしない。法人向けライセンスのみという可能性もあるが、そうなるとBYODの場合に面倒になったりしないか、という気がする。
2. Windows 7とのCHKDSK問題
5日間使ったところでは、CPまでのようなCHKDSK問題には遭遇していない。同じパーティションにWin7とWin8の双方からCHKDSKをかけてみてもとくに問題になってなかったので、とりあえず忘れてよさそうである。
この問題自体はWin8でNTFSの管理が変更されたこと（chkdskの刷新と新しいNTFS正常性モデルの追加）に関係していそうではあったが。
[追記]
その後、Win7をリカバリーした際にWin8のパーティションをCHKDSKの対象から外し忘れていたら、何かの拍子にWin7のCHKDSKの自動実行がかかってWin8のパーティションが壊れた。このこと自体は仕方ないとして、やはりWin7のCHKDSKからWin8のパーティションは外しておいた方がいいとは思う。
3. 私感
この先、タブレットが伸していくことは確実で、色々なデバイスの関係をリシャッフルしていくのだと思う。となると、当然にPCとタブレットをどう融合させるのか、あるいは使い分けるのかが課題になってくる。
もちろんWin8はタブレット市場にMicrosoftが切り込んでいくための武器なわけだが、頑なにスタートメニューを排除しようとするのには、おそらく不利を覚悟の上での（たぶんスティーブン・シノフスキーの）信念のようなものを感じる。
といっても、それをユーザーが受け入れるかは別問題で、既に慣れてしまったPCの使い方をわざわざ勉強し直したい人は少ないと思うので、純粋なデスクトップ機で成功するかは懐疑的。自分はこういうチャレンジは好きだが、それでもこれがPCとタブレットの融合に対する答えかとなると、一歩引いて考えて、まだ足りてない感は否めない……が、後はハードウェアを含めたパッケージ次第かなと。
とにかくMicrosoftが当面の答えを見せたところで、Appleは同じ課題にどういう答えを持ってくるのか、そこに興味がある。
2012/03/17
Windows 8 CPに関する諸点
Windows 8 Consumer Preview（CP）を二週間ばかり使ってきての気づき。
Windows 8といえばMetroだが、従来のデスクトップも細かい改良を受けていて、それが気に入って常用している。開発環境もこちらに移行した。
リボン化されたエクスプローラだが、リボンの出し入れはクリック1回だし、クイックアクセスツールバー（タスクバーに配置できるアイコン）もあるし、Windows 7の機能を絞り込んだものに比べて便利になっていると思う。シンプルさと各機能へのアクセスのしやすさはトレードオフの関係にあるが、後者に振っている。
日本語版の標準フォントはメイリオUIなので、Windows 7のメイリオより字間が詰まって、凝縮感が高い。これには初め違和感があったが、慣れた。
それから、Windows 7では残っていたビットマップフォントが消えて、すべてアウトラインフォントに変わっている。これは、しばらくWindows 8を使っていてWindows 7に戻ると古臭さを感じてしまう部分。
まあMac OSはとっくにそうなっているが（個人的にあのフォントはボケ度が強すぎるが）、ともかく新しいiPadのRetinaではないが、高精細な画面でUIがDPIから完全に、一片の曇りなく独立した世界が早く来てほしい。最近のノートPCの画面は細かくなる一方で、ついて行けるか個人的に不安を感じているので、割と切実である。
一応の情報として書いておくと、
[追記]
スタートメニューについて、カーソルを左下に移動して「スタート」の窓が出た状態で右クリックするとメニューが出るとのこと。いかにも管理用に使いそうなものが揃っている。
これなら、使い勝手的には十分な気がする。
Developer Previewと同じ方法でWindows To Goが作成できた。USBケースに入れたMSD6000では引き続き問題なし。USBメモリのGH-UFD3-32GFではIEでもインターネット接続ができるようになったが、Windows Updateができない部分は相変わらず。リムーバブルデバイスとして認識されることが問題の元かもしれないと思うが、原因不明。
場合によっては、割と致命的な問題。Bug Report - Serious filesystem corruption and data loss caused to other NTFS drives by Windows 8 CPのとおりで、自分を含めて6件（3/17現在）の報告があるので、まれな現象ではないと思う。
自分の経験したところでは、Windows 7とマルチブートで同居させていると、Windows 7で作成したパーティション（NTFS）をどこか改変してしまうらしく、Windows 7を走らせたときにブート時の自動CHKDSKがかかる。それで済めばいいが、修復に失敗することもあり、また逆に、Windows 7のCHKDSKがWindows 8のパーティションにかかると、今度はWindows 8のブート時の自動CHKDSKがかかって、これも修復できずにブート不能になることがある。
状況的には、NTFSとそれを扱うCHKDSKについて互換性に問題があるのではないかと疑わせる。このままRTMまで行ってしまうと、各所で悲鳴が上がりそうだが……ファイルシステムに関わるだけに、残された期間でMicrosoftが解決できるか、個人的にはやや悲観的。そもそも社内テストで見つからなかったのか、とも思うし。
ともあれ、対処療法的にブート時の自動CHKDSKを抑止する方法はあって、レジストリの"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager"の"BootExecute"というキーで、"autocheck autochk *"に/kオプションで除外するパーティションのドライブレターを挿入するというもの。
ただ……Windows 7とWindows 8 CP双方で互いのパーティションを自動CHKDSKから除外するよう設定してみたが、それでもWindows 8では除外しておいたパーティションに自動CHKDSKがかかることがあったので（丁寧なことに、その後にレジストリを見ると設定したオプションが消えていた）、効いているのか怪しい。
ということで、自分の環境ではこの設定をした後は一応安定しているが、Windows 8 CPは仮想環境で動かすか、それ専用のPCを当てた方が無難ではある。
[追記]
おそらく同じ問題に対して、Windows 8の高速スタートアップに関係があるのではないかという説がMicrosoft Answersで出ていた（マルチブート環境にWindows8CPをインストールしてコールドブートするとCHKDSKが実行される）。
確かに、通常OSを終了する際にクリアされるダーティビットが高速スタートアップのためにクリアされないのであれば、次回ブート時にCHKDSKが自動起動することは説明できる。ただ、問題はCHKDSKが実行された結果OSがおかしくなることでもあるので、それだけの問題ではないと思う。
上記の問題があり、マルチブートするにしてもできるだけ環境は切り離したいので、古典的にWindows 7とWindows 8 CPのパーティション間でアクティブを切り替える方法をとっているが、これを簡単にする方法について。OS標準のDiskPartはスクリプトが使えるので、これをバッチファイルで実行する。
バッチファイルを作成する。以下はスクリプトファイル（scrpit.txt）を「C:\switch\」に置いた場合で、必須ではないが、実行結果を同じフォルダに作成されるログファイル（log.txt）に出力する場合。
1. UI
Windows 8といえばMetroだが、従来のデスクトップも細かい改良を受けていて、それが気に入って常用している。開発環境もこちらに移行した。
リボン化されたエクスプローラだが、リボンの出し入れはクリック1回だし、クイックアクセスツールバー（タスクバーに配置できるアイコン）もあるし、Windows 7の機能を絞り込んだものに比べて便利になっていると思う。シンプルさと各機能へのアクセスのしやすさはトレードオフの関係にあるが、後者に振っている。
日本語版の標準フォントはメイリオUIなので、Windows 7のメイリオより字間が詰まって、凝縮感が高い。これには初め違和感があったが、慣れた。
それから、Windows 7では残っていたビットマップフォントが消えて、すべてアウトラインフォントに変わっている。これは、しばらくWindows 8を使っていてWindows 7に戻ると古臭さを感じてしまう部分。
まあMac OSはとっくにそうなっているが（個人的にあのフォントはボケ度が強すぎるが）、ともかく新しいiPadのRetinaではないが、高精細な画面でUIがDPIから完全に、一片の曇りなく独立した世界が早く来てほしい。最近のノートPCの画面は細かくなる一方で、ついて行けるか個人的に不安を感じているので、割と切実である。
[関連]
週アスPlus: 「ペーパーライク」なディスプレイがヒトとコンピュータの関係を変える
週アスPlus: 「ペーパーライク」なディスプレイがヒトとコンピュータの関係を変える
一応の情報として書いておくと、
- 64bit日本語版をThinkPad X61sにインストールしたが、ドライバーはすべてIn BoxかWindows Updateで出てきたもので賄われたので（TrackPointや省電力ドライバー（ThinkPad PM Device）含め）、別途Windows 7用を当てる必要はなかった。
- 安定性の面は基本的に問題ない。ハイブリッドスリープをオンにしたときにサスペンドからの復帰に失敗したりしたことがあったが、これはハードウェア依存の問題（ドライバーなど）かもしれないので、とりあえず措く。
- スタートメニューがない点は、（その良し悪しは別として）ショートカットキーでカバー可能。Windowsキー＋Qでアプリの検索画面が出て、これが実質的にスタートメニューの代用になり得る。
[参考] Windows 8のショートカットキー
MSDN: A few Windows developer preview keyboard shortcuts
ITmedia +D: Windows 8でも使いたい「ショートカット」一覧
- ファイルの上書きコピー時に、その確認を求めるダイアログが一番上に来なくて、タスクバーのエクスプローラから拾い出さないといけないことがある。
[追記]
スタートメニューについて、カーソルを左下に移動して「スタート」の窓が出た状態で右クリックするとメニューが出るとのこと。いかにも管理用に使いそうなものが揃っている。
これなら、使い勝手的には十分な気がする。
[参考]
山市良のえぬなんとかわーるど: Windows 8 Consumer Preview > スタートメニューっぽいやつ
山市良のえぬなんとかわーるど: Windows 8 Consumer Preview > スタートメニューっぽいやつ
2. Windows To Go
Developer Previewと同じ方法でWindows To Goが作成できた。USBケースに入れたMSD6000では引き続き問題なし。USBメモリのGH-UFD3-32GFではIEでもインターネット接続ができるようになったが、Windows Updateができない部分は相変わらず。リムーバブルデバイスとして認識されることが問題の元かもしれないと思うが、原因不明。
3. Windows 7とのCHKDSK問題
場合によっては、割と致命的な問題。Bug Report - Serious filesystem corruption and data loss caused to other NTFS drives by Windows 8 CPのとおりで、自分を含めて6件（3/17現在）の報告があるので、まれな現象ではないと思う。
自分の経験したところでは、Windows 7とマルチブートで同居させていると、Windows 7で作成したパーティション（NTFS）をどこか改変してしまうらしく、Windows 7を走らせたときにブート時の自動CHKDSKがかかる。それで済めばいいが、修復に失敗することもあり、また逆に、Windows 7のCHKDSKがWindows 8のパーティションにかかると、今度はWindows 8のブート時の自動CHKDSKがかかって、これも修復できずにブート不能になることがある。
（注）実はDeveloper Previewでも同様の現象はあったが、再現性がよく分からなかった。ついでに、Windows 8 CPで自動CHKDSKがかかると、インストールしていたVisual Studioが起動不能になることがある。起動に関係する何らかの情報が書き換わってしまったのではないかと思うが、これも不明。
状況的には、NTFSとそれを扱うCHKDSKについて互換性に問題があるのではないかと疑わせる。このままRTMまで行ってしまうと、各所で悲鳴が上がりそうだが……ファイルシステムに関わるだけに、残された期間でMicrosoftが解決できるか、個人的にはやや悲観的。そもそも社内テストで見つからなかったのか、とも思うし。
ともあれ、対処療法的にブート時の自動CHKDSKを抑止する方法はあって、レジストリの"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager"の"BootExecute"というキーで、"autocheck autochk *"に/kオプションで除外するパーティションのドライブレターを挿入するというもの。
[参考]
Windows Reference: How to disable check disk (chkdsk) at startup in vista
Microsoftサポート: [CHKNTFS.EXE] CHKNTFS.EXE の使用方法
Microsoftサポート: [NT]Win2000:Chkdsk、Autochk、および Chkntfs ツールの拡張
Windows Reference: How to disable check disk (chkdsk) at startup in vista
Microsoftサポート: [CHKNTFS.EXE] CHKNTFS.EXE の使用方法
Microsoftサポート: [NT]Win2000:Chkdsk、Autochk、および Chkntfs ツールの拡張
ただ……Windows 7とWindows 8 CP双方で互いのパーティションを自動CHKDSKから除外するよう設定してみたが、それでもWindows 8では除外しておいたパーティションに自動CHKDSKがかかることがあったので（丁寧なことに、その後にレジストリを見ると設定したオプションが消えていた）、効いているのか怪しい。
ということで、自分の環境ではこの設定をした後は一応安定しているが、Windows 8 CPは仮想環境で動かすか、それ専用のPCを当てた方が無難ではある。
[追記]
おそらく同じ問題に対して、Windows 8の高速スタートアップに関係があるのではないかという説がMicrosoft Answersで出ていた（マルチブート環境にWindows8CPをインストールしてコールドブートするとCHKDSKが実行される）。
確かに、通常OSを終了する際にクリアされるダーティビットが高速スタートアップのためにクリアされないのであれば、次回ブート時にCHKDSKが自動起動することは説明できる。ただ、問題はCHKDSKが実行された結果OSがおかしくなることでもあるので、それだけの問題ではないと思う。
4. アクティブの切り替え
上記の問題があり、マルチブートするにしてもできるだけ環境は切り離したいので、古典的にWindows 7とWindows 8 CPのパーティション間でアクティブを切り替える方法をとっているが、これを簡単にする方法について。OS標準のDiskPartはスクリプトが使えるので、これをバッチファイルで実行する。
- DiskPartのスクリプトファイルを作成する。先に手動でDiskPartを使ってアクティブにするパーティションのdisk番号とpartition番号を確認しておき、それを手動でアクティブにするのと同じ内容を書けばいい。以下は"disk 0"の"partition 1"が目的のパーティションだった場合。ファイル名はここでは「script.txt」とした。
list disk
select disk 0
list partition
select partition 1
active
exit
（注）"list disk"と"list partition"は必須ではないが、実行結果を下記のログファイルに記録するため。
diskpart /s C:\switch\script.txt > C:\switch\log.txt
exit
ポイントはバッチファイル中のスクリプトファイルの指定方法で、ここはフルパスでないといけない。なぜならコマンドプロンプトを管理者権限で開くと自動的にカレントが「C:\Windows\System32」になるが、バッチファイルを管理者権限で実行したときもカレントは同じく「C:\Windows\System32」になり、たとえスクリプトファイルがバッチファイルと同じフォルダにあってもカレントから見えなくなるので。自分はこれを認識してなくて、少しはまった。
2011/09/23
Windows To GoなUSBメモリ
Windows 8 pre-betaであるところのWindows Developer Preview（以下、略してWDP）には、完全に独立したOSをUSBメモリから起動できるWindows To Goがある。これがあればPCにインストールしたままにしなくてもWDPが使えるので、このUSBメモリを作成してみた。
BUILD2011の資料を見ると、作成方法がさらっと書いてある。
環境依存のドライブレターがそのまま入っているので分かりにくいが、大体以下の手順で作成できることが分かる。
これに従えば、手順は以下のようになる。
実際に試した条件は以下のとおり。
先に、それぞれの速度をCrystalDiskMarkで確認しておく。なお、X61sはストレージ速度が遅いPCなので（前世代のX60sと比べても遅い）、他のPCならもっと速いと思われる。
まずRUF3-S32GS-BK。
テストサイズが1000MBのときの4Kランダムライトが極端に遅いのが分かる。
次にGH-UFD3-32GF。
これは1000MBでも4Kランダムライトがそれなりの値を維持している。なお、他の人のベンチマーク結果を見ると、このUSBメモリの値はこれよりかなり高い。
さらに比較用として、手持ちのUSB2.0のUSBメモリの中で最速のPicoBoost 8GB（以前の計測結果）。
1000MBでもそれほど遅くなっていない。これに比べるとRUF3-S32GS-BKの4Kランダムライトの遅さが際立つ。
最後にMSD6000によるUSB SSD。このMSD6000は最初期のSSDで、引退させていたのを探し出してきた。
当然といえば当然だが、ランダムライトはUSBメモリとは段違いに速い。
まず用意したのがRUF3-S32GS-BKで、これが順調に行っていればそこで終わりだったのだが。
作成は手順どおりにできたが、imagex.exeの実行には209分もかかった。
作成したUSBメモリからブートすると、インストールに長い時間がかかった後、WDPが起動した。起動後は、見た目は内蔵SSDから起動したときと変わらない。ページファイルを無効にした状態でUSBメモリの使用容量は約14GB。
ただし……起動と終了を何度か繰り返すうちにはっきりしたが、動作が極めて、極めて遅い。
起動時間（電源ボタンを押してからStart画面が出るまで）を内蔵SSDと比べると、
ここは実際の順番とは前後する。
Windows To Goが極めて遅いのはRUF3-S32GS-BKのランダムライトの遅さが原因という可能性があるので、改めてBUILD2011で配布されたUSBメモリを見ると、外観からKingstonのData Traveler Ultimate 3.0シリーズということが分かった。
このシリーズには第1世代（G1）と第2世代（G2）とがあって、G2の方がシーケンシャルリードでは速くなっているが、ランダムライトではG1の方が他のUSBメモリの中でも飛び抜けた速さを誇っている。これはG1が中身的にはUSB SSDに近いということがあると思う。
Microsoftが配布したのがG1かG2かは分からないが、ランダムライトの速さからいえばG1の方が理想的ではある。が、生産終了品でうまく入手できなかったのと、G2もランダムライトは速い方なので、G2とほぼ同じコントローラを持ち、入手性も高いGH-UFD3-32GFに方向転換した次第。
GH-UFD3-32GFでWindows To Goを作成したところ、imagex.exeの所要時間は50分と、かなり短縮された。
作成したUSBメモリからブートしてのインストールもそれほど待たされることなく、WDPが起動した。動作は内蔵SSDに比べればややぎこちないが、普通に操作できる。起動時間も十分に許容範囲。
なお、RUF3-S32GS-BKでは遅すぎてこの問題を確認するには至らなかった。
RUF3-S32GS-BKでは遅すぎて使い物にならないと判明した後、USB接続のストレージでランダムライトが速く、手持ちで試せるものとして浮かんだのがMSD6000をUSB接続にすること。
このUSB SSDでWindows To Goを作成すると、まずimagex.exeの所要時間が段違い。20分で終了した。
このUSB SSDからブートするとインストールもさくっと進み、WDPが起動。操作した感じも内蔵SSDと変わらない。起動時間もリーズナブル。
エクスペリエンスインデックスはこんなもの（上が内蔵SSD、下がUSB SSD）。
Primary hard diskは、内蔵SSDの7.2に対してUSB SSDは5.2なので、そんなに低くはない。
以上、USB SSDで作成したらさくさく動作するWindows To Goができた。
Windows To Goの動作には、USBメモリのランダムライトの速度が重要。これはOSがその上で動作することを考えれば当然ではある。接続がUSB2.0かUSB3.0かは直接関係ないし、PCの性能もあまり関係ないが、USBメモリの速度はPC本体にかなり左右されるところがあるので、無関係とも言えない。
これはReadyBoostの条件と似ているが、最近の、とくに32GB超のUSBメモリではReadyBoost対応は重視されてないようなので、盲点ではある。高速なシーケンシャルアクセスを謳う製品でも、ランダムライトが遅ければWindows To Goには不適格。この点は、Windows 8がリリースされるときにはReadyBoostのような基準を作る必要があると思う。
とりあえず容量と速度を考えれば自分のようにSSDを再利用するのが手っ取り早いが、ランダムライトが遅くないUSBメモリを慎重に選ぶか、先々は、教えていただいたSuper TalentのUSB 3.0 Express RC8のような中身的にUSB SSDに近いものを使うのがいいと思う。ただし、IEの問題は残るかもしれない。
Windows To Goの場合に限らないが、WDPの起動時に自動chkdskがかかった後、Windows 7で作成したパーティション（ファイルシステムはNTFS）がアクセス不能になったことが複数回あった。逆に、Windows 7で自動chkdskがかかった後、WDPのシステムパーティションがアクセス不能になったこともあった。
バックアップしておけばいいことだが、一応注意を要する。
[追記1]
Windows To Goの作成例。
また、ぱすわさんの場合もIEが起動できないということなので、これは普遍的な問題らしい。
さらに、清水さんの記事を読んで、改めてBUILD2011での動画を見ると、デモで使われていたのはSuper TalentのRAIDDrive USB3.0だった模様（市場で入手できる現在最速の、8chでSuper Talentのドライブと言っている）。確かにこれなら速度的には別格だから、道理でという感じ。資料を見直しても「USB Drive」と書いていても「USB Stick」とは書いてないので、これを（並みの）USBメモリと捉えたのが、ある意味ミスリーディングだったようにも思う。
[追記2]
USB SSDでWindows To Goを使っていたところ、サスペンド、ハイバネーションともできないことが判明した。内蔵SSDから起動した場合には可能なので、Windows To Goの場合特有の問題だと思う。
なお、内蔵SSDから起動した場合も「Power」に「Sleep」の選択肢は出ないが、ThinkPad式のショートカットキー（Fn + F12）でハイバネーションに入り、電源キーでレジュームする。ただし、サスペンド（Fn ＋ F4）したときもハイバネーションに入る模様（非常に速いので実害はないが）。
[追記3]
Windows To Goの最終的な姿が明らかになったので、まとめを書いた。
1. 作成方法
BUILD2011の資料を見ると、作成方法がさらっと書いてある。
（Channel9 BUILD2011 Running Windows from an external USB drive with Windows To Goのスライド資料より）
環境依存のドライブレターがそのまま入っているので分かりにくいが、大体以下の手順で作成できることが分かる。
- imagex.exeで（予め作成しておいた）OS環境のイメージファイル（.wim）をUSBメモリに展開する。
- Bcdboot.exeでOSを起動可能にする。
- imagex.exeか他の方法でイメージファイルを作成するときに必要なオプション、その有無が不明。
- WDPのバージョン（Build 8102）に対応したimagex.exeはWindows ADK（Windows 7までのWindows AIKに相当）に入っているようだが、これをダウンロードするにはMSDNサブスクリプションが必要。
これに従えば、手順は以下のようになる。
- Windows 7のWindows AIKをインストールし、imagex.exe（64bitは\Program Files\Windows AIK\Tools\amd64に、32bitは\Program Files\Windows AIK\Tools\x86にある）を適当な場所にコピーしておく。
- 32GB以上のUSBメモリをDiskPartでブート可能にしておく。詳しい方法は従来と同じ（diskpartを使ってWindows Vista/7のインストールUSBメモリを作る）。ただし、ファイルシステムはNTFSで。
- WDPのインストールDVDのISOファイルをマウントして（Windows 8では標準でこれが可能）、install.wim（\sourcesにある）をimagex.exeと同じ場所にコピーしておく。
- USBメモリを挿し、管理者としてコマンドプロンプトを開いて、imagex.exeのある場所から以下を実行（かなり時間がかかる）。ここまではWindows 7でも可。
imagex.exe /apply install.wim 1 d:\
（USBメモリのドライブレターがD:の場合）
- 続いて以下を実行。ここはWDPでなければ不可（Windows 7ではBcdboot.exeに/fオプションがないので）。
bcdboot.exe d:\windows /s d: /f ALL
（同上）
2. 実際
実際に試した条件は以下のとおり。
- PC: ThinkPad X61s（CPU: Core2Duo 1.8GHz、メモリ: 4GB、USB2.0）
- ISOファイル: 開発ツール付きの64bit版（WindowsDeveloperPreview-64bit-English-Developer.iso）
- USBストレージ:
- Buffalo RUF3-S32GS-BK (32GB、USB3.0、ファームウェアアップデート済み、TurboPCなど付属ツールは使用しない)
- GreenHouse GH-UFD3-32GF (32GB、USB3.0)
- Mtron MSD6000（MSD-SATA6025-032-N-A、32GB、SATAのSSD）
＋SilverStone SST-TS02B（USB2.0、2.5インチ用のUSBケース）
先に、それぞれの速度をCrystalDiskMarkで確認しておく。なお、X61sはストレージ速度が遅いPCなので（前世代のX60sと比べても遅い）、他のPCならもっと速いと思われる。
まずRUF3-S32GS-BK。
テストサイズが1000MBのときの4Kランダムライトが極端に遅いのが分かる。
次にGH-UFD3-32GF。
これは1000MBでも4Kランダムライトがそれなりの値を維持している。なお、他の人のベンチマーク結果を見ると、このUSBメモリの値はこれよりかなり高い。
さらに比較用として、手持ちのUSB2.0のUSBメモリの中で最速のPicoBoost 8GB（以前の計測結果）。
1000MBでもそれほど遅くなっていない。これに比べるとRUF3-S32GS-BKの4Kランダムライトの遅さが際立つ。
最後にMSD6000によるUSB SSD。このMSD6000は最初期のSSDで、引退させていたのを探し出してきた。
当然といえば当然だが、ランダムライトはUSBメモリとは段違いに速い。
RUF3-S32GS-BKの場合
まず用意したのがRUF3-S32GS-BKで、これが順調に行っていればそこで終わりだったのだが。
作成は手順どおりにできたが、imagex.exeの実行には209分もかかった。
作成したUSBメモリからブートすると、インストールに長い時間がかかった後、WDPが起動した。起動後は、見た目は内蔵SSDから起動したときと変わらない。ページファイルを無効にした状態でUSBメモリの使用容量は約14GB。
（C:がWindows To GoのUSBメモリ）
ただし……起動と終了を何度か繰り返すうちにはっきりしたが、動作が極めて、極めて遅い。
起動時間（電源ボタンを押してからStart画面が出るまで）を内蔵SSDと比べると、
- 内蔵SSD: 18秒
- RUF3-S32GS-BKによるWindows To Go（初回ではない）: 8分25秒
GH-UFD3-32GFの場合
ここは実際の順番とは前後する。
Windows To Goが極めて遅いのはRUF3-S32GS-BKのランダムライトの遅さが原因という可能性があるので、改めてBUILD2011で配布されたUSBメモリを見ると、外観からKingstonのData Traveler Ultimate 3.0シリーズということが分かった。
このシリーズには第1世代（G1）と第2世代（G2）とがあって、G2の方がシーケンシャルリードでは速くなっているが、ランダムライトではG1の方が他のUSBメモリの中でも飛び抜けた速さを誇っている。これはG1が中身的にはUSB SSDに近いということがあると思う。
[参考]
AnandTech: Kingston DataTraveler Ultimate 3.0 & OCZ Enyo, Quick Look at Two USB 3.0 SSDs
DecryptedTech: Kingstons' Data Traveler Ultimate G2 hits 100+MB/s
AnandTech: Kingston DataTraveler Ultimate 3.0 & OCZ Enyo, Quick Look at Two USB 3.0 SSDs
DecryptedTech: Kingstons' Data Traveler Ultimate G2 hits 100+MB/s
Microsoftが配布したのがG1かG2かは分からないが、ランダムライトの速さからいえばG1の方が理想的ではある。が、生産終了品でうまく入手できなかったのと、G2もランダムライトは速い方なので、G2とほぼ同じコントローラを持ち、入手性も高いGH-UFD3-32GFに方向転換した次第。
GH-UFD3-32GFでWindows To Goを作成したところ、imagex.exeの所要時間は50分と、かなり短縮された。
作成したUSBメモリからブートしてのインストールもそれほど待たされることなく、WDPが起動した。動作は内蔵SSDに比べればややぎこちないが、普通に操作できる。起動時間も十分に許容範囲。
- 内蔵SSD: 18秒
- GH-UFD3-32GFによるWindows To Go: 46秒
なお、RUF3-S32GS-BKでは遅すぎてこの問題を確認するには至らなかった。
MSD6000（USB SSD）の場合
RUF3-S32GS-BKでは遅すぎて使い物にならないと判明した後、USB接続のストレージでランダムライトが速く、手持ちで試せるものとして浮かんだのがMSD6000をUSB接続にすること。
このUSB SSDでWindows To Goを作成すると、まずimagex.exeの所要時間が段違い。20分で終了した。
このUSB SSDからブートするとインストールもさくっと進み、WDPが起動。操作した感じも内蔵SSDと変わらない。起動時間もリーズナブル。
- 内蔵SSD: 18秒
- MSD6000によるWindows To Go: 32秒
（C:がWindows To GoのUSB SSD）
エクスペリエンスインデックスはこんなもの（上が内蔵SSD、下がUSB SSD）。
Primary hard diskは、内蔵SSDの7.2に対してUSB SSDは5.2なので、そんなに低くはない。
以上、USB SSDで作成したらさくさく動作するWindows To Goができた。
3. まとめ
Windows To Goの動作には、USBメモリのランダムライトの速度が重要。これはOSがその上で動作することを考えれば当然ではある。接続がUSB2.0かUSB3.0かは直接関係ないし、PCの性能もあまり関係ないが、USBメモリの速度はPC本体にかなり左右されるところがあるので、無関係とも言えない。
これはReadyBoostの条件と似ているが、最近の、とくに32GB超のUSBメモリではReadyBoost対応は重視されてないようなので、盲点ではある。高速なシーケンシャルアクセスを謳う製品でも、ランダムライトが遅ければWindows To Goには不適格。この点は、Windows 8がリリースされるときにはReadyBoostのような基準を作る必要があると思う。
とりあえず容量と速度を考えれば自分のようにSSDを再利用するのが手っ取り早いが、ランダムライトが遅くないUSBメモリを慎重に選ぶか、先々は、教えていただいたSuper TalentのUSB 3.0 Express RC8のような中身的にUSB SSDに近いものを使うのがいいと思う。ただし、IEの問題は残るかもしれない。
4. 注意点
Windows To Goの場合に限らないが、WDPの起動時に自動chkdskがかかった後、Windows 7で作成したパーティション（ファイルシステムはNTFS）がアクセス不能になったことが複数回あった。逆に、Windows 7で自動chkdskがかかった後、WDPのシステムパーティションがアクセス不能になったこともあった。
バックアップしておけばいいことだが、一応注意を要する。
[追記1]
Windows To Goの作成例。
- Internet Watch: 清水理史のイニシャルB: 第460回：Windows Developer Preview登場！ USBで携帯するWindows 8「Windows To Go」を試す
- ComputerWorld: Windows Developer Preview、Windows To Go とゴー
- 人生無限ループ: Windows8(仮)『Windows To Go』を試す（その１）
Windows8(仮)『Windows To Go』を試す（その２）
また、ぱすわさんの場合もIEが起動できないということなので、これは普遍的な問題らしい。
さらに、清水さんの記事を読んで、改めてBUILD2011での動画を見ると、デモで使われていたのはSuper TalentのRAIDDrive USB3.0だった模様（市場で入手できる現在最速の、8chでSuper Talentのドライブと言っている）。確かにこれなら速度的には別格だから、道理でという感じ。資料を見直しても「USB Drive」と書いていても「USB Stick」とは書いてないので、これを（並みの）USBメモリと捉えたのが、ある意味ミスリーディングだったようにも思う。
[追記2]
USB SSDでWindows To Goを使っていたところ、サスペンド、ハイバネーションともできないことが判明した。内蔵SSDから起動した場合には可能なので、Windows To Goの場合特有の問題だと思う。
なお、内蔵SSDから起動した場合も「Power」に「Sleep」の選択肢は出ないが、ThinkPad式のショートカットキー（Fn + F12）でハイバネーションに入り、電源キーでレジュームする。ただし、サスペンド（Fn ＋ F4）したときもハイバネーションに入る模様（非常に速いので実害はないが）。
[追記3]
Windows To Goの最終的な姿が明らかになったので、まとめを書いた。
登録:
投稿
(
Atom
)
