John Spitzer wrote:
> Everything I've read
> so far says application programs, if the permissions and access is coded
> correctly, should not access the VS keys directly.
Sort of. This advice applies to legacy programs that don't know about
the virtualization. New apps should all be using HKCU keys from the
beginning, so the problem doesn't exist. But when you have a new app
that has to deal with information created by an older app, sometimes you
do have to poke through the virtualization directly.
> To test the access of the key in HKLM, I manually created the
> appropriate key value in HKLM. This is where the application stored the
> key on Windows XP. I also ran this program both as an administrator and
> standard user. With KEY_READ access, I can read the key. With
> KEY_ALL_ACCESS I get the error: [Error 5] Access is denied.
Are you using 32-bit Python or 64-bit Python? Registry virtualization
is only enabled for 32-bit processes. 64-bit apps are supposed to know
what's going on and use the right keys to begin with.
The virtualization is complicated. When you open the HKLM key from a
32-bit app, if you ask for write access and you are not entitled to
write access, it's supposed to open it with read access (unless a
particular flag is set on the key -- see below). Then, when you try to
write to it, it redirects to HKCU.
The registry key itself has certain flags that affect the
virtualization. For example, try this from a command line:
reg flags "HKLM\Software\Interface Software\ConnMgr" query
and see if any of the flags are set.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
