Windows Containerを使う場合に、Docker for WindowsのインストーラをDockerのサイトからダウンロードしてきてインストールするとデフォルトではLinux Containerを使うようにセットアップされます。
その状態でWindows Containerのセットアップ手順に沿ってサービスを起動しようとすると以下のようなエラーが発生することがあります。
start-service : Failed to start service 'Docker Engine (docker)'.
アプリケーションのイベントログには以下のようなログが残ります。
fatal: open //./pipe/docker_engine: Access is denied.
これはLinux Container向けのエンジンと通信しようとするために発生しているようです。
PS C:\WINDOWS\system32> docker version
Client:
Version: 17.03.0-ce
API version: 1.26
Go version: go1.7.5
Git commit: 60ccb22
Built: Thu Feb 23 10:40:59 2017
OS/Arch: windows/amd64
Server:
Version: 17.03.0-ce
API version: 1.26 (minimum version 1.12)
Go version: go1.7.5
Git commit: 3a232c8
Built: Tue Feb 28 07:52:04 2017
OS/Arch: linux/amd64
Experimental: true
解決方法
タスクトレイのアイコンのメニューから "Switch to Windows containers..."を選択することでWindows Containersを使うように変更できます。
PS C:\WINDOWS\system32> docker version
Client:
Version: 17.03.0-ce
API version: 1.26
Go version: go1.7.5
Git commit: 60ccb22
Built: Thu Feb 23 10:40:59 2017
OS/Arch: windows/amd64
Server:
Version: 17.03.0-ce
API version: 1.26 (minimum version 1.24)
Go version: go1.7.5
Git commit: 60ccb22
Built: Thu Feb 23 10:40:59 2017
OS/Arch: windows/amd64
Experimental: true
A peek into the WebAssembly Browser Previewや
ChakraCore v1.4.0からEnable WebAssembly browser preview support under experimental flag
とあるようにWebAssemblyのプレビューサポートがEdgeとChakraCoreに入ったので試してみようというお話です。
WebAssemblyのバイナリを作る
WebAssemblyはJavaScriptのようにテキストではなくバイナリの形をとります。つまり実行したいJavaScriptのコードをバイナリに変換する必要があります。
とはいえ何でも変換できるわけではありません。
基本的には低レベルなコード、要するにasm.jsのコードを変換することになります。将来的にはWebAPIやその他オブジェクト類も視野にあるようですが現状では扱えません。
Emscriptenなどのコンパイラはasm.jsのコードを吐くので一旦それで十分ということでしょう。
asm.jsなコードをWebAssemblyに変換すればよいので早速ツールを準備します。本当はEmscriptenでC言語のコードを変換する方が面白いのですがいろいろビルドする準備がとても面倒なのでとりあえずasm.jsをダイレクトに変換してみます。
asm.jsをWebAssemblyにコンパイルするためのツールとしてBinaryenというものが提供されています。
このbinaryenはC++で書かれているasm.jsやLLVM Emscripten出力を変換するためのコンパイラツールチェインです。
残念ながらWindows向けバイナリが提供されているわけではないので結局ビルドが必要ですが
Visual Studio 2015とCMakeさえあれば大丈夫です。
Visual StudioとCMakeが揃ったらリポジトリを git clone し、コマンドプロンプトで cmake . を実行すると Binaryen.sln が生成されます。このソリューションファイルを開き、ALL_BUILD プロジェクトをビルドすれば出来上がりです。意外と簡単です。
ビルド後に bin フォルダにいくつかの実行ファイルが生成されます。その中で今回使うのは以下の二つのツールです。
- asm2wasm: asm.js を wasm (wast)にコンパイルするツール
- wasm-as: wast を wasm に変換するツール
asm.jsをWebAssemblyに変換してみる
というわけでasm.jsなコードをWebAssemblyの形に変換します。変換するコードはBinaryenのREADMEにある以下のシンプルな足し算するだけのコードで試してみます。コードは適当な名前(sample.js など)で保存してください。
function () {
"use asm";
function add(x, y) {
x = x | 0;
y = y | 0;
return x + y | 0;
}
return { add: add };
}
Binaryenのフローではasm.jsからWebAssemblyのバイナリフォーマット(.wasm)へは直接変換できないので一度テキストフォーマット(wast)に変換して、それをバイナリフォーマットへ変換するという手順が必要です。
というわけでasm.jsをwast形式に変換するasm2wasmコマンドを実行します。しかしwastに変換するのにasm2wasmなのは納得いかないものがあります。
.\asm2wasm.exe test.js
コマンドを実行するとwastへ変換した結果が標準出力に出力されます。 wastはいわゆるS式で単純なコードであれば何となく雰囲気はつかめるのではないでしょうか。
(import "env" "memory" (memory $0 256 256))
(import "env" "table" (table 0 0 anyfunc))
(import "env" "memoryBase" (global $memoryBase i32))
(import "env" "tableBase" (global $tableBase i32))
(export "add" (func $add))
(func $add (param $x i32) (param $y i32) (result i32)
(return
(i32.add
(get_local $x)
(get_local $y)
)
)
)
)
標準出力に出力されても困るのでファイルに保存するように -o オプションでファイル名を指定して出力しましょう。
.\asm2wasm.exe test.js -o test.wast
これで test.wast に変換結果が書き込まれます。次はバイナリに変換…と行きたいところなのですがその前に出力結果を少し変更します。test.wastファイルを適当なテキストエディタで開いて import セクションを削除します。
本当はモジュールを読み込む際にimportするべきものをちゃんと渡してあげれば動くのではと思うのですがEdgeやChromeでうまく動かせず、間違ってるのか仕様と実装が違うのかよくわからないこともありとりあえずなくていいので削除します。出力されているimportは主にEmscriptenを想定している気がします。
で、importセクションを削るとこんな感じです。メソッドをexportしているだけになりました。
(module
(export "add" (func $add))
(func $add (param $x i32) (param $y i32) (result i32)
(return
(i32.add
(get_local $x)
(get_local $y)
)
)
)
)
wastができたら次はバイナリ形式であるwasm形式に変換します。wasm形式への変換にはwasm-as コマンドを使用します。特に難しいこともないので単に実行するだけです。
.\wasm-as.exe test.wast -o test.wasm
これでWebAssemblyのバイナリが出来上がりです!
WebAssemblyのバイナリをブラウザで実行してみる
というわけでwasmが出来上がったのでさっそく実行してみましょう。今回はEdge (Insider Preview)で実行してみます(Chromeで実行しても大丈夫です)。
適当なHTMLを作って次のようなスクリプトを書いて開いてみましょう。
fetch('test.wasm')
.then(x => x.arrayBuffer())
.then(x => WebAssembly.compile(x))
.then(x => {
const instance = new WebAssembly.Instance(x, {});
const retval = instance.exports.add(1, 2);
alert(retval);
});
1行目と2行目はfetch APIでバイナリを読み込んでいます。WebAssembly関係ないです。
3行目でwasmバイナリはバイトコードみたいなものなのでコンパイルしてモジュールにします。それが WebAssembly.compile です。
5行目はコンパイルしてモジュールになったものからインスタンス(JavaScript界のオブジェクト)を作ります。WebAssembly.Instanceの第一引数にはモジュール、第二引数にはimportするオブジェクトを指定します。今回はimportするものがないので空です。
6行目はインスタンスからエクスポートされている add メソッドを呼び出しです。ついにWebAssemblyのメソッドにたどり着きました。
7行目はaddの結果を出力しているだけですね。
このスクリプトを実行すると alert で 3 が表示されてWebAssemblyを動かした実感を得られるかどうかはわかりませんが動くことを確認できます。まあ面白くはないですけど…。
まとめ
手で書いたasm.jsから吐いても面白くないというかそもそもasm.jsも人間が書くものではない感じがするので、基本的にはEmscriptenのような何らかのコンパイラが出力するものという感じがしますね。C#もLLVMバックエンドとなるLLILCがちゃんと動くようになったら行けるかも、というかMSILからC++コードを吐いてEmscriptenを通してasm.jsというのはUnityがすでにやっているのでそういう道もありそうです。
触ってみた感じとしてWebAssembly.Instanceを作った後は単なるJavaScriptのオブジェクトとして使えるので、ライブラリとして提供されるというユースケースは良さそうです。例えばzlibとかそういった圧縮ライブラリや暗号化ライブラリ、エンコーダーやデコーダーといったものはWebAssemblyで提供されることで高速に読み込んで動作するとか。
折を見てEmscriptenで何か変換したりしてもう少し動かしてる感のあることをやりたいですね。
tl;dr
"DP HotPlug"を有効にする。
症状
Surface BookやSurface Pro 4をEIZO FlexScan EV2736WにDisplayPortで接続している環境でSurfaceの電源が切れた際、ディスプレイもスタンバイ(パワーセーブ)になりますがその後ディスプレイが応答しなくなることがあります。
Surface側はスタンバイから復帰するとディスプレイが切断された状態で問題なく動き続けますが、ディスプレイは主電源(後ろのスイッチ)を入れなおさないと復帰せず操作できない状態になります。
この問題はSurface Dock、Surfaceに直接接続時のどちらでも発生し、結構な頻度で発生するのでなかなかストレスフルです。
対処方法
Surface側がスタンバイや電源が切れた際にDisplayPortの接続が切れ、ディスプレイ側がスタンバイになったときに問題が発生しているような雰囲気があります。
ところでDisplayPortでの接続時にディスプレイ側の電源を切るとコンピューターから見て切断された扱いになる場合があることが知られていますが、
FlexScanには切断された扱いにならないようにする"DP HotPlug"という機能があります。これを有効にするとディスプレイの電源を切ってもマルチモニターが維持された状態になり、アイコンやウィンドウが残念なことにならないという便利機能です。
ディスプレイ側の電源なのでで関係なさそうなありそうなこの機能を有効にすると問題が収まりました(二日ぐらいたってもフリーズしてない)。
EV2736Wで"DP HotPlug"を有効にする方法「上矢印を押しながら電源を入れる」です。詳しくはマニュアルに書いてありますが、DisplayPort入力に切り替えたとき入力表示が灰色になっていれば有効になっています。
tl;dr
ドライバーをMicrosoftの"Remote NDIS Compatible Device"に強制的に変更する。
症状
PIX-MT100というUSBドングル型のLTE通信デバイスがあり、コンピューターに接続するとLTE回線を利用して通信できます。
そんな便利デバイスですがWindowsが動作しているコンピューターに接続した場合にOS全体の反応が異常に悪くなる(遅くなる/重くなる)ことがあります。
例えば、接続中はタスクマネージャーが著しく遅くなる、アプリケーションが応答しなくなるといった状態が発生します。詳しい発生環境は調べていませんがいくつかのWindows 10を実行しているコンピューターで発生することを確認しています。
原因と回避策
原因はどうやら接続時にインストールされるドライバーによるもののようなので、別なドライバにー変更することで正常に動作します。
デバイスマネージャーを開くと"Remote NDIS based Internet Sharing"というデバイスがネットワークアダプターの下に見つかります。
このデバイスを開いて、ドライバーの更新を選択します。
ドライバーの一覧から互換性のあるもの以外を表示するようにして全てのドライバーを表示します。この時点ではD-Linkのドライバが選択されているかと思います。
次に製造元はMicrosoftを選択し、"Remote NDIS Compatible Device"を選択して進めます。"Remote NDIS based Internet Sharing"ではないことに注意してください。
その際、互換性を確認できていない云々が表示されますがそのままインストールします。
インストールが完了すると、"Remote NDIS based Internet Sharing"の詳細タブの中で"Remote NDIS Compatible Device"になっていることを確認できます。
互換性云々のメッセージが出るにもかかわらず、これで問題なく動作するようになります。
おまけ
ところでこれと同じ症状はIntel EdisonをUSB接続したときにも発生します。特に試してはいませんがEdisonもRNDISデバイスとして見えるようになっていたので、多分同様の操作で治るのではないかという気がしています。
何を言っているのかという感じですが、ロックスクリーンを単体で起動する方法についてです。
ある日、Windowsのロックを解除したらなぜかロックスクリーンがウィンドウとして残るという現象が発生してちょっと驚きました。
もちろんウィンドウなので自由にリサイズでき、ロックスクリーンそのものなので画像を変更したり、情報などの表示物も変わったりします。複数の解像度の時の見た目を確認できて便利です。
WindowsのロックスクリーンはUWPのアプリケーションとして実装されているということは知っていたのですが、
確かにそれであればウィンドウみたいになってもおかしくはないですね。
ということはもしかして単体で起動できたりするかも?と思って調べたところうまく起動できました。
単純にロックスクリーンのUWPアプリケーションを起動するだけなのですが、exeを叩いて起動するのではなくAppIDをもとにアクティベーションするというややこしい手順が必要になります。
そこで手っ取り早く起動するのにWindows KitのUWPアプリケーションを起動できるコマンドを使います。
Windows Kit (App Certification Kit)をインストールしたら、コマンドプロンプトで次のコマンドを実行することでロックスクリーンを起動できます。
cd \Program Files (x86)\Windows Kits\10\App Certification Kit
microsoft.windows.softwarelogo.appxlauncher.exe Microsoft.LockApp_cw5n1h2txyewy!WindowsDefaultLockScreen