Preferred way of dll registration
Hi, We seem to have 2 different approaches for dll registration: 1) a regsvr.c file with all the necessary functions and registry information. 2) an inf file and some code to register/unregister the dll. The first one is the most common in our source but I can remember a comment from AJ about favoring the latter (or at least something like "maybe we should start using inf files for registration"). Thoughts? -- Cheers, Paul.
Hi Paul, On 2/24/10 8:59 PM, Paul Vriens wrote:
Hi,
We seem to have 2 different approaches for dll registration:
1) a regsvr.c file with all the necessary functions and registry information. 2) an inf file and some code to register/unregister the dll.
3) IRegistrar from atl.dll
The first one is the most common in our source but I can remember a comment from AJ about favoring the latter (or at least something like "maybe we should start using inf files for registration").
Thoughts?
I think both 2) and 3) are way better than regsvr.c. It avoids code duplication and you can add much more custom registries without a single line of C (I'd call it more flexible, but it's more a better flexibility/efforts factor). IRegistrar is much simplier than .inf parser, so it has fewer builtin features. Most useful things may be handled IRegistrar and very simple code in DllRegisterServer implementation to pass some string replacements. Using it would also require moving atliface.idl to include directory. Its advantage is that .rgs files are much cleaner as they represent keys as a tree (see dlls/atl/atl.rgs for an example). I usually use .inf files, but if we'd be considering standardization, my vote would go for IRegistrar and I'm surely all for limiting regsvr.c use. Thanks, Jacek
Jacek Caban <jacek(a)codeweavers.com> writes:
I think both 2) and 3) are way better than regsvr.c. It avoids code duplication and you can add much more custom registries without a single line of C (I'd call it more flexible, but it's more a better flexibility/efforts factor). IRegistrar is much simplier than .inf parser, so it has fewer builtin features. Most useful things may be handled IRegistrar and very simple code in DllRegisterServer implementation to pass some string replacements. Using it would also require moving atliface.idl to include directory. Its advantage is that .rgs files are much cleaner as they represent keys as a tree (see dlls/atl/atl.rgs for an example).
I usually use .inf files, but if we'd be considering standardization, my vote would go for IRegistrar and I'm surely all for limiting regsvr.c use.
Certainly anything is better than regsvr.c files. The ideal solution would be to be able to generate the registration code with widl, along the lines of dlldata.c (though we could also have it generate a .inf/.rgs file if that's easier). It would probably require defining some sort of magic attributes to add to the headers. -- Alexandre Julliard julliard(a)winehq.org
Hi Jacek, On 02/24/2010 09:30 PM, Jacek Caban wrote:
Hi Paul,
On 2/24/10 8:59 PM, Paul Vriens wrote:
Hi,
We seem to have 2 different approaches for dll registration:
1) a regsvr.c file with all the necessary functions and registry information. 2) an inf file and some code to register/unregister the dll.
3) IRegistrar from atl.dll
I see you already sent some atl patches ;)
The first one is the most common in our source but I can remember a comment from AJ about favoring the latter (or at least something like "maybe we should start using inf files for registration").
Thoughts?
I think both 2) and 3) are way better than regsvr.c. It avoids code duplication and you can add much more custom registries without a single line of C (I'd call it more flexible, but it's more a better flexibility/efforts factor). IRegistrar is much simplier than .inf parser, so it has fewer builtin features. Most useful things may be handled IRegistrar and very simple code in DllRegisterServer implementation to pass some string replacements. Using it would also
The registration in atl is currently with some 'hardcoded' values in the C-files. Wouldn't it be beneficiary to move these strings to the atl.rgs file? Than you wouldn't truly need a line of C code when things need to be changed? The above is not really an issue of course if we have autogenerated code for the registration. -- Cheers, Paul.
Hi Paul, On 2/25/10 11:43 AM, Paul Vriens wrote:
Hi Jacek,
On 02/24/2010 09:30 PM, Jacek Caban wrote:
Hi Paul,
On 2/24/10 8:59 PM, Paul Vriens wrote:
Hi,
We seem to have 2 different approaches for dll registration:
1) a regsvr.c file with all the necessary functions and registry information. 2) an inf file and some code to register/unregister the dll.
3) IRegistrar from atl.dll
I see you already sent some atl patches ;)
I just took a look how its implementation looks these days and saw some obvious bugs. They won't matter for using IRegistrar in Wine registration code.
The first one is the most common in our source but I can remember a comment from AJ about favoring the latter (or at least something like "maybe we should start using inf files for registration").
Thoughts?
I think both 2) and 3) are way better than regsvr.c. It avoids code duplication and you can add much more custom registries without a single line of C (I'd call it more flexible, but it's more a better flexibility/efforts factor). IRegistrar is much simplier than .inf parser, so it has fewer builtin features. Most useful things may be handled IRegistrar and very simple code in DllRegisterServer implementation to pass some string replacements. Using it would also
The registration in atl is currently with some 'hardcoded' values in the C-files. Wouldn't it be beneficiary to move these strings to the atl.rgs file? Than you wouldn't truly need a line of C code when things need to be changed?
I prefer not to duplicate CLSIDs and have them hardcoded in one place. It may avoid some typos and make make .inf/.rgs files nicer, but I don't feel strong about.
The above is not really an issue of course if we have autogenerated code for the registration.
Right. Jacek
participants (3)
-
Alexandre Julliard -
Jacek Caban -
Paul Vriens