Dave Plummer, engenheiro responsável por implementar o suporte nativo a arquivos compactados no Windows e outras funcionalidades famosas do sistema operacional (SO), detalhou em seu canal no YouTube os princípios de desenvolvimento que guiaram a criação do utilitário de monitoramento de processos.
A versão original da ferramenta, construída por ele, ocupava apenas 80 KB de espaço em disco, uma fração ínfima se comparada aos aproximadamente 4 MB da versão atual do programa.
O contexto do hardware nos anos 1990 e a exigência de resposta imediata
Plummer relatou que a principal restrição durante o desenvolvimento foi a capacidade de processamento dos PCs da época.
O engenheiro afirmou que uma ferramenta criada para recuperar o sistema após falhas graves precisava manter agilidade e responsividade mesmo quando todos os outros componentes do ambiente operacional estivessem congelados.
Cada linha de código adicionada representava um custo computacional notável, e cada alocação de memória deixava marcas permanentes no desempenho geral.
O programador comparou a situação com colegas de quarto que consomem a comida alheia sem contribuir financeiramente.
Por esse motivo, o Gerenciador de Tarefas foi criado sem as camadas de abstração e estruturas preparadas para cenários futuros que faziam parte de muitos aplicativos contemporâneos.
Plummer ironizou a prática atual de iniciar projetos com estruturas robustas, adicionar múltiplos níveis de conforto e antecipação de necessidades, e posteriormente demonstrar surpresa quando o software resultante exige centenas de megabytes para exibir informações básicas.
O mecanismo de verificação de instâncias congeladas
Uma das soluções técnicas que Plummer apontou com maior consideração diz respeito ao comportamento do programa durante a inicialização.
Aplicativos convencionais costumam verificar se outra cópia já está em execução e, caso positivo, simplesmente trazem a janela existente para o primeiro plano.
O Gerenciador de Tarefas executa uma etapa adicional ao enviar uma mensagem privada para a instância já ativa e aguardar uma confirmação de resposta.
Se a mensagem for respondida adequadamente, o programa entende que a cópia anterior permanece operacional e encerra a nova tentativa de abertura.
O silêncio após o envio da comunicação, por outro lado, indica que a instância prévia também está inacessível ou travada, autorizando o lançamento de uma nova janela para auxiliar o usuário a contornar o impasse.
Estratégias de carregamento seletivo e consultas otimizadas ao sistema
O engenheiro adotou ainda a prática de armazenar cadeias de caracteres utilizadas com frequência em variáveis globais, eliminando a necessidade de buscá-las repetidamente da memória ou de arquivos de recurso.
Funcionalidades ativadas com menor frequência eram carregadas apenas mediante solicitação clara do usuário. A construção da árvore de processos também seguiu um princípio de economia de chamadas de Interface de Programação de Aplicações (APIs).
Em vez de consultar cada programa individualmente, o Gerenciador de Tarefas requisitava ao núcleo do sistema a tabela completa de processos de uma só vez.
Caso o espaço reservado para armazenar esses dados se mostrasse insuficiente, o buffer era redimensionado e uma nova tentativa era realizada.
Essa abordagem evitou dezenas de interações desnecessárias com o SO e permitiu que a ferramenta funcionasse tranquilamente mesmo em máquinas com pouca memória disponível e que já enfrentavam instabilidades.
Leia mais
- Microsoft quer acabar com o Painel de Controle do Windows
- Microsoft começa a remover botões do Copilot de apps do Windows 11
- Microsoft tenta simplificar programa Windows Insider e reduz canais para Beta e Experimental
A mentalidade herdada de uma era de escassez computacional
Plummer descreveu o ambiente de criação do utilitário como um período em que uma falta de página na memória virtual era perceptível a olhos nus, e condições de pouca memória livre carregavam uma atmosfera quase física nos escritórios.
Apesar de não manifestar desejo de retornar ao uso daqueles hardwares antigos, Plummer expressou a vontade de que a indústria tivesse preservado parte daquela sensibilidade técnica.
Ou seja: ele queria que tivessem preservado o instinto de agrupar operações, armazenar em cache os dados corretos, descartar processamento visual desnecessário, verificar diferenças antes de atualizar a interface e consultar o núcleo do sistema uma única vez, em vez de repetir a solicitação várias vezes.
O engenheiro concluiu defendendo uma postura de ceticismo diante de conveniências de programação que transferem o encargo do consumo de recursos para o usuário final.
E aí? O que achou da novidade? Compartilhe o seu ponto de vista nesta publicação e continue acompanhando o Adrenaline!
Fonte: Tom’s Hardware
