On Wed Nov 1 14:21:27 2023 +0000, Jinoh Kang wrote:
@jacek Would the following make sense to you?
- Define new NtUserMessgae call type for USER32 controls, under
"Wine-specific exports." The next unoccupied ID is `0x0306`. 2. In each USER32 winproc, invoke NtUserMessageCall in place of NtUserSetRealClassId. (Ideally all handling code could be moved to win32u, but I don't believe that's strictly necessary.) 3. In NtUserMessageCall, switch on the call kind and dispatch to appropriate (existing or newly defined) win32u winproc functions. 4. In each of the win32u winproc functions, call `set_real_window_class_id` (which is no longer made extern).
Yes, something like that makes sense to me.
Define new NtUserMessgae call type for USER32 controls, under "Wine-specific exports." The next unoccupied ID is `0x0306`.
I recall seeing some mentions that Windows has reserved IDs for controls, but I can't find it right now. It should be fine to use Wine-specific values as you say, it's very unlikely to matter anyway.
(Ideally all handling code could be moved to win32u, but I don't believe that's strictly necessary.)
Some bits of controls handling should probably indeed be moved (real window classes are an example of that), but I wouldn't phrase it like that. For majority of controls handling code user32 seems to be the right place.
Side note: those control-specific `NtUserMessageCall` calls can fallback to `default_window_proc`, so in cases when we use them, we don't need a separated syscall for that.