Por que um sistema operacional de 64 bits não pode executar um aplicativo de 16 bits?

38

Por que é isso:

um sistema operacional de 32 bits, quando instalado em uma CPU de 64 bits, pode executar aplicativos antigos de 16 bits,
mas se você instalar um sistema operacional de 64 bits, ele não poderá executar esses aplicativos diretamente e precisará de algum tipo de emulação (que nem sempre funciona perfeitamente)?

Para ser mais específico, tenho um processador de 64 bits (Intel Core 2 Duo). Quando eu tinha o Windows XP e o Windows 7 (ambos de 32 bits) instalados, eles podiam executar aplicativos antigos do DOS e de 616 bits do Windows.

Agora eu instalei a edição de 64 bits do Windows 7. Por que ele não pode mais executar esses mesmos aplicativos?

— fixer1234
fonte

3

Eu acho que isso tem menos a ver com os bits e mais com o sistema operacional convidado. A quais sistemas operacionais você se refere especificamente?

— Pekka suporta GoFundMonica

Será executado no DOSBox?

— Penguat

11

Existe um utilitário chamado DOSBOX, um emulador de 16 bits que fornece ao seu programa de 16 bits um computador virtual de 16 bits para trabalhar e é gratuito.

Concordo com Pekka, o fato é que um sistema de 64 bits (hardware) pode executar código de 16 bits (heck, mesmo código de 1 bit se o sistema operacional tiver sido projetado). O problema é que a CPU não pode executar diretamente o código de 16 bits devido a coisas como tamanhos diferentes de ponteiros, mas esses problemas podem ser abstraídos pelo sistema operacional. A limitação é artificial que a Microsoft impôs para simplificar as coisas (embora elas ainda imitem 32 bits porque ainda há muito código de 32 bits). Existem outros sistemas operacionais (* nix?) Que podem executar código de 16 bits sem problemas.

— Synetech 01/09/12

Você está confundindo o Windows com todo o sistema operacional.

— Ken Sharp

24

Pelo que entendi, é porque, ao executar no Modo Longo (nativo x64), a própria CPU não suporta entrar no modo de 16 bits. Veja Wikipedia . Portanto, para oferecer suporte ao modo de 16 bits, o NTVDM (a camada de 16 bits no Windows) precisaria emular totalmente um processador de 16 bits.

Suponho que eles pesaram na reimplementação de uma camada de emulação vs usando um software de virtualização já existente (VirtualPC, VirtualBox) para lidar com isso, e foi decidido cortar o VDM.

— Matt Sieker
fonte

6

Citando da Wikipedia : Versões do Windows NT para arquiteturas de 64 bits (x64 e IA-64) não incluem o NTVDM e não conseguem executar aplicativos DOS ou Windows de 16 bits. Isso ocorre porque, em uma CPU x86-64, o modo 8086 virtual está disponível como sub-modo apenas no modo legado (para sistemas operacionais de 16 e 32 bits), não no modo nativo de 64 bits; é necessária uma reinicialização total da CPU para alternar para o modo legado. Portanto, a única maneira como o NTVDM funcionou até agora não está mais disponível e as VMs completas estão por aí em abundância, então o NTVDM foi cortado.

— Joey

5

Eca, não acredito que eles jogaram o modo V86. É possível ativar o modo real completamente e exigir carregadores de inicialização de 32/64 bits, se você fizer isso.

— 22910 Brian BrianBob

5

Isso é exatamente o que já aconteceu, M. Knoblauch. Uma máquina x86 moderna com firmware EFI passa diretamente do modo irreal em suas primeiras instruções para o modo protegido de 64/32 bits. Os gerenciadores de inicialização são de fato programas em modo protegido de 64/32 bits. É isso que são os aplicativos de inicialização EFI. Não há uso do modo real ou do modo protegido v8086 em nenhum lugar do processo.

— JdeBP

3

-1. O WINE suporta a execução de aplicativos do Windows de 16 bits no modo VM86 no Linux de 64 bits. captura de tela . Página do projeto V86-64 . A resposta de Mehrdad parece ser a razão mais convincente.

— Hugh Allen

3

@HughAllen: essa página atualmente diz "Atualmente, a versão de 64 bits do kernel Linux não suporta o modo V86 porque não é suportada no modo operacional nativo (modo longo) desses processadores". e "Este patch é muito experimental ". A resposta curta é que, embora seja possível executar o código de 16 bits, saindo completamente do modo longo, não é sensato fazê-lo.

— Harry Johnston

14

Como os identificadores de 64 bits possuem 32 bits significativos :

Observe que o Windows de 64 bits não oferece suporte à execução de aplicativos baseados no Windows de 16 bits.
O principal motivo é que os identificadores têm 32 bits significativos no Windows de 64 bits.
Portanto, os identificadores não podem ser truncados e passados para aplicativos de 16 bits sem perda de dados.

No Windows, os programas passam "alças" para o sistema operacional e vice-versa (que são números que o sistema operacional usa para identificar exclusivamente um recurso específico, como uma janela).

Para oferecer suporte a programas de 16 bits, o Windows de 32 bits gera apenas identificadores com 16 bits significativos - os 16 bits superiores são ignorados pelo sistema operacional (mesmo que os programas não estejam tirando proveito desse fato). Portanto, nenhum programa pode interagir com mais de 2 ¹⁶ objetos, o que é realmente bastante baixo.

No entanto, para melhorar isso, o Windows de 64 bits aumentou o número de bits significativos em um identificador para 32. Mas agora isso significa que os identificadores não podem ser passados para programas de 16 bits sem perda de informações. Portanto, os programas de 16 bits não podem ser executados no Windows de 64 bits.

— Mehrdad
fonte

3

@ Joey: Eu não entendo o que você está dizendo. Se o sistema operacional for Windows de 64 bits, os aplicativos de 16 bits não poderão ser executados nele. Não vejo como o fato de serem aplicativos "DOS" ou "Windows" altera qualquer coisa aqui - de qualquer forma, os identificadores precisariam ser truncados pelo aplicativo.

— Mehrdad

11

Aplicativos DOS não possuem alças. De fato, eles (geralmente) nem sabem que estão rodando no Windows.

— Joey

11

... na verdade, mesmo o código Win16 não deve ser um problema, agora que penso nisso. Tudo que você precisa é uma tabela de pesquisa.

— Harry Johnston

11

@HarryJohnston: Acho que você está perdendo o problema. O que você propõe que aconteça com sua "tabela de pesquisa" imaginária quando um aplicativo chama EnumWindowse há mais de 2 ^ 16 janelas no sistema?

— quer

11

Eu estava falando sobre alças de kernel conforme o artigo, não de janelas. São coisas completamente diferentes. Os aplicativos de 16 bits ainda veem janelas de 32 bits? Parece improvável, porque as estruturas da mensagem são diferentes; o que aconteceria se um aplicativo de 16 bits recebesse uma mensagem com um wParam de 32 bits? Além disso, observe que o número máximo de identificadores de janela ainda é 2 ^ 16, de acordo com msdn.microsoft.com/en-us/library/windows/desktop/…

— Harry Johnston

10

Para Windows, é porque as versões x86 do sistema operacional incluem emulação de 16 bits que lhes permite executar os processos DOS mais antigos. Nas versões x64, eles já precisam emular a execução x86 (eles chamam de WoW64) para permitir a execução de processos de 32 bits, e acho que usar o Wow64 para emular ainda mais o emulador de 16 bits causou muitos problemas.

Um punhado de processos reconhecidos de 16 bits será executado porque a emulação é codificada para lidar com eles, mas o restante não funciona porque a emulação não está incluída no x64.

Consulte "Nenhum código de 16 bits" no artigo do MSKB: http://support.microsoft.com/kb/282423

— SqlRyan
fonte

14

Não há emulação - o x86 / 64 pode executar essas coisas nativamente. No entanto, há thunking da API. A Microsoft escolheu esta oportunidade para retirar uma tecnologia significativamente antiga e quase não utilizada.

— Chris K

@ Chris Kaminski - Estou surpreso que eles fizessem isso como uma decisão de arquitetura - x86 x x64 - em vez de dizer "Tudo bem - é o Windows 7, e não estamos mais executando processos de 16 bits". Especialmente com o "Windows XP Mode" agora incorporado no 7, parece o momento perfeito para reduzir o suporte, mesmo na versão x86.

— SqlRyan

@ Chris Kaminski: Depois de pensar um pouco mais, acho que deve ser emulado, não apenas algum tipo de sujeira na API. Se ele pudesse executar o código de uma compilação de bits diferente nativamente, por que o x64 teria o Wow64 para executar aplicativos de 32 bits - não seriam executados nativamente também?

— SqlRyan

@darthcoder: A CPU simplesmente não suporta o modo virtual 8086 exigido pelo NTVDM no modo longo (64 bits). Portanto, o NTVDM precisaria se tornar uma VM completa, emulando tudo ou ser cortado. Como já existem VMs suficientes por aí (e a MS também tem), essa não foi uma decisão difícil. Eu não acho que tenha algo a ver com a idade ou o quanto isso foi usado.

— Joey

rwmnau: Para o WoW64, não há emulação (exceto para Itanium). As CPUs x64-64 ainda suportam as instruções de 32 bits, então quase tudo o que o Windows precisa fazer é alternar a CPU no modo de 32 bits e mexer com alguns ponteiros.

— Joey

3

Corrija-me se estiver errado, mas, pelo que entendi, é apenas por causa do problema específico do Windows que o NTVDM está usando o modo 8086 virtual. O modo de compatibilidade nos processadores x64 (executando no modo longo) suporta o modo protegido "limpo" completo, de 16 e 32 bits do que encontrei aqui: http://en.wikipedia.org/wiki/Long_mode , mas não alguns dos 386 adições, como o modo 8086 virtual. Portanto, provavelmente não há suporte para isso porque não vale a pena reprogramar o NTVDM, o que provavelmente exigiria a adição de mais emulação, porque alguns aplicativos em modo protegido de 16 bits podem usar o 8086 virtual, mesmo que a maioria não o faça. Suponho que com bastante trabalho é possível escrever algo mais rápido que o dosbox em execução no modo longo, pois há suporte de hardware para aplicativos de 16 bits.

— MichaelS
fonte

-1. O endereçamento de modo de 16 bits, também conhecido como segmento de 16 bits, é suportado através da tabela de descritores locais. . De fato, o winedvm on no Linux faz exatamente isso! Existe até um substituto não oficial chamado otvdm .

— user2284570 20/07

Bem, de acordo com o meu entendimento, (solução de vinho) contém um emulador de CPU. Portanto, não está usando o modo 8086 virtual. Essa é precisamente a solução que, potencialmente, poderia ser implementada no NTVDM, sem emular todo o PC, como o DOSBOX (com Win16). E se você diz que o modo protegido de 16 bits é suportado no modo longo, e os aplicativos em modo real do Win16?

— MichaelS

Ele contém um emulador, mas se for encontrada uma maneira de modificar a tabela de descritores locais no Windows, não será necessária nenhuma emulação. Sobre o modo real, eles também podem ser emulados da maneira feita pelo Dosemu (pelo menos na versão Linux). O Ntvdm foi projetado inicialmente para permitir a execução do programa Dos em plataformas como Mips ou PowerPc, suportado na versão anterior do Windows. É apenas um recurso opcional que precisa ser ativado no momento da compilação. E parece que o código-fonte vazou, permitindo que alguém fizesse exatamente isso: columbia.edu/~em36/ntvdmx64.html

— user2284570

3

A situação é diferente para aplicativos Dos e aplicativos Windows de 16 bits.

Para aplicativos Dos, o problema é que o modo 8086 virtual não está disponível no modo longo. Essa é uma limitação da arquitetura da CPU.

Para aplicativos do Windows de 16 bits (que são executados no modo protegido de 16 bits), o motivo é que a MS não estava preparada para fazer o trabalho para implementar uma camada de compatibilidade adequada. O Wine é perfeitamente capaz de executar aplicativos Windows de 16 bits no Linux de 64 bits.

— plugwash
fonte

11

é apenas porque não há NTVDM no Windows de 64 bits. A CPU ainda pode executar código de 16 bits no modo de compatibilidade. No manual da Intel: "Modo de compatibilidade (submodo do modo IA-32e) - O modo de compatibilidade permite que a maioria dos aplicativos herdados de 16 e 32 bits seja executada sem recompilação em um sistema operacional de 64 bits"

— phuclv

Pelo que entendi, o modo de compatibilidade permite o modo protegido de 16 bits, mas não o modo 8086 virtual.

— plugwash

2

Acho que o motivo mais provável é que apenas uma pequena porcentagem dos proprietários de PCs realmente deseja executar aplicativos antigos de 16 bits em seu novo hardware de 64 bits. A Microsoft provavelmente achou que não valia a pena continuar a suportar aplicativos de 16 bits.

— Stephen C
fonte

Isso faz sentido, exceto para o Windows 7 de 32 bits ainda suporta, aparentemente tão vale a pena usar o que eles já têm, mas não reimplementar-lo (como seria necessário para x86-64 devido à falta de modo virtual-8086

— Earlz

Eu estava pensando que "não queremos manter uma base de código complicada". Se eles fossem mantidos em 16 bits, talvez tivessem que oferecer suporte a software que remonta aos anos 80. Isso pode incluir invasões feias para que o Lotus 1-2-3 ainda funcione.

— Joe Plante

@Earlz sim, mas acho que essa é a resposta real, pois a solução real para acessar a tabela Local Descritor por 16 bits é fazê-lo diretamente e não através do modo Vm86. A Microsoft simplesmente não se incomodou em portar seu código. De fato, há uma substituição não oficial de software criada para Windows nativo de 64 bits .

— user2284570 20/07