Hi Jared,
Thank you for reminding me about the GetExecutableBitness function. I also thought for the solution you suggested and tried to implement it in ABS. The problem appeared to be in the replacement of aqFile methods with something available in plain scripting (preferably, with VBScript).
FSO seems to be not oriented to work with binary files (like it is mentioned, for example at
http://blogs.msdn.com/b/ericlippert/archive/2005/04/20/binary-files-and-the-file-system-object-do-not-mix.aspx). And I don't like the idea to read the whole analyzed executable file into memory, because the executable may be quite big.
Most other approaches from the internet recommend using ADO Stream (e.g.
http://www.tek-tips.com/viewthread.cfm?qid=202173&page=534 and your sample with downloading the file:
http://www.automatedqa.com/support/viewarticle/8999/?st=0), but all of them are dealing with text files and are using the 'Stream.Read' call which also reads the whole file into the stream (I believe, OS handles streams more efficiently than plain reading of the file into memory, but don't have proof for that). I tried to replace the Stream.Read call with Stream.Read(iNumBytes) one like in this code snippet:
'--------------------------------------------
...
Stream.Type = 1 ' Binary (adTypeBinary)
' Stream.Mode = 1 ' adModeRead
Stream.Open
Stream.LoadFromFile strFullFileName
' Stream.Open strFullFileName, 1 ' adModeRead
Stream.Position = &H3C ' contains offset to segmented .EXE header
iOffset = Stream.Read(4) ' ReadInt
...
'--------------------------------------------
but this code resulted in two problems.
The first problem was that the 'Stream.LoadFromFile strFullFileName' line failed when the strFullFileName contained the UNC path to the executable that was opened (running) on the remote machine. I don't know as we speak whether this was because of remote location of the file (though this seems to be OK according to the ADO documentation) or because the file was locked by remote OS (as the running process).
For the debug purposes, I tried with the strFullFileName pointing to the local file and got the second problem.
The second problem is that the Stream.Read(iNumBytes) call returns the bytes array (e.g. iOffset from the code snippet from above). In TestComplete's Watch window I was able to see the contents of the array, but failed with both: to convert the returned iOffset bytes array to integer and access its elements via iOffset[0] and iOffset(0) notation.
Summing-up: strategically, I feel that the suggested approach is correct one. Tactically, I am still looking for the code to read the binary files. I think that my next step will be to consider reading binary files with DelphiScript.
