Issues and Concerns
ALPHA Character Attribute of ULS Locale
Japanese ULS locale (OS/2) treats Hiragana, Katakana, Kanji characters as non-alpha although Windows treats them as alpha. Therefore, Open32 uses the following formula to check alpha character attribute for all locales:
alpha = graph && !digit && !punct && !space
But there's no guarantee that this formula always returns a correct result. Needs to seek for a better solution. Enumeration of ULS Objects
Unlike CP/WIN codepages, GPI fonts, etc., ULS objects cannot be enumerated
by any ULS API. However, Open32 needs to enumerate ULS codepage/locale objects
to support WIN32 API, EnumSystemCodePages and EnumSystemLocales. Open32,
therefore, tries to find all available ULS objects at the ULS directories.
Though it is not a well-behaved, secure method, there's no other way to
circumvent the problem. This problem was reported to NLS architecture group
in Austin and is treated as a future work item.
Counting of Result String Size by UniUconvTo/FromUcs
ULS API, UniUconvToUcs and UniUconvFromUcs does not support the functionality to return the required buffer size to contain the result string. (This functionality was formerly supported at the OS/2 For PowerPC development time frame.) Since, in MBCS/DBCS world, the required size to contain the result string is unpredictable, it is considered to be a common method to do the query first before performing real string conversion, for example, on WIN32 platform.
In reality, WIN32 API, MultiByteToWideChar and WideCharToMultiByte support this functionality. Open32, therefore, supports these WIN32 APIs by counting required size by parsing input strings by itself.
This problem was reported to NLS architecture group in Austin and is treated as a future work item.