Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Win32API::Registry -- RegOpenKeyEx fails when called 2 times.

by afoken (Chancellor)
on Mar 12, 2010 at 13:37 UTC ( [id://828290]=note: print w/replies, xml ) Need Help??


in reply to Win32API::Registry -- RegOpenKeyEx fails when called 2 times.

Two quotes from the very beginning of the Win32::Registry documentation:

obsolete, use Win32::TieRegistry

and

NOTE: This module provides a very klunky interface to access the Windows registry, and is not currently being developed actively. It only exists for backward compatibility with old code that uses it. For more powerful and flexible ways to access the registry, use Win32::TieRegistry.

So, why don't you just use Win32::TieRegistry?

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
  • Comment on Re: Win32API::Registry -- RegOpenKeyEx fails when called 2 times.

Replies are listed 'Best First'.
Re^2: Win32API::Registry -- RegOpenKeyEx fails when called 2 times. (our 2^H3 main weapons)
by tye (Sage) on Mar 13, 2010 at 07:27 UTC

    Heh. That's funny. You are quoting Win32::Registry documentation to somebody who is using Win32API::Registry. So, understandably, most of what you quoted doesn't apply very well here.

    But much of what you quoted may appear to apply here (and the spirit of your advice is certainly reasonable), so let's use this as an opportunity to spread some knowledge about the Perl Win32 Registry modules.

    This module provides a very klunky interface

    The interface Win32API::Registry provides is substantially similar to that of Win32::Registry and is certainly, at least in some ways, more clunky than the interface of Win32::TieRegistry. But the interface of Win32API::Registry is basically just the Microsoft interface.

    The main difference between Win32::Registry and Win32API::Registry (and the reason for the "API" in the name) is that the latter sticks very closely to the underlying interface (for several important reasons). One big reason is to prevent a common problem I find in so many XS modules, that of the XS module being (sometimes significantly) less powerful than the underlying interface that the module is supposed to be wrapping and/or exposing. The only "use" of the included API calls that I allowed myself to prevent was causing a "core dump" (a dated term from a different operating system but still the one I prefer as a generic term for what happens when a process violates basic sanity rules and the operating system is forced to "take it down" for everybody's protection).

    I was actually able to use the Win32API::Registry's interface to explore the Microsoft Registry interface very thoroughly in order to fill in details about the underlying interface that were undocumented, vaguely documented, or confusingly documented by Microsoft. My documentation for Win32API::Registry should have been mostly a transcription of Microsoft's documentation, since the interface was nearly identical (very slightly more Perlish) and the same functionality was provided.

    But I found that the number of questions raised by my reading of the Microsoft documentation tended to be on the same order of magnitude as the number of questions answered by it. The Microsoft documentation proved significantly insufficient as a source when writing the module documentation. But I found the Perl debugger and my module together made a very fast and easy playground for exploring the Microsoft interface and answering my own questions.

    and is not currently being developed actively

    To be frank, Win32API::Registry is not under anything close to "active development". And neither is Win32::TieRegistry. I continue to try to change that, having a bunch of fixes and improvements already made that need to be merged together between each other and other changes that have been made to those modules by others who volunteered to patch up some problems (mostly dealing with newer versions of Perl). The work has gotten badly fragmented due to so many moves over the decade-plus.

    It only exists for backward compatibility with old code that uses it.

    There was extra work done to Win32::Registry quite a while after I'd effectively (as far as I was concerned, at least) replaced it. So it isn't just for backward compatibility.

    In contrast, the reason for Win32API::Registry was to provide a full-power tool that could be used to implement a much friendlier (and much more Perlish) tool, Win32::TieRegistry. But Win32API::Registry is still a useful tool in its own right.

    There are several reasons one might choose to use Win32API::Registry instead of or in addition to Win32::TieRegistry. One might already be quite comfortable with the Microsoft interface (despite its pronounced non-Perlish nature). One might be trying to become more comfortable with that interface. And, there are some things that can't be done directly in the friendlier Win32::TieRegistry interface (which, of course, can be done via Win32API::Registry). For that last case, I tend to do the easy steps via TieRegistry and only use Win32API::Registry routines (which can be used via TieRegistry objects) for the particular "advanced" steps.

    For more powerful and flexible ways to access the registry, use Win32::TieRegistry.

    But, barring the above reasons, I agree that one is usually better off just using Win32::TieRegistry.

    - tye        

      Heh. That's funny. You are quoting Win32::Registry documentation to somebody who is using Win32API::Registry.

      <homer>D'oh!</homer> And I was wondering why the version numbers were so different ...

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

        Thanks All for your valuable responses.

        As tye said, my presentation is bit confusing.. So let me try to explain the problem again.

        I have to get the value of one subkey which might be present under wow6432node (e.g. SOFTWARE/Wow6432Node/Microsoft/Internet Explorer) location or under the original 32/64 bit (e.g. SOFTWARE/Microsoft/Internet Explorer) registry. So I had put them in if-else.

        The problem I was facing was, if the first key does not exist then my code (posted on the original thread) is not able to find the second key as well even though it exists at that location.

        The reason behind the problem was, I was relying on the regLastError to decide if 'RegOpenKeyEx' function has returned success or not.

        RegOpenKeyEx( $hKey, $sKey, 0, KEY_READ, $key) or warn "Can't ope +n $hKey\\$sKey: ", regLastError(),"\n"; $error = regLastError(); return "error" if ($error ne "");
        Following code works fine for me now:
        RegOpenKeyEx( $hKey, $sKey, 0, KEY_READ, $key) or warn "Can't ope +n $hKey\\$sKey: ", regLastError(),"\n"; RegQueryValueEx( $key, $sValue, [], $type, $data, [] ) or warn "C +an't read $hKey\\$sKey: ", regLastError(),"\n"; RegCloseKey( $key ) or warn "Can't close $hKey\\$sKey: ", regLastE +rror(),"\n"; chomp($data); return $data;


        Thanks again..
Re^2: Win32API::Registry -- RegOpenKeyEx fails when called 2 times.
by ashah21 (Initiate) on Mar 14, 2010 at 18:18 UTC

    Well I tried Win32::TieRegistry also but it is not working on IA64 machine. While Win32API::Registry is able to get the key values on IA64 machine as well. Not sure if I was missing anything.

    use Win32::TieRegistry( Delimiter=>"#", ArrayValues=>0 ); $pound= $Registry->Delimiter("/"); $swKey= $Registry->{"HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Internet Ex +plorer/"} or die "Can't read LMachine/System/Disk key: $^E\n"; $data= $swKey->{"/Version"} or die "Can't read LMachine/System/Disk// +Information value: $^E\n"; print "\n........data::$data";

    Same code works fine on x86 machine while fails on IA64.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://828290]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2024-04-24 06:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found