Pervasive PSQL アプリケーションを使用してコンピューターからネットワーク ファイルにアクセスするためには、そのコンピューターで適切なクライアントを使用する必要があります。アプリケーションの Pervasive PSQL 呼び出しはクライアント リクエスター経由でサーバーに送られて処理され、その結果はアプリケーションに返されます。

一般的に、Pervasive PSQL Server と Client のデフォルト構成はそのまま使用しても問題はありません。通常、データベース エンジンとクライアントの通信や機能について設定を行う必要はありません。

この章は、以下のセクションから構成されています。

このセクションでは、Pervasive PSQL クライアントによって使用されるネットワーク通信用の設定について説明します。これらの設定の変更は、コマンド ライン ユーティリティまたは PCC 内のエンジン プロパティを使用して行うことができます

各設定の詳細については、『Advanced Operations Guide』で説明しています。『Advanced Operations Guide』で以下のネットワーク通信用のプロパティを参照してください。

リクエスターを使用しているときは、Pervasive サーバー エンジンに接続してデータ ファイルにアクセスします。このセクションでは、Btrieve または DTI アプリケーションを使用してネットワーク上のファイルにアクセスする際に使用できる、さまざまなネットワーク ファイルの構文を紹介します。

Pervasive PSQL では、多くの操作環境で、UNC（Universal Naming Convention）およびドライブ パス形式（明確かつ最新）が使用できます。

パス形式についての詳細は、以下のセクションを参照してください。

お客様がアプリケーション開発者である場合は、URI 接続文字列をサポートする Btrieve API などの特定のアクセス方法についても留意してください。URI 文字列の詳細については、『Pervasive PSQL Programmer's Guide』のデータベース URI 参照してください。『Btrieve API Guide』の Create（14）、Open（0） および Login/Logout（78） を参照してください。

以下の UNC パス形式は、すべてのクライアントからすべてのサーバーへのパス表記に対応しています。

UNC 構文は、ターゲット サーバーで実行しているネットワーク オペレーティング システム（NOS）の実際の種類に関係なく、正しく解決されます。IP アドレスを使用する場合は、ドット付き表記の IPv4 アドレス、または IPv6 用にサポートされる 2 つの形式のうちのいずれか 1 つを使用してください。IPv6 アドレスを参照してください。

以下のドライブ表記は、すべてのクライアントからすべてのサーバーへのドライブ表記に対応しています。

Samba を使用する Linux サーバーが受け取るパスは、相対的な優先順序で次のように処理されます。

smb.conf ファイルでは、<sharename>（共有名）を受け付けるよう設定する必要があります。そうでない場合は、デフォルトで次のようになります。

smb.conf ファイルが適切に設定されていない、またはターゲット サーバー上で見つからない場合は、絶対パスを使用します。

Pervasive PSQL v11 SP3 の Linux バージョンの詳細については、Linux での Pervasive PSQL の使用を参照してください。

Pervasive がサポートするアクセス方法を使用した Pervasive PSQL Client は、IPv4 の場合と同様に IPv6 を使用して Pervasive PSQL データベース エンジンを実行している IPv6 ホストへ接続します。つまり、Pervasive PSQL Client はサポートされるアクセス方法の 1 つを介してサーバーを指定し接続します。サーバーの指定は、Pervasive PSQL Server または Workgroup が実行されているマシンのマシン名または IP アドレスのどちらを用いても可能です。

このセクションでは IPv6 の以下の点について説明します。

未加工の IPv6 アドレスは、コロンで区切られた 8 個のセグメントで構成されます。各セグメントは 4 桁の 16 進数値として記述できます。たとえば、「1234:5678:90ab:cdef:1234:5678:90ab:cdef」と表記されます。このフレームワーク内では、IPv6 名のいくつかの形式が利用可能です。

一般に、数値の IPv6 アドレスは IPv4 アドレスよりも複雑で扱いが困難です。数値によるリンク ローカル アドレスには問題があり、特にゾーン ID に関しては顕著です。

そのような理由から、Pervasive はアドレス解決に DNS サーバー、LLMNR、ホスト ファイル、または他の手段でホスト名を使用することをお勧めします。IPv6 数値アドレスは状況によって（判別がつかないときは）角カッコ（[ ]）が必要となることが多いので、数値のアドレスが必要な場合はかっこを追加してください。

Pervasive PSQL がサポートするのはユニキャスト アドレスのみです。Pervasive PSQL で使用できるユニキャスト アドレス形式は以下のとおりです。

IPv6 にはアドレス修飾子が含まれています。この修飾子はショートカットとして機能したり、また詳細な宛先の指定に用いたりすることができます。 Pervasive PSQL は IPv6 に以下の修飾子をサポートします。

Pervasive PSQL は IPv6-literal.net 名、および角かっこ（[]）で囲まれた IPv6 アドレスをサポートします。

ipv6-literal.net 名は以下に示す 3 つの変更を施した未加工の IPv6 アドレスです。

例：

かっこ付き IPv6 アドレスとは角かっこで囲まれた未加工の IPv6 アドレスです。この形式は UNC（Uniform Naming Convention）で正しく動作するアドレスとしても参照されます。

例：

Pervasive ライセンス サーバーはまだ IPv6 をサポートしていません。このため、IPv6 上で License Administrator を使用しライセンスを管理することはできますが、そのユーティリティでライセンスを認証することはできません。ライセンスを認証するには、IPv4 ネットワークまたはリモート認証または手動認証を使用する必要があります。

Pervasive PSQL でトランザクショナル インターフェイス用に IPv6 を使用する際の制限事項を次の表に示します。

IP アドレスにポート番号を含める必要があるのは、デフォルトのポートを上書きする場合のみです。一般に、ポート番号はコロン（:ポート番号）またはドット（.ポート番号）を用いて IP アドレスに追加されます。

UNC 形式の名前（アドレスの表記を参照）は、ポート番号の追加をサポートします。

このセクションは、Windows サーバー プラットフォーム上で実行している Pervasive PSQL サーバーへの接続に TCP/IP を使用する場合について説明します。

TCP/IP ネットワークで Pervasive PSQL を操作する場合、クライアントは、Windows サーバーに割り当てられた名前からそのサーバーの IP アドレスを取得できなければなりません。IP アドレスから名前への変換を可能にする 2 つの方法があります。

以下に、上記のそれぞれの方法を使った IP アドレスのセットアップ方法の概要を示します。ネットワーク構成および設定のセットアップの詳しい説明については、オペレーティング システムのドキュメントを参照してください。

DNS を使用する場合は、お使いのコンピューターがサーバーのデータベース内でサーバーのアドレスを検索できるよう設定します。DNS の設定に必要な情報はネットワーク管理者に確認してください。

hosts ファイルではサーバー名と IP アドレスとの関係を手動で入力します。DNS が使用できない状況の場合は、この方法を使用します。

ブラウザーの設定に応じて、TCP/IP リクエストが送られる際、［Windows ダイヤルアップ ネットワーク］ダイアログ ボックスが表示される場合があります。通常、このダイアログ ボックスはインターネット接続を行うためのものですが、Pervasive アプリケーションおよび TCP/IP の使用中は、この機能が邪魔になることがあります。

このセクションは、Windows コンピューター上で実行している Pervasive PSQL サーバーへの接続に SPX を使用する場合について説明します。

SPX は、Windows プラットフォームのネイティブのプロトコルではありません。SPX を使用する場合は、以下の手順を実行し、Pervasive PSQL が正しく動作するようにします。

TCP/IP と SPX の両方がインストールされている場合は、Pervasive PSQL クライアン用の TCP/IP を削除し、Pervasive アプリケーションで SPX が機能するようにします。

Pervasive PSQL は 3 つのポートを経由して通信します。ファイアウォールやルーターでは、サーバー データベース エンジンとのリモート アクセス用に、以下のポートへのアクセスを許可する必要があります。

通常、競合がない限りポートを変更する必要はありません。

リレーショナル インターフェイスの場合、ポートの割り当て 1583 は、Pervasive PSQL の各種ユーティリティを通じてサーバー用に設定することができます。このポートはクライアント用に手動で設定できます。『Advanced Operations Guide』のTCP/IP ポートを参照してください。

ポートの割り当ては 3351 とし、これを変更しないことをお勧めします。変更する必要がある場合は、Pervasive サポートまでご連絡ください。

ポートの設定はサーバー マシンとすべてのクライアントの両者で必ず一致するようにしてください。

サーバーの受信ポートの変更後は、そのポートの割り当て変更を有効にするために Pervasive PSQL エンジンを終了して再起動する必要があります。『Pervasive PSQL User's Guide』のPervasive PSQL の使用の章を参照してください。

services ファイルは、オペレーティング システムで使用されるネットワーク通信用のテキスト ファイルです。この services ファイルで、Pervasive PSQL Server とそのクライアントで使用されるポートを手動で割り当てることができます。services ファイルで記載される適用ポートと、Pervasive PSQL のユーティリティおよび関連する Windows ファイアウォール規則で設定されるポートは必ず一致している必要があるので注意してください。

services ファイルでポートの割り当てを変更したら、その変更を有効にするために Pervasive PSQL データベース エンジンを停止して再起動する必要があります。『Pervasive PSQL User's Guide』のデータベース エンジンの起動と停止を参照してください。

Pervasive PSQL Server および Pervasive PSQL Workgroup をインストールする場合、Windows オペレーティング システムのバージョンに応じてファイアウォールに関する特定の動作が実行されます。

Windows Vista 以上のオペレーティング システムには、ファイアウォール プロファイル（セキュリティ設定のグループ）を提供する「セキュリティが強化された Windows ファイアウォール」があります。それらのオペレーティング システムではデフォルトでファイアウォールが有効になっています。次の表では、アクティブなプロファイルに関する Pervasive PSQL のインストール動作についてまとめています。

上の表でわかるように、パブリック プロファイルがその他の 1 つ以上のアクティブ プロファイルと共にアクティブな場合、Pervasive PSQL 規則はパブリック プロファイル用に追加されますが無効になっています。Pervasive PSQL Server または Workgroup のインストールが対話式またはサイレントであってもこの動作を変更することはできません。パブリック プロファイルの規則を有効にしたい場合は、手動で行う必要があります。Pervasive PSQL 規則をパブリック プロファイルに対して有効にするにはを参照してください。

Pervasive PSQL をインストールした後にネットワーク プロファイルを変更すると、Pervasive PSQL が通信を受け付けることができなくなるかもしれません。たとえば、インストール時はプライベート ネットワーク プロファイルのみがアクティブだったとします。インストール後のある時点で、アクティブ プロファイルがドメイン（この設定はプライベート プロファイルの設定とはかなり異なることが前提）に変更された場合、データベース エンジンはネットワーク経由で通信ができなくなります。

Pervasive PSQL の通信を妨げるようなプロファイルまたはファイアウォール規則を変更する場合は、Pervasive PSQL 規則をパブリック プロファイルに対して有効にするにはの手順を参照してください。この手順は、アクティブ プロファイルに対して Pervasive PSQL 規則を有効にする方法の一般的なガイドランとして使用できます。この手順を使用すればデータベース エンジンはネットワーク経由で再び通信できるようになります。

コーポレート ポリシーによっては、ローカル管理者が特定のマシンに対するファイアウォール プロファイルを変更できない（つまり、プロファイルがロックされている）こともあります。そのような場合、ロックされたプロファイルによって監視されるネットワーク接続経由でデータベース エンジンが通信するために必要なファイアウォール規則を、Pervasive PSQL のインストールによって追加したり有効にしたりすることはできません。そのような状況の場合は、権限を持つシステム管理者へファイアウォール ポリシーの変更を要請してください。この変更で Pervasive PSQL でインストールされるすべてのサービスと通信する全ポートに対し受信 TCP および UDP トラフィックを許可します。

また、ターゲット システムがドメインに参加している場合は、グループ ポリシーにより制御されているファイアウォール プロファイル上の規則の追加および有効化を Pervasive PSQL のインストールから妨げるものは、グループ ポリシーのみであることに注意してください。Pervasive PSQL をインストールしているユーザーが、ドメイン ユーザーとしてではなくローカル ユーザーとしてターゲット システムにログインしていた場合、そのインストールによってファイアウォール プロファイルに対する規則の追加および有効化が行われます。ただし、ターゲット システムが後でグループ ポリシーを制御するドメインへ参加する場合はその規則が無効になります。

Windows Server 2003 および Windows XP にはファイアウォール プロファイルが含まれていません。これらのオペレーティング システムで、Pervasive PSQL Server および Pervasive PSQL Workgroup をインストールすると、Pervasive PSQL の各サービスが Windows ファイアウォールの例外リストに追加されます。オペレーティング システムのセキュリティで、Pervasive PSQL コンポーネントとの通信のブロックを解除または通信を許可するよう促された場合は［OK］（はい）を選択します。

Pervasive PSQL のインストールの結果、Windows ファイアウォールを介した全ポートで Pervasive PSQL サービスと通信する受信 TCP および受信 UDP トラフィックを許可する 1 つ以上のファイアウォール規則が追加されます。Pervasive PSQL で使用されるデフォルトのポートを変更する必要がある場合に備えてすべてのポートが使用されます。

インストール後にクライアント/サーバー アプリケーションが正しく動作しないという問題が発生した場合、ファイアウォール アクセス リストまたはポートを確認してください。クライアント/サーバー アプリケーションを有効にするには、セキュリティ設定を調整する必要があるかもしれません。ファイアウォール アクセス リストに Pervasive PSQL 実行可能ファイルを追加する、またはポートを開くことができます。これらの作業を両方とも行う必要はありません。1 つのポートを開くと、そのポートは Pervasive PSQL に対してだけでなくすべてのアクセスに対して開くことに注意してください。

ファイアウォール アクセス リストに Pervasive PSQL コンポーネントを追加する場合は、以下のファイルを追加します。

Windows ベースのクライアントを使用するネットワーク（ドライブの割り当てを使用）の場合は Linux サーバーで Samba が適切に設定されている必要があります。

TCP/IP ネットワークで Pervasive PSQL を操作する場合、クライアントは、Linux サーバーに割り当てられた名前からそのサーバーの IP アドレスを取得できなければなりません。IP アドレスから名前への変換を可能にする 2 つの方法があります。

以下に、上記のそれぞれの方法を使った IP アドレスのセットアップ方法の概要を示します。ネットワーク構成および設定のセットアップの詳しい説明については、オペレーティング システムのドキュメントを参照してください。

DNS を使用する場合は、お使いのコンピューターがサーバーのデータベース内でサーバーのアドレスを検索できるよう設定します。DNS の設定に必要な情報はネットワーク管理者に確認してください。

Windows プラットフォームのクライアントの場合：

hosts ファイルではサーバー名と IP アドレスとの関係を手動で入力します。DNS が使用できない状況の場合は、この方法を使用します。

TCP/IP リクエストが Windows に送られる際、［Windows ダイヤルアップ ネットワーク］ダイアログ ボックスが表示される場合があります。通常、このダイアログ ボックスはインターネット接続を行うためのものですが、Pervasive アプリケーションおよび TCP/IP の使用中は、この機能が邪魔になることがあります。

エンコードは文字セットを表す標準規格です。文字データは、コンピューターがデジタル処理できる標準形式に変換する、つまりエンコードする必要があります。エンコードは、Pervasive PSQL データベース エンジン（サーバー）と Pervasive PSQL クライアント アプリケーションとの間で規定する必要があります。互換性のあるエンコードを使用すれば、サーバーとクライアントでデータが正しく変換されます。

Pervasive PSQL v11 SP3 では、クライアントとサーバー間のエンコードの複雑性、およびオペレーティング システム、言語、アクセス方法のさまざまな組み合わせへの対処がより改善されました。エンコードの機能拡張は、データベース コード ページとクライアント エンコードに分割されています。この 2 種類のエンコードは、別個のものですが相互に関係しています（表 7 を参照してください）。

2 つのエンコード方法は上級ユーザー向けです。一般的には、デフォルトのエンコード設定で十分であり変更の必要はありません。

データベース コード ページおよびクライアント エンコードは、リレーショナル インターフェイスのみに適用されます。トランザクショナル インターフェイスには影響しません。

ここでは、以下の項目について説明します。

データベース コード ページはデータベース コード ページという新しいプロパティで指定します。このプロパティはデータベースとメタデータに使用するエンコードを識別します。デフォルトのデータベース コード ページは "サーバーのデフォルト" で、データベース エンジン実行中のサーバーのオペレーティング システム（OS）コード ページを意味します（OS のコード ページは一般的に「OS エンコード」と呼ばれ、この章のこれ以降の説明ではこの表現を使用します）。

データベース コード ページは、異なる OS エンコードを使用して Pervasive PSQL DDF を手動で別のプラットフォームへコピーしながら、データベース エンジンにメタデータを正しく変換させたい場合に特に役立ちます。

クライアントのエンコードは、Pervasive PSQL クライアント上のアプリケーションが使用するデータ エンコードです。アプリケーションは、任意に選択したエンコードでデータを格納することができます。ただし、前に述べたように、データベース エンジンとクライアント アプリケーション間では互換性のあるエンコードを定める必要があります。以前のバージョンの Pervasive PSQL では、データベース エンジンとクライアント間でエンコードの互換性を確実にする方法がありました。

これらの方法は、データベース コード ページを利用するように機能拡張されました。アプリケーションは、Pervasive PSQL クライアントがデータベース コード ページとクライアント アプリケーション間でデータを自動的に変換するように指定することができるようになりました。これは、自動変換と呼びます。ただし、自動変換によって文字を変換するのは、それらの文字が両方のコード ページ（サーバー マシンのコード ページとクライアント マシンのコード ページ）に存在する場合のみであることに注意してください。

自動変換は、クライアント アプリケーションがデータベース エンジンに接続したときに指定されます。『SQL Engine Reference』の ODBC 接続文字列を参照してください。

データの変換は、要求に応じてクライアントで行われます（変換はいつも必要なわけではありません。たとえば、クライアントのオペレーティング システム（OS）エンコードがサーバーの OS エンコードと一致している場合は不要です）。

次の表で、データベース コード ページとクライアント エンコード間の相互の影響を説明します。

データベース内に OEM 文字データがある場合、旧来の解決法は DSN を使用する ODBC のようなアクセス方法を使用して OEM/ANSI 変換を指定することでした。このバージョンでは、データベースに OEM コード ページを設定し、アクセス方法で自動変換を使用することが可能になりました。『SQL Engine Reference』のエンコード変換も参照してください。

データベース内に OEM 文字データがある場合、旧来の解決法はアクセス方法で OEM/ANSI 変換を指定することでした。ここでは、OEM 文字データを使用する Linux クライアント向けに旧来の方法について説明します。

Btrieve API または DTI（Distributed Tuning Interface）を使用する場合は、アプリケーションで使用されるローカル エンコードでファイル名とパスを提供する必要があります。Btrieve API や DTI は、サーバーおよびクライアント上の OS エンコード間の相違に対処します。

『SQL Engine Reference』の OEM/ANSI 変換も参照してください。

ODBC を使用する場合、エンコードは、 Win32 のOSでは SHIFT-JIS を使用してください。

日本語版の Linux は一般的にデフォルトでそのエンコードを EUC-JP または UTF-8 に設定します。

日本語版の Linux を使用している場合、クライアントは別の Linux サーバー（たとえばローカルに）、あるいは Win32 の SHIFT-JIS サーバーに接続できます。Linux サーバーに置かれている SHIFT-JIS にエンコードされたデータベースに接続することも可能です。

以下に示す手順を使用して必要な設定を行ってください。これらのケースは、アプリケーション自体は何も変換を行わず、そのマシンのネイティブのエンコードを使用することを前提としています。

このサーバーで受け取るものはすべて SHIFT-JIS でなければいけません。サーバーからクライアントに送られるものはすべて EUC-JP でなければいけません。

これを達成するには、指定のデータベースへの接続に使用する ODBC.INI（デフォルトで /usr/local/psql/etc にあります）内のクライアント DSN 設定が次のようになっている必要があります。

TranslationDLL の行は ODBC クライアント インターフェイスが使用する変換ライブラリを指定しています。

TranslationOption の行は、この変換で 9000（EUC-JP）から 0932（SHIFT-JIS）が必要であることを指定しています。

この例を使用すると、クライアントからのすべてのデータがサーバーに送られる前に SHIFT-JIS に変換され、クライアントがサーバーからデータを受け取る前には EUC-JP に変換されます。

このサーバーで受け取るものはすべて SHIFT-JIS でなければいけません。サーバーからクライアントに送られるものはすべて UTF-8 でなければいけません。

これを達成するには、指定のデータベースへの接続に使用する ODBC.INI（デフォルトで /usr/local/psql/etc にあります）内のクライアント DSN 設定が次のようになっている必要があります。

TranslationDLL の行は ODBC クライアント インターフェイスが使用する変換ライブラリを指定しています。

TranslationOption の行は、この変換で 9001（UTF-8）から 0932（SHIFT-JIS）が必要であることを指定しています。

この例を使用すると、クライアントからのすべてのデータがサーバーに送られる前に SHIFT-JIS に変換され、クライアントがサーバーからデータを受け取る前には UTF-8 に変換されます。

この設定を使用する場合は、DSN の定義を変更する必要はありません。dsnadd ユーティリティで作成されたままの DSN を使用します。

この設定を使用する場合は、DSN の定義を変更する必要はありません。dsnadd ユーティリティで作成されたままの DSN を使用します。『Pervasive PSQL User's Guide』の dsnaddを参照してください。

このサーバーで受け取るものはすべて EUC-JP でなければいけません。サーバーからクライアントに送られるものはすべて UTF-8 でなければいけません。

これを達成するには、指定のデータベースへの接続に使用する ODBC.INI（デフォルトで /usr/local/psql/etc にあります）内のクライアント DSN 設定が次のようになっている必要があります。

TranslationDLL の行は ODBC クライアント インターフェイスが使用する変換ライブラリを指定しています。

TranslationOption の行は、この変換で 9001（UTF-8）から 9000（EUC-JP）が必要であることを指定しています。

この例を使用すると、クライアントからのすべてのデータがサーバーに送られる前に EUC-JP に変換され、クライアントがサーバーからデータを受け取る前には UTF-8 に変換されます。

この状況は Win32 エンジンに SHIFT-JIS データベースがある場合に可能ですが、すべてのファイルを Linux EUC-JP サーバーに移動することができます。この場合、そのデータベースは EUC-JP Linux マシンにありますが、DDF ファイル内のすべてのデータおよびデータ ファイルは SHIFT-JIS です。

この場合、DSN は以下のようになります。

最後の行は、サーバーでは EUC-JP エンコードを使用するが、このサーバー上のデータは SHIFT-JIS として処理することを指定しています。

Pervasive PSQL v11 SP3 は DOS リクエスターで DOS Btrieve アプリケーションをサポートします。DOS リクエスターでサポートするのは Btrieve アプリケーションのみで、ODBC アプリケーションはサポートされません。このセクションでは、Windows で DOS リクエスターを使用して Pervasive PSQL ベースの DOS アプリケーションを実行する方法について説明します。

DOS ボックスのサポートにより、Windows プラットフォーム上の DOS ボックスで DOS アプリケーションを実行することができます。これにより、データベース エンジンではなく、Windows 32 ビット ワークステーションのコンポーネントと直接通信することが可能になります。この設定は、ローカルの Pervasive PSQL ワークグループ エンジン、あるいはリモート エンジンの両方で使用することができます。クライアント/サーバー アクセスに TCP/IP、SPX または NetBIOS プロトコルのどれを使用するかは、Windows 32 ビット コンポーネントの設定によって決まります。

DOS リクエスターは、ワークグループおよびクライアントからリモートのサーバー エンジンの設定をどちらもサポートします。

Windows 用のリクエスターは BTRBOX です。このリクエスターは DOS アプリケーションに使用することができます。

BTRBOX を使用して DOS アプリケーションを実行するために必要なコンポーネントはすべてクライアントでインストールされています。Windows クライアント コンポーネントをインストールすると、DOS または Windows 32 ビット アプリケーションを実行するために必要な要素がすべて揃います。インストールされる DOS アプリケーションのデフォルトのサポートは、Win32 DOS ボックス設定です。

DOS アプリケーションは 64 ビット Windows プラットフォームではサポートされません。このため、BTRBOX は 64 ビット Windows プラットフォームではサポートされません。

Windows プラットフォームでは、DOS ボックスのインストールはドライバーが完全に透過になるよう設定します。このため、すぐにコマンド プロンプトを開き、DOS Btrieve アプリケーションを実行することができます。%WINDIR%\SYSTEM32 ディレクトリにある CONFIG.NT ファイルには DOS アプリケーションのサポートを有効にするコマンドが含まれています。このファイルは DOS の CONFIG.SYS によく似ています。Windows オペレーティング システムでは DOS セッションが開くたびにドライバーを読み込みます。この設定ファイル内で、インストールを次のパスに置いて DOS ボックス ドライバーを読み込みます。

DEVICE = C:\WINDOWS\SYSTEM32\BTRDRVR.SYS