Discussion:
[omniORB] Problem with reading registry in Windows 7
Jens Kristian Villadsen
2009-10-22 17:52:57 UTC
Permalink
Hi all
I'm using omniORB 4.1.4 on a Windows 7 x64 machine and it works great
besides reading the registry. The values in the registry is set with the
sample.reg - meaning that the settings are located in
\HKEY_LOCAL_MACHINE\SOFTWARE\omniORB.

However, in the orboptionsreg.cc in src\lib\omniorb\orbcore\ the #define
NEW_REGKEY is assigned to "SOFTWARE\\omniORB" - thereby missing the
\HKEY_LOCAL_MACHINE string. Should'nt this be corrected in a newer
edition of omniORB?
Duncan Grisby
2009-10-26 22:08:17 UTC
Permalink
Post by Jens Kristian Villadsen
I'm using omniORB 4.1.4 on a Windows 7 x64 machine and it works great
besides reading the registry. The values in the registry is set with the
sample.reg - meaning that the settings are located in
\HKEY_LOCAL_MACHINE\SOFTWARE\omniORB.
However, in the orboptionsreg.cc in src\lib\omniorb\orbcore\ the #define
NEW_REGKEY is assigned to "SOFTWARE\\omniORB" - thereby missing the
\HKEY_LOCAL_MACHINE string. Should'nt this be corrected in a newer
edition of omniORB?
If you look at the calls to RegOpenKeyEx, you'll see that it opens the
key within HKEY_LOCAL_MACHINE.

What exactly is the problem you are seeing?

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
Jens Kristian Villadsen
2009-10-27 03:18:35 UTC
Permalink
I've tried debugging it a bit and I found the following:

Instead of accessing the \LOCAL_MACHINE\SOFTWARE\omniORB it accessed the
\HKEY_CLASSES_ROOT\SOFTWARE always. But what seems to be the nature of
this? Iv'e tried the "Run as Administrator"-kinda trick, but so far
nothing has helped me.
Post by Duncan Grisby
Post by Jens Kristian Villadsen
I'm using omniORB 4.1.4 on a Windows 7 x64 machine and it works great
besides reading the registry. The values in the registry is set with the
sample.reg - meaning that the settings are located in
\HKEY_LOCAL_MACHINE\SOFTWARE\omniORB.
However, in the orboptionsreg.cc in src\lib\omniorb\orbcore\ the #define
NEW_REGKEY is assigned to "SOFTWARE\\omniORB" - thereby missing the
\HKEY_LOCAL_MACHINE string. Should'nt this be corrected in a newer
edition of omniORB?
If you look at the calls to RegOpenKeyEx, you'll see that it opens the
key within HKEY_LOCAL_MACHINE.
What exactly is the problem you are seeing?
Cheers,
Duncan.
Jens Kristian Villadsen
2009-10-27 14:30:24 UTC
Permalink
I must admit, I am not all that familiar with the Windows Registry, but
as you point out, the behaviour has changed for Windows 2003. As I am
running Windows 7 x64 I cannot see how this applies to this case.
Anyhow, from my perspective, I would like to know the solution to the
problem,. and like to hear if anyone else has had this issue - and how
they solved it.
Hello!
The behaviour for HKEY_CLASSES_ROOT changed with Windows 2003 Server.
See http://technet.microsoft.com/en-us/library/cc739822%28WS.10%29.aspx
However, i don't see the connection to the SOFTWARE subkey. The above
applies to the subkey SOFTWARE/CLASSES only, IMHO.
Best regards,
Peter
Instead of accessing the \LOCAL_MACHINE\SOFTWARE\omniORB it
accessed the \HKEY_CLASSES_ROOT\SOFTWARE always. But what seems to
be the nature of this? Iv'e tried the "Run as Administrator"-kinda
trick, but so far nothing has helped me.
I'm using omniORB 4.1.4 on a Windows 7 x64 machine and it
works great besides reading the registry. The values in
the registry is set with the sample.reg - meaning that the
settings are located in \HKEY_LOCAL_MACHINE\SOFTWARE\omniORB.
However, in the orboptionsreg.cc in
src\lib\omniorb\orbcore\ the #define NEW_REGKEY is
assigned to "SOFTWARE\\omniORB" - thereby missing the
\HKEY_LOCAL_MACHINE string. Should'nt this be corrected in
a newer edition of omniORB?
If you look at the calls to RegOpenKeyEx, you'll see that it opens the
key within HKEY_LOCAL_MACHINE.
What exactly is the problem you are seeing?
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
Luke Deller
2009-10-28 07:03:25 UTC
Permalink
Hi Jens,

One thing to be aware of on Windows x64 editions is that when a 32-bit application requests to open "HKEY_LOCAL_MACHINE\SOFTWARE" it will actually be given "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node".

Similarly if you request to launch C:\WINDOWS\System32\reg.exe from a 32-bit application (such as the cygwin shell) you'll actually be running C:\WINDOWS\SysWOW64\reg.exe which is a 32-bit application subject to the mapping I mentioned in the previous paragraph.

So if your application is 64-bit, make sure you are initialising the registry settings using the 64-bit version of reg.exe, and likewise if your application is 32-bit then make sure you are running the 32-bit version of reg.exe

Regarding your observation that omniORB is looking at HKEY_CLASSES_ROOT, this does sound rather unlikely to me. You could confirm whether it is true using the Sysinternals "Process Monitor" tool available here:

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Regards,
Luke.

-----Original Message-----
From: omniorb-list-***@omniorb-support.com [mailto:omniorb-list-***@omniorb-support.com] On Behalf Of Jens Kristian Villadsen
Sent: Tuesday, 27 October 2009 8:30 PM
To: omniorb-***@omniorb-support.com
Subject: Re: [omniORB] Problem with reading registry in Windows 7

I must admit, I am not all that familiar with the Windows Registry, but
as you point out, the behaviour has changed for Windows 2003. As I am
running Windows 7 x64 I cannot see how this applies to this case.
Anyhow, from my perspective, I would like to know the solution to the
problem,. and like to hear if anyone else has had this issue - and how
they solved it.
Hello!
The behaviour for HKEY_CLASSES_ROOT changed with Windows 2003 Server.
See http://technet.microsoft.com/en-us/library/cc739822%28WS.10%29.aspx
However, i don't see the connection to the SOFTWARE subkey. The above
applies to the subkey SOFTWARE/CLASSES only, IMHO.
Best regards,
Peter
Instead of accessing the \LOCAL_MACHINE\SOFTWARE\omniORB it
accessed the \HKEY_CLASSES_ROOT\SOFTWARE always. But what seems to
be the nature of this? Iv'e tried the "Run as Administrator"-kinda
trick, but so far nothing has helped me.
I'm using omniORB 4.1.4 on a Windows 7 x64 machine and it
works great besides reading the registry. The values in
the registry is set with the sample.reg - meaning that the
settings are located in \HKEY_LOCAL_MACHINE\SOFTWARE\omniORB.
However, in the orboptionsreg.cc in
src\lib\omniorb\orbcore\ the #define NEW_REGKEY is
assigned to "SOFTWARE\\omniORB" - thereby missing the
\HKEY_LOCAL_MACHINE string. Should'nt this be corrected in
a newer edition of omniORB?
If you look at the calls to RegOpenKeyEx, you'll see that it opens the
key within HKEY_LOCAL_MACHINE.
What exactly is the problem you are seeing?
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
omniORB-***@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
**********************************************************************************************
Important Note
This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the
sender immediately and delete this email. Any views expressed in this email are not necessarily the views of IRESS Market Technology Limited.

It is the duty of the recipient to virus scan and otherwise test the information provided before loading onto any computer system.
IRESS Market Technology Limited does not warrant that the information is free of a virus or any other defect or error.
**********************************************************************************************
Jens Kristian Villadsen
2009-10-28 14:22:32 UTC
Permalink
Thanks Luke, Super!
Changing all the sample.reg parameters from
[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB] to
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\omniORB]
solved the issue. Everything works now - thanks!
Post by Luke Deller
Hi Jens,
One thing to be aware of on Windows x64 editions is that when a 32-bit application requests to open "HKEY_LOCAL_MACHINE\SOFTWARE" it will actually be given "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node".
Similarly if you request to launch C:\WINDOWS\System32\reg.exe from a 32-bit application (such as the cygwin shell) you'll actually be running C:\WINDOWS\SysWOW64\reg.exe which is a 32-bit application subject to the mapping I mentioned in the previous paragraph.
So if your application is 64-bit, make sure you are initialising the registry settings using the 64-bit version of reg.exe, and likewise if your application is 32-bit then make sure you are running the 32-bit version of reg.exe
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Regards,
Luke.
-----Original Message-----
Sent: Tuesday, 27 October 2009 8:30 PM
Subject: Re: [omniORB] Problem with reading registry in Windows 7
I must admit, I am not all that familiar with the Windows Registry, but
as you point out, the behaviour has changed for Windows 2003. As I am
running Windows 7 x64 I cannot see how this applies to this case.
Anyhow, from my perspective, I would like to know the solution to the
problem,. and like to hear if anyone else has had this issue - and how
they solved it.
Hello!
The behaviour for HKEY_CLASSES_ROOT changed with Windows 2003 Server.
See http://technet.microsoft.com/en-us/library/cc739822%28WS.10%29.aspx
However, i don't see the connection to the SOFTWARE subkey. The above
applies to the subkey SOFTWARE/CLASSES only, IMHO.
Best regards,
Peter
Instead of accessing the \LOCAL_MACHINE\SOFTWARE\omniORB it
accessed the \HKEY_CLASSES_ROOT\SOFTWARE always. But what seems to
be the nature of this? Iv'e tried the "Run as Administrator"-kinda
trick, but so far nothing has helped me.
I'm using omniORB 4.1.4 on a Windows 7 x64 machine and it
works great besides reading the registry. The values in
the registry is set with the sample.reg - meaning that the
settings are located in \HKEY_LOCAL_MACHINE\SOFTWARE\omniORB.
However, in the orboptionsreg.cc in
src\lib\omniorb\orbcore\ the #define NEW_REGKEY is
assigned to "SOFTWARE\\omniORB" - thereby missing the
\HKEY_LOCAL_MACHINE string. Should'nt this be corrected in
a newer edition of omniORB?
If you look at the calls to RegOpenKeyEx, you'll see that it opens the
key within HKEY_LOCAL_MACHINE.
What exactly is the problem you are seeing?
Cheers,
Duncan.
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
**********************************************************************************************
Important Note
This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the
sender immediately and delete this email. Any views expressed in this email are not necessarily the views of IRESS Market Technology Limited.
It is the duty of the recipient to virus scan and otherwise test the information provided before loading onto any computer system.
IRESS Market Technology Limited does not warrant that the information is free of a virus or any other defect or error.
**********************************************************************************************
Loading...