Ab sofort könnt ihr euch die finale Version von SpeedCommander 13.30 herunterladen. Auf Vorschlag von widestone habe ich die Beschriftung für die Ordnerfenster auf den Registerkarten noch einmal erweitert. Nun können neben dem Laufwerksbuchstaben und dem Ordnernamen auch noch beide in Kombination angezeigt werden. Die entsprechende Option befindet sich im Einstellungsdialog auf der Seite Verhalten – Registerkarten. Die anderen Neuerungen hatte ich ja schon beim Erscheinen der Betaversion beschrieben.

SpeedCommander 13.20 wurde veröffentlicht und kann heruntergeladen werden. Die Liste mit den Änderungen findet ihr wie üblich im Anwenderforum.

Über zwei neue Funktionen hatte ich bereits berichtet. Mit der Einstellung

[FileOperation]
;Verschieben, wenn Quell- und Zielname identisch sind
;0 - Fehlermeldung
;1 - Datei wird umbenannt von 'dateiname.ext' nach 'dateiname [1].ext'
MoveOnSameName=0

kann das Verhalten beim Verschieben von Dateien im gleichen Ordner gesteuert werden. Bis zur Version 12 hat SpeedCommander beim Ausschneiden und Einfügen einer Datei im gleichen Ordner diese zu ‘dateiname [1].ext’ umbenannt. Mit SpeedCommander 13 wurde dieses unter Umständen nicht ganz saubere Verhalten abgestellt und stattdessen eine Fehlermeldung angezeigt. Mit diesem Kompatibilitätsschalter kann das alte Verhalten wieder reaktiviert werden.

Das Öffnen von Dateien beim Doppelklick erfolgt ab dieser Version wieder mit der Windows-Funktion ShellExecuteEx. Beim Verwenden der Kontextmenü-Funktionen (neu ab SpeedCommander 13) scheint es leider das eine oder andere kleine Problem zu geben.

Im Anwenderforum könnt ihr euch die erste Beta von SpeedCommander 13.20 herunterladen. Eine sichtbare Änderung ist die veränderte Darstellung des fokussierten Eintrags unter Windows 7. Dieser wird nicht mehr durch einen gepunkteten Rahmen gekennzeichnet sondern durch eine durchgehende Umrandung. So sollte der fokussierte Eintrag besser zu erkennen sein:

Die in der Version 13.10 eingeführte verzögerte Ermittlung des Vorschaubilds beim Überschreiben von Dateien hatte unerwünschte Nebenwirkungen. Dokumente von Office 2007 konnten teilweise nicht überschrieben werden, weil die Generierung des Vorschaubilds durch das jeweilige Programm die Dateien sperrte. Deshalb wird in der neuen Version das vorherige Verhalten wieder reaktiviert, es kann durch Einträge in der SpeedCommander.ini aber angepasst werden:

[FilePreviewWnd]
;Anzeige von Vorschaubildern in Bestätigungsdialogen für diverse Dateioperationen
;0 - Vorschaubilder werden nicht angezeigt
;1 - Vorschaubilder werden angezeigt
;2 - Vorschaubilder werden angezeigt (Ermittlung im Hintergrund, eventuelle Fehlermeldung beim Ersetzen von bestimmten Dateitypen)
EnablePreview=1

;Deaktivierung von Vorschaubildern für bestimmte Dateitypen (durch Semikolon getrennt)
ExcludeExtensions=ext1;ext2

Damit kann jeder Anwender das von ihm bevorzugte Verhalten einstellen.

Hier im Blog werden ja immer wieder neue Funktionen von SpeedCommander vorgestellt. Eine hatte ich im letzten Jahr ganz vergessen. Es handelt sich um die Kennzeichnung von Anwendungen, die mit erhöhten Rechten ausgeführt werden. Einige werden die Anzeige auch schon vom Vista/7-Explorer kennen.

Und so schaut es in SpeedCommander 13 aus:

Ab sofort könnt ihr die finale Version von SpeedCommander 13.10.6000 herunterladen. Nun sollten alle größeren Probleme beseitigt sein, die sich aufgrund der Neuprogrammierung wesentlicher Programmteile in der Version 13 eingeschlichen haben.

Mit dieser Version gibt es auch ein kleines Jubiläum zu feiern – 6000 Tage Selbständigkeit. Im September 1993 war es bei weitem nicht abzusehen, dass mich SpeedCommander einmal so lange begleiten würde. Kaffee und Kuchen stehen rechts auf dem Tisch, bedient euch.

Auf dem Weg zur finalen Version 13.10 könnt ihr euch jetzt die zweite Betaversion herunterladen. Neu ist das Ausblenden von leeren Wechseldatenträgern, zudem wurden weitere Fehler beseitigt.

Windows 7 bietet die Möglichkeit, im Arbeitsplatz Wechseldatenträger ohne eingelegte Medien auszublenden. Das verspricht insbesondere bei Kartenlesern mit mehreren Laufwerksbuchstaben Vorteile, da noch nur das Laufwerk mit der eingelegten Speicherkarte sichtbar ist und somit die Frage ‘Welcher Laufwerksbuchstabe war das gerade noch?’ entfällt.

Wer mag, kann diese Funktionalität nun auch in SpeedCommander 13.10 aktivieren:

Ich war mir nicht sicher, ob diese Funktion standardmäßig aktiviert werden sollte. Möglicherweise wundert sich der eine oder andere, warum seine Laufwerke plötzlich nicht mehr sichtbar sind. Daher erst einmal die manuelle Aktivierung. Was meint ihr?

Die neue Betaversion ist hauptsächlich ein Bugfix-Release und behebt die meisten Probleme, die mir seit dem Erscheinen der RTM-Version gemeldet wurden. Zudem werden Shellerweiterungen nun während der Laufzeit nicht mehr entladen. Ich bin mal gespannt, ob der eine oder andere unerklärliche Absturz damit behoben ist.

Neu ist eine Kompatibilitätsoption für das Ziehen und Ablegen mit der rechten Maustaste. Durch das Setzen von

[Drag&Drop]
ShellRightDrop=0

in der SpeedCommander.ini zeigt SpeedCommander das Menü selbst an und führt die Aktionen auch selbst aus, wie es bis SpeedCommander 12 der Fall war. Allerdings werden dabei im Menü keine Aktionen von Shellerweiterungen mehr angezeigt.

Mit der Option

[Accels]
ShowContextMenuAccelerators=1

werden Tastenkürzel auch in den Kontextmenüs angezeigt. Die finale Version ist für Februar geplant.

Ein Anwender hatte mir berichtet, dass SpeedCommander bei ihm nach einer gewissen Inaktivität im Hintergrund bei Aktivierung abstürzt. Der Absturzbericht zeigt dabei folgenden Callstack an:

user32.dll!UserCallWinProcCheckWow()
user32.dll!DispatchMessageWorker()
MxMfc90ud.dll!AfxInternalPumpMessage()
MxMfc90ud.dll!CWinThread::PumpMessage()
MxMfc90ud.dll!CWinThread::Run()

Diesem kann man entnehmen, dass der Absturz während der Verarbeitung einer Nachricht in der Funktion UserCallWinProcCheckWow der user32.dll auftrat. Die Ursache ist aber leider nicht ersichtlich. Kurze Zeit später schrieb mir der Anwender, dass er mit Hilfe von ShellExView den Kontextmenüeintrag von StExBar deaktiviert hat. Anschließend stürzte SpeedCommander nicht mehr ab. Nach der Installation von StExBar konnte ich das Problem nachstellen.

StExBar ist eine Erweiterung für den Explorer und stellt ein Kontextmenü sowie eine Symbolleiste zur Verfügung, in denen häufig verwendete Befehle abgelegt werden können. Der Vertrieb erfolgt unter der GPL, der Quellcode steht somit zur Verfügung. Ich habe mir also den Quellcode heruntergeladen und versucht, mit dem Debugger dem Problem auf den Grund zu gehen.

Meine Vermutung war, dass es etwas mit dem vorzeitigen Entladen der Dll zu tun hat. Dazu muss man wissen, dass eine MFC-Anwendung von Zeit zu Zeit nicht mehr benötigte Handles und temporäre Objekte freigibt. Dies geschieht, wenn die Anwendung Däumchen dreht und auf eine Eingabe des Anwenders wartet. Zu den Aufräumarbeiten gehört es auch, dass in bestimmten Zeitabständen durch Aufruf der Windows-Funktion CoFreeUnusedLibraries nicht mehr benötigte COM-Dlls entladen werden. Zu diesen COM-Dlls zählen auch die verschiedensten Shellerweiterungen.

Beim Entladen einer COM-Dll ruft Windows die von der Dll exportierte Funktion DllCanUnloadNow auf. Durch Rückgabe von S_OK stimmt die Dll einer Entladung zu, mit S_FALSE wird das Entladen verhindert. Nach Änderung des Rückgabewertes auf S_FALSE wurde StExBar nicht mehr entladen und der Absturz in SpeedCommander blieb aus.

Nun galt es, den Grund des Entladeproblems zu finden. StExBar erstellt bei der Initialisierung ein Fenster, in dem eine Symbolleiste und ein Eingabefeld platziert werden. Die Anzeige des Fensters erfolgt im Explorer durch den Aufruf der Schnittstelle IDockingWindow::ShowDW, mit IDockingWindow::CloseDW wird das Fenster wieder entfernt.

SpeedCommander ist allerdings nur an der Anzeige des Kontextmenüs interessiert und nicht an der zusätzlichen Symbolleiste. Das führt dazu, dass das Fenster während der Initialisierung erzeugt, bei der Freigabe des Kontextmenüs aber nicht geschlossen wird. Auch beim Entladen der Dll bleibt das Fenster weiter bestehen, was natürlich nicht beabsichtigt ist.

Bei der Aktivierung von SpeedCommander informiert das Hauptfenster alle untergeordneten Fenster. Dazu gehört auch das unsichtbare Fenster der zwischenzeitlich entladenen StExBar-Dll. Dummerweise ist der Speicherbereich, den die Fensterfunktion belegt hat, durch das Entladen ungültig geworden. UserCallWinProcCheckWow greift so auf einen undefinierten Bereich zu und es kommt zum Absturz. Den vorgeschlagenen Fix hat Stefan schon eingecheckt, vielen Dank dafür an dieser Stelle! Mit der nächsten Version von StExBar sollte das Problem dann nicht mehr auftreten.

Dieses Beispiel zeigt wieder einmal, dass die durch das Entladen von Shellerweiterungen verursachten Abstürze äußerst vielgestaltig und schwer zu ermitteln sind. Deshalb habe ich mich dazu entschlossen, die automatische Entladefunktion in der MFC durch eine Option in der SpeedCommander.ini abschaltbar zu machen. Nun bin ich am Überlegen, ob die Entladefunktion standardmäßig aktiviert (wie bisher) oder deaktiviert werden sollte. Für die Aktivierung spricht, dass nicht mehr benötigte COM-Dlls von Zeit zu Zeit entfernt werden und der Arbeitsspeicher etwas entlastet wird. Die Deaktivierung hat den Vorteil, dass möglicherweise der eine oder andere unerklärliche Absturz der Vergangenheit angehören könnte. Die Tendenz geht im Moment zur Deaktivierung, was meint ihr?

Vor knapp zwei Jahren hatte ich darüber berichtet, dass Carbonite Backup die Anzeige von Overlaysymbolen nur für bestimmte Anwendungen erlaubt. Auf meine Bitte, in die Liste der erlaubten Anwendungen aufgenommen zu werden, habe ich damals keine Antwort bekommen.

Ich weiß nicht, ob dieses Verhalten eine Spezialität von Onlinebackup-Lösungen ist. Mozy macht es jedenfalls genauso, Overlaysymbole werden nur in bestimmten Anwendungen angezeigt:

• explorer.exe
• dopus.exe
• conf.exe
• pifsdr.exe
• piimporter.exe
• verclsid.exe
• regsvr32.exe

Nenne ich SpeedCommander.exe zum Beispiel auf Explorer.exe oder dopus.exe um, dann zeigt auch SpeedCommander die Overlaysymbole. Das gleiche gilt auch für die Anzeige des Ordners MozyHome Remote Backup unterhalb von Computer. Die Auflistung dieses Ordners ist nur möglich, wenn die Anwendung einem der oben genannten Prozessnamen entspricht.

Die Intention einer Whitelist liegt wohl darin, möglichen Problemen bei der Zusammenarbeit mit anderen Anwendungen aus dem Weg zu gehen. Leider weiß der normale Anwender davon nichts und schiebt die Schuld immer auf die andere Anwendung, in diesem Fall auf SpeedCommander. Der Explorer zeigt die Symbole ja schließlich auch an.

Wie schon beim Carbonite-Fall habe ich auch an Mozy eine Anfrage geschickt. Ich bin gespannt auf die Antwort.