Wie oft habe ich mich schon mit diesem blöden WOW64-Hive herumgeschlagen!
Der gibt nur Ärger.
Jetzt schon wieder.
Das 32-bit-Setup legt die Registry-Schlüssel unter WOW64 an, und die 64-bit-Anwendung sucht die Schlüssel aber im normalen Zweig.
So ein Sch..ß!
Ich muss einen Workaround finden.
breakpoint 
Ja, ätzend nicht ?!
LikeLike
Ja, ist es.
Und selbst wenn man weiß, wie man damit umzugehen hat, kostet es Zeit und Nerven.
LikeLike
Man sollte den Programmierer persönlich für sowas verantwortlich machen können.
LikeLike
Den Programmierer bei Microsoft?
Der setzt doch nur die Architektur um, wie sie in der Spezifikation festgesetzt wurde.
Die Architekten hatten bestimmt ihre Gründe, den WOW64-Hive einzuführen. Schließlich hätten sie auch 32-bit-Binaries gar nicht mehr unterstützen können.
Aber für Anwendungsentwickler liefert das halt immer wieder Probleme (nicht die einzigen ;D).
LikeLike
Nuja, als 32-bit-System kann der Installer halt nur die simulierte 32-bit Registry sehen, alles andere hätte wohl zu viele Programme „verwirrt“.
Insofern: die Ursache ist nur begrenzt bei Microsoft, eher beim nicht angepassten Installer, zu suchen.
LikeLike
Richtig genial sind auch Programme, die 2008 ausgeliefert wurden mit 16-bit Installer. „Den hab‘ ich anno ’92 teuer gekauft und das tut’s doch noch“. Außer natürlich auf einem 64-bittigen Windows. Aber dafür kann der Hersteller nun teuer Updates verkaufen.
LikeLike
Das Problem taucht so oder ähnlich halt immer wieder auf, wenn sowohl 32- als auch 64-bit-Anwendungen beteiligt sind.
Wer jetzt die „Schuld“ trägt, ist erst einmal zweitrangig – Hauptsache, man kriegt’s zum Laufen.
Ich hab auch irgendwo noch ein paar 16-bittige Programme.
Wenn ich mal eines davon laufen lassen will, mach ich das halt auf einer 32-bit-VM.
LikeLike
Pingback: breakpoint’s Wayback Archive #21 //1783 | breakpoint