Re: TransGaming and ReWind

On Fri, 7 Jun 2002, Gavriel State wrote:

> The new DCOM system is still a work in progress, and we are a little ways away
> from fully supporting InstallShield 6 with it.  We hope that anyone interested
> in DCOM and OLE support will work with us to improve it.  There are several things
> that remain to be done (including the marshalling bytecode interpreter) that Ove
> will elaborate on shortly.

Well, from memory, remaining is:

- figure out as many RPC format chars (i.e. bytecode values) as possible,
most aren't that difficult to find out since Microsoft's IDL compiler
(MIDL) emits annotated code... the ones I know I've put in rewind's
include/wine/rpcfc.h

- implement lots of marshalling primitives in rpcrt4, which should 
understand those format chars
- implement more support for stubless proxies/stubs in rpcrt4, complete
with RPC format char interpreter (a stubless proxy is a proxy made of
interpreted bytecode instead of compiled C code)

- beef up the IDL compiler, or just use MIDL
(I've placed the IDL compiler in rewind's tools/widl)
- use the IDL compiler of choice to emit marshalling code for IDispatch
(many Wine/ReWind headers may need to be made compatible with IDL before
it'll compile), as IDispatch is not something you want to manually write
marshalling code for

- implement remaining COM goodies and loose ends (proper object
instantiation (in my code it's just placed in the current apartment even
if it's of the wrong type), message filters, external locks, etc)

- oleaut32 should use Create{Proxy,Stub}FromTypeLib (exported from rpcrt4)
instead of doing the marshalling itself, according to a MSDN article;
these rpcrt4 entry points should then generate stubless proxies/stubs
containing the proper RPC bytecode from the typelib (ITypeInfo::GetMops()
may play a role here)

- anything else I didn't think of (including fixing bugs and stuff)