develooper Front page | perl.perl5.porters | Postings from July 2003

Re: [PATCH] Extend Win32::GetOSVersion() to return additional information

Michael G Schwern
July 30, 2003 16:42
Re: [PATCH] Extend Win32::GetOSVersion() to return additional information
Message ID:
On Wed, Jul 30, 2003 at 07:43:02AM -0700, Jan Dubois wrote:
> >> +[CORE] Returns the list (STRING, MAJOR, MINOR, BUILD, ID), where the
> ><snip>
> >> +On Windows NT 4 SP6 and later this function returns the following
> ><snip>
> >
> >This is just SCREAMING for a hash.  Perhaps instead of (or in addition to)
> >extending GetOSVersion() you could supply a similar function which returns
> >this information as a hash?
> Why?  This function is pretty similar to POSIX::uname(), which also
> returns everything as a list.  

POSIX::uname() is also screaming for a hash.  So much so that even the C
interface uses a struct!  Using its interface as precedence would simply 
be parroting's translation mistake.

Similar is localtime(), who's C equivalent also uses a hash.  This might 
give you an idea of where my brain is at.  Returning *nine* items which are 
unordered, different, yet related things is what a hash is for.  Quick!  
Without looking at the documentation, is this correct?

    my @date = localtime;
    printf "The year is %d", $date[6] + 1900;

Now, consider an alternative universe:

    my %date = localtime;
    printf "The year is %d", $date->{year} + 1900;

Now consider this:

    my @version_info = Win32::GetOSVersion;
    print "The build number is $version_info[2]";


    my %version_info = Win32::OSVersion;
    print "The build number is $version_info{BuildNumber}";

what is $version_info[2]?  I dunno, I'd have to refer to the documenation
or memorize the ordering.  What is $version_info{BuildNumber}?  Its the
build number of this version of Win32.  Simp. 

Look even at the internal implemenation of Win32::GetOSVersion, all the 
information is stored in a struct!

> Changing Win32::GetOSVersion() is out of
> the question for backward compatibility, I would think.  Just adding the
> additional values to the end of the returned list seems like a good idea
> to me.

I was suggesting you do your patch, add to GetOSVersion's list.  But *also* 
adding an additional function with a better interface and discouraging the 
existing one.

The simplest thign to do is to define a little wrapper with a new
name, say Win32::OSVersion.

    my @OSVersion_Keys = qw(MajorVersion MinorVersion BuildNumber PlatformID
                            ServicePackMajor ServicePackMinor SuiteMask
    sub OSVersion {
        my @version_info = Win32::GetOSVersion;
        return map { ($OSVersion_Keys[$_], $version_info[$_] } @version_info;

I'd give a patch, but I'm not sure where it should go considering the
issue below.

> I think it would be a good idea to move from libwin32 to
> the core to remove this weird interdependency.  Currently the
> documentation in Win32.pod from the core can easily be wrong if you don't
> have the corresponding version of libwin32 installed.

I'd tend to agree, the line between win32.c and libwin32 seems artificial.  
It also looks like libwin32 is practically a necessity to get anything 
interesting done on Win32.  What say, Jarkko of Borg and Sarathy of State?

It's Yellowing Laudanum time! Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About