Falsche DLL in SysWOW64 #559
Etiquetas
Sin etiquetas
(╯°□°)╯︵ ┻━┻
Bug
Diskussion
Dokumentation
Duplikat
Gitea
Hardware
Hilfe
Invalid
Java
Lernen
Qt
Remote
Subversion
Tablet
Tastaturbelegung
Test
Treiber/Android
Treiber/iOS
Treiber/Linux/Konsole
Treiber/Linux/xkbmap
Treiber/Linux/xmodmap
Treiber/MacOS
Treiber/Windows/AHK
Treiber/Windows/kbdneo
Treiber/Windows/ReNeo
Verbesserung
Website
Windows 11
Wontfix
Worksforme
Sin Milestone
No asignados
2 participantes
Notificaciones
Fecha de vencimiento
Sin fecha de vencimiento.
Dependencias
No se han establecido dependencias.
Referencia: neo/neo-layout#559
Cargando…
Referencia en una nueva incidencia
No se ha proporcionado una descripción.
Eliminar rama "%!s(<nil>) "
Eliminar una rama es permanente. Aunque la rama eliminada puede continuar existiendo durante un corto tiempo antes de que sea eliminada, en la mayoría de los casos NO PUEDE deshacerse. ¿Continuar?
Auf 64-Bit Windows gibt es zwei Verzeichnisse für DLLs:
Aber Vorsicht: WOW64 ist nicht identisch zu echtem 32-Bit-Windows!
Und da liegt das Problem. Der aktuelle Download enthält in SysWOW64 eine DLL für echtes 32-Bit-Windows statt für WOW64. Ich habe die Datei mit der Datei aus dem 32-Bit-Download verglichen und sie waren identisch.
Wie äußert sich das? Windows selbst scheint sich daran bislang nicht gestört zu haben. (Vielleicht wird die WOW64-DLL in aktuellen Windows-Versionen nicht mehr ausgewertet?)
Es ist aber ein Problem für Programme, die die DLL manuell lesen wollen. Dieser Anwendungsfall ist vielleicht eher ungewöhnlich, aber er kommt vor. Ich arbeite gerade an so etwas für GTK 3. Dabei ist mir heute beim Testen aufgefallen, dass der Code im 32-Bit-Modus auf meinem frisch installierten Windows 10 64-Bit crasht, obwohl er vorher funktionierte. Dachte zuerst natürlich, dass es an meinem Code läge, aber es passierte nur mit Neo. Habe dann die DLL aus meinem alten Windows 7 kopiert und siehe da: Kein Crash mehr.
Leider kann ich da nicht wirklich etwas machen. Der Fehler muss in Neo selbst behoben werden.
Ich gebe zu, ich kenne mich mit den Feinheiten bez. 32/64-Bit-DLLs nicht aus. Diese Unterscheidung war für mich bisher nur bei Anwendungsprogrammen von Bedeutung. Mangels anderer Informationen ging ich bisher davon aus, dass für WOW64 eben eine 32-Bit-Version verwendet wird – die Dateien sind nicht zufällig identisch, sondern wurden genau so kompiliert und kopiert.
Das Buildprojekt liegt offen – wenn Du mehr weißt und Hinweise darauf geben kannst, welche Einstellungen in Visual Studio (bzw. manuell für den Compiler/Linker) notwendig sind, um kombiniert eine 64-Bit- und eine WOW64-Version zu generieren, immer her damit.
Die alte Win7-Version funktioniert, weil sie mit dem früheren Windows DDK erzeugt wurde. Das neue DDK ist im Vergleich dazu ein riesiges Ungetüm, und die Beispiele, die genau dieses hier bauen sollen (mit dem Code für den deutschen Tastaturtreiber), sind kaputt und erzeugen nicht-lauffähige DLLs. Daher musste ich mich selbst an die Einstellungen herantasten, um funktionale und ähnlich kleine DLLs zu generieren.
Die WOW64-Problematik hatte ich wie gesagt nicht als solche erkannt, sondern einfach nur zweimal durchkompilieren lassen: für 32 und für 64 Bit.
War für mich auch neu. Bei Anwendungen und normalen DLLs gibt es diesen Unterschied ja auch nicht.
Ich habe mit dem DDK noch nie gearbeitet und NEO noch nie selbst kompiliert, daher kann ich dazu auch nicht viel sagen. Es sieht aber so aus, als ob
BUILD_WOW6432
definiert sein muss, um einen WOW64-Treiber zu bauen (vgl. kbd.h). Ob das alleine reicht, weiß ich nicht.Scheint auszureichen. Siehe Pull Request.
Die Commits sehen gut aus und bauen irgendwas. Ich teste noch kurz unter Windows 10, dass alles wie erwartet läuft und aktualisiere dann die Downloads.
Die x64-Downloads hab ich aktualisiert, da stecken nun die x64- und x86-wow-Versionen drin.
Danke nochmal für die Mühe und den Bugfix.
Vielen Dank!