When not to use MLang

by Michael S. Kaplan, published on 2006/01/06 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/01/06/509772.aspx

Under ordinary circumstances I would rather slide down a razor blade into a barrel of iodine than disagree with something that Raymond has posted, but in this case it might be better to either:

The reason for this is that MLang itself, while entirely supported, is really not being actively developed right now. And any time there is a better option to go with, it should probably not be the first choice.

Though it is sometimes the only good choice out there, for example in low-level font linking and code page detection (sorry, no post yet -- I'll have to blog about that at some point!). And even going the opposite direction (from name to LCID in an unmanaged, non-Vista scenario where there are no other good options), MLang might be the way to go.

But beyond that, it may be best to steer clear of MLang if you have a choice -- you will likely be a lot happier with the results....

This post brought to you by "ῴ" (U+1ff4, a.k.a. GREEK SMALL LETTER OMEGA WITH OXIA AND YPOGEGRAMMENI)

There've been lots of technologies that fall into the "supported but not actively documented" category, and in some cases its unfortunate. Is MLang simply "done"--nothing more that needs to be done with it? Or is it because most everything is now in the base platform? Was MLang mostly to help with providing IE a common base for both NT and 9x platforms?

MLang was indeed the IE answer to how to support things cross-Windows platform (not just 9x but also earlier NT), and prior to .NET was the only answer MS provided. But it falls short in many ways and is currently in maintenance mode in regard to the methods and interfaces (data may of course update, but that is a different story).

I use MLANG to do conversions from and to codepages. Our software needs to run under Win2000, XP and Win2k3. Unfortunately, when I query the name for the codepage 50220 under Win32 with GetCPInfoEx(), it does NOT return a name for it. To confuse matters more, I can go FROM 50220 to Unicode, but NOT from Unicode to 50220. I wonder if my OS had a failed language installation. All the languages are enabled in regional settings, the 5022x codepages do not appear in the advanced regional options.

I have checked the registry under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage

and the proper values are there, as well as the needed c_is2022.dll

When I trace into MultibyteToWideChar the proper internal structure gets allocated, but the callback function for the Unicode->50220 is null.

So that is why I have to use the Mlang Interface (as COM).

Also in some prior posts you had said the Win32 tables are in some spots outdated.

So what should I do now?

Ps. And do not get me started on the fact that 50220 is a "modal" codepage. Pesky escaped switch sequences that used to crash my program. ARR

>> When I trace into MultibyteToWideChar the
>> proper internal structure gets allocated, but
>> the callback function for the Unicode->50220
>> is null.

This is how it should be.

1. MultibyteToWideChar is taking a smaller bit into a larger bit space. Works.

2. WideCharToMultibyte takes a large (16 bit) into a smaller (8 bit usually) encoding. 8 bit is only good for 255 chacters.

3. So what do you think is going to happen when you realize 50220 needs more than 8 bits? Yeah, ??? or worse charcters show up!

Just say no to WideCharToMultibyte()!

Nik: I'm having the exact same problem with codepage 50220. It's valid Unicode, but WideCharToMultiByte refuses to accept it. However, Mlang will. To deprecate the only working solution would be frustrating.