Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #876 > unrolled thread

Using regsvr32 question

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  Using regsvr32 question GS <gs@somewhere.net> - 2012-03-07 00:27 -0500
    Re: Using regsvr32 question Deanna Earley <dee.earley@icode.co.uk> - 2012-03-07 08:51 +0000
      Re: Using regsvr32 question GS <gs@somewhere.net> - 2012-03-07 04:34 -0500
        Re: Using regsvr32 question Deanna Earley <dee.earley@icode.co.uk> - 2012-03-07 10:24 +0000
          Re: Using regsvr32 question Deanna Earley <dee.earley@icode.co.uk> - 2012-03-07 10:31 +0000
        Re: Using regsvr32 question "Mayayana" <mayayana@invalid.nospam> - 2012-03-07 09:58 -0500
          Re: Using regsvr32 question GS <gs@somewhere.net> - 2012-03-07 18:52 -0500
        Re: Using regsvr32 question "Farnsworth" <nospam@nospam.com> - 2012-03-07 22:24 -0500
          Re: Using regsvr32 question GS <gs@somewhere.net> - 2012-03-07 23:19 -0500
            Re: Using regsvr32 question "Mayayana" <mayayana@invalid.nospam> - 2012-03-08 08:53 -0500
              Re: Using regsvr32 question GS <gs@somewhere.net> - 2012-03-08 09:33 -0500

#876 — Using regsvr32 question

Hi all,

I recently ran into a situation where my VB6.exe encountered loaded COM 
Addins in an automated instance of Excel. Whenever I registered 
DLLs/OCXs with regsvr32 the entries would appear under HKCU. Typically, 
COM Addins listed here do not load in auto-instances of their 
respective MS Office host app.

The question I have is why would some software use HKLM for their COM 
Addins, and how would this be done since (by default) regsvr32 uses 
HKCU?

Does regsvr32 support options as to what Registry hive is used?

Thanks in advance...

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
    comp.lang.basic.visual.misc
    microsoft.public.vb.general.discussion

[toc] | [next] | [standalone]

#877

On 07/03/2012 05:27, GS wrote:
> Hi all,
>
> I recently ran into a situation where my VB6.exe encountered loaded COM
> Addins in an automated instance of Excel. Whenever I registered
> DLLs/OCXs with regsvr32 the entries would appear under HKCU. Typically,
> COM Addins listed here do not load in auto-instances of their respective
> MS Office host app.
>
> The question I have is why would some software use HKLM for their COM
> Addins, and how would this be done since (by default) regsvr32 uses HKCU?
>
> Does regsvr32 support options as to what Registry hive is used?

regsvr32 has no control over where the entries are placed, its sole job 
is to load the DLL and call its DLLRegisterServer function. What that 
does is entirely down to the author of the DLL.

By convention, this is used to register a COM DLL and Most ONLY write to 
HKLM but some have special checks to register themselves to HKCU if they 
don't have access.
You'll need to check with the authors to confirm what their DLL does.

More details:
http://blogs.msdn.com/b/oldnewthing/archive/2011/11/10/10235540.aspx

-- 
Deanna Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

[toc] | [prev] | [next] | [standalone]

#878

Deanna Earley has brought this to us :
> On 07/03/2012 05:27, GS wrote:
>> Hi all,
>>
>> I recently ran into a situation where my VB6.exe encountered loaded COM
>> Addins in an automated instance of Excel. Whenever I registered
>> DLLs/OCXs with regsvr32 the entries would appear under HKCU. Typically,
>> COM Addins listed here do not load in auto-instances of their respective
>> MS Office host app.
>>
>> The question I have is why would some software use HKLM for their COM
>> Addins, and how would this be done since (by default) regsvr32 uses HKCU?
>>
>> Does regsvr32 support options as to what Registry hive is used?
>
> regsvr32 has no control over where the entries are placed, its sole job is to 
> load the DLL and call its DLLRegisterServer function. What that does is 
> entirely down to the author of the DLL.
>
> By convention, this is used to register a COM DLL and Most ONLY write to HKLM 
> but some have special checks to register themselves to HKCU if they don't 
> have access.
> You'll need to check with the authors to confirm what their DLL does.
>
> More details:
> http://blogs.msdn.com/b/oldnewthing/archive/2011/11/10/10235540.aspx

Thanks, Deanna. That really didn't help much because there was no 
detail about whether a DLL is registered 'per user' or 'per machine'. 
My question is in context to what happens when I use regsvr32 versus 
when an installer registers components. How does it determine which 
hive to make the entries into?

For example, the COMAddins loaded into my auto-instance of Excel where 
listed under HKLM. Any that were listed under HKCU weren't loaded. I'm 
trying to determine how the DLLs under HKLM got there...

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
    comp.lang.basic.visual.misc
    microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#879

On 07/03/2012 09:34, GS wrote:
> Deanna Earley has brought this to us :
>> On 07/03/2012 05:27, GS wrote:
>>> Hi all,
>>>
>>> I recently ran into a situation where my VB6.exe encountered loaded COM
>>> Addins in an automated instance of Excel. Whenever I registered
>>> DLLs/OCXs with regsvr32 the entries would appear under HKCU. Typically,
>>> COM Addins listed here do not load in auto-instances of their respective
>>> MS Office host app.
>>>
>>> The question I have is why would some software use HKLM for their COM
>>> Addins, and how would this be done since (by default) regsvr32 uses
>>> HKCU?
>>>
>>> Does regsvr32 support options as to what Registry hive is used?
>>
>> regsvr32 has no control over where the entries are placed, its sole
>> job is to load the DLL and call its DLLRegisterServer function. What
>> that does is entirely down to the author of the DLL.
>>
>> By convention, this is used to register a COM DLL and Most ONLY write
>> to HKLM but some have special checks to register themselves to HKCU if
>> they don't have access.
>> You'll need to check with the authors to confirm what their DLL does.
>>
>> More details:
>> http://blogs.msdn.com/b/oldnewthing/archive/2011/11/10/10235540.aspx
>
> Thanks, Deanna. That really didn't help much because there was no detail
> about whether a DLL is registered 'per user' or 'per machine'.

It's entirely down to the author of the DLL.
regsvr32.exe itself has no control over that.

> My question is in context to what happens when I use regsvr32 versus
> when an installer registers components.

There is no inherent difference, as most installers just use regsvr32.exe.
(Note that Windows does apply a compatibility shim to regsvr32.exe but I 
don't know the details off hand)

> How does it determine which hive to make the entries into?

Ask the author of the DLL how they determine which hive.
(Or check what the framework they use does when asked to register)

> For example, the COMAddins loaded into my auto-instance of Excel
> where listed under HKLM. Any that were listed under HKCU weren't
> loaded. I'm trying to determine how the DLLs under HKLM got there...

As I said, it may have been a difference in permissions at the time it 
was registered, maybe file location, maybe the moon phase.

-- 
Deanna Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

[toc] | [prev] | [next] | [standalone]

#880

On 07/03/2012 10:24, Deanna Earley wrote:
> On 07/03/2012 09:34, GS wrote:
>> My question is in context to what happens when I use regsvr32 versus
>> when an installer registers components.
>
> There is no inherent difference, as most installers just use regsvr32.exe.
> (Note that Windows does apply a compatibility shim to regsvr32.exe but I
> don't know the details off hand)

Unauthoritative info at:
http://www.jrsoftware.org/files/is5-whatsnew.htm#5.1.11

-- 
Deanna Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

[toc] | [prev] | [next] | [standalone]

#881

| For example, the COMAddins loaded into my auto-instance of Excel where
| listed under HKLM. Any that were listed under HKCU weren't loaded. I'm
| trying to determine how the DLLs under HKLM got there...
|

  I never realized it was possible to register under HKCU. :)
Deanna's explanation makes sense to me. In general a
COM object is registered for use on the machine. That's
the main reason for having registration in the first place.
I have no ProgIDs at all under HKCU\Software\Classes\.
I've also written a number of DLLs in VB and none of them
registers under HKCU. And I don't see any Typelib key at
all under HKCU, which seems to indicate that nothing ever
has registered under HKCU.

   Out of curiosity, I wrote a short VBScript that creates
a dummy object:
  Set Obj = CreateObject("Slipshod.FileObject")
   MsgBox Obj.Something

  Running it with Regmon I saw WSH do 4 checks. It first
tried to open the HKCU key, then the HKLM key, then
repeated the same sequence. (This is on XP.) So it seems
to be feasible to register under HKCU, but very unusual. 

[toc] | [prev] | [next] | [standalone]

#882

These are MS Office COMAddins that are registered during install. My 
understanding from Excel developer sources is that these components 
'normally' install under HKCU/SOFTWARE/Microsoft/Office/Excel/Addins so 
they are accessible to users via the 'COM Addins Manager' dialog for 
runtime addin management, and NOT loaded in auto-instances of their 
host app. Putting them under HKLM (same path) prevents them from being 
accessible by users for runtime addin management and are ALWAYS loaded 
into their host app.

I don't understand why a author would insist on always loading their 
DLL when they know full well that this breaks the convention practiced 
by most everyone in the Excel development community. There's no issue 
with pre 2007 versions, only with MSO versions that implement the 
Ribbon. In this case any custom menus/toolbars appear on the Addins 
tab, which would normally be empty if people followed convention. All 
it takes is making their addin 'version-aware' so it behaves 
appropriately.

Now I must determine how to handle this going forward since it appears 
the Ribbon is here to stay. I can enumerate the key and grab all the 
'LoadBehavior' settings into an array, modify the values, then restore 
the original settings at shutdown. OR, I could simply set them how they 
should be set for auto-instancing and leave them that way (rather 
irresponsible). OR, I can abandon my approach and create my own custom 
tab and turn all the other ones off while my app is running. This, 
however, is the least desireable approach because it requires separate 
projects for early/late versions since the Ribbon gets managed by the 
imbeded xml in the XLAM. Currently, I use the same XLA for all versions 
of Excel and lock down the UI so only my menus appear on the Ribbon's 
Addins tab and all other tabs are hidden. Unfortuantely, the author 
doesn't give a crap about convention and version-aware practices.

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
    comp.lang.basic.visual.misc
    microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#883

"GS" <gs@somewhere.net> wrote in message news:jj7a3o$thc$1@dont-email.me...
> Thanks, Deanna. That really didn't help much because there was no detail 
> about whether a DLL is registered 'per user' or 'per machine'. My question 
> is in context to what happens when I use regsvr32 versus when an installer 
> registers components. How does it determine which hive to make the entries 
> into?
>
> For example, the COMAddins loaded into my auto-instance of Excel where 
> listed under HKLM. Any that were listed under HKCU weren't loaded. I'm 
> trying to determine how the DLLs under HKLM got there...

There are various ways to register a DLL:

1 - By using Regsvr32, which basically calls DllRegisterServer() function in 
the DLL. The DLL decides which hive it goes to. In VB6, you don't have 
access to the code behind DllRegisterServer(), but in other languages such 
as Delphi/C++, they have access, and can modify the code and change the 
references from HKLM to HKCU.

2 - By NOT using Regsvr32 at all, and create the entries manually. Either by 
using an installer, or a REG file. That way you can choose which hive to 
use.

To find out the registry entries, you can use this article and perhaps 
RegMon:

INFO: Registry Entries Made by an ActiveX Component
http://support.microsoft.com/default.aspx?scid=kb;en-us;183771

[toc] | [prev] | [next] | [standalone]

#884

Farnsworth used his keyboard to write :
> "GS" <gs@somewhere.net> wrote in message news:jj7a3o$thc$1@dont-email.me...
>> Thanks, Deanna. That really didn't help much because there was no detail 
>> about whether a DLL is registered 'per user' or 'per machine'. My question 
>> is in context to what happens when I use regsvr32 versus when an installer 
>> registers components. How does it determine which hive to make the entries 
>> into?
>>
>> For example, the COMAddins loaded into my auto-instance of Excel where 
>> listed under HKLM. Any that were listed under HKCU weren't loaded. I'm 
>> trying to determine how the DLLs under HKLM got there...
>
> There are various ways to register a DLL:
>
> 1 - By using Regsvr32, which basically calls DllRegisterServer() function in 
> the DLL. The DLL decides which hive it goes to. In VB6, you don't have access 
> to the code behind DllRegisterServer(), but in other languages such as 
> Delphi/C++, they have access, and can modify the code and change the 
> references from HKLM to HKCU.
>
> 2 - By NOT using Regsvr32 at all, and create the entries manually. Either by 
> using an installer, or a REG file. That way you can choose which hive to use.
>
> To find out the registry entries, you can use this article and perhaps 
> RegMon:
>
> INFO: Registry Entries Made by an ActiveX Component
> http://support.microsoft.com/default.aspx?scid=kb;en-us;183771

Thanks! I'm just used to registering my own VB6.DLLs via regsvr32, 
which puts entries for COMAddin.DLLs under HKCU, -OR- using a .reg 
(regedit4) to write the key. I didn't know how to access where a VB6 
DLL writes to and so is why I went with regedit4.

I suspect that the author has deliberately configured to use HKLM with 
disregard to the effects that has. I don't understand why users of MS 
Office should not be able to manage their COM Addins via the host app's 
UI dialogs. (Applies to pre v2007 releases of MS Office only)

..Brings back memories of my initial anguish over the introduction of 
the Ribbon. Makes me want to dump MSO altogether and opt for using my 
fpSpread.ocx instead. Problem is that clients WANT Excel-based 
solutions due to popular use in general.

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
    comp.lang.basic.visual.misc
    microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#885

| Thanks! I'm just used to registering my own VB6.DLLs via regsvr32,
| which puts entries for COMAddin.DLLs under HKCU, -OR- using a .reg
| (regedit4) to write the key. I didn't know how to access where a VB6
| DLL writes to and so is why I went with regedit4.
|

  I don't know anything about MS Office, but it sounds
like you're talking about two things. RegSvr32 registers
COM servers, in order to use classes provided by the
server. You usually have HKCR\Your.addin, HKCR\{...}
(the CLSID key, with a number of subkeys) and
HKCR\Typelib. Those are all just part of the system that
allows software to find the executable path and typelib
of a COM server and its classes.

    Other functions are separate. For instance,
a Browser Helper Object gets registered, but that's not
what makes it a BHO. There are specific Registry entries
required for IE to load it.

   I don't know whether there's such a thing as custom
RegisterServer functions for that. I doubt it. There
certainly aren't for VB DLLs. I install something like a
BHO by registering it and then adding the BHO keys and
settings "by hand" during install.

  I'm guessing it's the same with Office add-ins. Which
doesn't exactly answer your question, but it might help
you to ask a more accurate question in a VBA group.

[toc] | [prev] | [next] | [standalone]

#886

Mayayana formulated on Thursday :
>> Thanks! I'm just used to registering my own VB6.DLLs via regsvr32,
>> which puts entries for COMAddin.DLLs under HKCU, -OR- using a .reg
>> (regedit4) to write the key. I didn't know how to access where a VB6
>> DLL writes to and so is why I went with regedit4.
>> 
>
>   I don't know anything about MS Office, but it sounds
> like you're talking about two things. RegSvr32 registers
> COM servers, in order to use classes provided by the
> server. You usually have HKCR\Your.addin, HKCR\{...}
> (the CLSID key, with a number of subkeys) and
> HKCR\Typelib. Those are all just part of the system that
> allows software to find the executable path and typelib
> of a COM server and its classes.
>
>     Other functions are separate. For instance,
> a Browser Helper Object gets registered, but that's not
> what makes it a BHO. There are specific Registry entries
> required for IE to load it.
>
>    I don't know whether there's such a thing as custom
> RegisterServer functions for that. I doubt it. There
> certainly aren't for VB DLLs. I install something like a
> BHO by registering it and then adding the BHO keys and
> settings "by hand" during install.
>
>   I'm guessing it's the same with Office add-ins. Which
> doesn't exactly answer your question, but it might help
> you to ask a more accurate question in a VBA group.

Thanks! I didn't know about this and so was unaware of these behaviors. 
Unfortunately, it adds to the conundrum. VB6 provides us a means to 
create COM Addin DLLs targeted for MSO apps. Other languages do similar 
but apparently can be customized as to how they self-reg. I've pretty 
much concluded, though, that the author of the problem DLLs (yes, 
there's 3 for each MSO app<???>) has done what you do in how the 
Registry entries are handled. I'm trying to get them to either make 
their DLLs version-aware and/or put the entries under HKCU<LOL>!

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
    comp.lang.basic.visual.misc
    microsoft.public.vb.general.discussion

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web