by Michael S. Kaplan, published on 2010/03/10 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/03/10/9976075.aspx
So it was less than twelve hours ago that Erez asked me via the Contact link:
Hi Michael,
I would like to thank you for your post
on Windows7 RTL bug, you actually saved
us, our clients could not upgrade to Windows7 because of this bug and it was a serious problem.During our testing we found out that this is not the only thing that has changed, for example the GetDateFormat API, produces different day names On WindowsXP I get "ד"
On Windows7 I get "יום ד"This might seem puny at first but it has major influence, everywhere we use day names (and expect a single letter like before) we have an error, all the calendar controls are now bigger and hide other controls nearby etc'
this is the code I have :
SYSTEMTIME st;
GetSystemTime (&st);
LPWSTR buff =
new WCHAR[20];
int res = GetDateFormat (LOCALE_USER_DEFAULT,NULL,&st,L"ddd", buff,20 );I will greatly appreciate any help and guidance from you.
Thank you,
Erez.
Ah, another fan of How Windows 7 broke VB6's RightToLeft property, and how to get it fixed! I don't mind pointing out that this one has proven to be very popular via several of the different people who are pointing to it....
Now this other issue is slightly different and has to do with a different issue: the fact that according to Day, Month, Year, and Era Format Pictures, the ddd format refers to the LOCALE_SABBREVDAYNAME* values, and those values have been changed in Windows 7.
Did this change happen in Vista? I do not know but it may be the case. Does anyone know for sure?
Now the Day, Month, Year, and Era Format Pictures points out that:
Windows Vista and later: If a short version of the day of the week is required, your application should use the LOCALE_SSHORTESTDAYNAME* constants.
This is why I wonder if the change is true of Vista as well.
Because if the folks in the subsidiary in Israel decided to move those one letter day names to LOCALE_SSHORTESTDAYNAME* as soon as it started existing and then put some "slightly less short but still kind of short" names in LOCALE_SABBREVDAYNAME* as soon as the new set of names became available, then it would explain what happened here. And even in Erez's case it isn't like actual formatting is being done - a fancy way to extract the same value as the GetLocaleInfo[Ex] call is all that the code is, in this case (since there are no genitive dates in Hebrew as I mentioned before).
Though the problem here is that they did not add a format string, so to get the new shortest constants you would have to completely change to a GetLocaleInfo[Ex] call for the newer platforms.
Now this does suck a bit, though it kind of makes sense since the new constant was primarily added to support calendar-type applications rather than formatted dates. And there aren't good candidates for intuitive new format string tokens even if made sense to do (and there are bigger backcompat risks adding new tokens given the way that Windows handles tokens (something I could get into in some other post if people were interested).
Though they did not have to change the LOCALE_SABBREVDAYNAME* values and break folks like Erez here.
I mean, knowing that locale data is subject to change does not mean changes should feel so gratuitous....
referenced by