[PATCH v3] gdi32: Create the registry keys recursively, if needed.

[Gabriel Ivăncescu]

On 04/10/2021 18:41, Gabriel Ivăncescu wrote:
> On 04/10/2021 16:16, Gabriel Ivăncescu wrote:
>> On 04/10/2021 09:39, Huw Davies wrote:
>>> On Sun, Oct 03, 2021 at 08:33:41AM -0500, Marvin wrote:
>>>> 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=99265
>>>>
>>>> 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
>>>
>>> These do indeed appear to be new failures.
>>>
>>> Huw.
>>>
>>
>> Well, I get those tests even without this patch applied. I don't 
>> actually see how it *could* influence the tests anyway, because it 
>> first tries to open the key directly (like the helper in kernelbase) 
>> so as long as the key exists, the behavior should be identical to before.
>>
>> Maybe the testbot created new prefixes and the tests were simply 
>> broken before and not tested somehow? At least when creating a 32-bit 
>> prefix, my window decorator crashed without this patch.
>>
>> Thanks,
>> Gabriel
> 
> So it looks like 8e40e56b79c39356a981bbc25100daa9635b29f3 is the culprit 
> of the test failures, but note that the failures happen only when 
> *creating* the prefix with that commit, and it's what's broken.
> 
> If the prefix was created without that commit, it will succeed. Also, if 
> the prefix was created with that commit, and then wine without such 
> commit was used to run the tests, it would also fail.
> 
> Anyway, it's unrelated to this patch (I even tested with it to create 
> prefixes cleanly without crashing).

The problem is that these values are not set anymore in the registry:

[System\CurrentControlSet\Hardware Profiles\Current\Software\Fonts]
"FIXEDFON.FON"="vgafix.fon"
"FONTS.FON"="vgasys.fon"
"OEMFONT.FON"="vgaoem.fon"

This is because, in kernelbase, we have get_special_root_hkey and 
create_special_root_hkey, which creates the HKEY_CURRENT_CONFIG special 
key. This has to be created *before* the values are set in update_codepage!

However, commit 8e40e56b79c39356a981bbc25100daa9635b29f3 removed the 
get_dpi function, which did a get_reg_dword(HKEY_CURRENT_CONFIG, ...), 
which implicitly created the special key HKEY_CURRENT_CONFIG in kernelbase.

I'm not sure why it works if the prefix creation font init fails. You 
can just forcefully hack it to fail and it will work to create those 
values, although it crashes the decorator and all that. So, making the 
wine_fonts_key creation fail for some reason will enable those values to 
be set. But that's obviously a hack, so the patch isn't wrong (because 
it makes it work).

I have no idea how to fix this, since that whole special key thing is 
part of kernelbase. Any thoughts?