Alexandre Julliard julliard at winehq.com
Fri Nov 16 13:28:52 CST 2001

Ove Kaaven <ovehk at ping.uio.no> writes:

> Problem 1: MIDL-generated code.
> midl.exe is Microsoft's IDL compiler, it reads .idl files which describe
> RPC and COM interface, from which it generates .c files, .h files, and
> typelibs. (It is possible to find copies of midl.exe floating on the net,
> as some people have put together "COM kits" for Borland C++ that contains
> midl.exe and some standard .idl files and put them on the web)
> But can the machine-generated sources that MIDL outputs be put into the
> official Wine source?

I'd prefer not. If we want to use .idl files we'll have to come up
with our own compiler, and then we can put the .idl source in the tree
and compile it at build time.

> And how about source IDL files? Can we put into Wine IDL extracted from
> real Windoze .tlb files with a tool like oleview.exe, or IDL parsed from
> MIDL-generated Windows SDK .h files, like objidl.h, with a script?

No, anything generated from a Windows file is copyrighted by
Microsoft, so we cannot distribute it. We need to rewrite these files
from scratch, just like we do for the normal headers.

> Problem 2: RPCSS
> rpcss.exe is the place that keeps track of which process owns which RPC
> endpoints, exported COM objects, and object activation tables.
> The IRunningObjectTable interface, for example, is managed by rpcss.exe,
> and keeps track of certain kinds of COM objects on the computer, so that
> other processes can connect to running COM objects. We probably don't want
> Wine to have to run a separate process for this? If not, can we put this
> kind of COM stuff into the wineserver?

I'd prefer having a separate process, at least in the first stage.

Alexandre Julliard
julliard at winehq.com

More information about the wine-devel mailing list