Ove Kaaven ovehk@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.
On 16 Nov 2001, Alexandre Julliard wrote:
Ove Kaaven ovehk@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.
Hmm. Even when using flex and bison, it sounds like a fair amount of work... wonder who would volunteer?
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.
Now where are all the usual non-lawyers on this list who would argue that API definitions, like prototypes in header files (which of course IDL, as a formalized API spec format, is all about), cannot be copyrighted? Oh well...
-
Alexandre Julliard -
Ove Kaaven