- En Windows 7 y Windows Server 2008 R2, al usar un fondo de escritorio de color sólido, la pantalla Welcome podía quedarse durante hasta 30 segundos en el inicio de sesión, y la causa era la ausencia de una señal de listo
- El sistema de inicio de sesión solo cambiaba la pantalla Welcome cuando la barra de tareas, los componentes de servicios del sistema, la ventana del escritorio y la visualización del fondo reportaban que estaban listos, o cuando pasaban 30 segundos
- El código del fondo de pantalla solo llamaba a
Report(WallpaperReady)cuando había un fondo bitmap, así que con un fondo de color sólido sin bitmap la condición de espera se mantenía hasta el final - La directiva de grupo “Hide desktop icons” también podía caer en el mismo patrón si la llamada a
Report(DesktopIconsReady)quedaba metida dentro de una condición, provocando que faltara el reporte de iconos listos - Esto no significaba que el inicio de sesión real siempre tardara 30 segundos más; el fenómeno era que la pantalla Welcome se mantenía hasta el timeout de 30 segundos, sin relación con que el proceso de preparación normalmente hubiera terminado en 5 o 25 segundos
Por qué la pantalla Welcome permanecía demasiado tiempo con un fondo de color sólido
- Cuando termina la autenticación de inicio de sesión, Windows configura el entorno de escritorio del usuario
- Crea la barra de tareas
- Carga e inicializa varios componentes responsables de servicios del sistema
- Crea la ventana del escritorio y muestra los iconos
- En la ventana del fondo del escritorio, carga el fondo de pantalla y lo dibuja en pantalla
- El sistema de inicio de sesión espera hasta que cada componente informe que está listo
- Si todos los componentes reportan que están listos, cambia desde la pantalla Welcome
- O bien, cambia desde la pantalla Welcome cuando pasan 30 segundos
- El problema con el fondo de color sólido ocurría porque el reporte de fondo listo estaba dentro del código de carga del bitmap
- Si había definido un fondo bitmap, buscaba el archivo, lo cargaba en memoria, lo dibujaba en pantalla y luego llamaba a
Report(WallpaperReady) - Si no había bitmap, como en un fondo de color sólido, esa ruta de código no se ejecutaba y no se producía el reporte
WallpaperReady - El sistema de inicio de sesión esperaba un reporte que nunca iba a llegar, hasta alcanzar el límite de 30 segundos
- Si había definido un fondo bitmap, buscaba el archivo, lo cargaba en memoria, lo dibujaba en pantalla y luego llamaba a
La misma omisión de señales de listo se repitió también en la directiva de grupo
- La documentación de soporte relacionada indica que también podía haber una demora de 30 segundos cuando estaba activada la directiva de grupo “Hide desktop icons”
- Como las directivas de grupo muchas veces se agregan después encima del código existente, es fácil envolverlo con condiciones del tipo “ejecutar si la política lo permite”
- El código original de inicialización de iconos del escritorio se enlazaba a la carpeta del escritorio, enumeraba los iconos, los agregaba a la pantalla y luego llamaba a
Report(DesktopIconsReady) - Si al agregar soporte para la directiva de grupo todo ese bloque quedaba dentro de la condición de la política, entonces al activarse la política de ocultar iconos tampoco se ejecutaba el reporte de listo
- El código original de inicialización de iconos del escritorio se enlazaba a la carpeta del escritorio, enumeraba los iconos, los agregaba a la pantalla y luego llamaba a
- Este comportamiento no significa que la tarea de inicio de sesión en sí tardara 30 segundos adicionales
- Según el rendimiento del sistema, el tiempo normal para completar todos los reportes de listo podía ser de 5 segundos o de 25 segundos
- Cuando aparecía el problema, la pantalla Welcome se mantenía hasta el timeout de 30 segundos sin importar el tiempo real de preparación
- Según la marca de tiempo del documento, este problema se corrigió en noviembre de 2009, unos meses después del lanzamiento de Windows 7 en julio de 2009
- Una razón por la que antes se evitaban los fondos bitmap era que, en entornos antiguos con 4 MB u 8 MB de memoria, usar aproximadamente 0.75 MB solo para el fondo de pantalla representaba una carga
1 comentarios
Opiniones en Hacker News
Como alguien que prefiere los fondos de color sólido, siempre me sorprende cómo un gusto tan simple termina tan seguido llevando a madrigueras extrañas
En las versiones recientes de macOS, si intentas configurar un fondo sólido personalizado, solo aparece una pantalla blanca enceguecedora: https://discussions.apple.com/thread/256029958?sortBy=rank
GNOME eliminó toda la UI para configurar fondos de color sólido, pero técnicamente todavía es posible si cambias manualmente varias claves de configuración, y esas claves también parecen cambiar al azar entre versiones: https://www.tc3.dev/posts/2021-09-04-gnome-3-solid-color-bac...
Al final parece una función dejada a medias para una minoría de usuarios, y sería mejor soportarla correctamente o eliminarla limpiamente. Me gustaría simplemente ingresar valores RGB, pero en el estado actual creo que es mejor tener un único sistema de fondos de pantalla bien mantenido que una lógica inestable de colores de fondo
wallpaper type: plain color, puedes definirlo con un selector de colorTambién muestra la pantalla a la que se aplicará, y hay una opción booleana para aplicarlo a todas las pantallas de una vez
En las pantallas de teléfonos modernos tiene sentido incluso en términos de consumo de energía y se ve bien, pero algo que debería ser una opción predeterminada o un interruptor de un toque en la configuración se convirtió en una tarea que pasa por desconfianza, búsqueda y resignación
En OS X antiguo era una función que funcionó bien durante más de 20 años, así que parece estar relacionado con la reescritura de System Preferences
Como los accesos directos del escritorio se han abusado generación tras generación, mostrar el escritorio se volvió un desperdicio de espacio en pantalla, y aunque tengas cuidado termina siendo un páramo desordenado. En Windows es especialmente así, y terminé acostumbrándome a no usar el escritorio para nada y a tener siempre ventanas abiertas en varios monitores
Después de evitar el mundo de Windows durante los últimos 25 años y volver en años recientes a un entorno corporativo, veo este patrón todo el tiempo en las herramientas de Microsoft
Por problemas de seguridad, Teams no carga, pero en las notificaciones aparece todo el contenido del mensaje; o en la versión en la nube de Word, recién después de escribir algunas palabras o pegar un documento completo se ejecuta la revisión de seguridad y te exige configurar una etiqueta de sensibilidad
Parece una señal de que la arquitectura de software de las apps web de Microsoft es muy mala, y las apps de escritorio tampoco parecen ser la excepción
Luego venía la solicitud de permiso, y si la rechazabas, la vista previa desaparecía
Funcionan muy bien en los casos de uso obvios, pero en cuanto te encuentras con un caso límite que no cubrieron, te topas de inmediato con problemas raros. Los desarrolladores no tienen fama de ser poco capaces, así que podría deberse a la cultura corporativa o a la forma de trabajar; y con una base de usuarios enorme, quizá el 80% sea óptimo para el negocio. Aun así, como desarrollador externo, evito los productos de Microsoft siempre que puedo
Laptops que hace 5 años dormían perfectamente ahora se volvieron zombis de 24 horas con CPU, ventiladores y disco duro funcionando todo el tiempo
Estoy convencido de que un cambio estúpido parecido al que menciona el artículo arruinó una función que funcionaba bien, y de que nadie lo arregla porque podría interferir con alguna idea absurda moderna de hacer que una laptop de 10 años ejecute IA mientras duerme para sugerir anuncios basados en lo que escuchó a escondidas
Esto se relaciona con una práctica que probablemente empezó por aquella época: mostrar una pantalla de presentación durante cierto tiempo y luego mostrarle al usuario el entorno antes de que el software haya terminado de iniciarse
Sospecho que tanto los sistemas operativos como las apps lo hicieron para evitar la percepción de que “la app tarda demasiado”. Ahora hay que adivinar si el software realmente cargó antes de usarlo
Solo después de eso ves un hilo de UI que no responde, esperando sin hacer nada a que todo el software subyacente termine de cargar
La idea es que es mejor tener un escritorio que, aunque esté medio roto, al menos se pueda usar, que quedar atrapado para siempre en la pantalla de carga y tener que arrancar otro sistema operativo para arreglarlo
Haces algo y la UI muestra una rueda de carga/progreso, pero en realidad tarda indefinidamente; al iniciar una página web aparece una pantalla vacía con barras de marcador de posición o imágenes borrosas de colores. Y a esto le llaman diseño responsivo
A veces, para el usuario es mejor que el sistema lo maneje de forma optimista y asuma que realmente cargó
Aprendí a usar la configuración predeterminada en casi todos lados
Mantener personalizaciones es demasiado engorroso, así que lo más fácil es simplemente no preocuparse por eso. La excepción son unas 50 líneas de configuración de VS Code sincronizadas en algún archivo misterioso, probablemente en servidores de GitHub, pero no en ningún lugar que yo pueda ver
En computadoras personales uso stow, y en máquinas remotas copio y pego. Me gusta que estas herramientas sean tan estables que incluso al pasarme a Debian stable sigan funcionando bien
Si restauro directamente un respaldo de Sublime Text de hace unos años, mi configuración de usuario todavía funciona
Como recordatorio periódico: nix de verdad es bueno
Puedes decir: “Hay un bug, y puedes obtener una VM para reproducirlo con
nixos-rebuild build-vm --flake "github:user/repo#test-vm" && ./result/bin/run-*-vm”. Además, el código que crea esa VM no es un amasijo binario que parezca una pesadilla de seguridad, sino una expresión nix normal y legible por cualquiera; aplicarlo a una máquina nueva también se resuelve con un solo comandoSi entiendes qué hacen los valores predeterminados, muchas veces es más engorroso tocar todas las opciones del mundo
Me da risa la expresión “comida reconfortante”. Incluso después de pasar de AIX a Linux, sigo usando motif window manager con un escritorio steelblue4 y fondo wheat en xterm
Fueron los valores predeterminados que conocí por primera vez en la universidad en 1989, y siento que nada ha mejorado desde entonces. Cosas como GNOME y KDE me dan náuseas
El wrapper
if()agregado cuyo alcance se amplió un poco de más es un caso clásicoLa nostalgia es una droga poderosa
No lo digo con sarcasmo; de verdad tengo curiosidad por saber si HiDPI funciona realmente en motif
Hace muchísimo tiempo, cuando usaba Windows por hobby, edité el valor de una clave del Registro de Windows para cambiar
explorer.exeporcmd.exeAsí Windows no ejecutaba
explorer.exepara mostrar un escritorio con fondo e íconos, sino que quedaba un entorno parecido a un gestor de ventanas de UNIX, con cada ventana como una shell de Microsoftcmd.exesobre un fondo de un solo color. Era la clásica caja negra de Windows, con barra de título azul y un borde gris delgado, y desde el símbolo del sistema podía ejecutar apps comotaskmgr.exeenC:\windows\system32Para mí se sentía mucho más rápido y sólido que usar
explorer.exe, y definitivamente era más ligero. Más tarde vi en una foto de un artículo de Arthur Whitney un escritorio de Windows donde la única ventana abierta eracmd.exe; no quiero insinuar nada, pero siempre se me quedó grabadoHace poco también vi esto en la documentación de Microsoft: https://learn.microsoft.com/en-us/windows/configuration/shel...
Recuerdo que también había una versión de Windows barata/gratuita para IoT o embebidos que funcionaba solo con cmd, sin
explorerEsto entra en la categoría de lo que yo llamo bugs sistémicos o “bugs de tipos”
Si le hubieran pasado un token al componente de inicio de sesión e hicieran que el destructor del token marcara automáticamente la finalización del proceso, este bug habría sido casi imposible de escribir
En cambio, como en tiempo de ejecución lo dejaron en “los componentes tienen que acordarse de esto”, la propia estructura del código permite el bug
Hace unos años Facebook tuvo un bug parecido: el contador de notificaciones indicaba que había notificaciones, pero al hacer clic no había nada. La ruta que actualizaba el contador y la ruta que insertaba elementos en la lista eran distintas y se desincronizaban; al cambiarlo para que ambas quedaran gestionadas por la misma parte del sistema, ese bug desapareció para siempre
Siempre pensé que era por un mal caching
Es un poco meta, pero ya me acostumbré a esperar títulos estilo “Why did happen with” cuando anuncian un artículo de Raymond Chen
Siempre son interesantes
Es el único blog que resolvió las supersticiones informáticas sobre Windows que tenía desde niño
Ese código me recuerda mucho a mi bug favorito de Kubernetes
if (request.authenticationData) { ok := validate(etc); if (!ok) { return authenticationFailure; } }Es como si el mismo meme siguiera atravesando décadas
Si haces que todas las funciones que requieren algún permiso reciban ese permiso como argumento, por ejemplo escribiendo
void doFoo(PermissionToDoFoo permission, ...){...}, puedes hacer que la llamada solo sea posible a través de la ruta que obtiene el permiso a partir de los datos de autenticaciónAsí se vuelve imposible siquiera representar el estado incorrecto de realizar Foo sin permiso
¿Se trataba de que, si no había
authenticationData, básicamente se trataba como autenticado?Se sale un poco del tema, pero me encantaba el fondo de Windows Spotlight que se actualizaba automáticamente en la pantalla de inicio de sesión.
Por eso también usé un script para sincronizarlo como fondo de escritorio. Pero en mi Windows 10 dejó de funcionar sin razón aparente, así que en su lugar escribí un script que descarga la Bing Image of the Day: https://blog.est.im/2025/stdout-03