三田「お金を払わなきゃフェアじゃない。フェアユースじゃない。」
問「お金の問題なんですか？」
三田「金銭的なインセンティブは本質的な問題ではない。重要なのは作家へのリスペクトだ。」
問「なるほど、金銭以外にもリスペクトする方法があるってことですね。」
三田「お金を払わなきゃフェアじゃない。フェアユースじゃない。」
（以下、繰り返し）
2009年5月31日日曜日
2009年4月1日水曜日
Silverlight 3で追加されたaglimitパラメータによる機能制限はSilverlight広告への布石？
【注意】aglimitはエイプリルフールのネタで実際には存在しませんのであしからず。(追記 2009/4/3)
HTMLからSilverlight3アプリケーションを呼び出す時は、<object>タグを使用するのですが、その内部で、<params>タグを使って指定するパラメータにaglimitというパラメータが追加されているのです。
まずはサンプルを挙げてみます。
上記の value="audio+movie"の部分で、Silverlightアプリケーションでの動画や音声の再生が禁止されます。
ちなみに、agは銀の元素記号で、Silverlightを指しています。
Silverlight関連で、agを接頭辞に持つ名前が色々あるのはそのためです。（例：agcore.dll、AgDLR）
ついでですが、Silverlight 3 Beta 1で作成したアプリケーションを呼び出す<object>タグの使い方については、@matarilloさんの、「ユーザーがSilverlight 3ベータ版をインストールするときの挙動」が必読です。少なくともSilverlight 3アプリケーションを公開するかもしれない人は全員読むべきだと思います。
Microsoft側としては、Silverlightの表現力を制限する機能であるaglimitをあまり大っぴらに宣伝したくないのか、MIX09でのSilverlight関連の発表でも触れられていないようですし、開発者向けのドキュメントやヘルプにもまだ記載がありません。
そのため、aglimitが追加された理由については、はっきりとは分からないのですが、個人的には、aglimitは「Silverlight広告」の推進の布石ではないだろうか？と予想をしています。
というのは、従来のFlash広告には、この手の機能を制限する仕組みがほとんどありません。
ですから、広告のあるページを開いただけでいきなり音が鳴ってビックリした経験をお持ちの方も多いと思います。Flash広告が嫌われる理由の一つですね。
この問題については、仮に広告掲載側がFlash広告での音声の再生を禁止しようとしても、基本的にはFlash広告の中身を提供する側との契約内容で制限し、それを信頼するしかありませんでした。
つまり、Flashは広告として利用するにはアプリの自由度が少し高すぎるという欠点があったわけです。
Microsoftはこの点に目をつけて、Silverlight広告を掲載するページのHTML側でSilverilghtアプリケーションの機能をきめ細かく制限する方法を提供し、Flash広告との差別化を図ろうとしたのではないでしょうか？
HTML側から機能制限が可能になれば、広告を掲載する側が、Silverlight広告が悪意を持ったコードを含んでいるかどうかを心配する必要性が多少は減りますし、広告を提供する側も、一つのSilverlight広告を、禁止内容が異なる複数のサイトで使いまわすことができます。
先ほども書いたように、現時点ではドキュメントやヘルプにaglimitについての記載がないので、ごにょごにょして調べてみたのですが、どうやら以下の文字列を指定可能のようです。内容については一通り確認してみましたが、一部推測が混じってますので、注意してください。
文字列は+で連結して複数指定が可能。
aglimit=audio+movie -> audioとmovieを同時指定
文字列の前に-をつけると禁止を無効にできる
aglimit=media-audio ->movieとimageは無効でaudioのみ有効
後ろのパラメータが優先
aglimit=movie+audio-movie ->audioと同じ
大文字小文字は無視される
aglimit=Audio -> aglimit=audioと同じ
TYPOは黙って無視される
aglimit=soket -> socketのTYPOだが何も起こらない
かなり細かい指定が可能なのが分かると思います。
・パラメータを一つでも有効にすると、アプリケーション側からのJavaScriptとDOM操作が禁止される。
これは、aglimitで制限を加えても、JavaScriptやDOM操作を可能にしてしまうと機能制限を解除されてしまうからじゃないかと思います。
・httpまたはnetを指定した場合に、Assembly Caching機能が使用できない。
Assembly Cachingは、Silverlight 3で追加された新機能で、拡張ライブラリである.slvx形式のファイルを実行時にWebサイトから読み込むことで、アプリケーション本体のサイズを縮小し、一度読み込んだ拡張ライブラリをキャッシュして複数のアプリケーションで使いまわす機能です。.slvx形式のファイルは、アセンブリと呼ばれる.dllファイルを含んでいるのが普通ですが、もし他のファイルを含んでいた場合、aglimitでhttpやnetを使って外部ファイルの読み込みを禁止しても回避できてしまいます。故にAssembly Cachingも禁止対象になったということだと思います。
・Sloob(SilverLight Out Of the Browserの略)化すると、aglimitが無効になる。
Sloob化したSilverlightアプリケーションには、<params>の内容を渡すことが元々できませんので、これはまあ仕方ないと思います。
・aglimit=audioは音声を完全に禁止できるが、aglimit=movieは動画を完全には禁止できない。
movieはMediaElementを使った動画ファイルや動画ストリームの再生を禁止する事はできますが、複数の画像ファイルの連続表示を使った擬似的な動画再生を禁止することはできません。
かといって、imageも追加指定すると普通の静止画像も禁止されてしまい、表現力が大幅に損なわれます。この辺りは難しいところですね。
・hwaccelはCPU利用率を上げてしまうことがある。
GPUを使ったハードウェアアクセラレーションが、ソフトウェアエミュレーションに切り替わるからです。hwaccelは、GPUの利用によってシステムの安定性が下がることが懸念されるケース、例えば同じページ内にGPUを酷使している物が他にある場合等に限るか、gpuを指定してソフトウェアによるエミュレーションも完全に禁止した方がいいかもしれません。
・aglimitではCPU使用率はそんなに下がらない。
aglimitによる機能制限は、net等を指定して通信エラーが発生するような場合を除けば、アプリケーション側からはaglimitの内容を確認しない限りaglimitによる制限を感知できないようです。
ですから、audioを指定して音声の再生を禁止すると、音は鳴りませんが、アプリケーションは音声を流したつもりになっています。
これはアプリケーションの開発者がaglimitの存在を気にせずにコードを書くことを可能にするためじゃないだろうか？と予想していますが、よく分かりません。
・<params>で指定するパラメータとしてaglimitが予約されたので、他の用途で使えなくなった。
これは可能性としては低いだろうと思いますが、もし既存のSilverlight 2アプリで独自にaglimitパラメータを使って何らかの処理をしていたアプリケーションはソースの修正が必要になります。
一見、いいことづくめに見えるaglimit機能ですが、一つ残念なことがあります。
それは、実際に閲覧するユーザ側ではaglimitの指定が簡単にはできないことです。
これについては、Silverlightの構成に「機能」のようなタブを追加して、limitで指定するのと同等の制限を与えられるといいのではないかと思います。
Silverlightの構成のタブについては、Silverlight 2の「アプリケーション記憶域」タブもBeta 2になってから、ようやく追加されたという前例がありますので、今後、正式リリースまでの間にタブが追加される可能性はありそうです。
以上、Silverlight 3で追加されたaglimitパラメータについて、ざっと説明してみました。尚、Silverlight 3はまだBeta 1ですので、正式リリースまでの間に仕様の大幅な変更があることも充分考えられますので、実際に試す際は注意してください。
ひょっとするとドキュメントやヘルプに記載がないのもそのせいかもしれません。(了)
●はじめに
先月発表された、Silverlight 3 Beta 1でちょっと面白い機能を見つけました。HTMLからSilverlight3アプリケーションを呼び出す時は、<object>タグを使用するのですが、その内部で、<params>タグを使って指定するパラメータにaglimitというパラメータが追加されているのです。
まずはサンプルを挙げてみます。
1: <object data="data:application/x-silverlight-2," type="application/x-silverlight-2">
2: <param name="minRuntimeVersion" value="3.0.40307.0" />
3: <param name="aglimit" value="audio+movie" />
4: ...
5: <object>
上記の value="audio+movie"の部分で、Silverlightアプリケーションでの動画や音声の再生が禁止されます。
ちなみに、agは銀の元素記号で、Silverlightを指しています。
Silverlight関連で、agを接頭辞に持つ名前が色々あるのはそのためです。（例：agcore.dll、AgDLR）
ついでですが、Silverlight 3 Beta 1で作成したアプリケーションを呼び出す<object>タグの使い方については、@matarilloさんの、「ユーザーがSilverlight 3ベータ版をインストールするときの挙動」が必読です。少なくともSilverlight 3アプリケーションを公開するかもしれない人は全員読むべきだと思います。
●なぜaglimitが追加されたのか？
Microsoft側としては、Silverlightの表現力を制限する機能であるaglimitをあまり大っぴらに宣伝したくないのか、MIX09でのSilverlight関連の発表でも触れられていないようですし、開発者向けのドキュメントやヘルプにもまだ記載がありません。
そのため、aglimitが追加された理由については、はっきりとは分からないのですが、個人的には、aglimitは「Silverlight広告」の推進の布石ではないだろうか？と予想をしています。
というのは、従来のFlash広告には、この手の機能を制限する仕組みがほとんどありません。
ですから、広告のあるページを開いただけでいきなり音が鳴ってビックリした経験をお持ちの方も多いと思います。Flash広告が嫌われる理由の一つですね。
この問題については、仮に広告掲載側がFlash広告での音声の再生を禁止しようとしても、基本的にはFlash広告の中身を提供する側との契約内容で制限し、それを信頼するしかありませんでした。
つまり、Flashは広告として利用するにはアプリの自由度が少し高すぎるという欠点があったわけです。
Microsoftはこの点に目をつけて、Silverlight広告を掲載するページのHTML側でSilverilghtアプリケーションの機能をきめ細かく制限する方法を提供し、Flash広告との差別化を図ろうとしたのではないでしょうか？
HTML側から機能制限が可能になれば、広告を掲載する側が、Silverlight広告が悪意を持ったコードを含んでいるかどうかを心配する必要性が多少は減りますし、広告を提供する側も、一つのSilverlight広告を、禁止内容が異なる複数のサイトで使いまわすことができます。
●aglimitの詳細
先ほども書いたように、現時点ではドキュメントやヘルプにaglimitについての記載がないので、ごにょごにょして調べてみたのですが、どうやら以下の文字列を指定可能のようです。内容については一通り確認してみましたが、一部推測が混じってますので、注意してください。
- audio - 音声再生の禁止
- movie - 動画再生の禁止
- media - audio+movie
- cookie - cookieの受信の禁止
- http - HTTP使用の禁止
- socket - ソケット使用の禁止
- link - URLリンクの禁止
- network - cookie+http+socket (linkは対象外)
- ps - ピクセルシェーダの禁止
- hwaccel - GPUを使ったハードウェアアクセラレーションの禁止
- gpu - ps+hwaccel
- is - 分離ストレージの使用の禁止
- fullscreen - 全画面モードの禁止
- all - 上記全てのオプションを有効
文字列は+で連結して複数指定が可能。
aglimit=audio+movie -> audioとmovieを同時指定
文字列の前に-をつけると禁止を無効にできる
aglimit=media-audio ->movieとimageは無効でaudioのみ有効
後ろのパラメータが優先
aglimit=movie+audio-movie ->audioと同じ
大文字小文字は無視される
aglimit=Audio -> aglimit=audioと同じ
TYPOは黙って無視される
aglimit=soket -> socketのTYPOだが何も起こらない
かなり細かい指定が可能なのが分かると思います。
●aglimitの使用上の注意点
・パラメータを一つでも有効にすると、アプリケーション側からのJavaScriptとDOM操作が禁止される。
これは、aglimitで制限を加えても、JavaScriptやDOM操作を可能にしてしまうと機能制限を解除されてしまうからじゃないかと思います。
・httpまたはnetを指定した場合に、Assembly Caching機能が使用できない。
Assembly Cachingは、Silverlight 3で追加された新機能で、拡張ライブラリである.slvx形式のファイルを実行時にWebサイトから読み込むことで、アプリケーション本体のサイズを縮小し、一度読み込んだ拡張ライブラリをキャッシュして複数のアプリケーションで使いまわす機能です。.slvx形式のファイルは、アセンブリと呼ばれる.dllファイルを含んでいるのが普通ですが、もし他のファイルを含んでいた場合、aglimitでhttpやnetを使って外部ファイルの読み込みを禁止しても回避できてしまいます。故にAssembly Cachingも禁止対象になったということだと思います。
・Sloob(SilverLight Out Of the Browserの略)化すると、aglimitが無効になる。
Sloob化したSilverlightアプリケーションには、<params>の内容を渡すことが元々できませんので、これはまあ仕方ないと思います。
・aglimit=audioは音声を完全に禁止できるが、aglimit=movieは動画を完全には禁止できない。
movieはMediaElementを使った動画ファイルや動画ストリームの再生を禁止する事はできますが、複数の画像ファイルの連続表示を使った擬似的な動画再生を禁止することはできません。
かといって、imageも追加指定すると普通の静止画像も禁止されてしまい、表現力が大幅に損なわれます。この辺りは難しいところですね。
・hwaccelはCPU利用率を上げてしまうことがある。
GPUを使ったハードウェアアクセラレーションが、ソフトウェアエミュレーションに切り替わるからです。hwaccelは、GPUの利用によってシステムの安定性が下がることが懸念されるケース、例えば同じページ内にGPUを酷使している物が他にある場合等に限るか、gpuを指定してソフトウェアによるエミュレーションも完全に禁止した方がいいかもしれません。
・aglimitではCPU使用率はそんなに下がらない。
aglimitによる機能制限は、net等を指定して通信エラーが発生するような場合を除けば、アプリケーション側からはaglimitの内容を確認しない限りaglimitによる制限を感知できないようです。
ですから、audioを指定して音声の再生を禁止すると、音は鳴りませんが、アプリケーションは音声を流したつもりになっています。
これはアプリケーションの開発者がaglimitの存在を気にせずにコードを書くことを可能にするためじゃないだろうか？と予想していますが、よく分かりません。
・<params>で指定するパラメータとしてaglimitが予約されたので、他の用途で使えなくなった。
これは可能性としては低いだろうと思いますが、もし既存のSilverlight 2アプリで独自にaglimitパラメータを使って何らかの処理をしていたアプリケーションはソースの修正が必要になります。
●aglimit機能への要望
一見、いいことづくめに見えるaglimit機能ですが、一つ残念なことがあります。
それは、実際に閲覧するユーザ側ではaglimitの指定が簡単にはできないことです。
これについては、Silverlightの構成に「機能」のようなタブを追加して、limitで指定するのと同等の制限を与えられるといいのではないかと思います。
Silverlightの構成のタブについては、Silverlight 2の「アプリケーション記憶域」タブもBeta 2になってから、ようやく追加されたという前例がありますので、今後、正式リリースまでの間にタブが追加される可能性はありそうです。
●最後に
以上、Silverlight 3で追加されたaglimitパラメータについて、ざっと説明してみました。尚、Silverlight 3はまだBeta 1ですので、正式リリースまでの間に仕様の大幅な変更があることも充分考えられますので、実際に試す際は注意してください。
ひょっとするとドキュメントやヘルプに記載がないのもそのせいかもしれません。(了)
2009年3月23日月曜日
Silverlight 3 Beta 1で (H.264/AAC).mp4 の再生を試す簡単なやり方
先日、Microsoftから発表された、Silverlight 3 Beta 1（以下、SL3Beta1）の新機能の一つが、映像コーデックにH.264、音声コーデックにAAC、コンテナフォーマットにISO Base Mediaファイルフォーマット（ISO/IEC 14496-12）を使った動画ファイル(以下、(H.264/AAC).mp4)の再生機能です。
しかし、SL3Beta1は開発者向けのβ版なので、一般ユーザ向けのβ版のランタイム、つまりSL3Beta1のWebブラウザ用プラグインは配布されていませんし、今のところ、Silverlight 3が正式リリースされる前に、一般ユーザ向けにランタイムを配布する予定はないとのことです。
また、SL3Beta1のライセンス条項に従えば、Microsoft社と別途契約して許諾を得ない限り、公開されたWebサイト上でテストすることもできません。
ただ、開発者がPC上のローカルな環境でテストすることまでは、さすがに禁止されてはいないので、自分ではアプリを作成できないが、どうしても試してみたい方は
JW WMV Player以外のSilverlight版のビデオ再生アプリとしては、Tim Heuer氏のSilverlight 2 Video Playerがありますが、こちらでも同様の手順で再生可能です。
なお、WebブラウザとしてFirefoxやChromeを使用している場合、ローカルなHTMLファイルのパスに日本語(例：デスクトップ)が含まれていると、Silverlightアプリケーションが実行できなくなりますので注意してください。
IEであればパスに日本語が含まれていても問題ありませんでした。恐らく、URLのエンコーディング絡みの問題だと思います。
Silverlight側とWebブラウザ側のどちらの問題か？については、あえてコメントしませんのであしからずw
それから、再生に必要な(H.264/AAC).mp4な動画ファイルの入手方法ですが、Microsoft社が推奨しているのは、Microsoft Expressio Encoder 2（試用版もあります）にExpression Encoder 2 Service Pack 1を適用し、エンコード機能を使って(H.264/AAC).mp4な動画ファイルを作成する方法です。
そういうのは面倒くさいけど高解像度の動画の再生をちょっと試してみたいなーという方は、Apple - QuickTime - HD Gallerryからファイルを入手するのが一番手っ取り早くてオススメです。
「Silverlight 3向けの動画ファイルとしてAppleのサンプルファイルを紹介するのはけしからん！」とおっしゃる方もいらっしゃるでしょうが、Microsoftの高精細コンテンツ ショーケースにはWMV HDなファイルしかないので仕方がありません。というかどうにかしてください＞中の人
具体的には、適当な映像を選択してから、HTMLのソースを表示して、拡張子が.movになっているURLを探し、QuickTime Plug-inアドオンを停止（そうしないとブラウザ内で再生が始まってしまうので）した状態でWebブラウザのアドレスバーに入力するか、ダウンロード用のツールか何かを使ってダウンロードしてください。
ここで公開されているファイルは、(H.264/AAC).movなQuickTime形式のファイルですが、QuickTimeのファイルフォーマットは、ISO Base Mediaファイルフォーマットのベースになっている関係で、Silverlight3でも一応再生ができます。他に、iPod向けの(H.264/AAC).movなファイルをいくつか試してみましたが、今のところ問題ないようです。
もし、上記のサイトでダウンロードしたファイルのサイズが数十バイトだった場合、それはWindows MediaのASXファイルに相当する、QuickTime Metafileという形式のメタファイルですので、メモ帳やテキストエディットで中身を開いて、実体のファイル名を探してダウンロードし直してください。
以上の手順で私も実際に試してみましたが、Silverlight 3の発表時にポイントとして挙げられていた、「GPUによる動画の再生支援」については、全画面化やサイズ変更等のスケーリングがメインで、GPUにH.264デコードをさせるようなことはしていないことがCPUの負荷から確認できました。
ただ、これについては昨年9月の時点で、MS本社のAlex Zambelli氏がDXVAを使ったハードウェアアクセラレーションはサポートしないよと非公式に発言しているので、予想の範疇です。
その他、QuickTime Plug-Inとの挙動の違いとしては、
最後に、何故 Silverlight 2用のアプリでSilverlight 3の新機能である(H.264/AAC).mp4が再生できるのか？という疑問を持った方もいらっしゃると思いますが、Silverlight 3 Beta 1 ランタイムは、<param>タグのminRuntimeVersionも、AppManifest.xamlのRuntimeVersionも無視して、新機能が常に使える状態になっているからというのが、現時点での予想です。
この件については、気が向いたら 項を改めてまた書いてみたいと思います。(了)
しかし、SL3Beta1は開発者向けのβ版なので、一般ユーザ向けのβ版のランタイム、つまりSL3Beta1のWebブラウザ用プラグインは配布されていませんし、今のところ、Silverlight 3が正式リリースされる前に、一般ユーザ向けにランタイムを配布する予定はないとのことです。
また、SL3Beta1のライセンス条項に従えば、Microsoft社と別途契約して許諾を得ない限り、公開されたWebサイト上でテストすることもできません。
ただ、開発者がPC上のローカルな環境でテストすることまでは、さすがに禁止されてはいないので、自分ではアプリを作成できないが、どうしても試してみたい方は
- JW WMV Playerをダウンロードして展開する
- 展開したフォルダに、(H.264/AAC).mp4な動画ファイルを置く
- サンプルのHTMLファイル(readme.html)を参考に、動画ファイル名とサイズの指定を書き換える
JW WMV Player以外のSilverlight版のビデオ再生アプリとしては、Tim Heuer氏のSilverlight 2 Video Playerがありますが、こちらでも同様の手順で再生可能です。
なお、WebブラウザとしてFirefoxやChromeを使用している場合、ローカルなHTMLファイルのパスに日本語(例：デスクトップ)が含まれていると、Silverlightアプリケーションが実行できなくなりますので注意してください。
IEであればパスに日本語が含まれていても問題ありませんでした。恐らく、URLのエンコーディング絡みの問題だと思います。
Silverlight側とWebブラウザ側のどちらの問題か？については、あえてコメントしませんのであしからずw
それから、再生に必要な(H.264/AAC).mp4な動画ファイルの入手方法ですが、Microsoft社が推奨しているのは、Microsoft Expressio Encoder 2（試用版もあります）にExpression Encoder 2 Service Pack 1を適用し、エンコード機能を使って(H.264/AAC).mp4な動画ファイルを作成する方法です。
そういうのは面倒くさいけど高解像度の動画の再生をちょっと試してみたいなーという方は、Apple - QuickTime - HD Gallerryからファイルを入手するのが一番手っ取り早くてオススメです。
「Silverlight 3向けの動画ファイルとしてAppleのサンプルファイルを紹介するのはけしからん！」とおっしゃる方もいらっしゃるでしょうが、Microsoftの高精細コンテンツ ショーケースにはWMV HDなファイルしかないので仕方がありません。というかどうにかしてください＞中の人
具体的には、適当な映像を選択してから、HTMLのソースを表示して、拡張子が.movになっているURLを探し、QuickTime Plug-inアドオンを停止（そうしないとブラウザ内で再生が始まってしまうので）した状態でWebブラウザのアドレスバーに入力するか、ダウンロード用のツールか何かを使ってダウンロードしてください。
ここで公開されているファイルは、(H.264/AAC).movなQuickTime形式のファイルですが、QuickTimeのファイルフォーマットは、ISO Base Mediaファイルフォーマットのベースになっている関係で、Silverlight3でも一応再生ができます。他に、iPod向けの(H.264/AAC).movなファイルをいくつか試してみましたが、今のところ問題ないようです。
もし、上記のサイトでダウンロードしたファイルのサイズが数十バイトだった場合、それはWindows MediaのASXファイルに相当する、QuickTime Metafileという形式のメタファイルですので、メモ帳やテキストエディットで中身を開いて、実体のファイル名を探してダウンロードし直してください。
以上の手順で私も実際に試してみましたが、Silverlight 3の発表時にポイントとして挙げられていた、「GPUによる動画の再生支援」については、全画面化やサイズ変更等のスケーリングがメインで、GPUにH.264デコードをさせるようなことはしていないことがCPUの負荷から確認できました。
ただ、これについては昨年9月の時点で、MS本社のAlex Zambelli氏がDXVAを使ったハードウェアアクセラレーションはサポートしないよと非公式に発言しているので、予想の範疇です。
その他、QuickTime Plug-Inとの挙動の違いとしては、
- (QuickTime形式ではない)同じ動画ファイルをQuickTime Plug-InとSilverlight 3 Beta 1で再生すると色味が多少違う
- 再生品質がキープできない程高解像度の映像だった場合に、QuickTime Playerはフレームを間引くが、Silverlight3は画面が固まって音が途切れる
- ビットレートが高い映像をhttp経由で再生した場合に、再生バッファは十分溜まっているのに画面が1秒程度固まることがたまにある。
最後に、何故 Silverlight 2用のアプリでSilverlight 3の新機能である(H.264/AAC).mp4が再生できるのか？という疑問を持った方もいらっしゃると思いますが、Silverlight 3 Beta 1 ランタイムは、<param>タグのminRuntimeVersionも、AppManifest.xamlのRuntimeVersionも無視して、新機能が常に使える状態になっているからというのが、現時点での予想です。
この件については、気が向いたら 項を改めてまた書いてみたいと思います。(了)
2009年2月23日月曜日
あまり奇をてらった言葉をBlogのタイトルに使うべきではない（かもしれない）という話
先ほど、id:shi3zさんの、『テレビ朝日から「つれづれ～というブログタイトルが多いという客観的な証拠を今日中に示せ」と言われた』 from Keep Crazy;shi3zの日記 を読んで、自分のBlogタイトル名でGoogleブログ検索を試してみたら、あまり奇をてらった言葉をBlogのタイトルに使うべきではない（かもしれない）という面白い結果になりました。
一目瞭然ですね。Blogのタイトルに "っき雑記" を指定して検索すると検索結果が0件になります。
私は検索エンジンの仕組みはよく知らないので理由は分かりませんが、ひょっとすると、Googleブログ検索は「っ」で始まるBlogのタイトルをBlogのタイトルとしては扱わないようにしているのかもしれません。
私は、id:shi3zさんの
「人の記憶に残っても「つれづれ」などのありふれた言葉をタイトルに使っていると、検索して見つけてもらえる可能性が低くなってしまうのでタイトルとして採用するべきではない」
という主張はおっしゃる通りだろうと思っていますが、あまり奇をてらった言葉にするのも考えもののようですね。
ちなみに「っき」というのは私が使っているハンドルネームで、昔、アーケードゲームのスコアネームにアルファベット3文字しか使えなかった時代に使っていた"KKI"をローマ字読みしたものです。
SEO上不利(笑)なのかもしれませんが、それなりに愛着もありますのでタイトルはこのままにしておこうと思います。
2009年1月9日金曜日
「空から女の子が降ってきたらどうすればいいのか？」を電話なんでも相談室に相談してみた
先日、Twitterで「今時、空から女の子が降ってきたくらいで困惑する読者はいないよね」とつぶやいたあとで、実際にそんなことがあったらどうするのか何も考えてなかったことに気がついたので、せっかくだから市内にある『電話なんでも相談室』に質問してみることにした。電話をかけると、親切そうな感じのおじさんの相談員の人に繋がった。
相談員のおじさん（以下、お）「お待たせしました。えーと、質問内容は『空から女の子が降ってきたらどうすればいいでしょうか？』ですね？」
私「はい」
お「うーん、それはとても危ないですね。」
私「え？ 危ないんですか？」
お「はい、ですからその場合は周りに気をつけながら、すぐに地面に伏せて、じっと降ってくるのを待っててください。」
私「えーと、逃げなくていいんでしょうか？」
お「はい、逃げるより地面に伏せる方が安全です。もしまだ遠くに見えても、必ず逃げずに伏せてください。」
私「遠くでも伏せるんですか？」
お「はい、遠くでも伏せてください。降ってくるのは女の子なんですよね？」
私「え？ あ、はい」
お「降ってくるのが女の子だと分かるのであれば、地面に落ちるまで時間の余裕はありません。」
私「はあ、なるほど」
お「それに、遠くに見えても、空に浮いてる物の大きさは分かりにくいので、実は案外近いことがあります。迷ったりしてる暇はありませんから、見かけたらすぐ地面に伏せてくださいね。」
私「は、はい」
お「それから地面に伏せる時はうつ伏せで、両足を揃えてピンと伸ばして、頭を抱えて、かかとを寝かせるようにしてください」
私「？ かかとを寝かせるんですか？」
お「はい、かかとを寝かせてください。そうすると女の子に発見されにくくなります。」
私「え？ 発見されちゃダメなんですか？」
お「はい、発見されちゃダメです。空から降ってくるような女の子に発見されてはいけません。」
私「はあ」
お「回答内容は以上です。これでよろしいでしょうか？」
私「え？ あ、はい」
お「ご利用ありがとうございました。」
電話はこれで終わったが、空から女の子が降ってきた後、うつ伏せで頭を抱えて両足を揃えてピンと伸ばし、かかとを寝かせて地面に伏せた状態の私は一体どうすればいいのか？という肝心な事を聞き忘れたことに気がついた。
今は、もう一度同じ電話番号に電話をかけてみるべきなのかどうかを真剣に悩んでいる。(了)
以上、降臨賞(はてなIDが無いので)非公式応募作品。
相談員のおじさん（以下、お）「お待たせしました。えーと、質問内容は『空から女の子が降ってきたらどうすればいいでしょうか？』ですね？」
私「はい」
お「うーん、それはとても危ないですね。」
私「え？ 危ないんですか？」
お「はい、ですからその場合は周りに気をつけながら、すぐに地面に伏せて、じっと降ってくるのを待っててください。」
私「えーと、逃げなくていいんでしょうか？」
お「はい、逃げるより地面に伏せる方が安全です。もしまだ遠くに見えても、必ず逃げずに伏せてください。」
私「遠くでも伏せるんですか？」
お「はい、遠くでも伏せてください。降ってくるのは女の子なんですよね？」
私「え？ あ、はい」
お「降ってくるのが女の子だと分かるのであれば、地面に落ちるまで時間の余裕はありません。」
私「はあ、なるほど」
お「それに、遠くに見えても、空に浮いてる物の大きさは分かりにくいので、実は案外近いことがあります。迷ったりしてる暇はありませんから、見かけたらすぐ地面に伏せてくださいね。」
私「は、はい」
お「それから地面に伏せる時はうつ伏せで、両足を揃えてピンと伸ばして、頭を抱えて、かかとを寝かせるようにしてください」
私「？ かかとを寝かせるんですか？」
お「はい、かかとを寝かせてください。そうすると女の子に発見されにくくなります。」
私「え？ 発見されちゃダメなんですか？」
お「はい、発見されちゃダメです。空から降ってくるような女の子に発見されてはいけません。」
私「はあ」
お「回答内容は以上です。これでよろしいでしょうか？」
私「え？ あ、はい」
お「ご利用ありがとうございました。」
電話はこれで終わったが、空から女の子が降ってきた後、うつ伏せで頭を抱えて両足を揃えてピンと伸ばし、かかとを寝かせて地面に伏せた状態の私は一体どうすればいいのか？という肝心な事を聞き忘れたことに気がついた。
今は、もう一度同じ電話番号に電話をかけてみるべきなのかどうかを真剣に悩んでいる。(了)
以上、降臨賞(はてなIDが無いので)非公式応募作品。
2008年12月13日土曜日
LHa for Native Client (本編)
【警告】タイトルだけ見るとNative ClientでLHaが普通に動くように見えますが、実際には実用には堪えませんので、誤解のないようお願い致します。
（このエントリーは「LHa for Native Client (準備編)」の続きです。）
Native Clientの発表から、もうかなり経ちますので話題の旬はとっくに過ぎてしまったのですが、今回は実際にLHa for Native Clientを実行するところまで、何とか話を進めてみたいと思います。
ただし、LHa for Native Clientは、現時点でNative Clientがサポートしている3種類のOSの内、Mac OS XとLinuxで実行できることは確認しているのですが、Windowsでは今のところ実行に成功していません。
その理由を説明するには、そもそもNative Clientで何ができて、何ができないのか？を先に説明する必要があります。
当初はWindows版でも普通に動くだろうと思っていたので、これは誤算でした。
もう一つの誤算は、Native Clientが三日で飽きられてしまったためにx86ネイティブコードのsandbox以外の話を日本語で説明してくれるエントリに丸投げすることが出来なかったことです。
そのため、エントリがやたらと長くなってしまいましたが、どうか最後までおつきあいください。m(__)m
インブラウザモードとスタンダローンモード
Native Client上で動作する実行コード、これをGoogleはNatie Client moduleと呼んでいますので、以下では単にmoduleと呼ぶことにしますが、moduleには2種類の実行方法があります。
一つは、WebブラウザのNative Clientプラグイン上で実行する方法で、もう一つは、sel_ldrというローダを使うことで、単一のアプリケーションとして実行する方法です。
Googleは、この2種類の実行方法については、今のところ特に用語を命名してはいないようですので、ここでは仮にインブラウザモードとスタンダローンモードと呼ぶことにします。
moduleがスタンダローンモードとインブラウザモードの両方で実行可能な場合、moduleの実体である .nexeファイルは同じファイルで構いません。
基本的には同じ .nexeファイルが、Mac OS X、Linux、WindowsのどのOSでも動作します。
moduleの実行にはgccは不要
「GCCベースのコンパイラを含んだブラウザ用プラグインの形で提供され」と書いてある紹介記事を読んだために誤解している方がいらっしゃるようなので繰り返しますが、Native Clientは同一の.nexeファイルを複数のOSで実行可能なので、実行時にコンパイルは必要ありません。
Native Clientのパッケージに含まれているgccは、moduleのビルドに使われるだけです。
尚、moduleの実行環境及び開発環境そのもののビルドには、それぞれのOS向けの開発環境が別途必要になりますが、各OS向けのNative Clientパッケージはビルド済みの実行環境及び開発環境を含んでいますので、moduleをビルドして実行するだけであれば、実行環境や開発環境のビルドは不要になっています。
それから、Native Clientの実行条件として、Pythonが挙げられていますが、PythonはSconsというNative Clientの付属ツールや、スタンダローンモードのサンプルでsel_ldrを起動する際の補助に必要とされているだけで、Native Client moduleのビルドや実行に必須という訳ではないようです。
Native Client moduleの正体
正体という単語に期待した人には申し訳ないのですが、moduleの正体は、単に32-bit LSBなELF形式の実行ファイルです。
sandboxの実現のためにmoduleのビルドの際に実行コードに手を加えてはいますが、仕組み上、ELFのABIに違反するようなことはしていないはず（ここは自信なし、特にret）なので、moduleの実行をgdbで追いかけることもできるそうです。
しかし、Mac OS XのアプリケーションはMach-OというELFとは異なる形式で、付属のgdbもMach-O形式にしか対応していませんので、仮想OS上でLinuxを起動して、Linux上のgdbを使うのが無難だと思います。
それから、x86ネイティブコードのsandboxについては、id:amachangさん、omoさん、id:yaneuraoさんの各エントリに詳細が書いてありますので、そちらを参照することを強くオススメします。
Native Clientにできること
Native Clientは、newlibが提供する標準Cライブラリ、pthread、libSDLを使った音声と映像の出力機能の一部、NPAPIによるWebブラウザホストとの通信、IMCによるNative Client module同士の通信等が可能です。
スタンダローンモードではホストになるWebブラウザが無いためにNPAPIを使えませんが、実行時にAPIを呼び出した時点でエラーが返るだけなので、場合分けで処理を切り替えることも可能になっています。
スタンダローンモードで複数のmoduleを同時に実行してIMCで通信できるかどうかはちょっと分からないのですが、（私には難しそうですが）いつか試してみたいと思います。
映像出力と音声出力の仕様については、映像はRGBA各16ビットのフレームバッファになっています。フルスクリーンモードはありません。
「フレームバッファのハンドルはやるから好きにしろ、後は知らん」という感じですね。
音声は、44.1KHzまたは48KHzでステレオ、16ビットのリニアPCMを出力可能ですが、ヘッダのコメントによるとまだ多重再生はできないとのことなので、音声のMIXは自前で行う必要があります。
Native Clientにできないこと
Native Clientはまだバージョンが0.1ということもあって、使えるライブラリがほとんどありません。
GUIコンポーネントの表示どころか、基本的な描画ライブラリもなく、フォント、文字列エンコーディングの変換、画像、音声、動画のデコーダ等は全て自前で何とかする必要があります。
moduleは先に説明したようにELF形式なので、リンクできるライブラリもELF形式に限定され、Native Client向けにビルドしたライブラリである必要があります。
動的リンクはできないので、静的リンクのみです。
ですから、もしNative Clientで、例えばMac OS XのOpenGLライブラリを使用したいのであれば、実行環境をビルドする時にリンクして、moduleから利用するためのAPIを追加しなければいけません。しかし、それは実行環境の独自ビルドになるので、実行環境も一緒に配布しない限り、他の人のNative Client環境では実行できません。
結局、OpenGLやOpenCLについては、Googleが対応しない限りどうにもならないという事です。
Googleの今後の予定については何ともいえませんが、OpenGLやOpenCLを使えるようにするとセキュリティ上の安全性や安定性がOS側のドライバ頼みになってしまうので、見込みが薄いんじゃないかなーと個人的には思っています。あくまで個人的意見ですのであしからず。
ファイルI/Oの制限
ファイルI/Oについては、GoogleのTechnical Paperを読むと、ファイルI/OとしてPOSIX標準ファイルI/Oを利用可能だが、インブラウザモードの場合は、Web上のコンテンツの読み込みに用いられ、ファイル出力はできず、statはファイルサイズしか取れないと書いてあります。
これはHTTPではディレクトリ上のファイルの一覧を普通は取れないことを考えれば当然の仕様だと思います。
スタンダローンモードでもインブラウザモードの上記の制限を受けるために、クライアントPCのローカルファイルへのアクセスは基本的にできません。
（Native Clientがローカルファイルへのアクセスが自由に可能と説明している文章もあるようですが、それは何かの誤解だと思います。）
しかし、LHaはファイルの圧縮と圧縮を実行するツールなので、ローカルファイルにアクセスできないと意味がありません。
そこで、今回は、Native Clientに一つだけ用意されている抜け道を利用することにしました。スタンダローンモードのデバッグモードです。
デバッグモード
デバッグモードはsel_ldrに-dというオプションをつけて実行することで有効になるモードですが、このモードを使うとPOSIX標準ファイルI/Oでローカルファイルにアクセスすることが可能になります。
デバッグモードでもディレクトリエントリに対する操作はほとんど出来ませんが、ログ出力のために新規にファイルを作成したりバイナリファイルの読み書きを行う程度であれば何とかなります。
しかし、Windows版のNative Clientだけ、何故かsel_ldrでデバッグモードを有効にできません。
各OSで、スタンダローンモードでearthサンプルを実行してみた方は気づいたと思いますが、Windowsの場合だけフレーム数の表示がないことから、標準出力もできないようです。
これが、最初にWindowsでは動作しないと書いた理由です。
LHaの移植
今回のLHaの移植は、デバッグモードを利用しつつ、ディレクトリエントリが絡んだ部分を誤魔化す事で実現しています。
具体的には、Mac OS X上で普通に./configureを実行してconfig.hを作成した後で、nacl-gccでコンパイルした時にどのヘッダが足りないかを確認しながら、config.hの中身を適宜修正し、nacl-gccのリンカでエラーが出る関数をdummy.cというファイルででっちあげるという方法を取りました。
あくまで誤魔化しただけなので、ディレクトリ構造を持ったLZHファイルの作成や展開では問題が多々ありますし、実行権、シンボリックリンク、タイムスタンプ等も無視されます。最初に警告として実用には堪えないと書いたのはそのためです。
Makefileの流用も検討はしたのですが、結局、nacl_build.shというシェルスクリプトを用意しました。
結果的に出来上がったの以下のパッチとバイナリ
lha4nacl.patch
lha.nexe
をlha4nacl.tar.gzというファイルにしておきました。
ビルド方法としては、Mac OS Xの場合、LHa for UNIXのソースを展開してから、上記のファイルも展開し、
$ patch -p1 <lha4nacl.patch
(nacl_build.sh 内のNACLINSTALLPATHを適宜修正）
$ ./nacl_build.sh
と実行すれば、src/lha.nexeが作成されるはずです。
lha4nacl.patchを読めば分かりますが、元のソースには一切手を加えていません。移植性を考慮したコンソールアプリのソースなら、機能制限に目をつぶれば元ソースに手を加えなくてもそこそこ動いてしまうのがNaClの面白いところだと思います。
以上、駆け足で説明しましたが、抜けているところは適宜修正していきたいと思います。
もし、何かありましたら、メールまたはKKI@Twitter等にご連絡ください。
おつきあいありがとうございました。m(__)m
【蛇足】"Native"な"Client module"
Native Clientの登場直後から、Native ClientはGoogleのOSになるのではないか？という意見を見かけますが、私はそうは思いませんでした。
というのは、GoogleがNative ClientのバイナリをNative Client Applicationではなく、Native Client moduleと一貫して呼称しているからです。
Native Clientのパッケージの階層は、nacl/google_client/nativeclient となっていますが、Native Client moduleは、"Native Client"の"module"ではなく、Google Clientの"Native"な"Client module"なのではないでしょうか？
つまり、Native Client moduleはあくまで、NativeではないClient moduleと共にGoogle Clientを構成するmoduleの一つであり、最終的には単体のアプリケーションとして動作させる利用方法は減っていくのではないか？ということです。
Google Clientがどのような物かはまだ分かりませんが 将来的には、例えばGoogle DocumentのエンジンがNative Client moduleになったりするのではないかと私は考えています。
（このエントリーは「LHa for Native Client (準備編)」の続きです。）
Native Clientの発表から、もうかなり経ちますので話題の旬はとっくに過ぎてしまったのですが、今回は実際にLHa for Native Clientを実行するところまで、何とか話を進めてみたいと思います。
ただし、LHa for Native Clientは、現時点でNative Clientがサポートしている3種類のOSの内、Mac OS XとLinuxで実行できることは確認しているのですが、Windowsでは今のところ実行に成功していません。
その理由を説明するには、そもそもNative Clientで何ができて、何ができないのか？を先に説明する必要があります。
当初はWindows版でも普通に動くだろうと思っていたので、これは誤算でした。
もう一つの誤算は、Native Clientが三日で飽きられてしまったためにx86ネイティブコードのsandbox以外の話を日本語で説明してくれるエントリに丸投げすることが出来なかったことです。
そのため、エントリがやたらと長くなってしまいましたが、どうか最後までおつきあいください。m(__)m
インブラウザモードとスタンダローンモード
Native Client上で動作する実行コード、これをGoogleはNatie Client moduleと呼んでいますので、以下では単にmoduleと呼ぶことにしますが、moduleには2種類の実行方法があります。
一つは、WebブラウザのNative Clientプラグイン上で実行する方法で、もう一つは、sel_ldrというローダを使うことで、単一のアプリケーションとして実行する方法です。
Googleは、この2種類の実行方法については、今のところ特に用語を命名してはいないようですので、ここでは仮にインブラウザモードとスタンダローンモードと呼ぶことにします。
moduleがスタンダローンモードとインブラウザモードの両方で実行可能な場合、moduleの実体である .nexeファイルは同じファイルで構いません。
基本的には同じ .nexeファイルが、Mac OS X、Linux、WindowsのどのOSでも動作します。
moduleの実行にはgccは不要
「GCCベースのコンパイラを含んだブラウザ用プラグインの形で提供され」と書いてある紹介記事を読んだために誤解している方がいらっしゃるようなので繰り返しますが、Native Clientは同一の.nexeファイルを複数のOSで実行可能なので、実行時にコンパイルは必要ありません。
Native Clientのパッケージに含まれているgccは、moduleのビルドに使われるだけです。
尚、moduleの実行環境及び開発環境そのもののビルドには、それぞれのOS向けの開発環境が別途必要になりますが、各OS向けのNative Clientパッケージはビルド済みの実行環境及び開発環境を含んでいますので、moduleをビルドして実行するだけであれば、実行環境や開発環境のビルドは不要になっています。
それから、Native Clientの実行条件として、Pythonが挙げられていますが、PythonはSconsというNative Clientの付属ツールや、スタンダローンモードのサンプルでsel_ldrを起動する際の補助に必要とされているだけで、Native Client moduleのビルドや実行に必須という訳ではないようです。
Native Client moduleの正体
正体という単語に期待した人には申し訳ないのですが、moduleの正体は、単に32-bit LSBなELF形式の実行ファイルです。
sandboxの実現のためにmoduleのビルドの際に実行コードに手を加えてはいますが、仕組み上、ELFのABIに違反するようなことはしていないはず（ここは自信なし、特にret）なので、moduleの実行をgdbで追いかけることもできるそうです。
しかし、Mac OS XのアプリケーションはMach-OというELFとは異なる形式で、付属のgdbもMach-O形式にしか対応していませんので、仮想OS上でLinuxを起動して、Linux上のgdbを使うのが無難だと思います。
それから、x86ネイティブコードのsandboxについては、id:amachangさん、omoさん、id:yaneuraoさんの各エントリに詳細が書いてありますので、そちらを参照することを強くオススメします。
Native Clientにできること
Native Clientは、newlibが提供する標準Cライブラリ、pthread、libSDLを使った音声と映像の出力機能の一部、NPAPIによるWebブラウザホストとの通信、IMCによるNative Client module同士の通信等が可能です。
スタンダローンモードではホストになるWebブラウザが無いためにNPAPIを使えませんが、実行時にAPIを呼び出した時点でエラーが返るだけなので、場合分けで処理を切り替えることも可能になっています。
スタンダローンモードで複数のmoduleを同時に実行してIMCで通信できるかどうかはちょっと分からないのですが、（私には難しそうですが）いつか試してみたいと思います。
映像出力と音声出力の仕様については、映像はRGBA各16ビットのフレームバッファになっています。フルスクリーンモードはありません。
「フレームバッファのハンドルはやるから好きにしろ、後は知らん」という感じですね。
音声は、44.1KHzまたは48KHzでステレオ、16ビットのリニアPCMを出力可能ですが、ヘッダのコメントによるとまだ多重再生はできないとのことなので、音声のMIXは自前で行う必要があります。
Native Clientにできないこと
Native Clientはまだバージョンが0.1ということもあって、使えるライブラリがほとんどありません。
GUIコンポーネントの表示どころか、基本的な描画ライブラリもなく、フォント、文字列エンコーディングの変換、画像、音声、動画のデコーダ等は全て自前で何とかする必要があります。
moduleは先に説明したようにELF形式なので、リンクできるライブラリもELF形式に限定され、Native Client向けにビルドしたライブラリである必要があります。
動的リンクはできないので、静的リンクのみです。
ですから、もしNative Clientで、例えばMac OS XのOpenGLライブラリを使用したいのであれば、実行環境をビルドする時にリンクして、moduleから利用するためのAPIを追加しなければいけません。しかし、それは実行環境の独自ビルドになるので、実行環境も一緒に配布しない限り、他の人のNative Client環境では実行できません。
結局、OpenGLやOpenCLについては、Googleが対応しない限りどうにもならないという事です。
Googleの今後の予定については何ともいえませんが、OpenGLやOpenCLを使えるようにするとセキュリティ上の安全性や安定性がOS側のドライバ頼みになってしまうので、見込みが薄いんじゃないかなーと個人的には思っています。あくまで個人的意見ですのであしからず。
ファイルI/Oの制限
ファイルI/Oについては、GoogleのTechnical Paperを読むと、ファイルI/OとしてPOSIX標準ファイルI/Oを利用可能だが、インブラウザモードの場合は、Web上のコンテンツの読み込みに用いられ、ファイル出力はできず、statはファイルサイズしか取れないと書いてあります。
これはHTTPではディレクトリ上のファイルの一覧を普通は取れないことを考えれば当然の仕様だと思います。
スタンダローンモードでもインブラウザモードの上記の制限を受けるために、クライアントPCのローカルファイルへのアクセスは基本的にできません。
（Native Clientがローカルファイルへのアクセスが自由に可能と説明している文章もあるようですが、それは何かの誤解だと思います。）
しかし、LHaはファイルの圧縮と圧縮を実行するツールなので、ローカルファイルにアクセスできないと意味がありません。
そこで、今回は、Native Clientに一つだけ用意されている抜け道を利用することにしました。スタンダローンモードのデバッグモードです。
デバッグモード
デバッグモードはsel_ldrに-dというオプションをつけて実行することで有効になるモードですが、このモードを使うとPOSIX標準ファイルI/Oでローカルファイルにアクセスすることが可能になります。
デバッグモードでもディレクトリエントリに対する操作はほとんど出来ませんが、ログ出力のために新規にファイルを作成したりバイナリファイルの読み書きを行う程度であれば何とかなります。
しかし、Windows版のNative Clientだけ、何故かsel_ldrでデバッグモードを有効にできません。
各OSで、スタンダローンモードでearthサンプルを実行してみた方は気づいたと思いますが、Windowsの場合だけフレーム数の表示がないことから、標準出力もできないようです。
これが、最初にWindowsでは動作しないと書いた理由です。
LHaの移植
今回のLHaの移植は、デバッグモードを利用しつつ、ディレクトリエントリが絡んだ部分を誤魔化す事で実現しています。
具体的には、Mac OS X上で普通に./configureを実行してconfig.hを作成した後で、nacl-gccでコンパイルした時にどのヘッダが足りないかを確認しながら、config.hの中身を適宜修正し、nacl-gccのリンカでエラーが出る関数をdummy.cというファイルででっちあげるという方法を取りました。
あくまで誤魔化しただけなので、ディレクトリ構造を持ったLZHファイルの作成や展開では問題が多々ありますし、実行権、シンボリックリンク、タイムスタンプ等も無視されます。最初に警告として実用には堪えないと書いたのはそのためです。
Makefileの流用も検討はしたのですが、結局、nacl_build.shというシェルスクリプトを用意しました。
結果的に出来上がったの以下のパッチとバイナリ
lha4nacl.patch
lha.nexe
をlha4nacl.tar.gzというファイルにしておきました。
ビルド方法としては、Mac OS Xの場合、LHa for UNIXのソースを展開してから、上記のファイルも展開し、
$ patch -p1 <lha4nacl.patch
(nacl_build.sh 内のNACLINSTALLPATHを適宜修正）
$ ./nacl_build.sh
と実行すれば、src/lha.nexeが作成されるはずです。
lha4nacl.patchを読めば分かりますが、元のソースには一切手を加えていません。移植性を考慮したコンソールアプリのソースなら、機能制限に目をつぶれば元ソースに手を加えなくてもそこそこ動いてしまうのがNaClの面白いところだと思います。
以上、駆け足で説明しましたが、抜けているところは適宜修正していきたいと思います。
もし、何かありましたら、メールまたはKKI@Twitter等にご連絡ください。
おつきあいありがとうございました。m(__)m
【蛇足】"Native"な"Client module"
Native Clientの登場直後から、Native ClientはGoogleのOSになるのではないか？という意見を見かけますが、私はそうは思いませんでした。
というのは、GoogleがNative ClientのバイナリをNative Client Applicationではなく、Native Client moduleと一貫して呼称しているからです。
Native Clientのパッケージの階層は、nacl/google_client/nativeclient となっていますが、Native Client moduleは、"Native Client"の"module"ではなく、Google Clientの"Native"な"Client module"なのではないでしょうか？
つまり、Native Client moduleはあくまで、NativeではないClient moduleと共にGoogle Clientを構成するmoduleの一つであり、最終的には単体のアプリケーションとして動作させる利用方法は減っていくのではないか？ということです。
Google Clientがどのような物かはまだ分かりませんが 将来的には、例えばGoogle DocumentのエンジンがNative Client moduleになったりするのではないかと私は考えています。
LHa for Native Client (準備編)
【警告】タイトルだけ見るとNative ClientでLHaが普通に動くように見えますが、実際には実用には堪えませんので、誤解のないようお願い致します。
GoogleのNative Clientのスタンダローン版のデバッグモードでLHa for UNIX (autoconf版)を動かしてみたのでメモ。
ウチの環境は、iMac(24-inch, Early 2008) 3.06GHzモデルなので、id:amachangさんの「ブラウザで X86 のマシン語を動かす！ Google 謹製 Native Client をさっそく試してみる」を参考にさせて頂きました。記事と違う点としては、
さて、ここからが本題である LHa for Native Client の話なのですが、Native Clientのバージョンが新しくなってしまったので、その確認等が終わってから次のエントリーで書く事にします。
GoogleのNative Clientのスタンダローン版のデバッグモードでLHa for UNIX (autoconf版)を動かしてみたのでメモ。
ウチの環境は、iMac(24-inch, Early 2008) 3.06GHzモデルなので、id:amachangさんの「ブラウザで X86 のマシン語を動かす！ Google 謹製 Native Client をさっそく試してみる」を参考にさせて頂きました。記事と違う点としては、
- nacl_mac_0.1_9380090.tgzがリリースされていたので、そちらを利用
- wgetはMac OS Xには標準でインストールされていないので、代わりにcurlを使って、
curl -O http://nativeclient.googlecode.com/files/nacl_mac_0.1_9380090.tgz
を実行 - ファイルの展開先は、~/src
- サンプルのlifeは、
$ cd ~/src/nacl/googleclient/native_client/tests/life
で実行
$ ./run.py - ./sconsは、~/src/nacl/googleclient/native_client/ から実行
- ブラウザで開いたURLは、file:///Users/kki/src/nacl/googleclient/native_client/scons-out/nacl/staging/earth.html
- このURLで指定したファイルは、さっきまでの ~/src/nacl/googleclient/native_client/tests/earth ディレクトリのearth.htmlファイルではない事に注意。そちらのHTMLファイルを直接開くとearth.nexeファイルが同じディレクトリにないので、
The Native Client plugin was unable to load
というエラーが表示される。ここで少しハマった。 - ブラウザ上でNative Clientモジュールを実行する時に、HTMLファイルをopenコマンドで開くと、file://localhost/... というURLになるが、この場合、
Load failed: NaCl module did not come from a whitelisted source.
という警告ダイアログが表示され「(意訳)URLがfile://localhost/... になっているが、このURLは許可されていないので、file:///... にして開き直してくれ」と（何故か）怒られる。
Use a URL beginning with file:// - testsディレクトリ以下にある、ブラウザで表示可能なサンプルのリストが（私の場合は）file:///Users/kki/src/nacl/googleclient/native_client/scons-out/nacl/staging/index.html で表示されるので、こっちを使うのがオススメ
- add.nexeとdiff.nexeは、testsディレクトリ以下にadd、diffディレクトリを作成してその中で作成したが、今回は .nexeファイルがあるので、同じディレクトリ内のHTMLファイルをブラウザで直接指定しても問題ない
さて、ここからが本題である LHa for Native Client の話なのですが、Native Clientのバージョンが新しくなってしまったので、その確認等が終わってから次のエントリーで書く事にします。
登録:
投稿 (Atom)
