Unusual Referencing of the Registry between 32-bit and 64-bit apps

Discussion in 'Windows 64bit' started by Mark-Allen Perry, Jun 14, 2005.

  1. To all:

    Our team has discovered another strange referencing issue, this time with
    the Registry between 32-bit and 64-bit. I am wondering if others also see
    this and what their workaround is.

    If you run a script or application under a 64-bit context and create a key
    under HKLM, it appears as normal.
    Example: HKLM\Software\Test64

    If you execute Regedit under a 32-bit context, the key does not exist.

    I believe this is due to the 32-bit Registry being mapped to
    HKLM\Software\WOW6432Node.

    We confirmed which bit versions were running by checking the Task Manager.
    TaskMan displays 32-bit apps with an extension of "*32". 64-bit apps do not
    have this extension.

    So, my question is: if we run applications, scripts, HTAs, etc under 64-bit
    and then have some applications that are NOT 64-bit aware but require access
    to these Registry areas, how do we manage this?

    One simple solution would be to always write to the \WOW6432Node area of the
    Registry. However, this defeats the purpose of going towards 64-bit.

    Any help would be much appreciated.
     
    Mark-Allen Perry, Jun 14, 2005
    #1
    1. Advertisements

  2. Mark-Allen Perry

    Philip Sloss Guest

    Have you tried manually reflecting that key with RegEnableReflectionKey?

    Philip Sloss
     
    Philip Sloss, Jun 14, 2005
    #2
    1. Advertisements

  3. Have you tried manually reflecting that key with RegEnableReflectionKey?

    No. I've never heard of that. I'll Google it right now but have you got
    more information?

    many thanks,
     
    Mark-Allen Perry, Jun 14, 2005
    #3
  4. Mark-Allen Perry

    Philip Sloss Guest

    I haven't tried it myself, I'm just aware of the documentation -- it's in
    the online MSDN Library. Browsing through it, I also find this:
    http://msdn.microsoft.com/library/en-us/win64/win64/accessing_an_alternate_registry_view.asp

    Which suggests that the KEY_WOW64_64KEY flag might also work without manual
    reflection...

    The whole WOW64 section might be useful:
    http://msdn.microsoft.com/library/en-us/win64/win64/running_32_bit_applications.asp

    Philip Sloss
     
    Philip Sloss, Jun 14, 2005
    #4
  5. Excellent. I've gone through the pages and it appears to do what is needed.
    However...

    We have developed an automated system build process with HTAs, WSFs, and VBS
    scripts, which work on both the 32-bit systems and 64-bit systems. But
    we're seeing registry differences when we go to look after we've written
    something. It's not where it's supposed to be; i.e. written by 64-bit and
    can't be seen by 32-bit, and vice versa.

    And the function calls that are described are based on C code (or a
    derivative thereof.) It will not work for script code since library
    handling is difficult if not impossible.

    But I'm going to run some tests and see what I can do with a basic test
    script.

    If anyone can assist in this problem using scripts, it would be well
    appreciated.

    Many thanks for all your help.
     
    Mark-Allen Perry, Jun 14, 2005
    #5
  6. I've written a VBS script that determines what architecture (x86, AMD64,
    etc.) and what platform (64 or 32-bit). It creates a key with these two
    values and writes it to the Registry; HKLM\Software\{new key}.

    As expected, writing under a 32-bit context does NOT write to the same place
    as under a 64-bit context. Using a 64-bit RegEdit.exe, I can see the 64-bit
    key as expected, and under \Wow6432Node, I see the 32-bit key.

    Since this difficulty is compounded by an .HTA running only the 32-bit
    MSHTA.exe, what happens when the HTA executes a WSF or VBS script? Which
    bit version? And if we execute CMD.EXE via any of these methods, what
    version runs?

    Very confusing, to say the least. Does you have some ideas about how to
    stay in 64-bit under all conditions?

    many thanks for your help,
     
    Mark-Allen Perry, Jun 14, 2005
    #6
  7. Rafael Rivera [Extended64.com], Jun 15, 2005
    #7
  8. Thanks, Rafael.

    But what I desire is the functionality to write to the 64-bit area of the
    Registry from SCRIPTS, i.e. HTA, VBS, or WSF.

    From what I gather on the MSDN pages, these functions are available under
    C++++, maybe VB, but NOT scripts. There is no MS-approved method to
    reference libraries from scripts.

    Thinking about this problem last night, I imagined a new Registry hive key
    like, HKEY_LOCAL_MACHINE64, which would be available to 32-bit apps that
    points to the top of the 64-bit hive. This would solve all our problems.

    Ok, it appears that MS has again dropped the ball because this is only one
    of many issues we're having with discrepancies between 32-bit and 64-bit on
    an x64 machine. These issues aren't related to hardware, as we're using HP
    but in developing world-class software, especially a system build process
    that works across 32 and 64-bit systems.

    If you can think of anything that works under scripts, it would be well
    appreciated.

    Many thanks for all your help.

    --
    Mark-Allen Perry
    ALPHA Systems
    Marly, Switzerland
    mark-allen_AT_mvps_DOT_org
     
    Mark-Allen Perry, Jun 15, 2005
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.