Fixes a regression introduced by 1cdc74b2d62d1c94005c46f9c8f4b566aa8bdcbd when creating new prefixes, as NtCreateKey does not recursively create keys.
Signed-off-by: Gabriel Ivăncescu gabrielopcode@gmail.com --- dlls/gdi32/font.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c index 98c70a6..31310b1 100644 --- a/dlls/gdi32/font.c +++ b/dlls/gdi32/font.c @@ -6209,19 +6209,31 @@ UINT font_init(void) OBJECT_ATTRIBUTES attr = { sizeof(attr) }; UNICODE_STRING name; HANDLE mutex, hkcu; + HKEY key, wine_key; DWORD disposition; UINT dpi = 0;
static WCHAR wine_font_mutexW[] = {'\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s', '\','_','_','W','I','N','E','_','F','O','N','T','_','M','U','T','E','X','_','_'}; - static const WCHAR wine_fonts_keyW[] = - {'S','o','f','t','w','a','r','e','\','W','i','n','e','\','F','o','n','t','s'}; + static const WCHAR softwareW[] = {'S','o','f','t','w','a','r','e'}; + static const WCHAR wineW[] = {'W','i','n','e'}; + static const WCHAR fontsW[] = {'F','o','n','t','s'}; static const WCHAR cacheW[] = {'C','a','c','h','e'};
if (RtlOpenCurrentUser( MAXIMUM_ALLOWED, &hkcu )) return 0; - wine_fonts_key = reg_create_key( hkcu, wine_fonts_keyW, sizeof(wine_fonts_keyW), 0, NULL ); - if (wine_fonts_key) dpi = init_font_options( hkcu ); + key = reg_create_key( hkcu, softwareW, sizeof(softwareW), 0, NULL ); + if (key) + { + wine_key = reg_create_key( key, wineW, sizeof(wineW), 0, NULL ); + NtClose( key ); + if (wine_key) + { + wine_fonts_key = reg_create_key( wine_key, fontsW, sizeof(fontsW), 0, NULL ); + NtClose( wine_key ); + if (wine_fonts_key) dpi = init_font_options( hkcu ); + } + } NtClose( hkcu ); if (!dpi) return 96; update_codepage( dpi );
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=99262
Your paranoid android.
=== debiant2 (32 bit report) ===
gdi32: font.c:1234: Test failed: GetCharABCWidthsW should have failed font.c:1681: Test failed: GetGlyphIndicesW should have returned a 001f not 0000 font.c:4387: Test failed: info[0] = 3 for the system font font.c:5033: Test failed: Unexpected first glyph L":" font.c:5060: Test failed: Unexpected first glyph L":" font.c:7484: Test failed: expected 0, got -1 font.c:7485: Test failed: expected 0, got -6 metafile.c:5106: Test failed: expected 0, got 150 metafile.c:5180: Test failed: expected 0, got 150
=== debiant2 (32 bit Chinese:China report) ===
gdi32: font.c:1234: Test failed: GetCharABCWidthsW should have failed font.c:1681: Test failed: GetGlyphIndicesW should have returned a 001f not 0000 font.c:4387: Test failed: info[0] = 3 for the system font font.c:5033: Test failed: Unexpected first glyph L"8" font.c:5060: Test failed: Unexpected first glyph L"8" font.c:7484: Test failed: expected 0, got -11 font.c:7485: Test failed: expected 0, got -6 metafile.c:5106: Test failed: expected 0, got 178 metafile.c:5180: Test failed: expected 0, got 178
=== debiant2 (32 bit WoW report) ===
gdi32: font.c:1234: Test failed: GetCharABCWidthsW should have failed font.c:1681: Test failed: GetGlyphIndicesW should have returned a 001f not 0000 font.c:4387: Test failed: info[0] = 3 for the system font font.c:5033: Test failed: Unexpected first glyph L":" font.c:5060: Test failed: Unexpected first glyph L":" font.c:7484: Test failed: expected 0, got -1 font.c:7485: Test failed: expected 0, got -6 metafile.c:5106: Test failed: expected 0, got 150 metafile.c:5180: Test failed: expected 0, got 150
=== debiant2 (64 bit WoW report) ===
gdi32: font.c:1234: Test failed: GetCharABCWidthsW should have failed font.c:1681: Test failed: GetGlyphIndicesW should have returned a 001f not 0000 font.c:4387: Test failed: info[0] = 3 for the system font font.c:5033: Test failed: Unexpected first glyph L":" font.c:5060: Test failed: Unexpected first glyph L":" font.c:7484: Test failed: expected 0, got -1 font.c:7485: Test failed: expected 0, got -6 metafile.c:5106: Test failed: expected 0, got 150 metafile.c:5180: Test failed: expected 0, got 150
Hi Gabriel,
Small fly-fy suggestion from a lurker:
On Sat, 2 Oct 2021 at 14:15, Gabriel Ivăncescu gabrielopcode@gmail.com wrote:
Fixes a regression introduced by 1cdc74b2d62d1c94005c46f9c8f4b566aa8bdcbd when creating new prefixes, as NtCreateKey does not recursively create keys.
Signed-off-by: Gabriel Ivăncescu gabrielopcode@gmail.com
dlls/gdi32/font.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c index 98c70a6..31310b1 100644 --- a/dlls/gdi32/font.c +++ b/dlls/gdi32/font.c @@ -6209,19 +6209,31 @@ UINT font_init(void) OBJECT_ATTRIBUTES attr = { sizeof(attr) }; UNICODE_STRING name; HANDLE mutex, hkcu;
HKEY key, wine_key; DWORD disposition; UINT dpi = 0;
static WCHAR wine_font_mutexW[] = {'\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s', '\','_','_','W','I','N','E','_','F','O','N','T','_','M','U','T','E','X','_','_'};
- static const WCHAR wine_fonts_keyW[] =
{'S','o','f','t','w','a','r','e','\\','W','i','n','e','\\','F','o','n','t','s'};
static const WCHAR softwareW[] = {'S','o','f','t','w','a','r','e'};
static const WCHAR wineW[] = {'W','i','n','e'};
static const WCHAR fontsW[] = {'F','o','n','t','s'}; static const WCHAR cacheW[] = {'C','a','c','h','e'};
if (RtlOpenCurrentUser( MAXIMUM_ALLOWED, &hkcu )) return 0;
- wine_fonts_key = reg_create_key( hkcu, wine_fonts_keyW, sizeof(wine_fonts_keyW), 0, NULL );
- if (wine_fonts_key) dpi = init_font_options( hkcu );
- key = reg_create_key( hkcu, softwareW, sizeof(softwareW), 0, NULL );
- if (key)
- {
wine_key = reg_create_key( key, wineW, sizeof(wineW), 0, NULL );
NtClose( key );
if (wine_key)
{
wine_fonts_key = reg_create_key( wine_key, fontsW, sizeof(fontsW), 0, NULL );
NtClose( wine_key );
if (wine_fonts_key) dpi = init_font_options( hkcu );
}
- }
Instead of manually expanding into a series of reg_create_key() calls, would it make sense to create a helper that does the recursion? Sure it might be new microseconds slower, since one will need to parse/tokenize the string. Yet overall it should be less code and easier on the eyes ;-)
HTH -Emil
On 03/10/2021 04:15, Emil Velikov wrote:
Hi Gabriel,
Small fly-fy suggestion from a lurker:
On Sat, 2 Oct 2021 at 14:15, Gabriel Ivăncescu gabrielopcode@gmail.com wrote:
Fixes a regression introduced by 1cdc74b2d62d1c94005c46f9c8f4b566aa8bdcbd when creating new prefixes, as NtCreateKey does not recursively create keys.
Signed-off-by: Gabriel Ivăncescu gabrielopcode@gmail.com
dlls/gdi32/font.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c index 98c70a6..31310b1 100644 --- a/dlls/gdi32/font.c +++ b/dlls/gdi32/font.c @@ -6209,19 +6209,31 @@ UINT font_init(void) OBJECT_ATTRIBUTES attr = { sizeof(attr) }; UNICODE_STRING name; HANDLE mutex, hkcu;
HKEY key, wine_key; DWORD disposition; UINT dpi = 0;
static WCHAR wine_font_mutexW[] = {'\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s', '\','_','_','W','I','N','E','_','F','O','N','T','_','M','U','T','E','X','_','_'};
- static const WCHAR wine_fonts_keyW[] =
{'S','o','f','t','w','a','r','e','\\','W','i','n','e','\\','F','o','n','t','s'};
static const WCHAR softwareW[] = {'S','o','f','t','w','a','r','e'};
static const WCHAR wineW[] = {'W','i','n','e'};
static const WCHAR fontsW[] = {'F','o','n','t','s'}; static const WCHAR cacheW[] = {'C','a','c','h','e'};
if (RtlOpenCurrentUser( MAXIMUM_ALLOWED, &hkcu )) return 0;
- wine_fonts_key = reg_create_key( hkcu, wine_fonts_keyW, sizeof(wine_fonts_keyW), 0, NULL );
- if (wine_fonts_key) dpi = init_font_options( hkcu );
- key = reg_create_key( hkcu, softwareW, sizeof(softwareW), 0, NULL );
- if (key)
- {
wine_key = reg_create_key( key, wineW, sizeof(wineW), 0, NULL );
NtClose( key );
if (wine_key)
{
wine_fonts_key = reg_create_key( wine_key, fontsW, sizeof(fontsW), 0, NULL );
NtClose( wine_key );
if (wine_fonts_key) dpi = init_font_options( hkcu );
}
- }
Instead of manually expanding into a series of reg_create_key() calls, would it make sense to create a helper that does the recursion? Sure it might be new microseconds slower, since one will need to parse/tokenize the string. Yet overall it should be less code and easier on the eyes ;-)
HTH -Emil
Actually I was worried adding a full-blown recursive helper (the one from kernelbase as Nikolay mentioned) just for this particular case was overkill in terms of code added, but now that I simplified it for gdi32's cases only, it's actually fairly lean. I'll resend.
Thanks, Gabriel
There is a create_key() helper in kernelbase that you could reuse.