[PATCH] Tests that prove ntdll has no notion of HKCR.

George Stephanos gaf.stephanos at gmail.com
Sat May 18 18:33:10 CDT 2013


On Sat, May 18, 2013 at 11:57 PM, Juan Lang <juan.lang at gmail.com> wrote:

> Hi George,
> (consider subscribing to wine-devel so your emails don't get stuck in
> moderation.)
>
Hmm but I am already!

>
>
> On Sat, May 11, 2013 at 7:43 AM, George Stephanos <gaf.stephanos at gmail.com
> > wrote:
>
>> As instructed, I added a few lines to the already written tests that
>> confirm my claim.
>>
>> Part of the research of the registry merging project was to determine
>> where the implementation is going to be written: advapi32, ntdll or
>> the server itself. The server choice was dismissed since HKCR isn't
>> stored and rather fetched live. These tests prove that advapi32 calls
>> that reference HKCR are either pointed there to \REGISTRY\MACHINE or
>> \REGISTRY\USER and hence, that the merge is to be done in advapi32.
>>
>> http://newtestbot.winehq.org/JobDetails.pl?Key=976
>> ---
>>  dlls/advapi32/tests/registry.c | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/dlls/advapi32/tests/registry.c
>> b/dlls/advapi32/tests/registry.c
>> index b2483a7..8437e4d 100644
>> --- a/dlls/advapi32/tests/registry.c
>> +++ b/dlls/advapi32/tests/registry.c
>> @@ -43,6 +43,7 @@ static DWORD (WINAPI *pRegDeleteTreeA)(HKEY,LPCSTR);
>>  static DWORD (WINAPI *pRegDeleteKeyExA)(HKEY,LPCSTR,REGSAM,DWORD);
>>  static BOOL (WINAPI *pIsWow64Process)(HANDLE,PBOOL);
>>  static NTSTATUS (WINAPI * pNtDeleteKey)(HANDLE);
>> +static NTSTATUS (WINAPI * pNtQueryKey)(HANDLE,int,PVOID,ULONG,PULONG);
>>  static NTSTATUS (WINAPI * pRtlFormatCurrentUserKeyPath)(UNICODE_STRING*);
>>  static NTSTATUS (WINAPI * pRtlFreeUnicodeString)(PUNICODE_STRING);
>>
>> @@ -136,6 +137,7 @@ static void InitFunctionPtrs(void)
>>      pRtlFormatCurrentUserKeyPath = (void *)GetProcAddress( hntdll,
>> "RtlFormatCurrentUserKeyPath" );
>>      pRtlFreeUnicodeString = (void *)GetProcAddress(hntdll,
>> "RtlFreeUnicodeString");
>>      pNtDeleteKey = (void *)GetProcAddress( hntdll, "NtDeleteKey" );
>> +    pNtQueryKey = (void *)GetProcAddress( hntdll, "NtQueryKey" );
>>  }
>>
>>  /* delete key and all its subkeys */
>> @@ -2104,6 +2106,7 @@ static void test_classesroot(void)
>>      DWORD type = REG_SZ;
>>      static CHAR buffer[8];
>>      LONG res;
>> +    void *buf = malloc(300*sizeof(wchar_t));
>>
>
> You could just allocate a buffer on the stack. 300 is probably overkill,
> 100 looks like it would do it. You want to use WCHAR rather than wchar_t.
>
>      /* create a key in the user's classes */
>>      if (!RegOpenKeyA( HKEY_CURRENT_USER,
>> "Software\\Classes\\WineTestCls", &hkey ))
>> @@ -2132,6 +2135,9 @@ static void test_classesroot(void)
>>          RegCloseKey( hkey );
>>          return;
>>      }
>> +    pNtQueryKey( hkcr, 3 /*KeyNameInformation*/, buf,
>> 500*sizeof(wchar_t), (ULONG*)&res );
>>
>
> Not that this will actually overflow, but you specify 500, but only
> allocated 300. A straightforward way to accomplish agreement is to use
> sizeof(buf) / sizeof(buf[0]) as the size, if it's not dynamically allocated.
>
This slipped :|

>
>
>> +    ok( wcsncmp((wchar_t*)buf+2, L"\\REGISTRY\\USER", 14) == 0,
>> +        "key not from \\REGISTRY\\USER\n");
>>
>
> Using L"" constructs isn't portable, you'll need to declare these the
> tedious way you'll find in other Wine tests:
> static const WCHAR reg_user[] = { '\\','R',''E,'G','I','S','T','R',Y',
> etc. Then you can use the sizeof(reg_user) / sizeof(reg_user[0]) trick to
> specify the length.
> I think Alexandre will object to using msvcrt functions (wcsncmp in this
> case), but I don't have a straightforward alternative yet.
>
strcmp is already used. What's the difference?

>
> Welcome to Wine development :)
>
:)

> --Juan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20130519/47abc724/attachment.html>


More information about the wine-devel mailing list