Editing text correctly

[tnrh1]

Hello everyone,
I had some problems with text editing through hex editor.
Let's take this text for example:



Changing the "Informחץes do servidor" into "Server information".
Always when I edit text and the the old string was bigger I just fill the rest with zeros(ASCII=.) but in this case there is a kind of legal that between each message or any space instead of zeros there are 0a and 0d.

The result of filling the rest of the string with zeros is a blank page and with 0a & 0d is few break lines.

My guess somewhere in the client when the string is called he got limits and by using bigger or smaller strings I across them.

So where are those limits and the string call?or this little theory is piece of trash and the answer hides somewhere else.

[MentaL]

[bobsobol]

1. "Informחץes do servido"? you mean "Informções do servidor"! Speak proper Portuguese.
2. "I just fill the rest with zeros(ASCII=.)" ASCII=. is not Zero it's 46. Zero is ASCII=\0. Strictly speaking ASCII comprises the digits 32 to 128, so 0 is not ASCII.
3. 0x0d 0x0a is IBM OEM Carriage Return and Line Feed. <CR><LF> or \n\l.

My guess somewhere in the client when the string is called he got limits and by using bigger or smaller strings I across them.

You guess wrong. The rest is irrelevant as the basic primes is completely out of whack.

The text is processed, rather like formatted text displayed in a RichEdit control, but slightly less advanced.

Look at the control codes in an RTF file, and see how they relate to the formatted text in WordPad. It's a bit like HTML, but simpler. It often even lists default styles at the top like CSS.

Anyway, essentially this information is held like a text file in a buffer in memory. Now look at a standard INI file or something in your hex editor, and notice the "0D 0A" between each line.

The in-memory text file is processed line by line, and different colours may be applied to each line as it's displayed on screen.

0D 0A are part of the string which is processed. So you must have as many of them before the first "00" (if you insist on looking at it that way) as where in the original. You can think of them like commas in a CSV file if you like. Effectively the first "00" hit is taken as an EOF marker. (End of File)

The new line escape code ('\n\l') is taken as a delimiter. Primarily to move down a line, but PT will also analyse each line before displaying it to decide what colour it should be when it is passed to TextOut().

It would be easier, if it where not for this additional line by line processing, to pass the whole lot to a DrawText() API with the appropriate RECT structure, and have the OS do all the rest of the formatting.

--- EDIT ---
I know you are looking to start learning the x86 and possibly how it comes to being from the C (or C++, in places) source. This is a prime example. These are C strings. There is absolutely no convention for strings in x86. There is no "string data type" in C, but it is convention to use a "null terminated array of type char" addressed by a pointer. (or char*) In other words, a list of data elements of sizeof(char) (usually 1 byte, except in multi-byte character systems "MBCS") ending in a character code 0. (conventionally called null)

http://en.wikipedia.org/wiki/C_string