Cambalinho
Power Member
isso são hardwares que desconheço(ISA)
Windows ME: porque o MS-DOS fica em ecra preto?
- Autor do tópico Cambalinho
- Data Início
DavidJamez
Power Member
óptimo, boa ocasião para ficar a conhecer 
Arucard1983
Power Member
Para correr jogos para MS-DOS no hardware original ficaria melhor servido com um computador com CPU 486 ou equivalente da AMD, o MS-DOS 6.22 (e Windows 3.1) e boa sorte a configurar hardware com mais de 25 anos numa altura ou usava-se parâmetros no CONFIG.SYS e TSR no AUTOEXEC.BAT, ou alterava-se jumpers e switches nas placas.
O Windows 95, 98 e ME são compostos pelo kernel do MS-DOS (IO.SYS), que era a versão 7.0 no 95, 7.1 nos 95 OSR e 98 e finalmente 8.0 no ME (que era mais um 7.1 reduzido em funcionalidades), um server DPMI (para ter acesso ao modo protegido da CPU, em contraste com o modo real herdado do MS-DOS), um DOS Extender (VMM) que amplia a API do MS-DOS com extensões de 32-bit para os drivers em modo protegido, e as bibliotecas Win32c sobre o Win16 que são as dll que os programas de 16 bit e 32-bit executam normalmente sobre o Windows.
Escolher o Windows ME já quebra a compatibilidade com vários programas do MS-DOS, dado que o suporte aos drivers do modo real de terceiros foram desactivados (somente o HIMEM.SYS e similares são carregados, mesmo que ignore o CONFIG.SYS), e o kernel do MS-DOS 8.0 foi minimizado somente para carregar os componentes de modo real estritamente necessários para que o server DPMI e DOS Extender fossem carregados e funcionassem.
Uma versão menos restritiva do MS-DOS que suportava os drivers de modo real só permitia que carregasse a partir de disquetes, e não no disco rígido.
Foi a estratégia de choque para que os desenvolvedores de hardware cortassem de vez com o uso de drivers de modo real, e programas que acediam ao hardware usando interrupções da BIOS e DOS, em vez do Win32 API de modo protegido.
Também foi nessa altura que os drivers de 16-bit e 32-bit de modo protegido em formato VXD estava seriamente restringida, por usar métodos herdados do Windows 3.1 e 95. Ainda assim uma layer de compatibilidade para os drivers Windows Driver Model do Windows NT 5.0 estava disponível usando um VXD, mas raros eram os drivers na altura que usavam essa norma.
No ano 2000, já era demasiado evidente que a estrutura híbrida do Windows 9x estava obsoleta, e o lançamento do XP liquidou de vez o MS-DOS, incluindo as extensões de 32-bit (VXD e DPMI).
Devido a esse motivo, hardware como a placa de som AC97, que é mais um chipset que funciona em parte por software, já não seria possível a nível universal criar drivers de modo real devido ao facto de exigir multithreading (para correr num processo da CPU o software de suporte ao som, e noutro processo o jogo) que não existe de forma nativa (exigindo criar um novo DOS Extender somente para isso, e garantir que não entrava em conflito com os componentes de modo real!).
Este suporte existe naturalmente com o DOS Extender do Windows 95/98/Me, do qual é criado uma máquina virtual do MS-DOS ao copiar o estado do MS-DOS nativo do Windows (que é a máquina virtual zero, sendo a mesma que inicia o sistema, até carregar o VMM), e permite que os drivers de modo protegido para o som e vídeo sejam virtualizados na aplicação DOS, evitando o pesadelo que seria configurar os drivers de modo real para o mesmo fim.
No Windows NT (Isso inclui o 2000, XP, Vista, ..., 10) os programas para o MS-DOS não têm acesso real ao hardware (que no Windows 3.1, 95, 98 e Me tinham de forma restricta, que mesmo assim não evitavam a quebra total do sistema num erro grave.) e correm sobre um emulador chamado NTVDM (que foi removido nas versões de 64-bit do Windows, e actualmente é uma instalação opcional nas versões de 32-bit) que cria os ambientes de virtualização para correr programas do Windows 3.1 e DOS, sem no entanto permitir o acesso real ao hardware do sistema.
Actualmente é preferível usar emuladores como o DosBox para correr jogos do DOS em máquinas modernas, do que perder tempo em hardware retro a não ser que tenha experiência no assunto.
O Windows 95, 98 e ME são compostos pelo kernel do MS-DOS (IO.SYS), que era a versão 7.0 no 95, 7.1 nos 95 OSR e 98 e finalmente 8.0 no ME (que era mais um 7.1 reduzido em funcionalidades), um server DPMI (para ter acesso ao modo protegido da CPU, em contraste com o modo real herdado do MS-DOS), um DOS Extender (VMM) que amplia a API do MS-DOS com extensões de 32-bit para os drivers em modo protegido, e as bibliotecas Win32c sobre o Win16 que são as dll que os programas de 16 bit e 32-bit executam normalmente sobre o Windows.
Escolher o Windows ME já quebra a compatibilidade com vários programas do MS-DOS, dado que o suporte aos drivers do modo real de terceiros foram desactivados (somente o HIMEM.SYS e similares são carregados, mesmo que ignore o CONFIG.SYS), e o kernel do MS-DOS 8.0 foi minimizado somente para carregar os componentes de modo real estritamente necessários para que o server DPMI e DOS Extender fossem carregados e funcionassem.
Uma versão menos restritiva do MS-DOS que suportava os drivers de modo real só permitia que carregasse a partir de disquetes, e não no disco rígido.
Foi a estratégia de choque para que os desenvolvedores de hardware cortassem de vez com o uso de drivers de modo real, e programas que acediam ao hardware usando interrupções da BIOS e DOS, em vez do Win32 API de modo protegido.
Também foi nessa altura que os drivers de 16-bit e 32-bit de modo protegido em formato VXD estava seriamente restringida, por usar métodos herdados do Windows 3.1 e 95. Ainda assim uma layer de compatibilidade para os drivers Windows Driver Model do Windows NT 5.0 estava disponível usando um VXD, mas raros eram os drivers na altura que usavam essa norma.
No ano 2000, já era demasiado evidente que a estrutura híbrida do Windows 9x estava obsoleta, e o lançamento do XP liquidou de vez o MS-DOS, incluindo as extensões de 32-bit (VXD e DPMI).
Devido a esse motivo, hardware como a placa de som AC97, que é mais um chipset que funciona em parte por software, já não seria possível a nível universal criar drivers de modo real devido ao facto de exigir multithreading (para correr num processo da CPU o software de suporte ao som, e noutro processo o jogo) que não existe de forma nativa (exigindo criar um novo DOS Extender somente para isso, e garantir que não entrava em conflito com os componentes de modo real!).
Este suporte existe naturalmente com o DOS Extender do Windows 95/98/Me, do qual é criado uma máquina virtual do MS-DOS ao copiar o estado do MS-DOS nativo do Windows (que é a máquina virtual zero, sendo a mesma que inicia o sistema, até carregar o VMM), e permite que os drivers de modo protegido para o som e vídeo sejam virtualizados na aplicação DOS, evitando o pesadelo que seria configurar os drivers de modo real para o mesmo fim.
No Windows NT (Isso inclui o 2000, XP, Vista, ..., 10) os programas para o MS-DOS não têm acesso real ao hardware (que no Windows 3.1, 95, 98 e Me tinham de forma restricta, que mesmo assim não evitavam a quebra total do sistema num erro grave.) e correm sobre um emulador chamado NTVDM (que foi removido nas versões de 64-bit do Windows, e actualmente é uma instalação opcional nas versões de 32-bit) que cria os ambientes de virtualização para correr programas do Windows 3.1 e DOS, sem no entanto permitir o acesso real ao hardware do sistema.
Actualmente é preferível usar emuladores como o DosBox para correr jogos do DOS em máquinas modernas, do que perder tempo em hardware retro a não ser que tenha experiência no assunto.
