Es kursiert ja bereits das Windows Developer Preview, also eine virtuelle Maschine mit der man in die nächste Windows 8 und Visual Studio Version hinein schnuppern kann.
Mein Mit-MVP Mike Ryan hat nun bei Tests festgestellt, dass die mit der neuen Visual Studio Version erzeugten Programme, die die MFC 11 und CRT 11 benutzen nicht mehr unter Windows XP laufen ❗ 😮 Aus eigenen Tests kann ich das noch nicht bestätigen.
Das ist mit großer Sicherheit ein Killerkriterium… zumindest ist es das in unserer Firma.
Mich wundert das, vor allem weil der Support für Windows XP auch noch bis 2014 läuft und wenn man Statistiken glauben darf, dann ist die Häufigkeit der Verwendung von Windows XP erst seit Juli diesen Jahres unter die 50% Marke gefallen.
Auf Connect wurde ein entsprechende Bug-Report eröffnet, es gibt hier die Möglichkeit mit den eigenen Stimmen für etwas Widerstand zu sorgen:
https://connect.microsoft.com/VisualStudio/feedback/details/690617
Also bitte gebt Eure Stimme ab!
Da die nächste VS Version vermutlich noch bis Herbst nächsten Jahres auf sich warten lässt kann man nur hoffen, dass sich das ändern wird.
Nachtrag 26.09.2011: Weitere Details zu den fehlenden Funktionen siehe Kommentare
Nachtrag 29.09.2011: Es scheint kein Zufall oder eine vorläufige Beschränkung zu sein. Der Bug wurde mit By Design geschlosen ❗ Ich kann dennoch nur raten auf deisem case weiter mit Stimmen abzugeben.
Der Linker setzt den Wert für die Mindestversion automatisch auf 6.0, also Windows Vista. Wenn man diesen stattdessen im Linker-Konfigurationsdialog auf 5.1 setzt, dann startet das Programm wieder unter XP. Allerdings stört sich am fehlenden Export für CompareStringEx aus der KERNEL32.DLL, das nun statt CompareString in der CRT verwendet wird.
Die Änderung der Mindestversion scheint also mit Absicht passiert zu sein. Das könnte man zur Not noch selbst beheben, aber mit der Laufzeit wird es schon schwieriger.
Danke für Deinen Kommentar, allerdings ist nach Mike Ryan die Liste der Funktionen extrem viel länger. Wie gesagt, aktuell kann ich es noch nicht nachvollziehen (aktuell habe ich etwas wenig Zeit dafür), aber hier die Liste we Sie von Mike geführt wird:
In XP fehlende Funktionen in der msvcr110.dll:
kernel32.dll:
FlsGetValue
FlsSetValue
FlsAlloc
FlsFree
FlushProcessWriteBuffers
GetCurrentProcessorNumber
CreateSemaphoreExW
GetTimeFormatEx
GetDateFormatEx
CompareStringEx
LocaleNameToLCID
GetLocaleInfoEx
EnumSystemLocalesEx
GetTickCount64
IsValidLocaleName
LCMapStringEx
In XP fehlende Funktionen in der mfc110.dll:
kernel32.dll:
GetTickCount64
ApplicationRecoveryFinished
ApplicationRecoveryInProgress
RegisterApplicationRecoveryCallback
RegisterApplicationRestart
GetThreadPreferredUILanguages
user32.dll:
ChangeWindowMessageFilter
shell32.dll (delay loaded)
InitNetworkAddressControl
SHCreateItemFromParsingName
SHGetKnownFolderPath
uxtheme.dll (delay loaded)
DrawThemeTextEx
BufferedPaintUnInit
EndBufferedPaint
BeginBufferedPaint
BufferedPaintInit
propsys.dll (delay loaded)
PSGetPropertyDescriptionListFromString
dwmapi.dll (delay loaded)
DwmIsCompositionEnabled
DwmDefWindowProcDwmExtendFrameIntoClientArea
DwmSetWindowAttribute
Wem es noch nicht aufgefallen ist: Der case wurde geschlossen!
Dann bleiben wir halt bei vPrev 😉
Hi!
Ist es denn wie in VS2010 möglich für ältere MFCs zu kompilieren?
Also für 9,10 und halt 11?
Sicher! Das ist möglich, man kann dann aber nicht den neuen Compiler und die weiteren STL und Lambda Features benutzen…
Ich verstehe es immer noch nicht!
Der Support für WinXP ist leider nur noch Extended Support. Das bedeutet, dass nur noch Patches und Updates für XP veröffentlicht werden. Andere MS Produkte werden also nur noch Vista/win7/Win8 unterstützen. Das ist also kein Bug, das ist Absicht.
Mir ist klar, dass es Absicht ist, aber es entspricht nicht den Realitäten und den Bedürfnissen, die viele C++ Entwickler noch haben.
Für alle Entwickler, die mit VS2011 nicht zufrieden sind, gibt es doch auch noch VS2010, 2008 und 2005, Netbeans, Eclipse, etc…
These are the functions that a simple Win32 statically linked wizard generated app are dependent on:
LCMapStringEx – missing on XP but can be simulated using ID to locale name (nlsdl.dll) and calling LCMapString instead. (will be broken for „name only“ locales obviously)
Fls* functions – FlsAlloc, FlsGetValue, FlsSetValue, FlsFree – use GetProcAddress for these like CRT 10 does.
GetTickCount64 – missing on XP but here’s an implementation (from Chinese site)
http://blog.csdn.net/wr960204/article/details/6073192
I’ll put together a simple drop-in to allow running on XP for at least simple Win32 statically linked Windows and console apps.