Binary data type on 64bit systems

[andy-b]

Am really not to sure about the Binary data type but I found this code sample on another forum topic (5th post down): https://forums.jadeworld.com/viewtopic.php?f=9&t=1447
I can retrieve all the values and that is all good in a 32bit system.
What I am wondering is if I have to adjust the index values if I were to run this in a 64bit system?
e.g.
sysInfoStructure [ 32 : 1 ] := 0.Binary; ----should be ---> sysInfoStructure [ 64 : 1 ] := 0.Binary;
dwPageSize := sysInfoStructure[ 5 : 4].Integer ----should be ---> dwPageSize := sysInfoStructure[ ? : ? ].Integer

Any sort of info would be good at this point.
Thanks

[alanvl]

The layout of the sysInfoStructure appears to be the same apart from the addition of a couple of extra attributes:
WORD wProcessorLevel;
WORD wProcessorRevision;

See http://msdn.microsoft.com/en-us/library ... 85%29.aspx

So the sysInfoStructure [ 32 : 1 ] := 0.Binary;
becomes sysInfoStructure [ 36 : 1 ] := 0.Binary;

wProcessorLevel := sysInfoStructure[ 33 : 2].Integer;
wProcessorRevision := sysInfoStructure[ 35 : 2].Integer;

[andy-b]

Thanks for the reply

The reason why I was asking is that I am looking into an issue where we calculate some values based on calls to functions in Kernel32.dll (the other function being GetThreadTimes http://msdn.microsoft.com/en-us/library ... 85%29.aspx).
In a 64bit system the calculation seems to be producing a bizarre result so this is my starting point that maybe we need to account for some different processing when converting the various values in the binary data type. I am now investigating GetThreadTimes which we access by this conversion:

Code: Select all

vars threadHandle : Integer; // Windows thread handle creationTimeFT : Binary [ 8 ]; // Windows FileTime structure exitTimeFT : Binary [ 8 ]; // Windows FileTime structure kernelTimeFT : Binary [ 8 ]; // Windows FileTime structure userTimeFT : Binary [ 8 ]; // Windows FileTime structure systemTimeST : Binary [ 16 ]; // Windows SystemTime structure kernelTime : Time; userTime : Time; totalTime : Time; begin creationTimeFT [ 8 : 1 ] := exitTimeFT; exitTimeFT [ 8 : 1 ] := exitTimeFT; kernelTimeFT [ 8 : 1 ] := exitTimeFT; userTimeFT [ 8 : 1 ] := exitTimeFT; systemTimeST [16 : 1 ] := exitTimeFT; threadHandle := call getCurrentThread; if call getThreadTimes(threadHandle, creationTimeFT , exitTimeFT , kernelTimeFT , userTimeFT) then call fileTimeToSystemTime(userTimeFT, systemTimeST); userTime.setTime( systemTimeST[ 9 : 2].Integer, systemTimeST[ 11 : 2].Integer, systemTimeST[ 13 : 2].Integer, systemTimeST[ 15 : 2].Integer); call fileTimeToSystemTime(kernelTimeFT, systemTimeST); kernelTime.setTime( systemTimeST[ 9 : 2].Integer, systemTimeST[ 11 : 2].Integer, systemTimeST[ 13 : 2].Integer, systemTimeST[ 15 : 2].Integer); totalTime := userTime + kernelTime; endif;

Searching online I couldn't see any indication that these values or data structure would be different on a 64bit machine so I think I am clutching at straws. But this is the first time I have come across the binary type in Jade and seen it used to access data from a windows API call.

[allistar]

A better solution is to get the external function call to break the struct up for you instead of doing it in JADE. That way you are not dealing with a Binary in Jade but rather the members of the struct (which appear to be Integers).

[andy-b]

That would be a plan but unfortunately the external function is in a Windows dll file so is maintained by good old Microsoft. Not sure if I would have much sway in asking then to change their System32.dll file for me

[torrie]

We've created our own dll (as Allistar has suggested) which wraps the windows API calls. This was done so we could retrieve the last error value (getLastError method) for failed function calls. If you don't do this within an external DLL, other windows API methods can be called by JADE overwriting the last error value. Sometimes, we've defined our own parameters to the method so that they are Jade friendly. For example, we've wrapped up a Shell method SHGetFileInfo (Code is Delphi but could be easily converted to C or .Net.)

Code: Select all

function ceSHGetFileInfo( pszPath : PChar; dwFileAttributes : Cardinal; var hIcon : Cardinal; var iIcon : Cardinal; var dwAttributes : Cardinal; lpDisplayName : PChar; // MAX_PATH lpTypeName : PChar; // 80 uFlags : Cardinal; var dwLastError : Cardinal // Populated with the last error if the result is zero. ) : Integer; { Calls the Windows API SHGetFileInfo. See the API documentation for a description of the parameters. } var SFI : TSHFileInfo; begin result := SHGetFileInfo( pszPath, dwFileAttributes, SFI, SizeOf(TSHFileInfo), uFlags ); if result = 0 then dwLastError := getLastError() else begin hIcon := SFI.hIcon; hIcon := SFI.iIcon; dwAttributes := SFI.dwAttributes; StrLCopy( lpDisplayName, SFI.szDisplayName, MAX_PATH ); StrLCopy( lpTypeName, SFI.szTypeName, 90 ); end; end;

[allistar]

That would be a plan but unfortunately the external function is in a Windows dll file so is maintained by good old Microsoft. Not sure if I would have much sway in asking then to change their System32.dll file for me

You can create your own external function that wraps the Microsoft one. We do that quite a bit to prevent having to revet to nastiness in JADE code.