OSDev.org

I'm programming text I/O for my OS and I got into the "printf" part... and just were curious what method of adding a new blank line your OS uses.

I'm using the CRLF combination.

Regards
inflater

I'm using LF. I find that most C tutorials and code snippets use \n in their printf(), which equates to LF. So I make my printf() and related functions respond to LF.

I use LF as well. Using CRLF is supported in my kernel but is not necessary. A simple '\n' will suffice to start a new line.

When you are entering an EOL code, making it be just one byte is best. If it is two bytes, what do you do if they are in the wrong order? What happens if an application deals with LF/CR differently than your OS standard? Do you compress the CRs out of the input stream when a file is read? Isn't that annoying when the amount of data read != the amount of data you request? (I've always hated that with windoze.) And why waste a byte anyway?

I'm going with LF only, and no CR/LF support. (There will be a text file xlation utility, of course.)

bewing wrote:What happens if an application deals with LF/CR differently than your OS standard?

I'm not following Windows or MS-DOS, I'm following the standards:
If the app does only CR, the cursor is returned to it's "home" position, screen X = 0. Carriage return.
If the app does only LF, system creates a new line and updates the Y position, but doesn't reset cursor's X position.
If the app does CR + LF or LF + CR (its the same), it'll return cursor to the beginning and creates a new line.

The CR code has it's advantages, for example if you are writing something like this:

Processing, please wait...
05% done.

- if you want to change just the percent value, you'll just do CR and overwrite first two numbers. No need to do "DelLine", or gotoxy(), or remove the whole "XY percent done" line etc.

Regards
inflater

inflater wrote:

bewing wrote:What happens if an application deals with LF/CR differently than your OS standard?

I'm not following Windows or MS-DOS, I'm following the standards:
If the app does only CR, the cursor is returned to it's "home" position, screen X = 0. Carriage return.
If the app does only LF, system creates a new line and updates the Y position, but doesn't reset cursor's X position.
If the app does CR + LF or LF + CR (its the same), it'll return cursor to the beginning and creates a new line.

The CR code has it's advantages, for example if you are writing something like this:

Processing, please wait...
05% done.

- if you want to change just the percent value, you'll just do CR and overwrite first two numbers. No need to do "DelLine", or gotoxy(), or remove the whole "XY percent done" line etc.

Regards
inflater

That's possible on UNIX systems too - on UNIX CR performs a carriage return, but LF performs a carriage return AND line feed.

Slightly unintuitive but it's what I'm used to!

Well, then I'd say your poll and topic is slightly inspecific.

You can have CR perform completely different functions depending on whether it is an output byte, or an input byte. When you send a \r as an output byte, of course you want it to perform only a simple "carriage return". When you send an LF as output, many times you will need for the driver to have an ioctl flag that tells the driver to do a translation to a cr/lf pair. Text based devices might well work wrong if only sent a single lf.

The much more difficult question, I still say, is cr/lf pairs as INPUT. Especially in text files. In that case, the cr is just a wasted byte that causes headaches.

bewing wrote:Text based devices might well work wrong if only sent a single lf.

I think I didn't got your point, but I'm not supporting any (physical) terminals or radio transmitters in my OS.

bewing wrote:In that case, the cr is just a wasted byte that causes headaches.

May I ask why? The text file in my OS willn't be pre-processed (as for now). Everything, every single byte will be displayed on the screen, e.g. in the text editor. No matter if it's CR, LF, number or any letter. CR and LF does only what it's expected to do. LF, according to the standards, should only do "line feed". Nothing else. And I don't care about Unix, Windows, DOS, Mac, etc.

But I'm planning a new-line-xlation option too

inflater wrote: May I ask why? ...

But I'm planning a new-line-xlation option too

OK, let's take the assembler that I'm writing, as an example. It is written to the C standard, using LF as an expected EOL character. It also has a rather strict set of rules about illegal characters, and what constitutes "whitespace". ^M is not on the current list of acceptable whitespace. ATM, it would be very difficult to add ^M to that list.
If you wanted to use my assembler under your OS with cr/lf line terminators, you'd be pretty much out of luck -- without a lot of rewriting on your end.

And it's that new-line-xlation that makes things really painful from my point of view.

bewing wrote:If you wanted to use my assembler under your OS with cr/lf line terminators, you'd be pretty much out of luck -- without a lot of rewriting on your end.

That's right - if you have your own OS - our OSes are woefully incompatible between each other

And with that "new-line-xlation" I meant a translator program that would translate e.g. text files using UNIX line-ending (LF) to e.g. Mac OS (CR), or e.g. Patlock/DOS to Unix etc.

BTW DexOS also used CR to create new lines

Err, I'm not even close to coding anything related to this yet, and I must say that now I've got some thinking to do.

I can see the merits of doing just LF and doing LF+CR. Making a carriage return implicit in a line feed does make things easier, and quite honestly I'm having a bit of trouble trying to figure out where a simple line feed would be useful by itself. On the other hand, it does make sense to use them for exactly what they are: return to the start of the line and move down a line.

In the end I may just go with LF being the only part necessary. In many cases having an extra carriage return isn't going to affect it if you make it implicit in the line feed, so if a program decided to do LF+CR for some reason it wouldn't matter, where programs that only did LF would still work. In some cases where things like programming syntax in an editor is important, I guess it could matter, but not generally.

I use both LF+CR and LF. If only LF is present it calculates the next line end and start reverse searching of first non-empty space (empty space is assuming when the symbol is 0x20 ASCII and has the same foreground and background color). Then it moves the cursor after first result or to start of the next line if no results. The CR code returns the cursor to the start of the line. And the LF+CR combination (LF is fisrt) move to the next line. CR+LF works as LF only. I'm planning using this method only for 80x25 video mode. In SVGA I will do another one.

I suppose one curious advantage of using a carriage-return line-feed pair is that it's backwards compatible with typewriters. There are actually two different variations on this combination, the one where the line-feed and carriage-return characters *each* do as they say (so you could reverse their order and it would function the same), and the one where *both* are needed together to generate any effect (as Windows seems to do it).

The only place I have had to consider this so far is in my kernel's printf/print_char routines. In this I've used a single line-feed (\n) because it's just simpler that way. Compatibility isn't an issue as the only strings it's handling are the ones I've written myself.

If you don't mind losing the ability to control line-feeding and carriage-returning individually, then you can get the very best compatibility by coding it so that on the first \n or \r, it would not initially do anything. Then with the next character, if it's another \n or \r the same, do two CRLF actions (to handle \n\n (UNIX-like systems) and \r\r (Mac OS)). If it's the alternate one, do a single CRLF action (to handle \r\n (DOS/Windows) and \n\r). If it's any other character, do a single CRLF and then handle the character normally.

EDIT: Just realised that "\n" and "\r" don't always equate to the same bytes across C implementations like I thought they did because of different character sets. I assumed \n to represent 0x0A (line-feed) and \r to represent 0x0D (carriage return). You get the idea though. Wikipedia has a lot of detail on this: http://en.wikipedia.org/wiki/Newline

In my OS all strings internal to the kernel and all kernel generated strings are ended by "\n". However, since I grew up with windows and its just easier to transfer files to windows if I do it this way I allow the filesystem code to expand "\n" to CFLF when it outputs to the file. But other than that all code treats "\n" and "\r" identically.