Vorgespieltes Service Pack
Auf meinem Entwicklungssystem verwende ich immer noch Windows XP mit Service Pack 1, da der VC6 mit den Debugsymbolen vom Service Pack 2 nichts mehr anfangen kann. Zum Testen einer Funktion musste ich mir den Microsoft RAW Viewer installieren, der aber gleich bei der Installation das fehlende SP2 bemängelte und die Installation abbrach.
Die Versionsnummer des installierten Service Packs wird in der Registrationsdatenbank unter dem Schlüssel
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows]
im Wert CSDVersion als Vielfaches von 256 (0x100) gespeichert. Nach dem Ändern dieses Wertes auf 512 (0x200) und einem anschließenden Reboot war das Installationsprogramm des Microsoft RAW Viewers vom Vorhandensein des SP2 überzeugt und ließ sich problemlos installieren.
Windows mit Ausblick
„Vista is the new Windows“ war wohl die unterschwellige Botschaft, die in den CDs von Brian Valentine und Kevin Johnson versteckt gewesen sein muss. Doch wer steckt dahinter? Arnold Schwarzenegger, Alta Vista oder gar heise online?
Visual Studio 2005 (CTP Juni)
In den letzten Tagen habe ich mir die aktuelle Community Technology Preview vom Visual Studio 2005 installiert und damit etwas Zeit verbracht. Trotz einiger immer noch existierender Produktivitätsbremsen macht das Arbeiten mit VS 2005 zusehends mehr Spaß. Verantwortlich dafür sind einige nette Funktionen:
1. Projekte werden parallel erzeugt
Projekte, die unabhängig voneinander sind, werden auf Mehrprozessor-Maschinen parallel kompiliert. Die Anzahl der zeitgleich erzeugten Projekte ist abhängig von der Anzahl der Prozessoren. Auf meinem P4 mit Hyperthreading gibt es zwei logische Prozessoren, damit werden also zwei Projekte nebeneinander kompiliert. Beim nächsten Rechnerupdate lohnt es sich also wirklich einmal, einen Blick auf die Xeon-Prozessoren zu werfen.
2. Visual Assist ist nun auch für Visual Studio 2005 verfügbar
Die letzten Builds von Visual Assist unterstützen nun endlich auch das Visual Studio 2005. Wenn man sich einmal an Visual Assist gewöhnt hat, dann kann man ohne kaum noch arbeiten und fühlt sich sehr verlassen.
3. Hervorragender Debugger
Der Debugger ist eines der Sahnestücke in VS 2005, das Betrachten von Variablen während des Debuggens ist ein Traum. Man zeigt nur noch mit der Maus auf die entsprechende Variable und der Debugger zeigt eine Liste mit den Eigenschaften. Zeigt man wieder auf ein Objekt, dann wird auch dieses aufgeklappt und dessen Eigenschaften werden angezeigt:
4. Automatisches Einfügen eines Manifests
Damit eine Anwendung unter XP auch im entsprechenden Design angezeigt wird, muss sie ein Manifest enthalten. Bisher hat man das Manifest als Entwickler immer in die Ressourcendatei eingebunden. VS 2005 führt nun einen neuen Linker-Schalter ein, der ein Manifest auf Wunsch automatisch in die Programmdatei aufnimmt. In einer normalen Anwendung hat das Manifest immer die ID „1“ , in einer Dll (z.B. einer Explorer-Erweiterung) dagegen die „2“. Der Linker kümmert sich automatisch um die richtige ID, die folgenden Zeilen reichen völlig aus.
Diese Zeilen habe ich in eine Header-Datei gesteckt, die ohnehin in jedem Projekt eingebunden wird und allgemeine Eigenschaften definiert, die für alle Projekte gelten. Entsprechend der jeweiligen Plattform wird immer gleich das korrekte Manifest eingebunden, man muss sich nun nicht mehr mit Manifesten in Ressourcen herumärgern.
#if _MSC_VER >= 1400
#ifdef _M_IX86
#pragma comment(linker,"/manifestdependency:\"type='win32' " \
"name='Microsoft.Windows.Common-Controls' " \
"version='6.0.0.0' " \
"processorArchitecture='x86' " \
"publicKeyToken='6595b64144ccf1df' " \
"language='*'\"")
#endif
#ifdef _M_AMD64
#pragma comment(linker,"/manifestdependency:\"type='win32' " \
"name='Microsoft.Windows.Common-Controls' " \
"version='6.0.0.0' " \
"processorArchitecture='amd64' " \
"publicKeyToken='6595b64144ccf1df' " \
"language='*'\"")
#endif
#ifdef _M_IA64
#pragma comment(linker,"/manifestdependency:\"type='win32' " \
"name='Microsoft.Windows.Common-Controls' " \
"version='6.0.0.0' " \
"processorArchitecture='ia64' " \
"publicKeyToken='6595b64144ccf1df' " \
"language='*'\"")
#endif
#endif
Unkaputtbar
Seit meinem Umstieg auf Visual C++ vor knapp 10 Jahren programmiere ich mit der MFC (Microsoft Foundation Classes), und im Laufe der Jahre habe ich die MFC als eine verlässliche und robuste Bibliothek kennengelernt. Die MFC deckt alle Grundlagen für eine moderne Windows-Anwendung ab, kleine oder größere Erweiterungen findet man entweder im Netz oder programmiert man sich selbst.
In dem einen oder anderen Gespräch mit C++Entwicklern konnte ich feststellen, dass sich mit dem nahenden Longhorn und der Werbung für die schöne .nette Welt gewisse Ängste entwickeln, dass man in naher Zukunft mit C++ und der MFC nur noch im Regionalexpress fährt und vom .NET-Transrapid bald überholt wird. Ich selbst teile diese Ansicht nicht, denn auch in Longhorn wird .NET ein Aufsatz auf dem Betriebssystem bleiben. Das Windows-API wird natürlich weiter Bestand haben, da einerseits das gesamte Betriebssystem darauf aufbaut und Microsoft sich auch nicht erlauben kann, mit Longhorn einfach alle Brücken zu „alter“ Software zu kappen. In diesem Fall müssten sie das gesamte Betriebssystem auf gänzlich neue Füße stellen, und das kann selbst Microsoft sich nicht leisten.
Auch Avalon und seine Beschreibungssprache XAML hat für den normalen Anwendungsprogrammierer keine wirkliche Bedeutung. Oder glaubt tatsächlich jemand, man könnte einen Dateimanager oder ein Packprogramm mit einer XML-Sprache programmieren? Das nun auf später verschobene WinFS wird sicher auch aus nativen Anwendungen ansprechbar sein, ansonsten wäre wohl keine Integration in den Explorer möglich.
Steve Teixeira hat nun einen Ausblick auf die Zeit nach Visual Studio 2005 gegeben, und dieser dürfte den einen oder anderen zweifelnden C++/MFC-Programmierer doch sehr erfreuen:
MFC continues to be the C++ application framework of choice for many developers because the breath and depth of support that MFC provides for the Microsoft platforms remains unmatched by other frameworks. Visual Studio 2005 makes it possible for the C++ developer to leverage existing C++ code, the strengths of MFC, and the advantages of .NET, all within a single application.
Looking beyond Visual Studio 2005, C++ developers should expect deepened integration between MFC and the .NET framework. After the release of Windows Longhorn, Microsoft intends to add MFC support for key Longhorn APIs and features. Microsoft also intends to support the Avalon user interface framework in MFC, providing MFC developers with a bridge to the future of platform user interface design. In essence, as the platform evolves, developers can look forward to seeing MFC updated to leverage the latest managed and native APIs and frameworks.
MFC developers have access to more frameworks than any other type of developer on the platform. As such, MFC developers are free to leverage the best from all worlds as it makes business and technological sense to do so. Microsoft fully expects to support this capability into the foreseeable future.
Also, auf die nächsten 10 Jahre!
AddIns in SpeedCommander 11 (Teil 1)
Seit einigen Jahren wünschen sich die Anwender immer wieder eine Pluginschnittstelle im SpeedCommander. Bisher hatte ich mich immer etwas dagegen gesperrt, weil ich vom Pluginkonzept anderer Anwendungen nicht ganz überzeugt war. Ein Plugin muss sich in die Anwendung integrieren können, es muss Befehle zur Verfügung stellen und es muss auch die Möglichkeit bestehen, diese Befehle aus Menüs und Symbolleisten aufzurufen. Die Konfiguration sollte möglichst einfach gehalten werden und nicht über viele Dialoge verstreut sein.
Nach vielen Überlegungen bin ich auf das AddIn-Konzept von Microsoft gestoßen, das unter anderem in den Office-Produkten und in Visual Studio eingesetzt wird. Diese AddIns können mit jeder Sprache entwickelt werden, mit der sich COM-Objekte erzeugen lassen. Dies ist ein großer Vorteil gegenüber dem klassischen Dll-Konzept mit einem Satz von exportierten Funktionen, da sich auch mit Visual Basic und dem .NET-Framework COM-Objekte programmieren lassen. Beim klassischen Dll-Konzept bleiben Visual Basic und .NET nämlich außen vor.
Ein AddIn ist ein COM-Objekt und bietet verschiedene Schnittstellen an. Zwingend erforderlich ist lediglich die Schnittstelle IDTExtensibility2, welche aus fünf Methoden besteht:
- OnConnection
- OnStartupComplete
- OnBeginShutdown
- OnDisconnection
- OnAddInsUpdate
OnConnection wird aufgerufen, wenn das AddIn geladen wird. Das AddIn erhält jeweils einen Zeiger auf das Application-Interface von SpeedCommander und auf das Interface des AddIn-Objektes. Dazu bekommt es noch die Information, wie das AddIn geladen wurde. Dies kann einerseits gleich beim Starten von SpeedCommander geschehen oder später durch nachträgliche Installation oder Aktivierung des AddIns. Über das Application-Interface kann das AddIn später auf das umfangreiche Objektmodell von SpeedCommander zugreifen und z.B. neue Befehle oder eigene Symbolleisten erzeugen.
Wenn SpeedCommander komplett initialisiert wurde, wird bei allen geladenen AddIns die Methode OnStartupComplete aufgerufen. Hier kann das AddIn Funktionen aufrufen, die bei der Initialisierung eine Interaktion mit dem Benutzer erfordern. OnBeginShutdown wird aufgerufen, bevor SpeedCommander beendet wird. Das AddIn kann an dieser Stelle z.B. seine Einstellungen speichern.
Bevor das AddIn entladen wird, ruft SpeedCommander die Methode OnDisconnection auf. Dem AddIn wird hier auch der Grund des Entladens mitgeteilt. Das AddIn kann somit erkennen, ob es z.B. vom Anwender deinstalliert wurde und somit seine Einstellungsdaten löschen kann.
Die fünfte Methode OnAddInsUpdate wird aufgerufen, wenn ein anderes AddIn geladen wird. Wenn z.B. die AddIns A und B bereits geladen sind und später das AddIn C geladen wird, dann ruft SpeedCommander die Methode OnAddInsUpdate von AddIn A und B auf. Ist z.B. ein AddIn abhängig von einem anderen, so kann das AddIn hier prüfen, ob das andere AddIn geladen oder entladen wird.
Aus die Maus
Wie ich gestern erfahren musste, ist die sehr beliebte (und in meinen Augen beste Maus) MX700 von Logitech kaum noch erhältlich. In allen führenden Online-Shops ist sie nicht mehr gelistet, vermutlich wurde die Produktion zugunsten des Nachfolgemodells MX1000 eingestellt. Leider besitzt die MX1000 gegenüber der MX700 ein paar doch sehr störende Mängel. Der Unterboden ist nicht vollkommen plan, so dass die Maus ohne ein zusätzliches Mauspad unangenehm kippelt. Auch die gewohnten Logitech-Treiber sind mit der MX1000 nicht mehr verwendbar, die neuen haben sich bei mir in der Praxis überhaupt nicht bewährt. Ich nutze immer noch die Version 9.73, dies ist die letzte, in der man mit dem Mausrad noch in inaktiven Fenstern scrollen kann. In allen späteren Versionen ist das nicht mehr möglich.
Glücklicherweise steht die Ware in unserem lokalen Elektronik-Markt gern etwas länger im Regal, und so konnte ich mir noch zwei Exemplare für schlechte Zeiten sichern. Es waren übrigens noch mehr als genug da.
Quellcodestatistik
Es ist immer wieder interessant, wieviel Zeilen Quellcode sich hinter einem Projekt verstecken; es ist aber recht mühsam, dies Datei für Datei zusammenzurechnen. Für das Visual Studio gibt es ein AddIn, das einem diese Arbeit abnimmt. Ich habe den LineCounter mal auf den sich in Entwicklung befindlichen SpeedCommander 11 inklusive aller enthaltenen Module (aber ohne MFC) angesetzt. Folgende Resultate kamen dabei heraus:
| Projekttyp | Zeilen | Code | Kommentare | Gemixt | Leer |
|---|---|---|---|---|---|
| Anwendungen & MxLibs | 647349 | 376359 (58%) | 172428 (26%) | 18161 (2%) | 116723 (18%) |
| FxLibs (Sync & Search) | 31064 | 21578 (69%) | 5756 (18%) | 1178 (3%) | 4908 (15%) |
| CxLibs (Packer) | 165323 | 113445 (68%) | 27087 (16%) | 4367 (2%) | 29158 (17%) |
| 843736 | 511382 (61%) | 205271 (24%) | 23706 (3%) | 150789 (18%) |
In der ersten Zeile ist mein Code aufgelistet, die anderen beiden Zeilen zeigen die von Rainer übernommenen Quellen. Wenn man sich überlegt, dass Windows XP aus rund 38 Millionen Quellcodezeilen besteht, dann ist der SpeedCommander mit einer knappen Million mittlerweile doch schon ein ziemlich großes Projekt geworden.
Offener Brief
Vermutlich wurden Sie auf diesen Beitrag verwiesen, weil Sie bei einem Treffen ein Cola-Getränk (z.B. Pepsi Cola, Cola Cola oder Premium Cola) bestellt haben. Ihr Gegenüber möchte Sie darauf aufmerksam machen, dass Sie diese Getränke aus den folgenden Gründen vermeiden sollten:
Die genannten Getränke benutzen Rezepte, die von den Herstellern geheimgehalten werden. Daher können diese Getränke mit freien Rezepten nur schwer und evtl. unvollständig erzeugt werden. Außerdem besteht bei diesen proprietären Getränken die Gefahr, dass die Hersteller ihre Dominanz ausnutzen, um z.B. den gesamten Getränkeabsatz zu kontrollieren und die Verbraucher abhängig zu machen.
Die Person würde sich freuen, wenn Sie stattdessen auf OpenCola umsteigen würden. Wie Sie dies tun können, haben wir für Sie in einer Anleitung zusammengefasst.
Die Nutzung von proprietären Getränken übt Druck auf andere Nutzer aus, ebenfalls proprietäre Getränke zu verwenden und dadurch ihre Freiheit aufzugeben. Ihr Verhalten führt dazu, dass ihnen keine Alternativen bleiben. Es wäre deshalb nett, wenn Sie die Benutzung Ihrer Getränke zur Kommunikation mit anderen Menschen überdenken würden.
Im Namen der freien OpenCola Gemeinde
Der Unterzeichner
Inspiriert durch deshalbfrei.org.
PS: Dieser Beitrag enthält sehr viel Ironie, die aber nicht besonders gekennzeichnet ist.
TweakUI für Windows XP x64
Tweak UI von Microsoft ist in der Regel das erste Tool, welches ich nach einer frischen Windows-Installation benötige und installiere. Bei Windows XP x64 ist das aber leider nicht möglich, der Aufruf der 32bit-Version wird mit der folgenden Meldung quittiert:
Tweak UI may not be run under an emulator. Use the version of Tweak UI designed for your processor.
Das würde ich gerne, allerdings wird bei Microsoft nur die Itanium-Version angeboten, von der x64-Version fehlt jede Spur. In den Tiefen des Netzes habe ich gestern zufällig die Version 2.10 vom August 2003 als native x64-Version gefunden. Der Download zeigt zwar nicht auf einen Microsoft-Server, allerdings ist die Datei mit einer gültigen MS-Signatur versehen. Funktionieren tut sie übrigens auch.
Kuriose Rechtschreibprüfung
Wirklich interessant, was die Rechtschreibprüfung von Word 2003 als Korrektur für „SQX-Archiv“ vorschlägt:
