Hi All,
I would like to move all the helper functions register_coclass,etc to a separate file in advapi.dll called regsvr_helper.c and all declarations of structs, consts moved to a separate file called, wineregsvr.h in include/wine
So that it would be easy for other dlls to implement the DllRegisterServer and DllUnRegisterServer. And also clean up the code base.
I need your suggestions, before i submit patches.
Thanks, Vijay
On 6/22/06, Vijay Kiran Kamuju infyquest@gmail.com wrote:
Hi All,
I would like to move all the helper functions register_coclass,etc to a separate file in advapi.dll called regsvr_helper.c and all declarations of structs, consts moved to a separate file called, wineregsvr.h in include/wine
So that it would be easy for other dlls to implement the DllRegisterServer and DllUnRegisterServer. And also clean up the code base.
I need your suggestions, before i submit patches.
That would require at least one extra import from advapi32, which is not a good idea. We're trying to separate connections between dlls and extra exports, not create new ones.
Most of the dlls which have implemented the above functions are importing advapi, because all/most of the Reg*Key functions are implemented in advapi
I think this makes no difference to the existing dlls.
Thanks, Vijay
On 6/22/06, James Hawkins truiken@gmail.com wrote:
On 6/22/06, Vijay Kiran Kamuju infyquest@gmail.com wrote:
Hi All,
I would like to move all the helper functions register_coclass,etc to a separate file in advapi.dll called regsvr_helper.c and all declarations of structs, consts moved to a separate file called, wineregsvr.h in include/wine
So that it would be easy for other dlls to implement the DllRegisterServer and DllUnRegisterServer. And also clean up the code base.
I need your suggestions, before i submit patches.
That would require at least one extra import from advapi32, which is not a good idea. We're trying to separate connections between dlls and extra exports, not create new ones.
-- James Hawkins
On 6/22/06, Vijay Kiran Kamuju infyquest@gmail.com wrote:
Most of the dlls which have implemented the above functions are importing advapi, because all/most of the Reg*Key functions are implemented in advapi
I think this makes no difference to the existing dlls.
You misunderstood what I said. There's nothing wrong with a dll importing advapi32 exports. What you want to do would require *adding* an export to advapi32 that is not in native advapi32, which is wrong.
Ok, no problem. we can add delay import for advapi32. (guessing) As most of the implemented functions use the same code, for implementing those functions. So I thought moving them to a common location would be a good idea. Do you know where should i move the common implementation to?
Thanks, Vijay
PS: I am now going home, will discuss on IRC
On 6/22/06, James Hawkins truiken@gmail.com wrote:
On 6/22/06, Vijay Kiran Kamuju infyquest@gmail.com wrote:
Most of the dlls which have implemented the above functions are importing advapi, because all/most of the Reg*Key functions are implemented in advapi
I think this makes no difference to the existing dlls.
You misunderstood what I said. There's nothing wrong with a dll importing advapi32 exports. What you want to do would require *adding* an export to advapi32 that is not in native advapi32, which is wrong.
-- James Hawkins
On 6/22/06, Vijay Kiran Kamuju infyquest@gmail.com wrote:
Ok, no problem. we can add delay import for advapi32. (guessing) As most of the implemented functions use the same code, for implementing those functions. So I thought moving them to a common location would be a good idea. Do you know where should i move the common implementation to?
The imports for current dlls concerning advapi32 are fine; no need to change to delay import. I understand where you're going with moving factoring out registration, it's just that advapi32 is not the place. I'm not sure where else you could put this. I would ask Alexandre whether he wants it done at all, and if so, where the new code should be located.
On Thu, 22 Jun 2006 15:58:58 -0700, James Hawkins wrote:
The imports for current dlls concerning advapi32 are fine; no need to change to delay import. I understand where you're going with moving factoring out registration, it's just that advapi32 is not the place. I'm not sure where else you could put this. I would ask Alexandre whether he wants it done at all, and if so, where the new code should be located.
I believe this was discussed when the registration code was first added, and Alexandre preferred this approach to having some utility DLL. I guess it's a matter of taste. I would have preferred a wineutils.dll or somesuch but he is the boss :)
thanks -mike
-
James Hawkins -
Mike Hearn -
Vijay Kiran Kamuju