'int HCE300_Read(int TrackNo(int TrackNo, char *ReadData )');

my @strip = $readdevice->Call(2,\@in);

You cannot pass a perl array, nor a reference to one, using Win32::API. The Read() function is expecting a pointer to a character buffer: char *ReadData and the way to do that is pass a pre-initialised scalar. Also, the function returns a single integer: int HCE300_Read(..., assigning that to a perl array will work, but is pretty pointless.

Something like this might work (but since I don't have that DLL or whatever device it is talking to, I cannot test it):

my $buffer = chr(0) x 2**16; ## Hopefully it won't return more than 64
+K?
my status = $readdevice->Call( 2, $buffer );

### Now check the status and if the call was successful, 
### use the contents of $buffer. Though how you will know 
### how much data the call actually returned is an open question?
[download]

If that also bottles out you could try using a larger buffer. If it still fails, you'll need to know more about the code you are trying to call.

In all seriousness, trying to do this kind of thing with limited C knowledge and no information about the code you are trying to call is an exercise in frustration. For example, if the DLL was compiled using the wrong calling convention, then you will never be able to call it successfully with Win32::API.

Thanks for your help!
Increasing the buffer to 2**128 did not help. The perl interpreter still crashes.

Increasing the buffer to 2**128 did not help. The perl interpreter still crashes.

Attempting to allocate 1,208,925,819,614,629,174,706,176 Yottabytes of ram will have crashed the program long before you ever got around to attempting to call the dll.

2**128 is 3.4028236692093846346337460743177e+38. Which is close to the number of atoms that make up this entire planet, and billions of times more ram than has ever been made. And probably more than ever will be made.

FYI: 2**30 is probably more than you could allocate on your system.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Is the calling convention used by the DLL the same as the one defined by the WINAPI define (__stdcall)?

I use this script

I don't believe you. 'int HCE300_Read(int TrackNo(int TrackNo,char *ReadData )'?

This is the line from the sample C-code:
int HCE300_Read(int TrackNo, char *ReadData);

I have no readable documentation of the dll. The data is read from an usb device. Re-reading the documentation of Win32::API I changed the line to:

my $readdevice = Win32::API->new (
                    'HCE300_API.DLL', 'HCE300_Read','NP','N') or die $
+^E;
if(not defined $readdevice) {
        die "Can't import API HCE_Read: $!\n";
    }
[download]

I am not sure what it does, but it did not help. Perl still crashes.

If int HCE300_Read(int TrackNo, char *ReadData); is the prototype, then it uses the default calling convention. It my understanding that's __cdecl for MS compilers. Win32::API uses the __stdcall calling convention since that's what the Win32 API (kernel32.dll, etc) uses.

	Argument-passing order	Stack-maintenance responsibility
__stdcall	Right to left	Called function pops its own arguments from the stack
__cdecl	Right to left	Calling function pops the arguments from the stack

Win32::API expects the DLL function to reset the stack, but the DLL function expects its caller to reset the stack.