Win32::API::Struct - C struct support package for Win32::API


  use Win32::API;
  Win32::API::Struct->typedef( 'POINT', qw(
    LONG x; 
    LONG y; 
  my $Point = Win32::API::Struct->new( 'POINT' ); 
  $Point->{x} = 1024;
  $Point->{y} = 768;

  #### alternatively
  tie %Point, 'Win32::API::Struct', 'POINT';
  $Point{x} = 1024;
  $Point{y} = 768;


This module enables you to define C structs for use with Win32::API.

See "USING STRUCTURES" in Win32::API for more info about its usage.


This module is automatically imported by Win32::API, so you don't need to 'use' it explicitly. The main methods are typedef and new, which are documented below.


This method defines a structure named NAME. The definition consists of types and member names, just like in C. In fact, most of the times you can cut the C definition for a structure and paste it verbatim to your script, enclosing it in a qw() block. The function takes care of removing the semicolon after the member name. Win32::API::Struct does NOT support Enums, Unions, or Bitfields. NAME must not end in *, typedef creates structs, not struct pointers. See "typedef" in Win32::API::Type on how to create a struct pointer type. Returns true on success, and undef on error. On error it warns with the specific reason.

The synopsis example could be written like this:

  Win32::API::Struct->typedef('POINT', 'LONG', 'x', 'LONG', 'y');

But it could also be written like this (note the indirect object syntax), which is pretty cool:

  typedef Win32::API::Struct POINT => qw{
    LONG x; 
    LONG y; 

"Call" in Win32::API automatically knows that an 'LPNAME' type, refers to a 'NAME' type struct. Also see "typedef" in Win32::API::Type on how to declare pointers to struct types.

Unlike in Win32::API, a single non-array char or CHAR struct member in a struct is numeric, NOT the first character of a string. UTF16 strings pointers will be garbage on read back (passing in works, returning doesn't) since the NULL character will often be the 2nd byte of the UTF16 string.

new NAME

This creates a structure (a Win32::API::Struct object) of the type NAME (it must have been defined with typedef). In Perl, when you create a structure, all the members are undefined. But when you use that structure in C (eg. a Win32::API call), you can safely assume that they will be treated as zero (or NULL).


This returns the size, in bytes, of the structure. Acts just like the C function of the same name. It is particularly useful for structures that need a member to be initialized to the structure's own size.

align [SIZE]

Sets or returns the structure alignment (eg. how the structure is stored in memory). This is a very advanced option, and you normally don't need to mess with it. All structures in the Win32 Platform SDK should work without it. But if you define your own structure, you may need to give it an explicit alignment. In most cases, passing a SIZE of 'auto' should keep the world happy.


Instead of creating an object with the new method, you can tie a hash, which will hold the desired structure, using the tie builtin function:

  tie %structure, Win32::API::Struct => 'NAME';

The differences between the tied and non-tied approaches are:

  • with tied structures, you can access members directly as hash lookups, eg.

      # tied              # non-tied
      $Point{x}    vs.    $Point->{x}
  • with tied structures, when you try to fetch or store a member that is not part of the structure, it will result in a warning, eg.

      print $Point{z};
      # this will warn: 'z' is not a member of Win32::API::Struct POINT
  • when you pass a tied structure as a Win32::API parameter, remember to backslash it, eg.

      # tied                            # non-tied
      GetCursorPos( \%Point )    vs.    GetCursorPos( $Point )


Using Win32::API::Struct is not recommended in situations where a C function will return results to you by putting a pointer to a string or a pointer to another struct into your supplied struct. Win32::API::Struct will do its best to detect that a new pointer appeared and to read it contents into Perl, but that pointer will be tossed away after being read. If this pointer is something you must explicitly free, you have leaked it by using Win32::API::Struct to decode it. If this pointer is something you must pass back to the C API you are using, you lost/leaked it. If you pass NULL, or a ::Struct pointer in a ::Struct to C API, after the C API call, ::Struct will detect the pointer changed, it will read the new struct from the new pointer into Perl, and a new child ::Struct will appear in the hash slice of the parent ::Struct, if you pass this new child ::Struct into the C API it will be a COPY of the struct the C API from Perl's allocation placed in the parent ::Struct. For C++-like APIs, this will be unacceptable and lead to crashes as the C Functions tries to free a memory block that didn't come from the allocator of the C Function. Windows has many memory allocators, each CRT (VS 2, 3, 4, 5, NT/6, 7.0, 7.1, 8, 9, 10) malloc, LocalAlloc, GlobalAlloc, HeapAlloc, (each version of C++ Runtime Library) "new", CoGetMalloc, CoTaskMemAlloc, NetApiBufferAllocate, VirtualAlloc, CryptMemAlloc, AllocADsMem, SHAlloc, SnmpUtilMemAlloc. None of these allocators' pointers are compatible with Perl's allocator. Some C APIs give you static global buffers which never are freed or freed automatically in the next call to a function from to that DLL.

With foreign allocators, its best to treat to write a pointer class, bless the ref to scalar integer (holding the pointer) into that class to ensure that the DESTROY method will free the pointer and you never leak it, and your write method accessors using "pack" in perlfunc, "ReadMemory" in Win32::API and "WriteMemory" in Win32::API around the pointer.


Aldo Calpini ( ).


Cosimo Streppone ( ).