実際にWinUSBを使用しているわけではないので、参考までに。

今時のPCを使っている限り、ソフト（ドライバ）による速度低下は、極わずかではないでしょうか。
WinUSBを使わない場合でも、作り方にもよりますが、自ドライバ→バスドライバ、と2重の転送ルートがあるのは変わりません。
よほどシビアな速度を要求されるとなれば、関わってくるでしょうけど。

通信速度に大きく関わってくるのは、むしろハード側の要因の方が大きいのではないでしょうか。

WinUSB/UMDF のアーキテクチャでドライバを開発する場合には、USB Reset Pipeの問題など、デバイスの種類によっては適さない場合があります。

WinUSBを利用した開発を検討する場合には通常、通信速度よりもまず、開発しようとしているドライバが、WinUSBで開発可能かどうかを良く検討された方が良いかと思います。

KMDFやWDMでいまだに新規のUSBドライバを開発する理由は、実際、WinUSB利用のドライバでの開発では対応できない場合や、不安定な場合があるからです。USBというバス規格は結構いろいろな相性問題が付いて回るので、一旦WinUSBで開発したドライバでも、使いたい環境や、状況によってはKMDFで開発し直すことがあるという話も聞きます。

ご指摘の様にUMDFはリフレクタを介するので、その分性能余計なコンテキスト・スイッチが入り、理論的には性能が落ちるという事になりますが、それではどのくらい性能が落ちるのかは、WDKのEchoのサンプルで試しみれば良くわかると思います。

お二人とも情報ありがとうございました

こんばんは。
WinUSBに興味があり、いろいろと調べています。
いくつかご質問させてください。

(1)Windowsが提供しているドライバ(WinUSB.DLL,WinUSB.SYS)ということで、
　　WinUSBを用いれば、デジタル署名に関する心配(インストール時の警告＆KMCS)は
　　不要と思って良いのでしょうか？

(2)転送モードの制限(アイソクロナス転送不可)などがあることは分かりましたが、
　　他にも致命的な事前に検討すべき制限などありますか？
　　（例えばUSBの抜き挿しの検知や複数デバイスの制御など）

(3)(2)にも関連しますが、話題になっている「USB Reset Pipeの問題」とは
　　どのようなことでしょうか？基本的なことで申し訳ありません。

よろしくお願いいたします。

(1)明示された文献は無いのですが、私の知る限りでは、Microsoftは最近では「配布する予定があるドライバ・バイナリとドライバ・パッケージ」には、全て署名をするように勧めています。

従ってデジタル署名に関する心配は、そのドライバ・パッケージを配布するかどうか次第ではないでしょうか。

例えばUMDFドライバを作成せずに、アプリケーションからWinUSBを呼び出す場合は、現状ではINFファイルとコインストーラだけのドライバ・パッケージを作成してWinUSBドライバをインストールする必要があります。このような場合でもセキュリティ・カタログを作成して、それに署名しないとインストール時には警告が出ます。インストール時の警告は、WinUSBを使用しているかどうかには関係なく「ドライバ・パッケージ」に正当な署名が有るかどうかに依存します。

また、WinUSB.SYSのバイナリ自体はカーネル・モードで動作しますが、Microsoftの署名が付いているので64bit KMCSの制限は受けません。通常WinUSBを利用する場合は、アプリケーションやDLLから呼び出すか、またはUMDFのドライバからで呼び出すでしょうから、カーネルモードのドライバとしてWinUSBだけを利用するのであれば、それら自分で開発したものに署名が無くてもKMCSの制約は受けません。

(2)デバイス側の動作と、USBのドライバに期待されている役割は様々ですので、WinUSBで実際に開発して動作させてみないと、目的の動作が正しくできるかどうかがわからない、というのが一番の問題だと思います。それで、一度WinUSBで開発してから、KMDFまたはWDMで作り直す場合がある訳です。USBの抜き挿しの検知や複数デバイスの制御については、デバイス側がまともで有れば、問題ないと思います。

(3)Internetで「WinUSB Reset Pipe」で検索すると出てきます。WinHEC2008のPPT資料の以下の説明がシンプルでわかり易いと思います。

Error handling behavior is slightly different
UMDF only does a pipe reset on error, not a device reset (WinUSB limitation)
See Fx2 driver for an example

というわけで、FX2ドライバを参考にされると良いを思います。

(1)『インストール時の警告は、「ドライバ・パッケージ」に正当な署名が有るかどうかに依存します。』とのことで納得させていただきました。それでも、カーネルモードの制約を受けないのは、64bitにおける門前払いを回避できるのでありがたいです。
(2)昔に比べ情報も増えてきたと思いますので、まずは動作させてみるのがよさそうですね。
(3)ありがとうございます、さっそく確認してみます。

さらに調べていて疑問に思ったのですが、
いろいろなサイトで見かけるWinUSB INFファイルのClassとClassGuidで、
Class = USB
ClassGuid = {36fc9e60-c465-11cf-8056-444553540000}
をよく見かけます。

マイクロソフトのサイトで調べてみると、
（http://msdn.microsoft.com/en-us/library/ms791134.aspx）
This class includes USB host controllers and USB hubs, but not USB peripherals. Drivers for this class are system-supplied.
とありますので、USBデバイスに対して使用していいのか疑問に思っています。

「How to Use WinUSB to ～」では MyDeviceClassクラスを宣言していますが、
その場合ClassGuidはどのように決めているのでしょうか？
こちらにもguidgen.exeを使用するのでしょうか。

> USBデバイスに対して使用していいのか疑問に思っています。

私も疑問です。実際はご指摘の様に、Windowsロゴを取得しているUSBデバイス（周辺機器用）用ドライバで、USBクラスを利用している製品があるのも事実です。

恐らくですが、http://msdn.microsoft.com/en-us/library/ms791134.aspxの記述は一般論であり、実際のWindowsロゴの申請（＝取得）にどのクラスを使用するのかに関しては、最新のLogoPointに従う必要があります。従ってLogoPointに詳細の要件が記載されているはずです。LogoPointの要件は、毎年更新されるので注意が必要です。

> その場合ClassGuidはどのように決めているのでしょうか？
> こちらにもguidgen.exeを使用するのでしょうか。

はい、その通りです。ただし独自にClassを作成する場合には、通常クラス・インストーラによりCLASSをインストールすることが求められます。登録済みのクラスは以下にあります。
http://msdn.microsoft.com/en-us/library/ms791134.aspx

気になったので質問させていただきます。

＞独自にClassを作成する場合には、通常クラス・インストーラによりCLASSをインストールすることが求められます。
「求められる」とありますが、独自クラスを作成する場合は
何か＋αの作業が必要なのでしょうか。
それともWindows側で勝手に処理されるものなのですか。

私も「How to Use WinUSB to ～」のサンプルほぼそのままに実装してみましたが
特に独自クラスについて意識せずに通信までできました。

また、独自クラスについて
・自社製品に対して定義し販売する場合
・Windowsロゴ申請する場合
独自クラス申請のための手続きなどが必要なのでしょうか。
（登録済みクラスを使用する場合との差異はありますか。）

よろしくお願いいたします。

> 何か＋αの作業が必要なのでしょうか。

独自CLASSを定義して登録する場合には、クラス・インストーラによりCLASSをインストールする必要があります。
How to Use WinUSB のサンプルでは、[ClassInstall32]セクションのクラス・インストーラで、MyDeviceClassの名前を定義して登録しています。ただしMicrosoftのデバイス・インストール関連の文献によるClass Installerの解説では、このように単に新しい（または特別な）名前を使用することだけが目的のDevice Classを作ることは想定していません。もっと複雑なことをしています。

わざわざDevice Classを作るわけですから、そこにはそのCLASSに属するデバイス群にだけ固有かつ共通な処理やGUIがあるはずだという事を想定しています。例えばUSBクラスに登録するデバイスのプロパティには、全て「電力」というタブが出来ます。これをインストールするのもClass Installer（またはClass Co-Installer）の仕事です。

私の知っている限りでは、独自CLASS申請のための手続きなどは特に無い様です。（だからGUIDを使うのかも…）

独自CLASSを使用する場合には、Windowsロゴ要件に合致しないのでロゴ申請自体ができません。Windowsロゴ要件を定義するLogoPointには、デバイス種類を細かくグループ分けして種類別に、デバイスのインストールで使用すべきDevice Classが指定されているからです。

ただし、Windowsロゴに似ていて少し異なるUnclassified署名プログラムというのがあります。これは、LogoPointに記載してあるロゴ要件に合致しないデバイスに対して、Microsoftの署名が貰えるものです。Unclassifiedなのでその名の通りCLASSの制限は無く、独自CLASSも使えるはずです。そういうわけで、独自CLASSを各社が製品で使用することも自由であるし、Microsoftの署名もUnclassifiedの条件付きで取得可能です。

実際の製品が手元になく、記憶も確かではありませんが、前述の「Windowsロゴを取得しているUSBデバイス（周辺機器用）用ドライバで、USBクラスを利用している製品があるのも事実です。」というのは、もしかするとUnclassified署名を取得したデバイスだったのではないかと思い直しています。