X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Received: by 10.224.57.65 with SMTP id b1mr1981923qah.2.1371619812294; Tue, 18 Jun 2013 22:30:12 -0700 (PDT) X-Received: by 10.49.62.168 with SMTP id z8mr20729qer.11.1371619812251; Tue, 18 Jun 2013 22:30:12 -0700 (PDT) Newsgroups: comp.os.msdos.djgpp Date: Tue, 18 Jun 2013 22:30:12 -0700 (PDT) In-Reply-To: <8361xbs7vm.fsf@gnu.org> Complaints-To: groups-abuse AT google DOT com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO NNTP-Posting-Host: 65.13.115.246 References: <36e857f0-9899-496b-9fc6-32251e109888 AT googlegroups DOT com> <858cbded-7989-46e6-a997-93f842cdb3b0 AT googlegroups DOT com> <8361xbs7vm DOT fsf AT gnu DOT org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2b6a5964-e068-4031-bd00-191708e339ea@googlegroups.com> Subject: Re: General Protection Fault error is intermittent From: rugxulo AT gmail DOT com Injection-Date: Wed, 19 Jun 2013 05:30:12 +0000 Content-Type: text/plain; charset=ISO-8859-1 Bytes: 3038 Lines: 35 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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).