What code page does MSLU convert with

The Microsoft Layer for Unicode is usually just a very simple wrapper over the non-Unicode APIs on Window 95, 98, and Me, that uses the default system code page to do the conversions.

There are of course exceptions to this; there are times when Win9x will do just fine with the original Unicode strings, and when that is the case, MSLU works hard to honor that support. I will talk about those cases another day.

I would say there are six different buckets that the various functions fall into:

• Some use the default system codepage (CP_ACP), the one returned by the GetACP function;
  (e.g. functions like CreateDC, and most of the other functions that MSLU wrapped)
• Some use the default system OEM code page (CP_OEMCP), the one returned by the GetOEMCP() function;
  (e.g. functions like CharToOemBuff)
• Some could use either of the above two code pages, depending on the return from the AreFileApisANSI function;
  (e.g. file managment functions like FindFirstFile)
• Some use the ACP of a particular LCID, as returned by a call to GetLocaleInfo with the LOCALE_IDEFAULTANSICODEPAGE flag;
  (e.g. all of the NLS APIs that take LCID parameters, like GetNumberFormat)
• Some use the ACP based on a particular device context handle (HDC), which has a Charset associated with it;
  (e.g. most of the GDI functions that take an HDC parameter, like GetTextExtentExPoint)
• A very few use other mechanisms entirely, we'll call it the miscellaneous bucket.
  (e.g. GetClipboardData, which can use all manner of code pages depending on whether CF_LOCALE is specified on the clipboard or synthetic formats are being supported)

The decisions over what to use for the conversion were not arbitrary.

Because, believe it or not, there are many internal pieces of Win9x that actually do support Unicode. This is a fact that Chris Wendt reminded me of years ago, when he pointed to TrueType fonts, large pieces of the GDI that uses those fonts, the NLS data, all of the COM interfaces in the Shell, and more. And he was right; Unicode support is sometimes more than just the interface.  

Thus in cases where conversion was already being done by the operating system, the goal was to match that conversion that the OS itself was doing. Because any time we did not match the OS behavior, all of the string outside of ASCII was probably corrupted.

So the answer to the question first posed in the title of this post (What code page does MSLU convert with?) is that it really depends. On the function you are calling, sometimes on how you are calling it, and sometimes on the way other functions have set the stage....