For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects.
--
v12: win32u: Use the session shared object for user handle entries.
win32u: Use the session shared object to implement is_window.
server: Move the user object handle table to the shared memory.
server: Allocate a session shared memory header structure.
server: Use NTUSER_OBJ constants for user object types.
include: Implement ReadAcquire64.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7610
Yak-shaving for https://gitlab.winehq.org/wine/wine/-/merge_requests/7618.
I added a test to show that DefWindowProc, specifically, sends this event.
The timing is slightly off compared to WM_CTLCOLOR* sometimes, but I think that's fine. There's no reason to expect accessibility tools, specifically, to be sensitive to that.
The spurious events with MDI children changing state may be less fine. The MDI code (in user32) uses DefWindowProc internally to change the window text. Somehow, Windows must accomplish this without sending the event, so presumably there's some backdoor or internal interface in win32u that allows for it. There's a possibility that a screen reader responds to the NAMECHANGE by speaking the window title (I have no idea if any screen reader actually does this), which could be annoying to a user. Still, given that I don't know whether it's a problem, and it's extra complexity that we may not even need, I thought it'd be better to send the MR first with that known issue and see what people think.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7704