Você liga o micro e aquele monte de metal e plástico até então inerme
entra em frenética atividade. Os mostradores luminosos do gabinete
se acendem, estranhos ruídos são emitidos, piscam os leds dos drives
e do teclado, em suma: até que a máquina se ponha docilmente à disposição
do primeiro comando, ocorre uma febril atividade. Mas tudo o que
sabemos até agora de informática nos garante que o micro, por si
mesmo, não faz absolutamente coisa alguma: só o que a CPU sabe fazer
é executar instruções lidas na memória e é preciso que essas instruções,
ou programa, sejam carregadas na memória. Mas o micro faz tudo aquilo
imediatamente após ser ligado, sem que se tenha carregado programa
algum. Que diabo estaria acontecendo?
Bem,
toda aquela atividade tem o nome de “boot”. Que, traduzido do inglês,
significa “bota”, ou “botina”. O que não faz o menor sentido, a
menos que se conheça o ditado “rising oneself pulling up the bootstraps”,
usado quando alguém quer fazer sozinho algo que necessariamente
requer alguma ajuda, como levantar-se no ar puxando para cima o
cordão das próprias botas. Porque é mais ou menos isso que a máquina
faz quando é ligada: com seus próprios recursos, sem ajuda externa,
carrega o mais importante dos programas, aquele que a partir de
então irá controlar toda a máquina: o sistema operacional. Se você
levar em conta que, para uma máquina sem sistema operacional, a
palavra “arquivo” não faz o menor sentido (pois somente o sistema
operacional “entende” o conceito de arquivos), vai perceber que
o que ocorre é na verdade um pequeno milagre, exatamente como se
alguém tivesse levantado a si mesmo puxando para cima os cordões
das botinas. Por isso o processo de partida inicialmente tomou o
nome de “bootstrap”, que depois foi simplificado para boot.
Examinar
detalhadamente o que acontece durante o boot pode ser um exercício
interessante, mas implicaria em uma digressão que se estenderia
por semanas. Por isso vamos sintetizá-lo em duas ações: a máquina
testa-se a si mesma (por isso aciona todos os periféricos, o que
explica tanto piscar de leds) e carrega o sistema operacional. A
primeira ação é interessantíssima (chama-se POST, de Power On Self
Test, ou auto-teste de partida), mas no momento pouco nos interessa.
Já a segunda, o mistério da carga do sistema operacional a partir
do nada, é justamente o fulcro de nossa discussão de hoje: como
pode a máquina ler no disco os arquivos do sistema operacional para
carregá-los na memória, se ainda não carregou (evidentemente...)
o próprio sistema operacional, o único ente capaz de “entender”
o conceito de arquivos?
Uma
solução possível seria gravar o sistema operacional em chips de
memória ROM. Para entender como isso poderia funcionar, precisamos
definir o que vem a ser memória ROM. Pois não há mistério: ROM vem
de “Read Only Memory”, ou memória apenas para leitura. Um tipo de
memória que, como a nossa conhecida memória RAM, pode armazenar
bytes (e, portanto, guardar um programa). Mas que, diferentemente
da RAM, não pode ter seu conteúdo alterado. Em contrapartida, é
perene e não perde as informações que armazena quando a máquina
é desligada.
É
justamente essa última propriedade que poderia resolver nosso problema:
se armazenássemos em chips de memória ROM um programa cuja instrução
inicial esteja em um endereço conhecido, para o qual o ponteiro
de instruções da CPU “aponta” no momento em que ela é energizada,
esse programa seria executado automaticamente assim que a máquina
fosse ligada. Uma solução perfeita para o sistema operacional, não
fosse por dois detalhes pequenos mas relevantes: a memória ROM exige
longos tempos de acesso (ler bytes sucessivos em ROM leva um tempo
mais longo que em RAM, o que faz com que programas armazenados em
ROM sejam de execução muito lenta) e, como sabemos, a memória ROM
não pode ser alterada. Ora, o sistema operacional é executado o
tempo todo, mesmo quando outros programas estão “rodando”, e por
isso não pode ser lento. E precisa ser freqüentemente atualizado
(por isso tantas “versões” dos sistemas operacionais mais populares).
Se gravado em chips de memória ROM, para atualizar a versão seria
necessário trocar os chips. Por essas razões, embora alguns micros
portáteis usem o sistema operacional gravado em ROM, essa é a exceção,
não a regra. Portanto, a memória ROM não resolve nosso problema:
o sistema operacional deve ser carregado na memória RAM (mais rápida)
e lido do disco (para permitir mudar de versão meramente atualizando
arquivos).
Mas
nada impede que o programa que executa o POST seja gravado em ROM:
afinal, ele é executado uma única vez a cada partida e por isso
não é tão importante que seja rápido. E nem precisa ser atualizado
com tanta freqüência, pois os dispositivos que são testados não
mudam a toda hora. Pois ele é, de fato, gravado em ROM. Por isso
a máquina parte tão serelepe para executar o POST assim que ligada.
Portanto,
há um programa gravado em ROM que é executado automaticamente tão
logo o micro é ligado. Então, já que é assim, por que não incorporar
a ele as rotinas necessárias para ler do disco os arquivos do sistema
operacional? Bem, o problema é que o programa não “sabe” o que é
um arquivo. Infelizmente só quem “sabe” dessas coisas é o sistema
operacional, e o programa roda antes que ele seja carrregado. Portanto,
o programa não pode encontrar um arquivo no disco. A não ser que...
Mas
claro! Tinha que haver uma solução. E tinha que ser evidente...
Nessa
altura dos acontecimentos tenho certeza que você já atinou com ela.
Por isso nem vai ficar impaciente esperando a semana que vem para
encontrá-la aqui...
B.
Piropo
