Using regsvr32 question

[GS]

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...

[Deanna Earley]

Post by GS
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

[GS]

Post by GS
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.
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...

[Deanna Earley]

Post by Deanna Earley

Post by GS
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.
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]

Post by Deanna Earley

Post by GS
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

[Mayayana]

| 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.

[GS]

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.

[Farnsworth]

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

[GS]

Post by Farnsworth

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...

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
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.

[Mayayana]

| 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.

[GS]

Post by Mayayana

Post by GS
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>!