Por que a tela de logon do Windows 7 ficava parada por 30 segundos ao usar fundo de cor sólida
(devblogs.microsoft.com)- No Windows 7 e no Windows Server 2008 R2, ao usar um papel de parede de cor sólida, a tela Welcome podia permanecer durante o logon por até 30 segundos, e a causa era a ausência de um sinal de pronto
- O sistema de logon só trocava a tela Welcome quando a barra de tarefas, componentes de serviços do sistema, a janela da área de trabalho e a exibição do papel de parede reportavam que estavam prontos, ou quando se passavam 30 segundos
- O código do papel de parede chamava
Report(WallpaperReady)apenas quando havia um fundo bitmap, então em um fundo de cor sólida sem bitmap a condição de espera permanecia incompleta até o fim - A política de grupo “Hide desktop icons” também podia seguir o mesmo padrão: se a chamada
Report(DesktopIconsReady)ficasse presa dentro de uma condicional, o relatório de prontidão dos ícones podia não acontecer - Isso não significava que o logon real sempre ficava 30 segundos mais lento; o fenômeno era que a tela Welcome permanecia até o timeout de 30 segundos, independentemente de o processo de preparação que normalmente terminaria em 5 ou 25 segundos
Por que a tela Welcome demorava a sair com fundo de cor sólida
- Depois que a autenticação de logon termina, o Windows configura o ambiente de desktop do usuário
- criação da barra de tarefas
- carregamento e inicialização de componentes responsáveis por vários serviços do sistema
- criação da janela da área de trabalho e exibição dos ícones
- carregamento do papel de parede na janela de fundo da área de trabalho e desenho na tela
- O sistema de logon espera até que cada componente informe que está pronto
- quando todos os componentes reportam prontidão, ele sai da tela Welcome
- ou sai da tela Welcome quando passam 30 segundos
- O problema com fundo de cor sólida acontecia porque o relatório de prontidão do papel de parede ficava dentro do código de carregamento do bitmap
- se um fundo bitmap estivesse definido, o sistema encontrava o arquivo, carregava na memória, desenhava na tela e então chamava
Report(WallpaperReady) - se não houvesse bitmap, como em um fundo de cor sólida, esse caminho de código não era executado e o relatório
WallpaperReadynão acontecia - o sistema de logon ficava esperando um relatório que nunca viria até atingir o limite de 30 segundos
- se um fundo bitmap estivesse definido, o sistema encontrava o arquivo, carregava na memória, desenhava na tela e então chamava
A mesma falha de sinal de prontidão se repetiu na política de grupo
- A documentação de suporte relacionada diz que também podia haver atraso de 30 segundos ao ativar a política de grupo “Hide desktop icons”
- Políticas de grupo muitas vezes são adicionadas depois sobre código já existente, então é fácil encapsular tudo em uma condicional do tipo “executar se a política permitir”
- o código original de inicialização dos ícones da área de trabalho fazia o bind com a pasta da área de trabalho, enumerava os ícones, adicionava-os à tela e depois chamava
Report(DesktopIconsReady) - ao adicionar suporte à política de grupo, se esse bloco inteiro passasse para dentro da condicional da política, então quando a política de ocultar ícones estivesse ativa o relatório de prontidão também deixaria de ser executado
- o código original de inicialização dos ícones da área de trabalho fazia o bind com a pasta da área de trabalho, enumerava os ícones, adicionava-os à tela e depois chamava
- Isso não quer dizer que o próprio processo de logon passava a levar 30 segundos a mais
- dependendo do desempenho do sistema, o tempo normal para todos os relatórios de prontidão terminarem podia ser de 5 segundos ou 25 segundos
- quando havia o problema, a tela Welcome permanecia até o timeout de 30 segundos independentemente do tempo real de preparação
- Pelo timestamp da documentação, esse problema foi corrigido em novembro de 2009, alguns meses após o lançamento do Windows 7 em julho de 2009
- Um dos motivos para evitar fundos bitmap no passado era que, em ambientes com 4 MB ou 8 MB de memória, gastar cerca de 0,75 MB só com o papel de parede era considerado pesado
1 comentários
Opiniões do Hacker News
Como alguém que prefere fundos de cor sólida, sempre me surpreende como uma preferência tão simples acaba levando a tocas de coelho estranhas
No macOS mais recente, ao tentar definir um fundo sólido personalizado, aparece apenas uma tela branca ofuscante: https://discussions.apple.com/thread/256029958?sortBy=rank
O GNOME removeu toda a UI para configurar fundo de cor sólida, mas tecnicamente ainda é possível se você alterar manualmente várias chaves de configuração, e essas chaves também parecem mudar aleatoriamente a cada versão: https://www.tc3.dev/posts/2021-09-04-gnome-3-solid-color-bac...
No fim, parece um recurso deixado pela metade para uma minoria de usuários, e seria melhor dar suporte adequado a ele ou removê-lo de forma limpa. Eu gostaria de simplesmente inserir valores RGB, mas, no estado atual, acho melhor ter um único sistema de papel de parede bem mantido do que uma lógica instável de cor de fundo
wallpaper type: plain color, dá para defini-lo com um seletor de coresEle também mostra a tela à qual será aplicado e tem uma opção booleana para aplicar a todas as telas de uma vez
Em telas de celulares modernos isso faz sentido até em termos de consumo de energia e também fica visualmente bom, mas algo que deveria ser uma opção padrão ou um botão de um toque nas configurações virou uma tarefa que passa por desconfiança, busca e resignação
No OS X antigo, esse recurso funcionou bem por mais de 20 anos, então parece ter relação com a reescrita do System Preferences
Como atalhos na área de trabalho foram abusados ao longo das gerações, mostrar a área de trabalho virou desperdício de espaço de tela e, mesmo tomando cuidado, ela acaba virando um terreno baldio bagunçado. No Windows isso é especialmente verdadeiro, e acabei me acostumando a simplesmente não usar a área de trabalho para nada e manter janelas sempre abertas em vários monitores
Depois de evitar o mundo Windows nos últimos 25 anos e voltar recentemente por causa de ambientes corporativos, continuo vendo esse padrão nas ferramentas da Microsoft
Por exemplo, por questões de segurança o Teams não carrega, mas as notificações mostram o conteúdo completo das mensagens; ou, na versão em nuvem do Word, a verificação de segurança só entra em ação depois que você digita algumas palavras ou cola o documento inteiro, exigindo a configuração de um rótulo de sensibilidade
Isso parece um sinal de que a arquitetura de software dos web apps da Microsoft é muito ruim, e os apps de desktop também não parecem ser exceção
Depois vinha o pedido de permissão e, se eu recusasse, a prévia desaparecia
Eles funcionam muito bem nos casos de uso óbvios, mas, quando você encontra um caso de borda que não foi coberto, esbarra imediatamente em problemas estranhos. Como os desenvolvedores não têm fama de serem fracos, pode ser por causa da cultura corporativa ou do modo de trabalho, e, com uma base de usuários gigantesca, talvez 80% seja o ótimo do ponto de vista do negócio. Ainda assim, como desenvolvedor externo, acabo evitando produtos da Microsoft sempre que possível
Notebooks que dormiam perfeitamente cinco anos atrás agora viraram zumbis 24 horas por dia, com CPU, ventoinha e disco rígido sempre girando
Tenho certeza de que alguma mudança idiota parecida com a mencionada no texto quebrou uma função que funcionava, e ninguém corrige porque isso poderia atrapalhar a mais nova ideia absurda de fazer um notebook de 10 anos rodar IA enquanto está suspenso para sugerir anúncios com base no que ouviu às escondidas
Isso se conecta a uma prática que deve ter começado naquela época: mostrar uma tela de splash por um tempo determinado e, antes que o software tenha iniciado completamente, mostrar primeiro o ambiente do usuário
Suspeitava-se que tanto sistemas operacionais quanto apps faziam isso para evitar a percepção de que “o app está demorando demais”. Agora é preciso adivinhar se o software realmente carregou antes de usá-lo
Só depois disso você vê uma thread de UI sem resposta, esperando em branco que todo o software subjacente termine de carregar
A avaliação é que uma área de trabalho usável de qualquer forma, ainda que meio quebrada, é melhor do que ficar preso para sempre na tela de carregamento e precisar inicializar outro sistema operacional para consertar
Quando você faz algo, a UI mostra uma roda de carregamento/progresso, mas na prática aquilo fica rodando sem fim; e, ao iniciar uma página web, aparece uma tela vazia com barras de placeholder ou uma imagem borrada em cores. E chamam isso de design responsivo
Às vezes é melhor para o usuário que o sistema trate de forma otimista como se tivesse realmente carregado
Aprendi a usar a configuração padrão em quase tudo
Manter personalizações dá trabalho demais, então o mais fácil é simplesmente não se preocupar com isso. A exceção são umas 50 linhas de configurações do VS Code sincronizadas em algum arquivo misterioso, provavelmente nos servidores do GitHub, mas em nenhum lugar que eu consiga ver
Nos meus computadores pessoais uso stow; em máquinas remotas, copio e colo. Gosto do fato de essas ferramentas serem tão estáveis que continuam ok mesmo ao migrar para o Debian stable
Mesmo restaurando diretamente um backup do Sublime Text de alguns anos atrás, minhas configurações de usuário ainda funcionam
Como lembrete periódico: nix é realmente bom
Dá para dizer: “há um bug, e você pode obter uma VM que o reproduz com
nixos-rebuild build-vm --flake "github:user/repo#test-vm" && ./result/bin/run-*-vm”. O código que cria essa VM também não é um bloco binário que parece um pesadelo de segurança, mas uma expressão nix comum, legível por qualquer pessoa; aplicar em uma máquina nova também se resume a um único comandoSe você entende o que os padrões fazem, muitas vezes é mais trabalhoso sair mexendo em todas as opções do mundo
Acho engraçada a expressão “comida afetiva”. Mesmo depois de sair do AIX para o Linux, ainda uso o motif window manager com desktop steelblue4 e fundo wheat no xterm
Foram os padrões que conheci pela primeira vez na faculdade, em 1989, e desde então sinto que nada melhorou. Coisas como GNOME e KDE me dão enjoo
Um wrapper
if()remendado cujo escopo ficou um pouco amplo demais é um caso clássicoNostalgia é uma droga poderosa
Não estou sendo sarcástico; tenho curiosidade genuína sobre se HiDPI realmente funciona no motif
Muito tempo atrás, quando usava Windows por hobby, editei o valor de uma determinada chave do Registro do Windows para trocar
explorer.exeporcmd.exeCom isso, o Windows não executava o
explorer.exepara abrir a área de trabalho com papel de parede e ícones; em vez disso, ficava um ambiente em que cada janela era um shellcmd.exeda Microsoft sobre um fundo sólido, como em um gerenciador de janelas UNIX. Era aquele clássico retângulo preto do Windows, com barra de título azul e borda cinza fina, e dava para executar aplicativos comotaskmgr.exeemC:\windows\system32pelo prompt de comandoPara mim, parecia muito mais rápido e robusto do que usar o
explorer.exe, e certamente era mais leve. Mais tarde vi, numa foto em um texto de Arthur Whitney, uma cena em que a única janela aberta na área de trabalho do Windows era umcmd.exe; não estou tentando insinuar nada, mas isso sempre ficou na minha memóriaVi isso também recentemente na documentação da Microsoft: https://learn.microsoft.com/en-us/windows/configuration/shel...
Lembro que também havia uma versão barata/gratuita do Windows para IoT ou embarcados que funcionava só com cmd, sem
explorerIsso entra na categoria do que eu chamo de bug sistêmico ou “bug de tipo”
Se tivessem passado um token ao componente de login e feito o destrutor do token marcar automaticamente a conclusão do processo, esse bug teria sido quase impossível de escrever
Em vez disso, como em tempo de execução fizeram com que “os componentes precisem se lembrar disso”, a própria estrutura do código permite o bug
Alguns anos atrás o Facebook teve um bug parecido: o contador de notificações indicava que havia notificações, mas ao clicar não aparecia nada. O caminho de atualização do contador e o caminho de inserção na lista eram diferentes e ficavam dessincronizados; quando mudaram para que a mesma parte do sistema gerenciasse os dois, esse bug desapareceu de vez
Sempre achei que fosse por causa de cache ruim
É um pouco meta, mas passei a esperar títulos no estilo “Why did happen with” anunciando textos do Raymond Chen
São sempre interessantes
É o único blog que desfez superstições de computação relacionadas ao Windows que eu carregava desde criança
Esse código me lembra muitos dos meus bugs favoritos do Kubernetes
if (request.authenticationData) { ok := validate(etc); if (!ok) { return authenticationFailure; } }É como se o mesmo meme atravessasse décadas
Se toda função que precisa de uma determinada permissão receber essa permissão como argumento, por exemplo escrevendo
void doFoo(PermissionToDoFoo permission, ...){...}, e se a chamada só puder acontecer pelo caminho que obtém a permissão a partir dos dados de autenticação,então passa a ser impossível representar o estado inválido de executar Foo sem permissão
Se
authenticationDatanão existisse, era tratado como autenticado por padrão?Fugindo um pouco do tema, eu gostava muito dos papéis de parede do Windows Spotlight que eram atualizados automaticamente na tela de login
Por isso, também usava um script para sincronizá-los como papel de parede da área de trabalho. Mas, no meu Windows 10, isso parou de funcionar sem motivo, então escrevi um script para baixar o Bing Image of the Day: https://blog.est.im/2025/stdout-03