En
2009,
inmediatamente
después
del
lanzamiento
de
Windows
7,
algunos
usuarios
comenzaron
a
notar
un
comportamiento
peculiar
durante
el
proceso
de
inicio
de
sesión…
…si
habían
configurado
un
color
sólido
como
fondo
de
escritorio
en
lugar
de
una
imagen,
el
sistema
mostraba
la
pantalla
de
bienvenida
durante
medio
minuto
extra
antes
de
proceder
cargar
el
escritorio,
incluso
en
equipos
potentes
que
no
deberían
haber
tenido
ningún
problema
de
rendimiento.
Un
comportamiento,
sin
duda,
inusual
y
que
cabreó
bastante
a
los
usuarios
hasta
que
finalmente
fue
solventado
por
Microsoft.
Pero…
¿qué
lo
causaba?
Raymond
Chen,
ingeniero
de
las
antiguas
versiones
de
Windows,
lo
explica
en
su
blog…
no
sin
antes
dejar
claro
que
él, «personalmente»
usa
«un
fondo
de
color
sólido»,
el
histórico
verde
azulado
que «fue
el
valor
predeterminado
en
Windows
95».
En
su
artículo,
Chen
detalla
que
el
medio
minuto
de
tardanza
se
manifestaba
únicamente
bajo
ciertas
condiciones:
-
El
equipo
utilizaba
Windows
7
o
Windows
Server
2008
R2. -
Se
había
configurado
un
color
sólido
como
fondo
de
escritorio. -
El
servicio
Desktop
Window
Manager
Session
Manager
estaba
activado. -
El
usuario
iniciaba
sesión
localmente
(no
por
Escritorio
Remoto).
cuando
MICROSOFT
lanzaba
anuncios
ANTI-GOOGLE
¿Qué
causaba
realmente
el
problema?
Cuando
un
usuario
inicia
sesión,
Windows
no
solo
verifica
sus
credenciales,
sino
que
también
debe
preparar
todo
el
entorno
gráfico:
barra
de
tareas,
iconos,
servicios,
fondo
de
escritorio,
entre
otros.
Una
vez
que
todos
estos
componentes
informan
que
están
listos,
Windows
procede
a
abandonar
la
pantalla
de
bienvenida
y
mostrar
el
escritorio.
El
problema
surgía
cuando
uno
(o
dos)
de
estos
componentes
no
envíaba
su «señal
de
preparado».
En
ese
caso,
el
sistema
esperaba
un
máximo
de
30
segundos
antes
de
continuar
de
todos
modos.
El
bug
en
el
fondo
de
pantalla
En
versiones
iniciales
de
Windows
7,
el
código
responsable
de
establecer
el
fondo
de
escritorio
estaba
diseñado
así:
InitializeWallpaper()
{
if
(wallpaper
bitmap
defined)
{
LoadWallpaperBitmap();
}
}
Y
luego:
LoadWallpaperBitmap()
{
locate
the
bitmap
on
disk;
load
it
into
memory;
paint
it
on
screen;
Report(WallpaperReady);
}
El
problema:
tal
y
como
estaba
escrito
(vinculando
la
señal
de ‘WallpaperReady‘
con
el
proceso ‘LoadWallpaperBitmap‘),
si
no
había
un
archivo
de
imagen
(bitmap)
definido
(como
es
el
caso
cuando
se
usa
un
color
sólido),
el
paso ‘Report(WallpaperReady)‘
nunca
se
ejecutaba.
Como
resultado,
el
sistema
seguía
esperando
una
señal
que
jamás
llegaría.
La
trampa
de
los
iconos
ocultos
Un
segundo
problema
muy
similar
se
daba
cuando
se
habilitaban
políticas
como «Ocultar
todos
los
iconos
del
escritorio».
Como
en
el
caso
anterior,
el
arranque
de
Windows
tenía
un
mecanismo
que
esperaba
una
señal
de ‘estoy
listo,
ya
puedes
seguir
cargando’
por
parte
del
componente
encargado
de
cargar
los
iconos.
Pero
al
poner
la
señal ‘Report(DesktopIconsReady)‘
dentro
de
un
bloque
condicional ‘if
(desktop
icons
allowed
by
policy)‘,
dicha
señal
nunca
llegaba
a
darse
y,
como
resultado,
el
sistema
seguía
esperando
una
confirmación
que
nunca
llegaba…
lo
que
se
traducía
en
otra
espera
innecesaria
de
30
segundos.
¿Cómo
se
arregló?
Microsoft
abordó
el
problema
mediante
una
actualización
publicada
en
noviembre
de
2009.
Esta
solución
corregía
el
error
en
el
código
para
que
enviara
correctamente
la
señal
de
preparación
incluso
cuando
se
usaba
un
color
sólido
como
fondo.
Hasta
ese
momento,
los
usuarios
podían
aplicar
dos
soluciones
provisionales:
-
Usar
una
imagen
como
fondo,
incluso
si
consistía
en
un
bitmap
de
un
solo
color. -
Modificar
el
Registro
de
Windows
para
cambiar
el
valor
de ‘DelayedDesktopSwitchTimeout’,
que
establecía
cuánto
tiempo
espera
Windows
antes
de
forzar
el
cambio
desde
la
pantalla
de
bienvenida,
permitiendo
así
reducir
el
número
de
segundos
de
30
a,
por
ejemplo,
5.
¿Qué
hemos
aprendido
hoy?
Al
final,
lo
que
parecían
ser
meros
detalles
estéticos
—usar
un
fondo
de
color
sólido,
u
ocultar
los
iconos
del
Escritorio—
resultaron
ser
decisiones
con
un
impacto
notable
en
el
rendimiento
de
inicio
de
Windows
7.
Este
incidente
resalta
una
lección
fundamental
en
el
desarrollo
de
software:
el
manejo
de
excepciones
y
casos
atípicos
no
debe
ser
una
ocurrencia
tardía.
En
este
caso,
las
presuposiciones
de
los
programadores
sobre
el
uso
de
configuraciones
poco
convencionales
se
tradujo
en
un
error
de
lógica
por
parte
del
sistema
operativo.
Imagen
|
Marcos
Merino
mediante
IA
En
3DJuegosPC
|
Esta
es
la
historia
de
Windows,
desde
1985
hasta
W11.
Cómo
el
sistema
operativo
de
Microsoft
ha
evolucionado
con
los
años