Hex'n in Turin', and the rising urge to break things

[Delos]

I shall try make this as clear as possible.

I am currently attempting to circumvent some of Turing's more colourful limitations - well, colourless to be precise. Part of what I'm doing involves taking a hex dump (in this case of a BMP), reading it in, then REWRITING it in the normal ASCII style that can then be interpreted as .bmp.

All well and good.

I have my hex dump, I read it in, convert and so on, and all goes smoothly, until I have to do the actual file writing...
Specifically this line:

hex:

00 00 0A 00 00 00 0A 00 00 00 01 00 18 00 00 00

gets written as:

hex:

00 00 0D 0A 00 00 00 0D 0A 00 00 00 01 00 18 00 00 00

(For those interested, this is the second line in the BMP header. Specifically, it deals with defining the width and height of the BMP. In this case the 0A's indicate a size of 10x10.).

Fun fun fun. Seeing as the 0A being read in is translated into decimal(10), the chr() interpretes it as a line break. From what I can gather from experimentation, this is what the 0D is all about.

The fact that 10 -> Break is a very Turing thing. When I write that particular character to the file, it includes the line-break indicator...not what it should be doing mind you.
So, what I need to be able to do is to take that 10, still apply a chr() or similar operation and write a character that will still be later interpreted as 0A (if viewed in a Hex-editor).

When I try viewing the eventual .bmp, I get a "Drawing failed" error. However, if I go in and remove the 0D's from the file, the pic comes out perfectly.

Tech. info: I'm using XVI32 to edit the Hex. I can attach my hex source if need be - bear in mind that I have yet to figure out/find a programme that can actually 'dump' the hex it interprets into a file. As such, this particular one was manually (but accurately) typed.
Additionally, attaching the code would likely be futile, this is very much a theoretical problem. Unless wtd says otherwise, of course...

As a disclaimer, if any of the above information is incorrect with respect to the jargon, theory, or general application of Hex stuff, my apologies. I only started working with this stuff this afternoon...

[Dan]

1st of all why it is adding the 0Ds:

In the ASCII standers 0A (10) is line break and 0D (13) is line fead (or the other way around). Any how they are allmost allways put together as to go to the beging of the line and then to a new one. Turing most be adding in the 13 beacuse it thinks you are doing text file I/O.

It has been a bit since i worked with turing I/O but i blive you most use a binray output method. Are you using the read/write comands or the put get ones? If you are using the read/write comands is there any way to tell it to go to brianry mode?

[Delos]

Merçi, oh most lateral-thinking Dan. This works. I am now very, very happy!

The write method was the way to go. I guess this answers a lot of questions for myself at the same time. Arigatou gozaimasu.