Return Values from Dll's

[Kerros]

Does anyone know where I can find some information on what is returned when a DllCall completes successfully? I've done some searches on the net in the past couple of days, but I can not seems to find what I'm looking for.

As an example I'm passing a Set Feature command to a hard drive using kernel32.dll. This completes successfully, and when I issue an Identify device command I can now see from the Identify data, that the setting that I changed did complete. When this happens the drives sends a good status back to the driver. Status register = 50 Error register = 00. What I'm looking for is that there are brands of drives that accept the command, but do not actually change the feature. Usually these drives will send back a different value in the error register, but still good status, Status Register = 50 Error register = 01.

So I'm looking for a way to parse the data that is returned from DllCall to verify that the command did actually complete and change the feature.

Return data from DllCall when command completes correctly

[0]|1

[1]|0x00000730

[2]|315436

[3]|0x012F4E78

[4]|40

[5]|0x012F4E78

[6]|40

[7]|19860280

[8]|0x00000000

Return data from DllCall when Command completes correctly, but the feature is not supported by the drive.

[0]|1

[1]|0x00000724

[2]|315436

[3]|0x01324118

[4]|40

[5]|0x01324118

[6]|40

[7]|20085824

[8]|0x00000000

Does anyone know where I could look to find this information, or any more information about what DllCall is returning?

Thanks

Kerros

[PsaltyDS]

Show a sample DLL call so we can tell what call you are using. Then I expect it to be a Google into MSDN to find the explanation of returned values.

[Kerros]

Here is my DllCall. I did try searching via google, but I don't think I'm searching for the correct thing.

$cSF is the Set Feature Command

$cSC is the sector Count

$cSN is the Sector Number

I'm sorry, but I can't post the entire code at time time. I'm having a fun conversation with our legal department over how much of this code I can share.

CODE

Const $DLLStructDef_ATA_PASS_THROUGH_EX = "ushort Length; ushort AtaFlags; ubyte; ubyte; ubyte; ubyte; udword DataTransferLength; udword TimeOutValue; udword; ptr DataBufferOffset; ubyte PreviousTaskFile[8]; ubyte CurrentTaskFile[8]"

Func Sf_command($i, $cSF, $cSC, $cSN = 0x00)

Local $ret

Local $buffATAPassThrough

Local $sizeOfATAPassThrough

Local $bytesReturned

Local $temp1

Local $unret[1]

If GUICtrlRead($MN_Label) <> "Unsupported Device" Then

Dim $msg = MsgBox(1, "Run Set Features Command?", "Really run Set Feature Command: " & $cSF & " On Drive: " & $i & @CRLF & "With a Sector Count of " & $cSC & "?")

If $msg = 1 Then

$hDrive = OpenDrive($i)

$cSF = "0x" & $cSF

$cSC = "0x" & $cSC

If $cSN <> 0x00 Then $cSN = "0x" & $cSN

$bytesReturned = DllStructCreate("int")

DllStructSetData($bytesReturned, 1, 0)

;First create temp structure to find out size.

$buffATAPassThrough = DllStructCreate($DLLStructDef_ATA_PASS_THROUGH_EX)

$sizeOfATAPassThrough = DllStructGetSize($buffATAPassThrough)

$buffATAPassThrough = 0

;For SetFeatures cmd buffer size is the returning ATA_PASS_THROUGH_EX structure.

$buffATAPassThrough = DllStructCreate($DLLStructDef_ATA_PASS_THROUGH_EX)

;Set values in ATA_PASS_THROUGH_EX structure

DllStructSetData($buffATAPassThrough, "DataTransferLength", 0)

DllStructSetData($buffATAPassThrough, "CurrentTaskFile", 0xA0, $ITaskFile_Device)

DllStructSetData($buffATAPassThrough, "CurrentTaskFile", 0xEF, $ITaskFile_Cmd)

DllStructSetData($buffATAPassThrough, "CurrentTaskFile", $cSF, $ITaskFile_Feature)

DllStructSetData($buffATAPassThrough, "CurrentTaskFile", $cSC, $ITaskFile_SectCount)

DllStructSetData($buffATAPassThrough, "currentTaskFile", $cSN, $ITaskFile_SectNum)

DllStructSetData($buffATAPassThrough, "DataBufferOffset", $sizeOfATAPassThrough)

DllStructSetData($buffATAPassThrough, "ATAFlags", $ATA_FLAGS_DRDY_REQUIRED)

DllStructSetData($buffATAPassThrough, "TimeOutValue", 15)

DllStructSetData($buffATAPassThrough, "Length", $sizeOfATAPassThrough)

$ret = DllCall( _

"kernel32.dll", "int", _

"DeviceIoControl", _

"hwnd", $hDrive, _

"int", $IOCTL_ATA_PASS_THROUGH, _

"ptr", DllStructGetPtr($buffATAPassThrough), _

"int", DllStructGetSize($buffATAPassThrough), _

"ptr", DllStructGetPtr($buffATAPassThrough), _

"int", DllStructGetSize($buffATAPassThrough), _

"int", DllStructGetPtr($bytesReturned), _

"ptr", 0 _

)

If @error Then

MsgBox(1, "EXITING...", "DeviceIoControl DLLCall failed with error level: " & String(@error) & "!")

;Exit (1)

EndIf

If $ret[0] = 0 Then

;~ _GetLastErrorMessage("Error in DeviceIoControl call to IOCTL_ATA_PASS_THROUGH:")

;Exit (1)

EndIf

CloseDrive($hDrive)

EndIf

Return $ret

Drives_info()

Else

MsgBox(0, "Error", "Unable to run command on this Device")

$unret[0] = 1

Return $unret

EndIf

EndFunc ;==>Sf_command

[PsaltyDS]

So, you seem to be using DeviceIoControl Function:

BOOL WINAPI DeviceIoControl(

__in HANDLE hDevice,

__in DWORD dwIoControlCode,

__in_opt LPVOID lpInBuffer,

__in DWORD nInBufferSize,

__out_opt LPVOID lpOutBuffer,

__in DWORD nOutBufferSize,

__out_opt LPDWORD lpBytesReturned,

__inout_opt LPOVERLAPPED lpOverlapped

);

But, the interpretation of all those DLL struct buffers depends on dwIoControlCode ($IOCTL_ATA_PASS_THROUGH in your script). Where is that defined, and as what?

Without that, can you interpret the rest? Doesn't it depend on the requirements/return of that particular control code that was not given?

[Kerros]

PsaltyDS

Global Const $IOCTL_ATA_PASS_THROUGH = 0x4D02C

I got this value from the windows header files. I had uninstalled the SDK, so I am reinstalling at this point and will determine exactly which header file it came from.

Even when this script was originally written I didn't really understand what the return values meant. I know what status is coming from the drive because I can take a bus trace and see what is happening at the drive level.

Kerros

[PsaltyDS]

PsaltyDS

Global Const $IOCTL_ATA_PASS_THROUGH = 0x4D02C

I got this value from the windows header files. I had uninstalled the SDK, so I am reinstalling at this point and will determine exactly which header file it came from.

Even when this script was originally written I didn't really understand what the return values meant. I know what status is coming from the drive because I can take a bus trace and see what is happening at the drive level.

Kerros

That doesn't clear the fog for me...

IOCTL_ATA_PASS_THROUGH is a function to be called from a driver library, not a variable to be passed, it seems.

But this is getting over my head, and you'll have to wait for the smart people now.

[Kerros]

Now that's a feeling I understand.

This project has been one full of dead ends and requests for information, that keep getting denied by the company as I don't have a "need to know". It's like pulling teeth to get the actual program developers here to give up source code. Which is why I started designing this one from scratch.