Mail Archives: djgpp/2013/06/19/01:45:17
Hi,
On Tuesday, June 18, 2013 11:26:05 AM UTC-5, Eli Zaretskii wrote:
> > Date: Tue, 18 Jun 2013 07:43:24 -0700 (PDT)
> > From: rugxulo AT nospam DOT for DOT me
>
> > > Remind me again, is DOS newline : "\r\l" or "\r\n" ???
>
> > Most DOS calls assume CR (carriage return) plus LF (linefeed), aka 0xD 0xA.
>
> No, DOS calls know nothing about the end-of-line conventions.
You're mostly right, I don't know what I was thinking, it's a tediously
complicated nit. Though there are some BIOS and DOS calls that behave
specially when confronted with 0xD or 0xA, esp. when writing to the
screen (and CR if often seen as end of input buffer).
> > The DOS kernel API usually assumes CR+LF.
>
> No, the DOS kernel doesn't care. It's the C library that does. The
> DOS kernel functions always read and write in what we call the "binary
> mode", i.e. they don't make any conversions between newline and CRLF
> or vice versa. This is always done by the C library.
You cannot just output 0xD or 0xA alone and expect it to work correctly
like '\n' would in *nix. At least when outputting to the screen, it won't
do what you want, even just using the BIOS. There are some protocols
(I forget which) that even require CR+LF explicitly. It's just that
*nix took the '\n' shortcut for whatever reason (space efficiency?).
I find it mildly frustrating how many apps (due to buggy libc or such)
don't handle other linefeed conventions properly, but what can you do?
Not much, usually you have to just work around it or use something that
does handle it properly. This is worse for old DOS apps, of course, but
other OSes aren't immune either. DJGPP stuff usually doesn't have this
kind of problem (unless coded incorrectly).
- Raw text -