Microsoft Layer for Unicode

The Microsoft Layer for Unicode (MSLU) is a software library for legacy versions of Windows, simplifying the creation of Unicode-aware programs on Windows 9x (Windows 95, Windows 98, and Windows Me). It is also known as UnicoWS (Unicode for Windows 95/98/Me Systems) or by its filename, UNICOWS.DLL.

Microsoft described it as providing "a layer over the Win32 API on Windows 95/98/Me so that a software developer can write a single Unicode version of their application and have it run properly on all platforms."[1] Previously, developers had to either provide two separate versions of an application, or perform complex string translations and API decisions at runtime.

In the present, UnicoWS can be used to compile newer software, which often expects Unicode support, for legacy versions of Windows.[2] UnicoWS can also be used at link time to compile software in languages that did not exist contemporaneously with Windows 9x and require Unicode support, like Rust.[2]

Alternatives exist, among them OPENCOW.DLL, "The Open Layer for Unicode for Windows", a free (MPL 1.1/GPL 2.0/LGPL 2.1 licensed) re-implementation of the MSLU by Mozilla.

Availability

The MSLU was announced in March 2001, and was first made available as a compatibility layer for Unicode-supporting code written for the then-new Windows XP RC1 in the July 2001 edition of Microsoft's Platform SDK. This drew criticism from developers who feel it was "too late", as it was released long past the peak popularity of Windows 9x and only one month before the release to manufacturing of Windows XP.[3] MSLU was given the codename Godot, a reference to Waiting for Godot, a play centered around the failure of a man named "Godot" to arrive and the endless wait for him, because such a Unicode compatibility layer was thought—even inside Microsoft—to have been long overdue.[3]

How it works

Normally, the Windows API provides both A (ANSI escape codes and ASCII characters) and W ("wide" character) versions of most subroutines. On Windows 9x, only the A versions are implemented and attempting to call a W version will fail with an error code that indicates that the function is unimplemented. On the Windows NT line of operating systems, both the A and W versions are implemented (however, the operating system generally only internally implements the W version natively, and the A version is usually a translation thunk to the W version).

By adding the UNICOWS.LIB to the link command-line before KERNEL32.LIB, ADVAPI32.LIB, or any other supported Win32 system link library, the linker will resolve referenced symbols with the ones provided by UNICOWS.LIB instead.

When a wide-character function is called for the first time at runtime, the function stub in UNICOWS.LIB first receives control and checks if it is running on a Windows 95/98/Me system:

• If so, it dynamically loads UNICOWS.DLL (if it hasn't been loaded yet) and passes control to the corresponding thunking stub in there. The thunking stub translates the wide-character arguments into ANSI strings and then invokes the native A version from the OS, and translates any returned strings back into wide character format.
• If the OS natively supports the W version (i.e. the Windows NT line of operating systems), then the function stub updates the in-memory symbol table so that future calls will directly invoke the native W version without any more overhead.

Because of this technique, when an application is linked against MSLU, only Windows 95/98/Me systems will need to rely on UNICOWS.DLL at runtime, and on all other versions of Windows there is only a slight performance penalty the first time a W function is called.

A common problem encountered occurs when some update packages or uninstall programs rename or delete either of the OLE libraries (OLEACC.DLL, OLEDLG.DLL), which are dependencies of UNICOWS.DLL.[4] This results in some applications, such as OpenOffice.org, showing an error with the message "Application cannot start because one of the required libraries cannot be found." This occurs even if UNICOWS.DLL is installed in the system, as it cannot start without its dependencies (see also DLL hell).

References

1. "The Microsoft Layer for Unicode on Windows 95/98/Me Systems". Global Development and Computing Portal. Microsoft. Archived from the original on 16 April 2003. Retrieved 25 April 2019.
2. Duda, Dennis (26 May 2020). "Compiling Rust binaries for Windows 98 SE and more: a journey". seri.tools. Retrieved 23 December 2021.
3. Kaplan, Michael Scott (12 February 2005). "Why/how MSLU came to be, and more". Sorting it All Out. Microsoft Developer Network Blogs. Archived from the original on 4 June 2011. Retrieved 22 December 2021. (Sometimes people ask less charitable versions of the question, like Why did Microsoft wait for so long to make MSLU? or Why did you wait to make MSLU until it was too late? but I'll stick to the nice version of the question!).
4. "Wine: dlls/unicows/Makefile.in". Wine (version 6.0.2). The Wine Project. 26 October 2021. Retrieved 23 December 2021 – via Fossies (The Fresh Open Source Software Archive).

External links

Microsoft

• Official announcement of availability
• MSDN Magazine article describing MSLU
• MSDN programming reference pages
• Michael Kaplan's blog entries about MSLU internals
• Download of MSLU redistributable (UNICOWS.DLL)
• Known bugs in each released MSLU version — formerly maintained by Michael Scott Kaplan, an employee of Microsoft who was the principal developer and maintainer for MSLU. (Kaplan 2005)

Open source alternatives

• libunicows — provides an MIT-licensed version of only the UNICOWS.LIB link-library, but still requires the Microsoft-provided UNICOWS.DLL or Mozilla's OPENCOW.DLL.
• opencow (previously MZLU) — reimplements both the DLL and LIB link-library as MPL 1.1/GPL 2.0/LGPL 2.1, originally for and by Mozilla.