2014-04-10 16 views
8

Nie mogę znaleźć wiele dokumentacji, ale ostatnio musiałem uruchomić narzędzie do testowania platformy Windows Server 2012 R2 w celu sprawdzenia poprawności niektórych produktów MSVC++ i C# (.exe, usług, bibliotek, bibliotek dll itd.) I napotkałem błąd wiadomości informujące, że ustawienie supported supported nie było dostępne w niektórych manifestach projektu.Co ustawienie obsługiwane przez manifest w rzeczywistości robi za kulisami?

Naprawiłem błędy, ale nie mogę się powstrzymać, zastanawiając się, co to jest ustawienie supportedOS za kulisami. Załóżmy na przykład, że ustawiłem ustawienie supportedOS na Windows 8.1 dla wszystkich moich projektów, czy zaczną one zgłaszać błędy w przypadku uruchamiania tych produktów w systemie Windows 8 lub Windows 7, mimo że są one znane z tego, że działają na tych systemach operacyjnych?

Najbardziej udało mi się znaleźć na supportedOS jest rzeczy tak: http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074(v=vs.85).aspx

+1

To wydaje się odpowiadać na twoje pytanie: http://msdn.microsoft.com/en-us/library/windows/desktop/dd371711%28v=vs.85%29.aspx –

+0

Przeczytałem to jeszcze raz. Po prostu mówi: "Wartość dodawania identyfikatorów GUID dla obu systemów operacyjnych w powyższym przykładzie polega na zapewnieniu wsparcia na poziomie niższym." Więc powinienem po prostu założyć, że te identyfikatory GUID są używane tylko do obsługi niższego poziomu? AKA, tylko "przyszła" wersja systemu operacyjnego (system operacyjny po ostatniej wersji GUID w aplikacji) użyje tych identyfikatorów GUID do zapewnienia zgodności obsługi aplikacji z wersją systemu operacyjnego, do której odnoszą się identyfikatory GUID? – Alexandru

+0

Och, rozumiem, co masz na myśli - chcesz wiedzieć, co się stanie, jeśli manifest, na przykład, mówi, że aplikacja * tylko * obsługuje system Windows 8, a nie wcześniejsze wersje, i próbujesz uruchomić go w systemie Windows 7. –

Odpowiedz

2

Pseudo kod jak Windows odczytuje wartości supportedOS może wyglądać mniej więcej tak:

double compatVer = 4.0; // Win95 
if (hasW10guid && _WIN_VER >= 0xa00) 
    compatVer = 10.0; 
else if (hasW81guid && _WIN_VER >= 0x603) 
    compatVer = 6.3; 
else if (hasW8guid && _WIN_VER >= 0x602) 
    compatVer = 6.2; 
else if (hasW7guid && _WIN_VER >= 0x601) 
    compatVer = 6.1; 
else if (hasWVistaguid && _WIN_VER >= 0x601) 
    compatVer = 6.0; // Application wants Vista compatibility on Win7+ 
else if (hasRequestedExecutionLevel) 
    compatVer = 6.0; // UAC compatible 

compatVer są przechowywane gdzieś wewnętrznie w proces, prawdopodobnie w PEB.

compatVer jest porównywany z rzeczywistą wersją systemu Windows w niektórych funkcjach, aby włączyć nowe funkcje lub zmienić jego zachowanie, aby był zgodny z wersją systemu Windows, dla której została zaprojektowana. Niektóre zmiany zachowań są udokumentowane na stronie MSDN w wersji compatibility cookbook.

Ponieważ wartości obsługiwane są identyfikatory GUID, nie można ich zgadnąć, więc deweloperzy nie mogą ubiegać się o wsparcie dla wersji systemu Windows, które nie zostały jeszcze wydane. W związku z tym identyfikator GUID systemu Windows 8 nie będzie działał, gdy aplikacja będzie działać pod kontrolą systemu Windows 7.

Istnieje ryzyko, że aplikacja ma błąd, który jest ukryty w wyniku zachowania zgodności i może zostać ujawniony przez dodanie wartości supportedOS ...

+0

I zanim ktoś zapyta o sprawdzenie wersji Windows na 0x601 dla GUID Vista; Obsługiwane wartości nie istnieją w systemie Vista, ta sekcja manifestu jest używana tylko w systemie Windows 7 i nowszych. – Anders

+0

Nie jest dla mnie jasne, co szczególnie dotyczy zwykłej aplikacji .NET (konsola, WinForms, WPF) z książki kucharskiej MSDN. Czy może przynieść jakieś korzyści związane z wydajnością? – xmedeko

+0

@xmedeko Może mieć pewne niewielkie korzyści z DirectX i niektórymi funkcjami jądra, ale głównym powodem ich istnienia jest możliwość wykrycia wersji 8.1 i 10, ponieważ interfejsy API wersji bez nich nie zgłaszają niczego powyżej 8.0. – Anders