detalhes sobre a partida da maquina, vamos entender como funcionam os arquivos de configuração e inicialização da maquina, como é montado o registro, desde o Windows 98 até o Windows vista e 7. Pensando assim, vamos começar tentando entender como são gerenciados os endereços de memória e como a Microsoft sempre os utilizou em cada sistema, começando pelo MSDOS para que tenhamos uma idéia mais aprofundada e possamos entender melhor o tema.

ARQUIVOS DE CONFIGURAÇÃO DO MS-DOS

CONFIG.SYS

O Sistema Operacional MS-DOS possuía um arquivo de configuração no diretório raiz, chamado CONFIG.SYS.

Era através deste arquivo que o sistema operacional era configurado em sua forma mais básica.

Nos sistemas Windows 9x e Windows NT, esse arquivo não era tão importante, pois raramente necessitavam que o usuário alterasse o seu conteúdo.

O mesmo, porém, não ocorria no MS-DOS.

Como o MS-DOS era um sistema operacional extremamente rudimentar, ele por si só não reconhecia os periféricos mais modernos da época - tais como unidades de cd-rom e placas de som, você deveria ensinar ao sistema como ele deveria fazer para lidar com estes recursos tão modernos "rsrsrsrs".

Este era o papel do driver, um pequeno programa carregado em memória que "ensinava" ao sistema como trabalhar com um determinado periférico. No MS-DOS, os drivers eram carregados geralmente pelo CONFIG.SYS. 

Eles também poderiam ser carregados pelo AUTOEXEC.BAT. No CONFIG.SYS, os drivers eram carregados através do comando DEVICE= ou DIVECEHIGH=.

Além disso, o MS-DOS possuía outro grande inconveniente, ele trabalhava em modo real e por isto reconhecia somente 640 KB de memória RAM.

A solução para isto era fazer com que o driver fosse carregado na área de memória acima de 640 KB, chamada de memória superior, fazendo com que a memória convencional não ficasse muito ocupada.

Isto era feito através do comando DEVICEHIGH=.

A edição do CONFIG.SYS não era tão difícil, bastava utilizar o comando EDIT do MS-DOS. No prompt do MS-DOS, como: EDIT C:\CONFIG.SYS.

Os comandos existentes no CONFIG.SYS são exclusivos. Isto quer dizer que você não poderia entrar com um comando do CONFIG.SYS diretamente no prompt do MS-DOS.

Além do mais o CONFIG.SYS só era lido uma única vez, quando o sistema operacional era carregado. (Se você já fez um curso de MSDOS, coloquei para relembra, se não fez, essa é uma boa oportunidade de aprender os principais comandos utilizados).

PRINCIPAIS COMANDOS USADOS NO CONFIG.SYS

DEVICE= : Para carregar o controlador de dispositivo instável para a memória (um controlador de dispositivos instável é um programa que controla um componente de hardware).

DEVICEHIGH=: Para carregar um controlador de dispositivos instável na área de memória superior.

DOS=: Para especificar se o MS-DOS deveria usar a área de memória alta (HMA) e se permitiria acesso a área de memória superior (UMB).

FILES=: Para especificar quantos arquivos poderiam ser abertos ao mesmo tempo.

INSTALL=: Para carregar um programa residente em memória (TRS).

REM=: Para indicar que o seguinte texto é um comentário descritivo, não um comando. Poderia ser utilizado para desativar um comando.

SET=: Para define o valor de variáveis de ambiente, tal como prompt ou temp.

CONTROLADORES DE DISPOSITIVOS INSTÁVEL

Um controlador é denominado instável porque você o instala incluindo um comando no arquivo Config.sys

COUNTRY.SYS: Para definir as convenções de idioma do país

DISPLAY.SYS: Para aceitar mudança de página de códigos para monitores.

EMM386.EXE: Para simular memória expandida e permite o acesso a área de memória superior.

HIMEM.SYS: Para gerenciar o uso de memória estendida.

SETVER.EXE: Para carregar a tabela de versão do MS-DOS na memória.

Em geral, para que o seu micro fique "no ponto", você deve editar o CONFIG.SYS da seguinte forma:

Caso um dia você precise criar um CONFIG.SYS básico para MS-DOS e não sabe como ele deve ser, utilize o exemplo abaixo.

device=c:\dos\himem.sys

device=c:\dos\e,,386.exe noems

dos=high,umb

stack=9,256

files=40

buffers=20

country=055,,c:\dos\country.sys

devicehigh=c:\dos\display.sys con=(,850)

devicehigh-c:\windows\ifshlp.sys

CONFIG.SYS PADRÃO PARA WINDOWS 9X (95/98)

Device=c:\windows\command\display.sys con=(ega,,1)

Country=055,850,c:\windows\command\country.sys

CONFIGURANDO O AUTOEXEC.BAT

O AUTOEXEC.BAT é um arquivo em lote (extensão BAT). Isto significa que qualquer comando válido existente pode ser executado diretamente no prompt do MS-DOS, ao contrário do que ocorre no CONFIG.SYS, que possui comandos próprios. Sua edição pode ser feita através do comando EDIT C:\AUTOEXEC.BAT. Da mesma forma que ocorre no CONFIG.SYS, através do AUTOEXEC.BAT carregamos drivers, comandos e programas residentes em memória.

PRINCIPAIS COMANDOS USADOS NO AUTOEXEC.BAT

PROMPT: Para definir o aspecto do seu aviso de comando.

PATH: Para especificar os diretórios e a ordem na qual o MS-DOS pesquisa arquivos executáveis (arquivos com extensão COM, EXE, BAT).

ECHO OFF: Para instruir o MS-DOS a não exibir os comandos do seu arquivo autoexec.bat a medida que são executados.

SET: Para criar uma variável de ambiente que pode ser usada por programas.

LOADHIGH: Para carregar controladores de dispositivos instável para área de memória superior.

MODE: Para definir as características do seu teclado, monitor, impressora e portas de comunicação.

AUTOEXEC.BAT NO WINDOWS 9X

@ echo off

Set temp=c:\windows\temp

If exist c:\windows\temp\~*.* del c:\windows\temp\~*.*

Mode con codepage prepare=((850) c:\windows\command\ega.cpi)

Mode con codepage select=850

Loadhigh= c:\windows\command\keyb.com br

Loadhigh=c:\windows\command\doskey.com

Path=c:\windows;c:\windows\command;c:\

Cls

 

O QUE É O REGISTRO?

De acordo com a Microsoft, o Registro do Windows de 32 bits ( Windows 9x e Windows NT ) é um banco de dados hierárquico que centraliza e armazena todas as configurações de hardware e software do computador.

Banco de dados porque sua função primordial é o armazenamento de dados de configuração chamados valores. Hierárquico, porque como você terá a oportunidade de examinar, a estrutura do Registro é semelhante à estrutura hierárquica de uma árvore de diretórios e subdiretórios, o que confunde muitos usuários desavisados que imaginam que as chaves de Registro são realmente pastas ocultas do Windows existentes no disco.

ORIGENS DO REGISTRO

O primeiro esboço do Registro surgiu no Windows 3.1 com o arquivo Reg.dat. Na época era um tanto limitado, servindo exclusivamente para guardar informações sobre associações de arquivos (que permitiam que o comando associar do gerador de arquivos do Windows 3.1 funcionasse ) e também informasse sobre OLE ( Object linking and Embedding ) usadas pelos aplicativos clientes ou servidores OLE.

REGISTRO DO WINDOWS 98

A estrutura do Registro do Windows 98 é idêntica a do Windows NT XP e Seus sucessores. Sua única diferença consiste em novas informações que foram acrescentadas à cada versão a fim de dar suporte aos inúmeros novos recursos dessa nova versão, como drives DVD, barramentos USB (Universal Serial Bus) e Fire Wire, suporte a múltiplos monitores, aperfeiçoamentos na tecnologia infrared, tecnologia push, suporte aos novos drives etc. Isso faz aumentar o tamanho dos arquivos correspondentes ao Registro no disco rígido a cada versão Windows que é lançada.

A Microsoft afirma que embora não seja possível perceber nenhuma diferença significativa na estrutura do Registro, o código que o implementa, é sempre otimizado (em nível binário), de modo a aumentar a velocidade do seu processamento etc.

ARQUIVO DO REGISTRO DO WINDOWS 9X

Windows 98 armazena o conteúdo do Registro em dois arquivos chamados SYSTEM.DAT e USER.DAT. O primeiro armazena as chaves e sub-chaves relativas à configuração do hardware e do software. O segundo guarda as configurações específicas dos usuários.

ARQUIVOS DE CÓPIA DO REGISTRO DO WINDOWS 98

No Windows 98 as cópias dos arquivos do Registro são guardadas na pasta %WINDIR%\SYSBCKUP, uma pasta (oculta) que já existia desde o Windows 95 e servia para armazenar alguns drivers e dlls.

As cópias são armazenadas em pastas compactadas no formato cabinet, semelhantes às existentes no CD-ROM de instalação do Windows 98.

Cada pasta possui o nome RB00x no qual x é um número no qual pode variar de 0 a 5. O Windows cria no máximo 5 dessas pastas de backup e dentro de cada uma delas encontraremos a cópia dos seguintes arquivos:

SYSTEM.DAT

USER.DAT

SYSTEM.INI

WIN.INI CÓPIA MANUAL NO WINDOWS 98

Uma vez que o Windows esteja funcionando perfeitamente bem, é aconselhável criar uma cópia manual dos arquivos do registro. Para isso é necessário desativar os atributos hidden e system de USER.DAT e SYSTEM.DAT. Utilizamos, para isso, o utilitário ATTRIB.EXE existente na pasta COMMAND que sempre existe dentro do diretório do Windows.

Como \%WINDIR%\COMMAND está referenciado no path do Windows, podemos dar os comandos abaixo de dentro do diretório do Windows:

attrib c:\windows\*.da? -h -r -s -a

del c:\windows\*.dat

ren c:\windows\*.da? *.dat

attrib c:\windows\*.dat +h +r +s +a

Agora é possível usar o comando COPY para copiar ambos os arquivos para um local seguro.

Se você consegue "navegar" pelo Windows Explorer não sentirá nenhuma dificuldade em navegar pelo Editor de Registro.

O Registro é formado por 6 chaves básicas (listamos na ordem em que aparecem no Editor de Registro):

HKEY_CLASSES_ROOT

KEY_CURRENT_USER

KEY_LOCAL_MACHINE

HKEY_USERS

HKEY_CURRENT_CONFIG

HKEY_DYN_DATA

Em cada chave é armazenado um tipo diferente de informação. Iremos ver como funciona cada chave e qual o tipo de informação há armazenada.

Sempre que possível iremos apresentar dicas que sejam válidas para todos os micros.

É muito importante notar que não há como fazermos um tutorial válido para todos os micros, pois em cada micro o Registro será um pouco diferente, já que os programas e periféricos instalados varia de micro para micro, mas vamos apresentar para você a maioria dos sistemas operacionais da Microsoft, desde o Windows 9X até o Vista.

HKEY_LOCAL_MACHINE

Essa é a chave mais importante do Registro Windows 98. É nela que estão armazenadas informações a respeito dos periféricos e programas instalados no micro - incluindo a configuração do próprio Windows 9x. Fisicamente falando, as informações dessa chave estão armazenadas no arquivo System.dat. Essa chave possui as seguintes sub-chaves.

Config: Armazena configurações para os Perfis de Hardware instalados no micro. Na maioria das vezes temos somente um perfil de hardware instalado e, daí, essa chave normalmente apresenta somente uma subchave - 0001 - que contém informações sobre esse único perfil. Caso você crie novos perfis de hardware (o que pode ser feito através da guia Perfis de Hardware do ícone Sistema do Painel de Controle) novas chaves são criadas. Durante o boot o Windows 9x carrega a configuração do perfil de hardware selecionado para a máquina.

Enum: Informações sobre o hardware do micro.

hardware: Informações sobre portas seriais e modems utilizados pelo programa HyperTerminal (como você pode reparar, o nome dessa chave pode enganar muita gente).

Network: Informações criadas quando um usuário se conecta a um micro conectado em rede. Armazena informações como nome do usuário, logon, tipo de servidor, etc.

Security: Informações sobre a segurança da rede e administração remota.

SOFTWARE: Informações e configurações de programas instalados no micro. Nessa chave as informações são armazenadas no padrão fabricante/programa/versão /configurações.

Por exemplo, configurações do programa Photoshop são armazenadas na chave Adobe/Photoshop/4.0. Interessante notar que as configurações do próprio Windows estão armazenadas nessa chave, em Microsoft/Windows.

System: Essa chave comanda o carregamento de drivers durante o boot e demais configurações do sistema operacional. A subchave Control contém informações utilizadas durante o carregamento do sistema operacional, enquanto a subchave Services contém informações sobre o carregamento de drivers de dispositivo.

HKEY_USERS

O Windows 9x permite que mais de usuário utilize um mesmo micro, cada um com suas configurações particulares, tais como proteção de tela, papel de fundo, atalhos presentes na área de trabalho, etc. A escolha do usuário é feita no logon do Windows, quando o sistema pede o nome do usuário e sua senha. Essa chave armazena as configurações do sistema para cada usuário e fisicamente está armazenada no arquivo User.dat.

Quando o sistema está configurado para o acesso por apenas um usuário, a chave HKEY_USER contém apenas uma subchave, .default, contendo todas as configurações pessoais do sistema (proteção de tela, papel de parede, etc).

No caso de haver mais de um usuário configurado no sistema, quando ele faz logon no sistema, essa chave conterá suas configurações pessoais. Por exemplo, no caso de haver um usuário chamado Adonel, existirá uma chave chamada "Adonel" quando esse usuário entrar no sistema. A chave .default continuará existindo, contendo as configurações padrão do sistema.

Interessante notar que nessa chave só estão disponíveis as configurações pessoais do usuário que fez logon do sistema.

Se no mesmo micro existir um outro usuário chamado Maria, a chave "Maria" só existirá quando o próprio usuário logon no sistema, de forma que um usuário não consiga ver nem alterar configurações de outro usuário (ou seja, o usuário Maria não conseguirá ver as configurações do Adonel e vice-e-versa).

HKEY_CURRENT_USER

Essa chave é um atalho para a chave do usuário que fez logon no sistema. Ou seja, se o usuário "Adonel" foi quem fez logon no sistema, essa chave apontará para a chave HKEY_USERS\Adonel. Portanto, fisicamente essa chave não existe, pois apenas aponta para outra parte do registro.

HKEY_CLASSES_ROOT

Essa chave é um atalho para a chave

HKEY_LOCAL_MACHINE\SOFTWARE\Classes. Essa chave existe para manter compatibilidade com programas de 16 bits, pois no registro do Windows 3.x só havia uma única chave principal no registro, chamada HKEY_CLASSES_ROOT. Da mesma forma que a chave anterior, essa chave não existe fisicamente; ela apenas aponta para outra área do registro.

HKEY_CURRENT_CONFIG

Essa chave também é um atalho (ou seja, não existe fisicamente, apenas aponta para outra área do registro), desta vez para HKEY_LOCAL_MACHINE\Config\xx, onde xx é o perfil de hardware que está atualmente configurado. Como na maioria dos micros só há um único perfil de hardware configurado, normalmente essa chave aponta para HKEY_LOCAL_MACHINE\Config\0001.

Você pode saber qual é o perfil de hardware que está sendo atualmente utilizado no sistema lendo o valor presente em HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\ConfigDB.

HKEY_DYN_DATA

Todas as configurações armazenadas nas chaves anteriores são estáticas, ou seja, são armazenadas em algum lugar do disco rígido (em geral nos arquivos System.dat e User.dat). A chave HKEY_DYN_DATA contém informações dinâmicas e que existem somente na sessão atual.

Essas informações são lidas durante o boot da máquina e contém informações como a lista de dispositivos Plug and Play instalados no micro (essas informações são armazenadas na subchave Config Manager\Enum). Essas informações ficam armazenadas em memória RAM e, portanto, são criadas a cada boot da máquina.

ARQUIVOS DE CONFIGURAÇÃO DO WINDOWS 9X

MS-DOS.SYS

O MS-DOS.SYS era o arquivo mais importante do Sistema Operacional Ms-Dos, pois ele controlava toda a memória que o MS-DOS poderia enxergar. Sendo um arquivo que continha rotinas de programação executáveis. O MSDOS.SYS no Ms-Dos, era um arquivo binário.

No Windows 9x, porém tudo mudou completamente de figura. As antigas funções do MSDOS.SYS foram incorporadas pelo IO.SYS no Windows 98. A nova função do MSDOS.SYS era então controlar o modo como o sistema operacional era inicializado.

MSDOS.SYS

[ Paths ]

WINDIR = C:\WINDOWS

WINBOOTDIR = C:\WINDOWS

HOSTWINBOOTDRV = C

[ Options ]

BOOTMULT = 1

BOOTGUI = 1

BOOTMENU = 1

BOOTDEDEY = 6

LOGO = 0

NETWORK = 0

VARIÁVEIS DO MSDOS.SYS:

[ PATHS ] = Essa seção indicava o caminho para alguns diretórios importantes, armazenando-os em variáveis.

WINDIR = Definia a localização do diretório de instalação do Win 98.

WINBOOTDIR = Definia onde estavam localizados os arquivos necessários ao processo de inicialização, geralmente C:\Windows.

HOSTWINBOOTDRV = C:  Definia a localização do diretório raiz usada no processo de Boot.

[ OPTIONS ]= Essa seção armazenava variáveis que podiam mudar o comportamento de inicialização do Sistema Operacional.

AUTOSCAN= Permitia definir se o Scandisk seria executado automaticamente quando o computador fosse reiniciado. Para desabilitar essa função, o valor seria mantido em 0. Se o valor fosse 2 o scandisk seria executado automaticamente quando fosse necessário, sem solicitar confirmação.

BOOTMENUDELAY = N: Quando o computador era inicializado, o usuário teria n segundos para pressionar uma tecla de função ( F8, ESC, Etc. ) que deveria ser pressionada após o aparecimento da mensagem de inicialização do Windows 98 ou um pouco antes.

BOOTKEY= N: Habilitava o uso de teclados de função durante a inicialização. Quando o valor 1 era atribuído a essa variável, as teclas não teria nenhum efeito e qualquer valor atribuído a Bootdelay = n seria ignorado.

BOOTMULT = 1 Ou 0

O Default 1 permitia que o usuário pudesse escolher o Sistema Operacional a ser utilizado na ocasião da inicialização da máquina. O valor “ 0 “ travava essa opção, obrigando o micro a utilizar o Sistema Operacional escolhido com Default.

Obs.: Essa opção só fazia sentido quando instalávamos o Windows 95 ou Win 98.

BOOTWIN = 1 ou 0: O número 1 fazia com que o Sistema Operacional Default fosse o Win 9X. Se alterarmos para 0, o Sistema Operacional escolhido seria a antiga versão do MS-DOS que se encontrava na máquina na ocasião da instalação do Windows.

BOOTGUI = 1 ou 0: Válidas apenas se Bootwin = tivesse sido definida com valor 1, ou se aquela variável não existisse no MS-DOS.SYS.

Se Bootgui fosse definida com 1, o Win 98 seria inicializado imediatamente após o Dos 7.10. Se a variável fosse definida com 0, um micro inicializava direto no Prompt do Dos.

LOGO = 0: esse valor 1 habilitava a exibição do logotipo animado do Windows e era estabelecido por Default.

BOOTMENU = 1 ou 0

0 – Carregava o Sistema sem mostrar o Menu de inicialização.

1 – Carregava o Menu de inicialização sem necessidade de pressionar-se a tecla de F8.

Bootmenudefault = n: Definia a opção que seria carregada à do sinal de igualdade.

Bootmenudelay = n: Definia quantos segundo o Sistema iria esperar.

ARQUIVOS DE INICIALIZAÇÃO DO WINDOWS 9X

WIN.INI

A função principal desse arquivo de inicialização era armazenar os parâmetros utilizados pelo ambiente Windows em sua área de trabalho, embora guardasse também outros tipos de informação.

Sua primeira seção denominava-se [Windows]:

[Windows]

spooler=yes

load=

run=

Beep=yes

Programas=com exe bat pif

DeviceNotSelectedTimeout=

TransmissionRetryTimeout=45

KeyboardSpeed=31

ScreenSaveActive=1

Essa seção armazenava alguns valores que poderiam ser escolhidos no painel de Controle do Windows, como, por exemplo, se o spooler ou gerenciador de impressão estava ou não ativado.

A variável programas definiam as extensões dos programas que o Windows considerava executáveis. Por default são as mesmas do MS-DOS acrescidas da extensão .PIF. algumas outras poucas poderiam ser artificialmente acrescentadas pelo usuário, como por exemplo, a extensão. SCR.

As demais opções forneciam o resultado de algumas escolhas feitas no painel de controle. Era mais seguro usar essa ferramenta do Windows para fazer tais modificações do que editar diretamente o WIN.INI.

A próxima seção é denominada[Desktop] e era a mais interessante de todas, pois permitia que o usuário inserisse uma série de variáveis que não constam como opção no painel de controle.

[Desktop]

Pattern=(nenhum)

TileWallPaper=0

GridGraunularity=0

IconSpacing=75

Wallpaper=(nenhum)

Poucas variáveis do WIN.INI eram capazes de produzir algum efeito no comportamento do Windows 9X, porém algumas delas (por exemplo, Run e Load= Executavam e carregavam qualquer programa executável.

SYSTEM.INI

Do ponto de vista do Hardware, esse era o mais importante dos arquivos de inicialização do Windows. Uma única linha errada, referência a um único arquivo de driver inexistente no SYSTEM.INI, impedia o Windows 9X de ser carregado corretamente.

A primeira seção do SYSTEM.INI era [Boot] e definia alguns itens básicos que deveriam ser carregados logo no início do Windows, por exemplo os núcleos do sistema GDI,USER, a Shell ativa, isto é, a interface de usuário a ser utilizada. Por default era o gerenciador de Programas (Progman.exe), mais você poderia mudá-la para Qualquer outro.

[Boot]

shell=program.exe

system.drv=system.drv

keyboard.drv= keyboard.drv

mouse.drv= mouse.drv

display.drv=vga.drv

comm.drv=comm.drv

sound.drv=mmsound.drv

386grabber=vga.3gr

fixedfon.fon=vgafix.fon

SCRNSAVE.EXE=C:\WINDOWS\SOSPERSW.SCR

As demais seções do SYSTEM.INI eram excessivamente técnicas, e em sua maioria, serviam para carregar dispositivos que controlavam o hardware para a memória RAM. A mais importante era a [386 Enh].

WIN.COM

O Win.com era um pequeno arquivo executável para MS-DOS e funcionava como um “gatilho” que servia para detonar o processo de carga de todos os módulos que iriam compor o ambiente Windows.

O QUE O WIN.COM FAZIA

O Win.com executava as tarefas, nesta ordem:

Verificava o tipo de máquina, a quantidade de memória e drivers instalados.

Chamava o módulo WIN386.EXE

Carregava as DLLs principais (arquivos do núcleo).

Carregava os drives de dispositivos.

Carregava as fontes e os arquivos de suporte aos idiomas utilizados.

Carregava os aplicativos não-Windows (isto é, suporte aos programas MS-DOS).

Carregava os arquivos que forneciam suporte aos componentes MS-DOS no Windows.

PROGMAN.INI

Esse arquivo definia as diversas opções de personalização para a Shell do Windows 3.1x; o Gerenciador de Programas.

CONTROL.INI

O arquivo CONTROL.INI continha diversas seções. Algumas delas eram modificadas por meio do Painel de Controle. Ele não tinha grande importância no Windows 98, tendo sido mantido por questões de compatibilidade com aplicativos WIN 16.

SISTEMA OPERACIONAL WINDOWS 9X

O Windows 9x foi realmente uma grande evolução comparado aos seus antecessores. Ele era muito mais fácil de usar e configurar. Entretanto, houve claramente um marketing exagerado, muitas vezes atribuindo-o características que não o possui.

Vamos a alguns exemplos:

Modo real e modo protegido

Processadores acima do 386 já possuam dois modos de operação bem distintos: o modo real e o modo protegido. No modo real o processador funcionava como se fosse um 8086, o processador utilizado no primeiro PC. Isto significava que ele utilizava instruções de 16 bits e, o que era pior, conseguiria acessar somente 1 MB de memória.

Era o caso do sistema MS-DOS: sua grande limitação era trabalhar apenas no modo real, o que fazia com que ele acesse somente 1 MB de memória (destes 1 MB, 640 KB era destinado à memória RAM).

No modo protegido, o processador conseguira trabalhar no topo de sua performance: além de instruções de 32 bits, conseguiu acessar a até 4 GB de memória, além de diversos outros recursos, em especial a multitarefa, a memória virtual e o modo virtual 8086.

O Windows 3.x trabalhava em modo protegido, e daí a sua grande vantagem: não possuir limitações de memória e poder contar com recursos avançados fornecidos pelo processador. Havia porem, um grande problema: Para o sistema operacional Windows 3.x e o MS-DOS. Qualquer operação de manipulação de arquivos necessitaria que o MS-DOS desempenhasse este papel; o Windows precisava do MS-DOS para funções básicas.

A idéia era escrever um sistema operacional de modo protegido, que não utilizasse o modo real ou o MS-DOS como base.

A Microsoft dizia que era assim que seria o Windows 95.

O Boot do Windows 9X

Porém era falsa a afirmação de que o Windows 9X não precisaria do MS-DOS. Ele passou a utilizar uma nova versão do MS-DOS (chamada de "MS-DOS 7") para o seu processo de boot e para algumas sub-rotinas não existentes em seu núcleo.

O "MS-DOS 7", porém, não trabalhava mais em modo real, mas sim no modo virtual 8086. Este modo de operação, presente no modo protegido dos processadores da época, permitiam que um processador 8086 com 1 MB fosse "simulado" em memória.

Várias sessões 8086 poderiam ser abertas simultaneamente, permitindo que vários programas escritos para o modo real fossem executados ao mesmo tempo. Havia também uma grande vantagem no modo virtual 8086: a área de memória da sessão virtual 8086 era isolada do restante da memória; era protegida. Isto evitaria que programas desastrados viessem a sobrepor sem querer.

Por que a Microsoft simplesmente não fez o Windows 9X totalmente em modo protegido? Compatibilidade.

Medo de que algum programa escrito para MS-DOS não "rodasse" no Windows 9X. Se você desse boot somente com o prompt do Windows 95 (pressionando a tecla [F8] quando aparecesse á mensagem "Iniciando Windows 95 ou 98..."), você teria carregado em seu micro uma nova versão do MS-DOS.

Pelo mesmo motivo, o arquivo que continha o código de carregamento do sistema operacional possuía o mesmo nome: IO.SYS. era neste arquivo que o "MS-DOS 7" estava armazenado. Este era o primeiro arquivo a ser carregado durante o boot do Windows 9X.

No MS-DOS, o segundo arquivo a ser carregado era o MSDOS.SYS. O "MS-DOS 7" estava totalmente dentro do arquivo IO.SYS, de forma que concluímos que o MSDOS.SYS não era necessário para o Windows 9X.

No entanto, alguns programas antigos escritos para MS-DOS poderiam verificar a presença deste arquivo no diretório raiz do primeiro disco rígido, podendo acusar uma mensagem de erro. Para isto não acontecer, a Microsoft criou um arquivo MSDOS.SYS "fantasma" que ficava armazenado no diretório raiz do disco rígido com Windows 9X. Para não desperdiçar espaço com um arquivo "fantasma", o MSDOS.SYS passou a ser um arquivo de configuração do Windows 9X.

Poderíamos editá-lo da mesma forma que editávamos um CONFIG.SYS ou AUTOEXEC.BAT.

Nesse caso, a sequência de boot do Windows 9X ficou assim:

Bootstrap do Bios (Setor de boot do disco rígido) carregava e executava IO.SYS

Era feita a leitura da configuração contida em MSDOS.SYS

CONFIG.SYS era lido e executado, caso existisse, se existisse o arquivo AUTOEXEC.BAT, o COMMAND.COM era executado de modo que os comandos do AUTOEXEC conseguissem ser executados

AUTOEXEC.BAT era lido e executado, caso existisse. Caso não existisse: o COMMAND.COM não era executado.

WIN.COM era executado. Este arquivo era um mero "chamador" do Windows 9X. Caso você tivesse dado boot com a opção "somente prompt", o processo de boot terminava no passo anterior.

WINSTART.BAT era lido e executado.

VMM32.VXD era executado. Este era um dos arquivos mais importantes do Windows 9X, pois era o Gerenciador de Máquinas Virtuais. Neste momento o processador passava para o modo protegido.

Kernel32.dll e Kernel386.exe

GDI32.dll e GDI.exe

User32.dll e User.exe

Fontes e outros recursos

Win.ini

A interface Gráfica

Componentes da área de trabalho e daí por diante, a carga do Windows 9X variava um pouco de sistema para sistema, sobretudo pelas configurações que estivessem presentes no registro do Windows 9X e nos arquivos SYSTEM.INI e WIN.INI, responsáveis pelas configurações básicas do sistema.

O DOS no Windows 9X

Entre as inúmeras vantagens do Windows 9X sobre o DOS estava a sua capacidade de suporte a periféricos. O Windows 9X detectava e gerenciava qualquer periférico instalado em seu micro, coisa que o MS-DOS não fazia. Não havia mais a necessidade de colocarmos drivers de periféricos no CONFIG.SYS ou no AUTOEXEC.BAT como fazíamos no MS-DOS, pois o Windows 9X gerenciava periféricos automaticamente.

Dentro do Windows 9X havia duas formas básicas de se acessar o MS-DOS: saindo-se do Windows 9X com a opção "Desligar", "Reiniciar o computador em modo MS-DOS" ou abrindo-se uma sessão MS-DOS através de um atalho ou do ícone "Prompt do MS-DOS". Independentemente da maneira que você optasse para chamar o MS-DOS, uma coisa era certa: o ambiente seria igual ao boot do "MS-DOS 7" antes da carga do núcleo do Windows 9X (ou seja, antes da execução do WIN.COM).

O primeiro caso equivale a dar boot somente com o prompt do DOS, o que poderia ser feito pressionando-se a tecla [F8] durante o boot, porém com um detalhe: quando você executava este procedimento, o arquivo DOSSTART.BAT presente no diretório C:\WINDOWS era executado.

No segundo caso, a história era outra: uma sessão virtual 8086 era aberta, simulando um processador 8086 com 640 KB de RAM e com o "MS-DOS 7". Esta sessão estaria protegida em memória e o Windows 9X continuaria carregado.

A multitarefa

Todos os processadores a partir do 386 já faziam multitarefa automaticamente quando estavam em modo protegido. Para isto, no entanto, era necessário que cada aplicativo estivesse protegido em memória, ou seja, isolado em sua própria área na memória.

Mais uma vez por motivos de compatibilidade, o Windows 3.x não poderia proteger seus aplicativos em memória. Para o processador, havia uma única área sendo utilizada pelo Windows e seus aplicativos; não havia divisão. Logo concluímos que não pode existir multitarefa naquele ambiente.

A Microsoft, porém, queria porque queria que o Windows 3.x fosse multitarefa. Como o processador não poderia comandar a multitarefa (já que os programas não estavam protegidos em memória), a solução encontrada foi fazer com que os próprios aplicativos a controlassem, criando o termo multitarefa cooperativa.

Neste caso, o próprio aplicativo era quem comandaria a alternância para o próximo aplicativo da lista de tarefas. Se o aplicativo simplesmente "empacasse" ou demorasse para chavear para o próximo aplicativo, a "multitarefa" pararia. O que era extremamente comum de ocorrer (quem trabalhou nessa época deve lembrar muito bem quando se tentava imprimir um documento grande e a impressão empacava, ou se a proteção de tela entrasse em ação quando você tentava abrir um outro aplicativo).

(Estes eram sintomas típicos da multitarefa cooperativa).

Um sistema operacional decente deveria ter uma multitarefa que funcionasse, e, para isto, necessitava que seus aplicativos fossem protegidos em memória. A vantagem de um aplicativo protegido em memória não estava só no fato dele usufruir a verdadeira multitarefa - chamada multitarefa preemptiva.

Estando protegido em memória, um aplicativo estava isolado dos demais.

Caso ocorresse algum problema neste aplicativo, o próprio processador era capaz de reportar esta condição ao sistema operacional, que tratava de remover o aplicativo integralmente da memória. O sistema operacional tornava-se mais seguro.

No modelo utilizado pelo Windows 3.x, onde não havia proteção de memória, um programa facilmente invadia a área ocupada por outro programa, ocasionando o temível erro de Falha Geral de Proteção, o GPF - o que normalmente obrigava o usuário a sair do Windows e chamá-lo novamente, de modo a "limpar" a memória.

Ao contrário do Windows 3.x, o Windows 9X já protegia seus aplicativos em memória, o que, além de torná-lo menos propenso a erros de GPF, permitia a utilização da verdadeira multitarefa, a multitarefa preemptiva.

Porém nem tudo era um mar de rosas. O esquema de proteção de memória do Windows 9X só funcionava para aplicativos escritos para o Windows 9X ("aplicativos de 32 bits"). Aplicativos escritos para Windows 3.x ("aplicativos de 16 bits") não eram protegidos em memória no Windows 9X.

Se aplicativos de 16 bits fossem executados no Windows 9X, dois grande problemas ocorriam.

O primeiro era a fragilidade do sistema. Sem proteção de memória erros de Falha Geral de Proteção eram muito mais frequentes.

O segundo grande problema era a não existência da multitarefa. Como os aplicativos de 16 bits foram escritos não tendo em vista a multitarefa preemptiva mas sim a cooperativa, o Windows 9X entrava numa espécie de "modo de compatibilidade" para conseguir executar esses aplicativos.

O Windows 9X se transformava "por debaixo dos panos", em Windows 3.11, o que fazia com que toda a multitarefa parece, mesmo que você tivesse uma porção de aplicativos de 32 bits sendo executados e apenas um aplicativo de 16 bits.

Em outras palavras, o esquema de multitarefa do Windows 9X só funcionava se você estivesse executando exclusivamente aplicativos escritos para Windows 9X ("aplicativos de 32 bits"). Bastava abrir um único aplicativo escrito para Windows 3.x ("aplicativo de 16 bits") que o esquema de multitarefa passava de preemptiva para cooperativa, transformando o Windows 9X em um Windows 3.11 "de luxo", não importando a quantidade de aplicativos de 32 bits que estivessem abertos.

O Windows 9X era um sistema operacional verdadeiramente de 32 bits?

Vimos que o boot do Windows 9X era feito por uma nova versão do MS-DOS trabalhando no modo virtual 8086. Do ponto de vista prático, este procedimento não acarretava nenhum problema, pois após a carga do VMM32.VXD o Windows 9X permanecia inteiramente em modo protegido e, teoricamente, trabalhando com um novo código de 32 bits.

Nesta afirmação "com um novo código de 32 bits" é que está a chave de tudo. A Microsoft deveria ter escrito inteiramente o Windows 9X a partir do zero. Mas ela não fez isto, por um motivo bem simples: ela queria que o Windows 9X funcionasse em um micro com apenas 4 MB de memória RAM.

Como um código de 32 bits é bem mais complexo e maior que um código de 16 bits, o Windows 9X precisaria de muita memória RAM para "rodar" caso fosse um sistema inteiramente compilado para o modo protegido de 32 bits.

Tanto o Windows 3.x quanto o Windows 9X possuía três núcleos básicos:

Kernel - O núcleo do sistema propriamente dito. É o Kernel que controla o acesso a memória, gerencia a memória virtual, controla os aplicativos, gerencia arquivos, etc.

GDI - Graphics Device Interface. É a parte do Windows responsável pela apresentação de tudo aquilo que está na tela. Todas as janelas e ícones são desenhados pelo GDI.

User - Controla a interface do Windows com o usuário, como entrada de comandos e documentos abertos.

No Windows 3.x, estes três núcleos possuem código de 16 bits, como é de se supor, e estão armazenados nos arquivos KRNL386.EXE, GDI.EXE e USER.EXE. O Windows 9X possui esses três núcleos compilados para o modo protegido de 32 bits, estando armazenados nos arquivos KERNEL32.DLL, GDI32.DLL e USER32.DLL. Apesar disto, o Windows 9X continuou com os três arquivos contendo o mesmo código de 16 bits presente no Windows 3.11.

O Windows 9X funcionava da seguinte forma: quando um aplicativo de 32 bits era executado, ele utilizava única e exclusivamente o núcleo 32 bits - o Kernel32, o GDI32 e o User32. Já um aplicativo de 16 bits, porém, tinham um pequeno problema. Como ele foi escrito de modo a utilizar os arquivos do núcleo de 16 bits (afinal o núcleo de 32 bits não estava presente no Windows 3.x), o núcleo de 16 bits do Windows 9X teria que ser especialmente qualificado. Quando um aplicativo de 16 bits fazia uma chamada a uma sub-rotina presente no núcleo de 16 bits, este redirecionava esta chamada ao núcleo de 32 bits.

Teoricamente este processo funcionava maravilhosamente bem, mas não era bem assim o andar da carruagem. Como a Microsoft decidiu não compilar totalmente os três núcleos do Windows 9X para o modo protegido de 32 bits por causa das exigências de memória RAM, estes núcleos não possuíam todas as sub-rotinas necessárias para a execução dos programas em 32 bits, com exceção do Kernel - que é o núcleo básico e mais importante, tendo sido totalmente reescrito para o modo protegido de 32 bits.

No Windows 9X quando um programa chamava uma sub-rotina do GDI ou do User, caso esta sub-rotina não estivesse presente no núcleo de 32 bits porque não foi implementada o núcleo de 32 bits chamava a sub-rotina necessária no núcleo de 16 bits.

O problema deste processo é que: mesmo aplicativos de 32 bits uma vez ou outra utilizavam código de 16 bits, porque o GDI32 e o User32 não possuíam todas as sub-rotinas necessárias “implementadas” em modo protegido de 32 bits.

O código de 16 bits era um tipo de código não-reentrante: ele foi escrito sem se preocupar com multitarefa. Por este motivo, um código de 16 bits não poderia ser executado simultaneamente por mais de um programa. Ou seja, tudo para, quando o núcleo de 16 bits é acessado.

É por este motivo, que às vezes quando você maximizava e minimizava programas no Windows 9X a janela do programa demorava um pouco para ser formada, mesmo quando estávamos trabalhando somente com aplicativos de 32 bits e mesmo com um micro com dezenas de MB de memória RAM: o GDI32 (que era o núcleo responsável por desenhar as janelas) de vez em quando acessava sub-rotinas presentes no núcleo de 16 bits.

Não parece que tudo isto importe tanto, afinal afirmamos anteriormente que o núcleo básico do Windows 9X - o Kernel32 - foi totalmente compilado para o modo protegido de 32 bits e, por este motivo, o sistema estaria totalmente a salvo destes problemas.

Há, no entanto, um detalhe importante: tanto o GDI quanto o User acessavam o Kernel E vice-e-versa. Desta forma, o Kernel32 acessava de vez em quando o User32 ou o GDI32. E vimos que o User32 e o GDI32 de vez em quando acessavam o User16 e o GDI16, sendo que estes dois acessavam o Kernel16 (KRNL386)...

Não importava se você tivesse somente aplicativos de 32 bits nem que você tivesse centenas de MB de RAM em seu micro. O Windows 9X era um sistema operacional híbrido que ainda acessava código de 16 bits. Como este código não poderia ser acessado por mais de um programa ao mesmo tempo, tudo parava até que o código fosse "liberado" por quem estivesse acessando. Por outro lado, é importante enfatizarmos que o Windows 9X somente protegia em memória aplicativos de 32 bits. Se você utilizasse ao menos um aplicativo de 16 bits, o esquema de proteção de memória era deixado de lado e a multitarefa passaria a ser igual à multitarefa utilizada pelo Windows 3.x. Em outras palavras, quando um aplicativo de 16 bits era aberto, o Windows 9X "se transformava" em Windows 3.11.

Compreendendo o arquivo IO.SYS

Na época em que o Ms-dos era utilizado como Sistema Operacional, esse arquivo funcionava como um dos núcleos desse sistema contendo o MSDOS – BIOS e o módulo de inicialização do MS – DOS, o SYSINIT, que consistiam em devices drivers residentes (rotinas de baixo nível destinadas a controlar os dispositivos periféricos suportados pelo computador) e, um módulo adicional de inicialização.

Com o advento do Windows 95, esse arquivos passou a ser o próprio DOS 7.10, ou seja, o Sistema Operacional em modo Real (16 bits), inserido no Windows9x, executando funções bem diferentes das anteriores.

Esse arquivo contém informações necessárias para inicializar o computador e carregar dispositivos do sistema que antes eram carregados pelos arquivos Autoexec.bat e Config.sys.

Os drivers carregados como padrão no IO.SYS incluem os seguintes arquivos:

HIMEM.SYS

IFSHLP.SYS

SETVER.EXE

DBLSPACE.BIN ou DRVSPACE.BIN

A maioria das funções comuns desempenhadas pelas várias entradas no arquivos Config.sys passaram a ser fornecidas por padrão no IO.SYS.

Parâmetros do Config.sys incorporadas ao IO.SYS

Dos=High

Himem.sys

Ifshlp.sys

Setver.exe

Files=

Lastdrive=

Buffers=

Stacks=

Shell=command.com

Fcbs=

Nota: O IO.SYS não carrega o EMM386.EXE. Se qualquer um dos seus aplicativos exigir memória expandida, ou carregar os dados para a área de memória superior, o EMM386 deverá ser definido no Config.sys.

COMMAND.COM

Este arquivo é o interpretador de comandos padrão do MS-DOS e demais sistemas da Microsoft, mesmo os mais modernos tem um interpretador de comando.

Este interpretador de comandos servirá de interface entre o usuário e o Sistema, sendo capaz de executar um grupo de funções internas, tais como manipular arquivos ou interpretar arquivos de processamento em lote (que fornecem uma limitada linguagem de programação, útil para escrevermos pequenos programas compostos de uma sequência de comando do MSDOS). Quando executado, inicialmente o COMMAND.COM procura por um arquivo chamado AUTOEXEC.BAT e, se existir, interpreta-os antes de qualquer outra operação.

Este arquivo estava residente em dois diretórios sendo o primeiro no diretório raiz, a inexistência desse arquivo neste diretório, fazia com que o sistema operacional não inicializasse, acusando a falta de um interpretador de comandos.

O segundo estava presente no diretório C:\Windows, a inexistência desse arquivo neste diretório também fazia com que o sistema não acesse o modo DOS.