Dlaczego w 64-bitowym systemie operacyjnym nie można uruchomić 16-bitowej aplikacji?

38

Dlaczego tak jest:

32-bitowy system operacyjny zainstalowany na 64-bitowym procesorze może obsługiwać stare 16-bitowe aplikacje,
ale jeśli zainstalujesz 64-bitowy system operacyjny, nie będzie on mógł bezpośrednio uruchamiać tych aplikacji i wymagać jakiejś emulacji (która nie zawsze działa idealnie)?

Mówiąc ściślej, mam 64-bitowy procesor (Intel Core 2 Duo). Kiedy miałem zainstalowany system Windows XP i Windows 7 (oba 32-bitowe), mogły one uruchamiać stare aplikacje DOS i 616-bitowe Windows.

Teraz zainstalowałem 64-bitową wersję systemu Windows 7. Dlaczego nie można już uruchamiać tych samych aplikacji?

— fixer1234
źródło

3

Myślę, że ma to mniej wspólnego z bitami, a więcej z systemem operacyjnym gościa. Do jakich systemów operacyjnych się odnosisz?

— Pekka obsługuje GoFundMonica

Czy będzie działał pod DOSBox?

— Penguat

1

Istnieje narzędzie o nazwie DOSBOX to 16-bitowy emulator, który daje 16-bitowemu programowi wirtualny 16-bitowy komputer do pracy i jest bezpłatny.

Zgadzam się z Pekką, faktem jest, że 64-bitowy (sprzętowy) system może uruchamiać 16-bitowy kod (do cholery, nawet 1-bitowy kod, jeśli system operacyjny został tak zaprojektowany). Prawdziwym problemem jest to, że procesor nie może bezpośrednio uruchomić 16-bitowego kodu z powodu takich rzeczy, jak różne rozmiary wskaźników, ale te problemy mogą zostać usunięte przez system operacyjny. Ograniczenie jest sztuczne, narzucone przez Microsoft w celu uproszczenia (choć nadal emulują 32-bit, ponieważ wciąż jest tak dużo 32-bitowego kodu). Istnieją inne systemy operacyjne (* nix?), Które bez problemu mogą uruchamiać 16-bitowy kod.

— Synetech

Mylisz system Windows z całym systemem operacyjnym.

— Ken Sharp

24

Z mojego zrozumienia wynika, że sam procesor nie obsługuje przejścia w tryb 16-bitowy podczas pracy w trybie długim (tryb macierzysty x64). Zobacz Wikipedia . Aby więc obsługiwać tryb 16-bitowy, NTVDM (16-bitowa warstwa w systemie Windows) musiałby w pełni emulować 16-bitowy procesor.

Przypuszczam, że ważyli ponowne wdrożenie warstwy emulacyjnej w porównaniu z użyciem już istniejącego oprogramowania do wirtualizacji (VirtualPC, VirtualBox), aby sobie z tym poradzić, i postanowiono wyciąć VDM.

— Matt Sieker
źródło

6

Cytowanie z Wikipedii : Wersje Windows NT dla architektur 64-bitowych (x64 i IA-64) nie zawierają NTVDM i nie są w stanie uruchomić DOS lub 16-bitowych aplikacji Windows. Wynika to z faktu, że w procesorze x86-64 tryb wirtualny 8086 jest dostępny jako pod-tryb tylko w jego starszym trybie (dla 16- i 32-bitowych systemów operacyjnych), a nie w natywnym, 64-bitowym trybie; wymagany jest twardy reset procesora, aby przejść do trybu starszego typu. Tak więc jedyny sposób, w jaki dotychczas działał NTVDM, nie jest już dostępny, a pełnych maszyn wirtualnych jest mnóstwo, więc NTVDM został odcięty.

— Joey

5

Fuj, nie mogę uwierzyć, że zrzucili tryb V86. Równie dobrze można rzucić tryb rzeczywisty i wymagać 32/64-bitowych programów ładujących, jeśli masz zamiar to zrobić.

— Brian Knoblauch,

5

Dokładnie tak się już stało, M. Knoblauch. Nowoczesna maszyna x86 z oprogramowaniem EFI przechodzi od trybu nierealnego w kilku pierwszych instrukcjach do trybu chronionego 64/32-bit. Programy ładujące są w rzeczywistości 64/32-bitowymi programami w trybie chronionym. Takie są aplikacje rozruchowe EFI. Nigdzie w tym procesie nie ma zastosowania trybu rzeczywistego ani trybu chronionego v8086.

— JdeBP,

3

-1. WINE obsługuje uruchamianie 16-bitowych aplikacji Windows w trybie VM86 na 64-bitowym systemie Linux. zrzut ekranu . Strona projektu V86-64 . Odpowiedź Mehrdada wydaje się być bardziej przekonującym powodem.

— Hugh Allen

3

@HughAllen: na tej stronie jest obecnie napisane: „Obecnie 64-bitowa wersja jądra Linuksa nie obsługuje trybu V86, ponieważ nie jest obsługiwana w natywnym trybie operacyjnym (tryb długi) tych procesorów”. i „Ta łatka jest bardzo eksperymentalna ”. Krótka odpowiedź jest taka, że chociaż możliwe jest uruchomienie kodu 16-bitowego, całkowite wyjście z trybu długiego nie jest rozsądne .

— Harry Johnston,

14

Ponieważ uchwyty 64-bitowe mają 32 znaczące bity :

Pamiętaj, że 64-bitowy system Windows nie obsługuje uruchamiania 16-bitowych aplikacji opartych na systemie Windows.
Głównym powodem jest to, że uchwyty mają 32 znaczące bity w 64-bitowym systemie Windows.
Dlatego uchwytów nie można obcinać i przekazywać do aplikacji 16-bitowych bez utraty danych.

W systemie Windows programy przekazują „uchwyty” do systemu operacyjnego i odwrotnie (są to liczby używane przez system operacyjny do jednoznacznej identyfikacji określonego zasobu, takiego jak okno).

Aby obsługiwać programy 16-bitowe, 32-bitowy system Windows generuje tylko uchwyty, które mają 16 znaczących bitów - 16 górnych bitów jest ignorowanych przez system operacyjny (nawet jeśli programy nie wykorzystują tego faktu). Dlatego żaden program nie może wchodzić w interakcje z więcej niż 2 ¹⁶ obiektami, co w rzeczywistości jest raczej niskie.

Jednak, aby to poprawić, 64-bitowy system Windows zwiększył liczbę znaczących bitów w uchwycie do 32. Ale teraz oznacza to, że uchwyty nie mogą być przekazywane do programów 16-bitowych bez utraty informacji. Dlatego programy 16-bitowe nie mogą działać w 64-bitowym systemie Windows.

— Mehrdad
źródło

3

@Joey: Nie rozumiem co mówisz. Jeśli system operacyjny to 64-bitowy system Windows, aplikacje 16-bitowe nie mogą na nim działać, kropka. Nie rozumiem, w jaki sposób fakt, że są to aplikacje „DOS” lub „Windows”, coś tu zmienia - w każdym razie uchwyty musiałyby zostać obcięte przez aplikację.

— Mehrdad

1

Aplikacje DOS nie mają uchwytów. W rzeczywistości (zwykle) nawet nie wiedzą, że działają w systemie Windows.

— Joey,

1

... właściwie nawet kod Win16 nie powinien stanowić większego problemu, teraz, gdy o tym myślę. Wszystko czego potrzebujesz to tabela przeglądowa.

— Harry Johnston,

1

@HarryJohnston: Myślę, że brakuje ci problemu. Co proponujesz, co powinno się stać z twoją wyobrażoną „tabelą odnośników”, gdy aplikacja zadzwoni EnumWindowsi w systemie jest więcej niż 2 ^ 16 okien?

— Mehrdad

1

Mówiłem o uchwytach jądra zgodnie z artykułem, a nie uchwytach okien. To są zupełnie różne rzeczy. Czy 16-bitowe aplikacje widzą nawet 32-bitowe okna? Wydaje się to mało prawdopodobne, ponieważ struktury komunikatów są różne; co by się stało, gdyby 16-bitowej aplikacji wysłano wiadomość z 32-bitowym wParam? Należy również pamiętać, że maksymalna liczba uchwytów okien nadal wynosi 2 ^ 16 według msdn.microsoft.com/en-us/library/windows/desktop/…

— Harry Johnston

10

W przypadku systemu Windows jest tak, ponieważ wersje systemu operacyjnego x86 zawierają 16-bitową emulację, która pozwala im uruchamiać starsze procesy DOS. W wersjach x64 muszą już emulować wykonanie x86 (nazywają to WoW64), aby umożliwić uruchomienie procesów 32-bitowych, i chyba Wow64 do dalszej emulacji 16-bitowego emulatora spowodował zbyt wiele problemów.

Uruchomi się garść rozpoznanych 16-bitowych procesów, ponieważ emulacja jest na stałe zakodowana, aby je obsłużyć, ale reszta nie działa, ponieważ emulacji nie ma w x64.

Zobacz „Brak kodu 16-bitowego” w artykule MSKB: http://support.microsoft.com/kb/282423

— SqlRyan
źródło

14

Nie ma emulacji - x86 / 64 może uruchamiać te rzeczy natywnie. Trwa jednak thunkowanie API. Microsoft wybrał tę okazję, aby wycofać znacznie starą i najczęściej nieużywaną technologię.

— Chris K

@Chris Kamiński - Dziwię się, że zrobiliby to jako decyzja architektoniczna - x86 vs x64 - w przeciwieństwie do powiedzenia „W porządku - to Windows 7 i nie obsługujemy już procesów 16-bitowych”. Zwłaszcza z „trybem Windows XP” teraz osadzonym w 7, wydaje się, że jest to idealny czas na ograniczenie wsparcia nawet w wersji x86.

— SqlRyan

@Chris Kamiński: Po głębszym przemyśleniu, myślę, że musi to być naśladowanie, a nie tylko mechacenie API. Gdyby mógł uruchamiać kod innej kompilacji bitów natywnie, to dlaczego x64 miałoby Wow64 do uruchamiania aplikacji 32-bitowych - czy te nie działałyby również natywnie?

— SqlRyan

@darthcoder: CPU po prostu nie obsługuje wirtualnego trybu 8086 wymaganego przez NTVDM w trybie długim (64-bitowym). Dlatego albo NTVDM musiałby stać się pełną maszyną wirtualną, emulując wszystko lub zostać odciętym. Ponieważ jest już wystarczająco dużo maszyn wirtualnych (a MS też je ma), nie była to trudna decyzja. Nie sądzę, żeby miało to związek z tym, ile to było lat i ile zostało wykorzystane.

— Joey

rwmnau: W przypadku WoW64 nie odbywa się emulacja (z wyjątkiem Itanium). Procesory x64-64 nadal obsługują instrukcje 32-bitowe, więc prawie wszystko, co Windows musi zrobić, to przełączyć procesor w tryb 32-bitowy i zepsuć się kilkoma wskaźnikami.

— Joey

3

Popraw mnie, jeśli się mylę, ale według mojego zrozumienia, NTVDM używa wirtualnego trybu 8086 tylko z powodu specyficznego dla systemu Windows problemu. Tryb zgodności na procesorach x64 (działających w trybie długim) obsługuje pełny „czysty” tryb chroniony, 16- i 32-bitowy z tego, co tu znalazłem: http://en.wikipedia.org/wiki/Long_mode , ale nie niektóre z 386 dodatków, takich jak wirtualny tryb 8086. Więc najprawdopodobniej nie jest obsługiwany, ponieważ nie opłaca się Microsoftowi przeprogramować NTVDM, co prawdopodobnie wymagałoby dodatkowej emulacji, ponieważ niektóre 16-bitowe aplikacje w trybie chronionym mogą korzystać z wirtualnego 8086, nawet jeśli większość tego nie robi. Przypuszczam, że przy wystarczającej pracy można napisać coś szybciej niż dosbox działający w trybie długim, ponieważ istnieje wsparcie sprzętowe dla aplikacji 16-bitowych.

— MichaelS
źródło

-1 Adresowanie w trybie 16-bitowym, czyli 16-bitowym, jest obsługiwane przez lokalną tablicę deskryptorów. . W rzeczywistości winedvm on na Linuksie właśnie to robi! Istnieje nawet nieoficjalna wymiana o nazwie otvdm .

— user2284570

Cóż, według mojego zrozumienia, to (rozwiązanie do wina) zawiera emulator procesora. Więc nie używa wirtualnego trybu 8086. To jest dokładnie rozwiązanie, które potencjalnie mogłoby zostać zaimplementowane w NTVDM, bez emulacji całego komputera, tak jak robi to DOSBOX (z Win16). A jeśli powiesz, że 16-bitowy tryb chroniony jest obsługiwany w trybie długim, to co z aplikacjami w trybie rzeczywistym Win16?

— MichaelS

Zawiera emulator, ale jeśli sposób na modyfikację lokalnej tabeli deskryptorów znajduje się w systemie Windows, emulacja w ogóle nie byłaby wymagana. O trybie rzeczywistym można je również emulować w taki sposób, jak robi to Dosemu (przynajmniej wersja Linux). Ntvdm został początkowo zaprojektowany do umożliwienia uruchamiania programu Dos na platformach takich jak Mips lub PowerPc, który był obsługiwany w poprzedniej wersji systemu Windows. To tylko opcjonalna funkcja, którą należy włączyć podczas kompilacji. I wygląda na to, że wyciekł kod źródłowy, pozwalając komuś to zrobić: columbia.edu/~em36/ntvdmx64.html

— user2284570

3

Inaczej jest w przypadku aplikacji Dos i 16-bitowych aplikacji Windows.

W przypadku aplikacji Dos problem polega na tym, że wirtualny tryb 8086 nie jest dostępny w trybie długim. Jest to ograniczenie architektury procesora.

W przypadku 16-bitowych aplikacji Windows (które działają w 16-bitowym trybie chronionym) powodem jest to, że MS nie był przygotowany do wykonania odpowiedniej implementacji warstwy kompatybilności. Zabawnie Wine jest doskonale zdolny do uruchamiania 16-bitowych aplikacji Windows na 64-bitowym systemie Linux.

— płyn do płukania
źródło

1

to tylko dlatego, że nie ma NTVDM w 64-bitowym systemie Windows. Procesor może nadal uruchamiać 16-bitowy kod w trybie zgodności. Z podręcznika Intela: „Tryb zgodności (pod-tryb trybu IA-32e) - Tryb zgodności pozwala na uruchamianie większości starszych aplikacji 16-bitowych i 32-bitowych bez ponownej kompilacji w 64-bitowym systemie operacyjnym”

— phuclv

Jak rozumiem, tryb zgodności pozwala na tryb 16-bitowy chroniony, ale nie na tryb wirtualny 8086.

— plugwash

2

Myślę, że najbardziej prawdopodobnym powodem jest to, że tylko niewielki procent właścicieli komputerów naprawdę chce mieć możliwość uruchamiania starych 16-bitowych aplikacji na nowym 64-bitowym sprzęcie. Microsoft prawdopodobnie doszedł do wniosku, że nie warto było kontynuować obsługi 16-bitowych aplikacji.

— Stephen C.
źródło

Ma to sens, z wyjątkiem tego, że Windows 7 32bit nadal go obsługuje, więc najwyraźniej warto skorzystać z tego, co już mają, ale nie wdrożyć go ponownie (jak byłoby to konieczne w przypadku x86-64 z powodu braku trybu wirtualnego-8086

— Earlz

Myślałem, że „nie chcemy utrzymywać skomplikowanej bazy kodu”. Gdyby utrzymywali 16-bit, mogliby musieli obsługiwać oprogramowanie z lat 80-tych. Może to obejmować włożenie brzydkich hacków, aby Lotus 1-2-3 nadal działał.

— Joe Plante,

@Ellz tak, ale myślę, że to jest prawdziwa odpowiedź, ponieważ prawdziwym rozwiązaniem w celu uzyskania dostępu do tabeli deskryptorów lokalnych dla 16 bitów jest zrobienie tego bezpośrednio, a nie poprzez tryb Vm86. Microsoft po prostu nie zawracał sobie głowy przenoszeniem swojego kodu. W rzeczywistości istnieje nieoficjalna wymiana oprogramowania Ntᴠᴅᴍ zaprojektowana dla natywnego 64-bitowego systemu Windows .

— user2284570