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:
The results: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";}
$VAR1 = 48120353; Empty Table Created. $VAR1 = "!B\336\2\0\0\0\0"; I know how to pack this table.
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:
What I get it's the famous "Segmentation fault (core dumped)".# 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");
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,
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).#ifdef MYTABLE_EXPORTS # define MYTABLE __declspec(dllexport) #else # define MYTABLE __declspec(dllimport) #endif MYTABLE enum cStatus myTableLoadFromFile(char const* filename, myTable +* raw_result);
In reply to Re^6: WIN32::API and void*
by sgv_81
in thread WIN32::API and void*
by sgv_81
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |