James Hawkins [mailto:truiken@gmail.com] wrote:
...and msdn is wrong a lot, but that doesn't mean the check is right. If the value you get is 1, then check exactly for 1.
I can currently only check on XP and the behaviour I see there does seem strange to me. It should rather return with some error and not change the size at all or maybe it just returns the default key, which usually should be an empty string. The test as is was meant to have at least some starting point. There will be many additions and possibly changes in the future as other results get known from different Windows versions.
Huh? The function, A or W, returns the number of TCHARS. What behavior should wine not imitate? We don't ignore expected behavior just because we doubt an app will depend on it, especiallly a behavior that is so common.
That is what it says in MSDN yes. But the reality is different!
GetServiceDisplayNameA(hsvcm, "eventlog", NULL, &size);
returns with 19 for the size but returns then only a string "Event Log".
GetServiceDisplayNameW(hsvcm, L"eventlog", NULL, &size);
returns with 9 for the size and returns with the string "Event Log".
Go figure. To me it seems they messed up with the conversion from Widechar to ASCII when needing to calculate the needed size. Unless they use some other function than WideCharToMultiByte() it couldn't be for avoiding an extra buffer allocation since WideCharToMultiByte() specifically states that the input and output buffer can not be the same pointer. Maybe that native NTDLL provides a lower level Unicode -> ASCII conversion that does allow for overlapping buffers. Then this strange behaviour could make sense when implementing the A function on top of the W function as it would avoid one temporary buffer allocation for the conversion. Our implementation currently directly accesses the according registry API to read the string so the actual Unicode conversion happens in the registry API.
While we certainly could hack our ASCII fucntion to behave exactly as the Windows one I do not see any reason to do so. For any properly implemented application it will cause unnecessary memory allocations only and for the others it won't make any difference.
And all this also leaves the problem of localization using different strings for the display name so checking for an explicit string length simply won't work, which was your main criticisme here in the beginning.
Rolf Kalbermatter