TC7.50rc1 unter Windows 7 x64
Moderators: Hacker, Stefan2, white
-
- Junior Member
- Posts: 15
- Joined: 2008-04-05, 17:36 UTC
TC7.50rc1 unter Windows 7 x64
Ich habe jetzt nicht alle Threads gelesen, aber beim Überfliegen habe ich nichts zu dem Thema gefunden, daher ein kleiner "Problembericht" von mir zu den Dinge die unter Vista x64 gingen, unter 7 x64 jedoch nicht mehr bzw. nur noch eingeschränkt:
Es betrifft den Total Commander 7.50 (b8 und rc1) unter einem 64Bit Windows 7 Ultimate. (aktuelle Version aus dem TechNet Plus Abo, also RTM).
Viele Befehle des Kontextmenüs funktionieren im Total Commander unter Windows 7 x64 nicht mehr. Bei den Punkten "Eigenschaften", "Löschen", "Kopieren", "Ausschneiden" und "Einfügen" ist es mir aufgefallen. Im X64-Untermenü klappt "Eigenschaften" hingegen, weswegen ich vermute, dass Microsoft die 32Bit Shell unter Windows 7 irgendwie beschnitten hat.
Die Tastenkombinationen <CTRL>+<C> und <CTRL>+<V> zum Kopieren/Einfügen von Dateien funktionieren ebenfalls nicht mehr.
Löschen <F8> in den Papierkorb klappt nur noch mit erhöhten Rechten, nicht mehr als normaler Benutzer. Direktes Löschen <SHIFT>+<F8> klappt hingegen auch ohne UAC-Abfrage.
Es betrifft den Total Commander 7.50 (b8 und rc1) unter einem 64Bit Windows 7 Ultimate. (aktuelle Version aus dem TechNet Plus Abo, also RTM).
Viele Befehle des Kontextmenüs funktionieren im Total Commander unter Windows 7 x64 nicht mehr. Bei den Punkten "Eigenschaften", "Löschen", "Kopieren", "Ausschneiden" und "Einfügen" ist es mir aufgefallen. Im X64-Untermenü klappt "Eigenschaften" hingegen, weswegen ich vermute, dass Microsoft die 32Bit Shell unter Windows 7 irgendwie beschnitten hat.
Die Tastenkombinationen <CTRL>+<C> und <CTRL>+<V> zum Kopieren/Einfügen von Dateien funktionieren ebenfalls nicht mehr.
Löschen <F8> in den Papierkorb klappt nur noch mit erhöhten Rechten, nicht mehr als normaler Benutzer. Direktes Löschen <SHIFT>+<F8> klappt hingegen auch ohne UAC-Abfrage.
-
- Power Member
- Posts: 556
- Joined: 2006-04-01, 00:11 UTC
-
- Junior Member
- Posts: 15
- Joined: 2008-04-05, 17:36 UTC
Oh, böse Falle. Danke für den Hinweis.
Ich hatte x64DisableRedirection auf 1 stehen und genau das hat die Probleme verursacht. Unter Vista hatte ich das noch nicht aktiviert. Es hat also nichts mit Windows 7 zu tun, sondern nur mit "x64DisableRedirection".
Wenn x64DisableRedirection nicht definiert oder auf 0 gesetzt ist, treten diese Probleme auch unter Windows 7 nicht auf.
Sorry, daran hatte ich nicht mehr gedacht.
Ich hatte x64DisableRedirection auf 1 stehen und genau das hat die Probleme verursacht. Unter Vista hatte ich das noch nicht aktiviert. Es hat also nichts mit Windows 7 zu tun, sondern nur mit "x64DisableRedirection".
Wenn x64DisableRedirection nicht definiert oder auf 0 gesetzt ist, treten diese Probleme auch unter Windows 7 nicht auf.
Sorry, daran hatte ich nicht mehr gedacht.
-
- Power Member
- Posts: 556
- Joined: 2006-04-01, 00:11 UTC
-
- Junior Member
- Posts: 15
- Joined: 2008-04-05, 17:36 UTC
x64DisableRedirection ist ein experimenteller Workaround, der eigentlich nur für XP(x64) benötigt wird.
Ab Vista gibt es die Möglichkeit über Sysnative das 64Bit-System32 Verzeichnis zu erreichen (in 90% der Fälle reicht das allemal aus).
Siehe auch MSDN: FileSystem redirector)
Selbst unter XP(x64) ist es die besser, die Redirection mittels eines Buttons: nur bei Bedarf auszuschalten.
Ansonsten kann es immer wieder passieren, dass Aufrufe von Systemfunktionen oder Shellerweiterungen fehlschlagen, weil innerhalb der aufgerufen Funktionen versucht wird eine 32Bit-DLL nachzuladen.
Das schlägt dann fehl, da die 32bit Version der DLL nicht im 64Bit-System32 gefunden werden kann, und natürlich nichts von SysWow64 weiss.
Den ganze Wirrwarr:
System32 ist entweder System32(x64) oder SysWow64
- je nachdem ob man von einem 64Bit Prozess oder 32bit Prozess darauf schaut;
- oder man wagt etwa über einen AdminShare einen Blick auf das Systemlaufwerk;
- mit oder ohne File-system-redirection;
- wehe man übergibt eine Systempfad von einer 32Bit an eine 64Bit Applikation weiter, ohne den momentanen Status der Redirection zu berücksichtigen;
-..
hätte sich MS einfach dadurch sparen können, indem sie das native Systemverzeichnis System64 genannt hätten.
Aber irgendjemand bei MS hat sich überlegt, dass man dann bei einigen hardkodierten Programmquelltexten nicht nur einfach einen Schalter x86/x64 umlegen, sondern den Quelltext für einen sauberen Neuanfang überarbeiten müsste.
Nun gut, dann müssen eben Programmier und Anwender die nächsten 25 Jahre mit diesem Unfug leben.
Danach gibt es dann anstelle von System128 bestimmt wieder die nächste Fehlentscheidung wie z.B Sysnative128 und SysWow128.
Gruß
Holger
Ab Vista gibt es die Möglichkeit über Sysnative das 64Bit-System32 Verzeichnis zu erreichen (in 90% der Fälle reicht das allemal aus).
Siehe auch MSDN: FileSystem redirector)
Selbst unter XP(x64) ist es die besser, die Redirection mittels eines Buttons:
Code: Select all
TOTALCMD#BAR#DATA
cm_SwitchX64Redirection
WCMICONS.DLL
0
2925
Ansonsten kann es immer wieder passieren, dass Aufrufe von Systemfunktionen oder Shellerweiterungen fehlschlagen, weil innerhalb der aufgerufen Funktionen versucht wird eine 32Bit-DLL nachzuladen.
Das schlägt dann fehl, da die 32bit Version der DLL nicht im 64Bit-System32 gefunden werden kann, und natürlich nichts von SysWow64 weiss.
Den ganze Wirrwarr:
System32 ist entweder System32(x64) oder SysWow64
- je nachdem ob man von einem 64Bit Prozess oder 32bit Prozess darauf schaut;
- oder man wagt etwa über einen AdminShare einen Blick auf das Systemlaufwerk;
- mit oder ohne File-system-redirection;
- wehe man übergibt eine Systempfad von einer 32Bit an eine 64Bit Applikation weiter, ohne den momentanen Status der Redirection zu berücksichtigen;
-..
hätte sich MS einfach dadurch sparen können, indem sie das native Systemverzeichnis System64 genannt hätten.
Aber irgendjemand bei MS hat sich überlegt, dass man dann bei einigen hardkodierten Programmquelltexten nicht nur einfach einen Schalter x86/x64 umlegen, sondern den Quelltext für einen sauberen Neuanfang überarbeiten müsste.

Nun gut, dann müssen eben Programmier und Anwender die nächsten 25 Jahre mit diesem Unfug leben.
Danach gibt es dann anstelle von System128 bestimmt wieder die nächste Fehlentscheidung wie z.B Sysnative128 und SysWow128.

Gruß
Holger
Danke dir für die ausführliche Antwort.
Im Grunde genommen wusste ich das schon, nur habe ich die Zusammenhänge bzgl. der Dialoge nicht erkannt.
Danke nochmal!
Aber man, das ist echt zum Heulen!
Man sollte Microsoft für diese 'Strategie' steinigen.
Wobei du noch das "Program Files" Dilemma außer Acht gelassen hast.
"Program Files (x86)" ist laut MS für 32bit Programme.
Aha. Dabei entspricht ein 64bit Prozessor ja auch der x86-Architektur, nur dass er eine Befehlssatz-Erweiterung hat.
Ich bin ja eigentlich ein MS Anhänger, liebe das .NET-Framework, und nehme MS immer in Schutz vor 'bösen MAC- und Unix-Jüngern', aber im Moment frage ich mich nur, welches kranke Hirn dafür verantwortlich zeichnet.
Das war eine rein marketingtechnische Entscheidung, weil sie mit dem von dir aufgezeigten sauberen technischen Umbruch deutlich mehr Probleme mit Anwendungen gehabt hätten (in der Anfangszeit).
Vielleicht machen sie es in 5-10Jahren mit 128bit besser.
Gruß,
Axel

Im Grunde genommen wusste ich das schon, nur habe ich die Zusammenhänge bzgl. der Dialoge nicht erkannt.
Danke nochmal!
Aber man, das ist echt zum Heulen!
Man sollte Microsoft für diese 'Strategie' steinigen.
Wobei du noch das "Program Files" Dilemma außer Acht gelassen hast.
"Program Files (x86)" ist laut MS für 32bit Programme.
Aha. Dabei entspricht ein 64bit Prozessor ja auch der x86-Architektur, nur dass er eine Befehlssatz-Erweiterung hat.
Ich bin ja eigentlich ein MS Anhänger, liebe das .NET-Framework, und nehme MS immer in Schutz vor 'bösen MAC- und Unix-Jüngern', aber im Moment frage ich mich nur, welches kranke Hirn dafür verantwortlich zeichnet.

Das war eine rein marketingtechnische Entscheidung, weil sie mit dem von dir aufgezeigten sauberen technischen Umbruch deutlich mehr Probleme mit Anwendungen gehabt hätten (in der Anfangszeit).
Vielleicht machen sie es in 5-10Jahren mit 128bit besser.

Gruß,
Axel
Man sollte Microsoft für diese 'Strategie' steinigen.
Ist lustig oder? Die Leute sind zurecht frustriert von den microsoftschen Machenschaften, aber sich abwenden? Och nö.ch bin ja eigentlich ein MS Anhänger, liebe das .NET-Framework, und nehme MS immer in Schutz vor 'bösen MAC- und Unix-Jüngern', aber im Moment frage ich mich nur, welches kranke Hirn dafür verantwortlich zeichnet.
Man hat den Eindruck Microsoft und die Benutzer sind ein altes Ehepaar, das nur noch aus alter Gewohnheit zusammen bleibt. Ob es jemals Liebe war, sei dahingestellt.
Ich nehme mich da übrigens auch nicht aus. Allerdings gehe in letzter Zeit auch öfter mal fremd.
Nun ja, da spielen natürlich auch berufliche Aspekte eine große Rolle.
Die Kunden bestimmen das Umfeld für uns/mich.
Ich bin 'gefangen' in der Microsoft-Welt, aber ich fühle mich deswegen nicht unwohl. Mir macht es immer noch Spaß.
Aber du hast Recht:
Hätte ich solch eine dominante, alte, engstirnige Dame in meinen eigenen vier Wänden, würde ich über 'ne Scheidung durchaus nachdenken.
Die Kunden bestimmen das Umfeld für uns/mich.
Ich bin 'gefangen' in der Microsoft-Welt, aber ich fühle mich deswegen nicht unwohl. Mir macht es immer noch Spaß.
Aber du hast Recht:
Hätte ich solch eine dominante, alte, engstirnige Dame in meinen eigenen vier Wänden, würde ich über 'ne Scheidung durchaus nachdenken.

Darüber sollte man mal nachdenken:
http://movies.apple.com/media/us/mac/getamac/2009/apple-mvp-broken_promises-us-20091023_480x272.mov
http://movies.apple.com/media/us/mac/getamac/2009/apple-mvp-broken_promises-us-20091023_480x272.mov
- dumbledore954
- Senior Member
- Posts: 373
- Joined: 2006-11-27, 08:10 UTC
- Location: Hessisch Sibirien (Germany)
Absolut cooles Video! Da sieht man mal wieder, dass Apple es einfach drauf hat.Lefteous wrote:Darüber sollte man mal nachdenken:
http://movies.apple.com/media/us/mac/getamac/2009/apple-mvp-broken_promises-us-20091023_480x272.mov
Aber wie Axel schon geschrieben hat:
So geht es mir leider auch.Ich bin 'gefangen' in der Microsoft-Welt, aber ich fühle mich deswegen nicht unwohl. Mir macht es immer noch Spaß.
Gruß Michael
WinXPPro SP3, TC 7.56a
#7640 Personal licence
WinXPPro SP3, TC 7.56a
#7640 Personal licence