On Wed, Sep 04, 2019 at 06:38:49PM +0800, Dmitry Timoshkov wrote:
Huw Davies huw@codeweavers.com wrote:
Is there a reason why we can't simply replace the MONITOR struct with a MONITOR2 struct? It would require a bit more work at initialisation but then calling the functions would be rather simpler.
I considered that, and even have done an initial implementation that way. However, the structures have different prototypes for some callbacks, and in order to take care of this we'd need to create wrappers. I'd rather decided to use an appropriate table instead.
It's only a couple of functions (OpenPortEx and XcvOpenPort) and all you'd need would be something like:
if (monitor.cbSize == sizeof(MONITOR)) monitor.pfnXcvOpenPort( old_args ); else monitor.pfnXcvOpenPort( new_args );
Of course it's a bit more complicated than this. What you could do is change monitor_t to something like:
... PMONITORUI monitorUI; MONITOR2 monitor; BOOL (WINAPI *old_open_port_ex)(LPWSTR, LPWSTR, PHANDLE, struct _MONITOR *); BOOL (WINAPI *old_xcv_open_port)(LPCWSTR, ACCESS_MASK, PHANDLE); HMODULE hdll; ...
On initialization set up the monitor fn ptrs as appropriate, then the call to XcvOpenPort looks like:
if (pm->monitor.old_xcv_open_port) pm->monitor.old_xcv_open_port( old_args ); else pm->monitor.pfnXcvOpenPort( new_args );
The call to OpenPortEx will be a little trickier, but we don't use that at the moment anyway.
Now you see that it's similar level of complexity in comparison what I've implemented.
Well hardly. Sure it'll make initialization more complicated (though it's really not that bad) but each call-site (apart from one or two exceptions) is simple. Whereas your current patch has complications at every call-site, which won't scale well as we implement more functionality.
Huw.