Win32::API::Struct - C struct support package for Win32::API |
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 the Win32::API manpage 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.
typedef NAME, TYPE, MEMBER, TYPE, MEMBER, ...
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 the Win32::API::Type manpage
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 the Win32::API manpage automatically knows that an 'LPNAME' type, refers to a 'NAME' type struct. Also see typedef in the Win32::API::Type manpage 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
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).
sizeof
align [SIZE]
SIZE
of 'auto'
should keep the world happy.
tie
INTERFACEInstead 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:
# tied # non-tied $Point{x} vs. $Point->{x}
print $Point{z}; # this will warn: 'z' is not a member of Win32::API::Struct POINT
# 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 the perlfunc manpage, ReadMemory in the Win32::API manpage and WriteMemory in the Win32::API manpage around the pointer.
Aldo Calpini ( dada@perl.it ).
Cosimo Streppone ( cosimo@cpan.org ).
Win32::API::Struct - C struct support package for Win32::API |