Windows シェル スクリプト (vbs)には、次のメソッドがあります。
object.GetObject(strPathname [,strProgID], [strPrefix])
次のコードがあるとします。
set myval = getObject("myObjectRef:myObjectArgs")
これは、あるマシンでは機能しますが、別のマシンでは機能しません。
私がやりたいことは、すべての myObjectRef/progIds が維持されている決定的なリストを見つけることです。
私の質問は次のとおりです。GetObject progid はどのように維持されますか?
仮定:
「レジストリを検索する」というより洗練された回答を探しています
うーん、これだけで十分なので、ちょっと難しいです。正確に「検索」する必要はありません。見つけられると予想される場所を確認するだけです。これは、regedit.exe の HKEY_CLASSES_ROOT ハイブのすぐ下にあります。キーはアルファベット順に並べ替えられているため、キーボードで「m」キーを入力するだけで、探している progid を既に閉じています。「myObjectRef.myObjectArgs」キーが表示されない場合は、実行時に COM が見つからないときに kaboom が発生する可能性があります。
「明確なリスト」はなく、progid が一意であることを保証するエンティティもありません。リストは各マシンに固有のものであり、そのマシンにインストールされていたものによって、Regedit.exe で何が返されるかが決まります。これらは、COM コンポーネントを見つけるために実際に重要な値である、GUID のわかりやすいバージョンにすぎません。サーバーを明確に識別するグローバルに一意の ID。progid キーの CLSID サブキーは、その GUID を提供します。それは大きな数であり、あまり人間に優しくありません。
progid キーは、コンポーネントがそれ自体をインストールするときにレジストリに書き込まれます。したがって、キーが見つからないということは、それがインストールされていないことを意味します。
64 ビット バージョンの Windows を起動するマシンでよくある問題は、COM サーバーが 32 ビット コンポーネントとしてしか利用できないのに、クライアントが 64 ビット プロセスであることです。これはレジストリでも解決され、CLSID キーは HKLM\Software\Wow6432Node\Classes にのみ存在します。Wow6432Node セクションは、32 ビット クライアントに表示されるものです。そのため、64 ビット クライアントは HKLM\Software\Classes を調べても、キーが見つかりません。実際には存在するにもかかわらず、「インストールされていない」問題のように見えます。それの64ビット版ではありません。SysInternals の Process Monitor は、このような問題を診断するための優れたツールです。失敗したクライアント プログラムがレジストリを検索していることがわかります。