SpeedCommander 12

SpeedCommander 12.51 ist verfügbar und behebt nochmal ein paar kleinere Probleme:

• Beim Ausdrucken von Ordnerlisten wurden die Ordnernamen mit Präfix ausgedruckt
• Mögliche Verzögerung vor der Anzeige des Bestätigungsdialogs beim Löschen/Verschieben von schreibgeschützten Dateien
• Möglicher Absturz beim Import von SC8-Einstellungen
• Verschwinden des Ordnerinhalts im Ansichtsmodus ‚Liste‘, wenn Dateien aus dem linken Fenster langsam in Richtung QuickDrop-Symbole geschoben werden
• Keine Anzeige von Gruppen unter Windows XP x64 (fehlerhaftes Makro im Platform SDK)
• AV-Signatur von RAR-Archiven wurde nicht mehr angezeigt
• SQX: Möglicher Absturz beim Entpacken eines Archivs, wenn ein falsches Kennwort angegeben wurde
• SQX: Fehlermeldung beim Komprimieren von WAV-Dateien mit anschließendem erweiterten Test
• CAB: Absturz beim Entpacken eines defekten CAB-Archivs
• FileSearch: Möglicher Absturz, wenn FileSearch während einer Suche beendet wird
• SCBackup&Restore: Probleme beim Auflösen von Zielordnern, die auf gemappten Netzlaufwerken liegen (Vista SP2)

Aus einer eMail von einem Anwender:

Guten Tag,

heute habe ich zu schnell auf Update gedrueckt und mir leider nicht zuvor den Freischaltcode gesichert und nun habe ich Probleme…

Ich habe das Programm bei Ihnen gekauft und bin sehr zufrieden mit Ihrem Produkt.
Meine Seriennr. lautet: xxxxx-xxxxx-xxxxx-xxxxx-xxxx¹
Meine User Id.: irgendwas¹

Bitte senden Sie mir einen neuen Freischaltcode.
Danke im voraus.

Sollte ich zum Update nicht berechtigt sein, sagen Sie mir bitte wie ich zu meiner alten Version zurueck kehren kann.

Gruesse

Dr. Hans Liris¹

¹ Daten anonymisiert

Manche denken, dass „Kaufen“ ein Synonym von „Freischaltcode im Internet gefunden“ ist.

Ein Anwender hat mir geschrieben, dass beim Öffnen der integrierten Eingabeaufforderung in SpeedCommander mit Strg+O eine Warnung von Kaspersky angezeigt wird:

Ohne eine Umleitung der Dateneingabe bzw. Datenausgabe lässt sich eine solche Funktion leider nicht programmieren. Irgendwann kommt die Zeit, in der Fenster generell nur noch nach einer Sicherheitswarnung angezeigt werden. Wetten?

SpeedCommander 12.50 ist ab sofort verfügbar. Neu im Vergleich zur Betaversion ist die Möglichkeit, auch relative Ordnerfavoriten verwenden zu können. Wenn ein Ordnerfavorit einen relativen Pfadnamen für das aktive und/oder inaktive Fenster enthält, dann geht SpeedCommander davon aus, dass sich der Pfadname auf den aktuellen Ordner bezieht.

Für Squeez gibt es auch noch eine kleine Fehlerkorrektur. Durch die Umstellung auf die neuen Packerbibliotheken in SpeedCommander 12.40 kann es passieren, dass beim Überfahren eines Dateieintrags die InfoTip-Erweiterung von Squeez abstürzt. Mit der Version 5.63 sollte dies nicht mehr passieren.

Viele Neuerungen gibt es diesmal leider nicht, da der Großteil meiner Entwicklungszeit mittlerweile in den SpeedCommander 13 fließt. Von dort kommt auch eine Optimierung des Netzwerkzugriffs, die ich in den SpeedCommander 12 rückportiert habe.

Bisher hat SpeedCommander bei der Ermittlung eines Netzwerkpfades den Pfad immer rückwärts zusammengesetzt. Bei größeren Netzwerken hat das aber seine Zeit gedauert. Deshalb schaut SpeedCommander nun, ob der Server bereits in der obersten Ebene zu finden ist. Bei Erfolg wird dann auch nach der Freigabe geschaut. Andernfalls wird der Pfad wie bisher rückwärts zusammengesetzt.

Der Geschwindigkeitsgewinn macht sich bereits in meinem kleinen Netzwerk bemerkbar. Ansonsten gibt es wie üblich noch ein paar kleine Fehlerbehebungen. Den Download findet ihr wieder im Anwenderforum (Anmeldung erforderlich).

Es ist ja kein Geheimnis, dass es ab und zu mal Probleme mit Kontextmenü-Erweiterungen. Vor mehr als zwei Jahren habe ich über ein Problem mit der Erweiterung des Nero-Covereditors berichtet. Ihr werdet es nicht glauben, aber es gibt immer noch Anwender, die genau diese fehlerhafte Version noch heute einsetzen.

Derzeit bereiten mir aber zwei andere Kontextmenü-Erweiterungen Probleme. Genaugenommen geht es um den Freeware-Zipper jZip und um das Vergleichsprogramm SourceGear DiffMerge. Bei beiden ist es so, dass sie ein eigenes Untermenü in das Kontextmenü einfügen und SpeedCommander bei Anwahl dieses Menüs in Ehrfurcht erstarrt und den Prozessor schwitzen lässt. Lässt man SpeedCommander im Debugger laufen, dann wirft die MFC nur so mit ASSERTs um sich. Für die Nichtentwickler unter euch: Ein ASSERT ist eine Prüfung zur Laufzeit, die auf unerwartete Zustände hinweist (z.B. ungültige Funktionsparameter). Die Prüfungen werden aber nur in der Debug-Version ausgeführt, die Release-Version enthält keine ASSERTs.

In diesem Fall treten die ASSERTs bei der Verarbeitung der WM_INITMENUPOPUP-Nachricht auf. Windows verschickt diese Nachricht, wenn ein Menü oder Untermenü angezeigt werden soll. Die MFC nutzt diese Gelegenheit, um den Status von Menüelementen zu aktualisieren. Soll z.B. ein bestimmter Menübefehl als gewählte Option angezeigt werden, so lässt sich das hier bequem erledigen. Häufig wird die WM_INITMENUPOPUP-Nachricht auch verwendet, um Menüs vor der Anzeige mit aktuellen Daten zu füllen. SpeedCommander nutzt dies u.a. für die Zusammenstellung der Ordnerfavoriten, die bei jeder Anzeige aktuell in das jeweilige Menü eingetragen werden müssen.

Eigentlich sollte man davon ausgehen können, dass das bei WM_INITMENUPOPUP im ersten Parameter mitgelieferte Menühandle auch gültig ist. Die MFC geht jedenfalls davon aus, eventuelle Probleme werden dem Programmierer durch ASSERTs gemeldet. Ich wüsste auch nicht, was dagegensprechen sollte. In 17 Jahren Windows-Programmierung kam mir noch nie eine WM_INITMENUPOPUP für ein ungültiges Menü unter. Die MFC fragt in ihrer Routine nun die Anzahl der Menüeinträge ab und durchläuft diese nacheinander, um der Anwendung die Möglichkeit zu geben, den Status der Einträge gegebenenfalls anzupassen.

Dummerweise rechnet die MFC nicht damit, dass GetMenuItemCount bei einem ungültigen Menühandle den Wert -1 zurückgeben kann. Das MFC-eigene Menüobjekt CMenu::GetMenuItemCount hat deshalb wohl auch als Rückgabewert einen UINT, was für ganzzahlige Werte von 0 bis 4294967295 steht. Und was passiert, wenn man in einer Schleife 4294967295 Menüeinträge durchlaufen möchte? Richtig, der Prozessor kommt ins Schwitzen und die Anwendung hängt erst einmal.

Aber wie kommt es zu einem ungültigen Menühandle? Ich vermute, dass beide Erweiterungen bei der Zusammenstellung des Kontextmenüs einen neuen Menüeintrag mit AppendMenu einfügen. Die Flags für den neuen Eintrag werden auf MF_POPUP gesetzt, was für ein neues Untermenü steht. Soweit ist das auch in Ordnung. Allerdings sollte dann der Parameter uIDNewItem auch das Handle eines mit CreatePopupMenu erstellten Menüs enthalten und nicht einen Zeiger auf eine private Datenstruktur.

Dass es keine normalen Windows-Menüs sind, sieht man im folgenden Screenshot:

Meine Abneigung für Kontextmenü-Erweiterungen mit eigenen Symbolen zur besseren Erkennbarkeit wird übrigens auch durch solche Verunstaltungen nicht gerade kleiner:

Schon krass, wie ein einzelner Eintrag das ganze Kontextmenü versauen kann.

Nach drei öffentlichen Betaversionen könnt ihr euch nun die finale 12.40 herunterladen. Bis auf eine Anpassung der Versionsnummern gab es seit der letzten Betaversion keine Änderungen mehr.

Sascha hatte entdeckt, dass beim sicheren Löschen unter Umständen nur die ersten 64 KiB einer Datei überschrieben werden. Entsprechend der gewählten Durchgänge öffnet SpeedCommander die Datei und überschreibt alle Daten entweder mit 0x00 (schnell) oder mit 0x00, 0xFF und einem zufälligen Wert (nach Regierungsrichtlinien). Zum Abschluss eines Durchgangs öffnet SpeedCommander die Datei im WriteThrough-Modus und überschreibt die ersten 64 KiB, um Windows zu zwingen, den Cacheinhalt der Datei auf die Festplatte zu schreiben. Anschließend wird die Datei gelöscht.

Es scheint aber so, als ob Windows den Cache nicht zurückschreibt und die Daten mit Ausnahme der ersten 64 KiB erhalten bleiben. Ich weiß nicht, ob sich das Verhalten von Windows in der Zwischenzeit geändert hat. Den Code hatte Rainer damals geschrieben und ich bin mir ziemlich sicher, dass er diesen auch intensiv getestet hatte.

Als Konsequenz öffnet SpeedCommander die Dateien nun zum Überschreiben der gesamten Daten in jedem Durchgang im WriteThrough-Modus. Zudem wird die Datei jetzt vor dem endgültigen Löschen auch auf ‚z‘ umbenannt, um keine Rückschlüsse mehr auf den Namen ziehen zu können.

Die Beta 3 kann im Anwenderforum heruntergeladen werden (Anmeldung erforderlich). Anfang Januar folgt dann die finale Version.

Die zweite Beta von SpeedCommander 12.40 kann im Anwenderforum heruntergeladen werden (Anmeldung erforderlich). Neue Funktionen sind nicht enthalten, stattdessen wurden weitere Fehler der 12.30 gefixt. Fehler, die sich mit der Umstellung der Archiver eingeschlichen haben, wurden ebenfalls beseitigt.

Im Anwenderforum könnt ihr euch nun die erste Beta von SpeedCommander 12.40 herunterladen (Anmeldung erforderlich). SpeedCommander kann nun auch Archive erstellen und entpacken, deren Dateinamen länger als 260 Zeichen sind. CAB und ACE bleiben leider auf 260 Zeichen beschränkt, da das CAB-SDK sowie die UnAceV2.dll längere Dateinamen nicht mögen. Bei RAR liegt die Grenze bei 1024 Zeichen. Pfade innerhalb von Archiven bleiben ebenfalls auf 260 Zeichen beschränkt.

Fehlermeldungen beim Komprimieren bzw. Entpacken sind jetzt auch genauer, zudem wird bei einer Fehlermeldung auch der verursachende Dateiname genannt. Der Fehlerdialog lässt sich beliebig vergrößern und merkt sich Größe und Position für die nächste Anzeige.

Das Löschen von Dateien aus 7z-Archiven ist nicht mehr auf einfache 7z-Archive beschränkt, auch aus Solid-Archiven lassen sich Dateien entfernen. Ebenso funktioniert das Löschen für Dateien, die sich in verschiedenen Datenströmen befinden. In beiden Fällen wird das Archiv temporär entpackt und ohne die zu löschenden Dateien neu erstellt.

Dazu gibt es noch eine Menge Fehlerbehebungen. Die finale Version wird Anfang Januar erscheinen.