MS OLE questions

[Kelly Leahy]

> > That's what I was thinking, but I found an article from 1994 claiming
> > that ole would be shortly moving to the DCE RPC protocol instead of
> > using window messages (and so they did).
> >
> > I guess they didn't purge window messages entirely.
>
>
> Actually, it looks like they didn't:
> http://www.microsoft.com/msj/0596/activex0596.aspx
>
> so it seems window messages are still used for RPC when no networking is
> involved.
>

This looks like the part that should be most interesting to us... (below)  I
didn't see anything to indicate that RPC uses messages (If i'm reading your
comments correctly, it sounds like you think it does?).  However, in order
to avoid the blocking RPC system call, the thread enters a message loop and
makes the RPC system call on another worker thread (when a call is made
within the channel implementation).  If this pool of threads and
worker-made-call functionality is not currently implemented in the standard
IRpcChannelBuffer implementation in WINELIB, then we probably need to
implement it somehow.

As shown in Figure 4, the Apartment model uses additional threads to achieve
the reentrancy requirements for OLE. In the Apartment model, when the client
thread makes a method call on an object in a different thread, process, or
host, the client is actually making a method call on a proxy. The proxy
marshals the appropriate parameters into the request PDU and dispatches the
call to the object by calling the channel's SendReceive method, which does
not return until the response PDU is received from the object. For those of
you new to standard marshaling, a channel is just a COM-based wrapper around
the RPC run-time layer. Once inside the implementation of the channel, the
client thread does not call the low-level RPC run-time routine directly.
Instead, the client thread spawns a worker thread to perform the blocking
call and then waits in a modal message loop so external method requests can
be serviced as well. (An application can install a message filter inside
this modal loop to allow or disallow incoming method requests and non-OLE
window messages. See CoRegisterMessageFilter for details.) This modal loop
continues until the worker thread notifies the client thread that the
response PDU was returned by the RPC run time. When the modal loop exits,
the channel's SendReceive method returns the response PDU to the proxy for
unmarshaling to the client. Because all of this happens behind the channel's
IRpcChannelBuffer interface, the client and proxy are blissfully unaware
that anything other than a blocking call took place. To avoid excessive
thread creation, COM maintains a pool of worker threads that perform
blocking RPC calls. The number of threads in the pool grows and shrinks
based on the number of outstanding calls.

Kelly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 48 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20030708/b251b44f/attachment.gif