On Tue, Nov 17, 2009 at 19:59, Mark Hammond <skippy.hamm...@gmail.com>wrote:
> On 18/11/2009 6:29 AM, Randall Walls wrote: > >> I don't believe so, but it seems like I'm in a catch 22, where I need to >> _winreg.OpenKey the key first before I can pass it to >> _winreg.DisableReflectionKey, but it doesn't exist, so I can't open it. >> >> I did find out that I can open the key using: >> hKey = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, >> r"SOFTWARE\ODBC\ODBC.INI\ >> DRSQL2000_mu0100\\", 0, _winreg.KEY_READ | _winreg.KEY_WOW64_64KEY) >> >> The 'trick' was adding _winreg.KEY_WOW64_64KEY, which apparently tells >> the system to look in the 64bit key area, and not under the Wow6432Node. >> That brings up problem #2, though... I can't seem to CREATE a key in the >> above path, and _winreg.CreateKey doesn't accept _winreg.KEY_WOW64_64KEY >> (in fact it doesn't accept any options other than key, sub_key). >> _winreg.CreateKey does work, it just puts the key in >> SOFTWARE\Wow6432Node\ODBC\ODBC.INI. So I'm in a quandry... I'd like to >> use one or the other, and not have to account for both. >> > > It looks like _winreg needs to be enhanced to make the RegCreateKeyEx API > function available. It can be called via the win32api module of pywin32, or > could also be called via ctypes. > > HTH, > > Mark > Created http://bugs.python.org/issue7347 and added a patch which I think will solve the problem moving forward.
-- http://mail.python.org/mailman/listinfo/python-list
