Omówienie potencjalnych problemów z uaktualnieniem (Visual C++)

W ciągu ostatnich lat kompilator języka Microsoft C++ przeszedł wiele zmian wraz ze zmianami w samym języku C++, standardową biblioteką C++, środowiskiem uruchomieniowym języka C (CRT) i innymi bibliotekami, takimi jak MFC i ATL. W związku z tym podczas uaktualniania aplikacji z wcześniejszej wersji programu Visual Studio mogą pojawić się błędy kompilatora i konsolidatora oraz ostrzeżenia w kodzie, który wcześniej skompilowany w sposób czysty. Im starsza oryginalna baza kodu, tym większa jest możliwość wystąpienia takich błędów. To omówienie zawiera podsumowanie najbardziej typowych klas problemów, które prawdopodobnie zobaczysz, i zawiera linki do bardziej szczegółowych informacji.

Uwaga

W przeszłości zalecamy, aby uaktualnienia obejmujące kilka wersji programu Visual Studio były wykonywane przyrostowo jedną wersję naraz. Nie zalecamy już tego podejścia. Ustaliliśmy, że prawie zawsze łatwiej jest uaktualnić program Visual Studio do najnowszej wersji niezależnie od starej bazy kodu.

Pytania lub komentarze dotyczące procesu uaktualniania można wysłać do programu vcupgrade@microsoft.com.

Zależności biblioteki i zestawu narzędzi

Uwaga

Ta sekcja dotyczy aplikacji i bibliotek utworzonych w programie Visual Studio 2013 i starszych wersjach. Zestawy narzędzi używane w programach Visual Studio 2015, Visual Studio 2017 i Visual Studio 2019 są zgodne binarne. Aby uzyskać więcej informacji, zobacz Zgodność binarna języka C++ między wersjami programu Visual Studio.

Podczas uaktualniania aplikacji z programu Visual Studio 2013 lub wcześniejszego do nowszej wersji często zaleca się uaktualnienie wszystkich bibliotek i bibliotek DLL linków do aplikacji. Musisz mieć dostęp do kodu źródłowego lub dostawca biblioteki musi podać nowe pliki binarne skompilowane przy użyciu tej samej wersji głównej kompilatora. Jeśli jeden z tych warunków jest spełniony, możesz pominąć tę sekcję, która dotyczy szczegółów zgodności binarnej. Jeśli tak nie jest, biblioteki mogą nie działać w uaktualnionej aplikacji. Informacje przedstawione w tej sekcji pomogą Ci zrozumieć, czy można kontynuować uaktualnianie.

Zestaw narzędzi

Formaty .obj plików i .lib są dobrze zdefiniowane i rzadko zmieniają się. Czasami dodawane są do tych formatów plików, ale te dodatki zazwyczaj nie wpływają na możliwość korzystania z nowszych zestawów narzędzi do korzystania z plików obiektów i bibliotek utworzonych przez starsze zestawy narzędzi. Głównym wyjątkiem jest kompilowanie przy użyciu /GL (KtoTo le Program Optimization). Jeśli kompilujesz przy użyciu polecenia /GL, możesz połączyć wynikowy plik obiektu tylko przy użyciu tego samego zestawu narzędzi, który został użyty do jego utworzenia. Dlatego jeśli utworzysz plik obiektu i /GL użyjesz kompilatora programu Visual Studio 2017 (wersja 141), musisz połączyć go przy użyciu konsolidatora programu Visual Studio 2017 (wersja 141). Wynika to z faktu, że wewnętrzne struktury danych w plikach obiektów nie są stabilne w głównych wersjach zestawu narzędzi. Nowsze zestawy narzędzi nie rozumieją starszych formatów danych.

Język C++ nie ma stabilnego interfejsu binarnego aplikacji (ABI). Jednak program Visual Studio utrzymuje stabilny język C++ ABI dla wszystkich wersji pomocniczych wydania. Zestawy narzędzi programu Visual Studio 2015 (wersja 140), Visual Studio 2017 (wersja 141), Visual Studio 2019 (wersja 142) i Visual Studio 2022 (wersja 143) różnią się tylko w wersji pomocniczej. Wszystkie mają ten sam numer wersji głównej, czyli 14. Aby uzyskać więcej informacji, zobacz Zgodność binarna języka C++ między wersjami programu Visual Studio.

Jeśli masz plik obiektu, który zawiera symbole zewnętrzne z łączem języka C++, ten plik obiektu może nie być poprawnie łączny z plikami obiektów utworzonymi przez inną główną wersję zestawu narzędzi. Istnieje wiele możliwych wyników: link może zakończyć się niepowodzeniem (na przykład jeśli dekoracja nazwy uległa zmianie). Link może zakończyć się powodzeniem, ale aplikacja może zakończyć się niepowodzeniem w czasie wykonywania (na przykład jeśli układy typów uległy zmianie). Lub aplikacja może nadal działać i nic się nie stanie. Należy również pamiętać, że chociaż język C++ ABI nie jest stabilny, ABI i podzbiór C++ ABI wymagane dla modelu COM są stabilne.

Jeśli łączysz się z biblioteką importu, każda późniejsza wersja bibliotek redystrybucyjnych programu Visual Studio, które zachowują zgodność usługi ABI, mogą być używane w czasie wykonywania. Jeśli na przykład skompilujesz i połączysz aplikację przy użyciu zestawu narzędzi programu Visual Studio 2015 Update 3, możesz użyć dowolnego późniejszego pakietu redystrybucyjnego. Dzieje się tak, ponieważ biblioteki z 2015 r. 2017, 2019 i 2022 r. zachowały zgodność plików binarnych z poprzednimi wersjami. Odwrotnie nie jest prawdą: nie można użyć pakietu redystrybucyjnego dla starszej wersji zestawu narzędzi niż użyto do utworzenia dowolnego składnika kodu.

Biblioteki

#include Jeśli określona wersja plików nagłówkowych jest wymagana, należy połączyć wynikowy plik obiektu z tą samą wersją bibliotek. Na przykład jeśli plik źródłowy zawiera program Visual Studio 2015 Update 3 <immintrin.h>, musisz połączyć się z biblioteką programu Visual Studio 2015 Update 3 vcruntime . Podobnie, jeśli plik źródłowy zawiera program Visual Studio 2017 w wersji 15.5 <iostream>, musisz połączyć się z biblioteką msvcprtVisual Studio 2017 w wersji 15.5 Standard C++ . Mieszanie i dopasowywanie nie jest obsługiwane.

W przypadku standardowej biblioteki języka C++ mieszanie i dopasowywanie zostało jawnie niedozwolone w #pragma detect_mismatch nagłówkach standardowych od programu Visual Studio 2010. Jeśli spróbujesz połączyć niezgodne pliki obiektów lub jeśli łączysz się z niewłaściwą biblioteką standardową, łącze zakończy się niepowodzeniem.

Starsze mieszanie i dopasowywanie wersji CRT nigdy nie było obsługiwane, ale często po prostu działało, ponieważ powierzchnia interfejsu API nie zmieniła się znacznie w czasie. Universal CRT złamał zgodność z poprzednimi wersjami, dzięki czemu w przyszłości możemy zachować zgodność z poprzednimi wersjami. Nie mamy planów wprowadzenia nowych, wersji uniwersalnych plików binarnych CRT w przyszłości. Zamiast tego istniejący uniwersalny CRT jest teraz aktualizowany w miejscu.

Aby zapewnić zgodność częściowego łącza z plikami obiektów (i bibliotekami) skompilowanymi ze starszymi wersjami nagłówków środowiska uruchomieniowego języka Microsoft C, udostępniamy bibliotekę , legacy_stdio_definitions.libz programem Visual Studio 2015 lub nowszym. Ta biblioteka zawiera symbole zgodności dla większości funkcji i eksportów danych, które zostały usunięte z uniwersalnego CRT. Zestaw symboli zgodności dostarczonych przez legacy_stdio_definitions.lib program jest wystarczający do spełnienia większości zależności, w tym wszystkich zależności w bibliotekach zawartych w zestawie Windows SDK. Jednak niektóre symbole zostały usunięte z uniwersalnego CRT, które nie mają symboli zgodności. Te symbole obejmują zarówno niektóre funkcje (na przykład __iob_func), jak i niektóre eksporty danych (na przykład __imp___iob, , __imp___mb_cur_max__imp___pctype).

Jeśli masz bibliotekę statyczną utworzoną przy użyciu starszej wersji nagłówków środowiska uruchomieniowego języka C, zalecamy następujące akcje w następującej kolejności:

1. Skompiluj bibliotekę statyczną przy użyciu nowej wersji programu Visual Studio i nagłówków universal CRT w celu obsługi łączenia z uniwersalnym CRT. To podejście jest w pełni obsługiwane i najlepsze rozwiązanie.

2. Jeśli nie możesz (lub nie chcesz) ponownie skompilować biblioteki statycznej, możesz spróbować połączyć się z legacy_stdio_definitions.lib. Jeśli spełnia ona zależności czasu połączenia biblioteki statycznej, należy dokładnie przetestować bibliotekę statyczną, ponieważ jest używana w pliku binarnym. Upewnij się, że nie ma to negatywnego wpływu na jakiekolwiek zmiany behawioralne wprowadzone w uniwersalnym CRT.

3. Być może zależności biblioteki statycznej nie są zadowalające legacy_stdio_definitions.lib lub biblioteka nie działa z uniwersalnym CRT ze względu na zmiany zachowania. W takim przypadku zalecamy hermetyzowanie biblioteki statycznej do biblioteki DLL, którą łączysz z wymaganą wersją środowiska Uruchomieniowego języka Microsoft C. Jeśli na przykład biblioteka statyczna została skompilowana przy użyciu programu Visual Studio 2013, skompiluj tę bibliotekę DLL przy użyciu zestawu narzędzi programu Visual Studio 2013 i bibliotek języka C++. Tworząc bibliotekę w bibliotece DLL, hermetyzujesz szczegóły implementacji, które są jego zależnością od konkretnej wersji środowiska uruchomieniowego microsoft C. Należy zachować ostrożność, aby interfejs DLL nie wyciekł szczegółów, z których korzysta środowisko uruchomieniowe języka C, na przykład jeśli zwraca granicę FILE* biblioteki DLL, lub - przydzielony mallocwskaźnik, który obiekt wywołujący musi free.

Korzystanie z wielu CTT w jednym procesie nie jest samo w sobie problematyczne. (W rzeczywistości większość procesów ładuje wiele bibliotek DLL CRT. Na przykład składniki systemu operacyjnego Windows zależą od msvcrt.dll, a clR zależy od własnego prywatnego CRT. Problemy pojawiają się, gdy wystąpią problemy ze stanem jumble z różnych CTT. Na przykład nie należy przydzielić pamięci przy użyciu polecenia msvcr110.dll!malloc i próbować cofnąć przydział tej pamięci przy użyciu metody msvcr120.dll!free, a nie należy próbować otworzyć pliku przy użyciu polecenia msvcr110!fopen i spróbować odczytać z tego pliku przy użyciu polecenia msvcr120!fread. Tak długo, jak nie ma stanu jumble z różnych CTT, można bezpiecznie mieć wiele CTT załadowanych w jednym procesie.

Aby uzyskać więcej informacji, zobacz Uaktualnianie kodu do uniwersalnego CRT.

Błędy spowodowane ustawieniami projektu

Aby rozpocząć proces uaktualniania, otwórz starszy projekt/rozwiązanie/obszar roboczy w najnowszej wersji programu Visual Studio. Program Visual Studio utworzy nowy projekt na podstawie starych ustawień projektu. Sprawdź, czy starszy projekt ma ścieżki biblioteki lub zawiera ścieżki, które są zakodowane w nietypowych lokalizacjach. Możliwe, że pliki w tych ścieżkach nie będą widoczne dla kompilatora, gdy projekt używa ustawień domyślnych. Aby uzyskać więcej informacji, zobacz Ustawienie konsolidatora OutputFile.

Ogólnie rzecz biorąc, teraz jest to doskonały czas na zorganizowanie kodu projektu w celu uproszczenia konserwacji projektu i ułatwienia jak najszybszego utworzenia uaktualnionego kodu. Jeśli kod źródłowy jest już dobrze zorganizowany, a starszy projekt kompiluje się w programie Visual Studio 2010 lub nowszym, możesz ręcznie edytować nowy plik projektu w celu obsługi kompilacji zarówno w starym, jak i nowym kompilatorze. W poniższym przykładzie pokazano, jak skompilować programy Visual Studio 2015 i Visual Studio 2017:

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

LNK2019: nierozwiązane zewnętrzne

W przypadku nierozwiązanych symboli może być konieczne naprawienie ustawień projektu.

• Jeśli plik źródłowy znajduje się w lokalizacji innej niż domyślna, czy dodano ścieżkę do katalogów dołączania projektu?

• Jeśli element zewnętrzny jest zdefiniowany w .lib pliku, czy określono ścieżkę lib we właściwościach projektu i czy znajduje się tam prawidłowa wersja .lib pliku?

• Czy próbujesz połączyć się z plikiem .lib skompilowanym przy użyciu innej wersji programu Visual Studio? Jeśli tak, zobacz poprzednią sekcję dotyczącą zależności biblioteki i zestawu narzędzi.

• Czy typy argumentów w lokacji wywołania są rzeczywiście zgodne z istniejącym przeciążeniem funkcji? Sprawdź, czy typy bazowe są oczekiwane, zarówno dla dowolnych definicji typów w podpisie funkcji, jak i w kodzie, który wywołuje funkcję.

Aby rozwiązać problemy z nierozwiązanym błędami symboli, możesz użyć dumpbin.exe metody do zbadania symboli zdefiniowanych w pliku binarnym. Spróbuj użyć następującego wiersza polecenia, aby wyświetlić symbole zdefiniowane w bibliotece:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t Jest typem natywnym)

(W programie Microsoft Visual C++ 6.0 i starszych wchar_t wersjach nie zaimplementowano go jako typu wbudowanego. Został zadeklarowany jako wchar.h definicja typu . unsigned short) Standard C++ wymaga wchar_t wbudowanego typu. Użycie wersji typedef może powodować problemy z przenośnością. Jeśli uaktualnisz starsze wersje programu Visual Studio i zobaczysz błąd kompilatora C2664, ponieważ kod próbuje niejawnie przekonwertować wchar_t element na unsigned short, zalecamy zmianę kodu, aby naprawić błąd, zamiast ustawiać wartość /Zc:wchar_t-. Aby uzyskać więcej informacji, zobacz /Zc:wchar_t (wchar_t Jest typem natywnym).

Uaktualnianie za pomocą opcji /NODEFAULTLIBkonsolidatora , /ENTRYi /NOENTRY

Opcja /NODEFAULTLIB konsolidatora (lub właściwość konsolidatora Ignoruj wszystkie biblioteki domyślne) informuje konsolidatora, aby nie łączył się automatycznie w bibliotekach domyślnych, takich jak CRT. Oznacza to, że każda biblioteka musi być wyświetlana indywidualnie jako dane wejściowe. Ta lista bibliotek jest podana we właściwości Dodatkowe zależności w sekcji Konsolidator okna dialogowego Właściwości projektu.

Projekty korzystające z tej opcji stanowią problem podczas uaktualniania, ponieważ zawartość niektórych bibliotek domyślnych została refaktoryzowana. Ponieważ każda biblioteka musi być wymieniona we właściwości Dodatkowe zależności lub w wierszu polecenia konsolidatora, należy zaktualizować listę bibliotek, aby używać wszystkich bieżących nazw.

W poniższej tabeli przedstawiono biblioteki, których zawartość zmieniła się począwszy od programu Visual Studio 2015. Aby uaktualnić, należy dodać nowe nazwy bibliotek w drugiej kolumnie do bibliotek w pierwszej kolumnie. Niektóre z tych bibliotek to biblioteki importowane, ale nie powinny mieć znaczenia.

Jeśli używasz:	Należy użyć tych bibliotek:
libcmt.lib	libcmt.lib, libucrt.lib, libvcruntime.lib
libcmtd.lib	libcmtd.lib, libucrtd.lib, libvcruntimed.lib
msvcrt.lib	msvcrt.lib, ucrt.lib, vcruntime.lib
msvcrtd.lib	msvcrtd.lib, ucrtd.lib, vcruntimed.lib

Ten sam problem ma zastosowanie również w przypadku użycia /ENTRY opcji lub /NOENTRY opcji, która ma również wpływ pomijania bibliotek domyślnych.

Błędy spowodowane ulepszoną zgodnością języka

Kompilator języka Microsoft C++ stale ulepszał zgodność ze standardem C++ na przestrzeni lat. Kod skompilowany we wcześniejszych wersjach może nie zostać skompilowany w nowszych wersjach programu Visual Studio. Dzieje się tak, ponieważ kompilator poprawnie flaguje błąd, który został wcześniej zignorowany lub jawnie dozwolony.

Na przykład /Zc:forScope przełącznik został wprowadzony na początku historii MSVC. Zezwala na niezgodne zachowanie zmiennych pętli. Ten przełącznik jest teraz przestarzały i może zostać usunięty w przyszłych wersjach. Zdecydowanie zalecamy, aby nie używać tego przełącznika podczas uaktualniania kodu. Aby uzyskać więcej informacji, zobacz /Zc:forScope- jest przestarzały.

Przykładem typowego błędu kompilatora, który może wystąpić podczas uaktualniania, jest przekazanie argumentu innego niż const do parametru const. Starsze wersje kompilatora nie zawsze flagowane jako błąd. Aby uzyskać więcej informacji, zobacz Bardziej rygorystyczne konwersje kompilatora.

Aby uzyskać więcej informacji na temat konkretnych ulepszeń zgodności, zobacz Visual C++ change history 2003 - 2015 and C++ conformance improvements in Visual Studio (Ulepszenia zgodności programu Visual C++ — 2003 — 2015 i C++).

Błędy obejmujące <stdint.h> typy całkowite

Nagłówek <stdint.h> definiuje definicje typów i makr, które, w przeciwieństwie do wbudowanych typów całkowitych, mają gwarancję określonej długości na wszystkich platformach. Oto przykłady uint32_t i int64_t. Nagłówek <stdint.h> został dodany w programie Visual Studio 2010. Kod napisany przed 2010 r. mógł dostarczać definicje prywatne dla tych typów. Te definicje mogą nie zawsze być zgodne z <stdint.h> definicjami.

Jeśli błąd to C2371 i stdint jest zaangażowany typ, prawdopodobnie oznacza to, że typ jest zdefiniowany w nagłówku w kodzie lub pliku biblioteki innej firmy. Podczas uaktualniania należy wyeliminować wszelkie niestandardowe definicje <stdint.h> typów, ale najpierw porównać definicje niestandardowe z bieżącymi definicjami standardowymi, aby upewnić się, że nie wprowadzasz nowych problemów.

Możesz nacisnąć klawisz F12 (Przejdź do definicji), aby zobaczyć, gdzie jest zdefiniowany typ.

Opcja kompilatora może być przydatna /showIncludes tutaj. W oknie dialogowym Strony właściwości dla projektu wybierz stronę Właściwości>konfiguracji C/C++>Advanced i ustaw opcję Pokaż zawiera wartość Tak. Następnie ponownie skompiluj projekt. W oknie danych wyjściowych #include zostanie wyświetlona lista plików. Każdy nagłówek jest wcięty pod nagłówka, który go zawiera.

Błędy związane z funkcjami CRT

Na przestrzeni lat wprowadzono wiele zmian w środowisku uruchomieniowym języka C. Dodano wiele bezpiecznych wersji funkcji, a niektóre zostały usunięte. Ponadto, jak opisano wcześniej w tym artykule, implementacja CRT firmy Microsoft została refaktoryzowana w programie Visual Studio 2015 w nowych plikach binarnych i skojarzonych plikach .lib .

Jeśli błąd obejmuje funkcję CRT, wyszukaj historię zmian języka Visual C++ 2003 — 2015 lub ulepszenia zgodności języka C++ w programie Visual Studio , aby sprawdzić, czy te artykuły zawierają dodatkowe informacje. Jeśli błąd jest LNK2019, upewnij się, że funkcja nie została usunięta. W przeciwnym razie, jeśli masz pewność, że funkcja nadal istnieje, a kod wywołujący jest poprawny, sprawdź, czy projekt używa elementu /NODEFAULTLIB. Jeśli tak, musisz zaktualizować listę bibliotek, aby używać nowych bibliotek uniwersalnych (UCRT). Aby uzyskać więcej informacji, zobacz sekcję powyżej dotyczącą biblioteki i zależności.

Jeśli błąd obejmuje printf metodę lub scanf, upewnij się, że nie definiujesz prywatnie żadnej funkcji bez dołączania stdio.hfunkcji . Jeśli tak, usuń definicje prywatne lub połącz z .legacy_stdio_definitions.lib Tę bibliotekę można ustawić w oknie dialogowym Strony właściwości w obszarze Właściwości konfiguracji Właściwości>wejściowe konsolidatora>, we właściwości Dodatkowe zależności. Jeśli łączysz się z zestawem Windows SDK 8.1 lub starszym, dodaj polecenie legacy_stdio_definitions.lib.

Jeśli błąd obejmuje argumenty ciągu formatu, prawdopodobnie dlatego, że kompilator jest bardziej rygorystyczny w zakresie wymuszania standardu. Aby uzyskać więcej informacji, zobacz historię zmian. Zwróć szczególną uwagę na wszelkie błędy, ponieważ mogą one potencjalnie stanowić zagrożenie bezpieczeństwa.

Błędy spowodowane zmianami w standardzie C++

Sam standard C++ ewoluował w sposób, który nie zawsze jest zgodny z poprzednimi wersjami. Język C++11 wprowadził semantyka przenoszenia, nowe słowa kluczowe oraz inne funkcje języka i standardowej biblioteki. Te zmiany mogą potencjalnie powodować błędy kompilatora, a nawet różne zachowanie środowiska uruchomieniowego.

Na przykład stary program C++ może zawierać iostream.h nagłówek. Ten nagłówek został przestarzały na początku historii języka C++ i ostatecznie został całkowicie usunięty z programu Visual Studio. W takim przypadku należy użyć <iostream> i ponownie napisać kod. Aby uzyskać więcej informacji, zobacz Aktualizowanie starego iostream kodu.

C4838: ostrzeżenie o zawężaniu konwersji

Standard C++ określa teraz, że konwersje z niepodpisanych do podpisanych wartości całkowitych są zawężające konwersje. Kompilator nie podniósł tego ostrzeżenia przed programem Visual Studio 2015. Sprawdź każde wystąpienie, aby upewnić się, że zawężenie nie ma wpływu na poprawność kodu.

Ostrzeżenia dotyczące używania bezpiecznych funkcji CRT

W ciągu lat wprowadzono bezpieczne wersje funkcji środowiska uruchomieniowego języka C. Mimo że stare, niezabezpieczne wersje są nadal dostępne, zaleca się zmianę kodu w celu korzystania z bezpiecznych wersji. Kompilator wyświetli ostrzeżenie dotyczące użycia niebezpiecznych wersji. Możesz wyłączyć lub zignorować te ostrzeżenia. Aby wyłączyć ostrzeżenie dotyczące wszystkich projektów w rozwiązaniu, otwórz pozycję Wyświetl>menedżera właściwości, wybierz wszystkie projekty, dla których chcesz wyłączyć ostrzeżenie, a następnie kliknij prawym przyciskiem myszy wybrane elementy i wybierz polecenie Właściwości. W oknie dialogowym Strony właściwości w obszarze Właściwości>konfiguracji C/C++>Advanced wybierz pozycję Wyłącz określone ostrzeżenia. Wybierz strzałkę listy rozwijanej, a następnie wybierz pozycję Edytuj. Wprowadź wartość 4996 w polu tekstowym. (Nie dołączaj prefiksu "C"). Aby uzyskać więcej informacji, zobacz Przenoszenie do korzystania z protokołu Secure CRT.

Błędy spowodowane zmianami w interfejsach API systemu Windows lub przestarzałymi zestawami SDK

Przez lata interfejsy API systemu Windows i typy danych zostały dodane, a czasami uległy zmianie lub usunięciu. Ponadto inne zestawy SDK, które nie należały do podstawowego systemu operacyjnego, przyszedł i zniknął. Starsze programy mogą zawierać wywołania interfejsów API, które już nie istnieją. Mogą również zawierać wywołania interfejsów API w innych zestawach SDK firmy Microsoft, które nie są już obsługiwane. Możesz zobaczyć błędy dotyczące brakujących interfejsów API systemu Windows lub interfejsów API ze starszych zestawów SDK firmy Microsoft. Możliwe, że interfejsy API zostały usunięte lub zastąpione przez nowsze, bezpieczniejsze funkcje.

Dokumentacja interfejsu API systemu Windows zawiera listę minimalnych lub maksymalnych obsługiwanych systemów operacyjnych. Aby uzyskać informacje na temat określonego interfejsu API systemu Windows, wyszukaj go w indeksie interfejsu API dla aplikacji klasycznych systemu Windows.

Wersja systemu Windows

Podczas uaktualniania programu korzystającego bezpośrednio lub pośrednio z interfejsu API systemu Windows należy zdecydować, czy minimalna wersja systemu Windows ma być obsługiwana. W większości przypadków system Windows 7 jest dobrym wyborem. Aby uzyskać więcej informacji, zobacz Problemy z plikiem nagłówka. Makro WINVER definiuje najstarszą wersję systemu Windows przeznaczoną do uruchamiania programu. Jeśli program MFC ustawia wartość WINVER 0x0501 (Windows XP), otrzymasz ostrzeżenie, ponieważ MFC nie obsługuje już xp, nawet jeśli sam zestaw narzędzi kompilatora ma tryb XP. Obsługa zestawu narzędzi kompilatora dla systemu Windows XP zakończyła się w programie Visual Studio 2017.

Aby uzyskać więcej informacji, zobacz Aktualizowanie docelowej wersji systemu Windows i Więcej nieaktualnych plików nagłówków.

ATL /MFC

ATL i MFC są stosunkowo stabilnymi interfejsami API, ale zmiany są wprowadzane od czasu do czasu. Aby uzyskać więcej informacji, zobacz Visual C++ change history 2003 - 2015, What's new for Visual C++ in Visual Studio and C++ conformance improvements in Visual Studio (Co nowego dla języka Visual C++ w programie Visual Studio) i C++ conformance improvements in Visual Studio (Co nowego w programie Visual Studio).

LNK 2005 _DllMain@12 już zdefiniowany w pliku MSVCRTD.lib

Ten błąd może wystąpić w aplikacjach MFC. Wskazuje problem z kolejnością między biblioteką CRT a biblioteką MFC. MFC musi być najpierw połączony, aby dostarczał new operatory i .delete Aby rozwiązać ten problem, użyj przełącznika /NODEFAULTLIB , aby zignorować następujące biblioteki domyślne: MSVCRTD.lib i mfcs140d.lib. Następnie dodaj te same biblioteki co dodatkowe zależności.

32 a 64-bitowe

Jeśli oryginalny kod jest kompilowany dla systemów 32-bitowych, możesz utworzyć 64-bitową wersję zamiast (lub oprócz) nowej aplikacji 32-bitowej. Ogólnie rzecz biorąc, najpierw należy skompilować program w trybie 32-bitowym, a następnie spróbować 64-bitowego. Kompilowanie dla 64-bitowej wersji jest proste, ale w niektórych przypadkach może ujawnić błędy ukryte przez kompilacje 32-bitowe.

Ponadto należy pamiętać o możliwych problemach z czasem kompilacji i środowiskiem uruchomieniowym dotyczących rozmiaru wskaźnika, wartości czasu i rozmiaru oraz specyfikatorów formatu specyficznego dla rozmiaru i printfscanf funkcji. Aby uzyskać więcej informacji, zobacz Configure Visual C++ for 64-bit, x64 targets and Common Visual C++ 64-bitowych problemów z migracją. Aby uzyskać więcej porad dotyczących migracji, zobacz Przewodnik programowania dla 64-bitowego systemu Windows.

Unicode vs MBCS/ASCII

Przed standaryzacją Unicode wiele programów używało wielobajtowego zestawu znaków (MBCS) do reprezentowania znaków, które nie zostały uwzględnione w zestawie znaków ASCII. W starszych projektach MFC MBCS było ustawieniem domyślnym. Podczas uaktualniania takiego programu zostaną wyświetlone ostrzeżenia, które doradzają zamiast tego używania formatu Unicode. Jeśli zdecydujesz, że konwersja na Unicode nie jest warta kosztu programowania, możesz wyłączyć lub zignorować ostrzeżenie. Aby wyłączyć go dla wszystkich projektów w rozwiązaniu, otwórz Okno >Menedżera właściwości, zaznacz wszystkie projekty, dla których chcesz wyłączyć ostrzeżenie, a następnie kliknij prawym przyciskiem myszy wybrane elementy i wybierz polecenie Właściwości. W oknie dialogowym Strony właściwości wybierz pozycję Właściwości>konfiguracji C/C++>Advanced. W właściwości Wyłącz określone ostrzeżenia otwórz strzałkę listy rozwijanej, a następnie wybierz pozycję Edytuj. Wprowadź wartość 4996 w polu tekstowym. (Nie dołączaj prefiksu "C"). Wybierz przycisk OK , aby zapisać właściwość, a następnie wybierz przycisk OK , aby zapisać zmiany.

Aby uzyskać więcej informacji, zobacz Przenoszenie z MBCS do Unicode. Aby uzyskać ogólne informacje o MBCS a Unicode, zobacz Tekst i ciągi w visual C++ i internationalization .

Zobacz też

Uaktualnianie projektów z wcześniejszych wersji programu Visual C++
Ulepszenia zgodności języka C++ w programie Visual Studio