When other teams lock down your implementation....

by Michael S. Kaplan, published on 2005/07/24 14:59 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/07/24/442720.aspx

The other day someone was talking about how we could maybe think about not using the registry for some of our NLS support configuration. It was an interesting thought, and I am not completely against the concept of breaking people who insist on doing unsupported things with undocumented registry keys. After all, that is why certain things are not documented!

But then yesterday I was looking through MSDN and stumbled acroos the Host Integration Server 2000 documentation (it was hard to miss, under a main topic like NLS (National Language Support), of course!). There are the SNANLS API Functions, and in particular OpenNlsRegistry which opens up the key that we were under the (apparently mistaken) impression was internal and undocumented. Darn.

Many of of their other functions (like SnaNlsinit) do similar things. Double darn. And it's probably too late to call it a typo. :-(

Now if you start looking around their APIs to see if there is anything you might want to use, note that their SnaNlsMapString has nothing to do with our NLS LCMapString; they are mapping between code pages, while we do a whole bunch of other mappings, like I describe here. They would be doing the equivalent of combining MultiByteToWideChar and WideCharToMultiByte calls to get the work done in this function....

This post brought to you by "«" (U+00ab, a.k.a. LEFT-POINTING DOUBLE ANGLE QUOTATION MARK)

I suppose that either you sre stuck with your current implementation, or you have to thunk the now published APIs into your new implementation.

My question (as the devils advocate) is if the APIs were "internal and undocumented" then how did the Host Integration Server team find out about them? Shouldn't they be only using the APIs that are listed in MSDN like all the rest of us :)

Hi Troy, Well, there are no Base NLS APIs that will check this functionality on remote machines, which is the basic reason most of them exist....

Perhaps if you were to prefix not-for-public-release thingamajiggers with "ms"? MsOpenNlsRegistry

That way every team (and customer!) would know what was public and what was private.

Good thought, but these are not API functions we are talking about, they are registry keys and values (that function I quoted was their wrapper, not our registry key). And they were all designed a decade ago with a lot of dependencies that are valid, so changing them would be hard even if people were not making them "public" as happened here. But random registry config. keys under HKLM that are not documented? I don't know of anyone who would assume that was public info.... :-)

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.