Confidencial de WindowsControl de problemas de compatibilidad

Raymond Chen

EXISTÍA UN PROGRAMA escrito para Windows® 3.1 que buscaba la ventana Panel de control, entraba en el menú Archivo y buscaba un elemento llamado Impresora para abrir el Panel de control de impresoras. En Windows 95, el Panel de control no tenía la opción Impresora en el menú Archivo. Como resultado, al ejecutarse en Windows 95, este programa enviaba un mensaje de comando de elemento no utilizado al Panel de control. Con el fin de solucionar este problema, Windows 95 creó una ventana de Panel de control de señuelo para que el programa la encontrara. Cuando el programa enviaba el mensaje al señuelo, se abría la carpeta Impresoras.

Algunas personas argumentan que Windows 3.1 debería haber detectado que el programa hacía suposiciones incorrectas sobre el Panel de control y mostrar entonces una advertencia. De esa manera, el autor del programa habría visto la advertencia y solucionado el problema antes de lanzar el producto. Pero detectar la intención de una porción de código requiere un nivel de análisis que se aproxima al campo de la inteligencia artificial. Básicamente, Windows 3.1 tendría que haber detectado que el programa usaba strcmp para Impresoras, haber analizado el strcmp en concreto y decidido si era incorrecto. Pero eso sólo detecta el caso de las impresoras. ¿Cuántas comprobaciones de compatibilidad desea que realice el sistema? ¿Y qué hay de los falsos positivos?

Otro argumento es que Windows 95 podría haber respondido a esta suposición incorrecta con un cuadro de diálogo de advertencia que indicara que el programa XYZ estaba realizando una operación incorrecta. Pero para que el Panel de control conociera el origen del mensaje de elemento no utilizado, la detección tendría que colocarse en el administrador de ventanas. Esto crea un acoplamiento frágil entre dos componentes, el Panel de control y el administrador de ventanas. Y, de nuevo, sólo soluciona un caso. ¿Desea que el administrador de ventanas se acople de forma frágil a todos los demás componentes del sistema?

Sería más fácil proporcionar un mensaje genérico, sin nombrar la aplicación específica. Pero ésa tampoco es una buena solución. Un mensaje de error impreciso no es mejor que ningún mensaje de error. Es más, lo más probable es que el usuario haga caso omiso de este cuadro de diálogo, ya que no recomienda una acción específica. Los usuarios percibirían el cuadro de diálogo como una molestia. Éste es un punto muy importante. Es esencial que se proporcionen vías de acción con cualquier mensaje de error. Si el usuario sabe cómo reaccionar ante la advertencia, el cuadro de diálogo es útil.

Otro problema es que un cuadro de diálogo crea un punto de reentrada debido al bucle del cuadro de diálogo. Esto es un problema técnico. La reentrada inesperada es una fuente importante de errores en la programación de IU. Además, el propio Panel de control puede estar en un estado modal y mostrar un cuadro de diálogo provocaría el bloqueo de la estructura modal.

Un cuadro de diálogo también crea una nueva carga de localización. Si se escribe un cuadro de diálogo para todos los problemas de compatibilidad, habrá cientos de ellos repartidos por todo el sistema. Cada uno tendría que traducirse en los 33 idiomas para los que Windows proporciona traducciones completas.

Por último, tenga en cuenta la reacción de la competencia cuando su producto dé como resultado uno de estos cuadros de diálogo. Dirían cosas como: "Microsoft culpa a los demás de los defectos de su sistema operativo" y "Microsoft hace quedar mal a nuestro programa intencionadamente". No exagero. Ha habido compañías que se quejaron al Congreso de que Microsoft estaba centrándose malintencionadamente en su software y desactivándolo. Tras realizar una inspección más a fondo, se encontró que existían errores en sus programas. Sinceramente, es mejor corregir el error por ellos que soportar una larga investigación del Congreso.

Como resultado, las versiones actuales de Windows sólo muestran un cuadro de diálogo de advertencia cuando un programa es tan incompatible con Windows que no se puede ejecutar o que se ejecuta con graves limitaciones. Incluso en este caso, Microsoft intenta siempre colaborar con el proveedor para garantizar que ningún cliente tenga problemas. Después de todo, la gente desea ejecutar programas en los sistemas operativos que compran. Si un programa no funciona, no importa de quién sea la culpa: lo único que le interesa al usuario es hacer su trabajo.

Raymond Chen, The Old New Thing, trata de la historia de Windows y la programación Win32. Actualmente trabaja en un libro, que casualmente también se titula The Old New Thing (Addison-Wesley, 2007).

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.