Segredos do WindowsO poder dos bugs
Raymond Chen
No Windows 95, você acessaria a página Solução de problemas e selecionaria Desabilitar confirmações síncronas de buffer. Mas você sabe o que essa caixa de seleção faria? Ou para que ela serve?
O comportamento normal da função Commit do MS-DOS® era liberar todos os dados não gravados de um determinado arquivo no disco e, em seguida, aguardar até que os dados fossem confirmados como gravados antes de retornar. Com a opção Desabilitar confirmações síncronas de buffer selecionada, a chamada retornaria imediatamente, em vez de aguardar que os dados fossem gravados. É claro que isso era uma violação da especificação funcional, a qual requer que a chamada não retorne até que os dados sejam gravados. Isso aumentou o risco daquilo que o artigo 139669 da Base de Dados de Conhecimento chama eufemisticamente de “problemas de integridade de arquivo”, pois faz com que o programa que emitiu a solicitação de liberação considere que os dados estavam protegidos no disco, quando não estavam.
Um programa de banco de dados pode usar a função Commit para estabelecer pontos nos quais o estado do arquivo no disco seja um acordo com aquilo que o programa espera que esteja no disco. Se o computador ficar sem energia durante uma atualização, o programa de banco de dados pode usar as informações registradas no último ponto de confirmação, a fim de estabelecer novamente a integridade do banco de dados. Se a função Commit for retornada imediatamente depois de ter sido concluída, esse ponto de verificação de integridade seria perdido. O resultado seria que o banco de dados ficaria corrompido.
Por que essa opção foi disponibilizada se as conseqüências são tão horríveis? O motivo: um bug no Windows® 3.11.
Figura 1** Habilitando o comportamento com bugs no Windows Server 2003 **(Clique na imagem para aumentar a exibição)
O Windows 3.11 introduziu o “acesso a arquivos de 32 bits”, o qual era uma implementação de 32 bits da interface de E/S de arquivo de baixo nível. No entanto, a implementação da função Commit continha um bug que efetivamente ignorava as solicitações para liberar buffers de arquivo. Se você utilizasse um programa que liberava seus buffers de arquivo e fosse executado no Windows 3.11, a chamada de liberação não tinha efeito. Conseqüentemente, se você ficasse sem energia justamente no momento errado, o banco de dados era corrompido.
O pessoal trabalhando no sistema de arquivos do Windows 95 solucionou esse bug, mas os novos relatórios começaram a ser filtrados. O programa de contas a pagar de determinado usuário também ficou muito lento. Então, o programa de banco de dados de outro usuário se comportou da mesma forma. O que estava acontecendo?
O que acabou acontecendo foi que esses programas estavam constantemente emitindo chamadas de liberação. Os programadores observaram que as chamadas de liberação eram realmente rápidas no Windows 3.11; assim, eles as distribuíram livremente em seus programas. Gravavam um byte e o liberavam. Gravavam uma cadeia de caracteres e a liberavam. Como as liberações eram muito rápidas, o aplicativo poderia confirmar os dados no disco depois de cada operação sem degradação notável de desempenho. Mas assim que o bug foi corrigido no Windows 95, esses programas começaram a ser executados muito lentamente, pois as chamadas de confirmação estavam, de repente, fazendo o trabalho real.
É claro que se a equipe do sistema de arquivos não tivesse tomado qualquer medida, esses programas continuariam sendo executados lentamente e os usuários chegariam à conclusão de que o Windows 95 era o problema. “O Windows 95 parece uma carroça”, eles diriam uns aos outros. Por outro lado, se o sistema de arquivos retornasse para o comportamento anterior do Windows 3.11, estaria sendo reintroduzido um bug, o qual poderia causar esses irritantes “problemas de integridade de arquivos”.
Portanto, eles concluíram que a solução era deixar o bug corrigido, mas acrescentar uma caixa de seleção – apesar de escondida na página de solução de problemas – a fim de retornar ao comportamento do Windows 3.11. Essa caixa seria destinada aos usuários que durante a execução dos programas encontrassem problemas devido à correção do bug.
O que aconteceu foi que a história acabou se repetindo. No Windows Server® 2003, a equipe de E/S detectou um bug no qual as solicitações marcadas como FUA (Forced Unit Access, acesso forçado à unidade) perderiam essa marca e seriam executadas como E/S normal. Essa foi a versão moderna para ignorar as solicitações de liberação! Eles corrigiram o bug, mas deixaram uma opção para retornar ao comportamento anterior com bugs. A versão do Windows Server 2003 dessa caixa de seleção é chamada de “Ativar desempenho avançado”, mas agora é conhecida como apenas “Restaurar comportamento anterior com bugs”.
Raymond Chen, The Old New Thing, e o livro, de título idêntico (Addison-Wesley, 2007) tratam da história do Windows e da programação Win32. Curiosamente, ele é tão prevenido que não tira nem as etiquetas dos travesseiros.
© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..