Move all common Dll[un]RegisterServer stuff to advapi
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(a)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
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(a)gmail.com> wrote:
On 6/22/06, Vijay Kiran Kamuju <infyquest(a)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(a)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
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(a)gmail.com> wrote:
On 6/22/06, Vijay Kiran Kamuju <infyquest(a)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(a)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. -- James Hawkins
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
participants (3)
-
James Hawkins -
Mike Hearn -
Vijay Kiran Kamuju