AutoHotkey Community

[Laszlo]

NumGet/Put has to perform data conversion. If you read/write floats, or signed/unsigned numbers different actions take place. It is not only the size. If you specify a size of 7 bytes, what does it mean? Do you want the number in NumGet/Put padded from left or right, especially if it is negative? What if it does not fit? What if the number has a decimal part? There are too many options to be considered, which do not fit to these functions.

I think, what foom has in mind is mem-move. It could be a separate function, with the first parameter a string of hex digits: MemPut("1f2233",var,offs,3) or String := MemGet(var,0,33). Or name them HexGet/HexPut. They can be useful at:
- filling constant parts of large structures with one instruction
- getting the content of binary files into an AHK variable in manageable form
- creating dynamic variable names from arbitrary data (~associative arrays), etc.

Btw, Chris: what does NumPut do if the number parameter is too large integer, like NumPut(256,var,0,"char"). The simplest was to ignore the high order bits, which do not fit, but it ought to be documented.

[Chris]

[Laszlo]

Proposed documentation extensions for NumPut: If float or double Type is specified, Number is rounded to the supported precision, otherwise its most significant bits are ignored, if any, which do not fit to the specified Type. E.g. NumPut(257,var,0,"Char") results in writing a single byte = 1 to the memory reserved for var.

[Chris]

I omitted the bit about floats/doubles because it's explained in DllCall types (which is already mentioned and linked). I added a slightly abbreviated version of the rest: "If an integer is too large to fit in the specified Type, its most significant bytes are ignored; e.g. NumPut(257, var, 0, "Char") would store the number 1."

Thanks.

[Laszlo]

HexGet/Put: I don't know fast dll calls for this. NumGet/Put are normally called for each byte in a loop, which is slow. We cannot easily lump 4 bytes together, because the little endian architecture in PC's makes them appear in memory in the wrong order, so an extra dll call is needed: "ntdll\RtlUlongByteSwap". Int64 is even worse, because of the signed hex representation.

Does anyone know a faster way to read/write hex streams to memory? In AHK the functions look like this

[majkinetor]

Yes, that is very useful, I needed that many times.
_________________

[corrupt]

Which page was the release and documentation on again?...

[engunneer]

page 6 of this topic, unless I completely misunderstand what you are asking (very likely)
_________________
Unless otherwise noted, all code is untested.
Common Answers: 1.(Loops, Viruses, etc.) 2. Search 3.RTFM