[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