[PATCH 3/4] localspl: Add support for monitors providing the MONITOR2 interface.
Huw Davies
huw at codeweavers.com
Wed Sep 4 06:44:35 CDT 2019
On Wed, Sep 04, 2019 at 06:38:49PM +0800, Dmitry Timoshkov wrote:
> Huw Davies <huw at 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.
More information about the wine-devel
mailing list