Whats going to happen with COleTemplateServer::RegisterAll() in windows 7

Question

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

Answer 1

Take note that:

1. The documentation for these functions makes no mention of any privilege requirements; and
2. nobody online seems to be having trouble with these functions in limited privilege environments; and
3. 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 or RegQueryValueEx allow you to specify the HKEY_CLASSES_ROOT key. When you call these functions from a process running in the interactive user account, the system merges the default settings in HKEY_LOCAL_MACHINE\Software\Classes with the interactive user's settings at HKEY_CURRENT_USER\Software\Classes.

Further on:

If you write keys to a key under HKEY_CLASSES_ROOT, the system stores the information under HKEY_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 or HKEY_CURRENT_USER\Software\Classes).

So if it falls through to HKCU, you should be fine.

Caveat Implementor: Don't rely on implementation details.