Anteriores:
< Trilha Zero >

< Minhas Memórias >
< Parte VII: Garimpando Bytes >

 

Continuando nossa exploração dos esconsos desvãos da memória, vamos estabelecer alguns pontos básicos. Ficou claro que no endereço 1Mb há uma marca indelével. Então vamos combinar o seguinte: chamemos de "memória estendida" a tudo que se situa daí para cima. E, a tudo que estiver abaixo, de "memória convencional". Que, por sua vez, se divide em duas partes: a que o DOS destinou a programas, que vai de zero a 640K, e a situada desde aí até 1Mb, que o DOS reservou para si. À primeira, chamaremos de "memória para programas". E à última, de "memória reservada".

Tudo entendido? Ficou fácil? Bom. Então compliquemos um pouco e vejamos como programas podem se intrometer onde não foram chamados. Pois os 640K a eles destinados ficaram pequenos e foi preciso garimpar preciosos bytes seja lá onde eles pudessem ser achados. Vimos um exemplo disso ao discutir memória de vídeo: em máquinas com placas CGA, pode-se roubar até 64K da memória reservada, ampliando o limite da memória de programas para 704K.

Hoje veremos mais duas dessas mágicas. A primeira exige uma CPU 286, no mínimo, para resgatar um segmento inteiro e fazer uma interessante prestidigitação para "enganar" o DOS. Vamos ver como.

Já reparou nos odômetros dos automóveis? Em geral têm cinco algarismos que vão registrando o número de km percorridos. E quando chegam aos 100 mil, não podendo registrá-los, voltam ao zero.

Pois algo parecido ocorre com as máquinas com CPU 8088. Se um programa tenta chegar ao endereço 1Mb, há um "estouro" ("overflow") de memória e o ponteiro retorna a zero (antes que os escovadores de bits protestem: isso é uma simplificação. Na verdade, o gerenciamento de memória segmentado usado nos PC torna as coisas um pouco diferentes). E, sabemos todos, essas CPU têm vinte linhas para endereçamento, que nominalmente vão de A0 até A19 (com esse "A" simbolizando "Adress", de endereço).

As CPU 286 ou superiores têm mais de vinte linhas de endereços. E o que acontece com o estouro? Bem, já que há mais de vinte linhas, ele tende a ser manejado pela vigésima primeira, que se chama A20. Se ao DOS fosse dado enxergar acima de 1Mb, não haveria problema. Mas não é. Solução? Enganar ao DOS, apontando o registrador de segmentos exatamente para 1Mb e desenvolver um driver, ou gerenciador de memória, para a vigésima primeira linha de endereços. Voilá: o DOS pula, afinal, o muro do 1Mb. É pena que a segmentação de memória em blocos de 64K não o deixe ir muito longe. Mas pode-se ganhar um segmento inteiro, valiosos 64K, imediatamente acima de 1Mb.

Mas não tínhamos dito que acima de 1Mb fica a memória estendida, terreno vedado ao DOS? Sim, de fato. Mas aqui surge a primeira exceção. De apenas um segmento, e um caso tão particular que esse segmento, quando usado para esse fim, tem um nome especial: HMA, de "High Memory Area". Que iremos traduzir literalmente e chamar, a partir de agora, de "Área de Memória Alta".

Como esse segmento pode ser usado? Bem, há algumas restrições. Mas você não precisa se preocupar com detalhes: o sistema maneja toda a tralha de forma absolutamente transparente, desde que o driver da HMA seja instalado. E os programas que usam a HMA fazem essa instalação, modificando automaticamente seu CONFIG.SYS. A única pista é um aviso misterioso mencionando um "HMA driver" ou "A20 handler" que surge na tela ao se ligar a máquina. Essa é, sem dúvida, uma das melhores e mais indolores formas de se ganhar mais 64K de memória. E altamente recomendável. Que programas são capazes de fazê-lo? Alguns poucos. Mas, atualmente, a escolha me parece evidente: nenhum candidato é mais indicado para ocupar a HMA que o próprio sistema operacional. E dois deles são capazes disso: as versões 5.0 do MS DOS, da Microsoft, e as versões 5.0 e 6.0 do DR DOS, da Digital Research. Se você tem um AT, corra para eles.

Vamos procurar mais memória. Pensem um pouco: onde existem largos blocos de memória não usada? Lembram-se de toda aquela área que o DOS gulosamente reservou só para si e desfrutou tão pouco? Onde, dos seis segmentos disponíveis, geralmente menos de três são ocupados pelo sistema? Pois lá está a mina de bytes que procurávamos. Pena que para nela penetrar precisamos de portar, no mínimo, um 386. E um bom gerenciador de memória estendida.

Com esse armamento pesado podemos, despudoradamente, nos apossar dos terrenos baldios que o perdulário DOS reservou e não usou. E, como numa guerra de guerrilhas, localizar e ocupar desguarnecidos blocos de memória livres. Como sempre, em casos assim, correndo perigo: se ocuparmos um inocente bloco vazio mas para o qual o sistema reservou uma utilidade futura, podemos nos preparar para um inevitável "crash". Mas o butim é precioso, e vale o risco.

Como batizaram a esses espaços invadidos? Dessa vez, lamentavelmente, o nome não me pareceu bem escolhido: UMB, de "Upper Memory Blocks", que vamos traduzir ao pé da letra para Blocos de Memória Superior. Um pouco confuso, eu sei, mas que fazer...

Quais são os locatários ideais dos UMB? Bem, como o terreno é grande, mas não contíguo, temos que procurar diversos inquilinos que não exijam grandes espaços. E os candidatos naturais são todos aqueles residentes e drivers que recheiam nossos Config.Sys e Autoexec.Bat. Cada um deles comendo um pouquinho de memória, mas todos juntos exibindo uma notável voracidade.

Como enfiá-los nos UMB? Bem, você vai precisar de um 386 ou 486 e de um gerenciador de memória estendida. Ambos os sistemas operacionais citados trazem o seu: MS-DOS tem o EMM386.EXE e o DR-DOS traz o EMM386.SYS. Mas, nesses casos, eu recomendo um gerenciador de memória especialmente desenvolvido para isso, como o QEMM386 da Quarterdeck ou o 386Max, da Qualitas. Que além de serem compatíveis com as novas versões do DOS, trazem primorosos utilitários que analisam sua configuração de memória e decidem para você que residentes e drivers devem ser carregados aonde. Uma beleza.

Qual o resultado disso tudo? Bem, quando eu usava DOS em um 386, recorria aos inestimáveis serviços do QEMM386. Meu Config.Sys e Autoexec.Bat estavam recheados com onze residentes e drivers. E após carregar o sistema, drivers e residentes, ainda me sobravam perto de 630 mil bytes para programas. Se você tem um 386 ou superior, ainda não passou para um sistema operacional decente, de 32 bits, e ainda usa o DOS, rode o comando CHKDSK em sua máquina, compare e veja se não vale a pena...

B. Piropo