To, že kernelový driver při neočekávaném deskriptoru zařízení, shodí celý systém, svědčí o cedníkovitosti driveru a neserioznosti jeho tvůrce (MS) nebo špatné implementaci celého systému.
Jinak rádi zařízení zapůjčíme k otestování, ať si to u MS spraví. Pokud by za to předvedli, jak má nad jejich usbser vypadat inf pro multiport, tak by nás to vysloveně potěšilo. Nemusíte mi psát vy, předejte to podpoře. Vy nejspíš svojí pravou identitu tajíte, když jsem Vám při vašem nepodloženém vychloubání před lety nabízel veřejnou diskuzi, tak jste se stáhl. Můj e-mail na FEL ČVUT najdete opravdu velmi rychle, tak můžete ukázat, že Vaše řeči myslíte vážně a pomoc zásadní bezpečnostní díru Windows opravit.
Za tím, že je driver usbser nepovedený, si stojím. Přitom jeho blokoce na konkrétní VID:PID již úplná zvrácenost. protože od toho, aby nebylo potřeba kvůli standardizovaným zařízením pořád přepisovat drivery a INFy, byly vymyšlené classy (u vzniku standardu USB přímo MS byl, takže by to mohl vědět) a slušné operační systémy raději připraví obecný driver spravovaný v mainline než aby nutily každého výrobce skládat vlastní bastl z milostivě utroušených zbytků.
Na druhou stranu mám velkou úctu Dave Cutlerovi za návrh koncepce NT jádra, i když je vysloveně škoda, že moderní OS nenavrhoval pro někoho jiného, např. IBM nebo DEC, od kterých většinu znalostí stejně načerpal. Ale to, co s tímto bezesporu slušným základem dělá MS, je spíš jen ke škodě. Další problém je, že některé věci, které byly koncepčně v roce 1992 revoluční jsou již dnes poněkud nevýhodné a koncept komunikace ovladačů přes interní, často nedokumentované IOCTL také moc k přehlednosti nevede. Takže mnohem flexibilnější a ze začátku možná i adhoc naimplementovaný soubor přímo volaných funkcí, jako je v jádře Linuxu, nakonec vede k lepšímu modelu a především výkonu. O RCU a dědičnosti priorit a dalších RT vymoženostech Linuxu si pak může nechat Windows jen zdát.