Software Design

内部時刻は UTC で持たせよう campaign

ちゃっぴ (tyappi@wankuma.com) — Sat, 07 Jun 2008 00:16:00 GMT

わんくまブログでもちょっと前に話題に上りましたが summer time。

Summer time が導入されるといろいろなところで問題が発生することが予想されます。

それはなぜでしょう？

それは簡単なこと。現行動いている system が summer time を考慮しないで構築されているから。

Summer time が導入されるか否かなんてここ数年で出てきた話ではなく、ずっと以前から議題に上っていたことですよね。ていうことは、いつ導入されてもおかしくないくらい変更される余地があるものとして、本来 system を構築しないといけないんじゃないの？

以前、summer time 対応を真面目に考えたことあるんですけど、結論としては NTFS とかでやっているような内部時刻は UTC で記録しておいて表示するときに local time へ変換かけるのが一番じゃないかと。まあ、その overhead はありますけど、file system で問題なく実装できているので目くじら立てることないと思うんですが。

ということで、これから system 設計するときは内部に保持する時刻は UTC 使いましょうよ。といってみる。

Akamai Download Manager

ちゃっぴ (tyappi@wankuma.com) — Tue, 29 Apr 2008 11:48:00 GMT

MSDN Subscription で Windows XP Service Pack 3 を download するときに気づいた現象です。

MSDN Subscription から Windows XP SP3 の ISO image を入手するためには Akamai Download Manager の install を求められます。これを使い download を何度か行っていたのですが、その時にこのような dialog が。。。

なにかと思い対象の file を確認してみる。

[デジタル署名] tab が存在しません。つまり署名されていないということになります。

なお、対象の file は "%SYSTEMROOT%Downloaded Program Files" に存在していますが shell によって property 表示が変えられているため、対象の file を copy してから確認してください。Akamai Download Manager を構成する file は "DownloadManagerV2.inf", "DownloadManagerV2.ocx", "Manager.exe" の３つになります。inf は置いておくとしても、"DownloadManagerV2.ocx", "Manager.exe" 両方とも電子署名がありません。

ちなみに IE ではこんな感じで表示されています。

ただ、上記警告が表示されなかった人も多いと思います。なぜでしょう？

それは対象の ActiveX control が cabinet (.cab) 形式で配布されていて、その cabinet file には有効な電子署名がなされているから。

したがって、初回実行時は警告が表示されません。まあ、この仕様どうよ？と正直思いますが。。。

ActiveX control を配布する場合、対象の ActiveX control はもちろん、そこから呼び出される executable file、配布に利用する cabinet file すべてに電子署名をつけるべきでしょう。

なぜ署名していないか？非常に理解に苦しみます。

本来手本を示さなければならない Microsoft 社が作成した software の配布に自社製ではないとはいえ、このような software を利用させることを大変遺憾に思います。

できるだけ、早く改善していただきたいですねぇ。。。

Destination directory exists

ちゃっぴ (tyappi@wankuma.com) — Wed, 12 Dec 2007 17:32:00 GMT

Windows AIK で Windows PE を作成しようと遊んでいたときに遭遇した現象

C:\Program Files\Windows AIK\Tools\PETools>copype x86 D:\temp\WinPE\x86 Destination directory exists: D:\temp\WinPE\x86

なんじゃこれ、確かに "D:\temp\WinPE\x86" は作ったけど作っちゃいけないの？

ということで、私はご存知のとおりのヒネクレ者なので "WinPE" folder も削除して実行してみる。

=================================================== Creating Windows PE customization working directory

D:\temp\WinPE\x86 ===================================================

1 個のファイルをコピーしました。 1 個のファイルをコピーしました。 C:\Program Files\Windows AIK\Tools\PETools\x86\boot\bcd C:\Program Files\Windows AIK\Tools\PETools\x86\boot\boot.sdi C:\Program Files\Windows AIK\Tools\PETools\x86\boot\bootfix.bin C:\Program Files\Windows AIK\Tools\PETools\x86\boot\etfsboot.com C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\chs_boot.ttf C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\cht_boot.ttf C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\jpn_boot.ttf C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\kor_boot.ttf C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\wgl4_boot.ttf 9 個のファイルをコピーしました C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\bcd C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\chs_boot .ttf C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\cht_boot .ttf C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\jpn_boot .ttf C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\kor_boot .ttf C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\wgl4_boo t.ttf 6 個のファイルをコピーしました 1 個のファイルをコピーしました。 1 個のファイルをコピーしました。

Success

Updating path to include peimg, oscdimg, imagex

C:\Program Files\Windows AIK\Tools\PETools\ C:\Program Files\Windows AIK\Tools\PETools\..\x86

ということで成功しちゃいました。

なんだかなぁ～。せっかく存在しない folder は作成してくれる便利機能あるのに、存在していると NG なわけ？非常にもったいないですよ。

CreateElevatedComObject

ちゃっぴ (tyappi@wankuma.com) — Sun, 16 Sep 2007 23:40:00 GMT

UAC が有効な環境で動作させる application で一部の機能をどうしても管理者として実行させる必要ある場合には、動的に昇格させることが推奨されるわけです。

「CoCreateInstanceAsAdminなんてない」とかで話題になった "CoCreateInstanceAsAdmin" ですけど、「Windows Vista Application Development Requirements for User Account Control Compatibility 3. Redesign Your Application's Functionality for UAC Compatibility」によると "CreateElevatedComObject" を使えって変更されていますね。って、中身を確認してみると名前変わっただけのようです。

こういうものは、API で用意しとけよと思っていたのですが、一応その予定はあるようです。

Note A version of this API that is more complicated to call is available. A simplified version will be available in a later version of Windows Vista.

CoCreateInstanceAsAdmin or CreateElevatedComObject sample

浸透していないなぁ。。。

ちゃっぴ (tyappi@wankuma.com) — Tue, 11 Sep 2007 02:22:00 GMT

Application Specification for Microsoft® Windows® 2000 for desktop applications

Designed for Windows XP アプリケーション仕様書 2.3 日本語版

Microsoft® Windows Vista™ 対応アプリケーションの互換性

さて、これ読んだことある人すべての programmer および設計者の何 %くらいでしょうか？

Windows Vista 向けの logo program 向けの documents が日本語化

ちゃっぴ (tyappi@wankuma.com) — Mon, 10 Sep 2007 02:22:00 GMT

日本語化されています。Logo program を取得するつもりが無くても、Windows 上で動作するあらゆる software を設計・作成している人は一通り目を通しておくべきでしょう。

<参考> Windows Vista ロゴプログラム (English)

文字長制限に引っかかった場合の error message

ちゃっぴ (tyappi@wankuma.com) — Sun, 09 Sep 2007 12:48:00 GMT

サロゲートペアとOracle Database
Unicodeの結合文字は最大何文字くっつけられる？
で話題になった件ですが、JIS X 0213 を扱い出すと surrogates pair とか結合文字とかはっきりいって、見た目の文字と実際に格納される size (Bytes) の対応を行うのは非常に厄介です。

ということで、size を超過した場合にはどういう error message を返すべきか？
とりあえず、案を3つばかり挙げてみます。

Size を超過したことのみ通知
Size の超過と同時に超過した Bytes を通知
Size の超過と制限されている Bytes と現在の Bytes を通知

さて user にとってはどれがいいですかね？

なぜ %PROGRAMFILES% に書き込んではいけないか？

ちゃっぴ (tyappi@wankuma.com) — Thu, 12 Jul 2007 02:55:00 GMT

Vista では %PROGRAMFILES% への書き込みは仮想化(Virtualization)されますが、なんでこういう風になったのでしょう？

まず、%PROGRAMFILES% への書き込みですが、実は Windows 2000 だろうと Windows XP だろうと書き込みが制限されていました。ただ、最小限の権限で実行するという security の大原則を守っていない user があまりにも多かったため、今までは問題なくやり過ごしてきたという人も多いと思います。

ちゃんと説明できる人は意外と少ないと思われますので、この際説明しておきます。

第一の理由は、security です。

通常 user が application を起動するときはその中身が置き換わっているかなんて注意を払わないものです。User が知らないうちにその application が置き換わったとします。これ、ある意味簡単に攻撃が成功してしまう状態ですね。

ただ、これが実際に深刻な脆弱性を招くかというと、攻撃手段が非常に限定されるため一般的にはそれほど問題は発生しないでしょう。むしろ、%WINDIR% とか、環境変数 "PATH" を通している folder の ACL を気にした方がよいです。ただし、当然推奨されるべきものではありません。

第二の理由としては、第一の理由と似ていますが、可用性(availability)です。

User が書き込めるということはすなわち、user の誤操作によって application を破壊してしまう恐れがあります。

ここまでは、application の置きかえ、改竄に関する問題です。第三の理由はここまでとは全く違う要因です。それは、multi user の support の問題です。

まず、Windows は NT 以降 multi user を前提に設計されています。その上で動作する application?も一部の例外を除き原則 multi user で動作するように設計・実装を行うべきです。

では、なぜ %PROGRAMFILES% に書き込むのが multi user で動作することを阻害するのでしょうか？

こちらの一点目の要因は、user 毎の設定ができないことです。Client でも１台の端末を複数の user で共有する場合はありますね。その場合、User 毎の設定ができた方がいいのは当然ですよね。

一点目の要因はそれほど深刻な状況を招きませんが、これから述べる二点目の要因は時に深刻な事態を招きます。それは、同時実行性の阻害です。

Windows 上で同時に複数の user で実行するしくみの一つに Terminal Service があります。最近では情報漏洩対策として既存 application を Terminal Service に移行するといった案件も多いでしょう。この場合、%PROGRAMFILES% に書き込みを行っていると問題が発生する場合があります。

ただ、Citrix Presentation Server (旧 MetaFrame) のように Vista の仮想化と同様の手法にて強引に互換性を保つものもありますが、こういったものは application を変更できる環境であれば積極的に利用してはいけません。

それから、問題は Terminal Service だけではありません。Windows XP 以降の client OS には「簡易ユーザーの切り替え」?(FUS: Fast User Switching) が搭載されています。この機能を利用している場合には、client OS でも問題が発生します。

ただ、複数の user で共有するものを扱いたい場合もあるでしょう。その場合はどうしたらよいか？

一番いい方法は、それを扱う専用の service 等を作成して、必ずそれを介して処理を行わせる方法です。代表的なものに多くの DBMS なんかが挙げられます。わざわざ自作しなくても、そういったものをお手軽に利用すのも一手です。

次の一手ですが、同時実行性を一切考慮しないのであれば単純に "All Users" の "Application Data"?(Vista の場合 "%PROGRAMDATA%") を利用するという方法もあります。この方法を利用する場合には、OS version によっては ACL を変更する必要があります。

どうでしょうか？ %PROGRAMFILES% に書き込んではいけない理由が漠然とでも理解していただければ幸いです。

最後に、application を設計・実装するのであれば、実際に設計・実装を行う前に下記 document に目を通しておくことをお勧めします。

Designed for Windows XP アプリケーション仕様書 2.3 日本語版

XP 時点の古いものですが、Vista でも有効な application の満たすべき要件が載っています。Vista に関しては下記 document を読んでおいた方がよいでしょう。

Certified for Windows Vista 技術要件

Designed for Windows XP (Vista で同じ level に当たるのは Works with Windows Vista) より厳しい Certified の要件ですが、非常に参考になると思います。