Move all common Dll[un]RegisterServer stuff to advapi

[Vijay Kiran Kamuju]

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

[James Hawkins]

On 6/22/06, Vijay Kiran Kamuju  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.

[Vijay Kiran Kamuju]

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  wrote:
> On 6/22/06, Vijay Kiran Kamuju  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

[James Hawkins]

On 6/22/06, Vijay Kiran Kamuju  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.

[Vijay Kiran Kamuju]

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  wrote:
> On 6/22/06, Vijay Kiran Kamuju  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

[James Hawkins]

On 6/22/06, Vijay Kiran Kamuju  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.

[Mike Hearn]

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