Do you have dumpbin.exe on your system? If so, could you post the output from the command:
dumpbin /exports HCE300_API.DLL
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.
| [reply]
[d/l]
[select] |
I installed Visual c++ and started dumpbin as you suggested. This is the output:
Dump of file c:\Programme\HCE300B_APP\ApiLib\HCE300_API.dll
File Type: DLL
Section contains the following exports for HCE300_API.dll
00000000 characteristics
0 time date stamp Thu Jan 01 01:00:00 1970
0.00 version
1 ordinal base
14 number of functions
14 number of names
ordinal hint RVA name
5 0 0005A51C HCE300_Break
13 1 0005B148 HCE300_Close
3 2 0005A514 HCE300_GetDeviceType
9 3 0005AFD8 HCE300_GetLastStatus
1 4 0005B2C8 HCE300_GetRecordFormat
2 5 0005B260 HCE300_GetTrack2Density
14 6 0005A52C HCE300_Open
11 7 0005A854 HCE300_Read
12 8 0005B174 HCE300_Reset
4 9 0005A4F0 HCE300_SetDeviceType
7 A 0005B268 HCE300_SetRecordFormat
6 B 0005A4D0 HCE300_SetShowDialog
8 C 0005B200 HCE300_SetTrack2Density
10 D 0005AC5C HCE300_Write
Summary
1000 .edata
3000 .idata
6000 .reloc
1A000 .rsrc
2000 BSS
5B000 CODE
2000 DATA
I also found some more C sample code:
char ReadBuf[250];
/* Open Success */
if(HCE300_Read(2, ReadBuf) == HCE300_OK) {
}
else {
}
(I removed the unreadable chinese comments from the sample)
| [reply]
[d/l]
[select] |
Update: ikegami's right. I shouldn't try to interact before having my second cup of tea. I exactly reverse the meaning of the underscore in my mind!
That shows that the calling convention used is __stdcall, so you should be able to call the dll successfully using Win32::API. __cdecl calling convention was used, so you will not be able to call the dll successfully winth Win32::API.
Ignore the rest!
And according to this translation of (probably the same?) chinese pdf, your (second) prototype:
my $readdevice = Win32::API->new (
'HCE300_API.DLL', 'HCE300_Read','NP','N'
) or die $^E;
is correct. It also identifies that the maximum length of data that can be read from the device is 300 bytes (track 2 when in 210bpi mode). (Though despite the warning in the descroption that it can be 300 bytes, all the examples use char buf[250]!)
The upshot is that what you are trying should work. If it doesn't, there are many possibilities for why it doesn't, and all of them are far beyond the scope of this Perl forum.
You mentioned using USB. The description of the device shows that it is intended to be connected to an old fashioned RS232 serial port. My one attempt at using a USB connected serial port convinced me that their RS232 emulation is far from transparent. If the device/driver was never written and tested to operate over USB, you are likely to encounter real problems.
One possibility is that at the end of that manual above, there is a description of the comms protocol commands for driving the device. You might be able to bypass the DLL and drive the device directly by writing and reading raw bytes to and from the serial port itself. Though I'll have to just wish you luck with that, because serial comms is more a black art than science, and it is hard enough to do hands-on with a protocol analyser to hand. Doing it remotely is pretty much impossible.
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.
| [reply]
[d/l]
[select] |
If there's a difference in calling conventions, yes. Unresolvable protocol differences.
It could be a number of other things too.
- You have the wrong prototype.
- You are using the library in a manner it doesn't expect.
- There's a bug in the library.
- etc.
| [reply] |