AutoHotkey Community

[Laszlo]

Chris keeps saying that someone has to write simple binary file read/write functions based on the example he provided. Here is mine. They open a file of the given name, read/write hex data and finally close the file. The returned value is the actual number of bytes processed. If there was an error, Errorlevel is set. The data is a long stream of 2-digit hex numbers, without the 0x prefixes.

The script below starts with calling examples, followed by the functions which could be included in other scripts.

[Rajat]

aw crap! i was going to post those! for binread i was tinkering to see if there's a way to not read 1 byte in a loop and maybe read the whole file or atleast 1kb a time.
thanx for posting 'em!
_________________

[Laszlo]

Rajat, I was thinking about the larger block read speedup, too. Windows probably keeps a whole block of data (512 bytes at ATA drives) in a buffer, and the DLL-calls only access this buffer, not fetching the disk blocks repeatedly. It means, the speedup only eliminates some subroutine calls and returns. They are not drastic.

For me the other issues look more interesting: to read/write in the middle of the file. I have no clue...

[Rajat]

[Rajat]

i tried the following, but the file wasn't recreated.

file = e:\stuff\water.exe

data =
res := BinRead(file,data)
BinWrite("new.exe",res)

the result was just a 2 byte file... where did i mess up?
_________________

[Laszlo]

BinWrite() expects as the second parameter a sequence of hex digits. res contains only the number of bytes read by the preceeding Binread(), data is containing the read bytes.

[Chris]

Thanks for writing these functions. I feel a little guilty for pressuring you to do it because your time would probably have been better spent proving that P != NP.

[Rajat]

doh!
thanx laszlo!
_________________

[Rajat]

i made a few minor changes to suit me:
- binread returns the read data
- errorlevel contains bytes read/written for both functions

if function didn't work out smoothly then errorlevel will still have error code

[Laszlo]

The original functions had the same calling syntax result:=func(file, data), which I like for their symmetry. Also, if something went wrong ErrorLevel used to tell a lot about what had happened. Now you see less information. The last dll calls might clear ErrorLevel, so you should move the assignment to it after the dll calls, under an Else, but still it is not a clean solution. You have a different design, so some more changes are necessary (besides updating the comments).

[Thalon]

I'll have a look over it, maybe I will overtake it in some piece of software (with little changes)!

Thx Laszlo!

[Laszlo]

With Chris’ tip I was able to update the functions (see edit in the original post). Now BinRead can read n characters (all if n = 0) starting from an offset ( < 0 counting from the end of the file). It allows, for example, getting MP3 tags or icons from a file, without any external SW.

BinWrite now overwrites n bytes of the file (if it exists) starting from the offset (< 0 counting from the end of the file) taken from the beginning of data. It does not change the length of the file. If the file does not exist, it gets created anew. In this case un-initialized data could be left in the beginning of the file when non-zero offset is specified.

There could be a further generalization of the BinWrite function with somewhat different syntax: BinWrite(file, data, insert_offset, continue_offset), meaning that the file remains unchanged before the insert_offset, the new data comes after it, but the bytes until continue_offset are dropped. The end of the file remains unchanged.

Changing the length of a binary file looks dangerous, though. If it has code, we can easily mess it up. Still, using the posted functions this data insertion can be easily programmed: read the beginning of the file, concatenate the new data followed by the end of the file also read. The resulting data can be written to a new file.

[Laszlo]

The original post is further edited with minor clarifications an cleanup.

These functions keep the data in hex form, such that the powerful string manipulating and search functions of AHK could be applied. If only pieces need to be cut and pasted, there is no need for hex conversions. Large chunk of data can be manipulated in binary buffers. The details are left as an exercise for the reader.

[Rabiator]

I always get errorlevel -4 when I run the script on Win 98. The reason is, SetFilePointerEx doesn't exist in this OS.
Is there a similar function?

[Laszlo]

Look here