Zgodność ze starszym Windows

W Windows od XP w górę, we właściwościach pliku EXE jest zakładka "Zgodność" i tam między innymi jest lista różnych wersji systemu Windows, z której wybiera się wersję, z którą dany program jest kompatybilny.

Zdarzało mi się parę razy z tego korzystać, a właściwie próbować, ale nigdy nie uzyskałem działającego programu, podczas, gdy ten sam program, w prawdziwej wersji systemu Windows działa poprawnie. Z tego wnioskuję, ze to jest taki bardziej pic na wodę fotomontaż.

Między innymi próbowałem następujące przypadki:

• Gra z Windows 98 uruchamiana na Windows XP 32-bit
• Sterownik z Windows 7 64-bit uruchamiany na Windows 8 64-bit
• Jakiś program użytkowy z Windows 98 lub XP 32-bit uruchamiany na Windows 8 64-bit

Nie przypominam sobie przypadku, w którym to ustawienie umożliwiło działanie programu, jedynym ratunkiem było postawienie maszyny wirtualnej z prawdziwą starą wersją Windows.

Na czym polega na niby kompatybilność, skoro to i tak nie działa? Ja zakładam, że to ustawienie jest właśnie po to, żeby system Windows udawał starą wersję Windows na użytek tego konkretnego programu, ale okazuje się, że tak nie jest, skoro to się nie dzieje.

Jeżeli program w Windows XP udającym Windows 98 nie działa, mimo, że ten program w prawdziwym Windows 98 działa, to znaczy, że ten udawany Windows 98 nie jest kompatybilny z Windows 98. W takim razie, czym jest ta niby zgodność z Windows 98 ustawiona w Windows XP?

Nie lepiej używać aktualnych systemów i aplikacji a nie bawiąc się w archeologię ?

A tutaj na temat 'compatibility-mode`
https://superuser.com/questions/133746/how-does-the-compatibility-mode-in-windows-work

z raz albo dwa lata tego użyłem, ale to mogło być za czasów jak jeszcze kawaletem byłem :D
i nawet pomogło.

Jest taka jedna gra jaka mnie interesuje Kozaki powrót na wojnę - tego nigdy nie odpalisz aby działało na systemie od 10 w górę. Próbowałem już wszystkie, setki poradników, zmian, ustawień i nic to nie dało. Nie raz po prostu na windowssie się nie da. Trzeba mieć osobną partycję i na niej stary system i wtedy korzystać. Inaczej bywa że się nie da.

Może to rozwiązanie Ci pomoże:
https://github.com/otya128/winevdm/releases

windows 7 64b miał tryb zgodności z XP, gdzie dostawałeś XPka na wirtualce i w nim się odpalał program

Nie lepiej używać aktualnych systemów i aplikacji a nie bawiąc się w archeologię ?

Ja generalnie używam współczesnych systemów i aplikacji, a do ewentualnej zabawy w archeologię stawiam maszynę wirtualną lub emulator, bo to zawsze działa, często lepiej niż kombinacje wymuszające zgodność. Dlatego przypadków użycia zgodności można liczyć na palcach jednej ręki. Inaczej, to by obu rąk nie starczyło.

Pytanie nie jest, jak zmusić nowoczesny Windows do uruchomienia staroświeckiego programu, tylko pytanie jest, czym tak naprawdę jest ta zgodność w ustawienia pliku exe, skoro to nie daje kompatybilności. Widocznie ja mam błędne wyobrażenia spowodowane opisami wprowadzającymi w błąd i to ustawienie nie jest udawaniem starego systemu, tylko czymś innym.

Jest taka jedna gra jaka mnie interesuje Kozaki powrót na wojnę - tego nigdy nie odpalisz aby działało na systemie od 10 w górę. Próbowałem już wszystkie, setki poradników, zmian, ustawień i nic to nie dało. Nie raz po prostu na windowssie się nie da. Trzeba mieć osobną partycję i na niej stary system i wtedy korzystać. Inaczej bywa że się nie da.

A jak zainstalujesz VirtualBox lub VMWare Player, wewnątrz którego zainstalujesz Windows 98 lub Windows XP, to ta gra od razu zadziała. Jak chcę grę dla DOS, to od tego jest DosBox. Jak chcę cały staroświecki PC z Dos lub Windows <=98, to jest Bochs i PCem.

Z takimi poradnikami i próbami, to jest inny problem. Masz np. 20 poradników, każdy przejdziesz od początku do końca, każdy coś tam wniesie, coś tam zmodyfikuje, ale po ostatnim gra ruszy. A później, jak będziesz chciał grę uruchomić na innym komputerze, to nie będziesz pamiętać, co trzeba zrobić, albo też będziesz pamiętać, który przeszedłeś, a i to nie poskutkuje, bo jakaś czynność z innego poradnika (nawet nie pamiętasz z którego i jaka, bo tyle tego było) plus ten ostatni poradnik razem dały oczekiwany skutek. A i samo istnienie kilku bezskutecznych poradników jest dowodem na to, że między komputerami systemy są tak różne (nie chodzi tu o wersje Windows, tylko o całą zawartość, czyli poinstalowane programy, sterowniki, dodatkowe biblioteki). Ktoś pokombinował, uruchomił grę, opisał krok po kroku, co zrobił, ale inna osoba nie uruchomi gry, bo jest jakaś różnica, która ma kluczowe znaczenie dla możliwości wykonania jakiejś czynności.

Amatorzy-hobbyści (skoro programy są open source, to znaczy, że na nich nie zarabiają) zrobili to lepiej niż Microsoft. Nawet sam Microsoft ma problemy z kompatybilnością, bo Microsoft Virtual PC 2007 na Windows XP działa poprawnie, ale na Windows 8 nie działa wcale. Jak się coś tam pozmienia w plikach systemowych, to ruszy, ale jest ryzyko, że się rozleci Windows, pomimo, że Windows jest od Microsoft i program też od Microsoft. Generalnie zrobiłem jedną próbę i uznałem, że skoro są z tym jakieś problemy, to zrezygnowałem z Microsoft Virtual PC na rzecz VirtualBox.

@andrzejlisek: umieściłem linka z wyjaśnieniem jak działa, chyba muszę wkleić,

Compatibility mode is achieved using so called shims. There is a good article on TechNet describing how these work.

Windows application files contain an import table which tells the application loader which DLLs the application needs and which functions it uses from them. A process might for example reference GetVersionEx in the kernel32.dll. When a program shall run in compatibility mode, then the shim is put between the application and the shim replaces the GetVersionEx function, so that the application does not call GetVersionEx from kernel32.dll but the GetVersionEx in the shim. The shimmed functions then implement the behaviour of previous Windows versions. GetVersionEx is an easy sample, each Windows version returns its own version numbers in GetVersionEx, so when faking an old Windows the GetVersionEx function now not returns the Windows 7 version numbers but for example the Windows XP version numbers. So the application will believe it is running on Windows XP.

There have also been some other changes from Windows version to Windows version. In older versions for example, if a program loaded a DLL, the search path for the DLL also included the current directory. This is a security issue, so newer versions of Windows by default don't search in the current directory. With the proper shim you can simulate the old behaviour.

Since shims are just a layer between the application and the Windows API a shim can just do what the application could do itself. The shim cannot be used for example to circumvent UAC or access protected files.

If you want to know more, here are some links you might find interesting:

Using the CorrectFilePaths Shim to Redirect Files on Windows Vista
Creating an Application Compatibility Shim with the Microsoft Application Compatibility Toolkit
MSDN blog on internal basics of shims

Especially Microsoft Application Compatibility Toolkit is worth a look. This tool gives you an overview over the applications with known issues, all available compatibility fixes and modes and which fixes are applied to each application.

raczej nie bylo tworzone dla gier i aplikacji normalnych uzytownikow

raczej nie bylo tworzone dla gier i aplikacji normalnych uzytownikow

Jednym zdaniem mówiąc, rozumiem, że ta "kompatybilność" polega tak naprawdę na wprowadzeniu warstwy pośredniej między programem, a systemem, która podstawia swoją implementację tych funkcji WinApi, których działanie różni się między bieżącą wersją, a "symulowaną" wersją Windows. Jeżeli nie do zwykłych gier i programów, to do jakich zastosowań to było wymyślone?

Z drugiej strony, jeżeli każdy jeden program, pośrednio lub bezpośrednio używa WinApi, to jeżeli w miejsce niekompatybilnych funkcji WinApi podstawi się kompatybilne funkcje WinApi, o ile nie jest to sprzeczne z działaniem bieżącej wersji (np. nie jest możliwe automatyczne żądanie praw admina bez udziału użytkownika), to wydaje się, że właśnie najpierw uruchomi się zwykłe, typowe programy, a później ewentualnie jakieś bardzo specjalistyczne aplikacje. Fakt, że kompatybilności 100% tą metodą nie da się zrobić, ale powiedzmy w przypadku kompatybilności 80%, to prędzej ruszy jakaś gierka niż nietypowy program. Tak samo, jak WINE w Linux. On nie jest w pełni kompatybilny z WinApi i nigdy nie będzie, ale właśnie prędzej zadziała "zwykły" program niż coś nietypowego.

ja myślałem raczej o korporacyjnym rynku, kiedyś jednak nie było aplikacji webowych, chodziło o utrzymanie przy życiu działających aplikacji.
Gry bym zaliczył raczej do nietypowego oprogramowanie szczególnie jak korzystają z api z okolic 3dfx

MiM napisał(a):

Może to rozwiązanie Ci pomoże:
https://github.com/otya128/winevdm/releases

Jeśli chodzi o gry, to jeszcze jest https://fdossena.com/?p=wined3d/index.frag

W ogóle to jest dość ciekawe, że do starych programów lepsza kompatybilność jest pod Linuchem z Wine niż pod nowym Windowsem :)

Cóż, Microsoft kiedyś musiał powiedzieć dość utrzymywaniu kompatybilności wstecznej ze starociami, zostawiając tylko tryb pseudo kompatybilności który pomaga tylko małemu odsetkowi programów

Piszę słabo znając się na temacie, ale się wypowiem to może się coś nauczę ?

Ja bym strzelał, że polega na tym, że wincrap ma gdzieś stare wersje dynamicznych libek poprawione i pokompilowane aby działały pod nowym windowsem, jądrem systemu, nowymi syscallami etc. Natomiast jest zgodność z ABI, więc pradawne apki działają używając zmienionej wersji takiej dll'ki.

O ile kojarzę, jak deklaracje funkcji muszą pozostać bez zmian to już zmienianie definicji nie wpływa na zgodność z ABI - program się uruchomi.
Czyli w nowym libc z void* malloc( size_t allocsize ), gdzie ty linkowałeś do czegoś z void *malloc( size_t allocmem_size ) to już nie zadziała.
Ale w samym ciele malloca możesz grzebać.

Przy czym na windowsie, moje mgliste pojęcie podpowiada mi, że dominuje mentalność kompilowania wszystkiego statycznie. Więc problem niezgodnośc abi nie powinien istnieć, przecież libc też wrzucilismy do naszego programu? No ale wyobrażam sobie, że dawne malloc które statycznie siedzi w naszej apce użwa starych syscalli których nie ma. Nowe malloc na naszym systemie używa czego innego.
Czyli byśmy musieli te stare syscalle wspierać.

Tryby zgodności włączają różne hacki które upodabniają działanie systemu do poprzednich wersji oraz do starszego sprzętu. Trywialnym przykładem może być kłamanie na temat wersji systemu - gdyby jakaś aplikacja sprawdzała niepotrzebnie albo nieprawidłowo wersję. Albo kłamanie nt. ilości wolnego miejsca na dysku, gdyby instalator sprawdzał to zbyt małym intem i przekręcała mu się wartość. Tych hacków jest sporo, a "tryb zgodności" z konkretnym Windowsem (98, XP, itd.) włącza jakiś ich predefiniowany zestaw. Z tym, że w zakładce "Zgodność" mamy dość ograniczone pole manewru - kilka predefiniowanych trybów i kilka checkboxów:

Znacznie więcej możliwości daje program Compatibility Administrator, gdzie jest do wyboru ogromna liczba takich fixów które mają poprawić kompatybilność:

Przykładowo tutaj dla pliku Heroes3.exe ustawione jest odpalanie z przekłamaną wersją systemu i wymuszonym jednym rdzeniem procesora (czyli znacznie mniej niż normalnie robiłby tryb zgodności z Windows 98):

przy czym ja tego wpisu nie robiłem - dodał to automatycznie instalator gry.

Compatibility Administrator to takie znacznie bardziej zaawansowane GUI na ten sam mechanizm trybów zgodności co w zakładce Zgodność we właściwościach exeka.