[PATCH 3/4] localspl: Add support for monitors providing the MONITOR2 interface.

[Dmitry Timoshkov]

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, and in addition there's a finished patch. I'd prefer
to leave it as it is now, and change it later when it's really needed.

-- 
Dmitry.