On Mon, Feb 11, 2008 at 05:34:16PM +0000, Tzafrir Cohen wrote: > On Mon, Feb 11, 2008 at 12:28:19PM -0500, Douglas A. Tutty wrote: > > On Mon, Feb 11, 2008 at 05:05:36PM +0000, Tzafrir Cohen wrote: > > > On Mon, Feb 11, 2008 at 11:45:10AM -0500, Douglas A. Tutty wrote: > > > > On Mon, Feb 11, 2008 at 06:05:08PM +0200, Micha wrote: > > > > > I have a stream of unsigned long numbers saved from visual studio (2005) that > > > > > I'm trying to open under linux, but the format seems to be very strange > > > > > (doesn't seem to be neither big endian nor little endian). For example, the set > > > > > of numbers 2, 288, 2624, 490 (or in hex 0x2 0x120, 0xA40, 0x1EA) comes out (in > > > > > hex) > > > > Your first 0x2 should be 0x002 to keep padding correct. > > > > > > > > > 02 00 00 00 20 01 00 00 40 0D 0A 00 00 EA 01 00 > > 02 00 00 0 20 01 00 00 40 0A 00 00 EA 01 00 > > > > > ^ > > > > where did the D come from? try using a longer string of hex integers. I bet the 0D comes up at a regular interval so that all you have to do is ignore 0D's at that interval and then it looks like little-endian hex to me. > > So the question is, what is the program doing to put that '0D' there. > > That whold block doesn't follow the pattern of the other three. > > s/\n/\r\n/ ??? yeah, sort of. I'm guessing it put's in 0D at a regular interval in that no "line" is more than 9 bytes long. seem's kind of silly though. A
Attachment:
signature.asc
Description: Digital signature