windows vamos aprender mais um coxe 6

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 freqüentes.

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 paresse, 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 continua possuindo 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 pára, 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)...

abraço