Windows 95
Não há como negar: o Windows 95 é realmente uma grande evolução comparado ao seu antecessor, Windows 3.11. Ele é muito mais fácil de usar e configurar. Entretanto, notamos claramente um marketing exagerado depositado em cima desse sistema operacional, muitas vezes atribuindo-o características que não possui.
Modo real e modo protegido
Processadores acima do 386 possuem dois modos de operação bem distintos: o modo real e o modo protegido. No modo real o processador funciona como se fosse um 8086, o processador utilizado no primeiro PC. Isto significa que ele utilizará instruções de 16 bits e, o que é pior, conseguirá acessar somente a 1 MB de memória. É o caso do sistema MS-DOS: sua grande limitação é trabalhar apenas no modo real, o que faz com que ele acesse somente 1 MB de memória (destes 1 MB, 640 KB é destinado à memória RAM).
No modo protegido, o processador consegue trabalhar no topo de sua performance: além de instruções de 32 bits, consegue 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 trabalha em modo protegido, e daí a sua grande vantagem: não possui limitações de memória e pode contar com recursos avançados fornecidos pelo processador. Há, todavia, um grande problema: o sistema operacional do Windows 3.x é o MS-DOS. Qualquer operação de manipulação de arquivos requer que o MS-DOS desempenhe este papel; o Windows precisa 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 95
Porém é falsa a afirmação de que o Windows 95 não precisa do MS-DOS. Ele utiliza uma nova versão do MS-DOS (chamaremos aqui de "MS-DOS 7") para o seu processo de boot e para algumas (poucas) subrotinas não existentes no núcleo do Windows 95.
O "MS-DOS 7", porém, não trabalha em modo real, mas sim no modo virtual 8086. Este modo de operação, presente no modo protegido dos atuais processadores, permite com que um processador 8086 com 1 MB seja "simulado" em memória. Várias sessões 8086 podem ser abertas simultaneamente, permitindo com que vários programas escritos para o modo real possam ser executados ao mesmo tempo. Há também uma grande vantagem no modo virtual 8086: a área de memória da sessão virtual 8086 é isolada do restante da memória; é protegida. Isto evita que programas desastrados a sobreponham sem querer.
Por que a Microsoft simplesmente não fez o Windows 95 totalmente em modo protegido ? Compatibilidade. Medo de que algum programa escrito para MS-DOS não "rodasse" no Windows 95. Se você der boot somente com o prompt do Windows 95 (pressionando a tecla [F8] quando aparecer a mensagem "Iniciando Windows 95..."), você terá carregado em seu micro uma nova versão do MS-DOS.
Pelo mesmo motivo, o arquivo que contém o código de carregamento do sistema operacional possui o mesmo nome: IO.SYS. É neste arquivo que o "MS-DOS 7" está armazenado. Este é o primeiro arquivo a ser carregado durante o boot do Windows 95.
No MS-DOS, o segundo arquivo a ser carregado era o MSDOS.SYS. O "MS-DOS 7" está totalmente dentro do arquivo IO.SYS, de forma que concluímos que o MSDOS.SYS não é necessário para o Windows 95. 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 fica armazenado no diretório raiz do disco rígido com Windows 95. Para não desperdiçar espaço com um arquivo "fantasma", o MSDOS.SYS passou a ser um arquivo de configuração do Windows 95. Podemos editá-lo da mesma forma que editamos um CONFIG.SYS ou AUTOEXEC.BAT.
Figura 1: MSDOS.SYS: Apenas um arquivo de configuração do Windows 95.
Seqüência de boot do Windows 95:
1 - Bootstrap (Setor de boot do disco rígido) carrega e executa IO.SYS
2 - É feita a leitura da configuração contida em MSDOS.SYS
3 - CONFIG.SYS é lido e executado, caso exista
4 - Se existir o arquivo AUTOEXEC.BAT, o COMMAND.COM é executado de modo que os comandos do AUTOEXEC consigam ser executados
5 - AUTOEXEC.BAT é lido e executado, caso exista. Caso não exista, uma vantagem: o COMMAND.COM não é executado (desde que você também não tenha escolhido a opção "somente prompt" durante o boot).
6 - WIN.COM é executado. Este arquivo é um mero "chamador" do Windows 95. Caso você tenha dado boot com a opção "somente prompt", o processo de boot termina no passo anterior.
7 - WINSTART.BAT é lido e executado.
8 - VMM32.VXD é executado. Este é um dos arquivos mais importantes do Windows 95, pois é o Gerenciador de Máquinas Virtuais. Neste momento o processador passa para o modo protegido.
Daí por diante, a carga do Windows 95 varia um pouco de sistema para sistema, sobretudo pelas configurações que estejam presentes no registro do Windows 95 e nos arquivos SYSTEM.INI e WIN.INI, responsáveis pela configurações básicas do sistema.
O DOS no Windows 95
Entre as inúmeras vantagens do Windows 95 sobre o DOS está a sua capacidade de suporte a periféricos. O Windows 95 detecta e gerencia qualquer periférico instalado em seu micro, coisa que o MS-DOS não fazia. Não há 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 95 gerencia periféricos automaticamente.
Dentro do Windows 95 há duas formas básicas de se acessar o MS-DOS: saindo-se do Windows 95 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ê opte para chamar o MS-DOS, uma coisa é certa: o ambiente será igual ao boot do "MS-DOS 7" antes da carga do núcleo do Windows 95 (ou seja, antes da execução do WIN.COM), utilizando, portanto, a mesma configuração.
O primeiro caso equivale a dar boot somente com o prompt do DOS, o que pode ser feito pressionando-se a tecla [F8] durante o boot, porém com um detalhe: quando você executa este procedimento, o arquivo DOSSTART.BAT presente no diretório C:\WINDOWS é executado. De qualquer forma, sair para o modo MS-DOS ou dar boot somente com o prompt equivale a mesma coisa: você estará no prompt do "MS-DOS 7" e o Windows 95 não estará carregado em memória.
No segundo caso, a história é outra: uma sessão virtual 8086 é aberta, simulando um processador 8086 com 640 KB de RAM e com o "MS-DOS 7". Esta sessão estará protegida em memória e o Windows 95 continuará carregado, dando todo o suporte a periféricos, tais como o kit multimídia ou a placa fax-modem. É preferível que você execute programas MS-DOS no Windows 95 desta forma.
Além do suporte a periféricos, que é muito importante, há uma outra vantagem em utilizar uma sessão MS-DOS: flexibilidade. Criando um atalho para um programa MS-DOS no Windows 95, você poderá configurar exatamente como será a sessão virtual 8086, em especial em relação a configurações de memória, um assunto especialmente traumático para os usuários iniciantes.
Criar um atalho na interface do Windows 95 é simples: basta clicar com o botão direito do mouse em qualquer área livre, escolhendo a opção "novo" e, em seguida "atalho". Definimos o caminho e o nome do arquivo a ser executado e, em seguida, nome e ícone para o atalho. Tudo muito simples.
Para configurar a sessão de seu atalho, basta clicar com o botão direito sobre seu ícone, escolhendo a opção "propriedades". Nas propriedades do atalho podemos fazer desde configurações simples (tais como o tipo de letra que será utilizado pela sessão) até configurações avançadas (como as referidas configurações de memória).
Figura1: Exemplo de configuração de um atalho para programa MS-DOS.
Versão anterior do MS-DOS
Quando você faz um "upgrade" do MS-DOS 6 para o Windows 95, o programa de instalação faz um backup dos arquivos do sistema: os arquivos IO.SYS, MSDOS.SYS, COMMAND.COM, CONFIG.SYS e AUTOEXEC.BAT transformam-se em, respectivamente, IO.DOS, MSDOS.DOS, COMMAND.DOS, CONFIG.DOS e AUTOEXEC.DOS. Isto permite que, quando necessário, você carregue o MS-DOS 6, pressionando a tecla [F4] ou a tecla [F8] quando aparecer a mensagem "Iniciando Windows 95...". No caso da tecla [F8], basta você escolher a opção "Carregar versão anterior do MS-DOS" do menu que aparecerá.
A multitarefa
Todos os processadores a partir do 386 fazem multitarefa automaticamente quando estão em modo protegido. Para isto, no entanto, é necessário que cada aplicativo esteja 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 protege seus aplicativos em memória. Para o processador, há uma única área sendo utilizada pelo Windows e seus aplicativos; não há divisão. Logo concluímos que não pode existir multitarefa nesse 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 é quem comandará a alternância para o próximo aplicativo da lista de tarefas. Se o aplicativo simplesmente "empacar" ou demorar para chavear para o próximo aplicativo, a "multitarefa" pára. O que é extremamente comum de ocorrer (Quem nunca tentou imprimir um documento grande ? A impressão empaca se a proteção de tela entrar em ação ou você tentar abrir um outro aplicativo. Estes são sintomas típicos da multitarefa cooperativa).
Um sistema operacional decente deve ter uma multitarefa que funcione. E, para isto, necessitará que seus aplicativos sejam protegidos em memória. A vantagem de um aplicativo protegido em memória não está só no fato dele usufruir a verdadeira multitarefa - chamada multitarefa preemptiva. Estando protegido em memória, um aplicativo está isolado dos demais. Caso ocorra algum problema neste aplicativo, o próprio processador é capaz de reportar esta condição ao sistema operacional, que trata de remover o aplicativo integralmente da memória. O sistema operacional torna-se mais seguro. No modelo utilizado pelo Windows 3.x, onde não há proteção de memória, um programa facilmente invade a área ocupada por outro programa, ocasionando o temível erro de Falha Geral de Proteção, o GPF - o que normalmente obriga ao 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 95 protege seus aplicativos em memória, o que, além de torná-lo menos propenso a erros de GPF, permite a utilização da verdadeira multitarefa, a multitarefa preemptiva.
Porém nem tudo é um mar de rosas. O esquema de proteção de memória do Windows 95 só funciona para aplicativos escritos para o Windows 95 ("aplicativos de 32 bits"). Aplicativos escritos para Windows 3.x ("aplicativos de 16 bits") não são protegidos em memória no Windows 95. Por este motivo, enfatizamos: evite utilizar aplicativos escritos para Windows 3.x - tais como o Word 6, Excel 5 e Access 2 - no Windows 95. Dê preferência aos aplicativos escritos para o Windows 95 ("aplicativos de 32 bits").
Se aplicativos de 16 bits forem executados no Windows 95, dois grande problemas ocorrem. O primeiro, evidentemente, é a fragilidade do sistema. Sem proteção de memória erros de Falha Geral de Proteção são muito mais freqüentes. O segundo grande problema é 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 95 entra numa espécie de "modo de compatibilidade" para conseguir executar esses aplicativos. O Windows 95 se transforma, "por debaixo dos panos", em Windows 3.11, o que faz com que toda a multitarefa pare, mesmo que você tenha 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 95 só funciona se você estiver executando exclusivamente aplicativos escritos para Windows 95 ("aplicativos de 32 bits"). Basta abrir um único aplicativo escrito para Windows 3.x ("aplicativo de 16 bits") que o esquema de multitarefa passa de preemptiva para cooperativa, transformando o Windows 95 em um Windows 3.11 "de luxo", não importando a quantidade de aplicativos de 32 bits que estejam abertos.
O Windows 95 é um sistema operacional realmente 32 bits?
Vimos que o boot do Windows 95 é feito por uma nova versão do MS-DOS trabalhando no modo virtual 8086. Do ponto de vista prático, este procedimento não acarreta nenhum problema, pois após a carga do VMM32.VXD o Windows 95 permanece 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 95 a partir do zero. Mas ela não fez isto, por um motivo bem simples: ela queria que o Windows 95 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 95 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 95 possuem 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 95 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 95 continua possuindo os três arquivos contendo o mesmo código de 16 bits presente no Windows 3.11.
O Windows 95 funciona da seguinte forma: quando um aplicativo de 32 bits é executado, ele utiliza única e exclusivamente o núcleo 32 bits - o Kernel32, o GDI32 e o User32. Já um aplicativo de 16 bits, porém, tem 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 95 tem que ser especialmente qualificado. Quando um aplicativo de 16 bits faz uma chamada a uma subrotina presente no núcleo de 16 bits, este redireciona esta chamada ao núcleo de 32 bits.
Teoricamente este processo funcionaria maravilhosamente bem, mas não é bem assim o andar da carruagem. Como a Microsoft decidiu não compilar totalmente os três núcleos do Windows 95 para o modo protegido de 32 bits por causa das exigências de memória RAM, estes núcleos não possuem todas as subrotinas 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.
Quando um programa chama uma subrotina do GDI ou do User, caso esta subrotina não esteja presente no núcleo de 32 bits porque não foi implementada, o núcleo de 32 bits chama a subrotina necessária no núcleo de 16 bits.
O problema deste processo é claro: mesmo aplicativos de 32 bits uma vez ou outra utilizarão código de 16 bits, porque o GDI32 e o User32 não possuem todas as subrotinas necessárias implementadas em modo protegido de 32 bits.
O problema é maior ainda, pois o código de 16 bits é 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 pode ser executado simultaneamente por mais de um programa. Ou seja, tudo pára quando o núcleo de 16 bits é acessado. E vimos que mesmo aplicativos de 32 bits acessam indiretamente o núcleo de 16 bits do Windows 95...
É por este motivo, por exemplo, que às vezes quando você maximiza e minimiza programas no Windows 95 a janela do programa demora um pouco para ser formada, mesmo quando estamos trabalhando somente com aplicativos de 32 bits e mesmo com um micro com dezenas de MB de memória RAM: o GDI32 (que é o núcleo responsável por desenhar as janelas) de vez em quando acessa subrotinas presentes no núcleo de 16 bits. E neste instante tudo pára, pois o código de 16 bits não pode ser acessado simultaneamente por mais de um aplicativo.
Não parece que tudo isto importe tanto, afinal afirmamos anteriormente que o núcleo básico do Windows 95 - 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 acessam o Kernel. E vice-e-versa. Desta forma, o Kernel32 acessa de vez em quando o User32 ou o GDI32. E vimos que o User32 e o GDI32 de vez em quando acessam o User16 e o GDI16, sendo que estes dois acessam o Kernel16 (KRNL386)...
Conclusões
Não importa que você tenha somente aplicativos de 32 bits nem que você tenha centenas de MB de RAM em seu micro. O Windows 95 é um sistema operacional híbrido que ainda acessa código de 16 bits. Como este código não pode ser acessado por mais de um programa ao mesmo tempo, tudo pára até que o código seja "liberado" por quem o esteja acessando.
Por outro lado, é importante enfatizarmos que o Windows 95 somente protege em memória aplicativos de 32 bits. Se você utilizar ao menos um aplicativo de 16 bits, o esquema de proteção de memória é deixado de lado e a multitarefa passa a ser igual à multitarefa utilizada pelo Windows 3.x. Em outras palavras, quando um aplicativo de 16 bits é aberto, o Windows 95 "se transforma" em Windows 3.11 para executá-lo, sendo os demais aplicativos que porventura estejam abertos prejudicados por esta mudança.
CONHEÇA UM POUCO SOBRE / LINKS E REFERÊNCIA BIBLIOGRÁFICAS /