http://www.pcausa.com/resources/qandis2k.htmをいーかげんに翻訳。 翻訳精度・内容は保証なし。質問不可。 ----------- [英] What are NDIS "filter" drivers and how to they relate to NDIS intermediate drivers? [日] NDIS 「フィルタ」ドライバとは何ですか。そして、NDIS中間ドライバと どういう関係にあるのですか。 [英] An NDIS filter driver is a special case of an NDIS intermediate driver. [日] NDIS フィルタドライバは、NDIS中間ドライバの特殊なケースです。 [英] A filter driver binds the adapter below it _exclusively_, exposes exactly _one_ virtual adapter per bound adapter, which has the same upper edge as the adapter below it. [日] フィルタ・ドライバはその下でアダプターを*排他的*に結び付け、アダ プタごとに、*1つ* の仮想アダプタを、正確に公開するものです。仮想アダプ タは、その下でアダプタのように 同じ上位のエッジ((訳注:APIと言ってもよ いかも)を持っています。 [英] In contrast to general NDIS intermediate drivers, filter drivers offer builtin installation support for the virtual adapters, which is documented in the DDK. [日] 一般的なNDIS中間ドライバに対比して、フィルタドライバは組込みのイ ンストールサポートを仮想アダプターに対して提供します。これは、DDKに記 述されています。 [英] Non-filter intermediate drivers require a Notify Object for installation (see next question). [日] 非フィルタ中間ドライバは、インストール(下記質問を参照)のために、 通知オブジェクトが必要となります。 ----------- [英] How do I install an NDIS intermediate driver in Windows 2000? [日] どのように、私はNDIS中間ドライバをWindows 2000にインストールすれ ば良いのですか? [英] An NDIS intermediate driver consists of two parts: [日] NDIS中間ドライバは、2つの部品から成りたっています。 [英] A protocol portion and a miniport portion, which exposes the virtual adapter(s). [日] それは、プロトコル部と仮想アダプタ部で、仮想アダプタ部は、仮想ア ダプタを公開しています。 [英] You need two INF files, one for each portion. [日] 上記のそれそれに対してINFファイルが必要となります。 [英] The user will install using the protocol INF. [日] ユーザーは、プロトコルINFを使って、インストールを行います。 [英] This INF must a) include the copy operation of the miniport INF and b) specify a Notify Object (see next question). [日] このINFは、 a)miniport INFのコピー・オペレーション b)通知オブジェクト(次の質問参照)の指定 を必要とします。 [英] You should use the ExcludeFromSelect directive in your miniport INF so that the user can't install it by accident. [日] ユーザーが偶然にそれをインストールすることができないように、 miniport INFにおいてExcludeFromSelectを使わなければなりません。 [英] The PASSTHRU sample in the Windows 2000 DDK contains two samples INFs that explain how to do this. [日] Windows 2000 DDKでのPASSTHRUサンプルは、これをする方法を説明する2 つのサンプルINFを含んでいます。 ----------- [英] Do I need a Notify Object to install my NDIS intermediate driver in Windows 2000? [日] 私は、私のNDIS中間ドライバをWindows 2000に取り付けるために通知オ ブジェクトが必要ですか? [英] Unfortunately, you do (unless your IM happens to be the special case of a "filter" driver, see above). [日] 残念なことに、答はYesです。(あなたのIM(Intermediate)が、たままた 「フィルタ」ドライバでなければ、上記を参照して下さい) [英] The reason is that you'll have to call NdisIMInitializeDeviceInstance() at some point in your ProtocolBindAdapter() function - and you need the device name of the instance of the miniport portion installed for that adapter. [日] その理由は、あなたがProtocolBindAdapter()において、 NdisIMInitializeDeviceInstance()を呼ぶことになるからです。そして、そし て、あなたはそのアダプターのためにインストールされるminiport部のインス タンスのデバイス名が必要となるからです。 [英] The protocol can't find this out by itself - that's where the Notify Object comes into play. [日] プロトコルは単独でこれを発見することができません。−それは通知オ ブジェクトが行うことになります。 [英] It must install the miniport, retrieve its device instance name and put it in the protocol's parameters registry subkey, so that the protocol can retrieve the required information from there. [日] 通知オブジェクトは、miniportをインストールしなければならず、その デバイスインスタンス名を獲得しなければならず、プトロコルのパラメータレ ジストリーのサブキーに置かなければなりません。 そして、そのプトロコルは、そこから要求された情報を獲得できるようになり ます。 [英] The builtin filter support puts this information in the registry in your protocol's parameters key under Parameters\Adapters\ as value "UpperBindings" of type REG_SZ. [日] 組込みのフィルタサポートは、この情報を、タイプREG_SZの値 「UpperBindings」としてParameters\Adapters\の下のあなた のプトロコルパラメータキーの中に置きます。 [英] When you call NdisOpenProtocolConfiguration(), it'll try to open this key, so you best put your data in the same place. [日] あなたがNdisOpenProtocolConfiguration()を呼ぶとき、通知オブジェク トはこのキーをオープンしようとするので、あなたもあなたのデータを同じ場 所に置きます(訳者 意味不明) ----------- [英] What do I have to do in my NDIS intermediate driver's Notify Object? [日] 私は、私のNDIS中間のドライバの通知オブジェクトで何をしなければな りませんか? [英] Basically, you need to write a Notify Object that installs and removes instances of the miniport portion in its NotifyBindingPath() member function, retrieve the installed miniport's BindName, prefix it with "\Device\", and write it to the protocol's parameters subkey in the location mentioned above. [日] 基本的には、あなたは、通知オブジェクトを記述する必要があります。 通知オブジェクトは、NotifyBindingPath()メンバ関数の中のminiport部のイ ンスタンスのインストールとアンインストールを行います。また。あなたは、 インストールされたminiportのバインド名を獲得し、それに"\Device\"を付け 加える必要があります。また、上記に述べた場所に、プロトコルのパタメータ のサブキーにそれを記述します。 [英] Doing the installation and removal in NotifyBindingPath() has one drawback, though: [日] しかし、NotifyBindingPath()でインストールと除去をすることは、1つ の欠点があります: [英] The miniport instances will be _immediately_ installed and removed when the user checks/unchecks the protocol in the NIC's connection properties, cancellation isn't possible. [日] ユーザが、NICの通信プロパティにおいてプロトコルのチェック・アンチェッ クを行い、キャンセルができない時には、miniportインスタンスは、*ただち に*インストールまたはアンインストールします。 [英] The "right" path would be to defer all the installation and removal operations until ApplyRegistryChanges() is called - but this path is blocked by Microsoft: [日] ApplyRegistryChanges()が呼ばれるまで、「正しい」パスは全てのイン ストールとアンインストールの作業をを延期することになるでしょうが、この パスはマイクロソフトによってブロック化されます: [英] A "reentrancy" check disables these operations at that point (apparently Microsoft thinks developers are too stupid to realize that these operations might lead to their ApplyRegistryChanges() function to be called again, which could lead to endless installation loops if the developer doesn't take care of this by setting a flag and exiting immediately when the flag is set...). [日] 「リエントラント性」チェックは、そこでこれらのオペレーションを使 用禁止にする。(あきらかに、マイクロソフトは『開発者は、阿呆だから、こ れらの操作がApplyRegistryChanges()を再度呼んでしまうことや、開発者が、 フラグのセットやそのフラグがセットされた時の緊急終了によって、このこと を配慮しょなければ、無限のインストレーションループが発生してしまうこと に気がつかないだろう・・・』と考えているようだ) [英] If anyone knows of a better solution, I'd love to hear it! [日] 誰かがより良い解を知っているならば、聞きたいものです。 [英] To get started on writing the Notify Object, see the "SFilter" sample in the Windows 2000 DDK (found under ddk\src\network\config\filter). [日] 通知オブジェクトを書くためには、Windows 2000 DDK (ddk\src\network\config\filterの下の)で、「SFilter」サンプルを見なさ い。 ----------- [英] What flaws does Microsoft's "SFilter" sample Notify Object have? [日] マイクロソフトの「SFilter」サンプル通知オブジェクトは、どんな欠陥 を持っていますか? [英] How do I remedy them? [日] どうやって直せば良いですか [英] First off, the sample clutters up the registry with its typelib, which it never removes. [日] 第一に、そのサンプルはそのtypelibでレジストリを散らかしているし、 それは除去できません。 [英] The typelib is unnecessary anyway. [日] いずれにしても、typelibは不必要です。 [英] Just get rid off the .RGS and .IDL files and kill the typelib resource from the .RC file. [日] ちょっと.RGSと.IDLファイルを取り除き、そして、.RCファイルから typelibリソースを無くしてみて下さい。 [英] Use the DECLARE_REGISTRY() macro in your class definition instead of DECLARE_REGISTRY_RESOURCEID(), and remove the TRUE arg from the _Module.RegisterServer() call in DllRegisterServer(). [日] あなたのクラス定義でDECLARE_REGISTRY_RESOURCEID()でなくて DECLARE_REGISTRY()マクロを使ってみて下さい。そして、_ Module.RegisterServer()コールインDllRegisterServer()からTRUE argを削除 して見てください。 [英] Second, the DLL is not unloaded after the Notify Object is uninstalled. [日] 第二に、通知オブジェクトがアンインストールされたあと、DLLはアンロー ドされません。 [英] Actually, it's "cached" for 10 minutes after uninstallation, but you can rid of that delay: [日] 実際に、アンインストレーションの後、10分間それはキャッシュされま すが、その遅延は取り除くことができます。 [英] Change the threading model (now in your DECLARE_REGISTRY() macro) from both to "THREADFLAGS_APARTMENT" and call CoFreeUnusedLibraries() in your DllUnregisterServer() function prior to exiting. [日] 終了の前にあなたのDllUnregisterServer()機能で両方ともから 「THREADFLAGS_APARTMENT」とコールCoFreeUnusedLibraries()までスレッディ ング・モデル(現在あなたのDECLARE_REGISTRY()マクロで)を変更しなさい。 [英] That way, the DLL will be unloaded right after uninstallation, but unfortunately still not in time for a DelFiles directive in your INF to remove it (Microsoft is aware of this problem and concluded that they'll have to fix their binding engine for this to work). [日] こうすることによって、そのDLLは、アンインストールの後に、正常にアンロー ドされるが、残念なことに、DelFilesには間に合いません (マイクロソフトは、この問題に気がついており、修理の必要ありと結論した)