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

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". ;-)

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";
[download]

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

Your presentation is a bit confusing, but it appears to me that it fails the same way both times. So you provide no evidence that "2 times" has anything to do with your problem.

My guess is simply that CurrentVersion is a subkey of LMachine/Software/ActiveState/ActivePerl, not a value. If so, that would make sense why trying to open a value named "CurrentVersion" would give you the "not found" error.