C++/ATL
VS 2008: C/C++-Laufzeit selbst kompilieren
Wer möchte, dass sich seine Anwendungen ohne Installation von einem USB-Stick starten lassen, der hat ab Visual Studio 2005 schlechte Karten. Bis einschließlich Visual Studio .NET 2003 konnte man die benötigten C/C++-Laufzeitbibliotheken sowie die MFC einfach so dazupacken, ab Visual Studio 2005 beharren diese Module nun auf einer separaten Installation in das WinSxS-Verzeichnis. Es gibt zwar auch die Möglichkeit, anwendungslokale Manifeste zu verwenden, aber das ist mir ehrlich gesagt viel zu umständlich. Die beste und vor allem stressfreiste Lösung für einen nativen Entwickler sind immer noch zwei Dlls (oder drei bei Verwendung der STL), die man einfach in das Anwendungsverzeichnis kopiert.
Der Aufwand dafür ist gar nicht so groß. Man muss lediglich die C/C++-Laufzeit sowie die MFC ohne Manifest kompilieren und hat dann alle Möglichkeiten, die man vor Visual Studio 2005 auch hatte. Man muss aber darauf achten, dass man keine Bibliotheken verwendet, die man nur als Binärversionen zur Verfügung hat und die bereits ein Manifest enthalten. Viele Entwickler schrecken aber vor dem Kompilieren zurück, daher möchte ich euch an dieser Stelle eine Schritt-für-Schritt-Anleitung aufzeigen. In diesem Artikel geht es erst einmal um die C/C++-Laufzeit, die MFC nehmen wir uns das nächste Mal vor.
Alle Änderungen spielen sich unterhalb des VC-Verzeichnisses ab, daher sind alle folgenden Pfadangaben relativ zum VC-Verzeichnis (VisualStudioInstallDir\VC).
1. Sicherung
Der erste Schritt ist die Sicherung der originalen Dateien. Bei mir hat es sich bewährt, im VC-Verzeichnis zwei neue Verzeichnisse !orig und !changed anzulegen. In das !orig-Verzeichnis werden zuerst die Verzeichnisse
- atlmfc
- crt
- include
- lib
kopiert, damit wir uns ungestört an den anderen Dateien vergehen können. So erhalten wir eine originale und eine angepasste Konfiguration, die sich dann schnell durch das Verschieben der vier Ordner austauschen lassen.
2. Anpassen der Dateien
Für eine manifestlose Laufzeit müssen wir erst einmal die Manifestdefinitionen entsorgen. Diese befinden sich in den Dateien crtdefs.h und use_ansi.h. Beide Dateien kommen doppelt vor, einmal in include und einmal in crt\src. In crt\src\crtdefs.h suchen wir die Zeile 118
#include <crtassem.h>
und kommentieren danach bis einschließlich Zeile 173 alles aus. Bitte unbedingt auf die einzelnen #endif-Kommentare achten, die ein einfaches /* */ erschweren. Bei include\crtdefs.h erfolgt das gleiche noch einmal, hier zwischen den Zeilen 93 und 147. Analog erfolgen die Änderungen auch in crt\use_ansi.h (Zeilen 59 bis 113) und include\use_ansi.h (Zeilen 53 bis 107).
3. Vorbereitung der .DEF-Dateien
Die .def-Dateien für die nötigen Exporte sind bereits im crt\src-Verzeichnis vorhanden, allerdings mit etwas kryptischen Namen. Wir benennen die Dateien wie folgt um:
sample_m.def -> msvcmrt.def sample_p.def -> msvcprt.def sample_u.def -> msvcurt.def sampld_m.def -> msvcmrtd.def sampld_p.def -> msvcprtd.def sampld_u.def -> msvcurtd.def
In den Verzeichnissen crt\src\intel und crt\src\amd64 befinden sich jeweils zwei weitere Dateien, die auch umbenannt werden müssen:
_sample_.def -> msvcrt.def _sampld_.def -> msvcrtd.def
Nun müssen wir uns vernünftigen Namen für die Laufzeit-Dlls ausdenken. Ganz wichtig ist, dass wir hier einen eigenen Namen wählen, um Komplikationen mit den originalen (MsVcr90.dll) sowie anderen angepasste Dateien zu vermeiden. Als Beispiel verwenden wir MyVcr90.dll, die Modulnamen in den Definitionsdateien werden nun mit einem Texteditor wie folgt angepasst:
msvcmrt.def: MyVcm90 msvcmrtd.def: MyVcm90d msvcprt.def: MyVcp90 msvcprtd.def: MyVcp90d msvcurt.def: MyVcm90 msvcurtd.def: MyVcm90d
Nun noch die vier Dateien aus den intel\amd64-Verzeichnissen:
msvcrt.def: MyVcr90 msvcrtd.def: MyVcr90d
Damit das Kompilieren der MFC später nicht mit einem Fehler beendet wird, ergänzen wir die beiden msvcrtd.def-Dateien noch um diese vier Zeilen:
_strdup_dbg _fullpath_dbg _wcsdup_dbg _wfullpath_dbg
MyVcr90.dll steht hier aber wirklich nur als Platzhalter, ihr solltet das nach dem ersten funktionierenden Testlauf durch euren Wunschnamen ersetzen.
4. Vorbereitung der Ressourcendateien
Nun müssen noch die Ressourcendateien in crt\src umbenannt
_sample_.rc -> MyVcr90.rc sample_m.rc -> MyVcm90.rc sample_p.rc -> MyVcp90.rc
und die Versionsinfos in diesen drei Dateien angepasst werden.
5. Anpassung des Makefiles
Jetzt fehlt eigentlich nur noch die Anpassung des Makefiles an unsere Modulnamen. Dazu öffnen wir die Datei crt\src\makefile mit einem Texteditor und ändern die Modulnamen wie folgt:
RETAIL_DLL_NAME=MyVcr90 RETAIL_LIB_NAME=msvcrt RETAIL_DLLCPP_NAME=MyVcp90 RETAIL_LIBCPP_NAME=msvcprt RETAIL_DLLMIXED_NAME=MyVcm90 RETAIL_LIBMIXED_NAME=msvcmrt RETAIL_LIBPURE_NAME=msvcurt RETAIL_PT_LIBMIXED_NAME=ptrustm RETAIL_PT_LIBPURE_NAME=ptrustu DEBUG_DLL_NAME=MyVcr90d DEBUG_LIB_NAME=msvcrtd DEBUG_DLLCPP_NAME=MyVcp90d DEBUG_LIBCPP_NAME=msvcprtd DEBUG_DLLMIXED_NAME=MyVcm90d DEBUG_LIBMIXED_NAME=msvcmrtd DEBUG_LIBPURE_NAME=msvcurtd DEBUG_PT_LIBMIXED_NAME=ptrustmd DEBUG_PT_LIBPURE_NAME=ptrustud RC_NAME=MyVcr90 RCCPP_NAME=MyVcp90 RCMIXED_NAME=MyVcm90
In der Datei crt\src\makefile.sub ersetzen wir in den Zeilen 106, 111 und 116 die Option -Wp64 durch -MP. -Wp64 wird seit Visual Studio 2008 nicht mehr unterstützt, bei aktiviertem Schalter wird das Kompilieren der CRT sonst abgebrochen. -MP sorgt bei Multicore-Prozessoren dafür, dass das Kompilieren wesentlich flotter abläuft.
6. Kompilieren
Jetzt sind endlich fast alle Vorbereitungen abgeschlossen und wir nähern uns langsam dem Kompilieren. Vorher müssen wir aber noch dafür sorgen, dass der Compiler auch alle Dateien findet. Dazu erstellen wir uns in crt\src zwei Batchdateien. Zuerst vcvars_x86.bat mit:
@ECHO OFF @SET PSDKINC=E:\Visual Studio.9\VC\PlatformSDK\include @SET PSDKLIB=E:\Visual Studio.9\VC\PlatformSDK\lib @SET PSDKBIN=E:\Visual Studio.9\VC\PlatformSDK\bin @SET VSCOMMON=E:\Visual Studio.9\Common7 @SET VCTOOLS=E:\Visual Studio.9\VC @SET VCTOOLSINC=$(PSDKINC) @SET LLP64=0 @echo Setting environment for using Microsoft Visual Studio 2008 x86 tools. @set PATH=%VCTOOLS%\BIN;%VCTOOLS%\BIN;%PSDKBIN%;%VSCOMMON%\IDE;%PATH%; @set INCLUDE=%VCTOOLS%\ATLMFC\INCLUDE;%VCTOOLS%\INCLUDE;%PSDKINC%;%INCLUDE% @set LIB=%VCTOOLS%\ATLMFC\LIB;%VCTOOLS%\LIB;%PSDKLIB%;%LIB%
und anschließend vcvars_amd64.bat mit:
@ECHO OFF @SET PSDKINC=E:\Visual Studio.9\VC\PlatformSDK\include @SET PSDKLIB=E:\Visual Studio.9\VC\PlatformSDK\lib @SET PSDKBIN=E:\Visual Studio.9\VC\PlatformSDK\bin @SET VSCOMMON=E:\Visual Studio.9\Common7 @SET VCTOOLS=E:\Visual Studio.9\VC @SET VCTOOLSINC=$(PSDKINC) @SET LLP64=2 @echo Setting environment for using Microsoft Visual Studio 2008 x64 cross tools. @set PATH=%VCTOOLS%\BIN\x86_amd64;%VCTOOLS%\BIN;%PSDKBIN%;%VSCOMMON%\IDE;%PATH%; @set INCLUDE=%VCTOOLS%\ATLMFC\INCLUDE;%VCTOOLS%\INCLUDE;%PSDKINC%;%INCLUDE% @set LIB=%VCTOOLS%\ATLMFC\LIB\amd64;%VCTOOLS%\LIB\amd64;%PSDKLIB%\x64;%LIB%
Die Pfade der Umgebungsvariablen müsst ihr an euer System anpassen. Der Übersichtlichkeit halber habe ich die Dateien aus dem Windows-SDK wie bei Visual Studio 2005 in das Unterverzeichnis PlatformSDK kopiert. Bei Visual Studio 2008 erfolgt die Installation der SDK-Headerdateien und Bibliotheksdateien normalerweise nach C:\Program Files\Microsoft SDKs\Windows\v6.0A.
Das war es auch schon mit den Vorbereitungen. Nun öffnen wir eine Eingabeaufforderung, wechseln in das Verzeichnis crt\src und geben zum Kompilieren der x86-Version
vcvars_x86.bat nmake
und für die x64-Version
vcvars_amd64.bat nmake
ein. Danach wird der Rechner jeweils ein wenig beschäftigt sein und die Laufzeitbibliotheken erstellen. Etwaige Warnungen können ignoriert werden, nur Fehler sollten keine auftreten. Wenn sich der Befehlsprompt wieder meldet, dann ist das Gröbste erledigt.
7. Kopieren der Lib-Dateien
Der letzte Schritt ist das Kopieren der erstellten Importbibliotheken aus den Verzeichnissen crt\src\build\intel bzw. crt\src\build\amd64 in das lib-bzw. lib\amd64-Verzeichnis. Da wir uns nur für die dynamischen Bibliotheken interessieren, reichen diese vollkommen aus:
msvcrt.lib msvcrtd.lib msvcprt.lib msvcprtd.lib
In den Buildverzeichnissen finden wir auch die angepassten Dlls MyVcr90(d).dll für die C-Laufzeit sowie MyVcp90(d).dll für die C++-Laufzeit (STL). Die ebenfalls erstellten MyVcm(d).dll enthalten die Laufzeit für verwalteten Code. Die hier vorgestellte Vorgehensweise ist aber wirklich nur für rein nativen Code gedacht, daher können wir die Vcm-Dlls links liegen lassen.
Das war’s auch schon, mit der MFC geht es dann morgen weiter. Im Vergleich mit der C/C++-Laufzeit wird das aber eher ein Kindergeburtstag.
Falsch multipliziert
Beim Debuggen von SpeedCommander unter x64 bin ich auf einen unschönen Bug in der ATL vom Visual Studio 2005 gestoßen. Während des Einlesens der Symbolleisten-Einstellungen wurde eine Exception geworfen und SpeedCommander stürzte ab. Nach dem Durchkämpfen bis zum Auslöser der Exception war der Fehler auch recht schnell sichtbar.
Die Exception wurde nach der Funktion AtlMultiplyThrow ausgelöst. AtlMultiplyThrow wird beim Reservieren eines Speicherbereichs aufgerufen und dient dazu, die Größe des zu reservierenden Speicherbereichs aus einer Anzahl von Elementen und deren Blockgröße zu ermitteln. Der Parameter tLeft gibt in diesem Fall die Anzahl der zu reservierenden Elemente und der Parameter tRight die Blockgröße an:
template <typename T>
inline T AtlMultiplyThrow(T tLeft, T tRight)
{
T tResult;
HRESULT hr=AtlMultiply(&tResult, tLeft, tRight);
if(FAILED(hr))
{
AtlThrow(hr);
}
return tResult;
}
AtlMultiplyThrow ruft lediglich AtlMultiply auf, im Fehlerfall wird eine Exception ausgelöst:
/* generic but compariatively slow version */
template<typename T>
inline HRESULT AtlMultiply(T* ptResult, T tLeft, T tRight)
{
/* avoid divide 0 */
if(tLeft==0)
{
return 0;
}
if(::ATL::AtlLimits<T>::_Max/tLeft < tRight)
{
return E_INVALIDARG;
}
*ptResult= tLeft * tRight;
return S_OK;
}
Der Fehler tritt nur auf, wenn der Wert tLeft Null ist. In diesem Fall gibt AtlMultiply 0 zurück, was auch der Wert für S_OK ist. AtlMultiplyThrow wird erfolgreich verlassen und gibt den Wert von tResult zurück. Wenn man sich die beiden Funktionen nun etwas genauer anschaut, dann entdeckt man, dass der Inhalt von tResult undefiniert ist. In der Debugversion werden alle Werte automatisch mit 0xCCCCCCCC initialisiert, somit gibt AtlMultiplyThrow hier 3435973836 zurück.
Die Allokation des Speichers erfolgt beim Einlesen der Einstellungen, genauer gesagt wenn ein String geladen wird. In der entsprechenden MFC-Funktion wird Speicher entsprechend der Zeichen im String reserviert. Für einen leeren String werden 0 Bytes reserviert, durch den Bug in der Berechnung soll Windows allerdings knapp 3.5 GB bereitstellen. Das kann natürlich nicht gut gehen.
Die Korrektur ist sehr einfach, in der Funktion AtlMultiply muss lediglich die Variable ptResult genullt werden, wenn tLeft den Wert 0 enthält:
/* generic but compariatively slow version */
template<typename T>
inline HRESULT AtlMultiply(T* ptResult, T tLeft, T tRight)
{
/* avoid divide 0 */
if(tLeft==0)
{
*ptResult = 0;
return S_OK;
}
if(::ATL::AtlLimits<T>::_Max/tLeft < tRight)
{
return E_INVALIDARG;
}
*ptResult= tLeft * tRight;
return S_OK;
}
Abschließend muss die MFC zwingend neu kompiliert werden, da der Fix ansonsten nur für eigene Anwendungen gilt und nicht für Funktionen innerhalb der MFC.