Perché un sistema operativo a 64 bit non può eseguire un'applicazione a 16 bit?

38

Perché è che:

un sistema operativo a 32 bit, se installato su una CPU a 64 bit, può eseguire vecchie applicazioni a 16 bit,
ma se installi un sistema operativo a 64 bit non è possibile eseguire direttamente quelle applicazioni e necessita di una sorta di emulazione (che non sempre funziona perfettamente)?

Per essere più specifici, ho un processore a 64 bit (Intel Core 2 Duo). Quando avevo installato Windows XP e Windows 7 (entrambi a 32 bit), potevano eseguire vecchie applicazioni DOS e Windows a 616 bit.

Ora ho installato l'edizione a 64 bit di Windows 7. Perché non è più possibile eseguire quelle stesse applicazioni?

— fixer1234
fonte

3

Penso che abbia meno a che fare con i bit e di più con il sistema operativo guest. A quali sistemi operativi ti riferisci in particolare?

— Pekka supporta GoFundMonica

Funzionerà sotto DOSBox?

— Penguat,

1

C'è un'utilità chiamata DOSBOX, è un emulatore a 16 bit che fornisce al tuo programma a 16 bit un computer virtuale a 16 bit su cui lavorare, ed è gratuito.

Sono d'accordo con Pekka, il fatto è che un sistema a 64 bit (hardware) può eseguire il codice a 16 bit (diamine, anche il codice a 1 bit se il sistema operativo è stato progettato). Il vero problema è che la CPU non è in grado di eseguire direttamente il codice a 16 bit a causa di cose come dimensioni di puntatore diverse, ma questi problemi possono essere sottratti dal sistema operativo. La limitazione è artificiale che Microsoft ha imposto per semplificare le cose (anche se hanno ancora emulato a 32 bit perché c'è ancora tanto codice a 32 bit). Esistono altri sistemi operativi (* nix?) Che possono eseguire codice a 16 bit senza problemi.

— Synetech,

Stai confondendo Windows con tutti i sistemi operativi.

— Ken Sharp

24

Da quanto ho capito, è perché quando si esegue in modalità lunga (nativo x64), la CPU stessa non supporta l'accesso alla modalità 16 bit. Vedi Wikipedia . Quindi, per supportare la modalità a 16 bit, NTVDM (il layer a 16 bit in Windows) dovrebbe emulare completamente un processore a 16 bit.

Suppongo che abbiano pesato reimplementando un livello di emulazione rispetto all'uso di software di virtualizzazione già esistenti (VirtualPC, VirtualBox) per gestire questo, e si è deciso di tagliare il VDM.

— Matt Sieker
fonte

6

Citando da Wikipedia : Le versioni di Windows NT per architetture a 64 bit (x64 e IA-64) non includono NTVDM e non sono in grado di eseguire applicazioni DOS o Windows a 16 bit. Questo perché, in una CPU x86-64, la modalità 8086 virtuale è disponibile come modalità secondaria solo nella sua modalità legacy (per l'esecuzione di sistemi operativi a 16 e 32 bit), non nella modalità nativa a 64 bit; è necessario un hard reset della CPU per passare alla modalità legacy. Quindi l'unico modo in cui NTVDM ha funzionato finora non è più disponibile e le VM complete sono disponibili in abbondanza, quindi NTVDM è stato tagliato.

— Joey,

5

Yuck, non posso credere che abbiano scaricato la modalità V86. Potrebbe anche lanciare completamente la modalità reale e richiedere caricatori di avvio a 32/64 bit se lo farai.

— Brian Knoblauch,

5

È esattamente quello che è già successo, M. Knoblauch. Una moderna macchina x86 con firmware EFI passa direttamente dalla modalità irreale nelle sue prime istruzioni alla modalità protetta a 64/32 bit. I boot loader sono infatti programmi in modalità protetta a 64/32 bit. Ecco cosa sono le applicazioni di avvio EFI. Non è possibile utilizzare la modalità reale o la modalità protetta v8086 in nessun punto del processo.

— JdeBP,

3

-1. WINE supporta l'esecuzione di app Windows a 16 bit in modalità VM86 su Linux a 64 bit. screenshot . Pagina del progetto V86-64 . La risposta di Mehrdad sembra la ragione più convincente.

— Hugh Allen,

3

@HughAllen: quella pagina attualmente dice "Attualmente la versione a 64 bit del kernel linux non supporta la modalità V86 perché non è supportata nella modalità operativa nativa (modalità lunga) di questi processori." e "Questa patch è molto sperimentale ". La risposta breve è che sebbene sia possibile eseguire il codice a 16 bit, uscendo completamente dalla modalità lunga, non è ragionevole farlo.

— Harry Johnston,

14

Poiché gli handle a 64 bit hanno 32 bit significativi :

Si noti che Windows a 64 bit non supporta l'esecuzione di applicazioni basate su Windows a 16 bit.
Il motivo principale è che gli handle hanno 32 bit significativi su Windows a 64 bit.
Pertanto, gli handle non possono essere troncati e passati ad applicazioni a 16 bit senza perdita di dati.

In Windows, i programmi passano "handle" al sistema operativo e viceversa (che sono numeri che il sistema operativo utilizza per identificare in modo univoco una particolare risorsa, come una finestra).

Per supportare i programmi a 16 bit, Windows a 32 bit genera solo handle con 16 bit significativi: i 16 bit superiori vengono ignorati dal sistema operativo (anche se i programmi non trarranno vantaggio da questo fatto). Quindi nessun programma può interagire con più di 2 ¹⁶ oggetti, che in realtà è piuttosto basso.

Tuttavia, al fine di migliorare ciò, Windows a 64 bit ha aumentato il numero di bit significativi in un handle a 32. Ma ora ciò significa che gli handle non possono essere passati a programmi a 16 bit senza perdita di informazioni. Quindi i programmi a 16 bit non possono essere eseguiti su Windows a 64 bit.

— Mehrdad
fonte

3

@Joey: non capisco cosa stai dicendo. Se il sistema operativo è Windows a 64 bit, le applicazioni a 16 bit non possono essere eseguite su di esso, punto. Non vedo come il fatto che siano l'applicazione "DOS" o "Windows" cambi qualcosa qui - in entrambi i casi, l'applicazione dovrebbe essere troncata.

— Mehrdad,

1

Le applicazioni DOS non hanno handle. In effetti, (di solito) non sanno nemmeno che sono in esecuzione su Windows.

— Joey,

1

... in realtà, anche il codice Win16 non dovrebbe essere un grosso problema, ora che ci penso. Tutto ciò di cui hai bisogno è una tabella di ricerca.

— Harry Johnston,

1

@HarryJohnston: penso che ti manchi il problema. Cosa proponi dovrebbe succedere con la tua "tabella di ricerca" immaginaria quando un'applicazione chiama EnumWindowse ci sono più di 2 ^ 16 finestre nel sistema?

— Mehrdad,

1

Stavo parlando di handle del kernel come da articolo, non di handle di finestre. Sono cose completamente diverse. Le applicazioni a 16 bit vedono anche finestre a 32 bit? Sembra improbabile, perché le strutture dei messaggi sono diverse; cosa accadrebbe se un'app a 16 bit venisse inviata un messaggio con un wParam a 32 bit? Inoltre, si noti che il numero massimo di handle di finestra è ancora 2 ^ 16 secondo msdn.microsoft.com/en-us/library/windows/desktop/…

— Harry Johnston,

10

Per Windows, è perché le versioni x86 del sistema operativo includono l'emulazione a 16 bit che consente loro di eseguire quei processi DOS più vecchi. Nelle versioni x64, devono già emulare l'esecuzione x86 (lo chiamano WoW64) per consentire l'esecuzione dei processi a 32 bit, e immagino che l'uso di Wow64 per emulare ulteriormente l'emulatore a 16 bit abbia causato troppi problemi.

Una manciata di processi riconosciuti a 16 bit verrà eseguita perché l'emulazione è hardcoded per gestirli, ma il resto non funziona perché l'emulazione non è inclusa in x64.

Vedere "Nessun codice a 16 bit" nell'articolo di MSKB: http://support.microsoft.com/kb/282423

— SqlRyan
fonte

14

Non c'è emulazione in corso - x86 / 64 può eseguire queste cose in modo nativo. C'è comunque il thunking API in corso. Microsoft ha scelto questa opportunità per ritirare una tecnologia notevolmente vecchia e per lo più inutilizzata.

— Chris K,

@Chris Kaminski - Sono sorpreso che lo farebbero come una decisione di architettura - x86 vs x64 - invece di dire "Va bene - è Windows 7 e non eseguiamo più processi a 16 bit". Soprattutto con "Windows XP Mode" ora incorporato in 7, sembra il momento perfetto per tagliare il supporto anche nella versione x86.

— SqlRyan,

@Chris Kaminski: dopo averci pensato un po 'di più, penso che debba emularlo, non solo una sorta di mucking API. Se fosse in grado di eseguire nativamente codice di una diversa generazione di bit, allora perché x64 dovrebbe avere Wow64 per eseguire app a 32 bit - non dovrebbero funzionare anche nativamente?

— SqlRyan,

@darthcoder: la CPU semplicemente non supporta la modalità 8086 virtuale richiesta da NTVDM in modalità lunga (64 bit). Pertanto, NTVDM dovrebbe diventare una VM completa, emulare tutto o essere tagliato. Dato che ci sono già abbastanza macchine virtuali (e anche MS ne ha una) non è stata una decisione difficile. Non penso che abbia nulla a che fare con quanti anni aveva o quanto usato.

— Joey,

rwmnau: Per WoW64 non è in corso alcuna emulazione (tranne per Itanium). Le CPU x64-64 supportano ancora le istruzioni a 32 bit, quindi quasi tutto ciò che Windows deve fare è cambiare la CPU in modalità 32 bit e pasticciare con alcuni puntatori.

— Joey,

3

Correggimi se sbaglio, ma a quanto ho capito è solo a causa del problema specifico di Windows che NTVDM utilizza la modalità 8086 virtuale. La modalità di compatibilità sui processori x64 (in esecuzione in modalità lunga) supporta la modalità protetta "pulita", a 16 e 32 bit da quello che ho trovato qui: http://en.wikipedia.org/wiki/Long_mode , ma non alcuni dei 386 aggiunte come la modalità 8086 virtuale. Quindi non è supportato molto probabilmente perché Microsoft non ripaga la riprogrammazione di NTVDM, che probabilmente richiederebbe l'aggiunta di un po 'più di emulazione perché alcune applicazioni in modalità protetta a 16 bit possono usare l'8086 virtuale, anche se la maggior parte no. Suppongo che con abbastanza lavoro sia possibile scrivere qualcosa più velocemente di dosbox in esecuzione in modalità lunga, poiché esiste un supporto hardware per le app a 16 bit.

— Michaels
fonte

-1. L'indirizzamento in modalità 16 bit, noto anche come segmento a 16 bit, è supportato attraverso la tabella dei descrittori locali. . In effetti winedvm su Linux fa proprio questo! C'è anche una sostituzione non ufficiale chiamata otvdm .

— user2284570

Bene, secondo la mia comprensione (soluzione di vino) contiene un emulatore della CPU. Quindi non utilizza la modalità 8086 virtuale. Questa è precisamente la soluzione che, potenzialmente, potrebbe essere implementata in NTVDM, senza emulare l'intero PC, come fa DOSBOX (con Win16). E se dici che la modalità protetta a 16 bit è supportata in modalità lunga, che dire delle app in modalità reale Win16?

— MichaelS,

Contiene un emulatore ma se su Windows viene trovato un modo per modificare la tabella dei descrittori locali, allora non sarebbe richiesta alcuna emulazione. A proposito della modalità reale, possono anche essere emulati come fatto da Dosemu (almeno la versione Linux). Inizialmente Ntvdm è stato progettato per consentire l'esecuzione del programma Dos su piattaforme come Mips o PowerPc che era supportato nella versione precedente di Windows. È solo una funzione opzionale che deve essere abilitata in fase di compilazione. E sembra che il codice sorgente sia trapelato consentendo a qualcuno di fare proprio questo: columbia.edu/~em36/ntvdmx64.html

— user2284570

3

La situazione è diversa per le applicazioni Dos e le applicazioni Windows a 16 bit.

Per le applicazioni Dos il problema è che la modalità 8086 virtuale non è disponibile in modalità lunga. Questa è una limitazione dell'architettura della CPU.

Per le applicazioni Windows a 16 bit (eseguite in modalità protetta a 16 bit) il motivo è che MS non era preparato a fare il lavoro per implementare un livello di compatibilità adeguato. Divertente Wine è perfettamente in grado di eseguire app per Windows a 16 bit su Linux a 64 bit.

— plugwash
fonte

1

è solo perché non c'è NTVDM in Windows a 64 bit. La CPU può ancora eseguire codice a 16 bit in modalità compatibilità. Dal manuale di Intel: "Modalità di compatibilità (sotto-modalità della modalità IA-32e) - La modalità di compatibilità consente l'esecuzione della maggior parte delle applicazioni legacy a 16 e 32 bit senza ricompilazione in un sistema operativo a 64 bit"

— phuclv

Da quanto ho capito, la modalità di compatibilità consente la modalità protetta a 16 bit, ma non la modalità 8086 virtuale.

— lavaggio:

2

Penso che la ragione più probabile sia che solo una piccola percentuale dei proprietari di PC voglia effettivamente essere in grado di eseguire vecchie applicazioni a 16 bit sul loro nuovo hardware a 64 bit. Probabilmente Microsoft ha pensato che non valesse la pena continuare a supportare applicazioni a 16 bit.

— Stephen C
fonte

Questo ha senso tranne che per Windows 7 a 32 bit lo supporta ancora, quindi apparentemente vale la pena usare ciò che già hanno ma non reimplementarlo (come sarebbe necessario per x86-64 a causa della mancanza della modalità virtuale-8086

— Earlz

Pensavo che "non vogliamo mantenere una base di codice complicata". Se fossero rimasti a 16 bit, avrebbero dovuto supportare software risalente agli anni '80. Ciò può includere l'inserimento di brutti hack in modo che Lotus 1-2-3 funzioni ancora.

— Joe Plante,

@Earlz sì, ma penso che questa sia la vera risposta in quanto la vera soluzione per accedere alla tabella Local Descriptor per 16 bit è farlo direttamente e non attraverso la modalità Vm86. Microsoft semplicemente non si è preoccupata di trasferire il proprio codice. Esiste infatti una sostituzione software non ufficiale Ntᴠᴅᴍ progettata per Windows nativo a 64 bit .

— user2284570