On Wed Jan 31 18:10:46 2024 +0000, Jinoh Kang wrote:
Or rather, are you saying that KUSD's broken state doesn't matter because it's closed before the application starts, but that isn't the case for desktop shared mapping? Like, another thread/proces suspending the desktop-accessing thread at the right moment and extracting the shared mapping handle remotely.
KUSD is handled in ntdll/unix/virtual.c at process initialization, it is a "singleton" object which is created once on the server and never destroyed. So while maybe it is not exactly perfect there as well, doing such hacks in win32u is much worse, it breaks layering with win32u starting making assumptions on Nt kernel object operation and performing memory management directly.
I think if saving space is needed now just avoiding Nt section is more straightforward than building Wine specific infrastructure around those, and some way of pooling of the shared memory is more straightforward than that.