Überblick über potenzielle Aktualisierungsprobleme (Visual C++)

Im Laufe der Jahre wurde der Microsoft C++-Compiler stetig überarbeitet und es wurden Änderungen an der Programmiersprache C++ selbst, der C++-Standardbibliothek, der C-Runtime (CRT) und anderen Bibliotheken wie MFC (Microsoft Foundation Classes) und ATL (Active Template Library) vorgenommen. Daher werden beim Upgrade einer Anwendung aus einer früheren Version von Visual Studio möglicherweise Compiler- und Linkerfehler und Warnungen im Code angezeigt, der zuvor sauber kompiliert wurde. Je älter die ursprünglichen Codebasis, desto größer die Wahrscheinlichkeit derartiger Fehler. Diese Übersicht fasst die am häufigsten verwendeten Klassen von Problemen zusammen, die Sie wahrscheinlich sehen, und enthält Links zu ausführlicheren Informationen.

Fragen oder Kommentare zum Upgradevorgang können Sie an vcupgrade@microsoft.com senden.

Abhängigkeiten zwischen Bibliothek und Toolset

Wenn Sie eine App von Visual Studio 2013 oder vorher auf eine neuere Version aktualisieren, ist es häufig ratsam und erforderlich, alle Bibliotheken und DLLs zu aktualisieren, auf die die App-Links verweist. Sie müssen entweder Zugriff auf den Quellcode haben, oder der Bibliotheksanbieter muss neue Binärdateien bereitstellen, die mit derselben Hauptversion des Compilers kompiliert wurden. Wenn eine der folgenden Bedingungen zutrifft, können Sie diesen Abschnitt überspringen, der sich mit den Details der Binärdateikompatibilität befasst. Wenn keines der Fall ist, funktionieren die Bibliotheken möglicherweise nicht in Ihrer aktualisierten App. Die Informationen in diesem Abschnitt helfen Ihnen zu verstehen, ob Sie mit dem Upgrade fortfahren können.

Toolset

Die .obj Formate und .lib Dateiformate sind gut definiert und ändern sich selten. Wenn diese Dateiformate erweitert werden, haben diese Erweiterungen im Allgemeinen keinen Einfluss auf die Fähigkeit neuerer Toolsets, die von älteren Toolsets erzeugten Objektdateien und Bibliotheken zu nutzen. Die haupt ausnahme ist, wenn Sie die Verwendung /GL (Gesamte Programmoptimierung) kompilieren. Wenn Sie die Kompilierung verwenden /GL, können Sie die resultierende Objektdatei nur mit demselben Toolset verknüpfen, das zum Erstellen verwendet wurde. Wenn Sie also eine Objektdatei mit /GL einem Visual Studio 2017 (v141)-Compiler erstellen und verwenden, müssen Sie sie mit dem Visual Studio 2017 (v141)-Linker verknüpfen. Der Fehler liegt daran, dass die internen Datenstrukturen innerhalb der Objektdateien nicht über Hauptversionen des Toolsets hinweg stabil sind. Neuere Toolsets verstehen nicht die älteren Datenformate.

C++ verfügt über keine stabile Anwendungsbinärdateischnittstelle (Application Binary Interface, ABI). Allerdings verwaltet Visual Studio eine stabile C++-ABI für alle Nebenversionen eines Releases. Visual Studio 2015 (v140), Visual Studio 2017 (v141), Visual Studio 2019 (v142) und Visual Studio 2022 (v143) Toolsets variieren nur in ihrer Nebenversion. Sie haben alle die gleiche Hauptversionsnummer (nämlich 14). Weitere Informationen finden Sie unter C++-Binärkompatibilität zwischen Visual Studio-Versionen.

Angenommen, Sie verfügen über eine Objektdatei, die externe Symbole mit C++-Verknüpfung enthält. Dann kann diese Objektdatei möglicherweise nicht ordnungsgemäß mit Objektdateien verknüpft werden, die mit einer anderen Hauptversion des Toolsets erzeugt wurden. Es gibt viele mögliche Ergebnisse: Der Link kann vollständig fehlschlagen (z. B. wenn die Namensdeko geändert wurde). Der Link konnte erfolgreich ausgeführt werden, aber die App konnte zur Laufzeit fehlschlagen (z. B. wenn die Typlayouts geändert wurden). Oder Ihre App funktioniert möglicherweise weiterhin, und es wird nichts schief gehen. Beachten Sie außerdem, dass die C++-ABI, während die C++-ABI nicht stabil ist, die C ABI und die Teilmenge der für COM erforderlichen C++-ABI stabil sind.

Wenn Sie eine Verknüpfung mit einer Importbibliothek herstellen, können jegliche spätere Versionen der verteilbaren Visual Studio-Bibliotheken, die die ABI-Kompatibilität beibehalten, zur Laufzeit verwendet werden. Wenn Sie Ihre App z. B. mithilfe des Visual Studio 2015 Update 3-Toolsets kompilieren und verknüpfen, können Sie jede spätere Weiterverteilerfunktion verwenden. Das liegt daran, dass die Bibliotheken 2015, 2017, 2019 und 2022 die Abwärts-Binärkompatibilität beibehalten haben. Die Umgekehrte ist nicht wahr: Sie können keine Weiterverteiler für eine frühere Version des Toolsets verwenden, als Sie zum Erstellen einer Beliebigen Komponente Des Codes verwendet haben.

Libraries

Wenn Sie #include eine bestimmte Version der Headerdateien verwenden, müssen Sie die resultierende Objektdatei mit derselben Version der Bibliotheken verknüpfen. Wenn Ihre Quelldatei beispielsweise das Visual Studio 2015 Update 3 <immintrin.h>enthält, müssen Sie eine Verknüpfung mit der Visual Studio 2015 Update 3-Bibliothek vcruntime herstellen. Wenn Ihre Quelldatei auch die Visual Studio 2017 Version 15.5 <iostream>enthält, müssen Sie eine Verknüpfung mit der Visual Studio 2017 Version 15.5 Standard C++-Bibliothek herstellen. msvcprt Das Mischen und Abgleichen wird nicht unterstützt.

Für die C++-Standardbibliothek wurde das Mischen und Abgleichen seit Visual Studio 2010 explizit durch die Verwendung #pragma detect_mismatch in den Standardheadern nicht zugelassen. Wenn Sie versuchen, inkompatible Objektdateien zu verknüpfen, oder wenn Sie eine Verknüpfung mit der falschen Standardbibliothek herstellen, schlägt der Link fehl.

Ältere CRT-Versionsmischung und -abgleich wurden nie unterstützt, aber es funktionierte oft nur, weil sich die API-Oberfläche im Laufe der Zeit nicht viel geändert hat. Mit der Universal CRT wurde die Abwärtskompatibilität unterbrochen, sodass eine Abwärtskompatibilität für die Zukunft erreicht werden kann. Wir haben keine Pläne, in Zukunft neue, versionierte Universelle CRT-Binärdateien einzuführen. Für die vorhandenen Universal CRT erfolgt jetzt stattdessen eine direkte Aktualisierung.

Um die teilweise Verknüpfungskompatibilität mit Objektdateien (und Bibliotheken) bereitzustellen, die mit älteren Versionen der Microsoft C-Runtime-Header kompiliert wurden, stellen wir eine Bibliothek mit legacy_stdio_definitions.libVisual Studio 2015 und höher bereit. Diese Bibliothek bietet Kompatibilitätssymbole für die meisten Funktionen und Datenexporte, die aus der Universal CRT entfernt wurden. Der Satz von Kompatibilitätssymbolen legacy_stdio_definitions.lib reicht aus, um die meisten Abhängigkeiten zu erfüllen, einschließlich aller Abhängigkeiten in Bibliotheken, die im Windows SDK enthalten sind. Einige Symbole wurden jedoch aus der universellen CRT entfernt, die keine Kompatibilitätssymbole aufweisen. Diese Symbole enthalten sowohl einige Funktionen (z. B__iob_func. ) als auch einige Datenexporte (z__imp___iob. B. , , __imp___pctype). __imp___mb_cur_max

Wenn Sie über eine statische Bibliothek verfügen, die mit einer älteren Version der C-Runtime-Header erstellt wurde, empfehlen wir die folgenden Aktionen in dieser Reihenfolge:

1. Erstellen Sie die statische Bibliothek mithilfe der neuen Version von Visual Studio und den Universal CRT-Headern neu, um das Verknüpfen mit der Universal CRT zu unterstützen. Dieser Ansatz wird vollständig unterstützt und die beste Option.

2. Wenn Sie die statische Bibliothek nicht neu erstellen können (oder nicht möchten), können Sie versuchen, eine Verknüpfung herzustellen legacy_stdio_definitions.lib. Wenn sie die Verknüpfungszeitabhängigkeiten Ihrer statischen Bibliothek erfüllt, sollten Sie die statische Bibliothek sorgfältig testen, wie sie in der Binärdatei verwendet wird. Stellen Sie sicher, dass sie von keiner der Verhaltensänderungen beeinträchtigt wird, die an der universellen CRT vorgenommen wurden.

3. Möglicherweise sind die Abhängigkeiten Ihrer statischen Bibliothek nicht erfüllt legacy_stdio_definitions.lib , oder die Bibliothek funktioniert aufgrund von Verhaltensänderungen nicht mit dem universellen CRT. In diesem Fall wird empfohlen, Ihre statische Bibliothek in eine DLL zu kapseln, die Sie mit der erforderlichen Version der Microsoft C-Runtime verknüpfen. Wenn beispielsweise die statische Bibliothek mit Visual Studio 2013 erstellt wurde, erstellen Sie diese DLL auch mit den Visual Studio 2013-Toolset und C++-Bibliotheken. Durch das Erstellen der Bibliothek in einer DLL-Datei kapseln Sie das Implementierungsdetail, das die Abhängigkeit von einer bestimmten Version der Microsoft C-Laufzeit darstellt. Achten Sie darauf, dass die DLL-Schnittstelle keine Details der C-Runtime, die sie verwendet, verloren geht, z. B. wenn sie eine FILE* über die DLL-Grenze zurückgibt, oder ein malloc-zugewiesener Zeiger, den der Aufrufer benötigt free.

Die Verwendung mehrerer CRTs in einem einzigen Prozess ist nicht selbst problematisch. (Tatsächlich laden die meisten Prozesse mehrere CRT-DLLs. Die Komponenten des Windows-Betriebssystems hängen beispielsweise davon ab msvcrt.dll, und die CLR hängt von ihrem eigenen privaten CRT ab.) Probleme treten auf, wenn Sie den Zustand aus verschiedenen CRTs zusammenhäufen. Sie sollten z. B. keinen Arbeitsspeicher msvcr110.dll!malloc zuweisen und versuchen, diesen Speicher mithilfe msvcr120.dll!freedes Speichers zuzuordnen, und Sie sollten nicht versuchen, eine DATEI mithilfe msvcr110!fopen dieser DATEI zu öffnen und zu versuchen, aus dieser DATEI zu msvcr120!freadlesen. Solange Sie keinen Jubelzustand aus verschiedenen CRTs haben, können Sie sicher mehrere CRTs in einem einzigen Prozess geladen haben.

Weitere Informationen finden Sie unter Aktualisieren von Code für die Universal CRT.

Durch Projekteinstellungen verursachte Fehler

Öffnen Sie ein älteres Projekt, eine ältere Projektmappe oder einen älteren Arbeitsbereich in der neuesten Version von Visual Studio, um das Upgrade zu starten. Visual Studio erstellt ein neues Projekt basierend auf den alten Projekteinstellungen. Überprüfen Sie, ob das ältere Projekt Bibliothekspfade enthält oder Pfade enthält, die hartcodiert an nicht standardmäßigen Speicherorten sind. Es ist möglich, dass die Dateien in diesen Pfaden für den Compiler nicht sichtbar sind, wenn das Projekt die Standardeinstellungen verwendet. Weitere Informationen finden Sie unter OutputFile-Einstellung des Linkers.

Im Allgemeinen ist jetzt ein guter Zeitpunkt, um Ihren Projektcode zu organisieren, um die Projektwartung zu vereinfachen und Ihren aktualisierten Code so schnell wie möglich zu erstellen. Wenn Der Quellcode bereits gut organisiert ist und Ihr älteres Projekt unter Visual Studio 2010 oder höher kompiliert wird, können Sie die neue Projektdatei manuell bearbeiten, um die Kompilierung sowohl für den alten als auch für den neuen Compiler zu unterstützen. Das folgende Beispiel zeigt, wie Sie die Kompilierung für Visual Studio 2015 und Visual Studio 2017 durchführen:

<PlatformToolset Condition="'$(VisualStudioVersion)'=='14.0'">v140</PlatformToolset>
<PlatformToolset Condition="'$(VisualStudioVersion)'=='15.0'">v141</PlatformToolset>

LNK2019: Nicht aufgelöste Externe

Für nicht aufgelöste Symbole müssen Sie die Projekteinstellungen möglicherweise korrigieren.

• Wenn sich die Quelldatei an einem nicht standardmäßigen Speicherort befindet, haben Sie den Pfad zu den Includeverzeichnissen des Projekts hinzugefügt?

• Wenn das externe Element in einer .lib Datei definiert ist, haben Sie den Lib-Pfad in den Projekteigenschaften angegeben, und ist die richtige Version der .lib Datei dort gespeichert?

• Versuchen Sie, eine Verknüpfung mit einer .lib Datei zu erstellen, die mit einer anderen Version von Visual Studio kompiliert wurde? Wenn dies der Fall ist, lesen Sie den vorherigen Abschnitt über Abhängigkeiten zwischen Bibliothek und Toolset.

• Stimmen die Typen der Argumente an der Aufrufsite tatsächlich mit einer vorhandenen Funktionsüberladung überein? Stellen Sie sicher, dass die zugrunde liegenden Typen das sind, was Sie erwarten, sowohl für alle Typedefs in der Signatur der Funktion als auch im Code, der die Funktion aufruft.

Um nicht behobene Symbolfehler zu beheben, können dumpbin.exe Sie die in einer Binärdatei definierten Symbole untersuchen. Verwenden Sie zum Anzeigen der in einer Bibliothek definierten Symbole die folgende Befehlszeile:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t Ist nativer Typ)

(In Microsoft Visual C++ 6.0 und früher wchar_t wurde sie nicht als integrierter Typ implementiert. Sie wurde als typedef für unsigned short.) deklariertwchar.h. Der C++-Standard erfordert, dass es wchar_t sich um einen integrierten Typ handelt. Die Verwendung der „typedef“-Version kann Portabilitätsprobleme verursachen. Wenn Sie ein Upgrade von früheren Versionen von Visual Studio durchführen und den Compilerfehler C2664 sehen, da der Code versucht, einen in implizit wchar_t unsigned shortzu konvertieren, wird empfohlen, den Code so zu ändern, dass der Fehler behoben wird, anstatt den Fehler festzulegen /Zc:wchar_t-. Weitere Informationen finden Sie unter /Zc:wchar_t (wchar_t Ist nativer Typ).

Upgrade mit den Linkeroptionen /NODEFAULTLIB, /ENTRYund /NOENTRY

Die /NODEFAULTLIB Linkeroption (oder die Linkereigenschaft "Alle Standardbibliotheken ignorieren") weist den Linker an, die Verknüpfung in den Standardbibliotheken wie z. B. CRT nicht automatisch zu verknüpfen. Das bedeutet, dass jede Bibliothek als einzelne Eingabe aufgelistet werden muss. Diese Liste der Bibliotheken wird in der Eigenschaft Zusätzliche Abhängigkeiten im Linkerabschnitt des Dialogfelds Projekteigenschaften angegeben.

Projekte, die diese Option verwenden, stellen bei der Aktualisierung ein Problem dar, weil der Inhalt einiger Standardbibliotheken geändert wurde. Da jede Bibliothek in der Eigenschaft Zusätzliche Abhängigkeiten oder in der Befehlszeile des Linkers aufgelistet werden muss, ist es erforderlich, die Liste der Bibliotheken so zu aktualisieren, dass alle aktuellen Namen verwendet werden.

In der folgenden Tabelle werden die Bibliotheken angezeigt, deren Inhalt seit Visual Studio 2015 geändert wurde. Sie müssen zum Aktualisieren die Bibliotheksnamen in der zweiten Spalte zu den Bibliotheken in der ersten Spalte hinzufügen. Einige dieser Bibliotheken sind Importbibliotheken, aber das sollte nicht wichtig sein.

Dasselbe Problem tritt auch auf, wenn Sie die Option /ENTRY oder /NOENTRY verwenden, die ebenfalls zur Umgehung der Standardbibliotheken führen.

Durch verbesserte Sprachkonformität verursachte Fehler

Die Konformität des Microsoft C++-Compilers mit dem C++-Standard wurde im Lauf der Zeit stetig verbessert. Code, der in früheren Versionen kompiliert wurde, kann in späteren Versionen von Visual Studio möglicherweise nicht kompiliert werden. Das liegt daran, dass der Compiler ordnungsgemäß einen Fehler kennzeichnet, den er zuvor ignoriert oder explizit zugelassen hat.

Der Parameter /Zc:forScope wurde beispielsweise früh im Verlauf von MSVC eingeführt. Er lässt nicht konformes Verhalten für Schleifenvariablen zu. Dieser Schalter ist inzwischen veraltet und kann in zukünftigen Versionen entfernt werden. Es wird dringend empfohlen, diese Option beim Upgrade des Codes nicht zu verwenden. Weitere Informationen finden Sie unter /Zc:forScope- "Veraltet".

Ein Beispiel für einen bei der Aktualisierung häufig auftretenden Compilerfehler ist die Übergabe eines nicht konstanten Arguments an einen konstanten Parameter. Ältere Versionen des Compilers kennzeichnen sie nicht immer als Fehler. Weitere Informationen finden Sie unter Strikte Compilerkonvertierungen.

Weitere Informationen zu bestimmten Verbesserungen bei der Übereinstimmung mit Standards finden Sie unter Änderungsverlauf von Visual C++ von 2003 bis 2015 und C++ conformance improvements in Visual Studio (Verbesserungen bei der Übereinstimmung mit C++-Standards in Visual Studio).

Fehler, die integrale Typen betreffen <stdint.h>

Die <stdint.h> Kopfzeile definiert Typedefs und Makros, die im Gegensatz zu integrierten integralen Typen garantiert eine bestimmte Länge auf allen Plattformen aufweisen. Beispiele sind uint32_t und int64_t. Die <stdint.h> Kopfzeile wurde in Visual Studio 2010 hinzugefügt. Code, der vor 2010 geschrieben wurde, hat möglicherweise private Definitionen für diese Typen bereitgestellt. Und diese Definitionen sind möglicherweise nicht immer mit den <stdint.h> Definitionen konsistent.

Wenn der Fehler C2371 ist und ein stdint Typ beteiligt ist, bedeutet dies wahrscheinlich, dass der Typ in einem Header entweder in Ihrem Code oder in einer Bibliotheksdatei eines Drittanbieters definiert ist. Beim Upgrade sollten Sie benutzerdefinierte Definitionen von <stdint.h> Typen beseitigen, aber zuerst die benutzerdefinierten Definitionen mit den aktuellen Standarddefinitionen vergleichen, um sicherzustellen, dass keine neuen Probleme auftreten.

Mit F12 (Gehe zu Definition) können Sie anzeigen, wo der betreffende Typ definiert ist.

Die /showIncludes Compileroption kann hier nützlich sein. Wählen Sie im Dialogfeld Eigenschaftenseiten für Ihr Projekt die Seite "Konfigurationseigenschaften>C/C++>Erweitert" aus, und legen Sie "Enthält anzeigen" auf "Ja" fest. Erstellen Sie dann Ihr Projekt neu. Die Liste der #include Dateien wird im Ausgabefenster angezeigt. Jeder Header wird unterhalb des Headers, der ihn enthält, eingerückt.

Fehler im Zusammenhang mit CRT-Funktionen

Im Laufe der Jahre wurden viele Änderungen an der C-Laufzeit vorgenommen. Viele sichere Versionen von Funktionen wurden hinzugefügt, und einige Funktionen wurden entfernt. Wie weiter oben in diesem Artikel beschrieben, wurde die Implementierung des CRT von Microsoft in Visual Studio 2015 in neue Binärdateien und zugehörige .lib Dateien umgestaltet.

Wenn ein Fehler eine CRT-Funktion betrifft, finden Sie ggf. in den Artikeln Visual C++ change history 2003 – 2015 (Änderungsverlauf von Visual C++ von 2003 bis 2015) und C++ conformance improvements in Visual Studio (Verbesserungen bei der Übereinstimmung mit C++-Standards in Visual Studio) zusätzliche Informationen. Wenn der Fehler LNK2019 ist, stellen Sie sicher, dass die Funktion nicht entfernt wurde. Wenn Sie sicher sind, dass die Funktion noch vorhanden ist und der aufrufende Code korrekt ist, überprüfen Sie, ob Ihr Projekt verwendet /NODEFAULTLIBwird. Wenn ja, müssen Sie die Liste der Bibliotheken aktualisieren, um die neuen universalen (UCRT)-Bibliotheken zu verwenden. Weitere Informationen finden Sie oben im Abschnitt zu Bibliotheken und Abhängigkeiten.

Wenn der Fehler beteiligt ist printf oder scanf, stellen Sie sicher, dass Sie keine funktion privat definieren, ohne diese einschließt stdio.h. Falls ja, entfernen Sie entweder die privaten Definitionen oder den Link zu legacy_stdio_definitions.lib. Sie können diese Bibliothek im Dialogfeld Eigenschaftenseiten unter Konfigurationseigenschaften>Linker>Eingabe in der Eigenschaft Zusätzliche Abhängigkeiten festlegen. Wenn Sie eine Verknüpfung mit Windows SDK 8.1 oder einer früheren Version herstellen, fügen Sie diese hinzu legacy_stdio_definitions.lib.

Wenn der Fehler Argumente von Formatzeichenfolgen betrifft, liegt dies wahrscheinlich daran, dass der Compiler eine strengere Erzwingung als der Standard einsetzt. Weitere Informationen finden Sie im Änderungsverlauf. Berücksichtigen Sie alle hier aufgeführten Fehler, da sie ein potenzielles Sicherheitsrisiko darstellen können.

Durch Änderungen im C++-Standard verursachte Fehler

Der C++-Standard selbst hat sich in einer Weise entwickelt, die nicht immer abwärtskompatibel ist. In C++11 wurden Verschiebungssemantik, neue Schlüsselwörter und andere Sprach- und Standardbibliotheksfeatures eingeführt. Diese Änderungen können möglicherweise Compilerfehler und sogar ein anderes Laufzeitverhalten verursachen.

Beispielsweise kann ein altes C++-Programm den iostream.h Header enthalten. Dieser Header ist im Verlauf von C++ schon lange veraltet, und wurde aus Visual Studio schließlich vollständig entfernt. In diesem Fall müssen Sie Ihren Code verwenden <iostream> und neu schreiben. Weitere Informationen finden Sie unter Aktualisieren des alten iostream Codes.

Warnung „C4838: Einschränkende Konvertierung“

Der C++-Standard gibt jetzt an, dass Konvertierungen von nicht signierten integralen Werten verengt werden. Der Compiler hat diese Warnung vor Visual Studio 2015 nicht erhöht. Überprüfen Sie jedes Vorkommen, um sicherzustellen, dass sich die Schmalung nicht auf die Richtigkeit des Codes auswirkt.

Warnungen zur Verwendung von sicheren CRT-Funktionen

Im Laufe der Jahre wurden sichere Versionen der C-Laufzeitfunktionen eingeführt. Zwar sind die alten, nicht sicheren Versionen weiterhin verfügbar, Sie sollten aber dennoch Ihren Code ändern und die sicheren Versionen verwenden. Der Compiler gibt bei Verwendung der nicht sicheren Versionen eine Warnung aus. Sie können diese Warnungen auch deaktivieren oder ignorieren. Um die Warnung für alle Projekte in der Projektmappe zu deaktivieren, öffnen Sie Ansicht>Eigenschaften-Manager, wählen Sie alle Projekte aus, für die Sie die Warnung deaktivieren möchten, klicken Sie dann mit der rechten Maustaste auf die ausgewählten Elemente, und wählen Sie Eigenschaften aus. Wählen Sie im Dialogfeld Eigenschaftenseiten und Konfigurationseigenschaften>C/C++>ErweitertBestimmte Warnungen deaktivieren aus. Wählen Sie den Dropdownpfeil und dann "Bearbeiten" aus. Geben Sie „4996“ in das Textfeld ein (Schließen Sie das Präfix "C" nicht ein.) Weitere Informationen finden Sie unter Portieren für die Verwendung von Secure CRT.

Fehler, die durch Änderungen an Windows-APIs oder veralteten SDKs verursacht werden

Im Laufe der Jahre wurden Windows-APIs und Datentypen hinzugefügt sowie manchmal geändert oder entfernt. Auch andere SDKs, die nicht zum Kernbetriebssystem gehören, sind gekommen und gegangen. Ältere Programme enthalten möglicherweise Aufrufe von APIs, die nicht mehr vorhanden sind. Sie können auch Aufrufe an APIs in anderen Microsoft-SDKs enthalten, die nicht mehr unterstützt werden. Fehler bei fehlenden Windows-APIs oder APIs aus älteren Microsoft-SDKs können angezeigt werden. Es ist möglich, dass die APIs von neueren, sichereren Funktionen entfernt oder ersetzt wurden.

In der Windows-API-Dokumentation sind die mindestens oder maximal unterstützten Betriebssysteme aufgeführt. Informationen zu einer bestimmten Windows-API können Sie im API-Index für Windows-Desktopanwendungen nachschlagen.

Windows-Version

Wenn Sie ein Programm aktualisieren, das die Windows-API entweder direkt oder indirekt verwendet, müssen Sie die mindeste Windows-Version für die Unterstützung entscheiden. In den meisten Fällen ist Windows 7 eine gute Wahl. Weitere Informationen finden Sie unter Header file problems (Probleme mit Headerdateien). Das Makro WINVER definiert die älteste Version von Windows, unter der das Programm ausgeführt werden kann. Wenn Ihr MFC-Programm auf 0x0501 (Windows XP) festgelegt ist WINVER , erhalten Sie eine Warnung, da MFC XP nicht mehr unterstützt, auch wenn das Compilertoolset selbst über einen XP-Modus verfügt. Die Compilertoolset-Unterstützung für Windows XP endete in Visual Studio 2017.

Weitere Informationen finden Sie unter Aktualisieren der Windows-Zielversion und veralteter Headerdateien.

ATL/MFC

ATL und MFC sind relativ stabile APIs, allerdings werden auch hier gelegentlich Änderungen vorgenommen. Weitere Informationen finden Sie unter Visual C++-Änderungsverlauf 2003 - 2015, Neuerungen für Visual C++ in Visual Studio und C++-Konformitätsverbesserungen in Visual Studio.

LNK 2005 _DllMain@12 bereits in MSVCRTD.lib definiert

Dieser Fehler kann in MFC-Anwendungen auftreten. Er weist auf ein Sortierungsproblem zwischen der CRT- und der MFC-Bibliothek hin. MFC muss zuerst verknüpft werden, damit sie bereitstellt und delete Operatoren.new Verwenden Sie zum Beheben des Fehlers den /NODEFAULTLIB Schalter zum Ignorieren dieser Standardbibliotheken: MSVCRTD.lib und mfcs140d.lib. Fügen Sie dann dieselben Bibliotheken wie zusätzliche Abhängigkeiten hinzu.

32-Bit oder 64-Bit

Wenn Ihr ursprünglicher Code für 32-Bit-Systeme kompiliert wird, haben Sie die Möglichkeit, eine 64-Bit-Version anstelle (oder zusätzlich) einer neuen 32-Bit-App zu erstellen. Im Allgemeinen sollten Sie das Programm zuerst im 32-Bit-Modus kompilieren, und anschließend die Kompilierung der 64-Bit-Version vornehmen. Die Kompilierung für 64-Bit ist einfach, aber in einigen Fällen werden Fehler sichtbar, die in 32-Bit-Builds verborgen waren.

Außerdem sollten Sie sich über mögliche Kompilierungszeit- und Laufzeitprobleme im Zusammenhang mit Zeigergröße, Zeit- und Größenwerten sowie größenspezifischen Formatbezeichnern in printf und scanf Funktionen bewusst sein. Weitere Informationen finden Sie unter Configure Visual C++ for 64-Bit, x64 targets and Common Visual C++ 64-Bit migration issues. Weitere Migrationstipps finden Sie im Programmierhandbuch für 64-Bit-Windows.

Unicode oder MBCS/ASCII

Vor der Standardisierung von Unicode verwendeten viele Programme den Multibyte-Zeichensatz (MBCS), um Zeichen darzustellen, die nicht im ASCII-Zeichensatz enthalten waren. In älteren MFC-Projekten war MBCS die Standardeinstellung. Wenn Sie ein solches Programm aktualisieren, werden Warnungen angezeigt, die stattdessen die Verwendung von Unicode empfehlen. Wenn Sie entscheiden, dass die Konvertierung in Unicode die Entwicklungskosten nicht wert ist, können Sie die Warnung deaktivieren oder ignorieren. Um diese für alle Projekte in der Projektmappe zu deaktivieren, öffnen Sie Ansicht>Eigenschaften-Manager, wählen Sie alle Projekte aus, für die Sie die Warnung deaktivieren möchten, klicken Sie dann mit der rechten Maustaste auf die ausgewählten Elemente, und wählen Sie Eigenschaften aus. Klicken Sie im Dialogfeld Eigenschaftenseiten auf Konfigurationseigenschaften>C/C++>Erweitert. Klicken Sie in der Eigenschaft Bestimmte Warnungen deaktivieren auf den Pfeil des Dropdownmenüs und dann auf Bearbeiten. Geben Sie „4996“ in das Textfeld ein (Schließen Sie das Präfix "C" nicht ein.) Wählen Sie "OK " aus, um die Eigenschaft zu speichern, und wählen Sie dann "OK " aus, um Ihre Änderungen zu speichern.

Weitere Informationen finden Sie unter Portieren von MBCS zu Unicode. Allgemeine Informationen zu MBCS und Unicode finden Sie unter Text und Zeichenfolgen in Visual C++ und Internationalisierung .

Siehe auch

Aktualisieren von Projekten aus früheren Versionen von Visual C++
Verbesserungen der C++-Konformität in Visual Studio 2015