Database Search

TechHome

• !!Processing Templates Files with BinaryTag - Insider Tech Notes
• Binary Sort Two Different Fields
• BinaryPeek versus BinaryPeekStr
• BinaryPoke and Bit Swapping Discussion
• BinaryRead File Line by Line
• BinaryReplace With NULL Characters
• BinarySort Considerations
• BinarySort Example
• BinaryXlate Explanation
• Convert to UTF-8
• Could Not Allocate Binary Buffer Error
• Create Zero Length Binary Value
• CryptAcquireContext Gets a Handle to a Key Container within a CSP
• Example of Keeping Track of Multiple Pointers
• Extract Line 79 from a File
• Insert a Delimiter Every 5 Chars
• Nested Binary Sort
• Offset beyond binary EOD
• Parsing Dilemma
• Remove Line from File that Contains a string
• Remove Line from File
• Replace First Instance of a String in a File
• Retrieve last line from a File
• Search and Replace Another Example
• Search and Replace in Binary Buffer
• Splitting Registry Binary Entry for Writing to INI File
• System Ini writing multiple device lines to
• System.Ini and Device lines
• Use Binary Functions to Edit INI Files
• Use BinaryRead Like FileRead
• Using BinaryPeek to Find Null 00 Character

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

BinaryPoke and Bit Swapping Discussion

Keywords: 	  BinaryPoke Bit

Question:

BinaryPoke2(b,0,838)

Answer:

BinaryPoke2 stuffs the data using the Intel format. Apparently your data wants it differently.

x=838
BinaryPoke(bb,0, (x>>8)&255)
BinaryPoke(bb,1,x&255)

Question (cont'd):

first_two_bytes= (BinaryPeek(binbuf,0) << 8)+BinaryPeek(binbuf,1)

I realize I will get back a lot of Litle/Big Endian logic, so the question is from a layman without that instant binary calculation mentality.

Answer:

When to swap.

Depends. Mostly you need to either have or be able to infer the layout of the data in the file.

In general most of the problems will involve numeric fields larger than one byte. The value of each field must be understood and the number built from the bytes.

BinaryPeek2, BinaryPeek4 and BinaryPeekFloat all assume a prticular byte ordering that is common to Intel processors.

It turn out that (IMHO) the Intel ordering is most consistent, but that other (very) confusing factors make it seem like the oddball.

Basically any processor can make any file format, but fileformats that are "native" to the processor are usually chosen.

Mostly you have to get the bytes in a numeric field and figure out how to arrange them so that they give you the number you want.

Question (cont'd):

Answer:

Often the file format designers even overlook the byte order problem, not even realizing such a problem exists. However they are at least usually consistent within a file.

OK. Now I will explain the "blackboard problem".

In my years of working with this problem, I think I can trace the entire little endian, big endian and related problems to early Computer science professors. Here is how it works:

In CompSci 101 in college, the professor draws a large box on the blackboard and calles it a visual represntation of the machine's memory.

For this discussion lets say he draws a long, narrow box across the blackboard so that everything is laid out in one line.

Then he subdivides the box into individual bytes. Now the trick part comes. Lets say he makes 32 bytes. And numbers them.

Some professors start numbering from the left. 0, 1, 2, 3, ... 31

Some professors number from the right

31, 30, 29, ... 2, 1, 0

In the first case it is numbers kind of how left-to-right languages read, from left to right. In the other case it is numbered from right to left. (how right-reading languages read, and more in keeping with bit numbering where the left-most bit of a 32 bit number is considerd bit 31 (the most significant bit) and the right-most is 0 (the least significant bit).

(It helps if you draw this on a piece of paper)

Now lets day you have a 16-bit number (2 bytes) and you wish to store this into memory. You need two memory locations for this. Lets pick locations 2 and 3.

In the left to right ordering it would make sense (kind of) to put the high-order byte into location 2 and the low order byte into location 3. Seems reasonable, but the the high order byte is in the low numbered address and the low order byte is in the high numbered address. Hmmmm

In the other case the high-order byte would fit naturally into location 3 and the low order byte into location 2. So the high ordered byte is in the higher numbered memory location and the low ordered byte is in the low numbered memory location. Seems logically consistent.

However another disaster occurred. It turns out that most hex edit/view programs display the bytes in a left to right numbering scheme, making the Wintel bytes appear in the wrong order, and thus making the Wintel numbers appear "flipped".

Then there are other manifestations of this issue. It's a mess.

A Related Question):

Answer:

If you make a new temporary 8-byte binary buffer, then BinaryPeek() the four individual bytes that comprise the 32-bit value, and then BinaryPoke() them into the temp buffer in swapped order in such a way that you can then do a BinaryPeekFlt on the temp buffer to get the correct value (setting the other four bytes of the 64-bit value to zero) this would probably leave the problem that the most significant bit of the value is the sign bit, which you would have to move from byte 8 to byte 16 using bitwise operators.

Unfortunately, byte swapping alone will not do it. Here is a link to an MSFT site that shows the difference between 32 and 64 bit little endian floating point formats.

http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html

Article ID:   W15446

File Created: 2003:05:13:11:27:56

Last Updated: 2003:05:13:11:27:56