The Microsoft
Layer for Unicode is a library that adds support to programs compiled
to use the Unicode versions of certain API
functions so they can run unmodified on systems that do not otherwise
support Unicode, such as Windows 95, Windows 98, and Windows ME. For
instance, Windows 95 does not support CreateFileW, so if you call it in your
program, it won’t work on that operating system. If you use MSLU, then it will handle the call by forwarding it
to the non-Unicode CreateFileA function. For the most part,
MSLU doesn’t provide any additional
functionality to programs on Windows 95; what it does is allow you to use
Unicode functions on Windows NT and still be able to run the same program
on Windows 95 without any reduced functionality.
MSLU comes as two files, a DLL and a lib. The lib file is only for use with C and C++, but it adds a significant feature, the MSLU loader. The loader makes it possible to distribute the DLL to only the versions of Windows that need it.
You can read more about MSLU and the loader in an article in the October 2001 issue of MSDN Magazine.
MSLU in Delphi
I have written a pair of units to allow Delphi programs to take advantage of MSLU.
The first unit is MSLUDirect, which is simply a DLL import unit with declarations for all the
functions exported by Unicows.dll. The
functions in that unit are Unicode-aware functions with behavior that
varies depending on what version of Windows they run on. A program that
calls functions from MSLUDirect must have Unicows.dll present to run. If the DLL is not present, then the operating system will
refuse to load the program at all.
The other unit is MSLU, and it aims to mimic the effect
of the MSLU loader. It allows a program to make
calls to Unicode API functions on Windows
versions that do not support Unicode. It works by patching a
module’s import tables when the program starts up so that instead
of calling Unicode API functions directly, the
calls get routed through code in the MSLU unit first. For
details on how this unit works, see the comments in the source code.
If a function cannot be found in Unicows.dll, then the function will get redirected to an error-handling function that duplicates the API functions’ documented failure behaviors, just like Unicows.lib does.
Not all functions are declared equally. The MSLUDirect
unit contains several declarations that have been commented out because I
lack declarations for some of the data types used for the
functions’ parameters. If you have a unit that includes those
types, then simply add that unit to MSLUDirect’s uses clause and uncomment the relevant
declarations. Also fix up the functions in the implementation section by removing the return
types from them. You can perform similar fix-ups for the
Unicows_X function-override variables in the
MSLU unit.
The MSLU unit uses the JclPeImage unit, part
of the JCL. The MSLUDirect unit
does not have any dependencies.
These units have not been tested in programs that use run-time packages. So far, I believe the code will only work in self-contained EXE and DLL files, not BPL files.
I developed these units using Delphi 2005, but there is nothing in the
code that absolutely relies on Delphi 2005 features. There are two
instances of the inline directive, but they
can be removed without affecting the program. The code also uses the $REGION compiler directive to facilitate code
folding. Older Delphi versions do not support that, but you can remove
those directives without any ill effects, either, except that the code
will be harder to navigate through.
Although this package includes two units, do not use both of them in a
single project. Pick either MSLU or
MSLUDirect.