• 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)

Download für Windows Vista/XP/2000
Download für Windows Vista/XP x64
Download für U3-Stick

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.

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?

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.

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).

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.

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.

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.