Komfortabler Dateimanager mit vielen Funktionen

Visual C++ 2008 Feature Pack Beta

By Sven on 08.01.2008 - 10:09 in MFC, Visual Studio 2008 with 7 Kommentare

Gestern abend hat Microsoft die erste Beta vom Visual C++ 2008 Feature Pack veröffentlicht. Das Paket ist 303 MiB groß und erfordert zur Installation ein englisches Visual Studio 2008. Die dazugehörige Dokumentation ist etwas kleiner (3.40 MiB) und lässt sich auch ohne Installation betrachten.

Mit der Installation des Feature Packs werden die CRT- und MFC-Verzeichnisse aktualisiert. Es empfiehlt sich daher, vor der Installation eine Kopie des aktuellen VS 2008-Installationsverzeichnisses anzulegen, damit man nach der Installation bei Bedarf zwischen beiden Versionen hin- und herschalten kann. Wer nach der Installation einen schwerwiegenden Fehler mit der Meldung bekommt, dass keine VS 2008-Installation gefunden werden konnte, der sollte vor der Installation des Patches die Installations-DVD von VS 2008 einlegen. Eine Aufforderung dazu gibt es nämlich nicht.

Mit dem Visual C++ 2008 Feature Pack verwandelt sich die MFC zu einem Monstrum. Das atlmfc\include-Verzeichnis wächst von 152 Dateien auf 334 Dateien an und im atlmfc\mfc\src-Verzeichnis befinden sich nach dem Update 437 Dateien (vorher 261). Die zu verteilende mfc90(u).dll wächst von 1.10 MiB auf 3.57 MiB an, was die Größe des Redistributionspakets mal eben locker verdreifacht.

Nun zu den guten Nachrichten. Die normalen MFC-Dateien sind bisher (noch?) nicht von den neuen BCG-Dateien abhängig. Wenn man in atlmfc\mfc\src\makefile die Sektion CONTROLBARS entfernt und die neuen Exporte in den mfc90(ud).def-Dateien löscht, dann kann die MFC immer noch ohne die BCG-Dateien erstellt werden. Zudem muss aus der atlmfc\mfc\src\mfcdll.rc noch die Zeile #include “afxribbon.rc” auskommentiert werden, damit die Office 2007-Grafiken nicht eingebunden werden. Wenn das auch in Zukunft so bleibt, dann kann ich damit leben.

This is Gerald

By Sven on 04.01.2008 - 10:44 in Webweites with 8 Kommentare

Eigentlich bin ich ja kein großer Freund von Web-Comics, aber keine Regel ohne Ausnahme:

This is Gerald

Seit dem 20. Juni 2007 gibt es jeden Montag, Mittwoch und Freitag einen neuen Strip aus Geralds Leben. Gerald freut sich über jeden neuen Leser, also schaut doch einfach einmal vorbei.

Unverständlich

By Sven on 19.12.2007 - 18:04 in Support with 16 Kommentare

Wie kommt man eigentlich auf die Idee, sich mit folgenden Daten zu registrieren?

{Produkt}: SC8
{KNR}:
{Name1}: sdf
{Name2}: FSDf
{Strasse}: dsfsdfsd
{PLZ}: 943534
{Ort}: sdfsf
{Country}: DE
{EMail}: WERW at WEFW.de
{Gekauft}: we

Handbremse gelöst

By Sven on 18.12.2007 - 15:14 in SpeedCommander 12 with 5 Kommentare

Im Forum haben sich einige Anwender darüber beklagt, dass SpeedCommander beim Anzeigen von Ordnern in Netzwerken nicht gerade fix ist. Mit aktivierter Baumansicht dauert das ganze sogar noch länger.

Nach der Umstellung auf lange Dateinamen habe ich nun die Funktionen, die für die Auflistung von Ordnern zuständig sind, Stück für Stück seziert, um die Gründe für die magere Performance zu finden.

1. Ermittlung der Pidls

SpeedCommander verwendet für die Navigation im Dateisystem normale Pfadnamen, während die Windows-Shell im gesamten Namensbereich sogenannte ITEMIDLISTs verwendet. Ein Pfad wird durch eine oder mehrere aneinandergekettete ITEMIDLIST-Strukturen dargestellt, man spricht hier auch von Pidls (Pointer auf ITEMIDLIST). Viele Shell-Funktionen erwarten nun anstatt dem normalen Pfadnamen eine Pidl, SpeedCommander muss dafür den normalen Pfadnamen (z.B. C:\Test\123.txt) in eine Pidl konvertieren.

Für die Konvertierung verwendete SpeedCommander bisher die dafür empfohlene und in vielen Beispielen verwendete Funktion IShellFolder::ParseDisplayName. Leider ist diese Funktion insbesondere im Netzwerk eine ziemliche Performancebremse, was mir bisher gar nicht so bewusst war. Mit der Eliminierung dieser Performancebremse hat sich die Geschwindigkeit bei der Anzeige von Ordnern in der Dateiliste spürbar erhöht. Dies gilt auch für den lokalen Arbeitsbereich.

2. Baumansicht und Archivdateien

Wenn im Einstellungsdialog auf der Seite Aussehen – Dateien & Ordner die Option Archive im Baum anzeigen aktiviert ist, dann prüft SpeedCommander bei der Zusammenstellung der Baumansicht jede Datei, ob sie ein potentielles Archiv ist. Eigentlich sollte dabei nur die Erweiterung geprüft werden, allerdings hatte sich hier noch eine (mittlerweile unnötige) Abfrage der Dateiattribute eingeschlichen. Durch Deaktivierung dieser Option kann SpeedCommander in der aktuellen Version die einzelnen Baumelemente schneller aufklappen, ab der 12.10 bringt auch eine Aktivierung keine Nachteile mehr.

3. Baumansicht und Netzlaufwerke

In der Baumansicht zeigen kleine Pluszeichen vor dem Ordnersymbol an, ob der Ordner noch weitere Unterordner enthält. In der Netzwerkumgebung wird dagegen vor jedem Ordnersymbol ein kleines Pluszeichen angezeigt, weil die Prüfung auf das Vorhandensein von Unterordnern unter Umständen sehr viel Zeit kosten kann. Erst beim Klick auf den jeweiligen Ordner wird das Pluszeichen gegebenenfalls aktualisiert.

Ab SpeedCommander 12.10 entfällt die Prüfung auch für gemappte Netzlaufwerke, so dass das Aufklappen von Ordnern in der Baumansicht hier deutlich schneller erfolgt.

4. Ermittlung des Speicherplatzes für die Statuszeile

Der in der Statuszeile angezeigte freie und verfügbare Speicherplatz wird bei jeder Auswahländerung in der Dateiliste neu ermittelt. Gerade bei VPN-Verbindungen beansprucht das aber viel Zeit, so dass die Bewegung des Auswahlbalkens unter Umständen sehr zähflüssig verläuft. Ab SpeedCommander 12.10 erfolgt die Ermittlung nur noch bei der Auflistung des Ordners sowie bei Änderungen aufgrund der automatischen Hintergrundaktualisierung.

5. Anzeige des Kontextmenus

Die oben erwähnten Pidls werden auch für die Anzeige des Kontextmenüs der rechten Maustaste benötigt, bisher wurden diese bei jedem Aufruf neu ermittelt. SpeedCommander 12.10 verwendet nun die bereits für die Anzeige ermittelten Pidls, was eine sofortige Anzeige des Kontextmenüs ohne Verzögerung erlaubt.

6. Brotkrumen für Netzwerkumgebung

Bei der Zusammenstellung der Brotkrumenansicht für die Netzwerkumgebung muss SpeedCommander alle Elemente für den gesamten Netzwerkpfad ermitteln. Bis zum Freigabebereich geschieht das auch recht zügig, erst der Bereich von der Freigabe bis zur Netzwerkumgebung selbst kann etwas Zeit in Anspruch nehmen. In der Regel ändert sich diese Information beim Verzeichniswechsel unterhalb der Freigabeebene aber nicht mehr, so dass SpeedCommander 12.10 auf die erneute Ermittlung verzichten kann. Zudem erfolgt die Zusammenstellung der Brotkrumenansicht nun im Hintergrund, damit werden schnelle Ordnerwechsel nicht mehr unnötig blockiert.

Mehr zu #undef MAX_PATH

By Sven on 13.12.2007 - 21:25 in SpeedCommander 12 with 4 Kommentare

Ich habe einmal ein paar Fragen und Antworten zur MAX_PATH-Geschichte zusammengestellt.

Was ist MAX_PATH?

MAX_PATH ist eine Konstante aus dem Windows-SDK und definiert die maximal mögliche Länge eines Dateinamens. Der Wert von MAX_PATH beträgt 260, d.h. ein gültiger Dateiname für die Windows-API darf maximal 260 Zeichen enthalten. Die meisten Programme arbeiten deshalb mit festen Puffern von 260 Zeichen, wenn es um Dateinamen geht.

Ich habe aber schon längere Dateinamen gesehen. Wie geht das denn?

Die maximal möglichen 260 Zeichen gelten für den vollständigen Dateinamen inklusive Laufwerksbezeichnung. Wenn man sich eine etwas tiefer gelegene Netzwerkfreigabe als neuen Laufwerksbuchstaben einrichtet, dann kann man ab dieser Freigabe wieder mit 260 Zeichen arbeiten. Kopiert man nun Dateien mit sehr tiefen Ordnerstrukturen in diese Freigabe, dann kann man diese problemlos verwalten, aber auf dem Rechner mit der Freigabe kommt man aber nicht mehr bis an das Ende der Struktur. Viele Programme zeigen dann die Fehlermeldung “Der Dateiname oder die Erweiterung ist zu lang.” an.

Wie umgeht SpeedCommander diese Beschränkung in Zukunft?

Die Unicode-Versionen vieler Windows-Funktionen können Dateinamen mit bis zu 32000 Zeichen verarbeiten, wobei eine einzelne Komponente maximal 255 Zeichen lang sein kann. Durch Voranstellung des Präfixes \\?\ vor dem Dateinamen kann die Beschränkung auf 260 Zeichen aufgehoben werden. Statt dem bisher gewohnten Dateinamen C:\Windows\explorer.exe verwendet man einfach \\?\C:\Windows\explorer.exe. Bei UNC-Namen gilt \\?\UNC\Server\Freigabe anstatt \\Server\Freigabe.

Muss ich das Präfix nun auch immer voranstellen?

Nein, für den Anwender ändert sich nichts. SpeedCommander verwendet das Präfix nur intern, der Anwender sieht weiterhin die gewohnten Datei- und Ordnernamen.

Die Windows-Shell kann aber nur Dateinamen mit bis zu 260 Zeichen verarbeiten. Was nun?

Die meisten Shell-Funktionen (z.B. SHGetFileInfo und SHFileOperation) sowie die Shell-Interfaces (z.B. IShellFolder und IContextMenu) kommen nur mit Dateinamen mit maximal 260 Zeichen klar. Das heißt, dass es für Dateinamen mit mehr als 260 Zeichen keine Vorschaubilder oder Informationen von Spaltenerweiterungen gibt. Die Anzeige des Kontextmenüs, Drag&Drop sowie das Löschen in den Papierkorb ist für diese Dateinamen ebenfalls nicht möglich. Ab Windows Vista kann die Shell auch mit sehr tiefen Ordnerstrukturen umgehen (bis zu 26 Unterverzeichnisse, wenn die Ordnernamen jeweils mehr als 8 Zeichen lang sind, bei kürzeren Ordnernamen sind noch mehr Stufen möglich).

Welche Funktionen bleiben auf 260 Zeichen beschränkt?

Alle wichtigen Funktionen in SpeedCommander, FileSearch und FileSync können mit Dateinamen von bis zu 32000 Zeichen umgehen. Für Archive gibt es vorerst weiterhin ein Limit von 260 Zeichen, es ist aber geplant, dieses Limit zumindestens für Archivdateien aufzuheben. Innerhalb der Archive bleibt die Beschränkung auf 260 Zeichen aber bestehen. Weiterhin gilt das Limit für

  • das Programmverzeichnis von SpeedCommander inkl. seiner Komponenten
  • das Verzeichnis mit den Einstellungsdateien
  • die Schnellansicht für Multimedia, Internet Explorer und Schriftarten
  • sämtliche Shell-Aufrufe (Vorschaubilder, Spaltenerweiterungen, Drag&Drop, Kontextmenü, Löschen in den Papierkorb)
  • das Starten von Anwendungen
  • die Auswahl von Dateinamen über Öffnen-/Speichern-Dialoge sowie der Ordnerauswahl-Dialog 

Genug erzählt. Gib uns endlich den Downloadlink!

Die Abkehr von der 260-Zeichen-Begrenzung hat naturgemäß viele Veränderungen in den Programmfunktionen nach sich gezogen, die natürlich erst einmal von den festen Betatestern umfassend getestet werden müssen. Die Freigabe der Version 12.10 ist für das erste Quartal 2008 geplant.

#undef MAX_PATH

By Sven on 11.12.2007 - 10:24 in SpeedCommander 12 with 11 Kommentare

Ein Bild sagt mehr als 260 Zeichen:

Dateinamen bis zu 32760 Zeichen

Carbonite Backup ist etwas wählerisch

By Sven on 10.12.2007 - 11:42 in Entwicklung with 11 Kommentare

Ein SpeedCommander-Anwender setzt die Software Carbonite Backup ein, mit der die zu sichernden Daten über das Internet in ein Backup-Center übertragen werden. Mit Hilfe von Overlay-Symbolen wird der Status gekennzeichnet. Ein grüner Punkt zeigt z.B. an, dass die Datei gesichert wurde. Mit einem gelben Punkt versehene Dateien werden gerade gesichert.

Soweit so gut, doch leider werden die Punkte nur im Explorer angezeigt, in SpeedCommander sind alle Dateien punktlos. Eigentlich gibt es dafür aber keinen Grund, da SpeedCommander die entsprechenden Overlay-Symbole ebenfalls bei der Shell anfragt und dann auch anzeigen sollte.

Im Debugger sah ich dann, dass beim Aufruf von IShellIconOverlay::GetOverlayIndex der Fehlercode E_FAIL zurückgegeben wird. Laut Dokumentation bedeutet dies, dass die übergebene PIDL ungültig ist. Zu erklären ist dies aber nicht, da alle anderen Overlay-Symbole ja korrekt ermittelt werden.

Aus Verzweiflung kam ich auf die dumme Idee, SpeedCommander.exe in Explorer.exe umzubenennen und aufzurufen. Danach sah ich das:

SpeedCommander als explorer.exe

Die Darstellung der Overlay-Symbole von Carbonite Backup funktioniert also wohl nur in Prozessen, die Explorer.exe heißen. Zur Überprüfung habe ich mir dann die Datei CarboniteNSE.dll angeschaut und bin auf folgende hartkodierte Namen gestoßen:

  • explorer.exe
  • dopus.exe
  • pdexplo.exe
  • regsvr32.exe
  • verclsid.exe
  • carboniteui.exe

Ändere ich SpeedCommander.exe in einen dieser Namen, dann werden die Symbole korrekt angezeigt. Bei allen anderen verweigert Carbonite Backup die Anzeige der Symbole und des Kontextmenü-Eintrags.

Erweiterte Farbeinstellungen

By Sven on 06.12.2007 - 16:30 in SpeedCommander 12 with 4 Kommentare

Fly hat im Anwenderforum berichtet, dass sich die Textfarbe für Jede zweite Zeile sowie die Hintergrundfarben für Komprimiert und Verschlüsselt nicht anpassen lassen. Bisher war das einfach nicht vorgesehen, mit SpeedCommander 12.10 wird das aber möglich sein.

Es gab zudem immer wieder Nachfragen, warum man in diesem Dialog zwar die Farben der Titelzeilen anpassen konnte, dies aber scheinbar keinen Einfluss auf die Anzeige in den Ordnerfenstern hatte. Der Grund war die im Bereich Spezielles abgelegte Option Office 2003-Gradientfarben für aktives Fenster. Ist diese gewählt, dann werden bei aktiviertem Office 2003/2007-Layout immer feste Farben verwendet.

Diese Option findet sich ab SpeedCommander 12.10 nun gleich im Farbeinstellungs-Dialog und sie hat auch Einfluss auf die Vorschau im Beispielfenster. Eventuelle Irritationen sollten damit in Zukunft abgestellt sein.

Und so sieht die neue Seite nun aus:

Erweiterte Farbeinstellungen

Aufmerksame Leser werden feststellen, dass sich bei aktiviertem Office 2007-Design die Gradientfarben für das aktive und inaktive Fenster geändert haben. Mehr dazu in einem der nächsten Beiträge.

VS 2008: Remote Debugger unter Windows 2000

By Sven on 05.12.2007 - 10:46 in Visual Studio 2008 with 1 Kommentar

Beim Versuch, auf einer Windows 2000-VM den Remote Debugger auf die finale Version zu aktualisieren, bekam ich folgende Meldung zu sehen:

Meldung unter Windows 2000

Weniger schön, zumal der Remote Debugger der Beta 2 dieses Verhalten noch nicht kannte. Aber glücklicherweise ist das nur ein Problem des Installationsprogramms. Wer vorsichtig genug war, das DVD-Image der Beta 2 noch nicht zu entsorgen, der entpackt einfach beide Versionen von rdbgsetup.exe (jeweils zu finden unter Remote Debugger\x86), ersetzt die install.exe der RTM-Version durch die der Beta 2 und startet diese dann manuell. Voila, und schon kann man wieder unter Windows 2000 debuggen.

Bei euch bestellt

By Sven on 04.12.2007 - 15:15 in Support with 4 Kommentare

Letzte Woche habe ich die Updateinformationen zu SpeedCommander 11.65 versandt. Einige Kunden haben darauf geantwortet und gefragt, was sie denn davon zu halten hätten? Schließlich haben sie doch bei uns bereits das Upgrade auf den SpeedCommander 12 gekauft.

Viele Kunden denken, dass SWE Sven Ritter (speedproject.de) und JDS Software (jds-software.de) eine Firma ist. Anfragen zu Bestellungen werden an Jens Driese adressiert und an info@speedproject.de geschickt; andere meinen wiederum, dass Jens den SpeedCommander selbst entwickelt hat.

SWE Sven Ritter und JDS Software sind aber zwei völlig eigenständige Unternehmen. Obwohl unsere Telefonnummern es fast vermuten lassen, dass wir Tür an Tür arbeiten, so liegen unsere Büros doch 5 km auseinander. Während der 14-jährigen Zusammenarbeit hat sich natürlich auch eine enge Freundschaft entwickelt, diese ändert aber nichts daran, dass die wirtschaftlichen Tätigkeiten völlig autonom ablaufen.

SpeedCommander wird von mir entwickelt und supportet, mit dem Vertrieb selbst habe ich aber überhaupt nichts zu tun. Der Verkauf läuft über JDS Software und share*it!, für Anfragen zu getätigten Bestellungen bin ich deshalb der völlig falsche Ansprechpartner. Wer also Fragen zu offenen Bestellungen hat, der muss sich direkt an die beiden Firmen wenden. Beide arbeiten übrigens auch völlig unabhängig voneinander. Es gab schon Fälle, wo bei share*it! bestellt und bezahlt wurde, aber aufgrund eines hochoptimierten Spamfilters kein Freischaltcode eingetroffen ist. Anstatt bei share*it! nachzufragen, wurde nach zwei Wochen einfach bei JDS Software erneut bestellt. Anschließend hat man sich bei mir beschwert, warum man denn zweimal bezahlen müsse und um Rücküberweisung gebeten.

Die eMail-Informationen beim Erscheinen neuer Versionen werden von mir versendet. Voraussetzung dafür ist eine Registrierung über http://register.speedproject.de/. Diese ist völlig unabhängig vom Kauf der Software über JDS Software oder share*it!. Bei Updates werden nur die Anwender informiert, die sich für die jweilige Version registriert haben. Wenn sich z.B. ein registrierter SC11-Anwender für den SC12 registriert, dann wird die Kennung dieser eMail-Adresse von SC11 auf SC12 geändert und er bekommt in Zukunft nur noch Updateinfos zum SC12. Verzichtet er aber auf die erneute Registrierung, dann bleibt er in der SC11-Liste hängen und wird somit bei zukünftigen SC11-Updates weiter informiert, nicht aber bei SC12-Updates.

Top