Thanks. It seems that using your version would mean a lot less of a headache for me, unfortunately, the script won't be running on my machine, and its owner/admin has pushed for this version of WIN32::API. Probably with the only aim of making my existance a little bit more challenging... So, I'm going to try to make the script work with HANDLES and LPHANDLES.

IMHP myTableCreate basically returns a "HANDLE" in Win32 API speak, or a void * in C: Which basicly means that the way to properly declare myTableCreate() is:  my $CreateTable = new Win32::API("ctbl_v2.dll","HANDLE cTblCreate()"); And $CreateTable will hold the HANDLE of the new empty table.

This is how I've put together the perl code so far:

#! /usr/bin/perl
use Win32::API;

# Load the table creator from the dll.
# Some info about the API function:
# C signature: __declspec(dllimport) myTable myTableCreate();
# typedef
# struct myTable { 
# void* opaque;  ///< Opaque pointer to storage
# } myTable;
$pass = 1;
my $CreateTable = new Win32::API("myDll.dll","HANDLE myTableCreate()")
+;
if(not defined $CreateTable) {
        die "Can't import API myTableCreate(): $!\n";
}
$pass = $pass && defined($CreateTable->Call()) == 1;
#Create an empty table.
if($pass) 
{
    $aTable = $CreateTable->Call();
    print("Table Created"); 
}
else
{
die "Cant Create a Table";
}
[download]

This code at least doesn't crash and prints "Table Created". I have ignored the "pack" and "unpack" calls since the API function returns a HANDLER directly. Let me know if I got this wrong.

Let's try to "fill" the table with data from a file using the API function int myTableLoadFromFile(*char filename, myTable* raw_result). It seems that raw_result will be a void**, probably for the reasons you pointed out. Using some fuzzy logic I've determined that must be LPHANDLER (pointer to myTable, hence pointer to HANDLER, hence LPHANDLER).

About the whole packing and unpacking of the handlers before passing them out, I'm not sure whether I should pack $aTable or not. I understand that because it's the value returned by an API function, $aTable should already be stored with the appropiate format (unless there is any transformation behind the scenes before perl stores its value).

I have packed the string with the file path since in the header files it's advised that the string containing the filename has to be null terminated (I've checked http://perldoc.perl.org/functions/pack.html and sounds like a pack('Z', string) to me).

my $LoadTableFromFile = new Win32::API("myDll.dll","int myTableLoadFro
+mFile(char* filename, LPHANDLE raw_result)");
if(not defined $LoadTableFromFile) {
        die "Can't import API HANDLELoadFromFile(): $!\n";
 }
my $pathTable = 'C:/Temp/Requests/TestTable.TBL';
$pathTable = pack('Z',$pathTable);
$pass = 1;
$pass = $pass && defined($LoadTableFromFile->Call($pathTable,$aTable))
+ == 1;
if($pass)
{
    my $isLoaded = $LoadTableFromFile->Call($pathTable,$aTable);
    print("Table loaded");
}
else
{
    die "Can't load the table from the file $pathTable";
}
[download]

Something isn't right since I get a "Segmentation fault (core dumped)" error. Which means I'm not passigng the correct arg for LPHANDLER raw_result. I've tried to "$aTable=pack('J',$aTable);" before passing it to myTableLoadfromFile, but I still get the same error. Any idea what I'm missing?

$pass = $pass && defined($CreateTable->Call()) == 1;
[download]

You probably leaked a table. Do doing the Call() means you run the C function and the defined check is meaningless since the result will be 0 (probably NULL pointer/failure for the C function) or a pointer (12345 format), never undefined. Check defined only on $CreateTable API obj. I posted code from a test suite of Win32::API, you need to change it a little bit more.

    $aTable = $CreateTable->Call();
    print("Table Created");
[download]

Correct, try printing $aTable to the screen, I prefer Data::Dumper.

use Data::Dumper;
$Data::Dumper::Useqq = 1;
print Dumper($aTable);
[download]

$aTable should be a decimal number, 123456 style. "HANDLER" isn't a C or Win32 API type. Its "HANDLE". If you tried HANDLER you should be getting warnings printed to console, but I'm not sure if 0.68 will report unknown types or not.

About the whole packing and unpacking of the handlers before passing them out, I'm not sure whether I should pack $aTable or not. I understand that because it's the value returned by an API function, $aTable should already be stored with the appropiate format (unless there is any transformation behind the scenes before perl stores its value).

"appropiate format", no its not. Thats why 0.68 sucks.

I have packed the string with the file path since in the header files it's advised that the string containing the filename has to be null terminated (I've checked http://perldoc.perl.org/functions/pack.html and sounds like a pack('Z', string) to me).

Useless, all scalar strings in perl are automatically null terminated at all times secretly so they can be passed to OS/library C function that want null terminated (even if you feed binary garbage to the C function, the C function will hit a null in your binary garbage, or hit the secret null, either way, it will never buffer overflow. This is a ansi/ascii null, not a UTF16 null, if your doing UTF16 in perl, you need to write "\x00\x00" yourself. The secret null character never appears in the perl language, so if you put the scalar to disk, or through a network, then you need to add the null yourself with pack or

.= "\x00";
[download]

Something isn't right since I get a "Segmentation fault (core dumped)" error. Which means I'm not passigng the correct arg for LPHANDLER raw_result. I've tried to "$aTable=pack('J',$aTable);" before passing it to myTableLoadfromFile, but I still get the same error. Any idea what I'm missing?

The pack J is what your missing. After you pack $aTable, do a print Dumper on it, it should be 4 or character, some of the characters might be in "\123" octal escape sequence since they are unprintable binary. You can also try

$packedaTable = pack('J', $aTable);
die "bad code" if unpack('J', $packedaTable) != $aTable;
[download]

you can also scrap the C prototype interface of Win32 API and use the letter interface.

my $LoadTableFromFile = new Win32::API("myDll.dll","int myTableLoadFro
+mFile(char* filename, LPHANDLE raw_result)");
[download]

becomes

my $LoadTableFromFile = new Win32::API("myDll.dll", "myTableLoadFromFi
+le", 'PP', 'I');
[download]

Final question, are you on 32 bits or 64 bit windows and what is the calling convention of your C functions? I think you have cdecl functions, since a no parameter stdcall and a no parameter cdecl are interchangable and identical under the hood, so whats might be why create doesn't crash, but myTableLoadFromFile does.

Regarding the pack J, you can't remove it. Reread my last post, your forgetting the difference between a HANDLE and a LPHANDLE on API 0.68.

I've printed the Dumper, and I think it's encoraging to know that I get 48120353 after aTableCreate is called. The table J-packs to !B\336\2\0\0\0\0 and unpacks to the original table.

All together the create section of the code becomes:

my $CreateTable = new Win32::API("myDll.dll","HANDLE myTableCreate()")
+;
 if(not defined $CreateTable) {
        die "Can't import API myTableCreate(): $!\n";
}
#Create an empty tables.

$aTable = $CreateTable->Call();
use Data::Dumper;
$Data::Dumper::Useqq = 1;
print Dumper($aTable);
print("Empty Table Created.\n");

# pack the table.
my $packedaTable = pack('J',$aTable);
print Dumper($packedaTable);
if(unpack('J',$packedaTable) == $aTable) 
    {print "I know how to pack this table.\n";}
else
    {die "I dont know how to pack this table";}
[download]

The results:

$VAR1 = 48120353;
Empty Table Created.
$VAR1 = "!B\336\2\0\0\0\0";
I know how to pack this table.
[download]

Well that sounds good to me (ignoring ! it's and array of blocks of chars or blocks of 1 or 3 integers). There is something created at least. Let's carry on with the loading. After some changes:

# aTable Path
my $pathATable = 'C:/Temp/Requests/testTable.TBL';
# Load the function.
my $LoadTableFromFile = new Win32::API("myDll.dll","myTableLoadFromFil
+e", 'PP', 'I');
if(not defined $LoadTableFromFile) {
        die "Can't import API myTableLoadFromFile(): $!\n";
 }
my $isLoaded = $LoadTableFromFile->Call($pathATable,$packedaTable);
print("Table loaded");
[download]

What I get it's the famous "Segmentation fault (core dumped)".

Regarding the pack J, you can't remove it. Reread my last post, your forgetting the difference between a HANDLE and a LPHANDLE on API 0.68. What I've understood it's that LPHANDLE is treated as a pointer to a string, and has to be packed to get a \xAB\xCD\xED\x00 format. While HANDLE is a number. Well in my case twice, since I'm using a Win64 machine. This time I've pased $packedaTable. I don't feel terribly confident about this part, so if you think I'm missing something, please point it out.

Final question, are you on 32 bits or 64 bit windows and what is the calling convention of your C functions? I think you have cdecl functions, since a no parameter stdcall and a no parameter cdecl are interchangable and identical under the hood, so whats might be why create doesn't crash, but myTableLoadFromFile does. Well, my machine is 64 bits. You think that's the issue?. About the calling convention, In the header file of the library there isn't any explicit reference to the calling convention for passing parameters. There is only a reference to the "storage class" with __declspec. For example for myTableLoadFromFile,

#ifdef MYTABLE_EXPORTS
#   define MYTABLE __declspec(dllexport)
#else
#   define MYTABLE __declspec(dllimport)
#endif
MYTABLE enum cStatus myTableLoadFromFile(char const* filename, myTable
+* raw_result);
[download]

But I agree, it's pretty suspicious that it seems to work when we needn't pass any parameter (as in myTableCreate) and breaks if we pass them (myTableLoadTableFromFile).