https://bugs.winehq.org/show_bug.cgi?id=41713
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Explorer.exe is wrong when |Initial 'explorer' process |started from the process |fails to register/run |creating the Wine prefix |ShellWindows class local | |COM server in new | |WINEPREFIX due to | |incomplete registry data CC| |focht@gmx.net Component|-unknown |programs
--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello folks,
revisiting, still present. I've encountered this in bug 45600 again, see https://bugs.winehq.org/show_bug.cgi?id=45600#c3
If you don't mind I refine the summary line a bit more. It's not easy to find/remember in Bugzilla. I suspect a number of apps suffering from this and users currently just get away by chance:
* WINEPREFIX recycling (using existing prefix) * manual bootstrapping/creation of WINEPREFIX * unelevated process starts using "ShellExecuteFromExplorer" method happen separately, after installer has terminated (launcher)
How about propagating the HRESULT from 'shellwindows_init' to 'manage_desktop' caller and let the process terminate if the COM server fails to register/run due to incomplete registry data? This also ensures that the "root" instance which can't run a COM server by design (only pumps messages) is gone. Then either let the next (UI) process that needs the desktop window automatically bootstrap 'explorer.exe' process again or do it explicitly in 'wineboot' at late stage. At that point all the proxy data is in registry.
https://source.winehq.org/git/wine.git/blob/HEAD:/programs/explorer/desktop....
https://source.winehq.org/git/wine.git/blob/HEAD:/programs/explorer/desktop....
https://source.winehq.org/git/wine.git/blob/HEAD:/programs/explorer/desktop....
$ wine --version wine-5.0-144-g9a9a1821a3
Regards