Gerenciamento de Memória - Windows 16 bits

O início da história das interfaces gráficas com o usuário (GUIs) é provavelmente o computador Alto, demonstrado pela Xerox em 1973 e nunca lançado comercialmente. O Alto, e o seu sucessor o Star, foram desenvolvidos por um centro de pesquisa da Xerox chamado PARC.

Em 1980, algumas semanas antes da Microsoft fechar as negociações do DOS com a IBM, um dos desenvolvedores da Xerox bateu na porta da Microsoft. Era Charles Simonyi, um húngaro que tinha desenvolvido o processador de textos do Alto, provavelmente o primeiro editor "WYSIYWYG". Alguns meses depois ele estava contratado como diretor de desenvolvimento de produtos avançados, se dedicando inicialmente ao desenvolvimento do tipo de aplicações que atualmente chamamos de Office (planilha eletrônica, editor de texto, etc).

As idéias da PARC corriam soltas na nascente indústria de microcomputadores. Na Apple, geraram o Lisa e depois o Mac. Na Comdex de 1982 Bill Gates levou um susto com um produto chamado VisiOn. Desenvolvido pela empresa responsável pelo VisiCalc (a primeira planilha eletrônica), o VisiOn era um pacote de aplições completo com interface gráfica, rodando no PC. A única boa notícia é que o produto ainda não estava pronto. Ao longo de 1983 diversos outros sistemas gráficos e multitarefa foram anunciados.

A resposta da Microsoft chamava-se inicialmente Interface Manager. Na Comdex de 1983 já estava rebatizado para Microsoft Windows e era objeto de uma campanha de marketing sem precedentes. Após várias mudanças de curso e uma negociação em cima da hora com a Apple, o Windows foi finalmente lançado na Comdex de 1985. Embora as primeiras notícias tenham sido favoráveis, testes mais completos revelaram um sistema lento, com suporte limitado a periféricos e com uma ausência quase total de aplicativos.

A primeira versão do Windows sofria com um processador sem a capacidade necessária, com placas de vídeo extremamente limitada e, o que aqui nos interessa mais, da falta de recursos de hardware para gerenciamento de memória.

Windows 1

Do ponto de vista visual, o Windows 1 tinha uma grande diferença em relação a todas as versões seguintes: não apresentava janelas sobrepostas.

Do ponto de vista de memória, o Windows 1 suportava apenas os até 640K de memória convencional do 8088 e 286. Entretanto, já apresentava uma série de recursos avançados:

• Ao executar múltiplas instâncias de um mesmo programa, era usada um única cópia em memória do código e dos resources.
  

• Grande parte das áreas de memória alocada através do windows podiam ser movidas, para agrupar as áreas livres criando blocos contíguos maiores ou para permitir expandir o tamanho de uma área alocada anteriormente.
  

• Segmentos de código e resources eram normalmente carregados sob demanda, só sendo trazidos para memória quando necessários.
  

• Os segmentos de código e resources eram normalmente descartáveis, podendo ser retirados temporariamente da memória (e posteriormente recarregados a partir do .EXE) para liberar memória.
  

Desta forma, o Windows 1 já era capaz de rodar "simultaneamente" vários programas que ocupavam junto mais memória que a disponível fisicamente. Entretanto, isto requeria acessos frequentes ao disco, com consequente queda de performance.

Windows 2

A principal alteração no Windows 2 foi o suporte a janelas sobrepostas e melhoramentos na parte visual (o que causou uma disputa judicial com a Apple).

Do ponto de vista de memória, a novidade foi a adição de suporte à memória expandida (LIM EMS).

A Microsoft criou também uma versão específica para o 386 (Windows386), que implementava memória expandida na memória extendida e usada o modo 8086 virtual para suportar múltiplas janelas DOS. O Windows e as aplicações continuavam rodando no modo real tanto no 286 como no 386.

Windows 3

A terceira versão finalmente suportou o modo protegido. A mágica foi feita pela iniciativa isolada de um programador, num momento em que a Microsoft estava concentrada no OS/2.

Do ponto de vista visual, o Windows 3 apresentava alguns efeitos simples de "3D".

O Program Manager e o File Manager substituiam o "MS-DOS Executive", fornecendo uma interface mais gráfica para disparar programas e manipular arquivos.

O Windows 3 era capaz de operar em três modos:

• real mode: da mesma forma que o Windows 2, suporta o 8088 e 286/386 com pouca memória. Largamente ignorado por desenvolvedores e usuários e abandonado na versão 3.1.
  

• standard mode: para máquinas com um 286 e 1M de Ram ou mais (ou máquinas com 386 e menos de 2M de Ram), usa o modo protegido do 286.
  

• 386 enhanced mode: além de usar o modo protegido do 286, utiliza dois recursos do 386: paginação (para implementar memória virtual) e o modo 8086 virtual (para suportar múltiplas janelas DOS).

Organização da Memória no Windows 16 bits

A memória gerenciada pelo Windows é chamada de "memória global" ou "global heap" (global no sentido de total) e vai do ponto onde o Windows foi carregado pelo DOS até o fim da memória disponível.

O Windows 16 bits utiliza segmentos de até 64K. Cada bloco alocado da memória global é um segmento. Um programa possui um ou mais segmentos de código e um ou mais segmentos de dados. O Windows cria dois segmentos adicionais para cada um programa, um compartilhado por todas as instâncias e outro único para cada instância. Os resources são também carregados em segmentos.

Normalmente os segmentos são considerados movíveis. No modo real, quando um segmento se move, os ponteiros far (aqueles que incluem segmento e offset) precisam ser ajustados. No modo protegido, o Windows precisa apenas alterar o descritor do segmento e os ponteiros far continuam válidos. Um segmento pode ser marcado como fixo, mas isto irá atrapalhar o gerenciamento de memória, criando "buracos" na memória livre.

Para permitir a movimentação de segmentos no modo real, o Windows utiliza com frequência handles ao invés de endereços. Os handles são índices ou offsets para tabelas que contém o endereço real. Quando um segmento é movido, apenas as tabelas precisam ser atualizadas. Ao alocar memória (usando a rotina GlobalAlloc) um programa recebe um handle. Para acessar a memória, o segmento é temporariamente fixado e convertido em um endereço (usando GlobalLock), o acesso é feito e a memória é desbloqueada (usando GlobalUnlock). Para causar o mínimo impacto ao sistema, a memória deve ficar fixa somente enquanto uma mensagem de janela é tratada.

Uma outra consequência das limitações do modo real, é que um programa só pode conter inicialmente um segmento de dados movível, os demais serão fixos. Isto ocorre porque o Windows não tem como interferir com o código gerado pelo compilador para acessar dados em outros segmentos. Na prática, os programas tinham apenas um segmento de dados e criavam os outros dinamicamente (usando GlobalAlloc).

O resumo de tudo isto é que era muito complicado fazer programas no Windows 1 e 2 (ou no modo real do Windows 3) que precisassem de bastante memória.

No lado do código as coisas eram melhores, com o Windows suportando múltiplos segmentos de forma transparente (porém ao custo de desempenho). Aliás, era uma estratégia frequente quebrar programas em um número absurdo de pequenos segmentos (por exemplo, o programa Write que era incluído no Windows tinha 220K de código distribuído em 83 segmentos de código, todos movíveis e descartáveis e nenhum deles com mais de 10K). Desta forma, o Windows conseguia rodar (ou melhor, engatinhar) mesmo em um 8088 com memória bastante restrita.

A passagem para o modo protegido deixou para trás a maior parte destas preocupações. As poucas que sobraram foram embora com a passagem para os 32 bits, com o Windows NT e o Window 95.