ADVAPI32: Start test for service tests

Rolf Kalbermatter r.kalbermatter at hccnet.nl
Mon Jun 4 15:31:15 CDT 2007


James Hawkins [mailto:truiken at 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




More information about the wine-devel mailing list