The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.
 / 
Win32-API-0.58
River stage two • 30 direct dependents • 34 total dependents
9 ++
/ Win32::API

NAME

Win32::API - Perl Win32 API Import Facility

SYNOPSIS

  #### Method 1: with prototype

  use Win32::API;
  $function = Win32::API->new(
      'mydll, 'int sum_integers(int a, int b)',
  );
  $return = $function->Call(3, 2);
  
  #### Method 2: with parameter list
  
  use Win32::API;
  $function = Win32::API->new(
      'mydll', 'sum_integers', 'II', 'I',
  );
  $return = $function->Call(3, 2);
  
  #### Method 3: with Import
 
  use Win32::API;
  Win32::API->Import(
      'mydll', 'int sum_integers(int a, int b)',
  );  
  $return = sum_integers(3, 2);

ABSTRACT

With this module you can import and call arbitrary functions from Win32's Dynamic Link Libraries (DLL), without having to write an XS extension. Note, however, that this module can't do everything. In fact, parameters input and output is limited to simpler cases.

A regular XS extension is always safer and faster anyway.

The current version of Win32::API is always available at your nearest CPAN mirror:

  http://search.cpan.org/dist/Win32-API/

A short example of how you can use this module (it just gets the PID of the current process, eg. same as Perl's internal $$):

    use Win32::API;
    Win32::API->Import("kernel32", "int GetCurrentProcessId()");
    $PID = GetCurrentProcessId();

The possibilities are nearly infinite (but not all are good :-). Enjoy it.

DESCRIPTION

To use this module put the following line at the beginning of your script:

    use Win32::API;

You can now use the new() function of the Win32::API module to create a new Win32::API object (see "IMPORTING A FUNCTION") and then invoke the Call() method on this object to perform a call to the imported API (see "CALLING AN IMPORTED FUNCTION").

Starting from version 0.40, you can also avoid creating a Win32::API object and instead automatically define a Perl sub with the same name of the API function you're importing. The details of the API definitions are the same, just the call is different:

    my $GetCurrentProcessId = Win32::API->new(
        "kernel32", "int GetCurrentProcessId()"
    );
    my $PID = $GetCurrentProcessId->Call();

    #### vs.

    Win32::API->Import("kernel32", "int GetCurrentProcessId()");
    $PID = GetCurrentProcessId();

Note that Import returns 1 on success and 0 on failure (in which case you can check the content of $^E).

IMPORTING A FUNCTION

You can import a function from a 32 bit Dynamic Link Library (DLL) file with the new() function. This will create a Perl object that contains the reference to that function, which you can later Call().

What you need to know is the prototype of the function you're going to import (eg. the definition of the function expressed in C syntax).

Starting from version 0.40, there are 2 different approaches for this step: (the preferred) one uses the prototype directly, while the other (now deprecated) one uses Win32::API's internal representation for parameters.

IMPORTING A FUNCTION BY PROTOTYPE

You need to pass 2 parameters:

  1. The name of the library from which you want to import the function.

  2. The C prototype of the function.

When calling a function imported with a prototype, if you pass an undefined Perl scalar to one of its arguments, it will be automatically turned into a C NULL value.

See Win32::API::Type for a list of the known parameter types and Win32::API::Struct for information on how to define a structure.

IMPORTING A FUNCTION WITH A PARAMETER LIST

You need to pass 4 parameters:

1. The name of the library from which you want to import the function.
2. The name of the function (as exported by the library).
3. The number and types of the arguments the function expects as input.
4. The type of the value returned by the function.
5. And optionally you can specify the calling convention, this defaults to '__stdcall', alternatively you can specify '_cdecl'.

To better explain their meaning, let's suppose that we want to import and call the Win32 API GetTempPath(). This function is defined in C as:

    DWORD WINAPI GetTempPathA( DWORD nBufferLength, LPSTR lpBuffer );

This is documented in the Win32 SDK Reference; you can look for it on the Microsoft's WWW site, or in your C compiler's documentation, if you own one.

1.

The first parameter is the name of the library file that exports this function; our function resides in the KERNEL32.DLL system file.

When specifying this name as parameter, the .DLL extension is implicit, and if no path is given, the file is searched through a couple of directories, including:

1. The directory from which the application loaded.
2. The current directory.
3. The Windows system directory (eg. c:\windows\system or system32).
4. The Windows directory (eg. c:\windows).
5. The directories that are listed in the PATH environment variable.

So, you don't have to write C:\windows\system\kernel32.dll; only kernel32 is enough:

    $GetTempPath = new Win32::API('kernel32', ...
2.

Now for the second parameter: the name of the function. It must be written exactly as it is exported by the library (case is significant here). If you are using Windows 95 or NT 4.0, you can use the Quick View command on the DLL file to see the function it exports. Remember that you can only import functions from 32 bit DLLs: in Quick View, the file's characteristics should report somewhere "32 bit word machine"; as a rule of thumb, when you see that all the exported functions are in upper case, the DLL is a 16 bit one and you can't use it. If their capitalization looks correct, then it's probably a 32 bit DLL.

Also note that many Win32 APIs are exported twice, with the addition of a final A or W to their name, for - respectively - the ASCII and the Unicode version. When a function name is not found, Win32::API will actually append an A to the name and try again; if the extension is built on a Unicode system, then it will try with the W instead. So our function name will be:

    $GetTempPath = new Win32::API('kernel32', 'GetTempPath', ...

In our case GetTempPath is really loaded as GetTempPathA.

3.

The third parameter, the input parameter list, specifies how many arguments the function wants, and their types. It can be passed as a single string, in which each character represents one parameter, or as a list reference. The following forms are valid:

    "abcd"
    [a, b, c, d]
    \@LIST

But those are not:

    (a, b, c, d)
    @LIST

The number of characters, or elements in the list, specifies the number of parameters, and each character or element specifies the type of an argument; allowed types are:

I: value is an integer (int)
N: value is a number (long)
F: value is a floating point number (float)
D: value is a double precision number (double)
C: value is a char (char)
P: value is a pointer (to a string, structure, etc...)
S: value is a Win32::API::Struct object (see below)
K: value is a Win32::API::Callback object (see Win32::API::Callback)

Our function needs two parameters: a number (DWORD) and a pointer to a string (LPSTR):

    $GetTempPath = new Win32::API('kernel32', 'GetTempPath', 'NP', ...
4.

The fourth and final parameter is the type of the value returned by the function. It can be one of the types seen above, plus another type named V (for void), used for functions that do not return a value. In our example the value returned by GetTempPath() is a DWORD, so our return type will be N:

    $GetTempPath = new Win32::API('kernel32', 'GetTempPath', 'NP', 'N');

Now the line is complete, and the GetTempPath() API is ready to be used in Perl. Before calling it, you should test that $GetTempPath is defined, otherwise either the function or the library could not be loaded; in this case, $! will be set to the error message reported by Windows. Our definition, with error checking added, should then look like this:

    $GetTempPath = new Win32::API('kernel32', 'GetTempPath', 'NP', 'N');
    if(not defined $GetTempPath) {
        die "Can't import API GetTempPath: $!\n";
    }

CALLING AN IMPORTED FUNCTION

To effectively make a call to an imported function you must use the Call() method on the Win32::API object you created. Continuing with the example from the previous paragraph, the GetTempPath() API can be called using the method:

    $GetTempPath->Call(...

Of course, parameters have to be passed as defined in the import phase. In particular, if the number of parameters does not match (in the example, if GetTempPath() is called with more or less than two parameters), Perl will croak an error message and die.

The two parameters needed here are the length of the buffer that will hold the returned temporary path, and a pointer to the buffer itself. For numerical parameters, you can use either a constant expression or a variable, while for pointers you must use a variable name (no Perl references, just a plain variable name). Also note that memory must be allocated before calling the function, just like in C. For example, to pass a buffer of 80 characters to GetTempPath(), it must be initialized before with:

    $lpBuffer = " " x 80;

This allocates a string of 80 characters. If you don't do so, you'll probably get Runtime exception errors, and generally nothing will work. The call should therefore include:

    $lpBuffer = " " x 80;
    $GetTempPath->Call(80, $lpBuffer);

And the result will be stored in the $lpBuffer variable. Note that you don't need to pass a reference to the variable (eg. you don't need \$lpBuffer), even if its value will be set by the function.

A little problem here is that Perl does not trim the variable, so $lpBuffer will still contain 80 characters in return; the exceeding characters will be spaces, because we said " " x 80.

In this case we're lucky enough, because the value returned by the GetTempPath() function is the length of the string, so to get the actual temporary path we can write:

    $lpBuffer = " " x 80;
    $return = $GetTempPath->Call(80, $lpBuffer);
    $TempPath = substr($lpBuffer, 0, $return);

If you don't know the length of the string, you can usually cut it at the \0 (ASCII zero) character, which is the string delimiter in C:

    $TempPath = ((split(/\0/, $lpBuffer))[0];  
    # or    
    $lpBuffer =~ s/\0.*$//;

USING STRUCTURES

Starting from version 0.40, Win32::API comes with a support package named Win32::API::Struct. The package is loaded automatically with Win32::API, so you don't need to use it explicitly.

With this module you can conveniently define structures and use them as parameters to Win32::API functions. A short example follows:

    # the 'POINT' structure is defined in C as:
    #     typedef struct {
    #        LONG  x;
    #        LONG  y;
    #     } POINT;
    

    #### define the structure
    Win32::API::Struct->typedef( POINT => qw{
        LONG x; 
        LONG y; 
    });
    
    #### import an API that uses this structure
    Win32::API->Import('user32', 'BOOL GetCursorPos(LPPOINT lpPoint)');
    
    #### create a 'POINT' object
    my $pt = Win32::API::Struct->new('POINT');
    
    #### call the function passing our structure object
    GetCursorPos($pt);
    
    #### and now, access its members
    print "The cursor is at: $pt->{x}, $pt->{y}\n";

Note that this works only when the function wants a pointer to a structure: as you can see, our structure is named 'POINT', but the API used 'LPPOINT'. 'LP' is automatically added at the beginning of the structure name when feeding it to a Win32::API call.

For more information, see also Win32::API::Struct.

If you don't want (or can't) use the Win32::API::Struct facility, you can still use the low-level approach to use structures:

  1. you have to pack() the required elements in a variable:

        $lpPoint = pack('LL', 0, 0); # store two LONGs

  2. to access the values stored in a structure, unpack() it as required:

        ($x, $y) = unpack('LL', $lpPoint); # get the actual values

The rest is left as an exercise to the reader...

AUTHOR

Aldo Calpini ( dada@perl.it ).

MAINTAINER

Cosimo Streppone ( cosimo@cpan.org )

LICENSE

To finally clarify this, Win32::API is OSI-approved free software; you can redistribute it and/or modify it under the same terms as Perl itself.

See http://dev.perl.org/licenses/artistic.html

CREDITS

All the credits go to Andrea Frosini for the neat assembler trick that makes this thing work. I've also used some work by Dave Roth for the prototyping stuff. A big thank you also to Gurusamy Sarathy for his unvaluable help in XS development, and to all the Perl community for being what it is.

Cosimo also wants to personally thank everyone that contributed to Win32::API with complaints, emails, patches, RT bug reports and so on.