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

[Jacek Caban]

On 10/4/21 7:29 PM, Gabriel Ivăncescu wrote:
> 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?


Thanks for looking at this. The problem is that reg_create_key doesn't 
handle well creation of root-less keys. It shouldn't try to create 
"\Registry" key. The attached change helps here, does it work for you?


Thanks,

Jacek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: font.diff
Type: text/x-patch
Size: 452 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20211004/627cebcc/attachment-0001.bin>