• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • RegistryGet not finding entries due to VirtualStore on Windows 10

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (1)

Resolved RegistryGet not finding entries due to VirtualStore on Windows 10

  1. Issue
0
Votes
Undo
  1. Mitch Goldstein
    Mitch Goldstein
  2. PowerBuilder
  3. Thursday, 9 November 2017 05:09 AM UTC

Hello,

I'm struggling to find consistencies across platforms due to registry virtualization.  When running through my PB 2017 IDE, the following code works, but when I compile as 32bit or 64bit app, and run the exe, it does not find the product code.

RegistryGet(HKEY_LOCAL_MACHINE\Software\WOW6432Node\Min-U-Script Pro", "Product Code", RegString!, gs_product_code)

Additionally, when I look at the registry, the path looks completely different:

Computer\HKEY_USERS\S-1-5-21-1312213260-3357453489-502601113-1001\Software\Classes\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\Min-U-Script Pro

Please help with a registry strategy which will work across platforms.

TIA,

Mitch

64 bits executable and accessing Excel data
Host-service somewhere?
Responses (1)
Marco Meoni
Marco Meoni Accepted Answer Pending Moderation
  1. Thursday, 9 November 2017 07:25 AM UTC
  2. PowerBuilder
  3. # 1

Hi Mitch,
that is the correct behavior and it happens because you have insufficient privileges to write directly to HKLM. It's called virtualization. You should keep things as they are and write/read from the same HKLM key you are writing to, Windows will transparently redirect for you.
As a background info, HKU contains user-specific configuration information for all logged users and the sequence of dash-separated numbers corresponds to that user SID. The key you wrote gets there because virtualization (google for Windows virtualization).
In essence, 32bit apps (like the PB IDE) will transparently access the appropriate 32bit registry hive, as well as the 64bit will. But you must be explicit when use an application of a different bitness and want to modify the registry (but you should have serious reasons for doing that).

For the sake of completeness, if you actually want to manage 64bit registry from PB, you can declare native RegOpenKeyEx API as local external function and access explicitly the WOW64, see for instance this link: https://stackoverflow.com/questions/10533421/accessing-64-bit-registry-from-32-bit-application/10533865#10533865.

Cheers,
Marco

Comment
Mitch Goldstein
  1. Mitch Goldstein
  2. Thursday, 9 November 2017 13:17 PM UTC
Thanks for the quick response.  I did some more testing.  Still issues with permissions at runtime.  From the IDE this works.  It writes to the registry and then I can read it back.



gs_regpath="HKEY_LOCAL_MACHINE\Software\WOW6432Node\"

li_ret=RegistrySet(gs_regpath + "\Min-U-Script", "regtest", RegString!, "test " + string(now(),"hh:mm"))

li_ret=RegistryGet(gs_regpath + "\Min-U-Script", "regtest", RegString!, ls_regtest)

MessageBox("debug",ls_regtest)



When I run this from the exe, it fails.  I get a -1 returned.  If I run my exe as administrator, then it writes and reads.  If I then run again, not as administrator, then it only reads, but fails on the write.  So can I no longer write to the registry when not running as administrator?  Additionally, it does not seem to matter if I have the path as:



gs_regpath="HKEY_LOCAL_MACHINE\Software\WOW6432Node\" 



or



gs_regpath="HKEY_LOCAL_MACHINE\Software\"



Thanks,



Mitch



 

  1. Helpful
Olan Knight
  1. Olan Knight
  2. Thursday, 9 November 2017 20:21 PM UTC
Mitch -

   That is correct; you must have ADMIN rights in order to write directly to the non-virtual sections of the Windows Registry.



Olan

  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.