Escritos
B. Piropo
Anteriores:
< Trilha Zero >
Volte de onde veio
15/02/1993

< Usando os UMB >


Se você tem acompanhado esta série, sua máquina já está pronta para receber residentes e drivers nos UMB. Agora só falta carregá-los lá. Prepare-se para ter trabalho, já que a coisa será feita de forma um tanto artesanal, na base da tentativa e erro. Mas fique certo que o esforço vale a pena.

Primeiro, vamos examinar os comandos necessários. Já sabemos que, para carregar um controlador de dispositivo na memória convencional, usamos o comando "device" seguido da especificação completa do arquivo. Pois para carregá-lo nos UMB basta substituir "device" por "devicehigh". O resto é igual. Se o driver exigir, parâmetros podem ser incluídos exatamente como no comando "device". Por exemplo: se você usa um disco RAM de 512K na memória estendida e quer carregar seu driver nos UMB, inclua no Config.Sys a linha:

devicehigh=ramdrive.sys 512 /e

Já os residentes em geral carregam-se por meio de linhas do Autoexec.Bat com a especificação do arquivo seguida, eventualmente, de parâmetros. Para carregá-los nos UMB há duas formas: a primeira, mais simples, consiste em preceder a especificação do arquivo pelo comando "loadhigh", que pode ser abreviado para "lh". Um exemplo: para carregar nos UMB o utilitário do DOS doskey usando um buffer de 1k, inclua em seu Autoexec.Bat a linha:

loadhigh doskey /bufsize=1024

ou, abreviadamente:

lh doskey /bufsize=1024

A outra forma é mais complicada, mas economiza mais algumas centenas de bytes da memória convencional. Consiste em carregar residentes mediante o comando "install" no Config.Sys (e não no Autoexec.Bat, como seria de se esperar). O mesmo doskey seria carregado nos UMB mediante a inclusão, no Config.Sys, da linha:

install=doskey /bufsize=1024

A maior economia de memória se deve ao fato de que, carregado do Config.Sys, o programa não cria uma cópia do "ambiente", como o faria se fosse carregado do Autoexec.Bat. Em contrapartida, não pode usar variáveis ambientais. Nem depender do Command.Com para manejar erros eventuais. Eu raramente recorro ao "install", preferindo sempre o "loadhigh". Afinal, gerenciar memória já é bastante delicado para incluir complicações adicionais. Sugiro que vocês façam o mesmo. (Uma observação: para simplificar, considerei que os arquivos usados nos exemplos estavam no diretório raiz do disco de boot. Se, em sua máquina, Doskey.Com e Ramdrive.Sys estiverem em outro diretório, o disco e a via do diretório devem ser incluídos antes do nome do arquivo.)

Agora, uma advertência: não espalhe devicehighs e lhs em seus Config e Autoexec só porque já aprendeu a usá-los. Vá com calma.

Primeiro, nunca carregue um residente ou driver nos UMB sem testá-lo antes na memória convencional. Conflitos de endereços, interrupções e mais o que a enorme criatividade das bruxas que se escondem nas entranhas de nossas máquinas conseguem inventar, já são bastante comuns sem as complicações que a transferência para os UMB podem acarretar. Portanto, melhor resolver todos os possíveis conflitos antes de tentar usar os UMB. Na verdade o ideal é, antes de começar a mexer nos UMB, verificar se todos os residentes e drivers que se pretende carregar ali funcionam bem, juntos, na memória convencional. Um residente ou driver pode rodar sem maiores percalços meses a fio e somente apresentar problemas depois que se instala um novo freguês que, aparentemente, nada tem a ver com ele. Então, antes de começar a usar os UMB, instale seus programas, carregue todos os drivers e residentes na memória convencional e verifique se tudo vai bem (não se contente com o prompt após o boot: rode os programas que utiliza com maior freqüência. Particularmente se usa Windows). Assim, com todos previamente instalados lá em baixo, ficará mais fácil modificar as linhas do Config.Sys e Autoexec.Bat quanto os testarmos nos UMB.

Depois: jamais se atreva a mexer na memória sem um disco de boot ao alcance da mão. Tenha em mente que você está prestes a alterar as bases do funcionamento de sua máquina. Tudo bem: não precisa ter medo. Qualquer mudança indevida pode perfeitamente ser desfeita sem maiores prejuízos. Desde que você possa dar um boot do drive A caso algo dê errado. E há uma enorme probabilidade de ter que fazê-lo pelo menos uma vez durante o doloroso processo de tentativa e erro. Senão, não seria "tentativa e erro", pois não?

E mais: assegure-se que dispõe de um editor de texto ASCII puro que possa ser carregado de um disquete. A razão é evidente: se algo der errado e a máquina não conseguir dar o boot após ter carregado algo nos UMB, certamente o causador do desastre é o indigitado driver ou residente, que teve vertigem das alturas. Nesse caso, será imprescindível alterar o Autoexec.Bat ou o Config.Sys para remover o freguês mal comportado. E mais: teste o disco de boot e o editor. A pior hora para descobrir que um disco de boot não dá boot é quando se está com a máquina "pendurada" depois de alguma mudança mal sucedida no Autoexec ou no Config.

Feitas estas advertências, vamos começar a discutir um método (razoavelmente) seguro de determinar quem pode ou não subir para os UMB sem sentir vertigens. Semana que vem, naturalmente.

B. Piropo