Re: wine's setupapi.dll / newdev.dll ?

[Damjan Jovanovic]

--- Robert Shearman  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