Hallo zusammen, Frage wie im Betreff: könnte man nicht die Treiber eines Geräts (INF-Datei) mit ausliefern, so dass Windows die beim Anstecken gleich vom Gerät läd? Wäre doch sehr viel einfacher als dieses CD-Gefummel. Gruß Anwender
:
Verschoben durch Moderator
Anwender schrieb: > könnte man nicht die Treiber eines Geräts (INF-Datei) mit ausliefern Die INF-Datei ist nicht der Treiber. Da steht nur drin, welche Dateien/Treiber für das Gerät nötig sind: https://msdn.microsoft.com/en-us/library/windows/hardware/ff548081(v=vs.85).aspx > Warum enthalten USB-Geräte nicht auch ihre Treiber? - weil du dann andauernd ein Update für dein USB-Gerät für die neueste Software bräuchtest. - weil du dann viel Speicher für viele Treiber unterschiedlchster Betriebssysteme bräuchtest.
Anwender schrieb: > Wäre doch sehr viel einfacher als dieses CD-Gefummel. wer legt heute noch CDs ein? Der Herstellen müsste nur den Treiber bei MS veröffentlichen (keine Ahnung welchen Aufwand das macht, FTDI macht es zumindest) und schon wird er beim Anstecken vom Internet geladen.
AVM packt die Treiber für die Fritz!Sticks einfach auch eine kleine Partition eines Massenspeichers mit drauf. Einstecken -> USB Stick wird erkannt -> Treiber wird installiert -> Gerät wird erkannt.
Anwender schrieb: > Hallo zusammen, > > Frage wie im Betreff: könnte man nicht die Treiber eines Geräts > (INF-Datei) mit ausliefern, so dass Windows die beim Anstecken gleich > vom Gerät läd? > Wäre doch sehr viel einfacher als dieses CD-Gefummel. > > Gruß > Anwender Weil Benutzer aller anderen Betriebssysteme - und das sind viele - damit nichts anfangen können und WOLLEN.
Lothar M. schrieb: > - weil du dann andauernd ein Update für dein USB-Gerät für die neueste > Software bräuchtest. Wieso sollte das so sein? Das Gerät würde doch einen "Initialzustand" mit den hinterlegten Treibern herstellen. Wenn ich neuere Treiber haben will, lade ich sie mir eben nachträglich aus dem Internet. Wenn schon neuere Treiber installiert sind und ich das Gerät einstecke sollte Windows doch merken, dass die alten Treiber auf dem Device nicht installiert werden sollen. > - weil du dann viel Speicher für viele Treiber unterschiedlchster > Betriebssysteme bräuchtest. Naja... "viel" ist relativ. Martin S. schrieb: > AVM packt die Treiber für die Fritz!Sticks einfach auch eine kleine > Partition eines Massenspeichers mit drauf. Okay, sowas habe ich mir vorgestellt. Das heißt technisch ist das machbar. Woher weiß Windows, dass es auf dem Device nach dem Treiber suchen muss? Oder poppt doch noch ein Auswahldialog für den User auf?
Martin S. schrieb: > Einstecken -> USB Stick wird erkannt -> Treiber wird installiert -> > Gerät wird erkannt. -> Windows meckert daß der Treiber zu alt/zu neu ist, das Gerät bekommt nen Ausrufezeichen und man darf anfangen zu suchen oder -> Linux kann damit garnichts anfangen und man muß eh selbst Hand anlegen Pauschallösungen sind immer toll, funktionieren aber selten und machen in der Entwicklung soviel Aufwand daß es sich selten lohnt.
Anwender schrieb: > Woher weiß Windows, dass es auf dem Device nach dem Treiber > suchen muss? Oder poppt doch noch ein Auswahldialog für den User auf? Windows weiß das nicht. Das Gerät verhält sich genauso wie ein USB-Stick. Heißt also, dass der Anwender entweder ein Setup-Programm vom Stick starten muss oder alternativ dem Treiberassistenten von Windows zeigen muss, dass die Treiberdaten auf eben diesem Wechselspeicher liegen. Diese Variante des auf dem Gerät mitgelieferten Treibers ist auch gar nicht so selten. Ich habe sowas schon öfters bei Mobilfunk- und TV-Sticks gesehen. Allerdings muss ich auch sagen, dass ich davon nicht sonderlich begeistert bin. Zwar hört sich das in der Theorie alles toll an, aber praktisch scheitert die Installation auch gerne und das Teil wird immer wieder lediglich als Speicherstick erkannt oder wechselt dauernd zwischen den Modi. Wenn man dann einfach einen aktuellen Treiber aus dem Netz installieren will, wird das eigentliche Gerät nicht gefunden usw.. Noch spannender wird es dann, wenn das Betriebssystem nicht Windows ist.
Wenn beim Einstecken, ohne Rückfrage, von dem zusätzlich enthaltenem Massenspeicher Gerätetreiber installiert werden, freuen sich die Malwareprogrammierer. Hat es, zumindest bei einer Klasse von Betriebssystemen wohl auch schon gegeben. Soweit ich mich erinnern kann, ist in den USB-Deskriptoren sogar Platz für eine URL. Auch wenn hier ein automatischer Download nicht angedacht ist (sinnvoll aus o.g. Gründen), kann dem Anwender zum mindesten der Weg zu aktuellen Treibern gewiesen werden. Die Entscheidung zur Installation sollte dann trotzdem von ihm getroffen werden.
Norbert schrieb: > Weil Benutzer aller anderen Betriebssysteme - und das sind viele - damit > nichts anfangen können und WOLLEN. Hab bisher nicht gehört, dass es jemanden mit einem alternativen OS gestört hätte, wenn auf den Sticks Windowsleichen liegen. Sie ignorieren es einfach. Anwender schrieb: > Wieso sollte das so sein? Das Gerät würde doch einen "Initialzustand" > mit den hinterlegten Treibern herstellen Habs schon oft genug gehabt, dass alte Treiber nach 1..2 Jahren bei einem aktuellen Windows nicht mehr funktionieren oder Probleme machen. D.h. der Initialzustand bei nicht allzusehr verbreiteter Hardware klappt nur, wenn du auch bei dem alten OS Zustand bleibst. Anwender schrieb: > Wenn schon > neuere Treiber installiert sind und ich das Gerät einstecke sollte > Windows doch merken, dass die alten Treiber auf dem Device nicht > installiert werden sollen. Eigentlich ignoriert Windows die alten Versionen und nimmt die neueren ohne zu meckern. Dass die neuere Version dann möglicherweise nicht zu der Uralt-GUI passt, die auch auf dem Stick ist, schafft dann neue Probleme. Und dann fällt mir noch ein, wie problematisch die automatische Installation mit den Virenverseuchten Sticks ist.
Steffen R. schrieb: > Norbert schrieb: >> Weil Benutzer aller anderen Betriebssysteme - und das sind viele - damit >> nichts anfangen können und WOLLEN. > > Hab bisher nicht gehört, dass es jemanden mit einem alternativen OS > gestört hätte, wenn auf den Sticks Windowsleichen liegen. Sie ignorieren > es einfach. > Mich würde es stören. - Tastatur angesteckt => HID-Device UND zusätzlichen Massenspeicher angemeldet - Maus angesteckt => HID-Device UND weiteren Massenspeicher angemeldet - Tablett angesteckt => HID-Device UND noch einen Massenspeicher angemeldet irgendwann haben wir /dev/sda bis /dev/sdz belegt. Die Japaner haben's da besser, deren Alphabet umfast rund 250 Zeichen;-) Es gibt sicherlich Dinge welche dem 'normalen' Windows Anwender gefallen würden, aber bitte keine Zwangsbeglückung aller Anderen!
Anwender schrieb: > Hallo zusammen, > > Frage wie im Betreff: könnte man nicht die Treiber eines Geräts > (INF-Datei) mit ausliefern, so dass Windows die beim Anstecken gleich > vom Gerät läd? > Wäre doch sehr viel einfacher als dieses CD-Gefummel. Machen einige doch. Ist nix wirklich gut, aber machen sie. Da kommen USB Geräte mit einer CD-Emulation oder einer Massenspeicher-Implementierung auf der sich Treiber finden. Die Treiber sind dann - veraltet und - für das falsche Betriebssystem Bei Billiggeräten auch mal für ein ganz anderes Gerät. Ebenfalls sehr lustig ist es wenn, wie bei meinen Smartphone, kein Treiber aber eine Bedienungsanleitung als PDF auf der CD-Emulation ist. In der wird beschrieben wie man von der beiliegenden echten CD die Treiber und eine Anwendung installiert: CD einlegen und auf start.exe klicken ... Beim ersten Start geht die Anwendung ins Internet, lädt neue Versionen der Treiber und Anwendung und installieren diese. Da waren Maximalbekiffte am Werk. USB-Geräte mit mitgebrachten Treibern sind besonders spaßig wenn sie eigentlich mit einem standardisierten USB-Profil laufen würden, also nicht mal einen Treiber benötigen würden, wenn da nicht eine Umschaltung von CD-Emulation auf Normalbetrieb nötig wäre.
Anwender schrieb: > könnte man nicht die Treiber eines Geräts > (INF-Datei) mit ausliefern, so dass Windows die beim Anstecken gleich > vom Gerät läd? Lothar M. schrieb: > - weil du dann viel Speicher für viele Treiber unterschiedlchster > Betriebssysteme bräuchtest. https://www.amazon.de/Ethernet-Inateck-Notebooks-Ultrabooks-USB-Anschl%C3%BCssen/dp/B00ESVH4MO der macht es so, ich wunderte mich das kein Treiber beilag, der Treiber für das Netzwerk scheint im HUB zu sitzen, es meldet sich auch als CD an! Fedora und win7 liefen am Netzwerk.
Anwender schrieb: > Hallo zusammen, > > Frage wie im Betreff: könnte man nicht die Treiber eines Geräts > (INF-Datei) mit ausliefern, so dass Windows die beim Anstecken gleich > vom Gerät läd? > Wäre doch sehr viel einfacher als dieses CD-Gefummel. > > Gruß > Anwender Es wird Teilweise so gemacht. Wenn du ein NXP Kinetis Demo-Board am PC einsteckst, erscheint erstmal ein USB-Laufwerk (msd)mit den Treibern für das Board. Nach den installieren der Treiber geht (je nach Firmware Version) das Laufwerk wieder weg. Aber das CD-Gefummel ist definitv out. Am saubersten ist, wie weiter oben schon erwähnt, der Weg über MS.
:
Bearbeitet durch User
Guest schrieb: > Martin S. schrieb: >> Einstecken -> USB Stick wird erkannt -> Treiber wird installiert -> >> Gerät wird erkannt. > > -> Windows meckert daß der Treiber zu alt/zu neu ist, das Gerät bekommt > nen Ausrufezeichen und man darf anfangen zu suchen Noch nie erlebt, dass Windows automatisch irgendwelche Treiber eines Massenspeichergeräts installiert... > oder > > -> Linux kann damit garnichts anfangen und man muß eh selbst Hand > anlegen Was interessiert mich Linux? Entweder sind Linux Treiber dabei, oder nicht. Wenn die Treiber 90% der am Markt genutzten Betriebssysteme abdeckt, reicht das. > Pauschallösungen sind immer toll, funktionieren aber selten und machen > in der Entwicklung soviel Aufwand daß es sich selten lohnt. Welcher Aufwand? Treiber auf eine Partition packen? Wahnsinnig aufwändig...
Anwender schrieb: > Frage wie im Betreff: könnte man nicht die Treiber eines Geräts > (INF-Datei) mit ausliefern, so dass Windows die beim Anstecken gleich > vom Gerät läd? Du könntest glatt bei Microsoft arbeiten. Es ist schon schlimm genug, dass Software sich automatisch von Sticks installiert, darunter natürlich auch Viren. Noch schlimmer ist es freilich, wenn das dann auch noch Kernel-Komponenten wie Treiber sind.
Okay.. das ganze ist also technisch kein Problem und wird noch einfacher mit den folgenden Einschränkungen: 1) Ich betrachte nur Windows-Betriebssysteme 2) Der Treiber ändert sich nicht wirklich 3) Der Treiber ist relativ klein (<1 MB) Wenn ich das realisieren wollen würde, sollte sich das Device beim ersten Anstecken als Massenspeicher melden. In Windows poppt ein Auswahldialog auf in dem der Anwender den Treiber auf dem neuen Massenspeicher auswählen kann. Mir ist die Unterscheidung zwischen dem ersten Anstecken (Massenspeicher) und den folgenden Anstecken (eigentliche Funktion) nicht klar. Welche Informationen müssen zwischen Host und Device ausgetauscht werden, damit der "richtige" Treiber ausgewählt wird?
Anwender schrieb: > Wenn ich das realisieren wollen würde, sollte sich das Device beim > ersten Anstecken als Massenspeicher melden. Ist mir so schon bei einem Surfstick begegnet. Noch besser ist freilich diese existierende Kombination: Der Stick gibt sich sowohl als Massenspeicher als auch als Tastatur aus. Per Tastatursimulation tippt er dann die notwendigen Kommandos ein, um die Programme vom Massenspeicher zu installieren. Und um vorher störende Sicherheitsprogramme zu deaktivieren.
Mich wundert, dass niemand auf diesen Punkt eingeht: >Wenn beim Einstecken, ohne Rückfrage, von dem zusätzlich enthaltenem >Massenspeicher Gerätetreiber installiert werden, freuen sich die >Malwareprogrammierer. Selbst für den Test, ob der Treiber schon installiert ist, und die Rückfrage, "willst Du jetzt einen Treiber installieren?", müsste ja schon eine Software vom USB-Device gestartet werden. Wie sollen denn die Daten in dem Stick abgelegt werden? Maskenprogrammiert, also ein Schuss und wenn da ein Fehler drin ist geht alles in die Tonne? Flash, damit irgendwelche bösen Buben da dann geänderte Dateien ablegen?
Martin S. schrieb: > Noch nie erlebt, dass Windows automatisch irgendwelche Treiber eines > Massenspeichergeräts installiert... Dann bist Du noch nicht lange dabei? Als die Autorun Funktionalität nicht überall gesperrt war, startete das setup automatisch. Ähnliches muss es aber auch jetzt noch geben, da man sich ja durch bloßes Einstecken eine USB Sticks seinen Windows PC verseuchen kann.
Die ganze Diskussion über die Sicherheit vom Anstecken ist doch albern. Der Stick selber kann sich, wenn er Manipuliert ist schon als Tastatur ausgeben und beliebige Befehle ausführen. Dafür braucht man gar keine Dateien auszuführen und das geht auch unter Linux. Wenn man Hardware an den PC Steckt, muss man etwas vertrauen in die Hardware haben.
Anwender schrieb: > Mir ist die Unterscheidung zwischen dem ersten Anstecken > (Massenspeicher) und den folgenden Anstecken (eigentliche Funktion) > nicht klar. Welche Informationen müssen zwischen Host und Device > ausgetauscht werden, damit der "richtige" Treiber ausgewählt wird? Im einfachsten Fall wird das Gerät bei vorhandenen Treiber aktiviert und bei Unbekannt suspended. Wenn der letzetre Zustand kein üblicher Zustand für das Gerät ist, kann diese Information im Gerät genutzt werden.
Peter II schrieb: > Die ganze Diskussion über die Sicherheit vom Anstecken ist doch albern. Hier gehts (zumindest mir) darum, dass funktionierende Wege existieren.
Peter II schrieb: > Die ganze Diskussion über die Sicherheit vom Anstecken ist doch albern. > > Der Stick selber kann sich, wenn er Manipuliert ist schon als Tastatur > ausgeben und beliebige Befehle ausführen. Dafür braucht man gar keine > Dateien auszuführen und das geht auch unter Linux. Also mein Linux System fragt mich, bevor es irgendwelche Änderungen am System vornimmt, nach dem Root-Passwort, und das einzugeben dürfte für den Stick schwierig werden.
> mit den folgenden Einschränkungen: > > 1) Ich betrachte nur Windows-Betriebssysteme > 2) Der Treiber ändert sich nicht wirklich > 3) Der Treiber ist relativ klein (<1 MB) Jeder Productmanager hält sich an 1)! Kein Productmanager hält sich an 2) + 3)! - - - Was die Plattformagnostik angeht: bei OpenFirmware nach IEEE-1275 ist ein Forth-Interpreter zentral dabei; im ROM der Steckkarten steht dann F-Code der CPU-Architektur unabhängig ist, die Eigenschaften der Steckkarten beschreibt und (rudimentäre) Bedienroutinen mitbringt. Tatsächlich technisch echt kein Problem. OFW IEEE-1275 ist aber nur auf "Richtigen Computer[TM]" anzutreffen... Es grüsst der "OK> "-Prompt :)
A. H. schrieb: > Also mein Linux System fragt mich, bevor es irgendwelche Änderungen am > System vornimmt, nach dem Root-Passwort, und das einzugeben dürfte für > den Stick schwierig werden. warum sollte man root werden um deine eigenen Dateien zu löschen/verschlüsseln?
Peter II schrieb: > warum sollte man root werden um deine eigenen Dateien zu > löschen/verschlüsseln? Warum sollte man Administrator sein, um was am System verändern zu dürfen?
ausserdem: der USB-Standard klassifiziert USB-Peripheriegeräte in Standarisierte Klassen. Hat ein "Richtiges Bertiebssystem[TM]" für jede Klasse ein Standardtreiber schon dabei UND halten sich die USB-Peripheriehersteller an besagte Klassen (sprich: bauen Ihre Geräte Standardkonform) sind keine nachzuladende Treiber nötig. Die Realität: jeder Herst. will nach "mee-too"-Muster einfach ein USB-Anschluss an seinem Kram und foutiert sich um Standardkonformität. Das ist genauso nervig wie wenn hier im Forum unverständliches, inkorrektes Deutsch geschrieben wird. Reaktion: "steinigt Sie!".
Peter II schrieb: > A. H. schrieb: >> Also mein Linux System fragt mich, bevor es irgendwelche Änderungen am >> System vornimmt, nach dem Root-Passwort, und das einzugeben dürfte für >> den Stick schwierig werden. > > warum sollte man root werden um deine eigenen Dateien zu > löschen/verschlüsseln? Weil meine regelmäßigen Backups ein chown root:root auf die gesicherten (Archiv-) Dateien machen und meine Repositories unter einem eigenen Account mit einem eigenem Passwort liegen.
Grmpff... toll, dass hier der Thread mit unwichtigen Gequassel gekapert wird. :-( Es geht hier nicht um Security-Policy von Betriebssystemen! Auch nicht was hier jeder für richtig oder falsch hält. Meinee Fragen sind 1) Ob das technisch machbar ist: --> Ja 2) Wie das in der Realität dann aussieht (hatte noch nie ein Device dass das macht). --> Das hier scheint ein Ansatz zu sein: Steffen R. schrieb: > Im einfachsten Fall wird das Gerät bei vorhandenen Treiber aktiviert und > bei Unbekannt suspended. Wenn der letzetre Zustand kein üblicher Zustand > für das Gerät ist, kann diese Information im Gerät genutzt werden. Das Aktivieren / Suspenden geht von Windows aus? Muss das Verhalten als Device-Entwickler irgendwo (.inf) beschrieben werden?
Schöne Sache ist auch bei z.b. UMTS-Sticks wenn sich die CD-Emu nur abschaltet wen der Treiber installiert wurde, gerade bei gebrandete Sticks ist es oft so das man die Anbieter SW installieren muss um das Gerät nutzen zu können. In anderen Betriebssystemen macht das Regelmäßig Probleme obwohl der scheiß an sich Out-Off box läuft. Halte davon auch nix, vor alledem weil es nicht nötig ist das genau so zu machen es würde auch alles Parallel gehen. Bei Acer Netbooks sind PCIe UMTS karten verbaut die per USB angebunden sind, die machen auch diese Art der Zwangsbeglückung, und wer will schon das Hersteller/Anbieter Gedöns drauf haben, die Org. Treiber + SW finden ist grade da oft Glückssache.
Peter II schrieb: > Die ganze Diskussion über die Sicherheit vom Anstecken ist doch albern. > > Der Stick selber kann sich, wenn er Manipuliert ist schon als Tastatur > ausgeben und beliebige Befehle ausführen. Dafür braucht man gar keine > Dateien auszuführen und das geht auch unter Linux. Also wenn ein solcherart manipuliertes USB Device an meinen Rechner gesteckt wird, bekomme ich ein Popup mit VID:PID und das Gerät funktioniert selbstverständlich nicht. Erst manuelles Freischalten bringt die gewünschte Funktion. > > Wenn man Hardware an den PC Steckt, muss man etwas vertrauen in die > Hardware haben. Man muß nur darauf vertrauen das das Ding keine 5000V aufbaut und den Rechner zappt. Und wenn man darauf nicht vertraut hilft eventuell ein USB Hub.
Anwender schrieb: > Steffen R. schrieb: >> Im einfachsten Fall wird das Gerät bei vorhandenen Treiber aktiviert und >> bei Unbekannt suspended. Wenn der letzetre Zustand kein üblicher Zustand >> für das Gerät ist, kann diese Information im Gerät genutzt werden. > > Das Aktivieren / Suspenden geht von Windows aus? Muss das Verhalten als > Device-Entwickler irgendwo (.inf) beschrieben werden? Das macht der USB Host. Windows: Bei meinen embedded Entwicklungen war Suspend der Zustand, den das Gerät eingenommen hat, wenn Windows keinen Treiber hat und im Systemmanager das gelbe Dreieck zeigt. Allerdings düfte es wohl auch der Zustand sein, den das Gerät zum Stromsparen einnimmt. Aber prinzipiell kannst Du es erkennen, wenn du die Kommandosequenzen zw. Host und Device auf dem Device auswertest. Die .inf Datei beschreibt für welche VendorID und Produktcode welcher Treiber genutzt werden soll.
Interessante Meinung: Scheiss Sicherheit am Computer. MEIN Computer ist sicher und deshalb sind solche potentiell gefährlichen Lösungen gut. Warum machen es die Hersteller dann nicht? Weil sie sich die vielen Dau's vom Leibe halten wollen, die ihnen bei geschrottetem Rechner die Bude einrennnen bzw. danach nicht mehr als Kunden vorbeischauen. Wenn die Schlauen mit den sicheren Rechnern sich darum kümmern, dass auch die Dau-Rechner sicher sind wird es auch was mit der selbstkonfigurierenden Hardware. Wie schon weiter oben geschrieben, die einfachste und gleichzeitig auch einigermßen sichere Lösung für viele Devices wäre sich an die Standard-Device-Klassen zu halten. Da könnte sich der Hersteller sogar noch Arbeit für eigene Treiber sparen. Für diese 'Software-vom-USB-Device'-Lösung wäre es mal nicht schlecht, wenn die Dateien zum manuellen Starten einfach in einem RO-Massenspeicher-Device liegen und die eigentliche Funktionalität auch ohne die Installation irgendwelcher Software oder USB-Device-Umschalt-Schritte nutzbar ist (siehe UMTS-Sticks mit der leidigen Umschalterei, nicht leidig für Win, aber für alles andere.)
Steffen R. schrieb: > Ich werfe mal USB-CAN Interfaces in den Raum... Und was viel üblicheres: Surfsticks. Die emulieren eine serielle Schnittstelle mit AT-Kommandos. Dafür gibts aber keine Standard Klasse und daher braucht man die entsprechende Software, auch wenn der Treiber einfach nur der Standard CDC Treiber ist.
>Und was viel üblicheres: Surfsticks. Die emulieren eine serielle >Schnittstelle mit AT-Kommandos. Dafür gibts aber keine Standard Klasse >und daher braucht man die entsprechende Software, auch wenn der Treiber >einfach nur der Standard CDC Treiber ist. Neuerdings gibt es Surfsticks, die vom Rechner als Netzwerkschnittstelle erkannt werden. Keine Ahnung wie da die Standardklasse heisst, aber die funktionieren ohne Extra-Treiber. Bei CAN, keine Ahnung. Die Aussage war ja auch nicht 'Alles laesst sich ueber Standardklassen abdecken'. Aber wo möglich sollte das der Weg der Wahl sein.
Hallo, ich habe hier noch einen USB-Stick rumliegen, der eine Texas-Instruments-Entwicklungssystem für Prozessoren des Typs 430 enthält, da ist neben Emulator usw. auch die nötige Software drauf, meines Wissens bis hin zum C-Compiler. Die Praxis sieht so aus: Beim ersten Anstecken installiert sich die gesamte Software, aber da die nach wenigen Wochen, höchstens Monaten nicht mehr aktuell ist, muss ich anschliessend bei TI auf die Suche nach dem Download neuerer Versionen gehen und die neu installieren, womöglich noch vorher die Stickversion deinstallieren. Also annähernd doppelte Arbeit, da verzichte ich gern drauf. Georg
Anwender schrieb: > Frage wie im Betreff: könnte man nicht die Treiber eines Geräts > (INF-Datei) mit ausliefern, so dass Windows die beim Anstecken gleich > vom Gerät läd? Es gibt sowas ähnliches bereits (https://github.com/pbatard/libwdi/wiki/WCID-Devices). Aber: HID und Mass Storage brauchen kein .INF, CDC braucht auch keins mehr in Win10. Kombinationen sind übrigens ebenfalls erlaubt. Damit erschlägt man 99% aller Anwendungsfälle. Modernes Windows kann WHQL Treiber auch selbständig aus dem Internet saugen, das machen z.B. die FTDI USB->UART Adapter. Deren Zertifizierung ist für kleinere Anbieter aber ziemlich teuer. Das CD Geraffel braucht man in vielen Fällen aber für die Anwendungssoftware weiterhin. Ich würde heutzutage allerdings eher USB Sticks benutzen: CD Laufwerke sterben bei flachen Notebooks aus.
Anwender schrieb: > Grmpff... toll, dass hier der Thread mit unwichtigen Gequassel > gekapert > wird. :-( Weil es schon längst ausdiskutiert ist. Willst du es auf die Stirn tätowiert haben? Also: Ja, geht. Ja, ist scheisse. Die Grundidee ist Scheiße. Die von dir gewünschte vollautomatische Implementierung ist Super-Scheiße. Die Grundidee ist Scheiße, weil Spezialtreiber statt der OS-Treiber für standardisierte USB-Profile scheiße sind. Warum ist die vollautomatische Implementierung Super-Scheiße? Weil damit unter Windows lange und mühsam erkämpfte Sicherheitsmechanismen ausgehebelt werden. Nämlich dass das verfluchte Autostart endlich per Default aus ist. Was bedeutet, du darfst dich auf das Niveau von Virus-Autoren begeben damit deine Idee funktioniert. > Es geht hier nicht um Security-Policy von Betriebssystemen! Doch, darum geht es. Es interessiert deine Kunden nämlich sehr wohl ob du für deine idiotische automatische Treiberinstallation ihr Betriebssystem hackst. > Auch nicht was hier jeder für richtig oder falsch hält. > Meinee Fragen sind Wir sind in einem öffentlichen Forum. Deine Fragen sind bereits beantwortet. Du musst uns nicht wie deine Leibeigenen behandeln, die dir mundgerechte Antworten servieren müssen. Wir diskutieren was wir wollen.
Ob von USB unterstützt, weiß ich nicht, aber grundsätzlich sollte es doch erstmal so gehen: Gerät wird angesteckt und meldet sich als 'Gerät mit eingebauten Treibern'. Gerät meldet: 'Treiber Version X.X für Betriebssysteme a,b,c…' Entweder der Treiber für das aktuelle Betriebssystem ist auf dem Gerät vorhanden, dann kann er, je nach Benutzereinstellung, installiert werden, oder er ist nicht vorhanden und es passiert das, was sonst bisher auch bei jedem Gerät ohne Treiber passiert. Dann kann man zum Beispiel in Windows die Komfortfunktion nutzen, während sich für Linux das Gerät so verhält, als wäre gar kein Treiber drauf, was im Vergleich zu anderen Geräten ganz ohne Treiber kein Nachteil wäre. Je nach Sicherheitsbewusstsein müsste die automatische Installation wählbar sein. Ausgeschaltet verhält sich das Gerät dann wie jedes andere.
Jim M. schrieb: > Aber: HID und Mass Storage brauchen kein .INF, CDC braucht auch keins > mehr in Win10. CDC ohne inf-Datei - Sicher? Mein Stand: Wenn Windows 10 die VendorID/Produktcode nicht kennt, benötigt es weiterhin eine inf. Diese macht allerdings die Signatur des Treibers nicht mehr kaputt und wird daher ohne eigene Signatur akzeptiert.
Steffen R. schrieb: > CDC ohne inf-Datei - Sicher? https://msdn.microsoft.com/en-us/library/windows/hardware/dn707976.aspx sagt: > In Windows 10, a new INF, Usbser.inf, has been added to %Systemroot%\Inf > that loads Usbser.sys as the function device object (FDO) in the device > stack. If your device belongs to the Communications and CDC Control > device class, Usbser.sys is loaded automatically. The driver is loaded > based on a compatible ID match similar to other USB device class drivers > included in Windows.
Jay schrieb: schon längst ausdiskutiert ist. Willst du es auf die Stirn > tätowiert haben? Geht das denn auch in Windows-Farben? > Ja, ist scheisse. [...] Scheiße. [...] Super-Scheiße. [...] Scheiße, > [...] scheiße [...] Super-Scheiße? Da bleibt kein Raum für fachliche und soziale Kompetenz oder? Mit deinen Worten: "Wir sind in einem öffentlichen Forum." Läufst du so auch durch die Innenstadt? > Wir sind in einem öffentlichen Forum. [...] Wir diskutieren was wir wollen. Wofür genau ist dann die Untergliederung un Themen und Threads? Übrigens: die technischen Details waren zu dem Zeitpunkt keineswegs geklärt. Freundlichen Gruß.
Dussel schrieb: > Ob von USB unterstützt, weiß ich nicht, aber grundsätzlich sollte es > doch erstmal so gehen: > Gerät wird angesteckt und meldet sich als 'Gerät mit eingebauten > Treibern'. > Gerät meldet: 'Treiber Version X.X für Betriebssysteme a,b,c…' > > Entweder der Treiber für das aktuelle Betriebssystem ist auf dem Gerät > vorhanden, dann kann er, je nach Benutzereinstellung, installiert > werden, oder er ist nicht vorhanden und es passiert das, was sonst > bisher auch bei jedem Gerät ohne Treiber passiert. > > Dann kann man zum Beispiel in Windows die Komfortfunktion nutzen, > während sich für Linux das Gerät so verhält, als wäre gar kein Treiber > drauf, was im Vergleich zu anderen Geräten ganz ohne Treiber kein > Nachteil wäre. > Je nach Sicherheitsbewusstsein müsste die automatische Installation > wählbar sein. Ausgeschaltet verhält sich das Gerät dann wie jedes > andere. Dieses verhalten könnte man annäherungsweise mit einem Timeout auf Geräteseite hinbekommen: Falls nach 5Sek kein Treiber sich die Eigentliche Funktion krallt, wird in den Massenspeicher Modus umgeschaltet. BTW: Bei meinem letzten Wlan-Stick waren Linuxtreiber in form von Sourcecode auf der CD vorhanden.
Jens M. schrieb: > Neuerdings gibt es Surfsticks, die vom Rechner als Netzwerkschnittstelle > erkannt werden. Keine Ahnung wie da die Standardklasse heisst, aber die > funktionieren ohne Extra-Treiber. Auch CDC, Standardklasse für Modems und Netzwerkschnittstellen. Das Zweckentfremden von CDC-ACM als "Serieller Port ohne Modem über USB" ist eigentlich nicht korrekt, u.A. deshalb haben FTDI/Silabs/Prolific/.... eigene Treiber für ihre USB->RS232-Wandler.
Bilder sagen mehr als tausend Worte. Im Anhang ein Bild von einer "Onboard-Surfstick-Software" eines E-Plus/Blau.de gebrandmarkten Sticks. Es ist das absolute Gegenteil von: Jens M. schrieb: > Neuerdings gibt es Surfsticks, die vom Rechner als Netzwerkschnittstelle > erkannt werden. Keine Ahnung wie da die Standardklasse heisst, aber die > funktionieren ohne Extra-Treiber. Weißt du wie das dann funktioniert? Per PPTP reinwählen?
Anwender schrieb: > könnte man nicht die Treiber eines Geräts > (INF-Datei) mit ausliefern, so dass Windows die beim Anstecken gleich > vom Gerät läd? Meine angenehme Erfahrung: Im Labeldrucker QL-700 von Brother kann man auf Knopfdruck den USB-Speicher aktivieren und die Treibersoftware (Microsoft Windows) installieren.
:
Bearbeitet durch User
es würde ja reichen eine .inf Datei abzulegen..damit Windows weiß wo es die treiber herunterladen kann.. Das gleiche für grafikkarten etc pp. ich hatte damals ein pc geschäft, und hatte mir gedacht, das dieser tag kommen wird, dann bricht viel geld durch service weg...aber bis heute wurde das nicht gemacht..keine ahnung warum.. Das ginge für wirklich nahzu alles, hdd contoller, UArt karten, usb dongles, soundkarten etc pp.. einstecken..warten..fertig
Tanja schrieb: > es würde ja reichen eine .inf Datei abzulegen..damit Windows weiß wo es > die treiber herunterladen kann Das wäre dann eine Microsoft-Only Lösung, die trotzdem Internet braucht. Damit bietet das exakt 0 Vorteil gegenüber der existierenden Microsoft-Only Lösung, die Treiber automatisch von den MS-Update-Servern herunterzuladen. Aber den Nachteil, dass du keine Automatischen Updates bekommst, und die Treiber+Anwendungssoftware der Hersteller nicht mal den grundlegendsten Qualitätsansprüchen genügen müssen, also z.B. Viren- und Adware verseucht sein dürfen. Warum willst DU auf Sicherheit&Komfort verzichten, nur damit die Hardware-Hersteller ein paar € für ihre Treiber-Zertifizierung und veröffentlichung bei MS sparen?
Planlos schrieb: > Jens M. schrieb: >> Neuerdings gibt es Surfsticks, die vom Rechner als Netzwerkschnittstelle >> erkannt werden. Keine Ahnung wie da die Standardklasse heisst, aber die >> funktionieren ohne Extra-Treiber. > > Auch CDC, Standardklasse für Modems und Netzwerkschnittstellen. > Das Zweckentfremden von CDC-ACM als "Serieller Port ohne Modem über USB" > ist eigentlich nicht korrekt, u.A. deshalb haben > FTDI/Silabs/Prolific/.... eigene Treiber für ihre USB->RS232-Wandler. Nein, Mobile Broadband ist eine eigene Klasse. Mittlerweile hat Windows dafür eigene Treiber.
Hannes J. schrieb: > Nein, Mobile Broadband ist eine eigene Klasse. Mittlerweile hat Windows > dafür eigene Treiber. Interressant, muss ich mich einlesen. Ich kannte das nur als CDC-Ethernet, dass dann ein eigenes Netzwerk-Segment incl. Router und DHCP-Server zur Verfügung stellt. Ist aber auch schon ein paar Jahre her, dass ich mich mit UMTS-Routern & Tethering beschäftigt habe.
Planlos schrieb: > Hannes J. schrieb: >> Nein, Mobile Broadband ist eine eigene Klasse. Mittlerweile hat Windows >> dafür eigene Treiber. > > Interressant, muss ich mich einlesen. Es ist wie immer bei Microsoft ziemlich chaotisch: https://msdn.microsoft.com/de-de/library/dn265427(v=vs.85).aspx https://msdn.microsoft.com/de-de/library/windows/hardware/ff538833(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/hardware/ff560545(v=vs.85).aspx Ach ja, hätte der Thread-Starter sich auch nur ein bisschen in die Materie eingelesen, dann wäre er sehr schnell über https://msdn.microsoft.com/de-de/library/windows/hardware/ff540283(v=vs.85).aspx#automatic_installation_of__winusb_without_an_inf_file gestolpert und hätte sich überlegen können ob sein hypothetisches Spezialgerät damit nicht gut bedient wäre.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.