日 時：1999年9月16日（水）13：30〜16：30 場 所：東京工科専門学校ICAテラハウスB1Fテラホール 参加人員：55名 テーマ：『Windows 2000に向けてのアプリケーション開発』 構 成： 第１部 『既存アプリケーションのWindows 2000への移行』 マイクロソフト株式会社 ビジネスソリューションズ事業部 デベロッパーマーケッティング部 課長 寺田 雄治 様 第２部 『Windows 2000 認定アプリケーションの構築』 ライオンブリッジジャパン株式会社 代表取締役 マーク･アタウェイ 様 今回は２部構成で出荷が近づいてきましたWindows 2000に向けてのアプリケーション開発をテーマにお話いただきました。
第１部では、寺田講師より、『既存アプリケーションのWindows 2000への移行』と題し、Windows 2000にWindows95、98およびWindows NT4.0のプラットフォームからアプリケーションを移行させる際にどのような互換性上の問題点が生じるかについて、(1)Windows 2000の位置付け、(2)“非互換”が発生する要因、(3)「非互換が発生する要因」について細かい所から実際のOSの仕様変更といった部分まで一つ一つ説明が行われました。
(1)現状は、順調にいけば米国内で本年中のRC1出荷というところでスケジュールが進んでいる。Windows 2000の位置付けとして３点の特長がある。 @ 本当に久々にWindows NTのバージョンアップである。OSのバージョンアップに関しては、旧来のOSのバグフイックスと仕様の変更や機能の追加が存在する。今回一番大きなファクターとして互換性をある程度犠牲にしても信頼性を向上させようという戦略のもとでOSのビルドを進めている。このために今回アプリケーションの互換性に若干影響を及ぼしている部分がある、ということをご承知おきいただきたい。 A 他国語対応が挙げられる。これはOS自身が各国合わせてOne Binary、つまりOSにおいては１つしかコードが存在しないことになる。今までのバージョンではUS版、日本語版、韓国版などと世界では何十カ国版が存在したが、今回のバージョンではバイナリーが基本的に１つ、それに対してLanguageサポートという形で各種文字のリソースを追加することによって各国の環境が実現される。これにより各国のローカルコードが基本的に存在しないことになる。例えば日本においては、こういうアプリケーションが絶対動かなければいけないからといったような手心の加え方が一切できない。例えばWindows NT4.0やWindows 98のリリースの際にはアプリケーションベンダーさんと密接な連絡を取りながら、どうしても動かさなければならないアプリケーションに関してはOSのコードを若干修正してでも動かしたという経緯があるが、このような方法は今後一切使えなくなる。そういう場合は直すのはOS側でなく、アプリケーション側にお願いすることになる。 B 一番大きな特長は、今回のWindows 2000はWindows 98の機能のスーパーセットである。これは従来Windows 95,98のプラットフォームを対象にしていたアプリケーションがその動作環境としてWindows 2000を選択いただきたいという意味合いを持っている。それによって当然のことながら今までWindows NTでは意識しなかったようなアプリケーションをWindows 2000で動かすようになる。動作対象アプリケーションが増加することによって今まで考えたことのないような症状が起こる可能性が出てくる。スーパーセットといっても元々の98、NTではプラットフォーム間の差異がアプリケーションにダメージを与えるかもしれない。マイクロソフトとしてはWindows 95,98からWindows 2000アップグレードのパスを提供する予定であるので、一般のユーザーに関してもWindows 95,98からアップグレードされる可能性がある。クリーンインストールなら問題はないが、Windows 95,98に上書きでWindows 2000をインストールしたときにアプリケーションに何らかの問題が出る可能性があるかもしれない。 こういった主に３点のファクターのもとにいくつか出てきた問題点について説明が行われました。 (2)アプリケーションの非互換が発生する要因としては、大まかに分けて４通りあると考えられる。 @ インストールにおける不具合 1点は、OSにおける問題というよりバージョンに対するアプリケーションの考え方に起因するものが多い。もう１点は、OSがアップグレードする度に若干ながらアプリケーションの動作環境に変更が生じることがある。例えばレジストリのエントリーの使い方とか、デフォルトとして推奨するディレクトリ等の変更等によって若干アプリケーション側として環境が変わってしまうことが上げられる。これらを如何に解決するかである。 AOS側の仕様変更 これによって従来動いていたアプリケーションに不具合が生じるケースが存在しうる。 Bアプリケーションの潜在バグの顕在化 今までの環境ではたまたま発現していなかったバグが、OS側のコードがより厳しくなったために顕在化してしまうというケースがままある。例えばAPIの中で従来は厳密にパラメータのチェックをしていなかったのが今度のバージョンから厳しくチェックするようになり、そのため今まで動いていたものがAPIからエラーコードが返ってきて動かなくなる、こういうケースは今までかなりの割合で存在している。これは特にコードを知っていてWindowsのプログラミングに慣れている方ほど陥りやすい問題である。例えば最後のパラメータを省略しても動作に問題ないからここは書かないとか、ここはNULLでも構わないというような形で、アプリケーションの仕様書になくてもそれで動いているから構わないというコードのケースでよく生じる問題である。このようなものがよく出るし、それ以外にも仕様上は禁止されているがたまたま動いているから構わないと思っていたものが新たに顕在化するケースがある。 Cプラットフォーム間の差異 スーパーセットとはいいながらやはり内部的な差異が若干存在しており、それによって生じる不具合がある。 (3)では、(2)の@インストールにおける不具合、AOS側の仕様変更、Bアプリケーション側の潜在バグの顕在化、Cプラットフォーム間の差異について詳細な説明が行われました。 @『インストールにおける不具合』では、OSがアップデートした時に最もポピュラーに起こり、最もユーザーが困る問題はアプリケーションがインストールできないというケースである。その原因はまずセットアッププログラム等で起こしてしまう、或いは環境が違うのでうまくセットアップできないケースがある。また、インストールはできたが動作しないというケースで存在するのがバージョン番号に関するものであり、内部でのバージョンチェック（Windows 2000のバージョン番号は“5.0”）で引っ掛かって動かないケースがある。これらは基本的にコード上のケアレスミスであり、ちょっとした修正で直るというケースが多い。困ったことにこれらは、アップグレードインストールでは顕在化しないことも多く、問題の切り分けが非常に面倒なことがあったりするが、この辺はベータ版でセットアップして動作させていただければ一発で分る問題であるので早めの対応をお願いしたい。 続いて各項目の詳細説明に入り、「Version Checking」、「DLL Version Checking」、「DLL Hellとは？」、「DLL Hellを回避するために」、「DLL Redirection」、「間違ったPathへのインストール」、「Component Checking」、「セキュリティ」、「デフォルトのサーバーアクセス権」についてのお話がありました。 特に、OSのアップグレードおよびアプリケーション側のインストールによって常に起こる問題としてDLL Hell（DLL地獄）が存在し、これがシステムの安定性を損なう最大の原因にあげられると云われており、これを回避することなしにはOSの安定性が保てないと考えている。OS側の頻繁なパッチなどによりDLLの体系やバージョンが非常に複雑になってしまったというのが一番の問題である。「DLL Redirection」については、特にWindows95、98でアプリケーションを動作させているベンダーさんに関しても非常に影響がある話なので是非ともご記憶いただきたいとの前置きがあり、DLL Redirection はWindows 98 SE以降で既にサポートされており、Kernel32の修正、そのアプリケーションに合致したバージョンのモジュールをApplication Directoryに配置、.exe.localファイルの参照により適切なDLLのロード、などの詳しい解説がありました。これらにより比較的場当たり的な処置になるが、システムのアップデートによるアプリケーションの動作環境の変化を極力避けることができ、かなりの確率で従来のアプリケーションを救うことができる。 またSide by SideといわれるバージョニングのシステムがWindows 2000の方でサポートされる。具体的にはCOMコンポーネントやDLLの複数のバージョンを管理して、必要とされるバージョンのモジュールをアプリケーションにロードさせる仕組みであるが、アプリケーション側の変更が必要である点と詳しい資料がまだできていないので今はお知らせできないが、詳しい資料が出次第Webページで公開する、とのことです。 A『OS側の仕様変更』では、アプリケーションの互換性を保つことは重要なファクターであるが、プラットフォームの機能を前進させるためにはやむを得ず互換性を犠牲にしてでもOS側の仕様変更を行うケースがあり、これらがアプリケーションの動作に影響を与えることもある、との前置きがありました。続いて、各項目の詳細説明に入り「Foreground Windowに関する変更」、「Super Hidden Files」、「System File Protection」、「SFPの無効」、「NetBIOS」、「Network.infファイルの刷新」、「物理ドライブ番号の検出」、「テープデバイスへのアクセス」、「カーネルモードでの書込み禁止」、「ディスプレイドライブのフック」、「スタック使用量の増加」についてのお話がありました。 B『アプリケーション側の潜在バグの顕在化』では、OS側の変更はしばしばアプリケーションの潜在バグを顕在化させることがあり、アプリケーション仕様書等のドキュメントの内容に則っていないソフトウェアも数多く、Path等のリソースをハードコードしているケースもまだまだ見受ける、との前置きがありました。続いて、各項目の詳細説明に入り「ハードコードされたPath」、「長いファイル/プリンタ名」、「ヒープマネージメント」、「Calling Conventions」、「バッファを使用しないファイルI/O」、「大容量ドライブの利用」、「ビットフラグのチェック」、「メッセージの配信順」、「マルチモニタの影響」についてのお話がありました。特に、「Calling Conventions」では、通常マニュアルでは、WindowsのAPIはすべてSTDCALLの呼出しが前提になっているが、従来からの互換性を残すためにWindows 95/98ではWindows及びdialogまわりのAPIではC_DECLの呼出しをサポートしていたが、Windows 2000では全面的に使用不可となるので、あえてC_DECLを使用していた場合は修正が必要である。 C『プラットフォーム間の差異』では、Windows 2000は、Windows NTがベースであり、Windows 98のスーパーセットである。しかし、機能的なスーパーセットではあるが内部仕様のスーパーセットではないので内部仕様においてWindows 2000とWindows 98には若干差異があり、その差というものを意識してコーディングしないと両方で動くアプリケーションは書き得ないことになる。特にWindows 95/98からWindows 2000へアップデートした時にアップデートそのものは上手くいったが、そこのアプリケーションのインプリメントがされていないために動作しないというケースも起こりうるので、従来のWindows 95/98のアプリケーションでWindows 2000をサポートする場合には、ここで説明するところをチェックいただきたい、との前置きがありました。続いて、各項目の詳細説明に入り「Windows 95/98のAPI」、「32ビットハンドル」、「GDI座標系」、「フラットサンク」、「DeleteFile()」、「FileTimeToDosDataTime()」、についてのお話がありました。「Windows 95/98のAPI」では、一部のAPIはWindows 2000でサポートされておらず、またWindows 2000にはあるがWindows 95/98にはないAPIもある。アプリケーションが両方での動作を前提とする場合は、その最大公約数内でのAPIで処理を行う必要がある。この内容については、Platform SDK中のWin32API.CSVというファイルがあり、これにAPI名とその各々のプラットフォーム名があり○、Ｘが記述してありそこでどのプラットフォームがサポートしているか判るので、もしグレイのAPIがあった場合このシート上でチェックしていただいてからお使いいただきたい。「32ビットハンドル」では、Windows 2000においては16ビットハンドルの使用は不可で、Windows 95/98を前提に32ビットハンドルを正しく操作していないアプリケーションは、Windows 2000上で誤動作する可能性がある。具体的には、アプリケーション内部では32ビットハンドルを使っていただき、Windows 95/98で使う際は上位16ビットを無視して使うなどの形でやっていただくのが好ましい。 ちなみに上位16ビットをゼロにした場合、それでWindows 2000で動くかというと2000の場合には上位16ビットのうちどれか1ビットは必ずフラグを立てない正常と認めないことになっているので、単純にゼロをサプレスしてしまって両方で動くだろうという処理は認められないので、ご承知おきください、とのことです。 先にあげた４項目のアプリケーションにおける影響を説明したが一応今のような話がすべてアプリケーションに該当するとは思わないし、皆さんがテスティングでトラブルが生じた場合は今回の話を参照していただき、もしかしたら該当するのではないかと思い出していただければ、これ以上の幸いはない。こういうことを調べることも必要であるが、まずはともかく動かしてみていただきたい。Windowsコンソーシアムの会員さんには、Windows 2000ベータ３を7月度のWindowsキットに入れてお送りした。テスティングが必要でベータ版が足らないときには、数があるかぎりはご提供できるのでお申し出いただきたい。ともかく現状のアプリケーションをベータ版で動かしていただいて、それによってもし何かトラブルが生じた場合、今回のデータを思い出していただき該当するところがあれば直していただいて、必要だったらパッチなりアップデート版でのリリースをWindows 2000のリリースと同時期頃にご検討いただければと思う。もしアップデート情報等がユーザーさんに周知されたい場合には、アプリケーションの互換性のWebをマイクロソフトがたてるのでそこに情報を載せていただき、それによってユーザーさんがアップグレードに関する情報収集をサポートできればWeb利用が可能である。 「Call To Action」として、まずは、Windows 2000ベータ版上でのテストを行い、必要であればパッチまたはアップデート版でのリリースを行うが、ユーザーへの情報提供には、マイクロソフトのWeb利用が可能である。 ＜事務局から＞ 「Windows 2000互換性ガイド」については、 MSDN Online Japanで公開中です。下記を参照ください。 http://www.microsoft.com/japan/developer/visualc/resource/book01.htm 第２部では、マーク・アタウェイ講師よりWindows 2000 の認定テストとそのアプリケーション仕様についてお話いただきました。
お話は、(1)プログラム概要、(2)アプリケーション仕様、(3)スケジュール、(4)リソースと４つのトピックについて、また、 (5)ライオンブリッジジャパン株式会社の紹介がありました。 (1)Windows 2000 の認定テストについては、今回技術的なレベルはアプリケーションを作成する側から見ると、非常に高くなっている。テスト自体も以前のロゴプログラムであると割とベーシックな仕様やそのルールに従っていれば合格することが可能だったが、今回はより厳密に細かい点までテストされることになるので注意して欲しい。アプリケーション仕様自体は顧客のニーズをベースに作られたもので、ユーザーとしてWindows 2000またWindows 2000上のアプリケーションがより使いやすくなるように作られた仕様書である。従ってアプリケーションを作る側から見ると大変なところもあるかもしれないがユーザーのために作られたものであるから、それをご理解いただければと思う。また今回のプログラムについてはマイクロソフトでもかなりの投資をしているので、このプログラムに参加される皆さまにはいろいろと大きいメリットがあるかと思う。 ロゴプログラムは、最初Windows 3.1から始まった。当時はWindowsコンパチブルというロゴプログラムがあり、それに続いて現在のDesigned for WindowsというWindows NT4.0とWindows 98を中心にしたロゴプログラムができた。今回Windows 2000という新しいOSが出ることにより、ロゴプログラムをCertified for Windowsという新しい認定プログラムに切り替えることになった。この新しい認定プログラムは、名前通りWindows 2000が中心になり、今はデスクトップ用とサーバー用の２つのプログラムが準備されているが、本日のプレゼンテーションでは、デスクトップ用のみについて説明させていただく。 デスクトップ用の場合は、５つのロゴが用意されている。まずはWindows 2000のみのロゴがあり、それに続いてWindows 2000とWindows 98の組み合わせのロゴがある。残りの３つのロゴはWindows 2000とWindows NT4.0をベースにしたロゴであって、まずは、Windows 2000とWindows NT4.0のみ、次はWindows 2000＋Windows NT4.0＋Windows 98、最後は全てをまとめたWindows 2000とWindows NT4.0とWindows 98とWindows 95のロゴとなる。 認定の対象となるOSは、デスクトップ型の仕様ではWindows 2000 Professional、Windows NT Workstation Version 4.0、Windows 98、Windows 95であり、分散型の仕様ではWindows 2000 Server、Windows 2000 Advanced Serverとなる。なお、テストには、各OSの最新リリースバージョンを使用して行う。 (2)では、Windows 2000 対応アプリケーション仕様およびデスクトップ アプリケーション向け仕様概要についてのお話がありました。 Windows 2000 対応アプリケーション仕様は、ユーザーの ニーズを考えて作られたもので、Windows2000上でユーザーが一切問題なく使えるようにするのが目的であり、2 種類のアプリケーション仕様（デスクトップ アプリケーション向け、分散型多層アプリケーション向け）がある。本日はデスクトップの話のみとなる。アプリケーションの仕様自体は、次のURLからダウンロードできるので参照していただきたい。 http://www.microsoft.com/japan/developer/msdnisv/windows2000/appspc.asp デスクトップ アプリケーション向け仕様概要では、大きく分けて７つの項目（Windows 基礎要件、Microsoft Installer (MSI) を使ったインストール、コンポーネントの共有、OnNow/ACPI、複数モニターのサポート、その他特定のハードウェア要件、前バージョンのプラットフォームからの移行）があるとのことで、これらについての説明が行われました。 ●Windows の基礎要件 ・Windows 2000上で主要機能の実行と安定性の保持ができなければならない。 ・32ビットコンポーネントのみが対象となるので、EXEファイルやDLLファイルなど実行可能な全てのファイルがPE(Portable Exe)フォーマット形式になっていなければならない。 ・長いファイル名とUNCパスの完全サポート ・長いファイル名とUNCパスを持つプリンタの完全サポート ・NTベースのOS(Windows 2000、Windows NT4.0) 上では、４つのファイル（Win.ini、System.ini、 Autoexec.bat、Config.sys）の読み書きが禁止されている。実際ロゴプログラムの中で95や98上でのテストを行う場合は、これらのファイルへの読み書きをしてもチェックされないので安心されたい。 ・全てのファイル（隠しファイルなどを除いて自分のディレクトリ以外にインストールされるもの）に対してファイルタイプが登録されなければいけない。全ファイルタイプに関連のアイコン、説明、およびアクションがつくことになる。 ・Windows バージョンチェックを正しく行う必要がある。Windows NTは、Version 4であったが、Windows 2000はVersion 5になる。ただし、互換性は今のOS以上のものに対して互換性を持たなければいけないということで、実際テストプランをご覧になれば分かるがWindows 2000を実際はVersion 5でなく、Version 6に設定してテストされるので、例えばVersion 5のみとチェックされる場合は不合格となる。 ・今まではアプリケーションをCDからインストールされる時には、スタートメニュから実行することも許されていたが、これからは全てアプリケーションに対して AutoPlay をサポートしなければならなくなった。ユーザーとしては、CDを入れたら自動的に立ち上がるのが当然のことになるようになる。 ・カーネルモードドライバに問題点があるとシステムへの影響が大きいので、それをできるだけ避けるためにカーネルモードドライバが含まれている製品の場合は、Windows 2000の認定テストを行う前にカーネルモードドライバの検証テストを行う必要がある。実際、検証用のユーティリティなどは仕様書に書かれており、自由にダウンロードできて使えるものがあるので仕様書を読んでいただきたい。 ・ハードウェアドライバが含まれる製品については、ソフトウェアの認定テストを受ける前にハードウェア自体を WHQL(Windows Hardware Quality Lab.) でテストする必要がある。テストされて合格したもののみが、ソフトウェアの認定を受ける対象になる。VeriTest社の場合は、ソフトのみの認定テストを行っているので、ソフトの認定テストが終わった段階でVeriTest社からWHQLに連絡して、そこでハードウェアドライバが検証テストを合格したことを確認するので、もしそこでハードウェアドライバが合格していなかったら、ソフトウェアの認定も取れなくなる。 ●インストールとアンインストール 今までユーザーの面からみるといろいろと大きな問題が起きているのは、インストールやアンインストールの時点であると思われるので、そのような問題を減らすためにこれからはWindowsインストーラーが用意されて、それをベースにしたインストレーションパッケージのみが対象となる。 ・Windowsインストーラーの検証テストに合格したものを使う必要がある。 ・コンポーネント化規則に準拠：自分のコンポーネントをシステムのディレクトリに書込みしようとしないことが要求される。 ・共有コンポーネントの識別：他のアプリケーションに影響ないように設定しなければならない。 ・Program Filesディレクトリへのインストールをデフォルトとする。：ハードコードされているようなものではなくて、Program Filesホルダーのプロパティを読み込んでそれをベースに正しいディレクトリへのインストールが要求される。もちろん、ユーザーの方でデフォルトから他のディレクトリに変更を希望の場合は、それもサポートしなければならない。 ・「アプリケーションの追加と削除」 をサポート：今までは特に「削除」の方は独自にアンインストールのプログラムを使っていたアプリケーションが多かったが、これからは全てのアプリケーションに対してコントロールパネルから「アプリケーションの追加と削除」の機能を通してきれいにインストールもアンインストールもできなければならない。アンインストールの場合は、特に今まではスタートメニュなどを使ってやっていたケースがあったのでご注意いただきたい。 ・アプリケーションがアドバタイズ機能をサポートすることを確認：アドバタイズ機能とはソフトがインストールされる時にソフト自体をインストールするのではなくて､そのソフトへのショートカットのようなもののみがハードディスクにインストールされてユーザーが初めてそのアプリケーションを起動させようとした時に実際ソフトウェアでCD-ROMなどからインストールされるようになる。この機能が何故あるかというと、大きいアプリケーションやSuiteの場合は複数のプログラムが入っているものが多いので、必要なものだけが実際ハードディスクにインストールされてそれによって必要な容量を減らす目的で作られたものである。 ・正しいアンインストールのサポートを確認：そのアプリケーションに関するファイルがきれいに全て削除されていて、他のアプリケーションやシステムに影響ないようにアンインストールされなければならない。 ●コンポーネント化の規則 ・リソースを複数コンポーネントに搭載しない：同じリソースを使っているコンポーネントが複数ある場合は、アンインストールしようとする時に正しくそのコンポーネントを削除して、それに関するリソースを削除することは難しくなるので、リソース自体は１つのコンポーネントのみに与えることが基本となる。 ・同一コンポーネント内のファイルは全て同一ディレクトリ中にインストールする：プログラマから見ると当然のことと思われるが、１つのコンポーネントに対してそれに関連する全てのファイルが同じディレクトリにインストールされることが要求される。このようなプログラミングのプラクティスを行うことによって、アンインストールの時も結構楽になると思われる。 ・１つのコンポーネントにつき１つのアドバタイズされたファイル：アドバタイズ機能のコンポーネント毎に１つだけ与えることが要求される。 ・COM サーバー、拡張サーバーが KeyPathであること：コントロールパネルのアプリケーションもそうであるが、必ず正しくレジストリキーとしてPathを登録する必要がある。 ●コンポーネントの共有 ・システムファイル保護機能によって保護されているファイルの置き換えを試みない：システムファイルをアプリケーションなどが置き換えしようとした場合、自動的にこれが機能してそこでシステムファイルの修復を行うわけなのでアプリケーションなどからシステムファイルを置き換えしようとしないのが基本となる。 ・コンポーネント作成者は、Side by Sideのコンポーネントを作成：Side by Sidコンポーネントとは、いろいろなバージョンのDLLが同時に複数のアプリケーションで使えるようにするテクニックであるが、これを使うことによってシステムのDLLを置き換えしようとする必要がないし、割ときれいに自分だけのためのDLLを自分のディレクトリに用意して使うことが可能となる。 ・アプリケーションの開発者は Side by Sideのコンポーネントを使用し、インストールする ・Side by Side以外のコンポーネントを正しい場所にインストールする：正しい場所とは自分のディレクトリとなり、できるだけシステムのディレクトリや他のディレクトリにファイルをインストールしないようにする。 ●データおよび設定の管理 ・ユーザー作成データをデフォルトで 「マイドキュメント」に保存：ユーザーがデータを作成したり、ファイルを読み込んだりする場合は、ダイアログとしてはファイルを開く/保存のダイアログがよく使われるが、はじめてそのダイアログが使われる時は基本として「マイドキュメント」にデフォルトするようにしなければならない。それ以外、同じダイアログが呼び出された場合は、最後に使われたPathにデフォルトするのが推奨される。 ・アプリケーションデータを正しく分類して保存する必要が出てきている：分類のカテゴリとしては３つある。１つ目はユーザーごとにローミング（マシンからマシンへ同じユーザーがまわってログインして使うケース）、２つ目はユーザーごとにローミングしない場合、１つのマシンで１つのユーザーが使う場合のデータと、３つ目はユーザーごとでなくてマシンごとにデータが保存されるようなカテゴリが用意されている。今までの説明もそうであるが、細かい点は仕様書にいろいろと書かれているので是非参照することをお勧めする。 ・アクセス拒否されたら停止せずに機能を制限：ユーザーのレベルには３つのユーザーがあると第１部でお話があったが、１番高いレベルは管理者であり、次にはパワーユーザーがあり、１番低いレベルには一般ユーザーがある。一般ユーザーができることは大変制限されており、アプリケーションとしては制限されているユーザーが制限されている環境の中でうまくプログラムが動作することが要求される。そこでユーザーの設定を読み込んだり、それに合わせてプログラムの機能を、例えば使えない機能などを表示したり、ユーザーにエラーメッセージを出して停止せずにプログラムの起動を続けることが期待される。 ・セキュリティを確保したWindows 環境でも実行：次項で説明。 ・システムレベルでのグループポリシー設定に従う：普通のアプリケーションにはあまり影響ないが、OSの機能の一部を置き換えたり、OSの機能に追加されたりするアプリケーションの場合は、システム上設定されているグループポリシーを正しく意識して、その設定に従わなければならない。 ・ADMファイルを作成するアプリケーションでADMファイル設定がレジストリに正しく保存される：ADMファイルとは簡易テンプレートであるが今まであまり使われていないケースが多かったが、ADMファイルを作成するアプリケーションでは正しいレジストリキーに登録する必要がある。 ●セキュリティを確保したWindows 環境 Windows 2000をNTFSパーティション内に完全にインストール：白紙の状態でWindows 2000をNTFS用のパーティションにインストールされた環境による。この環境上で一番低いレベルの一般ユーザー(管理者、パワーユーザー以外)が書込みできる場所は、次のように本当に限られた場所であるのでプログラムの中で十分注意してなければならない。 ・レジストリの各ユーザーの部分 ・ユーザー自身のプロファイル ディレクトリとサブディレクトリ ・共有ドキュメントの場所 ●ユーザーインターフェイス ユーザーから見ると一番印象的な部分なので、マイクロソフトとしては各アプリケーションのユーザーインターフェイスの統一感を高めるためにいろいろとルールを強化している。 ・標準システム サイズ、色、フォント、入力設定のサポート：まずは割と単純なフォントや入力のUI関係の設定にプログラムとしては従う必要がある。これによりどのアプリケーションを立ち上げても同じ画面が出てくることによりユーザーが安心することが期待される。 ・ハイコントラストオプションに対応：目の不自由な方やよく見えない場合に、ハイコントラストオプションを選択する場合は色の調整が行われて見易くなる仕組みになっているので、その設定がされている場合はアプリケーションとしても意識しなければならない。 ・文書化された全機能へのキーボードアクセスを提供：マウスを全然使えない場合もあるので、マウスを使わずにキーボードから全ての機能がアクセスできなければならない。その上で文書化されていなければならない。 ・キーボード位置を示す：マイクロソフトにはアクセシビリティ機能(Microsoft Active Accessibility)という障害を持つユーザーの方のためのプログラムがある。アクセシビリティの一部の機能としてキーボードの位置の周りが拡大されて読み易くなるような機能があり、この機能をサポートするためにキーボードの位置を必ず示す必要がある。 ・サウンドのみにフォーカスに依存しない：耳の不自由なユーザーもいるのでサウンドのみで大事な通知を行うことは禁止されている。サウンドで通知する場合は、画面にも表示する必要がある。また、サウンド解説のオプションを設置したユーザーの場合は、そこで例えば音楽が流れていたり、メッセージが音声のみで流れている場合は追加画面などを利用してユーザーに情報を提供する必要がある。 ・[スタート]メニューにドキュメント、ヘルプ、アンインストールへのショートカットを配置しない：今まで[スタート]メニューのためにいろいろプログラムを起動させようとする時に、余計なもの（ReadMeファイル、Helpファイルなど）が入っているアプリケーションが沢山あり、場合によってはユーザーとしては何を選択する分からなくなっているくらい混乱するケースがあった。これからは[スタート]メニューからは起動するアプリケーションのみが入っていて、起動に必要ないショートカットなどは[スタート]メニューに入れないようにしなければならない。 ・複数モニターのサポート ●OnNow のサポート OnNowとは、パソコンをステレオやTVと同じような感覚で使えるようにするためのものである。かなり時間がかるようなブート機能を除いて、直ぐ使えるようにするためにアプリケーションとしてはこれからOnNowの機能が要求される。 ・アプリケーションのビジー状態を適切に示す：アプリケーションが外から見た場合アイドルに見えていても実際は内部で何か処理を行っている場合は、ビジーという通知をOSに送る必要がある。 ・OSからのスリープ要求に適切に応答し、スリープ通知を適切に処理する。また、通常のスリープ状態からデータを失うことなく復帰処理する。：これに正しく従う必要がある。正しく従うとは、データを保存する必要がある場合は保存し、開いてあるファイルを閉じたりして、後から復帰した時にきれいにデータを失わずにプログラムの実行を続けることができることである。 ・クリティカルスリープからの復帰を適切に処理する：非常時に電源が突然切れたりする場合はシステムから事前にアプリケーションに通知することができないので、電源が復旧した場合、アプリケーションに「クリティカルスリープがありました」と過去形で通知があるのでアプリケーションとしては、それに正しく対応してそこでクラッシュせずに実行を続けなければならない。クリティカルスリープの場合はどうしてもデータなどを失うケースがあるので、その場合はユーザーに正しく「今データを失いました」というようなエラーメッセージを出しながら実行を続けなければならない。 ●アプリケーションの移行 OSをWindows 2000 Professional にアップグレードした後も、アプリケーションとしては再インストールせずにそのまま正常に機能し続けなければならない。今まではユーザーにとって全てのアプリケーションを再インストールするのは非常に大きい負担であったので、ユーザーがOSのアップグレードを嫌がって遅くアップグレードするような場合もあったので、再インストールの必要のないプログラムを作ることが要求される。 ●効果的な実施 これは必須条件ではないがユーザーから見てより使いやすくするために、また今後のOSのアップグレードなどを考えた上で今のうちサポートした方が効果的だと思われているようなものが推奨されている。 ・Windows 2000上での再起動の必要がないアプリケーションのインストール：今まではこのようなことは不可能に近い状態だったが、ここでDLLのSide by Sideコンポーネントなどがバージョン別に使えることから作り方によってはアプリケーションをインストールする際OSの再起動の必要が無くなるケースが多いかと思う。ユーザーにとってインストールして直ぐ使えるメリットがある。 ・SHGetFolderPath を使用し特殊なフォルダーパスを決定：この関数を使うことによってWindows 95からWindows 2000までの動作が同じようになるようなアプリケーションの構造にもよい影響を与えるのではないかと思われている。 ・グローバリゼーション（国際化）に対するアドバイスがこのセクションに書かれている。 ・ローカライズ適性：世界は大きいということで皆さんが作られたアプリケーションが全世界で簡単にローカライズできるようなアドバイスがこのセクションに入っている。 ・ユーザー補助についてさらに考慮すべき事項：アクセシビリティ機能(Microsoft Active Accessibility)の提供により障害を持つユーザーの方のためのアドバイスが入っている。 ・64 ビット対応データ 型の使用：現時点で64ビット対応のOSが開発中であり、それに対応するためのいろいろなアドバイスがこのセクションに含まれている。 (3)認定テストのスケジュール ●Windows 2000用の認定テスト 米国でデスクトップ用は9月7日から開始されて、アプリケーションも実際テストされている。分散型は未定であるが、デスクトップ用の方は、日本とパリでも 11月からテストが始まる予定である。 ●テストプラン企画過程 アプリケーション仕様書以外にテストプラン自体も一般公開されている。マイクロソフトでは多くの時間をかけてテストプランを作った。これが一般公開されたことにより、全世界の開発者が自由にこれをダウンロードして一つ一つ見ることができる大きなメリットがある。アプリケーションの開発者によってはアプリケーション仕様書を見なくてもテストプランに従っていればいいのではないかという人も米国にははいたが、実際レベルが全く違うということで両方お読みになることをお勧めする。アプリケーション仕様書自体はもっとハイレベルであって、何故こういうことをしなければならないかが書かれており、プログラムのデザインや構築のときに役立つ。また、テストプラン自体は、一つ一つ細かく書かれているので、それも見たほうが認定テストを受けるときに合格しやすくなるかと思う。 これらのテストは、プロフェッショナルパートナーとの協力により行われる。Microsoft社はWindows 2000テスト、要件とプランの調整を行う。また、Rational Software社は開発用のツールを提供しており、このツールを開発のQAサイクルの中で使うことによって認定テストに従っているか、いないかが分かるようになっている。VeriTest社は実際の認定テストを行う。 ●ロゴプログラムのサインアップ方法 ・デスクトップアプリケーションのWindows 2000認定テストは9月7日にロサンゼルスで開始された。 ・東京とパリでのテストは11月に開始予定。 ・作業方法は下記のWebサイトに細かい情報がいろいろ入っているので参照願いたい。テストに直接関係するもの以外にもロゴの種類や価格表、テストプランやアプリケーション仕様書へのリンクも全てそこからできるので、一括でいろいろとご覧になれる。 http://www.veritest.com/mslogos/windows2000/ ●Windows 2000 Readiness Programとデベロッパー 認定プログラム以外にマイクロソフトの方でReadiness Programを用意しており、日本でもこれが行われると聞いている。Readiness Programは認定するためのサポートやトレーニングなどを無料でデベロッパーの方に提供するプログラムなので是非ご利用になっていただきたい。技術的な利点は、インターネット上でのQA、デベロッパートレーニーングの機会、開発ラボの優先アクセスや、Wedコミュニティ、プライベートなニュースグループなどがあり、また、営業やマーケティングの面からもマイクロソフトとの共同マーケティングの機会もあり、とても便利かと思う。 ● Directory of Windows 2000 Applications 一つのホームページで全てWindows 2000のアプリケーションの情報をまとめようということでマイクロソフトはWindows 2000 Applications Directoryを開発した。Windows 2000 対応情報に関して最も信頼できる顧客サイトである。これはサーチエンジンを通して各アプリケーションの次のような情報を検索できるようになっている。 ・製品名、説明、バージョン ・Windows 2000 対応状況 計画中 (近い将来に対応を予定) 動作確認済み (ISV が対応していると言っている) 認定済み (アプリケーション仕様への準拠をテスト済み) ・パッチをダウンロードするための ISV サイトへのリンク ここには、認定済みと表示されるようになっているので、アプリケーション仕様などを利用して認定テストを受けて合格された場合はお客さまからのより高い支援が得られるかと思う。 (4)リソース 今まで説明したリソースのWebアドレスを次に示すので、是非参照して欲しい。 ・Directory of Windows 2000 Applications（米国 Microsoft社） http://www.microsoft.com/windows2000/ready ・Readiness Program（米国 Microsoft社） http://msdnisv.microsoft.com/msdnisv/win2000/ ・Windows 2000 アプリケーション カタログ http://www.2000dev.com/w2000/appscatalog/ ・Windows 2000 アプリケーション への登録 これは日本のマイクロソフトのリンクなので完全に翻訳された日本語版のアプリケーションの仕様書もある。 http://www.microsoft.com/japan/windows2000/appsreg/default.htm ・Online Special Interest Group http://msdn.microsoft.com/osig/win2000 ・Windows 2000 アプリケーション仕様 http://www.microsoft.com/japan/developer/msdnisv/windows2000/appspc.asp ・VeriTest テスト プログラム http://www.veritest.com/mslogos/windows2000 (5)VeriTest社の紹介 ●VeriTest社は、昔からテスティングを専門にやってきた会社であって、今年の１月からLionBridge社と合併してテスティングサービスを米国のカリフォルニアだけでなく全世界で計上できるようになった。LionBridge自体はテスティング以外にローカリゼーションとインターナショナリゼーションを中心に作業としてやってきた。 VeriTest社は、 ・広く信頼されている独立マイクロコンピュータラボである。 ・1987年以来ハードウェアとソフトウェアのデベロッパーにサービスを提供してきた。 ・総合的なテストプロジェクト管理、テストアーキテクチャ、スクリプト、テスティングを行っている。 ・LionBridge Technologiesとの合併によってグローバルテストネットワークを形成した。 ●テストのタイプ VeriTest社が行っているテストには３つのタイプがある。 ・タイプ１：ローカリゼーションに関係するテストで、言語面での画面用のテストが中心になる。ローカラーズされたもののGUIなど、例えば日本語化された場合は全てのメニューが日本語になっているのを確かめたり、文字化けがないか、メッセージが切れたりしてないかなどのチェックを行う。標準テストサイトはアイルランドにあるが、日本のサイトでは日本語化についてのテスティング作業を行っている。 ・ タイプ２：技術面でハードウェアとソフトウェアの互換性、ベータ機能、規格準拠のテストを行っている。標準サイトは、ロサンゼルス、パリ、東京にある。 ・ タイプ３：実際お客さんのサイドでいろいろソースコードを見ながらコンサルティングするような仕事を提供している。I18Nコードの確認、E-テスト、企業アプリケーションの相互作用とスケーラビリティなど。 ●VeriTestのロゴ認証プログラム ・業界でのロゴ認定プログラムの定義、確立、実施における確固たる経験をもつ。 ・1994年以来、ロゴプログラムにおけるテストの要領と方法についてMicrosoftにアドバイスしている。 ・独立した自社製品のない第3者としてのテスト機関となっているので顧客からの信頼をおいている。 ・独立ラボとしてデベロッパーが規格に準拠するための支援を行うなどユニークな役割をしている。 ●次のようなMicrosoftソフトウェア対応プログラムの認定ラボである。 ・Windows NT、Windows 98 ・Windows CE ・Visual Basic for Applications ・Terminal Server Testing Program ●ソフトウェア ロゴ テスト BackOffice向けプログラムテストは、ロサンゼルス・パリで実施しており、東京でも近日中に実施したい。 ●主要ロゴ認定プログラム公認ラボ Windows用ソフトでMicrosoft社以外に、BMC SOFTWARE社、 ORACLE社、 AutoCAD社などのソフトウェアのロゴプログラムを行っている。 ●LionBrige社のグローバルサービスインフラストラクチャ 世界７カ国（米国、アイルランド、フランス、オランダ、日本、中国、韓国）に12拠点があり、社員は約450人おり ローカリゼーションやテストなどを中心にやっている。また。8月中旬にNASDACで株を公開させていただいた。 ここで出席の皆さんのアンケートからのご意見をご紹介いたします。 第１部では、「互換性チェックの要点を4つにまとめられ、時期を得たテーマである」、「アプリケーションベンダーに発生するであろう問題がよくわかった」、「一部初歩的、常識的な内容も含まれていたが、全体として有用な内容であった」、「問題点だけでなく解決法や今後の方針も示されていて大変ためになった」、「細かい部分まで詳しく説明されたので有用だった」、「概要としてはよくわかった。『アプリケーション仕様』を参照させてもらって内容を確認したい」、「Windows 2000対応アプリにおける注意点などがいろいろ分ったのでとても参考になった」、「Tech･Edセミナーで聞いていたので分りやすかった」、「side-by-sideの話がなかったのが残念」、「side-by-sideのDLLのインストールに関して聞きたかった」、「もっと細部の説明が欲しい」です。 第2部では、「アプリケーション仕様の概要に時間をかけていただいたので理解が深まった」、「Windows 2000対応のアプリをデザインする上で有用な情報が得られた」、「今後もWindows認定プログラム関連についてはこういった場を希望する」、「認定テスト等の内容の概要がある程度分った」、「Windows2000について今後の調査を行う上で有用な情報を得ることができた」、「情報へのポインタを教えてくれたのは有用だった」、「担当部門は開発ではないが、このようなシステムの概要を知ることは有益である」２件、「URLが紹介されていたので後で見にいきたい」。「実際のロゴテストの申込手順等を説明して欲しかった」。「説明がやや駆け足気味であったのが残念」です。 セミナー全体としては、「時宣を得たテーマである」、「開発でなくサポート担当であるが、このようなセミナーは有益である」、「全体を通してWindows 2000の概要がよく分った」、「Windows 2000に向けた大きな流れというものがよく分った」、「情報を得たのは有用だった」2件、「MFCを使ったActiveXコンポーネントを開発・販売しているがMSが推奨するインストール方法では、ActiveXコンポーネントを使って作成したアプリをユーザーが配布するのは非常に難しいのではないか？ シンプルかつ安全な方法をきちんと提供して欲しい」です。 今後希望するセミナーは、「Windows Installerに的を絞ったセミナー」、「MSIの詳細な説明を行うセミナー」、「Windows 2000関連で初心者向けセミナー」、「Windows 2000のセミナー」、「SQL関連」です。ありがとうございました。 |
