Re: [V2] Support of .idl files

From: Alexey Pakhunov (alexeypa_at_[hidden])
Date: 2005-06-02 15:33:48

Few more comments...

> There are two DLLs that are generated in COM: the "normal" DLL provides the 
> implementation of the COM object along with the entry points to create and 
> manage it and the "proxy" DLL which contains the code generated by the MIDL 
> compiler to allow a COM object to be used over process and computer 
> boundaries using RPC (Remote Procedure Call). It is possible to have a 
> "merged" DLL that contains the code for both the "normal" and "proxy" DLLs.

.. and to make things even more complex: a COM server (i.e. the code 
that goes to the "normal" DLL) can be compiled to an executable. In case 
if BB probably the only change will be changing 'lib' to 'exe'.

>>I think you've decided to use composite feature already? 

This is a one possible approach. Looks nice at the first glance but 
actual results are not too impressive.

> * $(idl)_dlldata.c -- DLL data (not sure exactly what this contains);

This file defined proxy dll entry points:
DllGetClassObject
DllCanUnloadNow
GetProxyDllInfo
DllRegisterServer
DllUnregisterServer

In case of merged DLL names of these functions are prefixed with "Prx". 
The prefix is set via the ENTRY_PREFIX preprocessor define.

> The $(idl)_dlldata.c and $(idl)_p.c files should only be compiled and linked 
> if you are building a proxy/merged DLL with the defines _WIN32_WINNT=0x0500, 
> USE_STUBLESS_PROXY and ENTRY_PREFIX=Prx, and the following libraries 
> included: rpcns4.lib and rpcrt4.lib.

In case of merged DLL an additional requirement should be satisfied: a 
developer should correctly call PrxXxx functions (see above) from 
standard COM DLL entry points (DllXxx).

Plus a developer should supply correct .def files for COM and proxy DLLs.

> The solution I was aiming for was to generate the _dlldata.c and _p.c files 
> as .gen files so Boost.Build would not compile them, then generate a .c file 
> that includes these in, having setup the appropriate definitions and 
> libraries. However, my solution does not quite work yet.

My point is even if BB generates helper .c wrappers, required defines 
and automatically links required dlls a developer still will have to 
write some code manually (.defs and wrapping PrxXxx). So I would say it 
would be better to have a simple rule that describes what midl actually 
does. And a developer will do the rest. I volunteer for writing HOWTO 
describing how to convert existing Visual Studio project to a .jam file.

Best regards,
Alexey Pakhunov.