Komfortabler Dateimanager mit vielen Funktionen

Erste Eindrücke von Windows 10

By Sven on 03.08.2015 - 14:10 in Windows 10 with 6 Kommentare

Nach der Annäherung an Windows 10 in einer VM habe ich das System nun auch auf dem PC installiert. Die erste grundlegende Erfahrung: Windows 10 mag es überhaupt nicht, wenn das AppData-Verzeichnis per Junction auf ein anderes Laufwerk verweist. Das war bisher meine bevorzugte Methode, um Anwendungsdaten auch nach dem Zurückspielen eines Images zu erhalten. Unter Windows 10 setzt man damit aber

  • Startmenü
  • Suchfenster
  • Modern UI-Anwendungen und
  • Teile der Taskleiste

außer Funktion.

Das zurückgekehrte Startmenü überzeugt mich nicht. Ich vermisse die klare Menüstruktur, mit der sich auch verschachtelte Ordner einfach und schnell anzeigen lassen. Auch fehlt die Möglichkeit, die Systemsteuerung als Menü anzeigen zu können. So habe ich das unter Windows 8 verwendete Start 8 auch unter Windows 10 installiert. Entgegen der Aussage von Stardock konnte ich keine Kompatibilitätsprobleme feststellen, alles läuft wie in Windows 8 gewohnt. Das Upgrade auf Start 10 habe ich mir deshalb erst einmal gespart.

Die neue Oberfläche in Windows 10 ist etwas gewöhnungsbedürftig. Der schon flache Stil von Windows 8 wurde in Windows 10 weiter verflacht. Die Haken in den Kontrollkästchen kommen arg zart herüber, die in Windows 8 haben mir besser gefallen. Die Fenstertitel haben nun zwingend einen weißen Hintergrund, sowohl im aktiven als auch im inaktiven Zustand. Nur die Textfarbe ist mit schwarz und grau unterschiedlich. Man kann sich zwar die gewünschte Fensterfarbe mit einem Trick zurückholen. Das führt dann aber dazu, dass auch die inaktiven Fenster in der gleichen Fensterfarbe dargestellt werden und der Textbereich mit einem grauen Hintergrund gezeichnet wird.

Bilder werden in Windows 10 standardmäßig mit der Modern UI-App Fotos angezeigt. Wer wie ich weiter die Windows Fotoanzeige verwenden will, muss dem System durch Änderungen an der Registrationsdatenbank auf die Sprünge helfen.

Richtig überzeugen kann mich Windows 10 bisher noch nicht. Die grafische Oberfläche ist weiterhin ein großer Mischmasch von verschiedenen Technologien. Der neue hochgelobte Webbrowser Edge hat kaum Anpassungsmöglichkeiten und Cortana macht ohne Mikrofon wohl wenig Sinn. Die nützlichsten Neuerungen sind für mich bisher das Einfügen von Texten in der Eingabeaufforderung mit Strg+V und das Scrollen mit der Maus in inaktiven Fenstern. Die Scrollfunktion für inaktive Fenster musste man bisher mit KatMouse nachrüsten. Positiv ist auch, dass Kachel-Anwendungen nun auch ohne zusätzliche Hilfsmittel automatisch im Fenstermodus laufen.

Aber rechtfertigt dies das Überspringen einer ganzen Versionsnummer? Würde Microsoft das Upgrade nicht kostenlos zur Verfügung stellen, dann würden wohl viele weiter bei Windows 7 oder 8 bleiben.

SpeedCommander 15.61

By Sven on 30.07.2015 - 10:35 in SpeedCommander 15 with 8 Kommentare

SpeedCommander 15.61 ist voraussichtlich das letzte Update für die aktuelle Hauptversion. Es enthält überwiegend Fehlerkorrekturen, die alle in der Versionsgeschichte aufgelistet sind. Zu finden ist es wie gewohnt im Downloadbereich.

Die Arbeiten an SpeedCommander 16 werden nun langsam abgeschlossen. Der öffentliche Betatest wird voraussichtlich in der letzten Augustwoche starten. Wer jetzt noch eine Vollversion oder ein Upgrade von SpeedCommander 15 erwirbt, der erhält später wie üblich einen kostenlosen Freischaltcode für SpeedCommander 16.

Anwendungslokaler Einsatz der Universal CRT

By Sven on 24.06.2015 - 10:20 in Visual Studio 2015 with 1 Kommentar

Stephan T. Lavavej hat in einem Kommentar im Visual C++ Team Blog angekündigt, dass eine anwendungslokale Verwendung der Universal CRT mit der RTM-Version von Visual Studio 2015 möglich sein wird:

I’ve received confirmation that app-local deployment will be fully supported in 2015 RTM. This includes the Universal CRT, the STL, and everything else as usual. (Note that this applies to desktop apps only; store apps inherently use the framework packages.)

Damit steht einem Wechsel zum (hoffentlich) bald erscheinenden Visual Studio 2015 nicht mehr viel im Weg.

Ruhezustand im Coherence-Modus

By Sven on 17.06.2015 - 15:10 in Mac with Keine Kommentare

Auf dem iMac nutze ich Windows im Coherence-Modus. Das bedeutet, dass eine Windows-Anwendung so angezeigt wird, als wäre sie eine native Mac-Anwendung. Natürlich so, wie sie auch unter Windows zu sehen ist, aber eben ohne einen Windows-Desktop im Hintergrund.

Schon seit längerem hat mich gestört, dass sich die Schrift im Quelltextfenster von Visual Studio manchmal extrem vergrößert bzw. verkleinert, wenn man unmittelbar nach dem Aufwachen aus dem Ruhezustand mit dem Trackpad scrollen möchte. Es hat sich gezeigt, dass dies nur passiert, wenn Visual Studio im Vordergrund ist, wenn man den iMac mit Alt+Cmd+Eject in den Ruhezustand versetzt. In diesem Fall führt auch das Drücken von F4 sofort nach dem Aufwachen zum Schließen von Visual Studio. Das Problem tritt nicht auf, wenn eine Mac-Anwendung im Vordergrund ist oder vor dem Ruhezustand der Desktop angeklickt wird.

In dieser Woche bin ich das Problem endlich einmal angegangen und habe den Support von Parallels kontaktiert. Dieser hat sich bei mir eingeloggt und ein paar Sachen probiert, was aber nicht zu einer Lösung führte.

Ein intensives Nachdenken führte mich dann aber zur Ursache dieses Phänomens. Ist eine Windows-Anwendung beim Drücken von Alt+Cmd+Eject im Vordergrund, dann bekommt Windows nur die gedrückte Alt-Taste mit und setzt das entsprechende Status-Flag. Anschließend wird der iMac (und damit auch die Windows-VM) sofort in den Ruhezustand versetzt. Nach dem Aufwachen ist für Windows die Alt-Taste immer noch gedrückt, weil es vom Loslassen der Taste nichts mitbekommen hat. So führt z.B. ein Drücken von F4 zum sofortigen Schließen der Anwendung, ohne dass die Alt-Taste dazu gedrückt werden muss.

Zur Behebung dieses Problems müsste Parallels also das Drücken von Alt+Cmd+Eject erkennen und in diesem Fall auf das Weiterleiten der Alt-Taste an Windows verzichten. Darauf habe ich aber keinen Einfluss und mich deshalb auf die Suche nach einer eigenen Lösung gemacht.

Erforderlich sind dafür nur zwei Programme, die eigentlich auf jedem Mac installiert sind. Mit Karabiner ändert man die Eject-Taste auf F15. Anschließend erstellt man im BetterTouchTool für Cmd+Eject eine neue Aktion Sleep Computer, die hier als Cmd+F15 angezeigt wird. Nun kann man den iMac mit Cmd+Eject in den Ruhezustand versetzen, ohne Windows zu verwirren.

Zoom-Größe in Visual Studio permanent ändern

By Sven on 13.05.2015 - 11:00 in Visual Studio 2013 with Keine Kommentare

Die bevorzugte Schriftgröße für den Texteditor lässt sich bekanntermaßen im Einstellungsdialog ändern. Manchmal würde man aber gerne eine Zwischengröße verwenden, weil 8 Punkte zu klein und 9 Punkte zu groß sind. Allerdings werden nur Ganzzahlen akzeptiert und man muss sich für eine Größe entscheiden.

Hier könnte das Zoom-Eingabefeld am unteren linken Rand des Texteditors weiterhelfen, mit dem man die Schriftgröße viel feinstufiger anpassen kann. Könnte helfen, denn Visual Studio öffnet jedes neue Fenster mit 100%, ein Standardwert lässt sich nirgends vorgeben. Eine ständige Korrektur der Zoom-Größe bei jedem neuen Fenster ist natürlich auch keine praktikable Lösung.

Abhilfe schafft die TroutZoom-Erweiterung. Einmal installiert merkt sie sich den zuletzt eingestellten Wert und sorgt dafür, dass neue Fenster immer mit dieser Zoom-Größe geöffnet werden. Zudem werden bei einer Änderung der Größe automatisch auch alle anderen geöffneten Fenster angepasst. Der Quellcode für die Erweiterung ist auch verfügbar. Wenn man sich den Quellcode mal anschaut, dann fragt man sich, warum die 10 Zeilen nicht gleich Bestandteil von Visual Studio sind.

Visual Studio 2015 und die Universal CRT

By Sven on 12.05.2015 - 11:15 in Visual Studio 2015 with 2 Kommentare

Entwickler von portablen Programmen, die sich ohne Installation aufrufen lassen, sollten sich den Umstieg auf Visual Studio 2015 gut überlegen. Grund dafür ist die neue universelle Laufzeitbibliothek für C/C++ (Universal CRT). Bisher brauchte man nur die C/C++-Laufzeitbibliotheken msvcr120.dll und msvcp120.dll der Anwendung beilegen und die Anwendung konnte aus jedem Verzeichnis gestartet werden. Mit Visual Studio 2015 hat Microsoft die Laufzeitbibliothek in einen universellen und einen compilerabhängigen Teil aufgeteilt. Der universelle Teil ucrtbase.dll wird Bestandteil von Windows 10 und kann in Zukunft über Windows Update aktualisiert werden. Ältere Windows-Versionen können die Universal CRT ebenfalls über Windows Update einspielen, alternativ ist auch die Verwendung eines eigenständigen Installationspakets vcredist.exe möglich, das 14 MB groß ist und neben der Universal CRT auch alle anderen Laufzeitbibliotheken (inklusive MFC) enthält.

Problematisch an der ganzen Geschichte ist, dass der universelle Teil fest im Windows-Systemverzeichnis residieren soll und nicht mehr in das Anwendungsverzeichnis kopiert werden darf. Unter Windows 10 ist das nicht weiter tragisch. Der universelle Teil ist immer vorhanden, der compilerabhängige Teil kann mit der vcruntime140.dll weiter der Anwendung beigelegt werden. Auf den älteren Systemen muss der universelle Teil aber vor dem Starten der Anwendung installiert werden, entweder über Windows Update oder über das eigenständige Installationspaket. Auf dem eigenen Rechner ist das eine einmalige Sache und sollte nicht weiter stören. Der Zweck eines portablen Programms ist aber, dass man es schnell auf jedem Rechner starten kann und dafür in der Regel keine Administrator-Rechte benötigt. Mit dem Einzug der Universal CRT klappt das auf Windows XP/Vista/7 und 8 nur noch, wenn diese vom Administrator vorher installiert wurde. Ansonsten startet das Programm nicht. Man kann dies nur umgehen, indem man die C/C++- und MFC-Laufzeitbibliotheken statisch einbindet. Damit kann sich aber auch die Programmgröße wesentlich erhöhen, insbesondere wenn eine Anwendung aus mehreren Modulen besteht.

Wenn Microsoft für dieses Problem keine Lösung findet, dann werden Entwickler von portablen Programmen bei Visual Studio 2013 bleiben müssen. Man kann Visual Studio 2013 und 2015 zwar parallel installieren und in Visual Studio 2015 die Projekte auch mit den 2013-Tools erstellen. Dabei muss man aber auf die neuen Compilerfunktionen und -optimierungen verzichten.

Eine weitere Möglichkeit wäre die Verwendung der CRT/MFC aus Visual Studio 2013 in Visual Studio 2015. Dafür kopiert man die Verzeichnisse VC\atlmfc, VC\crt, VC\include und VC\lib aus 2013 nach 2015. Ein MFC-Beispielprojekt lässt sich so fehlerfrei kompilieren, beim Linken gibt es allerdings ein paar nicht aufgelöste Referenzen:

1>MainFrm.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__Init_thread_header" in Funktion ""protected: static struct AFX_MSGMAP const * __stdcall CMainFrame::GetThisMessageMap(void)" (?GetThisMessageMap@CMainFrame@@KGPBUAFX_MSGMAP@@XZ)".
1>stdafx.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__Init_thread_header".
1>MainFrm.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__Init_thread_footer" in Funktion ""protected: static struct AFX_MSGMAP const * __stdcall CMainFrame::GetThisMessageMap(void)" (?GetThisMessageMap@CMainFrame@@KGPBUAFX_MSGMAP@@XZ)".
1>stdafx.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__Init_thread_footer".
1>MainFrm.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__Init_thread_epoch".
1>stdafx.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__Init_thread_epoch".

1>MFCApplication1Doc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""void __cdecl operator delete(void *,unsigned int)" (??3@YAXPAXI@Z)" in Funktion ""public: virtual void * __thiscall CDocument::CDocumentAdapter::`scalar deleting destructor'(unsigned int)" (??_GCDocumentAdapter@CDocument@@UAEPAXI@Z)".
1>stdafx.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""void __cdecl operator delete(void *,unsigned int)" (??3@YAXPAXI@Z)".

1>ChildFrm.obj : error LNK2001: Nicht aufgelöstes externes Symbol "___std_terminate".

Nach dem Setzen der zusätzlichen Compileroptionen (Projekteinstellungen – C/C++ – Befehlszeile)

/Zc:threadSafeInit-,sizedDealloc-,implicitNoexcept-

lässt sich das MFC-Beispielprojekt ohne Fehler mit dem Compiler von Visual Studio 2015 erstellen und aufrufen. Es verwendet die C-/C++/MFC-Laufzeitbibliotheken von Visual Studio 2013 und kann somit wie gewohnt verteilt werden.

Beim weiteren Test mit SpeedCommander wurden mir noch zwei weitere Referenzen nicht aufgelöst:

1>SpeedCommander.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""void __stdcall `eh vector constructor iterator'(void *,unsigned int,unsigned int,void (__thiscall*)(void *),void (__thiscall*)(void *))" (??_L@YGXPAXIIP6EX0@Z1@Z)" in Funktion ""public: virtual void __thiscall CSpeedCommanderApp::LoadState(void)" (?LoadState@CSpeedCommanderApp@@UAEXXZ)".
1>SpeedCommander.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""void __stdcall `eh vector destructor iterator'(void *,unsigned int,unsigned int,void (__thiscall*)(void *))" (??_M@YGXPAXIIP6EX0@Z@Z)" in Funktion ""public: void * __thiscall ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > >::`vector deleting destructor'(unsigned int)" (??_E?$CStringT@_WV?$StrTraitMFC_DLL@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@QAEPAXI@Z)".

Die Ursache dafür ist, dass sich die Parameter für die vom Compiler generierten Funktionen __ehvec_ctor und __ehvec_dtor leicht geändert haben und so nicht mehr denen der VS 2013-Laufzeitbibliothek entsprechen. Zur Abhilfe fügt man die Zeilen

#define CALEETYPE __stdcall
#define __RELIABILITY_CONTRACT
#define SECURITYCRITICAL_ATTRIBUTE
#define ASSERT_UNMANAGED_CODE_ATTRIBUTE

#if defined _M_IX86
#define CALLTYPE __thiscall
#else
#define CALLTYPE __stdcall
#endif

__RELIABILITY_CONTRACT
void CALEETYPE __ArrayUnwind(
	void*       ptr,                // Pointer to array to destruct
	size_t      size,               // Size of each element (including padding)
	int         count,              // Number of elements in the array
	void(CALLTYPE *pDtor)(void*)    // The destructor to call
	);

__RELIABILITY_CONTRACT
inline void CALEETYPE __ehvec_ctor(
	void*       ptr,                // Pointer to array to destruct
	size_t      size,               // Size of each element (including padding)
	//  int         count,              // Number of elements in the array
	size_t      count,              // Number of elements in the array
	void(CALLTYPE *pCtor)(void*),   // Constructor to call
	void(CALLTYPE *pDtor)(void*)    // Destructor to call should exception be thrown
	) {
	size_t i = 0;      // Count of elements constructed
	int success = 0;

	__try
	{
		// Construct the elements of the array
		for (; i < count; i++)
		{
			(*pCtor)(ptr);
			ptr = (char*)ptr + size;
		}
		success = 1;
	}
	__finally
	{
		if (!success)
			__ArrayUnwind(ptr, size, (int)i, pDtor);
	}
}

__RELIABILITY_CONTRACT
SECURITYCRITICAL_ATTRIBUTE
inline void CALEETYPE __ehvec_dtor(
	void*       ptr,                // Pointer to array to destruct
	size_t      size,               // Size of each element (including padding)
	//  int         count,              // Number of elements in the array
	size_t      count,              // Number of elements in the array
	void(CALLTYPE *pDtor)(void*)    // The destructor to call
	) {
	_Analysis_assume_(count > 0);

	int success = 0;

	// Advance pointer past end of array
	ptr = (char*)ptr + size*count;

	__try
	{
		// Destruct elements
        while (count-- > 0)
		{
			ptr = (char*)ptr - size;
			(*pDtor)(ptr);
		}
		success = 1;
	}
	__finally
	{
		if (!success)
			__ArrayUnwind(ptr, size, (int)count, pDtor);
	}
}

am Ende der stdafx.h ein. Sie sorgen dafür, dass der Linker die vom Compiler generierten Funktionen korrekt auflösen kann. Der Unterschied zwischen der VS 2013- und VS 2015-Version liegt hauptsächlich im Typ des dritten Parameters, der von int auf size_t geändert wurde.

In einem halben Jahr wird sich wohl zeigen, wie die Verteilung der Universal CRT auf älteren Windows-Systemen vorangeschritten ist. Von den mit VS 2015 angekündigten Leistungsverbesserungen beim Erstellen von Projekten habe ich bisher noch nicht viel gemerkt, vermutlich sind meine Projekte dafür auch zu klein. Die neue CodeLens-Funktion für C++ arbeitet leider nur mit Git-Repositories und nicht mit der TFS-eigenen Versionsverwaltung. Mal schauen, ob Microsoft hier noch nachlegt. Bis dahin werde ich wohl erst einmal beim bewährten Visual Studio 2013 bleiben.

Pfadnamen bei Projekterstellung

By Sven on 27.04.2015 - 10:45 in Visual Studio 2013 with 2 Kommentare

Viele Entwickler bevorzugen für die Ausgabe von kompilierten Dateien ihre eigene Verzeichnisstruktur. Ich selbst habe jahrelang in jedem Projektordner ein Verzeichnis objs verwendet, welches noch einmal jeweils einen Unterordner für jede Konfiguration (Debug, Release, …) enthielt. Zum Löschen aller Ausgabedateien reichte in FileSearch eine Suche nach objs mit dem anschließendem Löschen aller gefundenen Ordner.

Mit dem Umstieg auf dem Mac musste ich mich aber von diesem System verabschieden. Der Grund war die stündliche automatische Sicherung mit TimeMachine. Die Ausgabedateien belegen pro Entwicklungszweig insgesamt bis zu 10 GB und ändern sich mit jedem Compilerlauf. Eine stündliche Sicherung würde auf dem Backupmedium schnell einen Engpass erzeugen. Man kann zwar Verzeichnisse von der Sicherung ausnehmen, muss diese aber genau benennen. Bei knapp 50 objs-Ordnern pro Entwicklungszweig ist das aber eher eine mühselige und fehlerträchtige Aufgabe.

Die Lösung war ein gemeinsamer Basisordner für die Ausgabedateien jedes Entwicklungszweigs auf dessen oberster Ebene. Die Ausgabe- und Zwischenverzeichnisse für jedes Projekt änderten sich so von

objs\Release_x64

auf

..\..\!IntDir\SpeedCommander\$(ProjectName)\Release_x64\

Anschließend mussten in der TimeMachine nur noch zwei !IntDir-Verzeichnisse für die Dev/Main-Entwicklungszweige als Ausnahme eingetragen werden.

Ein eher unschöner Nebeneffekt waren allerdings die relativen Bezüge in den Pfadnamen für die Ausgabedateien im Ausgabefenster. Statt

2>     Bibliothek "objs\Release_x64\CxLib72.lib" und Objekt "objs\Release_x64\CxLib72.exp" werden erstellt.
2>  CxLibrary.vcxproj -> D:\Visual C++\Dev\Libraries\CxLibrary\objs\Release_x64\CxLib72.dll
...
3>  sqc.vcxproj -> D:\Visual C++\Dev\SpeedCommander\sqc\objs\Release_x64\sqc.exe
3>  Done Adding Additional Store
3>  Successfully signed: D:\Visual C++\Dev\SpeedCommander\sqc\objs\Release_x64\sqc.exe

wurde im Ausgabefenster nun

2>     Bibliothek "..\..\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.lib" und Objekt "..\..\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.exp" werden erstellt.
2>  CxLibrary.vcxproj -> D:\Visual C++\Dev\Libraries\CxLibrary\..\..\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.dll
...
3>  sqc.vcxproj -> D:\Visual C++\Dev\SpeedCommander\sqc\..\..\!IntDir\SpeedCommander\sqc\Release_x64\sqc.exe
3>  Done Adding Additional Store
3>  Successfully signed: D:\Visual C++\Dev\SpeedCommander\sqc\..\..\!IntDir\SpeedCommander\sqc\Release_x64\sqc.exe

angezeigt. Aber auch nach knapp sechs Monaten konnte ich mich an diese Darstellung nicht so recht gewöhnen.

Auf der Suche nach einer Lösung bin ich auf diese Seite gestoßen, auf der die Funktion $([System.IO.Path]::GetFullPath(“)) genannt wird. In den Tiefen der MSBuild-Umgebung habe ich dann die Datei Microsoft.cpp.targets gefunden, in der die Werte für Ausgabe- und Zwischenverzeichnis validiert werden. Gleich nach der Prüfung auf den abschließenden Backslash habe ich in Zeile 34 die folgenden Zeilen eingefügt:

  <PropertyGroup>
    <IntDir Condition="!$([System.IO.Path]::IsPathRooted('$(IntDir)'))">$([System.IO.Path]::GetFullPath('$(ProjectDir)$(IntDir)'))</IntDir>
    <OutDir Condition="!$([System.IO.Path]::IsPathRooted('$(OutDir)'))">$([System.IO.Path]::GetFullPath('$(ProjectDir)$(OutDir)'))</OutDir>
    <OutputPath>$(OutDir)</OutputPath>
  </PropertyGroup>

Diese sorgen dafür, dass die aus dem Projektverzeichnis und den dazu relativen Ausgabe- und Zwischenverzeichnissen zusammengesetzten Pfade keine überflüssigen Verweise mehr enthalten.

Beim nächsten Durchlauf war die Anzeige im Ausgabefenster nun bedeutend freundlicher:

2>     Bibliothek "D:\Visual C++\Dev\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.lib" und Objekt "D:\Visual C++\Dev\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.exp" werden erstellt.
2>  CxLibrary.vcxproj -> D:\Visual C++\Dev\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.dll
...
3>  sqc.vcxproj -> D:\Visual C++\Dev\!IntDir\SpeedCommander\sqc\Release_x64\sqc.exe
3>  Done Adding Additional Store
3>  Successfully signed: D:\Visual C++\Dev\!IntDir\SpeedCommander\sqc\Release_x64\sqc.exe

Erwähnenswert ist vielleicht noch, dass die Funktion $([System.IO.Path]::GetFullPath(“)) auch in den Befehlszeilen für Buildereignisse verwendet werden kann. Zudem sollte man damit rechnen, dass die Änderungen in Microsoft.cpp.targets beim nächsten VS-Update überschrieben werden können und dann neu durchgeführt werden müssen.

Nachtrag vom 11.05.2015

In der Zwischenzeit hat sich gezeigt, dass das Voranstellen des Projektpfades negative Auswirkungen auf das Neuladen von Projektdateien (z.B. nach dem Zurücknehmen von Änderungen) hat. Ich habe die beiden Zeilen nun so geändert, dass das Projektverzeichnis nur vorangestellt wird, wenn der Pfadname von In/OutDir relativ und nicht absolut ist.

SpeedCommander 15.60

By Sven on 22.04.2015 - 15:45 in SpeedCommander 15 with Keine Kommentare

Eine neue Version von SpeedCommander 15 kann heruntergeladen werden. Die Symbole für Menüs und Symbolleisten im Office 2013-Stil wurden vervollständigt. Für jedes Symbole des Office 2010-Stils sollte es nun auch eine Variante im Office 2013-Stil geben. Im Zuge dieser Überarbeitung habe ich auch die Office 2010-Symbole für Gehe zu, Hauptordner und Basisordner etwas angepasst. Beim Trennen und Erstellen von Multivolume-Archiven sind neue Größeneinheiten für GiB und TiB hinzugekommen. Die Höhe für die Kombinationsfelder in der Laufwerksleiste ist im Einstellungsdialog auf der Seite Erweitert – Spezielles anpassbar. So können auf Wunsch mehr Laufwerke im aufgeklappten Kombinationsfeld sichtbar angezeigt werden.

Zudem gab es wieder ein paar kleine Fehlerbehebungen, die alle in der Versionsgeschichte aufgelistet sind.

Vom PC zum Mac

By Sven on 03.03.2015 - 14:55 in Mac with 11 Kommentare

Etwas mehr als fünf Jahre ist es nun her, als ich den ersten Kontakt zur Apple-Welt hergestellt habe. Aus dem Wunsch, in die OS X-Programmierung hineinzuschnuppern, ist bis heute leider noch nicht viel geworden. Ich habe zwar mehrere Anläufe unternommen, mit Objective C bin ich aber nie richtig warm geworden. Mittlerweile gibt es Swift und vielleicht auch einen neuen Versuch.

Im Sommer 2011 folgte dann ein MacBook Air. Die ersten Versuche zur Abbildung meiner Windows-Arbeitsumgebung machte ich mit VMware, das kannte ich vom PC. Recht schnell folgte dann aber der Wechsel zu Parallels. Parallels merkt man an, dass es direkt für den Mac entwickelt wird, es passt sich einfach besser in die Umgebung ein. Zur Entwicklung taugte das Air aufgrund des doch recht schwachen Core2Duo-Prozessors nicht so recht. Was aber richtig gut funktionierte, war das Schreiben der Hilfe für SpeedCommander 14. Mit dem leichten Air war es ein Vergnügen, die Hilfe  auf der sonnigen Terrasse komplett zu überarbeiten. Das nicht vorhandene DVD-Laufwerk und der fehlende Ethernet-Anschluss fielen überhaupt nicht negativ auf.

Ein Jahr später stellte Apple dann das erste Retina-MacBook vor. Die Annehmlichkeiten eines hochauflösenden Displays kannte ich mittlerweile von iPhone 4 und iPad 3. So konnte ich es kaum erwarten, dies auch im Computerbereich zu erleben. Das MacBook Pro war mit i7-Prozessor und 16 GB RAM leistungsstark genug für die Windows-Entwicklung. Leider waren Windows 7, Outlook 2003 und Visual Studio 2008 nicht wirklich für HiDPI-Bildschirme ausgelegt, so dass ich Windows mit normaler Auflösung betreiben musste. Das betraf damals aber auch etliche Mac-Anwendungen, für die HiDPI ebenfalls Neuland war.

Im Januar 2014 war dann mit dem UP2414Q der erste 4K-Monitor von Dell für PCs lieferbar. Mittlerweile war ich auf Windows 8, Outlook 2013 und Visual Studio 2013 umgestiegen, die auf dem MacBook Pro ziemlich problemlos unter HiDPI liefen. So schien die Zeit endlich reif für einen 4K-Monitor am täglichen Arbeitsplatz. Nach dem ersten Anschließen kam aber schnell Ernüchterung auf. Für die Anzeige von 3840×2160 in 60 Hz musste der MST-Modus aktiviert werden, bei dem sich der Monitor als zwei Monitore mit jeweils 1920×2160 zu erkennen gibt. Ein Bug im Intel-Grafiktreiber sorgte aber dafür, dass linke und rechte Bildschirmseite vertauscht angezeigt wurden. Das würde sich zeitnah nur durch eine zusätzliche AMD/Nvidia-Grafikkarte abstellen lassen. Soweit kam es aber gar nicht.

Ich arbeite unter VMware viel mit virtualisierten Umgebungen. So kann man ohne weiteren Hardwareaufwand schauen, wie sich SpeedCommander auf älteren Windows-Versionen verhält und zur Not auch mal schnell den Debugger zu Hilfe nehmen. Leider ist VMware Workstation überhaupt nicht an die Verwendung in einer HiDPI-Umgebung angepasst. Das führt dazu, dass bei einer 200%-Skalierung die virtuellen Maschinen 1:1 angezeigt werden und somit nur halb so groß sind. Man müsste also in jeder virtuellen Maschine ebenfalls eine 200%-Skalierung aktivieren, um diese halbwegs normal verwenden zu können. Ältere Windows-Versionen sind damit aber hoffnungslos überfordert. Man bräuchte also für ältere Versionen wieder einen zweiten Rechner mit einem normalen Bildschirm. In Parallels lässt sich mit einer einzigen Einstellung festlegen, ob die virtuelle Maschine die native Auflösung verwenden soll oder eine skalierte. Ohne eine solche Option kann mit VMware in einer HiDPI-Umgebung nicht vernünftig gearbeitet werden.

Aber nicht nur VMware machte Probleme, auch einige andere Anwendungen hatten mit dem 4K-Bildschirm Schwierigkeiten. So packte ich den Monitor am nächsten Tag wieder in die Kiste und schickte ihn zurück. Stattdessen holte ich mir einen 27″-Bildschirm mit 2560×1440 Pixeln und fand mich damit ab, dass ein 4K-Bildschirm an einem stationären Rechner für absehbare Zeit ein unerfüllter Wunsch bleiben würde.

Im Oktober stellte Apple dann den neuen 5k-iMac vor. Meine erste Begeisterung wich schnell der Einsicht, dass ein solches Gerät nicht in mein Windows-Arbeitsumfeld passen würde. Die Gedanken ließen mich aber nicht los und ich habe gemerkt, dass ich die Sache aus einem falschem Blickwinkel betrachtete. 5120×2880 ist bei gleicher Bildschirmgröße exakt viermal so groß wie meine bisherige Auflösung (quasi das HiDPI-Optimum) und der i7-Prozessor ist genauso leistungsstark wie mein aktueller Rechner. Die Erfahrungen mit Parallels auf dem MacBook Pro haben gezeigt, dass Windows-Virtualisierungen problemlos funktionieren. Zudem habe ich in den fünf Jahren OS X als angenehmes Betriebssystem kennengelernt, auf dem man sich wohlfühlen kann.

Und so habe ich mir den 5k-iMac bestellt und bin seit November 2014 vollzeitlicher Mac-Benutzer. In den ersten Tagen habe ich noch Outlook 2013 verwendet, bin dann aber recht zügig auf Apple Mail umgestiegen. Über den Zwischenweg Outlook 2011 für Mac und mit Hilfe des OLM File Converters konnte ich alle Mails seit 1997 ohne Verlust übernehmen. Visual Studio 2013 und SpeedCommander laufen in einer Windows 8-VM unter Parallels im Coherence-Modus und integrieren sich so fast nahtlos in die OS X-Umgebung. Zudem habe ich noch weitere virtuelle Maschinen (z.B. Windows XP oder Windows 7) im Einsatz, die sich bei Bedarf im normalen Fenstermodus starten lassen.

Die Arbeit an einem HiDPI-Bildschirm macht extrem viel Spaß. Texte sind gestochen scharf und wirken wie gestanzt. Gerade bei der Entwicklung hat man ja viel mit Texten zu tun. Setzt man sich dann mal wieder an den alten Bildschirm, dann wirkt alles auf einmal recht pixelig.

In den letzten Monaten hat sich nun ein neues Arbeitsumfeld ergeben, das ich nicht mehr missen möchte. Die Time Machine sorgt für stündliche Backups, die dann im Laufe der Zeit zu täglichen Backups der letzten 30 Tage und zu wöchentlichen Backups der letzten Monate konsolidiert werden. Dafür muss man nur eine externe Festplatte anschließen, einen Schalter umlegen und bei Bedarf noch ein paar Ordner (z.b. die kompilierten Zwischendateien) ausnehmen. Alles andere geschieht automatisch. Apple Mail zeigt beim Klick auf eine eMail auch den zur eMail passenden Verlauf ordnerübergreifend an, das erspart häufig ein Suchen. Und muss man trotzdem doch einmal suchen, dann geschieht dies dank Indizierung blitzschnell. Kontakte und Termine werden über die iCloud automatisch auf iPhone und iPad synchronisiert, zusätzliche Anwendungen sind hier nicht nötig. Pages und Numbers haben Word und Excel ersetzt. Nachrichten und SMS kann ich nun direkt am Mac tippen und lesen. Auch das Anrufen und Angerufenwerden ist möglich, ohne das iPhone aus der Tasche nehmen zu müssen. Es funktioniert einfach alles ohne zusätzliches Basteln. Daran muss man sich als gelernter Windows-Anwender aber auch erst einmal gewöhnen und vor allem auch darauf einlassen wollen.

Der Mac Mini von 2009 ist übrigens auch wieder im Einsatz. Aufgerüstet mit Speicher und SSD läuft auf ihm mein TFS2013 in einer Parallels-VM. Mit 10 Watt im Leerlauf ist der Mini äußerst sparsam und vor allem extrem leise. Abends legt er sich schlafen und wacht unter der Woche morgens selbst wieder auf. Über ein VPN kann man auch von außerhalb darauf zugreifen und ist bei der Entwicklung nicht mehr nur auf das Büro angewiesen.

Trotz des neuen Arbeitsumfelds wird sich an meiner eigentlichen Arbeit aber nichts ändern. Die Entwicklung von SpeedCommander für Windows steht selbstverständlich weiter im Vordergrund. Es könnte aber durchaus passieren, dass die nächsten Versionen noch etwas benutzerfreundlicher werden.

Breite des blinkenden Textcursors ändern

By Sven on 29.01.2015 - 14:30 in Windows with 1 Kommentar

HiDPI-Bildschirme sind eine feine Sache. Wenn man einmal damit gearbeitet hat, dann möchte man nicht mehr zurück. Ein nicht ganz so schöner Nebeneffekt ist aber die schlechtere Erkennbarkeit des blinkenden Cursors bei der Eingabe von Texten. Der Textcursor ist für die hohe Auflösung einfach zu fein und auf dem Bildschirm nur schwer auszumachen.

Glücklicherweise lässt sich das in wenigen Schritten ändern. In der Systemsteuerung öffnet man das Center für erleichterte Bedienung und wechselt dann zu Erkennen von Bildschirmobjekten erleichtern. In der Sektion Erkennung von Elementen auf dem Bildschirm erleichtern lässt sich die Breite des blinkenden Cursors anpassen.

Der Standardwert ist 1. Bei einer 200%-Skalierung müsste man den Wert auf 2 ändern, um die gleiche logische Breite wie auf einem normalen Bildschirm zu erhalten. Meine bevorzugte Variante bei 200% ist 3.

Top