wine's setupapi.dll / newdev.dll ?
dj015 at yahoo.com
Thu Dec 29 08:05:30 CST 2005
--- Robert Shearman <rob at codeweavers.com> wrote:
> Damjan Jovanovic wrote:
> >I've been working on a still image implementation
> >wine / ReactOS for a while now, and I've only
> >realised how impossible it is in wine at the
> >wine's SETUPAPI.DLL is not even in its infancy, it
> >doesn't even let you enumerate non-serial-port
> >devices, and doesn't load class-installers, so you
> >can't even install a scanner's INF file. I see that
> >ReactOS's implementation is better and it is under
> >right (LGPL) licence; are we planning on including
> >into wine, and if so, when?
> I don't think it is planned. It is a question of
> showing a demand for
> the code and then someone taking the effort to merge
> the necessary parts.
> >wine's NEWDEV.DLL is pure stubs - so you can't even
> >start installing the device INF file. ReactOS's
> >SVN version of it is a little closer to what I
> >but can we include GPL code in wine? (I've asked
> >developers to relicense it under the LGPL for us,
> >they haven't gotten back to me yet).
> What does NEWDEV do?
Called through rundll32.exe from umpnpmgr, it does all
the user-interface aspects of device installation. All
those screens you see in Windows, where you select a
device category (eg. Mouse), then click "Next", then
you see a list of manufacturers and their devices and
that "Have disk" button, and then you select one and
click "Next" and it carries on - all that is done by
> >So what should I do - submit my STI.DLL and
> >into wine now, even though they won't be usable for
> >good while - or wait for wine to mature?
> Will STI and STI_CI work with the GPL NEWDEV code?
> If so, I would submit
> them and then hope someone will come along and
> implement the necessary
> parts of NEWDEV or convince the ReactOS developers
> to re-license it.
> >And does anyone know any good documentation for
> >writing COM out-of-process servers (that use
> >transport and have some [local] methods)?
> What documentation do you need? ncalrpc is just like
> any other transport
> - you just need to specify the right format for the
> endpoint and the RPC
> runtime does the work of opening it for you. Local
> methods are also
> straightforward. It just means that no remoting
> information is generated
> for it. This is typically used when the convenient
> form of the function
> has types incompatible with the RPC runtime. You can
> use a remote form
> with the call_as attribute to allow you to write a
> proxy/stub function to call the remote function. See
It seems you can't do the following - Microsoft's MIDL
specifically forbids specifying binding handles for
COM interfaces (so wine's widl must be broken, because
it does allow it):
So how else do you control which RPC binding handle is
used in marshalling a particular COM interface?
> Rob Shearman
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
More information about the wine-devel