Windows 2.x: Um Salto Técnico na Era dos PCs
No final dos anos 1980, o mercado de computadores pessoais estava em ebulição, impulsionado por avanços em hardware que expandiram drasticamente as capacidades dos sistemas operacionais. A Microsoft, ainda uma empresa em ascensão, lançou o Windows 2.x em 1987, uma camada gráfica sobre o MS-DOS que, embora não tenha dominado o mercado, foi um marco crucial na sua trajetória rumo ao Windows 3.0.
Antes de começar, vejam as caixas e discos das três versões do Windows 2:
Inovações de Hardware que Impulsionaram o Windows 2.x
O desenvolvimento do Windows 2.x foi diretamente moldado pela evolução dos processadores Intel e pelas inovações no gerenciamento de memória e gráficos. Vamos detalhar um pouco esses avanços para entender sobre o porque o Windows 2.x teve 3 versões diferentes e quais as diferenças entre essas versões.
Avanços nos Processadores: 80286 e 80386
O Intel 80286, lançado em 1982, trouxe avanços significativos em relação aos 8086/8088. Ele introduziu o modo protegido, que permitia acessar até 16 MB de memória (em vez de 1 MB no modo real) através de um sistema de segmentação mais robusto, com descritores de segmento que definiam privilégios e limites de memória, garantindo maior proteção contra acessos indevidos por aplicativos. O modo protegido era essencial para sistemas operacionais gráficos, que exigiam estabilidade e isolamento entre processos. No entanto, o 80286 não suportava multitarefa preemptiva de forma eficiente, pois o retorno ao modo real exigia um reset do processador, o que limitava a alternância rápida entre aplicativos.
O Intel 80386, lançado em 1985, foi um marco ainda maior. Ele introduziu endereçamento de 32 bits, permitindo acesso teórico a 4 GB de memória, e o modo virtual 8086, que criava máquinas virtuais para rodar aplicativos MS-DOS em paralelo, cada um com sua própria instância de 1 MB de memória. Isso possibilitou multitarefa preemptiva, onde o sistema operacional podia interromper e alternar entre processos sem depender da cooperação dos aplicativos. O 80386 também suportava paginação de memória, embora o Windows 2.x não a utilizasse, limitando-se à memória física disponível. Essas capacidades tornaram o 80386 ideal para sistemas operacionais avançados, como o Windows/386, que explorava a multitarefa para rodar múltiplos programas MS-DOS simultaneamente .
Por exemplo, um usuário com um 80386 rodando o Windows/386 podia abrir o Microsoft Excel, um editor de texto MS-DOS e um jogo como Tetris em janelas separadas, com o sistema alternando entre eles sem travamentos, algo impossível nos 8086/8088 ou mesmo no 80286 sem configurações complexas.
Gerenciamento de Memória: Um Quebra-Cabeça Técnico
O gerenciamento de memória era o principal gargalo dos PCs da época, devido à arquitetura do MS-DOS e às limitações de hardware. O Windows 2.x foi projetado para contornar essas restrições, aproveitando esquemas como memória convencional, expandida, estendida, HMA e UMA.
Antes disso, vamos relembrar alguns detalhes sobre o endereçamento da memória na arquitetura x86.
Lá na década de 1970/1980 os computadores eram, em sua maioria, de 8 bits. Isso quer dizer que os registradores eram de 8 bits, mas o barramento de endereços era de 16 bits (2ˆ16 = 65.536 endereços ou 64k). Resumindo: um computador de 8 bits tinha registradores de 8 bits, acessava endereços de 16 bits para ler/escrever valores de 8 bits na RAM.
Resumindo a fragmentação das memórias:
Memória Convencional (0 a 640 KB): Nos processadores 8086/8088, o endereçamento de 20 bits (segmento:offset) limitava o acesso a 1 MB de memória, dos quais 640 KB eram reservados para programas e dados, conhecidos como memória convencional. Os 384 KB restantes, entre 640 KB e 1 MB, formavam a Upper Memory Area (UMA), usada por dispositivos como adaptadores de vídeo (CGA, EGA, VGA) e BIOS. Essa "barreira dos 640 KB" era um obstáculo significativo, pois aplicativos como o Microsoft Excel exigiam mais memória do que o disponível. O Windows 2.0, operando em modo real, dependia exclusivamente dessa memória, o que limitava o número e a complexidade dos programas executados simultaneamente.
Memória Expandida (EMS - Expanded Memory Specification): Desenvolvida pela Lotus, Intel e Microsoft (LIM), a EMS permitia acessar até 32 MB de memória através de um mecanismo de bank switching. Uma janela de 64 KB na UMA, chamada de page frame, era usada para mapear páginas de memória armazenadas em placas EMS dedicadas ou em memória estendida emulada (no caso do 80386). O Windows 2.x suportava a especificação LIM 4.0, permitindo que aplicativos como o Aldus PageMaker armazenassem dados ou código na EMS, liberando memória convencional. Por exemplo, ao editar um documento grande no PageMaker, o Windows 2.0 podia mover partes do código para a EMS, mantendo mais espaço para o documento na memória convencional. No Windows/386, a emulação EMS usava o gerenciador de memória do 80386, eliminando a necessidade de placas físicas, o que era um diferencial significativo.
Memória Estendida (XMS - Extended Memory Specification): Disponível a partir do 80286, a XMS permitia acessar memória acima de 1 MB em modo protegido, usando o driver HIMEM.SYS. O High Memory Area (HMA), uma região de 64 KB logo acima do 1 MB (endereços 100000h a 10FFEFh), era particularmente importante. O Windows/286 usava o HMA para armazenar partes do kernel, liberando memória convencional para aplicativos. Por exemplo, ao carregar o Windows/286, o HIMEM.SYS movia o código do sistema para o HMA, permitindo que um aplicativo como o Microsoft Word utilizasse mais dos 640 KB disponíveis. A XMS também suportava memória estendida para aplicativos nativos do Windows, embora poucos existissem na época.
Upper Memory Area (UMA) e Upper Memory Blocks (UMBs): A UMA, entre 640 KB e 1 MB, era reservada para hardware, mas áreas não utilizadas podiam ser aproveitadas como UMBs para carregar drivers e programas residentes (TSRs), como gerenciadores de mouse ou rede. No entanto, o Windows 2.x não suportava UMBs nativamente, ao contrário de gerenciadores de memória como o EMM386, que só se tornariam comuns com o MS-DOS 5.0. Isso significava que drivers como o SMARTDRV.SYS (um cache de disco) tinham que residir na memória convencional, reduzindo o espaço para aplicativos. O Windows/286 e /386 mitigavam isso parcialmente ao usar o HMA, mas a falta de suporte a UMBs era uma limitação significativa. Por isso, sugiro que sempre que forem instalar VM com esses SO antigos, instalem as versões mais modernas possíveis para mitigarem essas limitações. Por exemplo, pra que instalar um MS-DOS 3.0 com Windows/286 enquanto você pode simplificar sua vida com um MS-DOS 6.22 (e todo o suporte mais moderno de gerenciamento de memória) com um Windows/386?
Endereçamento de Memória: Nos 8086/8088, o endereçamento em modo real usava um sistema de segmento:offset, onde um endereço físico era calculado como segmento × 16 (decimal ou &H10 hexadecimal) + offset, limitado a 1 MB. Por exemplo, o endereço &HC000:0010 correspondia a (&HC000 x &H0010) + &H0010 = &HC0000 + &H0010 = &HC0010 (786,448 bytes). O 80286 introduziu o modo protegido, com descritores de segmento que permitiam acessar 16 MB, mas a transição entre modos real e protegido era lenta, exigindo um reset do processador. O 80386 resolveu isso com o modo virtual 8086, que emulava múltiplos ambientes de modo real em modo protegido, cada um com 1 MB de memória virtual. O Windows/386 usava esse recurso para rodar aplicativos MS-DOS em máquinas virtuais, com o kernel gerenciando a memória estendida para alocar recursos dinamicamente.
Suporte a Gráficos VGA
O padrão VGA (Video Graphics Array), introduzido em 1987, suportava 256 cores (com 16 cores simultâneas a 640x480), um avanço em relação ao CGA (4 cores, 320x200) e EGA (16 cores, até 640x350). O VGA usava memória de vídeo dedicada (geralmente 256 KB), acessível via portas de E/S e mapeada na UMA (endereços A0000h a BFFFFh). O Windows 2.x aproveitava o VGA para exibir janelas com bordas nítidas, fontes escaláveis e cores mais vibrantes, essenciais para aplicativos gráficos como o Microsoft Excel, que usava gráficos para exibir planilhas. Por exemplo, ao plotar um gráfico de barras no Excel, o VGA permitia cores distintas para cada barra, melhorando a legibilidade em comparação com o EGA. No entanto, o suporte a VGA exigia adaptadores gráficos compatíveis, que eram caros em 1987, limitando sua adoção inicial (uma placa VGA custava, em 1987, entre US$ 200 a 500, cerca de US$500 a 1250 em valores atuais!).
Impacto no Windows 2.x
Esses avanços permitiram que o Windows 2.x superasse as limitações do Windows 1.0, que era restrito a modo real, gráficos EGA e 640 KB de memória convencional. O Windows/286 usava o HMA e o modo protegido do 80286 para liberar memória convencional, enquanto o Windows/386 explorava o modo virtual 8086 e a emulação EMS para multitarefa preemptiva e maior eficiência. Por exemplo, um usuário corporativo com um 80386 e 2 MB de RAM podia rodar o Windows/386, abrir o Excel para analisar dados financeiros, o Word para redigir relatórios e um terminal MS-DOS para comunicações, com o sistema alternando entre eles sem conflitos. Essas capacidades tornaram o Windows 2.x mais viável para ambientes gráficos e produtividade, embora ainda dependesse do MS-DOS para operações de baixo nível.
Concorrentes da Época: Como Utilizavam o Hardware
O mercado de sistemas operacionais para PCs era altamente competitivo, com o Apple Macintosh System Software, o OS/2 e o GEM como principais concorrentes. Cada um explorava o hardware de forma distinta, com pontos fortes e fracos que influenciaram sua adoção.
Apple Macintosh System Software (System 4.x)
O Macintosh System Software 4 (System 4.0/4.1) foi lançado em 1987, com o System 4.0 em março, junto com o Macintosh SE, e o System 4.1 em abril, com o Macintosh II. Ele rodava em Macs com processadores Motorola 68000 e 68020, como o Macintosh Plus, SE e II, introduzindo suporte a cores no Macintosh II (até 256 cores), expansão de slots, Apple Desktop Bus (ADB) e discos rígidos internos. O System 4.x aprimorou o Hierarchical File System (HFS) e trouxe o MultiFinder, permitindo multitarefa cooperativa, um avanço significativo para a época. O sistema usava um sistema de endereçamento linear, acessando memória esticada diretamente, sem as limitações de segmentação dos processadores Intel.
Em concorrência com o Windows 2.x, lançado no mesmo ano, o System 4.x se destacava pela interface gráfica intuitiva, com janelas sobrepostas e integração perfeita com o hardware Apple, oferecendo uma experiência mais fluida que o Windows, que dependia do MS-DOS e tinha multitarefa limitada (exceto no Windows/386). Suas vantagens incluíam estabilidade, design consistente e suporte a aplicativos como MacPaint e MacWrite, ideais para design gráfico. No entanto, era limitado pelo hardware proprietário caro (Macintosh SE custava ~$2.900) e pela multitarefa cooperativa (exigindo que aplicativos cedessem controle ao sistema, o que podia causar travamentos). O Windows 2.x, mais acessível e compatível com PCs diversos, tinha maior alcance, mas era menos refinado.
O System 4.x usava linguagens como Pascal e Assembly 68000, com o MacApp framework facilitando o desenvolvimento de aplicativos gráficos.
.jpg)
OS/2 1.x
O OS/2 1.x, lançado em 1987 por Microsoft e IBM, foi projetado para o 80286, usando o modo protegido para acessar até 16 MB de memória. Ele introduziu multitarefa preemptiva e, na versão 1.1 (1988), o Presentation Manager, uma interface gráfica semelhante ao Windows 2.1.
Desenvolvido em C e Assembly, o OS/2 era um projeto conjunto da IBM, que buscava um sistema corporativo, e da Microsoft, que ainda colaborava antes de focar no Windows. A parceria, porém, já mostrava tensões, com a Microsoft priorizando o Windows, enquanto a IBM assumiu maior controle do OS/2.
Várias razões técnicas e práticas contribuíram para esta separação. As duas empresas tinham diferenças em cultura e visão. A Microsoft preferia uma abordagem de sistema de hardware aberto, enquanto a IBM queria o OS/2 para impulsionar as vendas de seu próprio hardware e teria pressionado a Microsoft a abandonar recursos que o hardware da IBM não suportava. Os programadores da Microsoft também se incomodavam com a burocracia da IBM e com o uso de linhas de código para medir a produtividade do programador e que isso causava um código excessivamente inchado, enquanto os desenvolvedores da IBM reclamaram da concisão e da falta de comentários no código da Microsoft.
Além disso, o OS/2 1.x, mesmo sendo de 1987, tinha como alvo o Intel 80286, um processador de 16 bits de 1982, já em meia vida, enquanto o Windows 2.x tinha versões para o 80286 e para o 80386, um processador de 32 bits, lançado em 1985. Assim, o Windows 2.x (versão 386) conseguia executar multitarefa e acessar a memória extra enquanto o OS/2 estava limitado aos 640KB.
O OS/2 usava o HPFS (High Performance File System) em versões posteriores, mais eficiente que o FAT do MS-DOS e um meio irmão do NTFS, padrão atual do Windows desde o Windows NT. Sua robustez e suporte a aplicativos MS-DOS em modo protegido eram pontos fortes, mas exigia no mínimo 2 MB de RAM e um disco rígido, tornando-o caro (um sistema compatível custava cerca de $2.000). A complexidade de instalação e o suporte limitado a aplicativos nativos (escritos em C e Assembly) limitavam sua adoção. Por exemplo, rodar o Lotus 1-2-3 no OS/2 era mais estável que no Windows, mas exigia configuração manual de memória.
Se você quiser testar estas as versões iniciais, use este emulador online para navegador aqui.
Já falei do OS/2 aqui e aqui, mas ambos os casos foram da versão Warp 4.5, a última disponível.
GEM (Graphics Environment Manager)
Lançado pela Digital Research em 1985, foi uma interface gráfica para o MS-DOS, projetada para PCs IBM-compatíveis e, posteriormente, para o Atari ST como parte do TOS (The Operating System).
Desenvolvido em C e Assembly, o GEM surgiu como uma resposta ao sucesso da interface gráfica do Macintosh, oferecendo um ambiente WIMP (janelas, ícones, menus e ponteiros) que competia diretamente com o Windows 1.0 e, mais tarde, com o Windows 2.x. Inicialmente, o GEM foi bem recebido, especialmente por sua leveza e suporte a aplicativos como GEM Write e Ventura Publisher, amplamente usado em editoração eletrônica.
No entanto, uma disputa legal com a Apple em 1985, que alegou plágio da interface do Macintosh, forçou a Digital Research a remover recursos como janelas sobrepostas e animações no GEM 2.0, reduzindo sua atratividade. O GEM continuou a evoluir, com a versão 3.0 (1988) introduzindo troca de tarefas e suporte a até dez programas via memória expandida (EMS), mas perdeu mercado para o Windows e foi descontinuado no início dos anos 1990, com seu código-fonte liberado sob GPL anos depois.
O GEM usava o sistema de arquivos FAT, padrão do MS-DOS, sem suporte a sistemas mais avançados como HPFS ou NTFS, que só surgiriam mais tarde. Suas principais características incluíam suporte a gráficos CGA, EGA e, posteriormente, VGA, uma interface intuitiva com janelas (limitadas a lado a lado após a disputa com a Apple) e um desktop com ícones. O GEM Desktop 3.0 trouxe melhorias como fontes escaláveis e suporte a impressoras PostScript, mas não oferecia multitarefa preemptiva, apenas troca de tarefas, o que limitava sua eficiência em comparação com o Windows/386. O GEM rodava em sistemas modestos, exigindo apenas 512 KB de RAM, contra os 2 MB recomendados do Windows/386, tornando-o acessível para PCs mais simples, como o IBM PC/XT.
Na competição com o MS-DOS e o Windows 2.x, o GEM tinha vantagens claras em sua leveza e facilidade de uso, especialmente em máquinas com recursos limitados. Enquanto o MS-DOS era baseado em texto e carecia de interface gráfica nativa, o GEM oferecia uma experiência visual semelhante ao Macintosh, mas a um custo menor (um PC com GEM custava cerca de $1.000, contra $2.900 do Macintosh SE). Comparado ao Windows 2.x, o GEM era menos exigente, mas não explorava o modo protegido do 80286 ou a multitarefa preemptiva do 80386, recursos que davam ao Windows/386 uma vantagem técnica. A falta de suporte robusto a aplicativos nativos e a dependência do MS-DOS também limitavam sua escalabilidade, enquanto o Windows se beneficiava de aplicativos como Microsoft Word e Excel.
As desvantagens do GEM incluíam sua incapacidade de competir com o crescente ecossistema de aplicativos do Windows e a perda de funcionalidades devido à disputa legal com a Apple, que enfraqueceu sua competitividade.
Curiosidade: o GEM foi amplamente adotado no Atari ST como TOS, tornando-se a base da interface gráfica desse computador, popular entre músicos e artistas gráficos nos anos 1980 devido a aplicativos como o Cubase. Seu legado perdura no código-fonte aberto, OpenGEM, que ainda é estudado por entusiastas de sistemas retro.
Quer testar online o TOS do Atari ST? Clique aqui!
Posicionamento do Windows 2.x no Mercado
O Windows 2.x foi lançado em um mercado fragmentado, com o MS-DOS dominando, mas com crescente demanda por interfaces gráficas. Ele se posicionava como uma solução acessível, compatível com o vasto ecossistema IBM PC, ao contrário do Macintosh, que exigia hardware proprietário (um IBM PC com 80386 custava cerca de $1.500, contra $2.900 do Macintosh SE). O Windows/286 ($99) e Windows/386 ($195) eram mais baratos que licenças do OS/2 (cerca de $325). A introdução do Microsoft Word e Excel, que competiam com WordPerfect e Lotus 1-2-3, atraiu usuários corporativos. Por exemplo, o Excel permitia criar planilhas gráficas com fontes TrueType, mais amigáveis que o Lotus 1-2-3 em modo texto. Apesar disso, as vendas do Windows 2.x foram modestas (1 milhão em 1988, menos de 2 milhões até 1990), refletindo sua percepção como um sistema em transição.
Versões do Windows 2.x: 2.0, 286 e 386
Ufa! Depois deste texto todo, agora a gente entende porque existiam três versões do Windows 2.x: eram versões específicas para explorar diferentes processadores, cada uma com características e limitações distintas.
Windows 2.0 (Base Edition)
Lançado em 9 de dezembro de 1987, o Windows 2.0 operava em modo real, compatível com 8086/8088, usando memória convencional (640 KB) e EMS via placas LIM 4.0. Ele suportava gráficos VGA e janelas sobrepostas, mas a ausência de multitarefa preemptiva limitava sua eficiência. Por exemplo, rodar o Microsoft Word e o Paintbrush simultaneamente exigia que o usuário alternasse manualmente entre eles, com pausas frequentes. Sua compatibilidade com PCs mais antigos era uma vantagem, mas a barreira dos 640 KB restringia aplicativos maiores.
Windows/286
Renomeado com o Windows 2.1 (maio de 1988), o Windows/286 usava o HMA (64 KB acima de 1 MB) via HIMEM.SYS para liberar memória convencional. Ele suportava modo protegido do 80286, acessando até 16 MB, mas a multitarefa era cooperativa, o que causava instabilidade se um aplicativo travasse. Por exemplo, abrir o Excel e o Word simultaneamente podia resultar em um crash se um deles não liberasse o controle adequadamente. O suporte a placas EMS LIM 4.0 permitia rodar aplicativos como o PageMaker, mas a falta de suporte a UMBs limitava a flexibilidade.
Windows/386
Lançado em setembro de 1987, o Windows/386 usava o modo protegido e o modo virtual 8086 do 80386 para multitarefa preemptiva de aplicativos MS-DOS, cada um rodando em sua própria máquina virtual. Ele também oferecia emulação EMS, usando o gerenciador de memória do 80386 para simular memória bancada. Por exemplo, um usuário podia rodar um compilador MS-DOS, o Excel e um jogo como Flight Simulator em paralelo, com o Windows/386 alternando entre eles automaticamente. No entanto, a falta de memória virtual baseada em disco exigia RAM física abundante (mínimo 2 MB, ideal 4 MB), e a incompatibilidade com gerenciadores como QEMM limitava configurações personalizadas.
As versões existiam para atender à diversidade de hardware: o Windows 2.0 para PCs antigos, o Windows/286 para sistemas intermediários e o Windows/386 para máquinas de ponta. Limitações como os 640 KB do 8086 e a ausência de multitarefa preemptiva no 80286 justificavam essas edições.
Pontos Fortes e Fracos
Pontos Fortes
Interface Gráfica Avançada: Janelas sobrepostas, suporte a VGA e atalhos como Alt+F4, alinhados aos padrões CUA da IBM.
Compatibilidade Ampla: O Windows/286 rodava em 8086/8088, enquanto o Windows/386 explorava o 80386.
Multitarefa Preemptiva (Windows/386): Permitia rodar múltiplos aplicativos MS-DOS em paralelo, um diferencial técnico.
Aplicativos de Produtividade: Word e Excel desafiavam líderes como WordPerfect e Lotus 1-2-3.
Emulação EMS: Eliminava a dependência de placas físicas no Windows/386.
Pontos Fracos
Dependência do MS-DOS: Herdou limitações como os 640 KB de memória convencional.
Incompatibilidade com Gerenciadores de Memória: Não suportava QEMM ou CEMM, limitando otimizações.
Adoção Limitada: Menos de 2 milhões de cópias vendidas até 1990.
Instabilidade: A multitarefa cooperativa causava travamentos frequentes.
Requisitos do Windows/386: Exigia hardware caro (80386, 2-4 MB de RAM).
Diferenciais em Relação aos Concorrentes
O Windows 2.x combinava compatibilidade com hardware legado e suporte a processadores modernos, superando o Macintosh em acessibilidade e o OS/2 em leveza. A emulação EMS e a multitarefa preemptiva do Windows/386 eram exclusivas, enquanto Word e Excel ofereciam uma experiência gráfica superior a aplicativos baseados em texto como WordPerfect.
Inovações do Windows 2.x
Janelas Sobrepostas: Inspiradas no Macintosh, mas julgadas legais após disputa judicial.
Suporte a VGA: Melhorou a experiência visual em aplicativos gráficos.
Multitarefa Preemptiva (Windows/386): Única entre os concorrentes.
Emulação EMS: Reduziu a dependência de hardware adicional.
Padrões CUA: Atalhos como Alt+F4 e terminologia como "minimize/maximize".
Painel de Controle: Centralizou configurações do sistema.
Word e Excel: Introduziram produtividade gráfica.
Linguagens de Programação
O Windows 2.x foi desenvolvido em C e Assembly. O C era usado para o kernel e aplicativos, garantindo portabilidade, enquanto o Assembly otimizava operações de baixo nível, como gerenciamento de memória (por exemplo, acesso ao HMA no Windows/286) e controle do modo virtual 8086 no Windows/386. O Windows API, escrito em C, permitia que aplicativos como Word e Excel interagissem com a interface gráfica. O Driver Development Kit (DDK) incluía o WDEB386, um depurador para o 80386, e um linker para o formato de objeto do WIN386.386, usado por OEMs para criar drivers.
Easter Eggs
O Windows 2.x incluía um Easter egg acessado ao pressionar F1, F5, F9, F4, Backspace rapidamente, exibindo uma lista rolante com 79 nomes (Windows/386 2.01) ou 82 nomes (Windows 2.03) dos desenvolvedores, com um botão "Congrats!". Clicar duas vezes na lista mudava o fundo para rostinhos sorridentes, armazenados no bitmap 1 do USER.EXE. No Windows Write, segurar Ctrl+Shift e clicar com o botão direito no número de página inseria uma imagem da equipe do Write.
Bom, estamos chegando ao final! Vamos instalar a versão 386 em uma VM e transferir para o Proxmox! No post de instalação no VMWare em 2018 (aqui) eu falei que tive problemas com o Windows/386. Já em 2023, ao usar o VirtualBox (aqui) eu tinha compreendido um pouco mais sobre essa versão do Windows. Assim, prefiro instalar o Windows/386 (versão 2.11) sobre o MS-DOS 6.22 para usar todos os benefícios otimizados do sistema.
Aqui a gente faz como nas instalações anteriores: instalei o MS-DOS 6.22 com suporte a CD e instalei o mouse. A VM foi configurada com 64MB de RAM (uma loucura para a época, mas vamos lá!). Agora vamos otimizar e liberar a memória no MS-DOS 6.22 para instalar o Windows 2.x/386.
Otimizei os arquivos CONFIG.SYS e AUTOEXEC.BAT para liberar o máximo de memória convencional (até 640 KB) e memória superior (UMBs). Abaixo, explico cada comando e as mudanças realizadas, com base na evolução da memória convencional livre de 578 KB para 608 KB e da memória superior de 24 KB para 28 KB livres.
CONFIG.SYS Inicial
dos=high,umb
files=30
lastdrive=z
device=c:\dos\himem.sys
device=c:\dos\emm386.exe ram
devicehigh=c:\dos\setver.exe
devicehigh=c:\dos\display.sys con=(ega,,1)
devicehigh=c:\drivers\cd1.sys /d:intil
devicehigh=c:\drivers\mouse.sysCONFIG.SYS otimizado
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE NOEMS I=B000-B7FF
DOS=HIGH,UMB
FILES=15
BUFFERS=8
STACKS=8,128
LASTDRIVE=E
DEVICEHIGH=C:\DRIVERS\CD1.SYS /D:INTIL
DEVICEHIGH=C:\DRIVERS\MOUSE.SYS
DEVICEHIGH=C:\DOS\DISPLAY.SYS CON=(EGA,,1)
DEVICEHIGH=C:\DOS\SETVER.EXEExplicação das mudanças:
DEVICE=C:\DOS\HIMEM.SYS:
O que faz: Carrega o gerenciador de memória estendida (XMS), permitindo acesso a memória acima de 1 MB, essencial para o Windows 2.x/386 e SMARTDRV.
Mudança: Mantido como estava, mas movido para o início para garantir que seja carregado primeiro, habilitando DOS=HIGH e EMM386.
DEVICE=C:\DOS\EMM386.EXE NOEMS I=B000-B7FF:
O que faz: Fornece blocos de memória superior (UMBs) e gerencia memória alta (HMA). O NOEMS desativa memória expandida (EMS), economizando memória convencional, já que o Windows 2.x/386 usa principalmente XMS.
Mudança: Trocado de RAM para NOEMS para liberar memória convencional. Adicionado I=B000-B7FF para incluir a região de memória monocromática (B000-B7FF) nos UMBs, aumentando o espaço total de UMBs de 95 KB para ~127 KB, resultando em 28 KB livres.
DOS=HIGH,UMB:
O que faz: Move o núcleo do MS-DOS para a HMA (64 KB acima de 1 MB) e habilita UMBs para carregar drivers e TSRs.
Mudança: Mantido, garantindo que o DOS não ocupe memória convencional e que UMBs estejam disponíveis para DEVICEHIGH e LOADHIGH.
FILES=15:
O que faz: Define o número máximo de arquivos abertos simultaneamente.
Mudança: Reduzido de 30 para 15, economizando ~0.7-1 KB de memória convencional, já que o Windows 2.x/386 e aplicativos típicos não precisam de muitos arquivos abertos.
BUFFERS=8:
O que faz: Define buffers de disco para E/S, cada um usando ~512 bytes.
Mudança: Adicionado explicitamente (padrão era ~15) e reduzido para 8, economizando ~3.5 KB de memória convencional, com mínimo impacto no desempenho.
STACKS=8,128:
O que faz: Configura pilhas para interrupções de hardware, cada uma usando ~128 bytes.
Mudança: Adicionado e reduzido do padrão (~9,256) para 8,128, economizando ~1-2 KB de memória convencional.
LASTDRIVE=E:
O que faz: Limita as letras de unidade até E:, suficiente para o drive de CD-ROM (D:).
Mudança: reduzido de Z para E, adequado para a configuração.
DEVICEHIGH=C:\DRIVERS\CD1.SYS /D:INTIL, MOUSE.SYS, DISPLAY.SYS, SETVER.EXE:
O que faz: Carrega drivers na memória alta (UMBs) para liberar memória convencional. CD1.SYS suporta o drive de CD-ROM, MOUSE.SYS o mouse, DISPLAY.SYS caracteres internacionais, e SETVER.EXE compatibilidade de versão.
Mudança: Reorganizados para carregar drivers maiores (CD1.SYS, MOUSE.SYS) primeiro, reduzindo fragmentação nos UMBs. Mantidos, mas podem ser removidos se não necessários (ex.: DISPLAY.SYS se acentos não forem usados).
AUTOEXEC.BAT Inicial
c:\dos\smartdrv.exe /x
@echo off
Prompt $p$g
Path c:\dos
Set temp=c:\dos
C:\dos\mscdex.exe /d:intil
Lh c:\dos\doskey.com
Lh c:\dos\mouse.exeAUTOEXEC.BAT otimizado
@ECHO OFF
PROMPT $P$G
PATH C:\DOS
SET TEMP=C:\DOS
LH C:\DOS\MSCDEX.EXE /D:INTIL
LH C:\DOS\SMARTDRV.EXE /X 512
LH C:\DOS\DOSKEY.COMExplicação das mudanças:
@ECHO OFF:
O que faz: Desativa a exibição de comandos no boot, tornando a inicialização mais limpa.
Mudança: Movido para o início do arquivo para maior consistência.
PROMPT $P$G:
O que faz: Configura o prompt para mostrar o diretório atual (ex.: C:\>).
Mudança: Mantido, sem impacto na memória.
PATH C:\DOS:
O que faz: Define onde o DOS procura executáveis.
Mudança: Mantido, minimalista e suficiente.
SET TEMP=C:\DOS:
O que faz: Define o diretório para arquivos temporários.
Mudança: Mantido, sem impacto na memória.
LH C:\DOS\MSCDEX.EXE /D:INTIL:
O que faz: Carrega o suporte a drives de CD-ROM, associando o drive D: ao dispositivo INTIL do CD1.SYS.
Mudança: Adicionado LH para carregar na memória alta (UMBs), liberando ~25-40 KB de memória convencional. Movido para antes do SMARTDRV para correta inicialização.
LH C:\DOS\SMARTDRV.EXE /X 512:
O que faz: Carrega o cache de disco para melhorar o desempenho de leitura/escrita. /X desativa cache de gravação, e 512 define o tamanho do cache em 512 KB.
Mudança: Adicionado LH para carregar nos UMBs, liberando ~29 KB de memória convencional. Definido cache de 512 KB para economizar XMS (de ~1-2 MB padrão para 512 KB).
LH C:\DOS\DOSKEY.COM:
O que faz: Adiciona histórico de comandos e macros ao prompt do DOS.
Mudança: Mantido com LH, ocupando ~6 KB nos UMBs. Pode ser removido se não essencial, economizando espaço.
Remoção de MOUSE.EXE:
O que faz: Tentava carregar um driver de mouse redundante, mas causava erro File not found.
Mudança: Removido, já que MOUSE.SYS no CONFIG.SYS já fornece suporte ao mouse.
Resultados
Memória convencional: Aumentou de 578 KB para 608 KB livres (+30 KB), permitindo programas maiores no DOS e Windows 2.x/386 (precisa de pelo menos 512KB livres).
Memória superior (UMB): Aumentou de 95 KB (24 KB livres) para ~127 KB (28 KB livres, maior bloco 17 KB) com I=B000-B7FF, oferecendo mais espaço para drivers e TSRs.
XMS: Reduziu uso de 2353 KB para 849 KB, liberando 63568 KB, suficiente para o Windows 2.x/386.
Estabilidade: O sistema roda sem erros, com suporte a CD-ROM, mouse e Windows 2.x/386.
Têm alguns sites para ajudar nessa configuração de CONFIG.SYS e AUTOEXEC.BAT. O Blog do Michael é muito bom e eu gosto muito da didática e escrita dele. Este outro aqui, Madsen World, também é bem legal e tem um layout antigo que me agrada muito! O TechTarget também ajudou a esclarecer algumas coisas.
DEVICE=C:\DOS\HIMEM.SYS
DOS=UMB
FILES=30
DEVICE=C:\DOS\DISPLAY.SYS CON=(EGA,,1)
# VBoxManage clonehd --format RAW "W386.vdi" "W386.raw"# VBoxManage convertdd "W386.vdi" "W386.raw" --format RAW# qm importdisk 105 Windows 1.04.raw VM-Disk
Nenhum comentário:
Postar um comentário