On Sat, May 18, 2013 at 11:57 PM, Juan Lang <juan.l...@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.stepha...@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 >
