http://www.cs.wisc.edu/~rkennedy/ Posted Sunday, May 22nd, 2005 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 only on 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 Download MSLU.zip 54,392 bytes 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.

附加檔案：78661_MSLU.zip

天，老兄能否放个DEMO上来，怎么用啊～

我也希望有例子啊，楼主加油