Hi, Currently functions Dll[Un]RegisterServer in Wine look strange to me. It's a great code duplication. As we have ATLRegistrar implementation right now it can be changed. We can use ATL to register dlls. This way functions Dll[Un]RegisterServer can be really simple and registry can be described by elastic and simple rgs scripts. You can see example of rgs script here: http://cvs.winehq.org/cvsweb/wine/dlls/atl/atl.rgs?rev=1.2&content-type=... and documentation of ATLRegistrar here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/htm...
There are two more aspects of this solution: - dependence on atl I don't think it's a true problem as we can create ATLRegistrar by CoCreateInstance and finally we depend on atl _only_ while registering, so it's not a great dependency... - header file We would need to make atliface.idl accessible for other dlls. Actually it is a public ATL header file, so there is nothing wrong in doing this. We could just move it to include/ (or maybe include/atl where, in future, more headers of ATL could be placed).
The benefit is: no code duplication, more elastic and clean registration code. What do you think? Is it a good idea?
Thanks, Jacek
Jacek Caban wrote:
Hi, Currently functions Dll[Un]RegisterServer in Wine look strange to me. It's a great code duplication. As we have ATLRegistrar implementation right now it can be changed. We can use ATL to register dlls. This way functions Dll[Un]RegisterServer can be really simple and registry can be described by elastic and simple rgs scripts.
The format of the .rgs files does not look that appealing to me. The native components usually implement DllRegisterServer by calling an advpack function on a .inf file stored in the dll's resources. This format is cleaner, but still has the disadvantage that you cannot do anything dynamic with it, such as, registering typelibs and registering interface marshalers.
The benefit is: no code duplication, more elastic and clean registration code. What do you think? Is it a good idea?
In my opinion, no. I would prefer to have the current common regsvr code in a file that can be included, which would bring about the same benefits.
Rob
-
Jacek Caban -
Robert Shearman