あれ？動いていたはずのツールが止まった。しかも２つである。コンピュータネタ、目次へ
正確には空振りした。正常終了はしたのだが戻りがカラである。ひとつはすぐわかった。毎日の電源のON/OFF時刻を記録するものを作っていたのだが、「スリープ」がデフォルトになったので、しっかり落としておかないと記録が残らないそうな。さっそくイベントビューアーをみて確認。イベント番号7001と7002の時刻も拾わないといけないのね、SQL部分を書き直してOKのはずだったが。(^^;あれ？うまくいかない。なんとシステムログにスリープと復帰の情報は残らないようだ。
どこかで足をすくってくれるよ、マイクロソフトは。もうひとつはさらに根が深い。Microsoft ExcelのVBAからシステム設定を取得していたのだが、中身がカラで戻ってきた。えー、なんでなんで。どうやらMS-OFFICEの64bit版はまだまだ安定度が低く、Windowsが64bitでも32bit版を使い続けるのがトレンドなのだそうだ。
この場合、32bitのアプリケーションから64bitのシステムをCallするので、値は戻るものの、アドレスが、ひょっとして上位32bitだけを受け取るのかな？とすると値は「ゼロ」。事実上何の値も戻ってこないな。理屈は分かるがすごく嫌だ。
あらためてVBAの「参照設定」を細かく勉強して、なるほどOSを呼んでいるDLLがWow「64」というフォルダの中にある32bitのものを使っているのが悪いのね。本当はSystem「32」というフォルダの中にある64bitのものを使わねばならない。（事情は分かるがなんとややこしいネーミング）。
ところがどうやっても参照設定が呼び込むのはWow64にあるDLL。コードの中でDLLを動的に、フルパス指定して64bit分を読み込んでもわざわざ32bitを探して読み込んでくれる。
意地でも読みこむこの執念はすごい。さすがの私もあきらめた。
仕方なくVBScriptで同等のものを書いて「こいつの出力を読み込むしかないかあ」で、うん32bitのWindowsでも64bitのWindowsでも同じように動く、ことを確認して周囲に「試してみて」とメールで投げる。が、
空振りする。
灰色の脳細胞がささやいた。「ひょっとしてメールソフトが32bit？だとすると、メールに添付されたままこのスクリプトを実行するとメールソフトの枠内にいるから32bitのDLLを呼んでしまって元の木阿弥。」ひょえ、尋ねてみると「メールソフトは32bitです。」
どうやらあたりだ。
ただしVBScriptの場合は「CallするDLLを入れ替えることができる」ということがわかり、えっとー、WMIでOSのビット数を確認して・・・。ものすごく長くなったが動くぞお。もっとも、WMIでいろいろ呼べることを知った私はOS情報のみならず
ユーザー名とかCPU情報とかGPU情報とかメインメモリ容量とかネットワーク情報とかインストールされたプログラムの一覧とか、
いろいろ引っ張り出してきた。VBScriptなら、スタートアップにも登録できるし、出力をUNCパスでも指定できることを確認した。つまり各ＰＣの情報をネットワークドライブに集約できる。これを集計できるツールを作るならそんなに面倒なことでもない。これ使うと、ネットワーク上のＰＣ管理、楽になるんじゃないかしら。
32bit、64bitどちらでも動くし。