今日の出来事 (Jun, 2008)

VMware Workstation 6.5β2 e.x.p Build 99530 公開...

　VMware Workstation 6.5β2 が 24 日 (現地時間 23 日) に公開されましたので， 当日ダウンロードを行い昨日まで 5 日間ずっと格闘していました。(笑) 　格闘内容はともかく， まずは改善点など…とは言っても， 個人的に Unity Mode は興味がありません (使うことがない。) ので， Direct3D 方面に限定されるわけですけれど…。 いえ， Direct3D も頻繁に使用するわけではありませんが， それくらい取り上げませんとネタがなくなってしまいますので。 (^^;)

　まず， 地味ながらも意外と貢献度の高いと思われるのが， カーソル表示の改善です。 Build 91182 までは Direct3D 方面のサーフェス上で頻繁にカーソルが ちらついていましたが， Build 99530 では解消されています。 「ちらつき」と書いていますが， 普通の ちらつきと異なり この場合の「ちらつき」とは， 「VMware が決定しているカーソル表示の際の描画領域全体が一瞬黒抜きとなる」というものです。

　これは， 処理が追いつかず前処理の初期化若しくは XOR 計算した段階で描画されてしまう…といった単純なものではなく， Build 91182 ではピクセル シェーダー 2.0 の描画不具合にも繋がっていたものです。 解消されているわけですから， 当然ながら Build 99530 では， ピクセル シェーダー 2.0 も全く不具合なく描画されます。

　あと， Build 91182 では一部のオブジェクトが描画されない…というものがありました。 右上の画像で言えば， 煙や炎方面の一部オブジェクトが描画されていなかったわけですが， Build 99530 では全体が描画されるようになっています。 が， 良いことばかりではありません。 「オブジェクト全体が ちゃんと扱われる」ということは， 当然ながら それだけ処理が重くなり必要メモリーも増大することを意味します。 そして， それが格闘の原因でもあり 未だに敗北状態が続いているのでした。

　この内， 処理速度のほうは格闘とは何の関係もありません。 単純に重くなっただけです…その度合いが半端ではなかったりするわけですけれど…。 (笑)

　さて， 問題の使用メモリー増大ですが， 前にも書いたとおり VMware 6.5 ではβという理由もあると思いますが， 今のところは VRAM 容量が固定となっていて， 手元の Satellite WXW/78DW や Satellite TXW/69AW では 128MB となっています。 AGP には対応していませんから， AGP メモリーを利用しての追加も行われません。 なので， メモリーが足りなくなると その影響を受けたオブジェクトが黒抜きとなってしまいます。 Build 99530 は 91182 に対して使用メモリー量が倍加していますから， 黒抜きとなるオブジェクトも数倍となってしまいます。

　さらに， こちらが問題なのですが， Build 99530 では Compressed Textures が使えません。 といいますか， 使おうとすると一般保護エラーが発生します…特権レベルで…。 結果は…ゲスト OS のブルーサンダーを拝むか， ゲスト PC の実体である vmware-vmx-debug.exe が例外で落ちる (抜ける) かの どちらかとなります。 3DMark2001 辺りであれば強制的に 32/16 ビット Textures を指定することで回避できますが， Compressed Textures に固定されている 3DMark03 以降やゲームソフト辺りでは回避のしようがありません。 上の画像は その 3DMark03 のものですが， GT1 は たまたま問題が発生しないだけです。 GT2， GT3 やデモが仲良く落ちますし， 3DMark2001 は GT1～GT4 までデモを含めて全滅です。 …どころか， 3DMark2000 さえ動作しません。 (^^;;

　おそらく Build 91182 までで発生していたものも同様の問題だったと思われますが， Build 91182 の無差別的な発生とは異なり， Build 99530 では「落ちるところでは必ず落ちる」といったパターンに変わっています。 これは問題が単純化しているとも取れますが， 反対に「対処のしようがない」という側面ももっています。 何かというと， ゲスト側で DirectX 9.0 の同位体的な別バージョンを適用するとか， ホスト側のドライバーを変更する…といった手法で回避を図ることが出来ないわけです。

　それでも， 「何とか回避できないかしら？」と冒頭で書いたように昨日まで 5 日間， 出荷状態の ForceWare 156.61 から最新の 177.39 まで 15 種以上のドライバーを設定変更等も含めて試してみましたが， 結果は全く変わりませんでした。 もしかしたら とても単純な凡ミスによる一般保護エラー (バッファーオーバーフロー) 発生なのかもしれません。 (笑)

RW939si 雑感...

　火曜から使っている RW939si ですが， 昨日まで使ってみての感想なぞ…。 総論としては「価格 (定価ベース (とある参考価格で @46.8k。) では S900i と同等若しくは上。) のわりには， 感覚的に S900i よりも数ランク内容が劣る」というものになるかと…。

　まず， 一番気に入らないのが「新H システムを識別できない」というものです。 自身が使ってきた S900i どころか， その前の SG-350P…SG-290CW さえ識別できていたものが， なぜに今頃できないのかと…。 仕様表辺りでは '▲' マークで一応対応ということになっていますが， とても対応しているとは言えない代物です。 確かに仕様として「通常のレーダー波と同じ警報」と書かれていますし， 識別数としてもカウントされていませんが， それを曲がりなりにも '▲' マーク付きで「対応」と謳うのは誇大広告なのではないかと…。 撮影ポイントに入った途端「ステルスです」と警告されたところで， 何の意味があるのかと…。 後述するように誤爆が多いことから， Level 1 や 2 程度のレーダー警告も使い物になりません。 結果， データーに入っていない新ポイントでは全く無意味ですし， そうでなくとも「不定期的にスイッチが入る」というポイントには無力です。

　「識別している」というのであれば， 「H システムです」と しゃべらせたり表示したりするのに如何ほどの問題点が発生するというのでしょうか？ GPS のデーターだけが頼りで全く認識・識別していないからこその「通常のレーダー波と同じ警告」なのではないかと…。 現行世代の全レーダーが同様ですから， 特許は取得したものの， 別の特許が絡んでいて使えない…といった理由が存在するのかもしれませんね。 そうとでも解釈しないと， そういった仕様とした意図が理解できません。 どころか頭を疑ってしまいます。 (^^;;

　あ， SG-290CW→SG-350P の時点で止めた N システムのレーダー波による識別と同じく「GPS のデーターがあれば それで良い」というスタンスであるのなら， 1 か月毎 ほぼ確実にデーター更新の行われる都市圏だけで売ってください。 そうすれば買わずに済みますから。

　上の新 H システムの識別を行わない仕様的問題点とも絡みますが， 全般的に RW939si は電波の認識・識別能力が低いです。 感覚的には 5 世代くらい前でしょうか？ 例えば， 目前で事故処理を行っていた 4 度のケースを含めて， S900i や SG-350P では 20 回ほどカーロケを認識していますが， 横に並んだ RW939si は一度も認識していません。 実際に交通課御用達の警察車両を視認し その動向や圏外告知のタイミングなどから誤爆とは考えられないケースが 15 回ほど含まれているのにもかかわらずです。

　反対に， 誤爆の数も RW939si のほうが上です。 特に背景的電波に対する誤爆が多く， 下手にロック機能が存在することから， 最初から最後まで 1 時間レーダー警告しっぱなし…ということもありました。 一旦電源を切るとピタリと収まります。 おそらく中間的な微調整を行えないのでしょう。 S900i まで存在した 40km/h～60km/h でのスーパーモードが RW939si では無くなっていますから。 40km/h を超えると いきなりエクストラに入ってしまいます。 当然ながら， それは誤爆の増大に繋がってもいるのでした。 さらに， GPS 排除機能が存在しないことも影響しているのでしょうね。

　基本的性能が劣っている状態で識別数を誇ったところで全く意味がありません。 レーダーとして全く必要のない道の駅や SA/PA， 駐車場などをアイコン表示し， ワンセグやバックモニター， ナビと言った機能を付加している暇があったら， レーダーとしての本分を思い出して追求してもらいたいものです。

　Super Cat シリーズの購入で失敗したのは初めてですが， 買った以上は仕方がありませんので最長 1 年間くらいは使ってあげることにします。 とはいうものの， すでに買い換え対象となっていたりします。 (笑)

RW939si 到着...

　金曜に注文した RW939si ですが日曜の夜に「店舗納品」のメールが届きました…が， 結果論としては「店頭在庫が山ほどあるので買いに行くのじゃ」という状況だったようです。 注文せずとも土曜には買えたわけですね。 それはともかく， 今日の帰りに購入して帰宅後に取付を行いました。 ちょうど 2 年 (と 1 週間) の S900i は， 明日同僚のところへ お嫁に行く予定です。 [一覧]

『春色桜瀬』動作試験 on VMware Workstation 6.5...

　パープルソフトウェアの『春色桜瀬』体験版がダウンロード可能となりましたので， 試してみました。 とは言っても Web からダウンロードしたものではなくて TECH GIAN 8 月号の TG バージョンですけれど…。 いえ， こちらのほうが先でしたので。 Satellite WXW/78DW でも良かったのですが， せっかくですから ここは VMware Workstation 6.5 のゲスト Windows XP MCE 2005 マシンへインストールすることにしました。 前作等からシステムに大きな変更はありませんから， 実機で動作するのは判りきっていますので…。

　というわけで， 動作させてみたのが右の画像です。 背景アニメーションやズーム， エフェクトといった方面で DirectX 9.0c の機能を使用していますが， Direct3D 方面に限って言えば， どちらかと言えば 8.x レベルですので別段問題なく動いています。 ただ， 「どちらもβ版相当」ということで負荷が高いこともあって， サウンドの再生方面全般に影響が出てしまっているようですね。 再生が遅れたり， 途切れたり， (プログラムが) 想定外のループが発生したり…。 いや， 時節柄 重さよりも CPU コア温度のほうが問題かも…。 (笑)

　話変わって， 後ろに半分隠れて何やらエラーダイアログを表示しているのは， VMware Player e.x.p Build 91182 です。 Workstation 側では Windows Vista/XP/2k 全てで Direct3D が正常動作しているのに対して Player 側は どうなのかしら…と試してみたわけですが， 結果は敗北してしまいました。 仮想 PC の実体が同一ということもあって， Player で仮想 PC を起動すると それが WS 側のリストに反映されたりもするわけですが， フロントエンド側 (vmware.exe や vmplayer.exe) の違いも影響するのか， 同一の環境を動作させても Player で正常動作することは Vista/XP/2k 共に全くありませんでした。 どうやら RC 段階くらいへ開発が進まないと Player でのテストは無理のようです。

HH184S2 取付終了...

　11 日に注文した PIAA HH184S2 ですが， 月曜の 16 日に納品したものの平日では閉店前にディーラーへ辿り着くことは不可能…ということで， ようやく今日になって取付を行ってきました。 予想に反してといいますか， 頭から代車が用意されていて そのまま引き渡して一旦帰宅…という流れでした。 今回も開店と同時だったのですが， 作業が終了して引き取りに行ったのが 17:30 でしたから， 丸一日掛けた勘定となりますね。 待たせているわけではありませんから， 気楽に時間を掛けたのでしょう。

　技術料等の取付費用が ¥9k 近くだったのは予想より少し高かったかしら？ 以前行った (フォグの) ハロゲンバルブ交換だけでも ¥3k 程ですから， それからすると妥当な価格のような気もしますけれど。 何はともあれ， これで真冬の濃霧注意報にも多少は気楽に対処が可能となりました。 (笑) [一覧]

RW939si 注文...

　Super Cat の S900i を購入してから 2 年と， 個人的な更新サイクルには 1 年早いタイミングなのですが， 同じ Super Cat のシリーズである RW939si を注文してしまいました。 年会費は必要となりますが， SD カードを使ってのデーター更新が可能なことと， 探知方向の把握が可能である…， この 2 つの理由によるものです。 データー更新が可能ということで， 次の本体更新時期は延びるはずです…きっと…。 (^^;;

　RW949si が 2.8 インチという画面の大きさだけではなく解像度も上がっていたのなら， 何も考えず そちらを選択していたところなのですが， 同じ QVGA ということで こちらになりました。 …あれ？ そういえば， EL ディスプレーって止めてしまったのですね。 大画面， 多色表示競争には不利だったということなのかしら？ S900i が その EL ディスプレーなのですが， 落差が激しかったりすると少々ショックかもしれません。 まぁ， 納品される 1～2 週間後の お楽しみですね。 [一覧]

今年 (2008 年) の梅雨入り...

　昨日， 平年より 9 日遅れて梅雨入りしたわけですが， その初日が殆ど真夏日というのは辛いです…まだ暑さに慣れていませんので。 反対に， 「平年より 5 度ほど高く…」とか流れているのを聴くと「平年って そんなに低かったっけ？」と思ったりもするわけですけれど…。 まぁ， 昼も暑かったわけですが， それよりも午前 2 時頃のほうが堪えたような気がします。 25 度を超えていましたので…。 暑さで目が覚めてしまい， 10 分間だけ冷房を掛けたのは秘密です。 (^^;;

Wine 1.0 正式版登場...

　ついに Wine 1.0 正式版が登場しましたが…。 予想どおりといいますか， 手元で発生していた不具合については何一つ Wine 0.9.61β から改善されることがありませんでした。 結局， 結果論としては「ネイティブ (Windows) のモジュールを使わないと まともに動作しない」という点は 2000 年代初頭から変化が無かった…ということになりそうです。 要は 1.0 までについては「MS 謹製のモジュールを使おうが何だろうが， ○×のゲーム等が走ればそれで良い」という落としどころで満足してしまった…ということなのでしょう。

　拙作の UNLHA32.DLL や LHMelt については， Unicode アプリである点が幸いして日本語周りについては表示方面以外では気にしなくて済みますので， これ以上手を入れる必要は無さそうです。 何らかの対応は…，MS 謹製の NOTEPAD.EXE (メモ帳) でステータスバーが ちゃんと表示され， コモンダイアログも正常に表示 (要は Ver 5 に対応。) されるようになってから行うことにします。 といいますか， 対応しないことには 現行 Wine への対応コードが反対に不具合を発生させることになってしまいますので。 (笑)

　何はともあれ正式版の登場には感慨深いものがありますね。 Turbolinux 4.0 + Wine 990426 を使っていた頃が懐かしいです。 VMware Workstation 2 のページ冒頭の画像は 2001 年春相当のものですね。 Windows 2000 + VMware 2.0 + Turbolinux Workstation 6.0 + Wine 20001002 といった環境です。 画像自体は退役していた当該 PC を引っ張り出して 2004 年の正月 2 日に撮ったものですけれど。 (^^;)

VMware Workstation 6.5β の Direct3D と DirectX 9.0c の版...

　ゲスト Windows 2000 Professional 環境で Direct3D が正常動作しなかった VMware Workstation 6.5β ですが， ホストの設定もさることながら， こと手持ちの PC (Satellite WXW/78DW， Satellite TXW/69AW， dynabook SS LX/290DK， DynaBook G7/X19PDEW といった面々。) に限って言えば， (VMware Workstation 5 の頃からを含めて) 「特定のソフトに同梱された DirectX 9.0c」が鍵となるようです。

　特定のソフトというのは， 何度かネタにもしている『Pia♥キャロ動作検証版 魔女アラII』なのですが， この体験版相当のソフトは それ自体が， 同梱されている DirectX 9.0c でないと動作しなかったりします。 さすがに DirectX 10.x である Windows Vista は別ですが， それ以外については Windows XP だろうが Win2k だろうが， MS 公式サイトのものを含めて， ほかの殆どのソフトに同梱されている DirectX 9.0c でも動作不能で， 起動時に「DirectX 9.0c をインストールするのじゃ」と申告してきます。

　ホスト・ゲストの違いに関係なく同じ挙動を見せ， しかもゲストにおいては， 他の DirectX 9.0c では Direct3D 動作時にゲスト自体が落ちてしまうのでした。 含まれているモジュールが異なるのか， レジストリー設定が異なるのか…。 興味のある部分ではありますが， さすがに突き止めている時間は取れそうにありません。 (^^;; 　それはともかく， 過去に当該ソフトを実行したことはありますので， 結果論としては， いつの間にか DirectX 9.0c のモジュールが入れ替わっていたようですね。

　何はともあれ， これで VMware Tools が想定する Win2k～Vista については Direct3D が正常動作するようになりました。 画像は 3DMark2001 SE 等での動作確認のついでに動かしてみた『FINAL FANTASY XI Vana'diel Bench3』です。 動作したりしなかったりするようですが， 手元の環境は動作するクチのようです…といいますか， DirectX 8.1 世代ですから， どちらかと言えば「動作しないと困る」部類なのではないかと。 スコアは…正式版までは気にしてはいけません。 (笑)

　あと， 動作しないらしい『ゆめりあベンチ』も試してみましたが…。 こちらは DirectX の機能等ではなく， 「自身が知っているチップかどうか？」的な判断で動作しているような感じを受けます。 まがりなりにも 3DMark2000～3DMark05 の動作する環境に対して「このビデオカードでは～」と門前払いを食らわすのは， ソフト側の問題も大きいのではないかと…。 何かベンチ的なものを行っているパターンは考えられますね。 (^^;;

　あ， 件の固有 DirectX 9.0c ですが， 「それを適用することで動作しなくなるソフトは発生したことがない」という点が重要だったりします。

車検とナビデーター (2008 年春版) 更新...

　予定どおり， 昨日車検を行ってきました。 開店 (9:30) と同時だったということもあって 17:30 頃の引き取りだったのですが， ナビの書き換え (下手をすると 2 時間ほど掛かります。) を伴っていましたので， 当日のみで完結したのは意外でした。 当日で済むに越したことはありませんので， それで構わないわけですけれど。

　一応メンテナンスパックに入っていましたので手数料の類は免除されたわけですが， ¥61k 超の法定費用は別途支払となるわけですから， こと車検のみに関してはパックの有り難みは殆どゼロに近いですね。 (笑) 　その上， ナビの更新や (パック内容以外の) 交換等を行っていますから…。

　そのナビの更新ですが…。 地味に ¥1k 値上がりしていました。 (^^;) 　それはともかく， DVD セット等と価格を合わせるための「名目上の技術料」が高額に見えてしまいますね。 データーが @13,125.- なのに対して技術料が @1,575.- となっていますが， ナビのディスプレーを開いて書込用の機器を USB 接続， メニューからデーター更新を選択するだけ…という内容ですから， 作業だけなら誰でも行えます。 まぁ， パソコンの修理等を考えれば十分低価格ですけれど。 なお， 「機器の調達」という事務処理方面についてはデーターの価格に含まれていると解釈しての話です。 あ， 更新自体はディーラーと自宅間の 5km 程度で確認できました。 店舗間競争に敗北して比較的最近店をたたんだ近所のコンビニが， ちゃんとデーターから消えていましたから。 (^^;;

　次に交換組ですが， 交換自体は ATF だけです。 あとは下回りの洗浄・さび止め (ラス・プロ) と保証期間の延長処理ですね。 ブレーキパッドとシューの交換も お願いしてあったのですが， こちらは必要性が全くなかったようです。 結果， ナビの更新と合わせて ¥40k だったのですが， 高いのか安いのか微妙な価格です…。 (^^;;

　う～ん。 毎度ながら ¥100k を超えますねぇ～。 ……はっ。 来週フォグを弄りますから， これを合わせて考えると ¥170k ということになるのかしら？ (^^;;

HH184S2 注文...

　発売時 (今年の 2 月末。) から購入予定だった純正フォグランプ用 HID コンプリートキット PIAA HH184S2 ですが， せめて車検まで待ちましょう…と今まで待ちの態勢に入っていました。 が， その車検も今週末に行われますので， ようやくといいますか注文と相成りました。 納期が 1 週間ということでタイミングも丁度良いですし。 ついでというわけではないのですが， 車検の際にディーラーに交換 (取付) を お願いすることにします。 あ， 型番でお判りの方もあるかと思いますが， PLASMA ION YELLOW を選択しています。 個人的に黄色が お約束ですので。 (笑)

　その車検ですが， CATZ SUPER LED 1.25W CZLB03 という保険を掛けた上で LEXT105W-V3 のまま通してみる算段だったりします。 (すでにディーラーには申告済み。) 　これと もう一つ， 純正オプションながら LED デイタイムランプが懸案事項なのでした。 もっとも， 後者は純正オプションということで， 引っかかろうものならトヨタの責任において新品への交換等の対応が発生することになりますけれど。 (^^;;

　車検のついでにナビデーターの更新も お願いしているのですが， こちらは機材調達の関係で， HH184S2 と同時になるかもしれません。 [一覧]

Microsoft Office XP Professional の環境移行と認証...

　DynaBook G7/X19PDEW から仮想環境への移行作業の一貫として， 木曜日に Microsoft Office XP Professional をゲスト PC (毎度おなじみの開発用ともなっている Windows XP MCE 2005 環境。) へインストールしたのですが， 「あ～たは既にインストールしちゃってます」とインストール後の初回起動時に宣告されました。 おぉ～。 かなりの年数が経っているにもかかわらず ちゃんとカウントが有効となっているようですね。 ええ， 確かにデスクトップ (相当) とノートの 2 PC へインストールしていますから， ここで引っかかってくれないと却って「おやぁ～？」となってしまうところです。 (笑) 　既に 22 時をまわっていましたので， 即日の認証申請は諦めました。

　翌日 20 時過ぎ， 「この時間なら まだセーフでしょう」と電話したところまでは良いのですが…。 前にも思いましたが， 最初から担当者と直接交渉可能な方法も用意してほしいところです。 跳ねられると判っているのに数分掛けて 50 桁ほどの ID を入力させられるのは， 少々苦痛ですので。 それはともかく， DynaBook G7 からの移行であることをサポートの お姉さんに告げて， サクッと認証作業は終了しました。 自宅常駐組なので扱いはデスクトップとなっています。

　ちなみに， このタイミングでのインストールが， 実は 3DMark03 等の計測結果を Excel へ自動記録するためだった……というのは秘密です。(笑)

VMware Workstation 6.5β での Direct3D 使用可能 OS...

　一応 Direct3D に正式対応した VMware Workstation 6.5β ですが， (下手をすると正式版を含めて) ここには「Direct3D が機能するのは Windows XP だけ」という大きな落とし穴が存在します。 ドライバー自体は VMware Workstation 5 以降の Direct3D 対応組を含めた過去の版と同様， Windows 2000 以降で共通して使うことを意図して作られているのですが， WinXP 以外に対する調整を (現段階では) 言わば放棄した形になっているからです。

　VMware Workstation 6.5 では， ディスプレードライバーが VMware 5.0 以来の 11.5.1.0 (VMware Workstation 6 の場合。) に代わり 11.6.0.5 へ更新されていますが， このドライバーは新版の仮想 PC (vmware-vmx.exe 等。) への対応に伴い， こと Direct3D 方面に限って言えば新たに書き起こされたものです。 そのため， VMware 6.0 までの動作状況は一旦白紙にして考える必要があり， 右上画像のように， VMware 6.0 へ至るまでに正常動作するよう改善していた DirectX 8.1 レベルのソフトであっても， WinXP 以外では基本的に動作しません。 この辺りの状況は実は WinXP でも同様で， 単に ほかよりも調整が進んでいるだけであり， その辺りがホストの違いによる不安定さに繋がっていると言えます。

　ここで一番気になるのは， 「RC1， ひいては正式版までに WinXP 以外への対応が行われるのか？」という点です。 少なくとも現時点では， こと WinXP 以外については VMware 5.0 未満の段階まで後退してしまっているわけで， これが正式版でも同じとなると， WinXP 以外の仮想環境を使っているユーザーは， VMware 6.0 を使い続けるか他ソフトへ移行するしか無くなってしまいます。 Win2k 辺りを使っている場合でも「WinXP への移行を行えない」という理由で使い続けているケースが意外と多いでしょうし…。

　そもそも今回の シェーダー 2.0 方面対応化は， VMware 7.x 辺りでの WDDM 版ドライバー作成への布石として 「とりあえず WinXP (要は旧来のドライバー。) 上で DirectX 9.0c が (ほぼ) 正常動作するところまで開発を進める」 ものでしょうから， Windows 2000 等の切り捨て…ということも可能性としては あり得ます。 あまり考えたくはありませんけれど。

　ちなみに， 11.5.1.0 等 旧版のドライバーを使用して Direct3D 機能を有効にすることは出来ませんので， 念のため。 仮想 PC (vmware-vmx.exe) の更新に伴い Direct3D 方面が刷新されているわけですから， 言わば GeForce が載っている PC へ RAGEON のドライバーを適用するようなものです。

Jun.9,2008 追記

　上で「動かない」と書いていますが， Windows XP 以外では絶対動かない…という意味ではありません。 単に調整の進捗具合が異なるだけですから， 例えば手元の (ゲスト) Windows Vista Ultimate x64 辺りでは， x64 環境で動作さえすれば WinXP と同様に Direct3D 方面が正常に機能しています：

　ありがちな話ではありますが， 過去の OS である Windows 2000 よりは後継の Vista のほうが相性が良い…ということのなのでしょう。 元々のターゲットが Vista でもあることですし。

Jun.15,2008 追記

　Windows 2000 でも正常動作するようになりました。 手元の環境に限っての結論としては「(ホスト側の) ドライバー設定要件を満たした上で， ゲスト側には固有の DirectX 9.0c を適用しておく」ことで Direct3D が使えるようになるようです。 VMware 5.0 以降で (つまり初期から。) 有効。 (^^;;

VMware Workstation 6.5β のデバッグログと Direct3D...

　Satellite WXW/78DW 上でも Direct3D 機能が正常動作するようになった VMware Workstation 6.5β ですが， 細かい部分ではソフトによって正常に描画されなかったりと， 安定度の面においては まだまだ改善の余地がある状況です。 RC1 までに どれくらい改善されるのか…といった辺りは もちろんですが， ホスト側による影響についても興味のあるところでしたので， デバッグログを参照してみました：

のように おっしゃっています。 3 つほど未対応の機能が存在すると申告しているわけですが， 最初の GL_EXT_texture_filter_anisotropic については， 直前で取得している対応機能リストに含まれているものです。 意図的に無視しているのか何らかの原因が存在するのかは判りませんが， 異方性フィルターはソフト等の設定項目辺りでも お目に掛かる機能ですから， (結果として) 未対応扱いとなっているのは ちょっとだけ気になります。 (^^;)

　後の 2 つはリストにも含まれていませんから， 単純に機能が存在していないことになりますね。 glWeightPointer は GL_ARB_vertex_blend 拡張で使用するウエイト数なので読めない…ということでしょう。 この辺りがバーテックスやシェーダー方面の (色数が簡素化されているなどの) 微妙に正常描画されない辺りへ影響しているのかどうかは不明です。

　昨日， 正常動作報告のある 3DMark05 や『タイムリープぶーとべんち』を試してみましたが， 前者は一般保護エラー等の不正動作は無かったものの， 根本的に描画が追いついていない感じでした。 一方， 後者は HDM やセルフシャドウ等の環境光方面を有効にすると正常描画されませんでした。 これらの「まともに描画されない」現象が発生した際には：

のログが盛大に (1～2ms 単位。 ^^;) 出力されます。 要はフレームバッファーのメモリーを使い果たしたということなので， その影響を受けた部分が黒抜きとなってしまったりしています。 これが， 仮想環境の画像メモリー量の影響を直接受けているのかどうかは判りません。 ちなみに， WXW や Satellite TXW/69AW 上では， ホスト (256MB) の半分なのかどうかは判りませんが， 自動でも手動設定でも強制的に 128MB となります。 そのわりに 3DMark 方面は 256MB と報告してきますけれど…。 この辺りの不整合も影響しているのかもしれません。

　3DMark03 の申告値について， ホストとゲストで異なる部分には以下のようなものがあります：

　一番大きく影響しているのは AGP メモリー方面でしょうね， やっぱり。 あ， この辺りはホストの GPU や設定状況が影響しているはずです， 念のため。 反対に， それ以外の部分についてはゲスト上でもホストと同じ…ということになるわけですが， そのことが不具合に繋がっている可能性も有りそうです。

　書き忘れていましたが， 当初 WXW 上のゲストで Direct3D 機能が正常動作せず落ちまくっていたのは， DirectX 9.0c の違いによるものではなくて， ForceWare での対応テクスチャークランプ設定が OpenGL 仕様となっていたためでした。 そういえば， VMware 5.x の頃から そうだったような気がします。 すっかり忘れていましたけれど。 (^^;; いろいろ試していた際に vmware-vmx-debug.exe に対して当該設定を行った覚えはありますので， 元に戻すのを忘れたのでしょう。 いえ， ForceWare のコントロールパネルは結構お馬鹿で， 追加プログラム設定については次回以降表示してくれませんから…。 そのくせレジストリーにはしっかり記録され， 適用も行われるという…。 なので， たまにはレジストリーを確認するようにしましょう。(笑)

週末のお買い物 (CD 編)...

　この週末に CD を 2 枚ほど買ったのですが， オリジナルが CD ではなくて LP レコードだった代物です。 その面々は以下のとおり：

VMware Workstation 6.5β の Unity モード...

　昨日， 何とか Satellite WXW/78DW 上でも VMware Workstation 6.5β の Direct3D 機能が正常動作するようになりましたので， 今日は Unity モードのテストついでに別口のソフトを試してみることにしました。

　白羽の矢が当たったのは， たまたま発掘しやすいところに DVD-ROM が転がっていた『なるかな』です。 『Wiz Anniversary』や『プリリン』よりも Direct3D への依存度が高いので丁度良いでしょう。 それに， わりとプロテクト方面での不具合報告が多かったソフトですから， ゲスト PC 上で正常起動するのかどうかも興味がありましたので。 ただ， 真の意味でテスト目的以外には使い道のなかったりするのが難点でした。 何しろ， ホスト側にインストール済みですから。 (笑)

　というわけで， 早速インストールして実行してみたところ…。 予想以上にサクサク動作している感じです。 ホストに比べれば遅いのは当然ですが， (実機の) Satellite TXW/69AW と比べても遜色ありません。 さすがにクオリティーは下がっていますけれど…。 ミッション時の 3D マップ等やエフェクト方面も正常動作しています。 どうやら， 『なるかな』はゲスト上でも大丈夫のようですね……本格的にゲスト上でプレーすることは有りませんけれど。(^^;)

　さて， 普通に動作することは解りましたので， お次は Unity モードです。 Build 84113 と違って右上画像のとおり一応正常動作はしていますが， 「当社比 1/5」という感じの速度で， DynaBook G7/X19PDEW よりも重いくらいですし， 頻繁にちらつきが発生したりもします。 こちらは まだまだ調整段階といった感じのようですね。 RC1 辺りで もう一度テストしてみることにしましょう……となると， それまで削除できないことになるのかしら？ それはともかく， ホストが Windows Vista ということもあってゲスト上の『なるかな』の見分けは簡単ですが， ホストとゲストが同じ OS だったりすると見分けが難しくなりますから， 実際には， 一目で区別が付くように専用の境界ラインが引かれています。

VMware Workstation 6.5β e.x.p Build 91182 の動作状況...

　先月半ばに VMware Workstation 6.5 の新しいβが公開されましたので， 即日ダウンロードして試していたのですが…。 リリースノートのとおりといいますか， 自身が遭遇していた不具合については全く改善されていませんでした。 大きな問題ではありませんが， 個人的には 3DMark03 CT2 でのハング問題だけは製品版までに改善してほしいところです。 3DMark だけで発生するのなら良いのですが， 「一旦発生すると， 当該仮想 PC を強制終了する以外選択肢がない」という現象なので， 普通に利用するソフトで発生するとダメージが大きいですから。

　と， ここまでは Satellite TXW/69AW 上での話です。

　昨日， 「遅かれ早かれ， いずれ本番環境で試す必要がある」ということで， 思い切ってメイン PC である Satellite WXW/78DW へインストール (要は 6.0.3 からのアップグレード。) してみることにしたのでした。 ゲスト PC の一つが開発環境となっている状況からすると無謀ですが， 先日 HDD の換装を行っていますから， 旧 HDD をバックアップ媒体代わりとして使えますので， 何かあっても大きな問題とはなりません。

　というわけで， 早速インストール。 何も考えずとも旧版が自動削除されサクっと新版へのアップグレードが終了しました。 さて， 犠牲者は……一番犠牲にしてはいけないはずの開発環境でもある Windows XP MCE 2005 マシンです。 これが動作しないと お話になりませんので， どのみちテストが必要なのでした。 そのままでも良かったのですが， せっかくですから VMware 6.5 のネイティブである Ver 7 の仮想 PC へアップグレードを行っておきます。 Accelerate 3D 設定のオンも忘れてはいけません。

　設定が終了しましたので次は起動です。 ログイン後…なにやら 10 個以上新デバイスの追加が行われました。 VMCI は良いとして あとはよく解らない基本デバイスばかりです。 「大幅な PC 構成変更でもあったのかしら？」とデバイスマネージャーを確認してみると， PCI 配下に基本デバイスが大量羅列されているだけでした。 が， タスクバーに これまでは見かけなかった「デバイス取り外し」のアイコンが表示されています。 クリックして表示されたリストは…PCI 配下のデバイス御一同様でした。 なるほど， 6.5 の新機能である PCI デバイスのホットプラグ絡みで追加されたもののようです。 6.5 上で新規に作成した PC は もっとスッキリしていたはずですから， アップグレードした場合は何かレイヤー的なデバイスが必要となるのでしょう。 いろいろとデバイスが追加・変更されたりもしましたが， 不思議と再アクティベーションは求められませんでした。 地味に有り難いです。(笑)

　お次は VMware Tools の更新です。 …が， インストーラーが転けてしまいます。 はぁ～…。 予想はしていましたが， またですか。 幸い 6.0の時と異なり， 手動でアンインストールした後は普通にインストールが可能でした。 そして， ここでも再アクティベーションは発生しませんでした。

　いよいよ， 3DMark03 のテストです。 うわっ。 何故か TXW 以上の紙芝居状態です。 ＞GT1 　しかも， 頻繁に仮想 PC が落ちます。 右上画像のように VMware 側がトラップできるのは まだ良いほうで， 一般のプログラムが抜けてしまうのと同じように そのまま初期画面に戻ってしまったり， ホスト側の入力方面を全て奪ったまま (ゲスト PC が) 無限ループに陥ってしまったりと， こと 3D 方面に関しては全く使い物になりません。 Ver 7 へのアップグレードが原因かも…と， Ver 6 へ戻してみたりもしましたが， 状況に変化は見られませんでした。 3DMark03 と一緒に TXW 上での動作実験を行った『Wiz Anniversary』や『プリリン』も同様に落ちてしまいますので， ソフトの違いは関係ないようです。

　そもそも 6.5 で作成された PC ではない点が影響している可能性もありますので， 外付け HDD 経由で TXW 上でも実験してみたところ…こちらは何の問題もなく動作しました。 (TXW 上で) 新規に作成された仮想 PC と全く同じで， 何の違いも見られません。 「それならば」と， GeForce 8700M GT のドライバーを TXW と同じ 174.31 へ再び引き上げたり， 出荷状態の 156.16 や兄弟 PC である Satellite X205 用の 156.64 へ引き下げたりしてみましたが， 変化はありませんでした。 どうやら「Satellite TXW/69AW 上で たまたま正常動作していた」だけで， ホスト PC 自体に (相性問題としての) 当たり外れが存在するようです。

　これは嫌な上に重大な問題です。 もし製品版までに改善されなければ， 6.0 止まりとなってしまい， 遠からず DynaBook G7/X19PDEW までの資産を捨てざるを得なくなってしまうことを意味します。

　ピクセルシェーダー方面が絡んだ状況については判りましたので， 次に問題となるのは「どこまで動作するのか？」です。 というわけで， 6.0 で動作していた面々を順番に試してみることにしました。 2 月にお遊びでインストールしたままとなっていた『秋色恋華』が動作しているところを見ると， DirectX 8.0 までは気にする必要がないようです。 なので， まずは 3DMark2001 SE を試してみたところ…こちらは何も問題ありませんでした。

　お次は VMware Workstation 5 以来の 3D 方面動作確認用基準ソフトと化しつつある『Pia♥キャロ動作検証版 魔女アラII』です。 …が， 起動時に怒られてしまいました。 毎度ながら， MS のサイトで落としてくる DirectX 9.0c とゲームが要求する DirectX 9.0c とは異なるようです。 更新後は正常に動作しましたので， どうやら VMware Workstation 6 レベルについては問題ないようですね。 最低線は守られている…ということでしょうか？ (笑)

　と， この段階で大きな違いの存在することが確定しました。 それは DirectX 9.0c です。 TXW 上の VMware 6.5 で新規作成した MCE マシンは更新版の 9.0c なのでした。 というわけで， 再び 3DMark03 や『Wiz Anniversary』を試してみたところ…正常動作してしまいました。 (^^;; 　が， 3DMark03 の挙動が全く異なっていて， WXW 上では「本来のフレーム数がカウントされるように仮想 PC 上の時間と実時間の比率が変わる」とでも言えそうな動作結果となります。 なので， 一つのテストに要する実時間が長大なものになります。 6.5 で手を入れた部分にデバッグコードか何かが埋め込まれていて， その辺りが影響しているのかもしれません。

　結果として WXW 上でも概ね正常動作するようになったわけですが， 少なくとも TXW 上では何の対処も必要なく同様のレベルで動作していたわけですから， ホスト側との相性問題が存在することだけは確かなようです。 今回の経緯で今は 174.31 のドライバーを使用していますが， こちらは先日書いたとおり 3DMark03 が正常動作しません。 が， 同じ 174.31 でも GeForce Go 7600 が載っている TXW では何の問題も発生しません。 巷のゲームでも「8x00 シリーズだと動作しない」という不具合が散見されますから， チップ自体に何らかの問題 (非互換性) が存在するのかもしれませんね。

Wine 1.0-rc2 とコモンダイアログ 5.0...

　24 日に登場した Wine 1.0-rc2 ですが， 一番改善してほしいコモンダイアログ Ver 5.0 への対応は行われていませんでした。 いえ， 修正予定リストにすら載っていなかったわけですから， 直るはずもないのですけれど。 とはいうものの， なぜ対応されないのかしら？ これが直らないと Windows 2000/Me 以降を前提としたソフト (で GetOpenFileName() API 等を使用するもの) は全滅なのですけれど…。