wine's setupapi.dll / newdev.dll ?

[Robert Shearman]

Damjan Jovanovic wrote:

>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.
>  
>

That doesn't seem appropriate for Wine. We need to think hard about 
which way would be easiest for a user to use a scanner, etc. driven by 
STI. My opinion is that this functionality should be somehow integrated 
into winecfg.

>>>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):
>  
>

Yes, it is on my TODO list to improve the error detection in widl.

>[
>   object,
>   implicit_handle(handle_t bindingHandle)
>]
>interface IStillImage
>{
>....
>}
>  
>

This doesn't make sense at all because COM interfaces don't use binding 
handles, but instead use the abstract IRpcChannelBuffer concept.

>So how else do you control which RPC binding handle is
>used in marshalling a particular COM interface?
>  
>

I think you can control which transport this uses, but it isn't really 
necessary unless you are remoting across a network. What are you trying 
to do?

-- 
Rob Shearman