¿Por qué un sistema operativo de 64 bits no puede ejecutar una aplicación de 16 bits?

38

Por qué es eso:

  • un SO de 32 bits, cuando está instalado en una CPU de 64 bits, puede ejecutar aplicaciones antiguas de 16 bits,
  • pero si instala un sistema operativo de 64 bits, ¿no puede ejecutar esas aplicaciones directamente y necesita algún tipo de emulación (que no siempre funciona perfectamente)?

Para ser más específico, tengo un procesador de 64 bits (Intel Core 2 Duo). Cuando tenía instalado Windows XP y Windows 7 (ambos de 32 bits), podían ejecutar aplicaciones antiguas de DOS y Windows de 616 bits.

Ahora he instalado la edición de 64 bits de Windows 7. ¿Por qué ya no puede ejecutar esas mismas aplicaciones?

windows-7 windows 64-bit 16-bit fijador1234
fuente
3
Creo que eso tiene menos que ver con los bits y más con el sistema operativo invitado. ¿A qué sistema operativo te refieres específicamente?
Pekka admite GoFundMonica
¿Funcionará bajo DOSBox?
Penguat
1
Hay una utilidad llamada DOSBOX, es un emulador de 16 bits que le da a su programa de 16 bits una computadora virtual de 16 bits para trabajar, y es gratis.
Estoy de acuerdo con Pekka, el hecho es que un sistema de 64 bits (hardware) puede ejecutar código de 16 bits (diablos, incluso código de 1 bit si el sistema operativo se diseñó así). El verdadero problema es que la CPU no puede ejecutar directamente el código de 16 bits debido a cosas como diferentes tamaños de puntero, pero estos problemas pueden ser resueltos por el sistema operativo. La limitación es artificial que Microsoft impuso para simplificar las cosas (aunque todavía emularon 32 bits porque todavía hay mucho código de 32 bits). Hay otros sistemas operativos (* nix?) Que pueden ejecutar código de 16 bits sin problemas.
Synetech
Estás confundiendo Windows con todos los sistemas operativos.
Ken Sharp

Respuestas:

24

Según tengo entendido, es porque cuando se ejecuta en modo largo (x64 nativo), la CPU en sí no admite entrar en modo de 16 bits. Ver Wikipedia . Entonces, para admitir el modo de 16 bits, el NTVDM (la capa de 16 bits en Windows) tendría que emular completamente un procesador de 16 bits.

Supongo que pesaron volver a implementar una capa de emulación frente al uso de software de virtualización ya existente (VirtualPC, VirtualBox) para manejar esto, y se decidió cortar el VDM.

Matt Sieker
fuente
66
Cita de Wikipedia : las versiones de Windows NT para arquitecturas de 64 bits (x64 e IA-64) no incluyen el NTVDM y no pueden ejecutar aplicaciones de Windows de DOS o 16 bits. Esto se debe a que, en una CPU x86-64, el modo virtual 8086 está disponible como un submodo solo en su modo heredado (para ejecutar sistemas operativos de 16 y 32 bits), no en el modo nativo de 64 bits de largo; Se requiere un restablecimiento completo de la CPU para cambiar al modo heredado. Entonces, la única forma en que NTVDM ha funcionado hasta ahora ya no está disponible y las máquinas virtuales completas están en abundancia, por lo que se cortó NTVDM.
Joey
55
Yuck, no puedo creer que hayan abandonado el modo V86. También podría lanzar el modo real por completo y exigir cargadores de arranque de 32/64 bits si va a hacer eso.
Brian Knoblauch
55
Eso es exactamente lo que ya sucedió, M. Knoblauch. Una máquina moderna x86 con firmware EFI pasa directamente del modo irreal en sus primeras instrucciones al modo protegido de 64/32 bits. Los cargadores de arranque son programas de modo protegido de 64/32 bits. Eso es lo que son las aplicaciones de arranque EFI. No hay uso del modo real o del modo protegido v8086 en ninguna parte del proceso.
JdeBP
3
-1. WINE admite la ejecución de aplicaciones de Windows de 16 bits en modo VM86 en Linux de 64 bits. captura de pantalla . V86-64 Página del proyecto . La respuesta de Mehrdad parece ser la razón más convincente.
Hugh Allen
3
@HughAllen: esa página actualmente dice "Actualmente, la versión de 64 bits del kernel de Linux carece de compatibilidad con el modo V86 porque no es compatible con el modo operativo nativo (modo largo) de estos procesadores". y "Este parche es muy experimental ". La respuesta corta es que, aunque es posible ejecutar código de 16 bits, al salir del modo largo por completo, no es sensato hacerlo.
Harry Johnston
14

Debido a que los identificadores de 64 bits tienen 32 bits significativos :

Tenga en cuenta que Windows de 64 bits no admite la ejecución de aplicaciones basadas en Windows de 16 bits.
La razón principal es que los identificadores tienen 32 bits significativos en Windows de 64 bits.
Por lo tanto, los identificadores no se pueden truncar y pasar a aplicaciones de 16 bits sin pérdida de datos.

En Windows, los programas pasan "identificadores" al sistema operativo y viceversa (que son números que el sistema operativo utiliza para identificar de forma exclusiva un recurso en particular, como una ventana).

Para admitir programas de 16 bits, Windows de 32 bits solo genera identificadores que tienen 16 bits significativos: el sistema operativo ignora los 16 bits superiores (aunque los programas no se aprovechen de este hecho). Por lo tanto, ningún programa puede interactuar con más de 2 16 objetos, lo que en realidad es bastante bajo.

Sin embargo, para mejorar esto, Windows de 64 bits aumentó el número de bits significativos en un identificador a 32. Pero ahora eso significa que los identificadores no pueden pasarse a programas de 16 bits sin pérdida de información. Por lo tanto, los programas de 16 bits no se pueden ejecutar en Windows de 64 bits.

Mehrdad
fuente
3
@Joey: No entiendo lo que estás diciendo. Si el sistema operativo es Windows de 64 bits, entonces las aplicaciones de 16 bits no pueden ejecutarse en él, punto. No veo cómo el hecho de que sean aplicaciones "DOS" o "Windows" cambia algo aquí: de cualquier manera, la aplicación debería truncar los identificadores.
Mehrdad
1
Las aplicaciones de DOS no tienen identificadores. De hecho, (generalmente) ni siquiera saben que se están ejecutando en Windows.
Joey
1
... en realidad, incluso el código Win16 no debería ser un gran problema, ahora que lo pienso. Todo lo que necesitas es una tabla de búsqueda.
Harry Johnston el
1
@HarryJohnston: Creo que te estás perdiendo el problema. ¿Qué propone que ocurra con su "tabla de búsqueda" imaginaria cuando una aplicación llama EnumWindowsy hay más de 2 ^ 16 ventanas en el sistema?
Mehrdad
1
Estaba hablando de los identificadores del kernel según el artículo, no de los identificadores de las ventanas. Son cosas completamente diferentes. ¿Las aplicaciones de 16 bits incluso ven ventanas de 32 bits? Parece poco probable, porque las estructuras de los mensajes son diferentes; ¿Qué pasaría si una aplicación de 16 bits recibiera un mensaje con un wParam de 32 bits? Además, tenga en cuenta que el número máximo de identificadores de ventana sigue siendo 2 ^ 16 según msdn.microsoft.com/en-us/library/windows/desktop/…
Harry Johnston
10

Para Windows, se debe a que las versiones x86 del sistema operativo incluyen una emulación de 16 bits que les permite ejecutar esos procesos DOS más antiguos. En las versiones x64, ya tienen que emular la ejecución x86 (lo llaman WoW64) para permitir que se ejecuten procesos de 32 bits, y supongo que usar Wow64 para emular aún más el emulador de 16 bits causó demasiados problemas.

Se ejecutarán un puñado de procesos reconocidos de 16 bits porque la emulación está codificada para manejarlos, pero el resto no funciona porque la emulación no está incluida en x64.

Consulte "Sin código de 16 bits" en el artículo de MSKB: http://support.microsoft.com/kb/282423

SqlRyan
fuente
14
No hay emulación en curso: x86 / 64 puede ejecutar estas cosas de forma nativa. Sin embargo, hay una conexión API. Microsoft ha elegido esta oportunidad para retirar una tecnología significativamente antigua y en su mayoría no utilizada.
Chris K
@ Chris Kaminski: me sorprende que lo hicieran como una decisión de arquitectura, x86 frente a x64, en lugar de decir "Bien, es Windows 7 y ya no ejecutamos procesos de 16 bits". Especialmente con el "Modo Windows XP" ahora integrado en 7, parece ser el momento perfecto para cortar el soporte incluso en la versión x86.
SqlRyan
@Chris Kaminski: Después de pensarlo un poco más, creo que tiene que estar emulando, no solo algún tipo de estupidez de API. Si podría ejecutar código de una construcción de bits diferente de forma nativa, entonces ¿por qué x64 tendría Wow64 para ejecutar aplicaciones de 32 bits?
SqlRyan
@darthcoder: la CPU simplemente no admite el modo virtual 8086 requerido por NTVDM en modo largo (64 bits). Por lo tanto, NTVDM tendría que convertirse en una máquina virtual completa, emulando todo o ser cortado. Dado que ya hay suficientes máquinas virtuales (y MS también tiene una), esa no fue una decisión difícil. No creo que tenga nada que ver con la antigüedad o la cantidad de uso.
Joey
rwmnau: Para WoW64 no hay emulación activa (excepto Itanium). Las CPU x64-64 aún admiten las instrucciones de 32 bits, por lo que casi todo lo que Windows tiene que hacer es cambiar la CPU en modo de 32 bits y meterse con algunos punteros.
Joey
3

Corríjame si me equivoco, pero a mi entender, es solo debido a un problema específico de Windows que NTVDM está utilizando el modo virtual 8086. El modo de compatibilidad en procesadores x64 (que se ejecuta en modo largo) admite el modo protegido "limpio" completo, 16 y 32 bits de lo que he encontrado aquí: http://en.wikipedia.org/wiki/Long_mode , pero no algunos de los 386 adiciones, como el modo virtual 8086. Por lo tanto, no es compatible porque probablemente no valga la pena que Microsoft reprograme NTVDM, lo que probablemente requerirá agregar más emulación porque algunas aplicaciones de modo protegido de 16 bits pueden usar 8086 virtual, incluso si la mayoría no lo hace. Supongo que con suficiente mano de obra es posible escribir algo más rápido que dosbox ejecutándose en modo largo, ya que hay soporte de hardware para aplicaciones de 16 bits.

MichaelS
fuente
−1. El direccionamiento en modo de 16 bits, también conocido como segmento de 16 bits, se admite a través de la tabla de descriptores locales. . De hecho, winedvm en Linux hace exactamente eso. Incluso hay un reemplazo no oficial llamado otvdm .
user2284570
Bueno, según tengo entendido, la solución de vino contiene un emulador de CPU. Por lo tanto, no está utilizando el modo virtual 8086. Esa es precisamente la solución que, potencialmente, podría implementarse en NTVDM, sin emular toda la PC, como lo hace DOSBOX (con Win16). Y si dice que el modo protegido de 16 bits es compatible con el modo largo, ¿qué pasa con las aplicaciones Win16 en modo real?
MichaelS
Contiene un emulador, pero si se encuentra una forma de modificar la tabla de descriptores locales en Windows, entonces no se requerirá ninguna emulación. Sobre el modo real, también se pueden emular de la forma en que lo hizo Dosemu (al menos la versión de Linux). Inicialmente, Ntvdm fue diseñado para permitir ejecutar el programa Dos en plataformas como Mips o PowerPc, que era compatible con la versión anterior de Windows. Es solo una característica opcional que debe habilitarse en el momento de la compilación. Y parece que el código fuente se filtró permitiendo que alguien haga exactamente eso: columbia.edu/~em36/ntvdmx64.html
user2284570
3

La situación es diferente para las aplicaciones Dos y las aplicaciones de Windows de 16 bits.

Para las aplicaciones Dos, el problema es que el modo virtual 8086 no está disponible en modo largo. Esta es una limitación de la arquitectura de la CPU.

Para aplicaciones de Windows de 16 bits (que se ejecutan en modo protegido de 16 bits), la razón es que MS no estaba preparada para hacer el trabajo de implementar una capa de compatibilidad adecuada. Divertidamente Wine es perfectamente capaz de ejecutar aplicaciones de Windows de 16 bits en Linux de 64 bits.

lavado
fuente
1
es solo porque no hay NTVDM en Windows de 64 bits. La CPU aún puede ejecutar código de 16 bits en modo de compatibilidad. Del manual de Intel: "Modo de compatibilidad (submodo del modo IA-32e): el modo de compatibilidad permite que la mayoría de las aplicaciones heredadas de 16 y 32 bits se ejecuten sin una nueva compilación en un sistema operativo de 64 bits"
phuclv
Según tengo entendido, el modo de compatibilidad permite el modo protegido de 16 bits, pero no el modo virtual 8086.
lavar el
2

Creo que la razón más probable es que solo un pequeño porcentaje de propietarios de PC realmente quiere poder ejecutar aplicaciones antiguas de 16 bits en su nuevo hardware de 64 bits. Microsoft probablemente pensó que no valía la pena mientras seguía admitiendo aplicaciones de 16 bits.

Stephen C
fuente
Esto tiene sentido, excepto que Windows 7 de 32 bits todavía lo admite, por lo que aparentemente vale la pena usar lo que ya tienen pero no
volver a implementarlo
Estaba pensando que "no queremos mantener una base de código complicada". Si se mantuvieron en 16 bits, podrían haber tenido que admitir software que se remonta a los años 80. Esto puede incluir poner hacks feos para que Lotus 1-2-3 aún funcione.
Joe Plante el
@ Earlz sí, pero creo que esta es la respuesta real, ya que la solución real para acceder a la tabla de descriptores locales para 16 bits es hacerlo directamente y no a través del modo Vm86. Microsoft simplemente no se molestó en portar su código. De hecho, hay un reemplazo de software no oficial de Ntᴠᴅᴍ diseñado para Windows nativo de 64 bits .
user2284570