Sítio do Piropo

Micro Cosmo

< Sequência de Boot >

Antes de seguir adiante examinando o processo de bot propriamente dito, vamos abordar um ponto interessante e importante: a seqüência de boot, ou a ordem em que os drives são inspecionados pelo bootstrap em busca do disco de boot.

Como sabemos - e por mais estranho que isso possa parecer nos dias de hoje - o PC não foi concebido para abrigar um disco rígido. Sua concepção previa apenas um drive de disquete, e mesmo assim como opcional (a IBM esperava que o meio de armazenamento de massa mais usado no PC fosse a fita cassete).

Sendo o drive opcional, as máquinas eram fornecidas sem ele. Portanto, ao serem ligadas, não davam boot (não se esqueça que boot é o nome que se dá à carga do sistema operacional). Como vimos semana passada, quando a rotina de inicialização do bootstrap não encontrava drive algum, simplesmente passava o controle para o interpretador Basic gravado em ROM. Nos dias de hoje o fato de um micro pessoal trazer gravada em ROM uma linguagem de programação nem ao menos faz sentido. Como sabemos todos, programas não são feitos por usuários mas por profissionais altamente especializados. Porém convém lembrar um fato do qual hoje em dia pouca gente se dá conta, por mais evidente que seja: quando o primeiro PC foi lançado ainda não havia programas para PC! Portanto, meu caro Watson, quem os quisesse havia de fazê-los. Por isso, naqueles bravos tempos que a Cora chama de era do byte lascado, cada micreiro era um programador. E programava em Basic, naturalmente.

Quanto ao sistema operacional, ele somente seria carregado se o drive existisse e abrigasse um disco de boot (portanto não é de estranhar que o DOS, concebido nos tempos do PC, tenha este nome - que a gente sempre esquece, mas quer dizer “sistema operacional de disco”). Caso contrário, mesmo constatando a presença do drive, o controle ainda era passado para o interpretador Basic. Que sabia perfeitamente lidar com drives e discos. O que, depois de muito matutar, me levou a perguntar ao meu professor de Basic da época para que diabos servia aquele tal sistema operacional, já que o interpretador Basic era capaz de fazer tudo o que ele fazia. Questão de tal forma transcendental que nem mesmo o professor conhecia a resposta. Ah, como eram ao mesmo tempo heróicos e ingênuos aqueles dias saudosos que não voltam mais...

As máquinas sem disco rígido só davam boot a partir de um disquete (o então famoso “disquete de boot”, ou “de sistema”, que tinha a curiosa característica de se enfiar nos locais mais recônditos e se refugiar nos recantos mais escusos da sala, desaparecendo sempre que se precisava dele - ou seja, o tempo todo). Mas o boot a partir de um disco rígido era infinitamente mais rápido e mais prático. Por isso a primeira atitude do feliz - e, naqueles tempos, rico - usuário que tinha a ventura de agregar um disco rígido à sua máquina era instalar nele o sistema operacional, transformando-o em seu disco de boot. Daí pra frente, boot de disquete nunca mais.

Mas se é assim, então porque durante tantos anos, mesmo depois que discos rígidos passaram a ser equipamento padrão e obrigatório nos PC, a procura pelo disco de boot continuou a ser feita sempre primeiro no drive de disquete e somente depois no disco rígido? Porque aquela irritante perda de tempo esperando o bootstrap investigar se há um disco de boot no drive A para só então tentar o boot pelo disco rígido? Porque apenas as máquinas mais modernas permitiram alterar esta seqüência através do ajuste inicial conhecido por “setup” (e que algum dia examinaremos)? E porque mesmo estas oferecem como opção preferencial a busca primeiro no drive A e depois no C?

Ora, meu amigo, pense um pouco que a resposta é evidente. Pois discos, sejam eles rígidos ou flexíveis, são dispositivos delicados e sujeitos a falhas. Quantas vezes já lhe aconteceu tentar ler um arquivo em disco e receber de volta uma mensagem de erro informando que o arquivo se corrompeu por uma razão qualquer?

Pois bem: depois de identificado o disco de boot e iniciado o procedimento de carga do sistema operacional a partir dele, não há como interromper o processo e reiniciá-lo a partir de outro drive. Neste caso, se for constatado que um arquivo imprescindível para a carga do sistema operacional corrompeu-se, o processo de boot é brusca e irremediavelmente interrompido. Na melhor das hipóteses, com uma mensagem de erro informando do infausto acontecimento. Na pior, com a máquina travada.

Em uma situação como esta, se o boot está sendo dado de um disquete, basta removê-lo do drive e substitui-lo por outro disco de boot em boas condições. Se o dano foi somente em um arquivo, depois do boot com o disco bom até mesmo os demais arquivos do disco de boot defeituoso podem ser acessados.

Agora: se a busca pelo disco de boot fosse feita primeiro no disco rígido e só depois no disquete e esta seqüência não pudesse ser alterada, como dar o boot em um micro no qual tivesse se corrompido um arquivo do disco rígido que fosse imprescindível para carregar o sistema operacional?

B. Piropo