Moin, Bekanntlich werden mit neuen Versionen von Windows viele USB Geräte in negativer Weise betroffen. Das verurteilt oft recht viele Geräte für den Werkstoffhof falls sie mit einem älteren BS nicht weiterbenutzt werden können. Man braucht z.B. nur an diverse uC Programmieradapter oder Scanner, Drucker und andere Spezialgeräte denken Vorerst, ich kenne mich mit den "grausigen Details" von Windows USB Treibern nicht sehr gut aus und frage eher aus der Sicht des 0815 Benützers. Was geht typisch zwischen Windows Versionen eigentlich zu Bruch? Sind es die Datendefinitionen und wichtige Parameter Einträge oder Treiber Code? Könnte man ein Tool bauen, welches alte USB Treiber wieder kompatibel macht indem man Einträge auf den notwendigen Stand bringt? Daß der eigentliche USB Treiber bei neueren Windows Versionen völlig anders funktioniert ist ja nicht sehr wahrscheinlich. Ich tippe da eher auf inkompatible Treiberdefinitioneneinträge. Wenn es nur diverse Einträge sind, die auf den neuesten Stand gebracht werden müssen, dann würde Hoffnung bestehen, ältere USB Geräte weiter betreiben zu können. Vielleicht könnte man sogar ein Update Tool bauen, das mit vielen Definitionsdateien zurecht kommt. Was meint ihr? Sich damit abfinden müssen, oder besser, versuchen für dieses leidige Problem, Lösungen zu finden um nützliche USB Geräte vor dem unnötigen Tod zu bewahren? Gruß, Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Bekanntlich werden mit neuen Versionen von Windows viele USB Geräte in > negativer Weise betroffen. Bekanntlich? Nö. Viele? Auch nicht. > Daß der eigentliche USB Treiber bei neueren Windows Versionen völlig anders funktioniert ist ja nicht sehr wahrscheinlich. Je nachdem, was "altes" und was "neues" Windows sind, ist genau das das Problem. Treiber für Müll wie Windows 98 sind nicht mit XP verwendbar, Treiber für XP sind nicht für neuere Windows-Versionen verwendbar, und 32-Bit-Treiber sind nicht für 64-Bit-Versionen verwendbar. Ein anderes Problem ist allerdings lösbar; aus Sicherheitsgründen verlangen neuere Windows-Versionen signierte Treiber. Diese Überprüfung lässt sich deaktivieren. Mit irgendwelchen "Definitionen" hat das alles nichts zu tun. Wenn Du eine genauere Betrachtung wünscht, nenne Ross und Reiter, d.h. exakt welche alte und welche neue Windows-Version, und welche Geräte betroffen sind/sein sollen.
Gerhard O. schrieb: > Vielleicht könnte man sogar ein Update Tool bauen, > das mit vielen Definitionsdateien zurecht kommt. Diese Dateien gibt es i.d.R. garnicht - was gebraucht wird, ist ein Treiber, der unter der Version läuft, und für uralte Geräte macht der Hersteller halt keinen mehr. In speziellen Fällen wie Scanner hilft alternative Software wie z.B. Vuescan. Georg
Berthold schrieb: > Gerhard O. schrieb: >> Bekanntlich werden mit neuen Versionen von Windows viele USB Geräte in >> negativer Weise betroffen. > > Bekanntlich? Nö. Viele? Auch nicht. > >> Daß der eigentliche USB Treiber bei neueren Windows Versionen völlig anders > funktioniert ist ja nicht sehr wahrscheinlich. > > Je nachdem, was "altes" und was "neues" Windows sind, ist genau das das > Problem. Treiber für Müll wie Windows 98 sind nicht mit XP verwendbar, > Treiber für XP sind nicht für neuere Windows-Versionen verwendbar, und > 32-Bit-Treiber sind nicht für 64-Bit-Versionen verwendbar. > > Ein anderes Problem ist allerdings lösbar; aus Sicherheitsgründen > verlangen neuere Windows-Versionen signierte Treiber. Diese > Überprüfung lässt sich deaktivieren. > > Mit irgendwelchen "Definitionen" hat das alles nichts zu tun. > > Wenn Du eine genauere Betrachtung wünscht, nenne Ross und Reiter, d.h. > exakt welche alte und welche neue Windows-Version, und welche Geräte > betroffen sind/sein sollen. OK, Danke. Es scheint, daß ich da auf dem Holzweg bin. Habe momentan nichts Konkretes das mir Probleme bereitet. Ich fand es etwas überraschend, dass z.B. ein CH340 Treiber der mit W10X64 einen neuen Treiber mit W11X64 braucht. (ich habe ein W11 Testsystem) Nach Download des aktuellen Treibers funktionierte es auch dort. Mich wundert nur, warum macht man das? Könne man funktionierende Systeme nicht endlich einmal in Ruhe lassen? Was ist an dem vorherigen CH340 Treiber do unpassend, dass W11 nicht damit zurecht kommt. Aus der Sicht eines "Laien" finde ich es irgendwie eine unnötige Schikane. Warum gibt es da als Abhilfe keinen "Legacy" Modus der existierende Systeme (auf eigenes Risiko) weiterverwendbar macht. Dass der Unterschied zwischen X32 zu X64 berücksichtigt werden müsste, kann ich ja noch verstehen. Aber es gab ja auch schon X64 mit XP. Irgendwie finde ich diese immer wieder auftretende Versionsprobleme als eine nicht notwendige Schikane aus der Sicht des einfachen PC Benutzers und daß sich die BS Hersteller etwas mehr "bemühen" sollten um unnötige Bereicherung der Müllhalden zu vermeiden. Danke für Dein Angebot Näheres über spezifische Probleme wissen zu wollen. Wie gesagt, im Augenblick läuft alles. Aber das sagt heutzutage wenig aus. Gruß, Gerhard
Gerhard O. schrieb: > Mich wundert nur, warum macht man das? Könne man funktionierende > Systeme nicht endlich einmal in Ruhe lassen? Was ist an dem vorherigen > CH340 Treiber do unpassend, dass W11 nicht damit zurecht kommt. Wahrscheinlich nur die Kennung, bzw. ein dicker Scheck an MS. Berthold schrieb: > Ein anderes Problem ist allerdings lösbar; aus Sicherheitsgründen > verlangen neuere Windows-Versionen signierte Treiber. Diese > Überprüfung lässt sich deaktivieren.
Georg schrieb: > Gerhard O. schrieb: >> Vielleicht könnte man sogar ein Update Tool bauen, >> das mit vielen Definitionsdateien zurecht kommt. > > Diese Dateien gibt es i.d.R. garnicht - was gebraucht wird, ist ein > Treiber, der unter der Version läuft, und für uralte Geräte macht der > Hersteller halt keinen mehr. > > In speziellen Fällen wie Scanner hilft alternative Software wie z.B. > Vuescan. > > Georg Danke für den Hinweis. VUescan kannte ich noch nicht. Aber wie gesagt, warum muß der Hersteller funktionierende Treiber immer wieder unbrauchbar machen, wenn die betroffenen Geräte nicht mehr unterstützt werden? Kann man im BS keinen Legacy Layer einbauen? Warum sträubt man sich so etwas Umweltbewußter zu denken? Die Entwickler leben ja schließlich nicht in einen Vakuum und daß unnötige Obsoleszenz Folgen hat kann jedes Kind sehen. Irgendwie finde ich mittlerweile die ganze USB Szene einen "Clusterf..." - USB war bestimmt eine gute Idee, die sich aber aus verschiedensten Gründen für Manche eher ein Fluch als Segen ausgewirkt hat. Z.B. wieviele High-End Audio Studio Geräte wurden durch BS Upgrades regelmäßig unbrauchbar gemacht. Da gibt es wahrscheinlich viele Benutzer die dadurch viele tausende Euro ausgeben mußten um wieder funktionierende Geräte zu haben. OK. Beenden wir das Thema. Sich darüber zu beschweren bringt ja nichts. Ist halt nur schade, daß es so ist wie es ist. Ich wollte nur wissen ob es oft nur an Definitionen liegt. Wenn natürlich der Treiber selber nicht mehr passt, ist es sowieso ein verlorenes Spiel.
Gerhard O. schrieb: > USB war bestimmt eine gute Idee, > die sich aber aus verschiedensten Gründen für Manche eher ein Fluch als > Segen ausgewirkt hat. An USB liegt es weniger. Mein erster Parallelport-Scanner musste beim Upgrade von Windows 98 auf Windows 2000 dran glauben. Der teure Canon-Scanner, den ich danach gekauft habe, läuft heute noch. Gerhard O. schrieb: > Die Entwickler leben > ja schließlich nicht in einen Vakuum Die wollen auch jeden Tag ihre Brötchen verdienen. Wenn sie Treiber bauen, die bis zum Ende aller Tage funktionieren, müssen das nicht nur Hellseher sein, sondern vor allem hungrige Hellseher... Gerhard O. schrieb: > Z.B. wieviele High-End Audio Studio Geräte wurden durch BS Upgrades > regelmäßig unbrauchbar gemacht. Hast Du da ein Beispiel? Ich kenne nur ein paar teure Gaming-Joysticks, bei denen das der Fall war. Bei denen lag das allerding hauptsächlich daran, dass sie keine eigene USB-ID genutzt haben, sondern einen Platzhalter aus einem Whitepaper von STM. (Ich bin bei einem Hobbyprojekt in die gleiche Falle gelaufen.)
:
Bearbeitet durch User
Walter T. schrieb: > Gerhard O. schrieb: >> USB war bestimmt eine gute Idee, >> die sich aber aus verschiedensten Gründen für Manche eher ein Fluch als >> Segen ausgewirkt hat. > > An USB liegt es weniger. Mein erster Parallelport-Scanner musste beim > Upgrade von Windows 98 auf Windows 2000 dran glauben. Der teure > Canon-Scanner, den ich danach gekauft habe, läuft heute noch. Mein teurer HP Scanner mußte damals an XP glauben, weil HP keinen Ersatz Treiber dafür bereitstellen wollte. > > Gerhard O. schrieb: >> Die Entwickler leben >> ja schließlich nicht in einen Vakuum > > Die wollen auch jeden Tag ihre Brötchen verdienen. Wenn sie Treiber > bauen, die bis zum Ende aller Tage funktionieren... Naja. Ich bin der Meinung, "Never break a running system". Die Benutzer von Atmel Studio können ja ein Liedchen singen wie unnötig fragil ihr USB Implementation war. Der kleinste Wind brachte dieses Konstrukt zum Einsturz. Hätte man alles das nicht robuster machen können? Mir scheint, so Vieles in unserer modernen Technik ist heutzutage so fragil, daß man von Robustheit nicht wirklich mehr sprechen kann. Wieviele TCP/IP Geräte werden regelmäßig durch Änderungen unbrauchbar. Man sollte die legale Frage stellen ob es eine Vergehen ist, Obsoleszenz durch SW und Standard Designentscheidungen zu verursachen die aus Hardware Gründen eigentlich unnötig ist. Ist es dem Käufer zumutbar den Gebrauch eines Gerätes durch SW Inkompatibilitäten vorzeitig zu beenden? Ich erwarte als Benutzer von USB Geräten, daß es IMMER ohne umfangreichen und nerviger Fehlersuche funktioniert. Hier hat die Industrie klar und deutlich aus verschiedensten Gründen versagt, nicht imstande oder Willens zu sein, robuste Implementationen von USB zu erstellen die mit dem Fortschritt funktionell bleiben. Im Prinzip sehe ich keinen Grund warum USB Treiber unbrauchbar werden - Es ist in den Augen der Entwickler/Firmen augensichtlich einfach nicht wichtig, Gerätefunktionalität zu erhalten. Ist es nicht bedeutsam, daß viele alte SW in aktuellen PCs teilweise noch funktioniert und nur die Treiber Schwierigkeiten machen und deshalb die SW am Ende als unbrauchbar zu verurteilen? Ob 32-bit oder 64-bit, es sollte keinen Unterschied machen. 32-bit SW funktioniert schließlich in den meisten Fällen im X64 BS. Es fehlt einfach am Willen Funktionalität zu erhalten. > > Gerhard O. schrieb: >> Z.B. wieviele High-End Audio Studio Geräte wurden durch BS Upgrades >> regelmäßig unbrauchbar gemacht. > > Hast Du da ein Beispiel? Ich kenne nur ein paar teure Gaming-Joysticks, > bei denen das der Fall war. Bei denen lag das allerding hauptsächlich > daran, dass sie keine eigene USB-ID genutzt haben, sondern einen > Platzhalter aus einem Whitepaper von STM. Leider nicht ohne Rückfrage. Es handelte sich um irgendwelche 24-Kanal Studio Aufnahmegeräte.
:
Bearbeitet durch User
Das ist im Grunde ganz einfach: Microsoft fummelt bei jeder neuen Windowsversion mehr oder weniger viel an den Systemschnittstellen rum. Damit die Gerätetreiber mit der neuen Version auch noch laufen, müssen sie an die neuen Schnittstellen angepasst werden. Viele Hersteller sagen sich dann aber: https://www.youtube.com/watch?v=q5WAEUWsiGY
sagen wir mal so, durch die Fake FTDI seriell Adapter und das unselige patchen in XP (oder war es windows7?) funktioniert mein USB dual RS232 Adapter am win7 nicht mehr, aber ich hatte ihn noch nicht entsorgt und nun am windows10/11 funktioniert er wieder! https://www.heise.de/make/meldung/Treiber-gegen-gefaelschte-Chips-FTDI-ruft-Fake-Killer-zurueck-2435079.html kam für mich zu spät
IT-Abteilung schrieb: > Das ist im Grunde ganz einfach: > > Microsoft fummelt bei jeder neuen Windowsversion mehr oder weniger viel > an den Systemschnittstellen rum. Damit die Gerätetreiber mit der neuen > Version auch noch laufen, müssen sie an die neuen Schnittstellen > angepasst werden. Viele Hersteller sagen sich dann aber: > > https://www.youtube.com/watch?v=q5WAEUWsiGY Ja. Aber warum? "Never break a running system". Was ist daran für MS so schwer zu verstehen?
Vielleicht ist es an der Zeit mal über den Tellerrand zu schauen. Wie Linux das macht....
Hugo schrieb: > Vielleicht ist es an der Zeit mal über den Tellerrand zu schauen. > Wie > Linux das macht.... Das können die Linux Users leichthin so daherzusagen:-)
Gerhard O. schrieb: > Was ist daran für MS so schwer zu verstehen? Ich kann MS nun wirklich nicht leiden, aber hier ist MS nur bedingt schuld. Manchmal müssen Schnittstellen einfach an neue Entwicklungen angepasst werden. Hugo schrieb: > Wie Linux das macht.... Genauso. Der Unterschied ist aber, dass Linux die Treiber schon im Kernel hat und diese bei Änderungen an den Schnittstellen einfach gleich mitangepasst werden.
Gerhard O. schrieb: > "Never break a running system". Du entwickelst doch selbst Sachen mit Software. Wenn Du an keiner Stelle eine alte Funktionalität durch etwas anderes ersetzen düftest, könntest Du Deine Sachen ab einem bestimmten Punkt nicht mehr weiterentwickeln. Klar - bei Systemen mit einigen Millionen Exemplaren ist die Abwägung natürlich noch einmal eine komplett andere als bei Kleinstückzahlen. Aber in diesem Spannungsumfeld bewegen wir uns doch alle.
:
Bearbeitet durch User
Gerhard O. schrieb: >> Wie Linux das macht.... > > Das können die Linux Users leichthin so daherzusagen:-) Wenn man das Windows in der VM hat, kann man ein Entwicklungssystem mitsamt Treibern auf einem alten Stand einfrieren. Man kann eine solche VM dann auch problemlos auf einen neuen Rechner oder ein neues Betriebssystem schieben, ohne sich um neue Treiber kümmern zu müssen. Sicherheitsaspekte einer uralten VM spielen keine wesentliche Rolle, weil man der Netzugang von und zu der VM einschränken oder ganz blockieren kann. Auf diese Art kommt man auch locker mit einem Linux als Host zurecht, weil der alte Kram des Windows-Vorgängers in einer von Blech konvertieren VM sitzt.
:
Bearbeitet durch User
IT-Abteilung schrieb: > Gerhard O. schrieb: >> Was ist daran für MS so schwer zu verstehen? > > Ich kann MS nun wirklich nicht leiden, aber hier ist MS nur bedingt > schuld. Manchmal müssen Schnittstellen einfach an neue Entwicklungen > angepasst werden. > > Hugo schrieb: >> Wie Linux das macht.... > > Genauso. Der Unterschied ist aber, dass Linux die Treiber schon im > Kernel hat und diese bei Änderungen an den Schnittstellen einfach gleich > mitangepasst werden. Aber für den Benutzer ist das alles so nervig und kostspielig und ist in manchen Fällen mit der Verlust wichtiger Funktionalität verbunden, wenn kein Ersatz im Markt erhältlich ist. Ich bin immer noch der Meinung, dass es auch von Seite MS nicht zwingend notwendig ist. Letzten Endes haben wir hier ein Betriebssystem, daß mit geeigneter SW läuft. Demzufolge müsste funktionierende SW die HW unterstützen. SW kann alles. An der USB HW Schnittstelle hat sich nicht unbedingt Wichtiges geändert. Solange die Treiber und ältere SW noch zusammenspielen könnten, könnte Funktionalität erhalten bleiben. Tut man aber nicht. Ich würde wirklich brennend gerne wissen welche USB Anwendungen nicht mehr funktionell erhalten werden können. An der PC HW liegt es nun wirklich nicht. Z.B. kann ich in einer VM und 32-bit XP AS4.19 mit AVR-ISP II erfolgreich im selben PC betreiben. Geht also. In X64 aber nicht. (Ist aber hier nicht wichtig, weil moderne SW ohnehin funktioniert).es gibt Berichte, dass das mit speziellen Klimmzügen machbar ist, AS4.19 plus Programmiergerät in X64 zu betreiben, hat aber bei mir nie zum Erfolg geführt. Bei den häufig vorkommenden USB Geräten wie Maus, Tastatur, Serial Com hat man es ja auch geschafft, Einstecken, 10s warten, funktioniert! Es ist schade, daß das bei so viel Legacy Zeug nie so implementiert wurde und deshalb so viele Wracks existieren.
Gerhard O. schrieb: > Es > ist schade, daß das bei so viel Legacy Zeug nie so implementiert wurde > und deshalb so viele Wracks existieren. Da gebe ich Dir recht. Allerdings liegt es eben meist am Legacy-Zeug und weniger am Betriebssystem. Und vielleicht fällt uns das USB-Geräte-Dilemma auch nur deshalb auf, weil wir mittlerweile verwöhnt sind. Wenn ich überlege, wieviel Hardware vom C128D ich am Amiga 500 weiterverwenden konnte, oder wie lange ich meine geliebte sauteure SoundBlaster AWE 32 (aus zweiter Hand) wirklich benutzen konnte, bis der ISA-Slot verschwunden war...
(prx) A. K. schrieb: > Gerhard O. schrieb: >>> Wie Linux das macht.... >> >> Das können die Linux Users leichthin so daherzusagen:-) > > Wenn man das Windows in der VM hat, kann man ein Entwicklungssystem > mitsamt Treibern auf einem alten Stand einfrieren. Man kann eine solche > VM dann auch problemlos auf einen neuen Rechner oder ein neues > Betriebssystem schieben, ohne sich um neue Treiber kümmern zu müssen. > > Sicherheitsaspekte einer uralten VM spielen keine wesentliche Rolle, > weil man der Netzugang von und zu der VM einschränken oder ganz > blockieren kann. > > Auf diese Art kommt man auch locker mit einem Linux als Host zurecht, > weil der alte Kram des Windows-Vorgängers in einer von Blech > konvertieren VM sitzt. Naja, ich mache es auch mittlerweile so, daß ich "schwierige" SW in der VM mit dem korrekten BS laufen lasse und das funktioniert auch. Ich habe auch Linux in der VM das ich ab und zu für Programmierarbeiten verwende. Aber es wäre halt schön wenn alles so wie früher jahrelang im aktuellen BS funktionieren würde und man nicht immer eine Extrawurst braucht. Aber heutzutage bricht so Vieles mit Regelmäßigkeit. Ich glaube es fehlt so etwas in der Welt wie "verantwortungsbewußter Fortschritt"; ich habe aber eher den Eindruck wir leben heutzutage im Wilden Westen des Fortschritts.
Walter T. schrieb: > Gerhard O. schrieb: >> Es >> ist schade, daß das bei so viel Legacy Zeug nie so implementiert wurde >> und deshalb so viele Wracks existieren. > > Da gebe ich Dir recht. Allerdings liegt es eben meist am Legacy-Zeug und > weniger am Betriebssystem. Deswegen sind diese Probleme so nervig. > > Und vielleicht fällt uns das USB-Geräte-Dilemma auch nur deshalb auf, > weil wir mittlerweile verwöhnt sind. Wenn ich überlege, wieviel Hardware > vom C128D ich am Amiga 500 weiterverwenden konnte, oder wie lange ich > meine geliebte sauteure SoundBlaster AWE 32 (aus zweiter Hand) wirklich > benutzen konnte, bis der ISA-Slot verschwunden war... Ja. Das ging mir genauso. Ich habe die Karten heute noch... (zum Ansehen;-) )
Man muss aber anmerken, dass USB-Geräte mit deren aktuellen Treibern heutzutage schon sehr zuverlässig funktionieren. Das war zu Beginn noch ganz anders. Von da her hat Microsoft sicher nicht alles falsch gemacht.
Ich habe gerade gegrübelt, welches das älteste USB-Gerät in meinem Fundus ist, das ich immer noch regelmäßig nutze. Momentan stehe ich bei meinem ersten Arduino TNG von vor 18 Jahren.
Johnny B. schrieb: > Man muss aber anmerken, dass USB-Geräte mit deren aktuellen > Treibern > heutzutage schon sehr zuverlässig funktionieren. Das war zu Beginn noch > ganz anders. Von da her hat Microsoft sicher nicht alles falsch gemacht. Ja. Das gebe ich offen zu. Manches ist nun mittlerweile sehr einfach geworden und funktioniert gut. Kann mich nicht erinnern Probleme mit Maus, Tastatur, Drucker, VCM und Anderes zu haben. Aber es nervt, wenn teures Zubehör wie Programmiergeräte, nur noch mit Klimmzügen gebrauchbar sind. Naja, der Dampf ist abgelassen, wenden wir uns also den wichtigeren Dingen zu:-) Zeit für einen frisch gebrauten Kaffee...
Walter T. schrieb: > Ich habe gerade gegrübelt, welches das älteste USB-Gerät in meinem > Fundus ist, das ich immer noch regelmäßig nutze. > > Momentan stehe ich bei meinem ersten Arduino TNG von vor 18 Jahren. Was ist ein TNG? Irgendetwas mit Packet Radio, APRS?
Immerhin kann ich meinen Laserdrucker von 1999 mit USB 1.1 bis heute verwenden.
Gerhard O. schrieb: > Was ist ein TNG? Ein Tippfehler. Arduino NG hieß der. Der erste Arduino mit USB. Danach kam der Arduino Duomillanueve.
(prx) A. K. schrieb: > Immerhin kann ich meinen Laserdrucker von 1999 mit USB 1.1 bis > heute > verwenden. Aber unter Linux. Nicht wahr?
Gerhard O. schrieb: > Aber unter Linux. Nicht wahr? Auch in Win10 finde ich noch Treiber, mit denen er funktioniert. Vor ein paar Wochen landete er zwar an der Fritzbox und wird seither über 9100 angesprochen, aber davon wars USB.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Gerhard O. schrieb: >> Aber unter Linux. Nicht wahr? > > Auch in Win10 finde ich noch Treiber, mit denen er funktioniert. Eigentlich wundert mich das nicht, weil auch mein alter Lexmark 4039 von 1995 noch mit W10 funktioniert, betreibe ihn allerdings über das Netzwerk. USB hatte der noch nicht.
Gerhard O. schrieb: > Solange die Treiber und ältere SW noch > zusammenspielen könnten, könnte Funktionalität erhalten bleiben. Tut man > aber nicht. für meinen Canon LIDE50 am win7 gibt es keine Treiber mehr von Canon! Dito mit dem BJC8200 photo, aber der ist tot, der Scanner lebt noch und man konnte mit VueScan zumindest den Treiber extern nachkaufen. Ich finde es nur schrecklich das funktionierende Hardware durch notwendig neue OS entsorgt werden muss!
Walter T. schrieb: > Gerhard O. schrieb: >> Was ist ein TNG? > > Ein Tippfehler. Arduino NG hieß der. Der erste Arduino mit USB. Danach > kam der Arduino Duomillanueve. OK. Danke. Kaum zu glauben, daß Arduino schon so alt ist...
Joachim B. schrieb: > Gerhard O. schrieb: >> Solange die Treiber und ältere SW noch >> zusammenspielen könnten, könnte Funktionalität erhalten bleiben. Tut man >> aber nicht. > > für meinen Canon LIDE50 am win7 gibt es keine Treiber mehr von Canon! > Dito mit dem BJC8200 photo, aber der ist tot, der Scanner lebt noch und > man konnte mit VueScan zumindest den Treiber extern nachkaufen. > Ich finde es nur schrecklich das funktionierende Hardware durch > notwendig neue OS entsorgt werden muss! Das ist ja auch mein Sentiment.
> Man braucht z.B. nur an diverse uC Programmieradapter oder Scanner, Drucker > >
und andere Spezialgeräte denken.
Was mir da mit einem neuen PC und W11 für die uC Programmierung und für
Stratum 1 Zeitserver-Funktion fehlte, waren je ein (Hardware-) COM und
LPT Port.
Zwei verschiedene PCI-e Karten mit je einem COM und LPT Port waren trotz
angeblich zertifizierten W11 Treibern nicht zum Laufen zu bringen.
Erst nach viel Unterstützung u.a. durch das MS Supportforum habe ich es
dann nach Monaten zum Laufen bekommen.
Beitrag #7240811 wurde von einem Moderator gelöscht.
Dirk O. schrieb: > Zwei verschiedene PCI-e Karten mit je einem COM und LPT Port waren trotz > angeblich zertifizierten W11 Treibern nicht zum Laufen zu bringen. > Erst nach viel Unterstützung u.a. durch das MS Supportforum habe ich es > dann nach Monaten zum Laufen bekommen. Klingt nach Bullshit, sonst hättest Du beschrieben, wo das Problem lag und was die Lösung war.
Gerhard O. schrieb: > Bekanntlich werden mit neuen Versionen von Windows viele USB Geräte in > negativer Weise betroffen. > [...] > Was meint ihr? Sich damit abfinden müssen, oder besser, versuchen für > dieses leidige Problem, Lösungen zu finden um nützliche USB Geräte vor > dem unnötigen Tod zu bewahren? Wenn es Linux-Treiber und -Software für die Geräte gibt, könnte man sie womöglich über Passthrough an eine Linux-VM durchreichen und nutzen.
IT-Abteilung schrieb: > Viele Hersteller sagen sich dann aber: Kannst Du auch schreiben was sie sich sagen? Immee diese sch**** Videos. ;) Bah schrieb im Beitrag #7240811: > Mit dem Windows-Mist kann man nicht arbeiten, Das gilt vielleicht für Dich. Ich kann mit Windows wunderbar arbeiten, und auch Geld verdienen.
:
Bearbeitet durch User
René H. schrieb: > Kannst Du auch schreiben was sie sich sagen? Immee diese sch**** Videos. Nö, ja, nö, wieso nö, da bin ich mir auch nicht einig, wieso, ja, nö
Gerhard O. schrieb: > Mein teurer HP Scanner mußte damals an XP glauben, weil HP keinen Ersatz > Treiber dafür bereitstellen wollte. Ein etwas unglückliches Beispiel. Oder wie kommst Du auf die Idee, ein 20 Jahre altes Problem heute noch rauskramen zu müssen. > Die Benutzer von Atmel Studio können ja ein Liedchen singen wie unnötig > fragil ihr USB Implementation war. Der kleinste Wind brachte dieses > Konstrukt zum Einsturz. Hätte man alles das nicht robuster machen > können? Aja - benutzt Atmel Studio nicht diesen komischen USB-Stack im Userspace (WinUSB, LibUSB0 und Konsorten)? Das ist wirklich etwas fragil, hat aber nichts mit USB an sich zu tun - da muß man sich nicht wundern ...
Gerhard O. schrieb: > Ich erwarte Jede Enttäuschung beginnt mit einer Erwartung oder einer Hoffnung.
Ein T. schrieb: > Gerhard O. schrieb: >> Ich erwarte > > Jede Enttäuschung beginnt mit einer Erwartung oder einer Hoffnung. Vor allem, wenn die Erwartung recht naiv ist.
DerEinzigeBernd schrieb: > Dirk O. schrieb: > >> Zwei verschiedene PCI-e Karten mit je einem COM und LPT Port waren trotz >> angeblich zertifizierten W11 Treibern nicht zum Laufen zu bringen. >> Erst nach viel Unterstützung u.a. durch das MS Supportforum habe ich es >> dann nach Monaten zum Laufen bekommen. > > Klingt nach Bullshit, sonst hättest Du beschrieben, wo das Problem lag > und was die Lösung war. Das "Bullshit" verbitte ich mir. Wenn du Interesse hast, kann ich das Problem gern beschreiben.
Ein T. schrieb: > Gerhard O. schrieb: >> Ich erwarte > > Jede Enttäuschung beginnt mit einer Erwartung oder einer Hoffnung. Vor allem, wenn die Erwartung recht naiv ist. Dirk O. schrieb: > Das "Bullshit" verbitte ich mir. Wenn du Interesse hast, kann ich das > Problem gern beschreiben. Brauchst Du Dir nicht zu verbitten. Es ist Bullshit, wenn Du das hier einfach so ohne weitere Details reinhaust, womit dann eben keiner nachvollziehen kann, woran es denn wirklich gelegen hat. Naja, wolltest eben auch mal was gegen Windows beitragen ...
Gerhard O. schrieb: > SW kann alles Warum gibt's dann überhaupt noch Software-Entwickler, wenn Software eh alles kann? Vielleicht weil Software-Entwicklung ein riesiger Aufwand ist, und Neuerungen viel Arbeit sind? Das bedeutet umgekehrt auch, dass es ein immenser Aufwand ist, uralte Software weiter zu unterstützen. Software Projekt Management besteht im Wesentlichen aus Prioritäten setzen, für welche Funktionalität man die knappe Arbeitskraft einsetzt. Das unterstützen uralter Treiber bringt wenig, hat also auch geringe Priorität. Gerhard O. schrieb: > Naja. Ich bin der Meinung, "Never break a running system". Wurde denn ein konkretes System kaputt gemacht? Oder hast du vielleicht ein neues System gekauft oder das OS aktualisiert? Warum hast du das gemacht? Um neue Funktionen nutzen zu können? Diese neuen Funktionen sind halt nicht so einfach mit alter Funktionalität unter einen Hut zu bringen. Bleib halt beim alten System. Vielleicht können ja alle, die verlangen, dass alle alten Zöpfe dran bleiben, sich bei Microsoft bewerben um unentgeltlich alte Funktionen zu integrieren. Ihr erwartet es ja so... Jens G. schrieb: > Das ist wirklich etwas fragil, Eigentlich ist es ziemlich robust. Damit eine gute Möglichkeit die diversen Tücken von Kerneltreibern zu umgehen.
Niklas G. schrieb: > Gerhard O. schrieb: >> SW kann alles > > Warum gibt's dann überhaupt noch Software-Entwickler, wenn Software eh > alles kann? Vielleicht weil Software-Entwicklung ein riesiger Aufwand > ist, und Neuerungen viel Arbeit sind? Das bedeutet umgekehrt auch, dass > es ein immenser Aufwand ist, uralte Software weiter zu unterstützen. Ich wollte damit nur ausdrücken, daß man es nicht wichtig genug fand, alte USB Treiber nicht zu brechen. Die PC HW ist ja nicht daran schuld, daß ältere SW Anwendungen schadhaft werden, weil man es nicht wichtig genug findet existierende Funktionalität zu erhalten. In der VM funktionierts ja auf dem modernen PC wenn die dafür geschriebenen BS eingesetzt werden. > > Software Projekt Management besteht im Wesentlichen aus Prioritäten > setzen, für welche Funktionalität man die knappe Arbeitskraft einsetzt. > Das unterstützen uralter Treiber bringt wenig, hat also auch geringe > Priorität. > > Gerhard O. schrieb: >> Naja. Ich bin der Meinung, "Never break a running system". > > Wurde denn ein konkretes System kaputt gemacht? Oder hast du vielleicht > ein neues System gekauft oder das OS aktualisiert? Warum hast du das > gemacht? Um neue Funktionen nutzen zu können? Diese neuen Funktionen > sind halt nicht so einfach mit alter Funktionalität unter einen Hut zu > bringen. Bleib halt beim alten System. Es geht darum, daß es wünschenswert wäre, daß der aktuelle PC und BS mir wichtige Anwendungen weiterhin funktionsfähig unterstützen würde. Ich sehe nicht ein, daß ehemalige 32 oder 64 Anwendungen die schon unter W2K oder XP oder W7 liefen nicht länger komplett gebrauchsfähig sind. > > Vielleicht können ja alle, die verlangen, dass alle alten Zöpfe dran > bleiben, sich bei Microsoft bewerben um unentgeltlich alte Funktionen zu > integrieren. Ihr erwartet es ja so... Sie brauchen nur existierende Treiber drin lassen. Nicht laufende SW oder Treiber kosten ja nichts. Alte HW kann dann auf die Treiber zugreifen für die sie geschrieben wurden. Windows ist schon so komplex, daß etwas mehr Komplexität für Legacy Support die Sau auch nicht mehr fett nachen. > > Jens G. schrieb: >> Das ist wirklich etwas fragil, > > Eigentlich ist es ziemlich robust. Damit eine gute Möglichkeit die > diversen Tücken von Kerneltreibern zu umgehen. Aber lassen wir es. Wir haben eben hier unterschiedliche Auffassungen. Es ist leider so, daß maßgebliche Leute, und bitte nichts für ungut, eben denken, daß man alle Brücken verbrennen muß um Fortschritt zu erzielen. Aber es muß nicht so sein. Behutsamer Fortschritt, ohne Brücken unnötig zu verbrennen, wäre der Menschheit, insgesamt gesehen, oft dienlicher und besser für den Planeten und seine Ressourcen. Ich bin halt der Ansicht, daß aktuelle BS alle Anwendungen HW mässig zurückgehend bis W2K prinzipiell unterstützen könnte. Es gibt keinen Grund, ausser, daß man es nicht wichtig genug findet. Sogar W98 32-bit Programme laufen zum Teil noch. Ich verlange ja nicht, daß 16-bit unterstützt werden muß. Aber w.g. alle wichtigen 32-bit HW/SW Anwendungen sollten heute noch zusammen lauffähig sein. Das hätte viele Gerätschaften vor der Verschrottung bewahrt. Die Berge von Elektronikmüll sprechen doch eine sehr deutliche Sprache. Der unnötige Verschleiss in den letzten 20 Jahren hat bestimmt Trillionen MW an Energie und andere Ressourcen gekostet um neues kurzlebiges Zeugs anstatt zu produzieren. Aber der wahnsinnige Ressourcenverbrauch wird ja lieber unter den Tisch gefegt.
:
Bearbeitet durch User
Gerhard O. schrieb: > Die PC HW ist ja nicht daran schuld, daß ältere SW Anwendungen schadhaft > werden, weil man es nicht wichtig genug findet existierende > Funktionalität zu erhalten. Schon, z.B. ganz alte DOS-Software funktioniert oft nicht mehr weil heutige PCs zu schnell sind und weil sich das alte Timing nicht präzise einhalten lässt. > In der VM funktionierts ja auf dem modernen > PC wenn die dafür geschriebenen BS eingesetzt werden. Ja, aber das alte BS unterstützt nicht die neuen Funktionen des neuen BS. Und beides unter einen Hut zu bringen ist Aufwand. Gerhard O. schrieb: > Ich sehe nicht ein, daß ehemalige 32 oder 64 Anwendungen die schon unter > W2K oder XP oder W7 liefen nicht länger komplett gebrauchsfähig sind. Anwendungen oder Treiber? Großer Unterschied! Siehst du denn ein dass alte Windows-Versionen ziemlich unsicher waren? Dass das geändert werden musste? Das geht eben nicht ohne Kompatibilität zu brechen. So etwas betrifft häufig Anwendungen, die sowieso nicht besonders sauber umgesetzt waren. Gerhard O. schrieb: > Sie brauchen nur existierende Treiber drin lassen. Was nutzen alte Treiber, die alte APIs nutzen welche nicht mehr vom System unterstützt werden? Gerhard O. schrieb: > Nicht laufende SW oder Treiber kosten ja nichts. Großer Irrtum; alle alte Software muss gepflegt, gewartet, aktualisiert werden. Das wird mit der Zeit immer mehr. Selbst Microsoft hat da nicht die Manpower für. Gerhard O. schrieb: > daß man alle Brücken verbrennen muß um Fortschritt zu erzielen Das stimmt überhaupt nicht. Microsoft ist sehr konservativ. Sehr viel alte Software funktioniert eben doch. Selbst manche (!) DOS-Programme gehen noch unter 32bit-Windows. Aber auf Biegen und Brechen alles zu unterstützen, egal was für krumme Hacks es am System vorbei macht, egal was für unsichere Zugriffe verwendet werden, was für veraltete APIs benutzt werden, geht einfach nicht. Das gilt eben besonders für Treiber, denn der Kernel kann nicht beliebig Kompatibilitätsschichten anbieten. Gerhard O. schrieb: > Ich bin halt der Ansicht, daß aktuelle BS alle Anwendungen HW mässig > zurückgehend bis W2K prinzipiell unterstützen könnte Wie soll denn z.B. Win11 Anwendungen ausführen, die routinemäßig auf C:\Programme schreibend zugreifen? Nach dem Motto "das ist ein Oldtimer, der darf das"? Oder "alte Viren sind okay"? Was ist mit Anwendungen die "if (WindowsVersion != Win2k) error();" machen? Gerhard O. schrieb: > Aber w.g. alle wichtigen 32-bit HW/SW Anwendungen sollten heute noch > zusammen lauffähig sein Wie stellst du dir vor dass ein 64bit-OS einen 32bit-Treiber laden soll?
> Brauchst Du Dir nicht zu verbitten. Es ist Bullshit, wenn Du das hier einfach >
so ohne weitere Details reinhaust, womit dann eben keiner nachvollziehen kann,
woran es denn wirklich gelegen hat. Naja, wolltest eben auch mal was gegen Windows
beitragen ...
Nein, ich hatte angenommen, dass mein Problem diesen Thread nur unnötig
aufblähen würde, wollte es aber zumindest erwähnen, weil der
Threadstarter auch von uC Programmierung etc. sprach. Die konkrete
Beschreibung meines Themas wäre aber so umfangreich, dass ich damit dem
Threadstarter sein eher allgemeines Thema wegnehmen würde.
Du siehst, ICH habe nachgedacht über das, was ich mache. Von deinen
Kommentaren kann ich das nicht sagen.
Gerhard O. schrieb: > Die Berge von Elektronikmüll sprechen doch eine sehr deutliche Sprache. > Der unnötige Verschleiss in den letzten 20 Jahren hat bestimmt > Trillionen MW an Energie und andere Ressourcen gekostet um neues > kurzlebiges Zeugs anstatt zu produzieren. Aber der wahnsinnige > Ressourcenverbrauch wird ja lieber unter den Tisch gefegt. Full Ack! Gerhard O. schrieb: > (prx) A. K. schrieb: >> Gerhard O. schrieb: >>> Aber unter Linux. Nicht wahr? >> >> Auch in Win10 finde ich noch Treiber, mit denen er funktioniert. > > Eigentlich wundert mich das nicht, weil auch mein alter Lexmark 4039 von > 1995 noch mit W10 funktioniert, betreibe ihn allerdings über das > Netzwerk. USB hatte der noch nicht. Meine Vermutung: Beides sind Drucker die PostScript verstehen. Hoch leben Standards! Gerhard O. schrieb: > Naja, ich mache es auch mittlerweile so, daß ich "schwierige" SW in der > VM mit dem korrekten BS laufen lasse und das funktioniert auch. Ich habe > auch Linux in der VM das ich ab und zu für Programmierarbeiten verwende. > Aber es wäre halt schön wenn alles so wie früher jahrelang im aktuellen > BS funktionieren würde und man nicht immer eine Extrawurst braucht. Aber > heutzutage bricht so Vieles mit Regelmäßigkeit. Mit früher meinst du die Zeit, wo Leute ihr Büro/Keller mit zig PCs vollgestellt haben, weil die eine Software Windows braucht, die andere Linux, OS/2 etc. , dann ältere Kisten weil noch ein ISA Bus EPROM Programiergerät erhalten wird oder die Kiste wo man vor Jahren ein Kundenprojekt drauf hatte, das man vielleicht all Schaltjahre noch warten können muss. Seit ich weiss, was VMs sind und das auch so Dinge wie USB, Seriell und Parallelport gehen, liebe ich VMs (also seit 2003 als ich mit Xilinx ISE in VMware auf einem Linux Host per Parallelport einen Spartan3 programmierte). Joachim B. schrieb: > für meinen Canon LIDE50 am win7 gibt es keine Treiber mehr von Canon! > Dito mit dem BJC8200 photo, aber der ist tot, der Scanner lebt noch und > man konnte mit VueScan zumindest den Treiber extern nachkaufen. > Ich finde es nur schrecklich das funktionierende Hardware durch > notwendig neue OS entsorgt werden muss! Bei einem teuren guten A3 Scanner habe ich einfach ein älteres Notebook (lag herum, kosten 0) mit passendem alten Win XP oben auf den Scanner Deckel geklebt. Der Scanner kann nun also all die neuen Sachen wie "scan to usb", "scan to email" oder "scan to network folder" :-)
Christoph Z. schrieb: > Meine Vermutung: Beides sind Drucker die PostScript verstehen. Hoch > leben Standards! Stimmt, aber bei PCL kann man auch Glück haben.
Niklas G. schrieb: > Vielleicht können ja alle, die verlangen, dass alle alten Zöpfe dran > bleiben, sich bei Microsoft bewerben um unentgeltlich alte Funktionen zu > integrieren. Auch wenn Du es nicht glaubst. Ich kann mir vorstellen, dass sich, würde MS Windows XP als Quelloffen auf GitHub freigeben, eine Menge freiwilliger Programmierer dessen annehmen würde. Windows XP könnte dann ein neues Leben bekommen, und vielleicht ähnlich wie Linux und Mac-OS mehrere Distributionen bekommen (kompatibel zu einander und die alte Treiberstruktur).
Moin, An Niklas: Ich möchte jetzt nicht im Detail auf Deine Gedanken zu meinen Einwänden eingehen, aber verstehe Deine Einwände. Die technischen Hintergründe dürfen ja nicht ignoriert werden. Aber aus der Sicht des Users kann es extrem frustrierend sein wenn es zu (teuren) Problemen kommt. Deshalb bitte ich auch mich zu verstehen. Ein konkretes Beispiel aus dem Leben, was mir passiert ist: In den Mittel 90ern kaufte ich (eigene Firma) für ein wichtiges Entwicklungsprojekt Agilent Genesys für rund $16K. Es kam mit Parallelport Dongle. Damals lief das noch (32-bit) unter W98 und allen 32-bit Version nachfolgender Windows bis W10X32. Da man mit der Zeit geht, fiel eventuell der Umstieg auf 64-bit BS an um mit der Zeit zu gehen. Und damit fingen die Probleme an, weil Agilent die Donglesoftware meiner Version niemals auf 64-bit modernisierte. Trotz Legacy PCIe Multi-IO Karte funktioniert der Dongle Treiber auf dem i7 PC nur noch unter 32-bit BS in VM. Eine Anfrage bei Agilent resultierte in deren Position ich müsste halt die aktuelle SW neu für $24K kaufen, weil ich später nicht mehr die jährliche Maintenance bezahlen konnte. Das war unter den gegebenen Umständen für mich finanziell nicht mehr vereinbar und ging den VM Weg um die SW weiter verwenden zu können. Es ist klar, daß man nicht MS dafür verantwortlich machen kann wenn der SW Hersteller nicht daran interessiert ist die SW auf 64-bit ohne Neukauf lauffähig zu machen. Es ist aber trotzdem ein Ärgernis, daß han seine SW nich unter einem Fach und ein BS bringen kann. Das Gleiche passierte mir mit $2K Graphicode CAM SW. Unter 64-bit fiel der PP. Dongle Treiber aus. Unter glücklichen Umständen war ich aber imstande später durch kulantes Verhalten der Firma eine moderne ältere Version mit USB Dongle zu erhalten und die funktioniert auch unter W10X64 einwandfrei. Auch Pr99SE machte hin und wieder Probleme. Aber mit Altium geht es ja jetzt ohnehin richtig. Über die Jahre brachen dann auch andere Anwendungen wie AS4.19 und USB ISP und noch einige andere Sachen. Es war halt ohne Klimmzüge unmöglich ein stabiles Entwicklungsumfeld ohne reaktive Maßnahmen zu erhalten. Moderneres AS ist natürlich kein Problem mehr. Man geht halt mit der Zeit... Ich möchte jetzt aber das Thema abkühlen lassen, weil so ziemlich alles Relevante erörtert wurde. Zum Glück half mir VM die Funktionalität für mich wichtiger SW bis zum heutigen Tag zu erhalten. Es macht halt viel Arbeit sich seine Werkzeuge zu erhalten. Ich wünschte nur, es wäre nicht notwendig und einmal gekaufte SW und HW funktioniert ab 32-Bit unbegrenzt. In diesen Sinn, Euch noch ein schönes W.E. Gruß, Gerhard
Gerhard O. schrieb: > Aber es nervt, wenn > teures Zubehör wie Programmiergeräte, nur noch mit Klimmzügen > gebrauchbar sind. Es müffelt nach DOS-Kompatibel oder eben einem besonderen Treiber, der gewissermaßen die Windows-Runtime, das Time-Sharing unterwandert, und einen Direktzugriff erlaubt. Die Audiokarte, die ich habe, (schon älter) kann kein Directx, so dass man die eigentlich nur für Audioaufnahmen nehmen kann. Das ist jetzt kein gutes Beispiel für problematische Hardwarezugriffe - aber es ist eines, welches gewisse Probleme verstehen hilft. Ich selbst bin bei Windows 8 stehen geblieben (fand Vista bzw 7 deutlich besser) und bei Linux bei Fedora 33, damit ich in Ruhe Skyrim spielen kann. Wine kommt nicht immer hinter die tollen neuen Linux-Features der neusten Versionsnummer hinterher. Man würde sagen unsynchron. Haskell Plattform wollte unverständlicherweise nicht auf Windows ME laufen. Auch Steinberg hat seine Recordingsoftware ständig mit neueren Windowsversionen upgedatet - wenn man was neues in dieser Software nutzen wollte (neuer Algorithmus zum Komponieren z.B.), dann musste man auch ein anderes Windows benutzen. Das hatte mir damals auch gestunken. Sind aber so grob immer Softwaregeschichten. Windows selbst ist normalerweise überdurchschnittlich kompatibel - ein Superemulator. Normalerweise. Da ich aber auf Windows 8 stehen geblieben bin, weiß ich nicht, was bei den neuesten Windowsversionen los ist. Highlight ist ja u.a. dass man das "WSL" nutzen kann, und auf mingw, Unixtools, cygwin usw. eigentlich verzichten könnte. Dass die früheren Programme wie Regmon oder Filemon bei den sysinternals den Sourcecode vergessen, fand ich auch nicht schön. oder dass bei Unix/Linux oft die Maustreiber (oder Touchpads) so kacke sind. Mein Vater fand das Touchpad auf dem NB (von 2008) richtig toll - welches aber auf Linux nur sehr hakelig funzte. Aber man konnte sehen, dass es da gewissen Support im Ubuntu-Forum gab. (Ubuntu also gut - die Treibersituation aber eher nicht) Dann hatte der noch sehr gerne Mahjong gespielt. Die Mahjong-Version auf Linux war einfach nur hässlich, und lieblos hingeklatscht. Die Überlegungen gingen dahin, ein Terminalsystem auf dem NB zu installieren, damit wir den Platz nicht immer wechseln müssen. (Wir hatten nur das eine NB).
Gerhard O. schrieb: > Es ist aber trotzdem ein Ärgernis, daß han > seine SW nich unter einem Fach und ein BS bringen kann. Natürlich ist das ärgerlich, aber das ist halt Agilent schuld. Da hilft nur: Nicht mehr bei Agilent kaufen. Gerhard O. schrieb: > Ich wünschte nur, es wäre nicht notwendig und einmal gekaufte SW und HW > funktioniert ab 32-Bit unbegrenzt. Ist halt technisch nicht machbar, insbesondere bei Treibern. Dank WinUSB kann man auf USB-Geräte ohne eigenen Treiber zugreifen, und sollte es jemals einen Sprung auf 128bit-CPUs geben könnte das sogar immer noch funktionieren. Microsoft muss da nur ein relativ "normales" Windows-API für pflegen. Das wäre für Dongles, Programmiergeräte & Co eine gute Möglichkeit. rbx schrieb: > Da ich aber auf Windows 8 stehen geblieben bin, weiß ich nicht, was bei > den neuesten Windowsversionen los ist. WinUSB geht ab Win10 besser, und Win10 lädt (man glaubt es kaum) USB-Klassentreiber direkt anhand der im Deskriptor angegebenen Klasse. D.h. man braucht keine .inf Datei (plus signierte .cat-Datei) mehr für jede einzelne USB-Maus welche Windows anweist den HID-Treiber zu laden, sondern Windows erkennt direkt dass es eine Maus ist und lädt den Treiber (so wie alle anderen OSe das schon immer machen).
Niklas G. schrieb: > Dank WinUSB kann man auf USB-Geräte ohne eigenen Treiber zugreifen, und > sollte es jemals einen Sprung auf 128bit-CPUs geben könnte das sogar > immer noch funktionieren. Microsoft muss da nur ein relativ "normales" > Windows-API für pflegen. Das wäre für Dongles, Programmiergeräte & Co > eine gute Möglichkeit. Naja, diese Programmiersoftware will halt unbedingt auch immer ein Teil der benutzer auf Linux lauffähig haben, da nimmt man dann LibUSB für das gleiche API. Aber da fängt der Spaß schon an. Man muss die richtige Version haben, die Signatur muss passen, und falls da vorher schon ein Treiber vom Hersteller dran war, muss der erst brachial mit Zadig oder sonstwas da abgebogen werden. WinUSB ist in der Tat ein Segen. Wir nutzen den seit Windows XP für unsere Geräte. Wir mussten bisher noch kein einziges Mal das API anpassen. Dazwischen kamen alle neuen Windows Versionen bis Windows 11, der Umstieg auf 64 Bit und unsererseits der Umstieg vom Cypress FX2 auf den FX3. Selbst für USB 3 Super Speed war keine einzige Änderung an der User Software nötig. Der Treiber ist mega stabil, wird von Windows gepflegt und mittlerweile kann man den sogar ohne inf laden, wenn man entsprechende Deskriptoren benutzt. Wir nutzen allerdings ein inf mit signiertem cat File, weil wir noch die schönen Bildchen mit ausliefern und eine eigene Gruppe im Gerätemanager wollen. Die Signatur ist eh da für die Anwender-Software. Also gerade den WinUSB als Beispiel für fragil zu nehmen zeugt von Unkenntnis. Da hat wohl einer noch nicht mit TI Debuggern gearbeitet und sich an deren selbst zusammen gestümperten Treibern erfreut....
Christian R. schrieb: > Man muss die richtige > Version haben, die Signatur muss passen, Entfällt wenn das Gerät als WinUSB Device mittels OS Deskriptor markiert ist. Dann lädt Windows einfach den aktuellen Treiber, und signiert ist der sowieso. Christian R. schrieb: > und falls da vorher schon ein > Treiber vom Hersteller dran war, muss der erst brachial mit Zadig oder > sonstwas da abgebogen werden. Ja, das Vorgehen ist sinnvoller wenn der Hersteller sowieso WinUSB vorsieht und keinen eigenen Treiber ausliefert. Christian R. schrieb: > Wir mussten bisher noch kein einziges Mal das API > anpassen. Cool danke, gut zu wissen. Christian R. schrieb: > Wir nutzen allerdings ein inf mit > signiertem cat File, weil wir noch die schönen Bildchen mit ausliefern Win10 liest immerhin den Product String Deskriptor aus und zeigt den Namen korrekt an, aber kein eigenes Bildchen und die Gruppe im Geräte-Manager ist generisch. Geschmackssache, ob das reicht
Niklas G. schrieb: > Ja, das Vorgehen ist sinnvoller wenn der Hersteller sowieso WinUSB > vorsieht und keinen eigenen Treiber ausliefert. Geht halt nicht für jedes Device und unter Linux muss man dann eine Zwischenschicht haben, die zu LibUSB vermittelt. Ich treffe LibUSB eigentlich nur bei solchem Zeug an, was unbedingt auch mit dem selben Quellcode unter Linux laufen muss.
Man kann "Spielen". Ich habe einen Mustek DIA-Scanner vom Flohmarkt (5 Euro) und lt. Aufkleber "nur für win-98". Ich habe den Treiber genommen, etwas getrickst und das Teil läuft unter Win-7 immer noch. Der wichtigste "Trick" war, das man den CODE von Win-7 in die Inf-Datei schreibt. Vorher macht man ein Backup, und dann installieren. Nach meiner Erfahrung laufen dann immer noch 80-90% aller Geräte weiter,sofern das OS die richtigen BITS (32 o. 64) kann und die richtige CPU-Gruppe hat. Ausnahme ist, wenn der Hersteller sein Treiber "brutal" ins System gequetscht hat, und sich nicht an 'Gängige Regeln' gehalten hat. Wobei ich die Feststellung gemacht habe, das China-Teile gerne mal das mit den Regeln nicht so eng nehmen. Musste man ein Treiber für ein Motorrad-Auslese-Software installieren. Der wollte ein super-Speziellen Ch-340 Treiber haben oder da lief NIX.
Christian R. schrieb: > und unter Linux muss man dann eine > Zwischenschicht haben, die zu LibUSB vermittelt. Wieso das? LibUSB kann unter Linux im Prinzip auf alle USB-Geräte direkt zugreifen, solange kein Kernel-Treiber aktiv ist; ob man unter Windows per WinUSB zugreift ist doch egal. Christian R. schrieb: > Ich treffe LibUSB > eigentlich nur bei solchem Zeug an, was unbedingt auch mit dem selben > Quellcode unter Linux laufen muss. Naja, einer proprietären Windows-Anwendung sieht man es kaum an, ob sie intern libusb für den Zugriff auf WinUSB nutzt oder ob sie es direkt macht. Bei proprietären Anwendungen wird irgendwo eine libusb-0.1.dll rumliegen (wenn die LGPL nicht geflissentlich ignoriert wurde), ansonsten kann es sogar statisch gelinkt sein.
:
Bearbeitet durch User
Gerhard O. schrieb: > Was ist daran für MS so schwer zu verstehen? Denke mal dran, daß der eigentlich vorgesehene Weg für USB-Geräte etwa so aussieht: a) Hersteller kauft sich ne vid und ne pid b) Hersteller baut seine USB-Geräte c) Hersteller verkauft seine USB-Geräte zusammen mit einem Bündel aus Treibern und Installations_Dateien Sowas bedeutet im Prinzip, daß der OS-Hersteller lediglich Festlegungen zum Interface bereitstellt und die eigentliche Arbeit bei den diversen Herstellern liegt. So wie ich das sehe, ist es eher eine Verständnis-Schwierigkeit zwischen MS und dem jeweiligen Hersteller darüber, wie manche Angaben in den gegebenen Festlegungen zu verstehen sind und was das korrekte Verhalten des Treibers - im Gegensatz zum tolerierten Verhalten - denn ist. Ich habe da meine eigenen Erfahrungen, allerdings auf der Geräteseite. Ich hatte mich vor Jahren mal daran gemacht, einen Treiber für den vorhandenen µC, anfangs für einen von Nuvoton, zu schreiben, um einen Ersatz für den am PC mittlerweile ausgestorbenen COM-Port zu haben. Das war ein Krampf, denn gut verständliche Dokumente gab es nicht (oder gibt es nur gegen Geld) und selbst die Dokumentation des im µC eingebauten USB-Peripheriecores ist zumeist eine Schwierigkeit. Bei den LPC von NXP war mir es sogar passiert, daß es partout nicht gehen wollte und als ich den Herrn Meeser von NXP daraufhin ansprach, kam dem zuerst das Lachen, denn im Referenzmanual zum Chip waren zwei Kommandos schlichtweg vertauscht. Aber das war vor der Cortex-Zeit und man hatte bei NXP keine Zeit oder Lust mehr, für den ARM7TDMI die Dokumentation zu berichtigen. Fazit: viele Dinge sind rein technisch zwar richtig konstruiert, aber es gab und gibt immerzu Fehler im Verstehen oder der Dokumentation, die dann dazu führen, daß man gezwungen ist, an der Software so lange herumzuprobieren, bis es läuft - und wenn man dann zwar nicht das wirklich korrekte Verhalten programmiert hat und es nur ein toleriertes Verhalten ist, dann mag es bei der nächsten OS-Version eben die Probleme geben, über die du dich beschwerst. Und das sollte man nicht bei MS festmachen. Solche Stolpersteine gibt es überall. Ich geb dir mal ein Beispiel: Zu der Zeit, wo man bei ARM-Controllern noch pingelig unterscheiden mußte zwischen Arm- und Thumb-Code mußte für die Übergänge bei Aufrufen noch etwas Zwischencode eingebaut werden. Wenn man nun den GCC benutzt und Funktionen in Thumb-Code in Assembler schreibt, dann reichte es nicht, im Assembler mit ".thumb" den Code festzulegen, denn der GCC Kram exportierte die Funktionsadressen als "Arm" und nicht als "Thumb". Folglich baute der Linker besagten Zwischencode ein, was bei Aufrufen von Thumb-Funktionen von Thumb-Aufrufern völlig überflüssig ist und zum Absturz führt. Das war den GCC-Leuten schon lange bekannt, aber anstatt das Fehlverhalten zu berichtigen, wurde ein ".thumbfunc" eingeführt, um besagte Funktionsadressen manuell als Thumb zu kennzeichnen. Kurzum: es wird überall und zu allen Zeiten gepfuscht - freiwillig oder unfreiwillig. Offenbar muß man damit leben. W.S.
Also tatsächlich schafft es Microsoft immer mal wieder die Systemtreiber zu versauen. Mit einer bestimmten Release von Windows 10 gibt es immer wieder Probleme, dass Dinge wie normale HID-Geräte nicht erkannt werden, obwohl sie mit den Versionen davor und danach und mit anderen Betriebssystemen einwandfrei laufen.
W.S. schrieb: > [...] und als ich > den Herrn Meeser von NXP daraufhin ansprach, kam dem zuerst das Lachen, Wenn man die Wahl hat, ob man Herrn Meeser oder irgendeinem Datenblatt glaubt, liegt ersterer eigentlich grundsätzlich immer richtig.
W.S. schrieb: > Das > war den GCC-Leuten schon lange bekannt, aber anstatt das Fehlverhalten Das ist kein Fehlverhalten. Du hast die "Funktionen" halt einfach nicht als Funktion deklariert, und Nicht-Funktions-Labels bekommen kein Instruction State bit. > zu berichtigen, wurde ein ".thumbfunc" eingeführt, um besagte > Funktionsadressen manuell als Thumb zu kennzeichnen. Das ist lediglich ein Shortcut für ".thumb" + ".type MeineFunktion, %function". Sowohl vorher als auch jetzt gilt: Funktionen müssen als Funktion gekennzeichnet werden, damit der Linker sie korrekt aufruft. Das geht nach wie vor per ".type MeineFunktion, %function". Das ".thumb_func" ist nur eine Abkürzung. Nur weil du deinen Code nicht dementsprechend korrigierst, ist das noch lange kein Binutils-Fehlverhalten (GCC hat damit nichts zu tun). Allerdings beweist es deinen Punkt: Wenn man sich weigert, das Interface einer Software (hier: GNU Assembler) zu verstehen und stattdessen über "Fehlverhalten" herzieht, gibt es Probleme...
:
Bearbeitet durch User
Niklas G. schrieb: > W.S. schrieb: >> Das >> war den GCC-Leuten schon lange bekannt, aber anstatt das Fehlverhalten > > Das ist kein Fehlverhalten. Du hast die "Funktionen" halt einfach nicht > als Funktion deklariert, und Nicht-Funktions-Labels bekommen kein > Instruction State bit. Na klar, man schreibt dediziert, daß man Code im Thumb Modus erzeugen will, aber das heißt für den GCC noch lange nicht, daß ein Thumb-Maschinencode auch wirklich Thumb ist und als solcher angesprungen sein will, sodaß man das noch extra dazuschreiben muß. Völlig klar sowas. Im Klartext: das war und ist ein fetter Bug, aber anstatt selbigen zu beseitigen, läßt man sich ne Ausrede einfallen, erklärt den Rest der Welt für deppert und erfindet einen Workaround. W.S.
W.S. schrieb: > Im Klartext: das war und ist ein fetter Bug Behauptet der, der nichtmal GCC vom GNU Assembler (Teil von Binutils, nicht von GCC) unterscheiden kann. W.S. schrieb: > aber das heißt für den GCC noch lange nicht, daß ein Thumb-Maschinencode > auch wirklich Thumb ist und als solcher angesprungen sein will Falsch. Es heißt nur, dass das Label keine Funktion ist! Weil Labels eben auch für etwas anderes sein können, z.B. Daten. Und bei Daten macht das Instruction Set Bit nicht besonders viel Sinn. Warum sonst funktioniert es eben auch ohne ".thumb_func", sondern auch mit ".type xx, %function" wenn zuvor einmal ".thumb" steht?! W.S. schrieb: > und erfindet einen Workaround. Das ".type" existiert auch für andere Architekturen und Dateiformate, ist also Standard-Syntax vom GAS ist und nicht Thumb-Spezifisch. Wie kann etwas ein Workaround für das Thumb-Problem sein, was es im GNU-Assembler schon gab bevor Thumb überhaupt existierte (vor 1994), geschweige denn vom GAS unterstützt wurde, und nichtmal ARM-spezifisch ist? Bei ARM manifestiert sich das Fehlen von ".type" lediglich besonders unangenehm. Genau so steht es auch in der Doku. Eine Software, die sich genau so wie intendiert und wie dokumentiert verhält - klar, muss ein Bug sein.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.