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
Unverständlich
Handbremse gelöst
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
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
Ein Bild sagt mehr als 260 Zeichen:
Carbonite Backup ist etwas wählerisch
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:
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
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:
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
Beim Versuch, auf einer Windows 2000-VM den Remote Debugger auf die finale Version zu aktualisieren, bekam ich folgende Meldung zu sehen:
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
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.
Endlich da
Im heise-Newsticker ist mir gestern diese brandaktuelle Flash-Werbung über den Weg gelaufen:
VS 2008: MFC selbst kompilieren
Gestern hatte ich darüber berichtet, wie man der WinSxS-Hölle entkommt und eine eigene Version der C/C++-Laufzeit kompiliert. Nun kompilieren wir uns noch eine MFC ohne Manifest und können in Zukunft die C/C++-Laufzeit sowie die MFC unseren Anwendungen beilegen, ohne uns mit Manifestproblemen herumquälen zu müssen.
1. Anpassen der Dateien
Die nötigen Änderungen an den MFC-Dateien halten sich in Grenzen. Zuerst schnappen wir uns die Datei atlmfc\include\MFCassem.h und kommentieren das Manifest ab Zeile 25 bis zum Ende aus. In atlmfc\include\afx.h ersetzen wir die Zeilen 81 bis 97 durch folgende:
#ifndef _UNICODE
#ifdef _DEBUG
#pragma comment(lib, “MyMfc90d.lib”)
#pragma comment(lib, “MyMfc90sd.lib”)
#else
#pragma comment(lib, “MyMfc90.lib”)
#pragma comment(lib, “MyMfc90s.lib”)
#endif
#else
#ifdef _DEBUG
#pragma comment(lib, “MyMfc90ud.lib”)
#pragma comment(lib, “MyMfc90sud.lib”)
#else
#pragma comment(lib, “MyMfc90u.lib”)
#pragma comment(lib, “MyMfc90su.lib”)
#endif
#endif
Damit legen wir fest, dass unsere Anwendungen dynamisch gegen die MyMfc90(u).dll gelinkt werden.
2. Vorbereitung der .DEF-Dateien
In atlmfc\src\mfc\intel und atlmfc\src\mfc\intel befinden sich jeweils vier .DEF-Dateien, deren Modulnamen ebenfalls angepasst werden müssen:
mfc90.def -> MyMfc90
mfc90d.def -> MyMfc90d
mfc90u.def -> MyMfc90u
mfc90ud.def -> MyMfc90ud
Im Gegensatz zur C/C++-Laufzeit werden aber nur die Modulnamen in den .def-Dateien angepasst, die Dateinamen selbst dürfen nicht geändert werden.
3. Anpassung des Makefiles
Die Änderung in der Datei atlmfc\src\atlmfc.mak beschränkt sich darauf, die Erstellung der statischen MFC sowie der WinForms-Komponenten auszuklammern. Dazu löschen wir in Zeile 123 die Einträge MFC_STATIC und MFCM_DLL.
4. Kompilieren
Nun kopieren wir unsere bereits erstellten Batchdateien mit den Umgebungsvariablen aus dem Ordner crt in den Ordner atlmfc\src. Zusätzlich erstellen wir in diesem Verzeichnis eine Datei makemfc_x86.bat mit dem Inhalt
nmake -f atlmfc.mak MFC LIBNAME=MyMfc90 PLATFORM=INTEL MP_BUILD=1
sowie makemfc_amd64.bat mit
nmake -f atlmfc.mak MFC LIBNAME=MyMfc90 PLATFORM=AMD64 MP_BUILD=1
Anschließend öffnen wir eine Eingabeaufforderung und starten
vcvars_x86.bat
makemfc_x86.bat
sowie anschließend
vcvars_amd64.bat
makemfc_amd64.bat
Nach ein paar Minuten sollte der Compiler seine Arbeit erledigt haben und wieder das Befehlsprompt erscheinen.
5. Kopieren der Lib-Dateien
Der letzte Schritt ist das Kopieren der lib-Dateien nach atlmfc\lib, damit der Linker diese später auch findet. Die Lib-Dateien für die 32-bit Version werden bei der MFC-Erstellung in atlmfc\lib\Intel abgelegt und müssen deshalb manuell nach atlmfc\lib kopiert werden. Die Lib-Dateien für die x64-Version landen dagegen direkt im richtigen Verzeichnis (atlmfc\lib\amd64).
Die MFC-Dlls finden wir in atlmfc\src\mfc\intel bzw. atlmfc\src\mfc\amd64. Zusammen mit den Dlls der C/C++-Laufzeit sowie den jeweiligen PDB-Dateien kopieren wir sie in einen Ordner, der in die PATH-Umgebungsvariable eingetragen wird. Somit ist sichergestellt, dass Visual Studio 2008 beim Debuggen auch alle nötigen Dateien findet.
6. Kontrolle
Zur Kontrolle erstellen wir uns ein Testprojekt und prüfen, ob gegen die richtigen Dateien gelinkt wird. Dazu lassen wir uns vom AppWizard eine einfache MFC-Anwendung erstellen und kompilieren diese. Mit Hilfe der Schnellansicht von SpeedCommander lässt sich leicht ermitteln, ob die Programmdatei an die richtigen Module gebunden wurden. Wenn es so ausschaut, dann ist alles in bester Ordnung:
Die gleiche Aktion führen wir noch einmal für die MyMfc90(ud).dll durch, diese sollten ebenfalls gegen die MyVcr90(d).dll gelinkt sein.
7. Letzte Worte
Zum Abschluss sei nochmals erwähnt, dass sich diese beiden Artikel wirklich nur an den nativen Entwickler richten, der vollständigen Einfluss auf die von ihm verwendeten Komponenten hat. Dazu gehört, dass alle Fremdkomponenten im Quellcode vorliegen und somit gegen die angepasste C/C++-Laufzeit bzw. die MFC kompiliert werden können. Verwendet man dagegen zusätzliche Managed Code-Erweiterungen oder fertige Libs/Dlls, die bereits gegen die originale MsVcr90.dll gelinkt sind, dann sollte man um die manifestlose Lösung einen großen Bogen machen.