x64 - visual c++ download




Build für Windows NT 4.0 mit Visual Studio 2005? (4)

Die Idee ist, dass die exe benötigt wird, um eine Verbindung zur statischen Bibliothek herzustellen.

Bitte versuchen Sie diese "Konfigurationseigenschaften", "Allgemein", "Verwendung von MFC", um "MFC in einer statischen Bibliothek zu verwenden", "Konfigurationseigenschaften", "Allgemein", "Verwendung von ATL" zu "Statischer Link zu ATL"

"Konfigurationseigenschaften", "C \ C ++", "Codegenerierung", "Laufzeitbibliothek" zu "Multi-Threaded (\ MT)"

Testplattform Build Machine: Visual Studio 2005 auf Windows XP SP2-Clientcomputer: Windows XP SP2 (kein VS2005 installiert)

Eine MFC-Anwendung, die ich zu migrieren versuche, verwendet afxext.h , was bewirkt, dass _AFXDLL gesetzt wird, was diesen Fehler verursacht, wenn ich /MT setze:

Bitte verwenden Sie den / MD-Schalter für _AFXDLL-Builds

Meine bisherigen Untersuchungen zeigen, dass es unmöglich ist, eine Anwendung für die Ausführung unter Windows NT 4.0 mit Visual Studio (in diesem Fall C ++ 2005) zu erstellen.

Ist das wirklich wahr? Gibt es einen Workaround?


Die Problemumgehung besteht darin, die Multithreaded-DLL zu reparieren. Einfache Anweisungen . Kurze Zusammenfassung:

Die Versand-8.0-C-Laufzeitbibliotheks-DLL (MSVCR80.DLL) unterstützt NT 4.0 SP6 nicht nur aus einem Grund und nur aus einem Grund: jemand bei Microsoft fügte einen Funktionsaufruf zu GetLongPathNameW der nicht in kernel32.dll unter NT 4.0 vorhanden ist.

CRTLIB.C In Zeile 577 wird GetLongPathNameW . Ersetzen Sie es einfach durch: ret = 0; Verwenden Sie diesen Build von MSVCR80.DLL nur unter NT 4.0.

Sobald Sie diese arbeiten haben, sollte eine generische Lösung trivial sein.


Obwohl ich nicht mit afxext.h vertraut bin, frage ich mich, was es macht es inkompatibel mit Windows NT4 ....

Um jedoch die ursprüngliche Frage zu beantworten: "Meine bisherigen Untersuchungen zeigen, dass es unmöglich ist, eine Anwendung für die Ausführung unter Windows NT 4.0 mit Visual Studio (in diesem Fall C ++ 2005) zu erstellen."

Die Antwort sollte ja sein, besonders wenn die Anwendung ursprünglich geschrieben wurde oder unter NT4 läuft! Mit dem afxext.h Ding beiseite, sollte dies ein einfaches JA sein.

Die andere Sache, mit der ich Probleme habe, ist die lockere Natur, in der die Leute die NT-Amtszeit hinauswerfen. Zugegeben, die meisten Leute denken an 'NT' als Windows NT4, aber es ist immer noch zweideutig, weil 'die meisten Leute' nicht gleich 'allen Leuten' sind.

In Wirklichkeit ist der Begriff "NT" gleichbedeutend mit der NT-Reihe. Die NT-Serie ist NT3, NT4, NT5 (2000, XP, 2003) und NT6 (Vista).

Win32 ist ein Subsystem, auf das Sie auch Ihren C / C ++ - Code ausrichten. So sehe ich keinen Grund, warum man nicht diese NT4-Plattform u. Subsystem zielt oder, wenn es eine Plattformportübung ist, die MFC-Abhängigkeiten entfernen, die VC möglicherweise auferlegt.

Wenn ich die afxext.h dem Mix hinzufüge, klingt es für mich wie ein Subsystem-Kompatibilitätsproblem. Es ist Teil von MFC aus meiner Google-Forschung. Die afxext.h scheint die MFC-Erweiterungen (Microsoft Foundation Class) zu sein.

Können Sie Ihre Abhängigkeit von MFC entfernen? Welche Art von Anwendung ist das? (CLR, Dienst, GUI-Schnittstelle?) Können Sie ein Projekt in ein nicht verwaltetes C ++ - Projekt in VC 8.0 konvertieren?

Hoffentlich hilft Ihnen etwas davon.


Um den _AFXDLL-Fehler loszuwerden, haben Sie versucht, auf die Einstellungen zu wechseln, um MFC als statische Bibliothek anstelle einer DLL zu verwenden? Dies ähnelt dem, was Sie bereits beim Ändern der Laufzeitbibliotheken in statische anstelle von DLL tun.





windows-nt