[Bug 52508] EnumDisplayDevices() fails in obscure ways on 32-bit arch when 64-bit Vulkan is present but 32-bit is missing

[WineHQ Bugzilla]

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

--- Comment #4 from Zhiyi Zhang <zzhang at codeweavers.com> ---
(In reply to Zeb Figura from comment #3)
> (In reply to Zhiyi Zhang from comment #1)
> > We can't just let explorer.exe manage them since there are console
> > applications that call EnumDisplayDevices() but don't launch explorer.exe,
> > as Alexandre mentioned. 
> 
> Do you have a link to this conversation?
> 

Eh, I can't find it. I vaguely remember it was during an IRC conversation.

> > I think with the PE work going on, we are moving in
> > the direction of initializing these registries only on the 64-bit side.
> > Jacek knows more about this. And obviously, some error prompt when Vulkan is
> > missing wouldn't hurt.
> 
> Are we planning to make the WoW64 path required? That seems questionable to
> me, but...
> 
> Could we initialize and query monitor information from some other
> centralized location? wineserver, perhaps (I know you had patches for this),
> or just let the first process initialize it while others query? Maybe I've
> had a particularly rough time of it, but it just seems too easy for
> different processes to get different results, in one way or another.

I think monitors are probably initialized in monitor.sys in kernel mode at
startup.
Since wine doesn't have a kernel mode, wineserver is probably the way to go.
My wineserver patches only move part of the monitor information, most of them
are and should still be in SetupAPI. Actually, there is a mechanism to let only
the first process initialize monitors. That's what the force parameter in
X11DRV_DisplayDevices_Init() is for. Maybe recent win32u work changed its
behavior or the first process to create windows isn't always 64-bit.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.