by Michael S. Kaplan, published on 2006/10/15 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/10/15/827944.aspx
Some may remember when I asked the question Why doesn't GetDateFormat take a CALID?
Some will recall when I pointed out how even ignoring the CALID issue, They make 'em smarter than GetDateFormat.
Some will have vague recollections of the updated GetDateFormat wrapper I got from colleague Tarek and talked about in Cue the smarter version of GetDateFormat... ok, it's a wrap! (note that this had another update done to it to address an additional corner case).
And the keenest among my readers will remember when I pointed out how there is an updated GetDateFormatEx (along with many other functions) in New in Vista: What's your name? Who's your daddy?
So, we have three posts pointing out limitations in GetDateFormat (all of which provide either the methodology to work around the problems or actual code to do so), and one of which points out that there will be in Vista new GetDateFormatEx that uses a locale name rather than a locale ID (LCID).
No, the new function does nothing for the problems pointed out in the original post (I'll get back to that in a second), but if you look at the prototype:
int GetDateFormatEx(
LPCWSTR lpLocaleName,
DWORD dwFlags,
CONST SYSTEMTIME* lpDate,
LPCWSTR lpFormat,
LPWSTR lpDateStr,
int cchDate,
LPCWSTR lpCalendar
);
You'll see that a little bit of thought/planning happened about/with the first problem with the missing CALID (for now that parameter is "Reserved; must be a null pointer" but at least a new GetDateFormatExEx won't be needed when the problem is eventually fixed.
And of course the remaining issues related to handling bidirectional text can be fixed in a future version with a new flag that does everything Tarek's wrapper does (and makes sure not to break anyone who is using the wrapper!).
Now of course the obvious question that comes up here is wondering why, if a new function is being added, no one just bit the bullet and fixed all of these known limitations in the existing functions. I mean after all, one problem was something I posted about in March of 2005, and the other one was first pointed out in February of this year. So its not like nobody knew about it with any warning or anything....
One of the biggest source of posts that I do here on technical NLS issues (way bigger then new features or possible features) is bugs and how to work around them or at least know about them. In fact the only source of posts that is bigger is warnings relating to using the NLS API and its managed analogue correctly and the consequences of not doing so.
If the folks who were triaging the work to be done decided to fix these issues, I could have blogged about that. But since they didn't, I went ahead and did the next best thing and told all of you about it. :-)
This post brought to you by ഗ (U+0d17, a.k.a. MALAYALAM LETTER GA)
Mihai on 16 Oct 2006 3:43 AM:
<< that parameter is "Reserved; must be a null pointer">>
I have seen tons of APIs with reserved parameters. And none of them was extended. In most cases a *Ex version was created.
One of the season why the "reserved parameter" cannot be used is because of backward compatibility.
I think Raimond Chen at some point explained in detail why it is a problem to start using a parameter that was requested for a long time to be NULL.
So, some ppl at MS know that "reserved parameter, must be null" will never be used (because it is dangerous). But there are others that keep adding them.
Now, what is the point of this post?
No point :-) Just saying :-)
Michael S. Kaplan on 16 Oct 2006 4:05 AM:
You need to have faith, Mihai. :-)
Dean Harding on 16 Oct 2006 4:46 AM:
I guess as long as the API actually enforces the "must be NULL" then it's OK. If, at any time, it allowed non-NULL values without reporting an error, then you can't all-of-a-sudden start using non-NULL values, because you can no longer be assured that callers passing in non-NULL know what they're doing.
Well, that was a long, confusing sentence :-)
Michael S. Kaplan on 16 Oct 2006 9:50 AM:
Exactly, Dean. Not confusing, at all!