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.

5. 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.

6. 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.

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.