wine's setupapi.dll / newdev.dll ?

Damjan Jovanovic 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
> for
> >wine / ReactOS for a while now, and I've only
> recently
> >realised how impossible it is in wine at the
> moment...
> >
> >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
> the
> >right (LGPL) licence; are we planning on including
> it
> >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
> latest
> >SVN version of it is a little closer to what I
> need,
> >but can we include GPL code in wine? (I've asked
> the
> >developers to relicense it under the LGPL for us,
> but
> >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
NEWDEV.DLL.

> >So what should I do - submit my STI.DLL and
> STI_CI.DLL
> >into wine now, even though they won't be usable for
> a
> >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
> ncalrpc
> >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
> translating 
> proxy/stub function to call the remote function. See
> 
> dlls/oleaut32/usrmarshal.c.

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):
[
   object,
   implicit_handle(handle_t bindingHandle)
]
interface IStillImage
{
....
}

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. 
dsl.yahoo.com 




More information about the wine-devel mailing list