Anteriores:
< Trilha Zero >

< Escarafunchando a Memória >

Está tudo muito bem, está tudo muito bom: nós já conhecemos os diversos "tipos" de memória e onde podemos carregar programas, residentes e drivers. Mas, uma vez carregados, como saber quanta memória dispomos para um programa? Ou seja: a máquina deu o boot, o Config.Sys e o Autoexec.Bat carregaram um monte de coisas e você agora vai executar uma planilha, editor de textos, banco de dados, sei lá. Será que vai caber na memória que sobrou depois de carregar tantos residentes e drivers? Como saber? Fácil: o próprio DOS 5 traz um utilitário para isto. Chama-se Mem.Exe e "mora" no diretório DOS, que deve estar incluído no comando PATH de seu Autoexec.Bat. Sendo assim, de qualquer diretório basta digitar "mem" para que apareça uma tela como a do exemplo. Agora basta interpretá-la linha a linha. As duas primeiras são redundantes e nos fornecem uma informação conhecida: temos 640K de memória convencional, toda ela à disposição do DOS (em português: "bytes de memória convencional total" e "bytes disponíveis para o MS-DOS"). Achou o número estranho? É porque se esqueceu que cada "K" tem 1024 bytes. Divida por 1024 o número que lá aparece, que dá 640K certinho. Já a terceira linha traz uma informação preciosíssima, justamente a que queremos: quanto sobrou para o programa (em português, "tamanho do maior programa executável"). No exemplo, quase 622K (e isto depois de carregar treze drivers e residentes). Logo aprenderemos como conseguir tal mágica: nossa meta é fazer que em sua máquina esse número mágico se aproxime o mais possível dos 640K. Igualar, impossível: a própria estrutura do DOS exige que uma parte da memória convencional seja usada pelo sistema. Mas repare que, no exemplo, gastou-se apenas 18K para o indispensável. Mas não é só isso que o Mem.Exe nos diz. E o resto freqüentemente é mal interpretado. Como já estamos com a mão na massa, vamos lá. As duas linhas seguintes se referem à memória EMS (em português: "bytes de memória EMS total" e "bytes disponíveis de memória EMS"). Interprete-mo-las. "Memória EMS" nada mais é que a nossa conhecida memória expandida. No exemplo, o primeiro número, 15488K, corresponde ao total de memória expandida. Como se chega a ele? Fácil: o driver de memória expandida (no DOS, o Emm386.Exe) converte toda a memória estendida que "sobrou" depois do boot em expandida. A máquina tem 16Mb de RAM (sorry, periferia). Destes, 640K são memória convencional. Do restante, 256K foram usados pelo próprio gerenciador de memória (parece muito, mas é proporcional à memória total; além do mais, não ocupa memória convencional). Pronto: sobraram 15488K. A linha seguinte corresponde à memória expandida livre, ou seja, o total menos a parcela de memória usada. No caso, 1Mb para cache de disco, 64K da HMA e mais 576K que, confesso, não consegui identificar o dono. Restaram quatro linhas. As três primeiras se referem à memória estendida (em português: "bytes de memória estendida contígua total", "bytes disponíveis de memória estendida contígua" e "bytes disponíveis de memória XMS"). A primeira é de pouca serventia: mostra sempre o total da memória instalada menos o primeiro mega. O que é evidente, já que a memória estendida começa imediatamente após o primeiro mega e vai até o final do total instalado. A segunda, além da pouca utilidade, costuma confundir e assustar os incautos, já que sempre dá zero. Não se preocupe: ela corresponde simplesmente à memória estendida que não obedece ao padrão XMS. Como todo gerenciador moderno de memória estendida segue o padrão, ela dá sempre zero. A terceira, afinal, é a que interessa: é a memória estendida total disponível. No exemplo, 11264K. Que se obtém subtraindo dos 16Mb totais tudo o que foi usado até então, incluindo todo o primeiro Mb, 64K de HMA, 1Mb do cache de disco, 256K que o gerenciador usa para si e tudo o mais que está sendo usado como memória expandida. E aqui cabe uma importante consideração: não some os totais disponíveis de estendida e expandida. Eles correspondem, de fato, à mesma coisa. Como o gerenciamento é dinâmico, se um programa "pede" memória expandida, o driver tira da estendida e transforma em expandida e vice-versa. Pronto, só falta uma linha. Que é importantíssima: informa se o sistema operacional foi carregado na HMA (em português, "MS-DOS residente na área de memória alta"). Se não aparece, ou se em seu lugar surge a mensagem "64kb de área de memória alta disponível" (ou o equivalente em inglês), você está desperdiçando todo um preciosíssimo segmento de 64K da memória convencional. Mas, garanto, só por uma semana. Pois dentro de sete dias você vai aprender como alojar o sistema operacional na HMA. Uma observação final: com um pouco de engenho e arte, o Mem.Exe escarafuncha toda a memória e nos diz não apenas quanto, mas quem e onde. Pois tem três parâmetros, que só podem ser usados um de cada vez. O "/p", de "program", mostra onde cada programa está carregado e quanto ocupa de memória. O "/d", de "debug", exibe toda a área do sistema. E o "/c", de "classify", vai mais fundo que o "/p" e faz uma radiografia tanto da memória convencional quanto dos UMB. Se quiser, experimente-os. Particularmente o último. Ao qual voltaremos ao final da série, depois de aprender a carregar residentes e drivers nos UMB. Pois é ele que vai comprovar, afinal, se conseguimos ou não lograr nosso intento.

B. Piropo