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
    ALPHA Systems
    Marly, Switzerland
    mark-allen_AT_mvps_DOT_org
    Mark-Allen Perry, Jun 14, 2005
    #1
    1. Advertising

  2. Mark-Allen Perry

    Philip Sloss Guest

    "Mark-Allen Perry" <mark-allen@mvps_dot_org> wrote in message
    news:%...
    > 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


    Have you tried manually reflecting that key with RegEnableReflectionKey?

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

  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
    ALPHA Systems
    Marly, Switzerland
    mark-allen_AT_mvps_DOT_org


    "Philip Sloss" <> wrote in message
    news:...
    > "Mark-Allen Perry" <mark-allen@mvps_dot_org> wrote in message
    > news:%...
    > > 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

    >
    > Have you tried manually reflecting that key with RegEnableReflectionKey?
    >
    > Philip Sloss
    >
    >
    Mark-Allen Perry, Jun 14, 2005
    #3
  4. Mark-Allen Perry

    Philip Sloss Guest

    "Mark-Allen Perry" <mark-allen@mvps_dot_org> wrote in message
    news:%...
    >> 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?


    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
    ALPHA Systems
    Marly, Switzerland
    mark-allen_AT_mvps_DOT_org


    "Philip Sloss" <> wrote in message
    news:...
    > "Mark-Allen Perry" <mark-allen@mvps_dot_org> wrote in message
    > news:%...
    > >> 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?

    >
    > 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
    >
    >
    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
    ALPHA Systems
    Marly, Switzerland
    mark-allen_AT_mvps_DOT_org


    "Mark-Allen Perry" <mark-allen@mvps_dot_org> wrote in message
    news:%...
    > 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
    > ALPHA Systems
    > Marly, Switzerland
    > mark-allen_AT_mvps_DOT_org
    >
    >
    > "Philip Sloss" <> wrote in message
    > news:...
    > > "Mark-Allen Perry" <mark-allen@mvps_dot_org> wrote in message
    > > news:%...
    > > >> 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?

    > >
    > > 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
    > >
    > >

    >
    >
    Mark-Allen Perry, Jun 14, 2005
    #6
  7. Re: Unusual Referencing of the Registry between 32-bit and 64-bitapps

    Have you looked into using RegDisableReflectionKey()?

    See:
    http://msdn.microsoft.com/library/d...n-us/sysinfo/base/regdisablereflectionkey.asp

    Rafael Rivera
    Extended64 | http://www.extended64.com
    Blog | http://www.extended64.com/blogs/Rafael

    Mark-Allen Perry wrote:
    > 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,
    >
    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


    "Rafael Rivera [Extended64.com]" <rafael*at*extended64*dot*com> wrote in
    message news:...
    > Have you looked into using RegDisableReflectionKey()?
    >
    > See:
    >

    http://msdn.microsoft.com/library/d...n-us/sysinfo/base/regdisablereflectionkey.asp
    >
    > Rafael Rivera
    > Extended64 | http://www.extended64.com
    > Blog | http://www.extended64.com/blogs/Rafael
    >
    > Mark-Allen Perry wrote:
    > > 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 15, 2005
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    390
  2. Pamela Fischer
    Replies:
    11
    Views:
    1,689
  3. The Master of The Known Universe

    Top 3 firewalls, anti-virus apps, anti-spyware apps

    The Master of The Known Universe, May 9, 2006, in forum: Computer Support
    Replies:
    10
    Views:
    1,024
    clouds
    May 13, 2006
  4. Willy David Jr
    Replies:
    3
    Views:
    2,393
    Willy David Jr
    Jan 9, 2007
  5. london1919
    Replies:
    1
    Views:
    2,877
    Lawrence Garvin \(MVP\)
    Dec 8, 2008
Loading...

Share This Page