Winreg

[R Pasco]

I'm running python 3.8 on Windows 8.1 x64. Running the following code
produces no errors but does not add a key, name or value. I had no problems
doing this using _wirreg under python 2.7. Any insight will be helpful.

Code:
===
import winreg

hive = winreg.HKEY_LOCAL_MACHINE
keypath = 'SOFTWARE\\AAA_Newkey'
host = None
hosthive = winreg.ConnectRegistry( host, hive )
key = winreg.CreateKeyEx( hosthive, keypath, reserved=0,
access=winreg.KEY_WRITE)
winreg.SetValueEx( key, 'NewValueName', 0, winreg.REG_SZ, 'NewStringValue' )
key.Close()
===
-- 
https://mail.python.org/mailman/listinfo/python-list

Winreg

[R Pasco]

 I can't find instructions for the proper way to reply to 'python list'. Is
it simply a matter of keeping the message title identical to the original
message and emailing again to python-list@python.org ? I'll reply both ways
to test this.

Yes, it's the 64/32-bit views that got me stuck. I think I've got it mostly
figured out. The key HKEY_LOCAL_MACHINE:SOFTWARE requires KEY_WOW64_64KEY
to be 'OR'ed. Winreg gives no indication of this requirement, but the
Windows doc "Redirected, Shared, and Reflected Keys Under WOW64" does
specifically mention  HKEY_CURRENT_USER :SOFTWARE as needing this added
access.

By the way, I'm running python X64, so the program is a "64 bit"
application. Strangely, the KEY_WOW64_32KEY access rights param also works
identically.

To sum it up the pertinent code, so far, is:
==
# Be able to test creating both WOW64 and non-WOW64 key paths.
if 1 :
hive = winreg.HKEY_LOCAL_MACHINE
hivename = 'HKEY_LOCAL_MACHINE'
else :
hive = winreg.HKEY_CURRENT_USER
hivename = 'HKEY_CURRENT_USER'
#
parent_keypath = 'Software'   # Both hives happen to have this top
level key.
newsubkey = 'AAA New Leaf Key, Process PID={}' .format( os.getpid() )

# Note keys created in HKEY_LOCAL_MACHINE::SOFTWARE will be viewed in
RegEdit
#   at HKEY_LOCAL_MACHINE:SOFTWARE\*Wow6432Node*\{newsubkey}.
CreateKeyEx
#   access rights must be set to [winreg.KEY_ALL_ACCESS |
winreg.KEY_WOW64_64KEY]
# -OR-
#   [winreg.KEY_ALL_ACCESS | winreg.KEY_WOW64_32KEY] (??? Why does this
also work ?)
#
newsubkeyPath = os.path.join( parent_keypath, newsubkey )

valuename = 'NewString'
value = 'New String Value'

with winreg.ConnectRegistry( None, hive ) as hivehndl :

with winreg.OpenKeyEx( hivehndl, parent_keypath ) as
parentpath_hndl :

with winreg.CreateKeyEx( parentpath_hndl, newsubkey, 0,
# winreg.KEY_ALL_ACCESS | winreg.KEY_WOW64_64KEY ) as
newkeyhndl :
winreg.KEY_ALL_ACCESS | winreg.KEY_WOW64_32KEY ) as
newkeyhndl :

winreg.SetValueEx( newkeyhndl, valuename, 0, winreg.REG_SZ,
value )

#end
==

Thanks for all the help.
Ray Pasco
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Winreg

[R Pasco]

 My code was just experimental and will be much refined in the future which
will include specific exception catches. Connecting to the local registry
is to 'go the last yard' for a full-blown implementation.

I had a hard time grasping the Windows registry concept of having to first
get a key handle for the parent keypath and then specifying an already
existing fina/'leaf' key as a string in order to simply read the key's
valuename/value data. Who can tell what they were thinking at the time! It
seems like a good idea to "abstract" this out since it seems overly
complicated and needlessly confusing.

Thanks for your extensive info. Its too bad this isn't published in the
python winreg/_winreg modules' info.
Ray Pasco

On Fri, Jul 31, 2020 at 12:43 AM R Pasco  wrote:

> My code was simply experimental and will be much refined in the future
> which will include specific exception catches. Connecting to the local
> registry is to go the 'last yard' for a full implementation.
>
> I had a hard time grasping the Windows registry concept of having to first
> get a key handle for the parent keypath and then specifying an already
> existing final or 'leaf' key as a string in order to simply read the key's
> valuename/value data. Who can tell what they were thinking at the time! It
> seems like a good idea to "abstract" this out since it seems overly
> complicated and needlessly confusing.
>
> Thanks for your extensive info. Its too bad this isn't published in the
> python winreg/_winreg modules' info.
> Ray Pasco
>
>
>
> On Thu, Jul 30, 2020 at 11:53 PM Eryk Sun  wrote:
>
>> On 7/30/20, R Pasco  wrote:
>>
>> >   access rights must be set to [winreg.KEY_ALL_ACCESS |
>> winreg.KEY_WOW64_64KEY
>>
>> It's a bad practice to request more access than you require, at the
>> very least because the request may fail with access denied for no good
>> reason.
>>
>> KEY_ALL_ACCESS includes all applicable standard rights (WRITE_OWNER,
>> WRITE_DAC, READ_CONTROL, DELETE) and all key rights (KEY_QUERY_VALUE,
>> KEY_SET_VALUE, KEY_CREATE_SUB_KEY, KEY_ENUMERATE_SUB_KEYS, KEY_NOTIFY,
>> KEY_CREATE_LINK). For an existing key, do you need to change the
>> owner, read and modify the security, delete the key, set a symlink,
>> etc? It looks like you just need to set a value, i.e. KEY_SET_VALUE.
>>
>> >   winreg.KEY_WOW64_32KEY] (??? Why does this also work ?)
>>
>> By default a 64-bit process doesn't see redirected keys, but if you
>> need to access them, use KEY_WOW64_32KEY in the desired access.
>> Normally a 32-bit process under WOW64 sees redirected keys, and if you
>> need to access the non-redirected keys, use KEY_WOW64_64KEY.
>>
>> Note that KEY_WOW64_64KEY and KEY_WOW64_32KEY access modes only affect
>> runtime redirection. As with the standard MAXIMUM_ALLOWED access mode,
>> they're not assignable rights that can be granted or denied in a key
>> object's access control list.
>>
>> >  with winreg.ConnectRegistry( None, hive ) as hivehndl
>>
>> There is no need to call ConnectRegistry here. By default, predefined
>> handles are resolved to local key handles. Also, if you actually need
>> to access a remote machine, note that it's nonsensical to try to
>> connect to HKEY_CURRENT_USER. The API allows it, but why would one
>> assume that the remote machine will have a profile for the current
>> user's SID? The remote system will most likely just connect to a
>> handle for the default user profile.
>>
>> > The key HKEY_LOCAL_MACHINE:SOFTWARE requires KEY_WOW64_64KEY
>> > to be 'OR'ed. Winreg gives no indication of this requirement, but the
>> > Windows doc "Redirected, Shared, and Reflected Keys Under WOW64" does
>> > specifically mention  HKEY_CURRENT_USER :SOFTWARE as needing this added
>> > access.
>>
>> At the machine level, the software hive is stored on disk at
>> "%SystemRoot%\System32\config\SOFTWARE" and mounted at
>> "\REGISTRY\MACHINE\SOFTWARE". For a WOW64 process, by default there is
>> extensive runtime redirection of keys in this hive to the subkeys
>> "WOW6432Node" and "Classes\WOW6432Node".
>>
>> At the user level, there are two hives mounted. The user profile is
>> stored on disk at "%USERPROFILE%\NTUSER.DAT" and mounted at
>> "\REGISTRY\USER\", where "" is the string form of the user's
>> security identifier (e.g. "S-1-5-21"). For
>> a WOW64 process, there is no redirection of subkeys th