Whats going to happen with COleTemplateServer::RegisterAll() in windows 7
-
14-06-2021 - |
Domanda
Ok, so we have a C++ app that runs fine in Windows XP. It has the following code in the initialization
// Register all OLE server (factories) as running. This enables the
// OLE libraries to create objects from other applications.
COleObjectFactory::RegisterAll();
Now like i said, it works fine in Windows XP, but as far I understand the program tries to register its COM interface Which is fine in XP, but this may be a problem in Windows Vista and Windows 7 because of the UAC. Especially if its is run as a standard user (with no elevated privileges).
If i understand it correctly this is needed for the program to run properly, but it cant execute this code without elevated privileges. If it will run every time the app runs (this usually runs when CWinApp::init()
is run)
Before you say just use admin privileges, the user will not have them, there is no way to change that
So, now my questions are:
1) am i correct in my assumptions?
2) if I am correct, what is the best way around this? Can i just remove this? Do i need to set up some other thing? (we changed some VB modules to use a XML file instead of stuff in the registry
PS: the modules compiles into DLLs
PPS: UAC MUST be on
Soluzione
Take note that:
- The documentation for these functions makes no mention of any privilege requirements; and
- nobody online seems to be having trouble with these functions in limited privilege environments; and
- it's 2012, I think someone would have noticed if these functions didn't work under UAC by now.
So (with nothing to suggest otherwise) I'd say It Just Works.
Notwithstanding the above, I looked at the implementation of COleObjectFactory::RegisterAll()
and COleObjectFactory::UpdateRegistryAll()
.
RegisterAll
Ultimately calling RegisterAll
ends up in olefact.cpp:135
where CoRegisterClassObject
is called. From MSDN:
Registers an EXE class object with OLE so other applications can connect to it.
I believe this registration will be limited to the current user's session and the lifetime of the application. The Remarks section touches on privileges (As of Windows Server 2003...) but doesn't provide anything concrete.
There's an object known as the Running Object Table
(ROT) that can be retrieved via GetRunningObjectTable
. The documentation has this snippet:
Each workstation has a local ROT that maintains a table of the objects that have been registered as running on that computer.
The COM Elevation Moniker has some more information about the ROT and privileges (it suggests processes of various privilege levels work fine with it). The links on the left-hand side might help, too.
Overall it seems there's nothing to suggest that CoRegisterClassObject
requires administrator permissions.
UpdateRegistryAll
This function ends up in olefact.cpp:375
where it opens HKEY_CLASSES_ROOT
. At this point the documentation gets a bit better:
Registry functions such as
RegOpenKeyEx
orRegQueryValueEx
allow you to specify theHKEY_CLASSES_ROOT
key. When you call these functions from a process running in the interactive user account, the system merges the default settings inHKEY_LOCAL_MACHINE\Software\Classes
with the interactive user's settings atHKEY_CURRENT_USER\Software\Classes
.
Further on:
If you write keys to a key under
HKEY_CLASSES_ROOT
, the system stores the information underHKEY_LOCAL_MACHINE\Software\Classes
The documentation doesn't define what happens when you try to write to HKEY_CLASSES_ROOT
under limited privileges (i.e. a standard user can't write to HKLM
), but I believe that you'll end up writing to HKCU
instead.
And finally, note:
Windows Server 2003 and Windows XP/2000: Applications can register dependent COM objects to either the per-machine or per-user COM configuration store (
HKEY_LOCAL_MACHINE\Software\Classes
orHKEY_CURRENT_USER\Software\Classes
).
So if it falls through to HKCU
, you should be fine.
Caveat Implementor: Don't rely on implementation details.