Microsoft Layer for Unicode ( MSLU ) es una biblioteca de software para versiones anteriores de Windows que simplifica la creación de programas compatibles con Unicode en Windows 9x ( Windows 95 , Windows 98 y Windows Me ). También se conoce como UnicoWS ( Unicode for Windows 95/98/Me Systems ) o por su nombre de archivo , UNICOWS.DLL .
Microsoft lo describió como proporcionar "una capa sobre la API Win32 en Windows 95/98/Me para que un desarrollador de software pueda escribir una única versión Unicode de su aplicación y hacer que funcione correctamente en todas las plataformas". [1] Anteriormente, los desarrolladores tenían que proporcionar dos versiones separadas de una aplicación o realizar traducciones de cadenas complejas y decisiones de API en tiempo de ejecución.
En la actualidad, UnicoWS se puede utilizar para compilar software más nuevo, que a menudo espera compatibilidad con Unicode, para versiones anteriores de Windows. [2] UnicoWS también se puede utilizar en el momento del enlace para compilar software en lenguajes que no existían contemporáneamente con Windows 9x y requieren compatibilidad con Unicode, como Rust . [2]
Existen alternativas, entre ellas OPENCOW.DLL , "La capa abierta para Unicode para Windows", una reimplementación gratuita ( licencia MPL 1.1/ GPL 2.0/ LGPL 2.1) de MSLU por Mozilla .
La MSLU se anunció en marzo de 2001 y se puso a disposición por primera vez como una capa de compatibilidad para el código compatible con Unicode escrito para el entonces nuevo Windows XP RC1 en la edición de julio de 2001 del SDK de la plataforma de Microsoft . Esto provocó críticas de los desarrolladores que sentían que era " demasiado tarde ", ya que se lanzó mucho después de la popularidad máxima de Windows 9x y solo un mes antes del lanzamiento a fabricación de Windows XP. [3] MSLU recibió el nombre en clave Godot , una referencia a Esperando a Godot , una obra centrada en el fracaso de un hombre llamado "Godot" en llegar y la interminable espera por él, porque se pensaba, incluso dentro de Microsoft, que una capa de compatibilidad Unicode de este tipo era necesaria desde hacía mucho tiempo. [3]
Normalmente, la API de Windows proporciona versiones A( códigos de escape ANSI y caracteres ASCII ) y W( caracteres "anchos" ) de la mayoría de las subrutinas . En Windows 9x, solo Ase implementan las versiones y el intento de llamar a una Wversión fallará con un código de error que indica que la función no está implementada. En la línea de sistemas operativos Windows NTA , se implementan tanto las versiones como Wlas (sin embargo, el sistema operativo generalmente solo implementa internamente la Wversión de forma nativa, y la Aversión suele ser un thunk de traducción a la Wversión).
Al agregar UNICOWS.LIB a la línea de comandos de enlace antes de KERNEL32.LIB , ADVAPI32.LIB o cualquier otra biblioteca de enlace del sistema Win32 compatible, el enlazador resolverá los símbolos referenciados con los proporcionados por UNICOWS.LIB .
Cuando se llama a una función de caracteres anchos por primera vez en tiempo de ejecución, el stub de la función en UNICOWS.LIB primero recibe el control y verifica si se está ejecutando en un sistema Windows 95/98/Me:
AW en memoria para que las futuras llamadas invoquen directamente la versión nativa sin más sobrecarga.WGracias a esta técnica, cuando una aplicación se vincula con MSLU, solo los sistemas Windows 95/98/Me necesitarán confiar en UNICOWS.DLL en tiempo de ejecución, y en todas las demás versiones de Windows solo hay una ligera penalización en el rendimiento la primera vez que se llama a una función.W
Un problema común que se encuentra ocurre cuando algunos paquetes de actualización o programas de desinstalación renombran o eliminan cualquiera de las bibliotecas OLE ( OLEACC.DLL , OLEDLG.DLL ), que son dependencias de UNICOWS.DLL . [4] Esto da como resultado que algunas aplicaciones, como OpenOffice.org , muestren un error con el mensaje "La aplicación no puede iniciarse porque no se puede encontrar una de las bibliotecas requeridas". Esto ocurre incluso si UNICOWS.DLL está instalado en el sistema, ya que no puede iniciarse sin sus dependencias (consulte también DLL hell ).
(A veces, la gente hace versiones menos caritativas de la pregunta, como ¿Por qué Microsoft esperó tanto tiempo para crear MSLU? o ¿Por qué esperaron para crear MSLU hasta que fue demasiado tarde? ¡Pero me quedaré con la versión amable de la pregunta!).