[
https://issues.apache.org/jira/browse/DAEMON-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789455#action_12789455
]
Jesse Morris commented on DAEMON-131:
-------------------------------------
KREG_WOW6432 doesn't come from any standard header. It's conditionally defined
at the top of prunsrv.c. The reason we need to use that flag for deletion is
that KREG_WOW6432 was already specified for the creation and access of the key,
presumably so that it can share settings between 32-bit and 64-bit versions of
procrun. Whether *that* makes sense to actually do is another question, which
depends largely on how people are using the tool. I don't really have any
insight into that.
If you were already seeing compilation problems on from it's macro expansion
(KEY_WOW64_32KEY) then this is a fine time to fix them. If it was compiling ok
a few days ago, my patch shouldn't break it.
> Win64 build: //DS// fails to delete registry keys
> ---------------------------------------------------
>
> Key: DAEMON-131
> URL: https://issues.apache.org/jira/browse/DAEMON-131
> Project: Commons Daemon
> Issue Type: Bug
> Environment: Win64; I've only seen it on AMD64, but presumably it
> would also happen on ia64.
> Reporter: Jesse Morris
> Assignee: Mladen Turk
> Priority: Minor
> Attachments: procrun-win64-registry-cleanup.patch
>
>
> When creating and accessing the configuration registry keys, the tool uses
> CreateRegKeyEx with the KEY_WOW64_32KEY flag, telling windows "Use the 32-bit
> hive instead of the 64-bit one". Maybe this was done so that 64-bit daemons
> could use the configuration from 32-bit ones?
> Anyway when it's time to go and delete the configuration from the registry it
> uses the ancient SHDeleteKey call, which tries to delete the key from the
> 64-bit hive, which fails, so the key is left behind.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
