SpeedCommander 15.50
SpeedCommander 15.50 steht zum Download bereit. In SpeedView und SpeedEdit lassen sich Registerkarten jetzt mit der mittleren Maustaste schließen. Zudem ist SpeedCommander nun auch auf Windows 10 vorbereitet.
Beseitigt wurden einige Unschönheiten auf HiDPI-Bildschirmen. Die Menüschriftart im Ribbon-Theme orientiert sich nun am Windows-Systemstandard, was auf hochauflösenden Bildschirmen für eine bessere Lesbarkeit sorgt. Das Installationsprogramm war bisher noch nicht an den HiDPI-Modus angepasst. Die Symbole für die Fenstermenübefehle (Minimieren, Schließen und Wiederherstellen) in SpeedEdit und SpeedView waren auf HiDPI-Bildschirmen zu winzig und sind nun besser zu treffen.
Korrigiert wurden auch einige Probleme mit der 64-bit Version auf Windows Vista. Die Ursache dafür ist ein Fehler in der C-/C++-Laufzeitbibliothek von Visual Studio 2013 bei der Ermittlung der CPU-Fähigkeiten, der sich durch einen Workaround glücklicherweise aber umgehen lässt.
Seit dem letzten Update erzeugte das Installationsprogramm auch keine Programmverknüpfung auf dem Desktop mehr. Dies wurde ebenfalls behoben. Die komplette Änderungsliste findet ihr wie gewohnt in der Versionsgeschichte.
Erfundene Kompatibilitätsprobleme
Die Vorstellung von Windows 10 hat viele überrascht, die meisten hatten mit Windows 9 gerechnet. Microsoft begründet den Sprung damit, dass die vielen Neuerungen den Versionssprung rechtfertigen. Sollte das stimmen, dann können wir noch großes erwarten. Der derzeitige Umfang der technischen Preview ist diesen Sprung für mich noch nicht wert.
Letzte Woche hat dann auf Reddit ein angeblicher Microsoft-Entwickler den wahren Grund preisgegeben. Schuld am Auslassen der Nummer 9 soll ein häufig vorkommender Quellcodeschnipsel mit dem Inhalt
if (osName.startsWith("Windows 9")
und die damit zu erwartenden Kompatibilitätsprobleme sein. Viele Seiten haben über die tausenden schlampigen Programmierer berichtet.
Die wenigsten haben sich aber bemüht, die etwaigen Kompatibilitätsprobleme zu hinterfragen. Searchcode liefert zwar mehr als 4300 Ergebnisse, die wenigsten entsprechen aber dem Suchmuster.
Die fragwürdigen Zeilen finden sich im Java Development Kit (JDK) von Oracle und in anderen Java-Programmen. Sie beziehen sich auf den Windows-Namen, den die Java-Laufzeitumgebung anhand der jeweiligen Windows-Version zusammenstellt. Die Laufzeitumgebung ruft dafür die Windows-Funktion GetVersionEx und auf wertet die Rückgabe aus. Der entsprechende Codeschnipsel für die aktuelle Windows-Generation (Versionsnummer 6) schaut so aus:
else if (ver.dwMajorVersion == 6) {
if (ver.wProductType == VER_NT_WORKSTATION) {
switch (ver.dwMinorVersion) {
case 0: sprops.os_name = "Windows Vista"; break;
case 1: sprops.os_name = "Windows 7"; break;
case 2: sprops.os_name = "Windows 8"; break;
case 3: sprops.os_name = "Windows 8.1"; break;
default: sprops.os_name = "Windows NT (unknown)";
}
Windows 10 meldet sich mit 6.4. Dieser Fall ist in den JDKs 7 und 8 noch nicht eingearbeitet. Also wird die default-Marke angesprungen und der von der Java-Laufzeit bereitgestellte Name wäre momentan ‚Windows NT (unknown)‘. In späteren Java-Versionen erfolgt hier sicher noch eine Anpassung. Die Entscheidung über den neuen gewählten Namen liegt aber ganz bei Oracle. Sollte Oracle Kompatibilitätsprobleme befürchten, dann hätte es ihnen auch freigestanden, einen kompatibleren Namen (z.b. Windows Nine) zu verwenden.
Mit Windows 8.1 hat Microsoft aber auch die Funktionalität von GetVersionEx geändert. Bis einschließlich Windows 8.0 war es so, dass GetVersionEx immer die aktuelle Versionsnummer zurückgegeben hat. Ab Windows 8.1 hängt die zurückgegebene Versionsnummer davon ab, ob sich die Anwendung per Manifest als kompatibel ausweist. Fehlt der Kompatibilitätseintrag im Manifest oder hat die Anwendung keins, dann gibt sich Windows 10 auch nur als Windows 8.0 zu erkennen. Ältere Anwendungen haben also keine bösen Überraschungen zu befürchten.
Dies würde im Moment auch die Abfrage im Java-JDK betreffen. Aufgrund des fehlenden Kompatibilitätseintrags für Windows 10 in der Java-Laufzeitumgebung gibt
public class Main
{
public static void main(String[ ] args)
{
String osName = System.getProperty("os.name");
System.out.println(osName);
}
}
derzeit unter Windows 10 den Text
Windows 8.1
aus.
SpeedCommander 15.40
SpeedCommander 15.40 kann heruntergeladen werden. Das Laufwerksstatus-Fenster zeigt acht neue Dateisystem-Eigenschaften. So kann man nun mit einem Blick sehen, ob das Laufwerk z.B. benannte Datenströme oder Hardlinks unterstützt. Der ‚Mehr Eigenschaften‘-Dialog enthält eine neue Schaltfläche zum Zurücksetzen aller Attribute. Beim Ausblenden von Dateien und Ordnern in der Listenansicht können ab sofort auch Pfadbezeichnungen verwendet werden.
SpeedEdit prüft beim Öffnen von Dateien ohne UTF-8 Kennung nun die ersten 2048 Zeichen auf eventuelle UTF-8 Vorkommen. Im Erfolgsfall wird die Datei dann automatisch im UTF-8 Modus geöffnet.
Dazu wurden noch einige kleine Fehler beseitigt. Eine vollständige Auflistung findet ihr in der Versionsgeschichte.
LibreOffice nach dem Start im Hintergrund
Ein Anwender hat berichtet, dass nach dem Doppelklick auf eine Dokumentendatei das LibreOffice-Fenster immer durch das SpeedCommander-Fenster überdeckt wird und erst durch einen Klick auf den Taskleisten-Eintrag in den Vordergrund geholt werden kann. Das Problem tritt nur mit LibreOffice-Dokumenten auf, ist aber auf Dauer doch sehr störend.
Nach dem Herunterladen von LibreOffice konnte ich das ganze hier auch nachstellen. Nach dem Doppelklick auf eine Datei zeigte sich der Startbildschirm von LibreOffice und anschließend auch das Programmfenster. Kurz danach verschwand das Programmfenster wieder hinter dem SpeedCommander-Fenster. Der Taskleisten-Eintrag für LibreOffice zeigt allerdings, dass LibreOffice weiter das aktive Programm ist. Man muss mit der Maus zweimal auf den Eintrag klicken, um das Fenster wieder in den Vordergrund zu holen.
Nach einer kurzen Analyse zeigte sich, dass das Problem mit dem Startbildschirm von LibreOffice zusammenhängt. Übergibt man in der Kommandozeile den Wert –nologo, dann funktioniert wieder alles wie gewünscht. Irgendwie scheint also im Programmcode von LibreOffice das Timing bei der Anzeige des Startbildschirms nicht richtig zu funktionieren.
Da es in den Einstellungen von LibreOffice keine Option zur Deaktivierung des Startbildschirms gibt (jedenfalls habe ich keine gefunden), muss man die Dokumentenverknüpfungen in der Registrationsdatenbank selbst anpassen. Dazu öffnet man durch Eingabe von regedit.exe den Registrationseditor und navigiert zu den Schlüsseln
[HKEY_CLASSES_ROOT\LibreOffice.WriterDocument.1\shell\open\command] [HKEY_CLASSES_ROOT\LibreOffice.CalcDocument.1\shell\open\command] [HKEY_CLASSES_ROOT\LibreOffice.DrawDocument.1\shell\open\command]
Hier fügt man den Programmparameter –nologo hinzu, aus
"C:\Program Files (x86)\LibreOffice 4\program\swriter.exe" -o "%1"
wird also
"C:\Program Files (x86)\LibreOffice 4\program\swriter.exe" -o --nologo "%1"
SpeedCommander 15.30
Ein neues Update für SpeedCommander 15 steht zum Download bereit. Das QuickDrop-Symbol für den Papierkorb zeigt auf Wunsch wieder den Füllstand an. Die Aktivierung erfolgt im Konfigurationsdialog für QuickDrop-Symbole (rechte Maustaste in den freien Bereich zwischen den Symbolen). Allerdings wird dann das Windows-Symbol für den Papierkorb angezeigt und nicht das des gerade gewählten Symbolstils. Diese Einschränkung ist leider nötig, weil sich sonst der Start von SpeedCommander verzögern würde, wenn der Papierkorb viele Dateien enthält.
Die Speicherung der Spaltenbreite in den Listenansichten erfolgt jetzt unabhängig von der aktuellen DPI-Skalierung. Das gleiche gilt auch für die Fenstergröße und die Position des Hauptfensters. Die Breiten und Relationen bleiben so auch beim Wechsel zwischen Systemen mit unterschiedlicher DPI-Skalierung erhalten.
Die Dateinamenslänge innerhalb von Archiven kann nun auch mehr als 260 Zeichen betragen. Das mit SpeedCommander 15 eingeführte Verhalten zum Zurücksetzen der Sicherheitsattribute beim Verschieben auf dem gleichen Laufwerk kann im Einstellungsdialog auf der Seite Erweitert – Spezielles wieder deaktiviert werden. Beim Synchronisieren mit FileSync wird die Zieldatei vor dem Kopieren nicht mehr gelöscht, wenn die Quelldatei gesperrt ist. SCBackupRestore erlaubt nun auch das Sichern von Einstellungen über Kommandozeilenparameter.
Zudem wurden auch noch einige Fehler behoben. Die Anzeige des Kontextmenüeintrags von Norton Internet Security funktioniert nun auch unter Windows 8.1. Das Speichern von Einstellungen über Extras – Einstellungen speichern war seit dem letzten Update ohne Funktion. Endgültig abgestellt sein sollten nun auch die Abstürze, die auf einigen Rechnern beim Anschließen eines USB-Sticks oder einer externen Festplatte auftreten konnten.
SpeedCommander 15.20
Pünktlich zum Frühlingsanfang steht ein neues Update für SpeedCommander zum Download bereit. Die Funktion Text unterhalb der Symbole anzeigen wurde reaktiviert und kann wieder für einzelne Symbolleisten aktiviert werden. Per Kommandozeile übergebene Ordner oder Archivdateien werden nun in einem neuen Ordnerfenster angezeigt. Auf einigen Systemen gab es Probleme mit der Anzeige der Netzwerkwerkumgebung. Abhilfe schafft eine neue Option im Einstellungsdialog, mit der die Ermittlung der Netzwerkgeräte im Hintergrund deaktiviert werden kann. Zudem können im Dialogfeld Mehrfaches Umbenennen die bevorzugten Einstellungen als Standardprofil gespeichert werden.
Der FTP-Transferpuffer wurde auf 256 KiB erhöht, dies sollte SFTP-Transfers etwas beschleunigen. Wird ein Ordnerpfad per Makro gesetzt, dann erfolgt das Einlesen des Ordnerfensters nicht mehr im Hintergrund. So kann auf die Einträge des Ordnerfensters sofort nach dem Befehlsaufruf zugegriffen werden. Bisher war das nicht möglich, weil die Aktualisierung des Ordnerfensters verzögert im Hintergrund erfolgte.
Dazu wurden auch noch etliche kleine Fehler behoben. Die Miniaturansichten standen in der 32-bit Version unter Umständen auf dem Kopf. Ursache dafür scheint ein Fehler im x86-Compiler von Visual C++ zu sein. Der Fehler trat nur in der optimierten 32-bit Version auf, die Debug-Version sowie die optimierte 64-bit Version zeigen die Miniaturansichten korrekt an. Wird die Optimierung für die betroffene Funktion gezielt deaktiviert, dann klappt es auch mit der 32-bit Version. Ich habe den Code jetzt so umgestellt, dass der Compiler keinen fehlerhaften Code mehr erstellt.
Die aktuelle Version von Norton Internet Security zeigt den Kontextmenüeintrag zum Scannen von Dateien nur noch im Explorer an, alle anderen Anwendungen werden explizit geblockt. Wird aber z.B. der Programmname von SpeedCommander.exe auf Explorer.exe geändert, dann ist der Kontextmenüeintrag plötzlich wieder sichtbar. Ich habe dann eine Möglichkeit gefunden, wie man Norton Internet Security auch ohne Umbenennen zur Anzeige des Eintrags überreden kann.
Unter Windows 8 wurden Miniaturansichten nicht mehr in voller Größe angezeigt. Die Erkennung von 256×256-Symbolen schlug fehl, weil einige Systemfunktionen plötzlich nicht mehr das machten, was sie unter Windows Vista/7 noch taten. Ein anderer Lösungsweg hat dann aber funktioniert.
Agile Prozessvorlage im TFS von 4.2 auf 2013 aktualisieren
Wenn man nach der Aktualisierung des Team Foundation Servers (TFS) auch die neuen Funktionen verwenden möchte, dann kommt man nicht umhin, die in den Teamprojekten verwendete Prozessvorlage zu aktualisieren. Ohne eigenes Zutun verbleibt diese nämlich in der Version, die bei der Projekterstellung aktuell war. Bei mir war das die Version 4.2 vom TFS 2008.
Von Microsoft gibt es dafür auch eine ausführliche Anleitung. Allerdings bezieht sich der erste Schritt zum Umbenennen der Systemfelder auf die englische Prozessvorlage. Die Anweisungen für die in der deutschen Version verwendeten Prozessvorlage lauten daher:
witadmin changefield /collection:CollectionURL /n:System.HyperLinkCount /name:"Anzahl von Hyperlinks" witadmin changefield /collection:CollectionURL /n:System.ExternalLinkCount /name:"Anzahl externer Links" witadmin changefield /collection:CollectionURL /n:System.RelatedLinkCount /name:"Anzahl zugehöriger Links" witadmin changefield /collection:CollectionURL /n:System.AttachedFileCount /name:"Anzahl angefügter Dateien"
Die restliche Anleitung ab Schritt 2 kann dann wie beschrieben abgearbeitet werden. Nach der Aktualisierung sollte noch der Cache zurückgesetzt werden:
witadmin rebuildcache /collection:CollectionURL
Und nicht vergessen: Vor solchen Änderungen immer eine Sicherung der Datenbanken erstellen.
Umstieg 2: Visual Studio 2013
Seit mehr als sechs Jahren nutze ich nun Visual Studio 2008. Compiler- und bibliothekstechnisch war ich trotzdem auf dem aktuellen Stand, da sich die neuen Versionen relativ problemlos in die alte IDE einbinden lassen. Den Team Foundation Server (TFS) läuft schon in der 2010er-Version, aufgrund der Einbindung in die 2008er-IDE arbeitet man aber quasi auf dem 2008er-Niveau.
Die Entwicklung lief also quasi auf fest eingetrampelten Pfaden, was natürlich auch eine gewisse Stabilität verspricht. Trotzdem kam in den letzten Wochen der Wunsch nach etwas Veränderung auf. Also habe ich mir das nagelneue Visual Studio 2013 einmal etwas genauer angeschaut und getestet, ob ein Umstieg in Frage kommt.
Bei der wichtigsten Erweiterung Visual Assist waren keine Probleme zu erwarten. Auf meine EasyTabs muss ich natürlich verzichten, aber das Tabs Studio ist ein guter Ersatz. Ziemlich erstaunt war ich, als ich meine Makros übertragen wollte. Die Makrofunktionen waren nicht mehr zu finden und nach einer Netzsuche wusste ich, dass es seit Visual Studio 2012 keine Makros mehr gibt. Abhilfe schafft hier die Visual Commander-Erweiterung vom Tabs Studio-Autor. Meine VB-Makros konnte ich nahezu 1:1 übernehmen. Ab und zu fehlte nur ein DTE. für den Zugriff auf das Automationsmodell.
Der erste Kompilierungsversuch scheiterte allerdings an einer Exception in Microsoft.Build.Utilities.FileTracker. Die Ursache fand ich recht schnell im Netz. Mein Temp-Verzeichnis zeigt auf eine RamDisk, und zwar direkt auf das Hauptverzeichnis. Das mag MSBuild wohl gar nicht. Nach der Verlagerung des Temp-Verzeichnisses in einen Unterordner auf der RamDisk war das Problem behoben.
Die Fehlermeldungen im Zusammenhang mit den Zieldateinamen waren zu erwarten, schließlich habe ich die Erfahrung ja schon beim Test von Visual Studio 2010 gemacht. Die damalige Abneigung gegen die Vergabe von Projektnamen in den Projekteinstellungen hat sich nun in Befürwortung geändert. Bei konsequenter Verwendung des Projektnamens in den Compiler-/Linkereinstellungen braucht man bei Versionsänderungen (z.b. von MxFtp71 auf MxFtp72) diesen nämlich nur noch einer einzigen Stelle ändern. Früher musste man dagegen noch sämtliche Ausgabedateien anpassen.
Bei den gemeinsamen Bibliotheken verwende ich als Ausgabeordner der .dll-Dateien ein gemeinsames Verzeichnis. Hier unterscheidet sich der Zielpfadname mit Absicht vom Ausgabeverzeichnis des Projekts, was MSBuild jedesmal mit einer Warnung quittiert. Ein Löschen der entsprechenden Zeile 1186 aus Microsoft.CppBuild.targets schafft Abhilfe.
Als ordnungsliebender Mensch hat mich das neu angelegte ipch-Verzeichnis in jedem Arbeitsbereichsordner gestört, in dem die Datenbank für die IntelliSense-Daten abgelegt wird. Im Einstellungsdialog lässt sich unter Text-Editor | C/C++ | Erweitert im Bereich Ausweichpfad ein alternativer Pfad hinterlegen. Der Ausweichpfad zeigt bei mir nun auf ein Unterverzeichnis im lokalen AppData-Bereich und die Arbeitsbereichsordner sind ipch-frei.
Etwas verwirrend finde ich, dass im Projektmappen-Fenster vor den Quellcode-Dateien nun auch kleine Pfeile angezeigt werden und man die Quellcode-Dateien wie Ordner aufklappen kann. Aktiviert man auf der oben erwähnten Einstellungsseite im Bereich Durchsuchen/Navigation die Option Datenbank deaktivieren, dann verschwinden die Pfeile. Allerdings wird dann nur noch eine leere Ressourcen-Ansicht angezeigt. Eine Ressourcen-Datei kann dann nur per Rechtsklick mit Öffnen mit und dem Ressourcen-Editor geöffnet werden. Bei einem Gegentest mit Visual Studio 2010 zeigte sich das gleiche Problem. Entweder hat sich hier ein Fehler durch mehrere Versionen geschlichen oder das ganze ist ‚by Design‘.
Beim Erstellen der konvertierten Projekte gab es nur wenige Probleme. Die MFC enthält nun Makros für die Nachrichtenfunktionen WM_COPY und WM_PASTE, damit konnte ich meine eigenen Makros für diese Funktionen löschen. Zudem wurden die Implementierungen für CWnd::OnDisplayChange und CWnd::OnPrintClient geändert. Hier muss man die Funktionen in den eigenen Klassen entsprechend anpassen. Das gilt aber nur, wenn die Projekte bereits auf dem VS 2012-Stand sind. Beim Konvertieren von älteren MFC-Versionen könnten auch mehr Korrekturen nötig sein.
Die Codeanalyse-Prüfungen im neuen Compiler wurden weiter aufgebohrt und es werden Sachen angemeckert, die der VS 2012-Compiler noch ohne Warnungen durchgewunken hat. Hier empfiehlt es sich, die Codeanalyse erst einmal temporär zu deaktivieren und die genaue Untersuchung auf einen späteren Zeitpunkt zu verschieben. Neu ist, dass die Regelsätze für die Codeanalyse nun auch angepasst werden können. Ob das in VS 2012 auch schon war, kann ich leider nicht sagen.
Von optischer Seite her macht Visual Studio 2013 einen sehr guten Eindruck. Die verwendeten Symbole sind zwar farblich sehr zurückhaltend, konzentrieren sich dadurch aber auf das Wesentliche. Besonders gut gefallen mir die synchronisierten Einstellungen über mehrere Rechner hinweg. Hier werden die Einstellungen für Darstellung, Tastenkürzel und Texteditor auf einem Microsoft-Server gespeichert und immer aktuell gehalten. Das erleichtert das Arbeiten an mehreren Rechnern enorm.
Sehr gelungen finde ich auch die Team Explorer-Ansicht innerhalb der IDE. Arbeitsaufgaben und ausstehende Änderungen sind immer im Blickfeld. Auch das Verknüpfen von Arbeitsaufgaben beim Einchecken geht ohne modale Dialoge sehr viel leichter von der Hand. Zu weiteren Erkundungen innerhalb der IDE bin ich noch nicht gekommen, aber ich freue mich schon darauf.
Etwas schade ist, dass der Remote Debugger nicht mehr auf Windows XP und Windows Vista läuft. Zu älteren Versionen des Remote Debuggers kann VS 2013 keine Verbindung mehr aufnehmen. Man kann zwar noch Anwendungen erstellen, die unter Windows XP laufen, diese aber nicht mehr auf Windows XP debuggen. Windows XP nähert sich also unaufhaltsam seinem Ende.
Alten Task-Manager in Windows 8 reaktivieren
Mit dem neuen Task-Manager von Windows 8 kann ich mich nicht so recht anfreunden. Zum einen wird trotz minimiertem Start und Ausblenden, wenn minimiert immer ein Eintrag in der Taskleiste angezeigt. Dazu möchte ich in der Prozessliste auch nur die Prozesse meines Benutzernamens sehen und nicht gleich alle Systemprozesse.
Im Netz habe ich eine Lösung gefunden, wie man weiter den alten Task-Manager verwenden kann. Die zusätzlichen Registrationseinträge sind nur nötig, wenn man den neuen Task-Manager komplett durch den alten ersetzen möchte. Ohne diese kann man z.B. den alten Task-Manager per Autostart minimiert in den Infobereich starten und hat bei Bedarf durch einen Rechtsklick auf die Taskleiste Zugriff auf den neuen.
Der einzige Nachteil ist, dass der alte Task-Manager nur in englischer Sprache verfügbar ist. Auch auf der deutschen Windows 8-DVD gibt es nur die englische Version. Aber das ist verschmerzbar.