1B 一般発表セッション「開発事例」  40名程度の部屋に立ち見ありの状態で、活発な議論が行われた。 1B-1 WindowsCEにおけるCOMアプリケーション開発事例 株式会社SRA 中部支社 有賀 英樹氏 発表者はある組込み機器を開発するにあたり、WindowsCEとATLを利用した。 本発表ではその際に発生した諸問題に対しての意見および改善案を示し、ATL およびWindowsCEを利用した開発にはまだ問題が多いことを述べている。 開発にあたっての基本コンセプトは、「時代の進みに対して陳腐化しないこと」。 開発方法としては、NT版を先行開発(Rapid Prototyping)し、次いでWindowsCE 環境へ移植した。 使用ライブラリの検討では、Win32API,MFC,ATLの3つを検討。 ・MFC : GUI開発が楽 経験者多い <-> モジュールサイズ大 ・ATL : 軽量 これからの中核技術 CEで利用可 <-> 経験者いない ・Win32 : 最も軽量 基本API <-> GUI開発が難しい ということで、再利用可能でコンセプトに合っているATLを選択した。 開発環境は、WindowsNTホスト(VC++, CE ToolKit)を、ターゲットと、 RS-232C(ただし終盤からは、Ethernet)で接続した。 アプリケーションの諸元は下記の通り、 ・処理内容 : 取得したデータの表示 ・画面数 : 約30 ・アプリケーションレイヤモデル  画面制御モジュール : 1個 (アプリケーションに相当)  画面モジュール :30個 (画面一個一個に相当)  画面コンポーネント :20個 (画面内コントロールに相当) アプリケーション開発にあたって生じた大きな問題点は二つ。 1つ目は、パフォーマンス上の問題で、 ・起動時間遅い : COM初期化が2〜3割 ・画面切り替え遅い : COMプロパティ設定がほとんど ・画面更新遅い : 同上 解析の結果、結論としては、COMが遅いということになり、画面上の COMコンポーネントを減らすことで改善させた。 もう一つの問題は、メモリリークの発生で、Win32API内部で発生して いたことを発見するまでに約一ヶ月かかった。 これに関するベンダの対応は、不満の残るものだった。やりとりを箇条 書きすると下記のようになる。  MS: サンプル送れ  当方: サンプル送付  MS: ソースに不備  当方: 対応、しかし変化なし  MS: 使用方法が違う  当方: ヘルプを参考にした  MS: ヘルプが間違えている  当方: NTでは正常なのになぜCEでは?  MS: 数十Kはキャッシュ。200KはDLLロードによるもの     DLLに関してはFreeLibraryでどうにかしろ  当方: FreeLibraryでさらに400KBの増加  MS: メモリ増加はMSの責任と認定 (ATL内) 結果としては、Win32APIで書き直して問題は収束した。 ただし、提供された暫定修正モジュールはOS内部にまで達するものであった。 正式な修正モジュールの提供はなく、ATLは使用できるレベルに達していない と思えるとのこと。また、CEのように、ソースが公開されてないOS内に問題が ある場合の修正の難しさを実感したとのこと。 ベンダ提供のソフトに対しては、下記が要求される。 ・信頼性の保証 ・障害発生時の対応の早さ また、MSとしても ・サポート体制の充実を予定 ・WindowsCE3.0のソース公開を予定 ということで、期待はしているとのこと。 質疑応答 Q. MSがメモリリークをバグと認めるまでの期間 A. 2週間程度 (最初の報告から)  顧客激怒 -> MSの技術者が缶詰に -> バグと認定 Q.起動速度が遅いのは A.フラッシュからのロード時間  COMのプロパティ更新 Q.画面内のCOMコンポーネント数 A.50程度   全てインプロセスサーバ  -> 本当はもっと早いはずでは? Q.NT->CE移植時にパフォーマンス低下した可能性は A.NTでは問題自体発生していなかった Q.ターゲットハードウェアの性能 A.486程度の性能 Q.エミュレータの不具合を具体的に A.イベントが違う  エミュレータと実機とで動作の違う部分があった Q.パフォーマンスの問題に対する対応は  メモリリークで使い物にならなくなった  -> パフォーマンスの如何のよらずこの手法は破棄  結果として検証には至っていない 1B-2 汎用OSを利用したAV情報家電の構築に関する報告 副島 康太氏 (日本鋼管株式会社 電子デバイス本部) 情報家電機器用アプリケーションの検証には多くの時間を必要とする。この 問題に対し、テストベッドとしてPC, Linux, JavaVMをテストベッドとして 利用することで、より効率的な検証を行うことができる。本発表はその事例 を紹介したものである。 背景としては、情報家電のソフトウェアの大規模化 (インターネット対応 など多くの機能が搭載されてゆく)があり、特に接続検証などで多くの時間 を必要とするようになってきていることが挙げられる。 PC上でのプロトタイピングをする場合、 ・ハードウェア不要 ・ツール豊富 環境構築が容易 ・安価な既成ハードウェアを利用可能 ・デバイスドライバが豊富 というような利点がある一方で、 ・移植が必要 ・プロトタイプでの検証だけでは完璧とは言えない などの問題点がある。これに対する解決法として、 ・ターゲット移植時の修正点を少なくする という方法が考えられる。変更点を最小にし、再検証点も最小にする。 例えば、双方でJavaを利用する方法では、 ・CPU独立なコード ・組込みJavaの進出により一般的に ・情報家電はCPUがリッチ 双方でLinuxを利用すると、 ・APIが同一 ・組込みLinuxの出現 ・自由に手が入れられる (OpenSource) ・豊富なツールとライブラリ (さらにOpenSource) さらに、デバイス用共通APIを定義して、デバイスドライバやインターフェース の違いを吸収し、開発ホストとターゲット間で同一ソースを利用可能にすること が考えられる。 ターゲットをHAVi準拠の情報家電(FAVならJava必須)にすれば、 ホストコンピュータからターゲットコンピュータへ移植する場合でも、 HAViアプリケーションやHAViミドルウェアをJavaVMやIEEE1394-I/Fの上で そのまま使う形で動作させることが可能になる。 質疑応答 Q.IEEE1394コントローラは A.OHCI規格対応品 (MELCO社製) Q.Windows98対応はどこまで行うか A.デバイスドライバ以外の部分は行いたい Q.HAVi規格のLAVが紹介から外れていたが A.LAVは規格外の製品を示すものであるので除外した Q.タイミングチェックはどうするか A.実機でなければ無理。なるべく減らす方向へ。 Q.Linuxを使うことの利点 A.PCで動くこと,開発環境の構築が楽であること,欠点としては周囲が  何をしているかわからない Q.パフォーマンス検証とJavaVM A.コードの移植性は高い.JavaVM自体も移植可能に(?) Q.HAViが適用される機器の目安 A.例としてディジタルテレビなど。10万程度。 Q.検証レベルはどの辺か A.ロジックレベル. 時間制約は仕方ない Q.テストスィートのような連続テストへの対応は A.JavaVMとデバイスドライバを修正することで対応可能 Q.これはHAVi専用なのか A.HAViに特化したものではない  JavaVMを利用すると言う点でHAVi機器に有利と思っている。 (1B以上)