[Bug 54405] New: FAVORITE games crash on New Game (Hoshizora no Memoria, Irotoridori no Sekai, AstralAir no Shiroki Towa, Sakura Moyu...)

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54405

Bug ID: 54405
           Summary: FAVORITE games crash on New Game (Hoshizora no
                    Memoria, Irotoridori no Sekai, AstralAir no Shiroki
                    Towa, Sakura Moyu...)
           Product: Wine
           Version: 8.0
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: trivial
          Priority: P2
         Component: winex11.drv
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Hello,

Multiple visual novels from FAVORITE crash at selecting New Game after startup.
List of affected games (non-exhaustive, using the same engine):

星空のメモリア (Hoshizora no Memoria) -Wish upon a Shooting Star-
    星空のメモリア (Hoshizora no Memoria) -Eternal Heart-
    いろとりどりのセカイ (Irotoridori no Sekai)
    いろとりどりのヒカリ (Irotoridori no Hikari)
    アストラエアの白き永遠 (AstralAir no Shiroki Towa)
    紅い瞳に映るセカイ (Akai Hitomi ni Utsuru Sekai)
    アストラエアの白き永遠Finale-白き星の夢- (AstralAir no Shiroki Towa Finale -Shiroki Hoshi
no Yume-)
    さくら、もゆ。(Sakura, Moyu.) -as the Night's, Reincarnation-)

Workaround:
Go to settings, switch to font settings tab, then go back to main menu. This is
far from obvious, as it looks like the game doesn't work at all.

Technical details:
The game engine crashes calling __invalid_parameter_noinfo after failing to
check results of certain call to GetGlyphOutlineA in its text rendering
routine. More precisely, the engine seems bugged. First thing it does after
starting New Game is trying to "render" Japanese space character U+3000.
GetGlyphOutlineA returns zero for it, this triggers the code path calling
GetLastError. Last error is sticky and there is no SetLastError anywhere before
it. Since GetGlyphOutlineA doesn't set the last error in Wine (at least it's
not the case here), GetLastError checks some "ancient" stuck value. The value
is also strange: 0xffffffff, which isn't usually seen as an error code.

I tried to figure out where 0xffffffff comes from. It's set in
win32u:wait_message. X11DRV_MsgWaitForMultipleObjectsEx returns -1 because the
count arg is 0, after process_events succeeds: ret is set to count-1. I don't
understand where the bug actually is, it's pretty confusing.