Mail Archives: djgpp/2000/08/26/21:01:41
From: | Radical NetSurfer <radsmail AT juno DOT com>
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | printf, cprintf and CR/LF problem
|
Date: | Sat, 26 Aug 2000 17:59:26 -0400
|
Message-ID: | <s2fgqs8iobmdvbfrjfl2tfm57i2o9e2mov@4ax.com>
|
X-Newsreader: | Forte Agent 1.8/32.548
|
X-No-Archive: | yes
|
MIME-Version: | 1.0
|
NNTP-Posting-Host: | 216.202.140.94
|
X-Original-NNTP-Posting-Host: | 216.202.140.94
|
X-Trace: | 26 Aug 2000 18:02:23 -0400, 216.202.140.94
|
Lines: | 24
|
X-Original-NNTP-Posting-Host: | 64.31.79.51
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Reply-To: | djgpp AT delorie DOT com
|
Todays latest discoveries, with no work-around to date:
Apparently,
printf
and
cprintf
are immediately outputting a cr/lf, and scrolling, once it reaches the
line limit, before it may actually be necessary to do so (issue cr/lf
and scrolling). Other screen I/O routines actually WAIT for the NEXT
line to actually begin printing, and then do NOT actually insert a
BLANK line (as if CR/LF is actually a part of the line itself)
(allowing all 80 characters of a standard text screen to be printed,
and seeing the CR/LF as simply going to the next line).
Is there any way to get this proper (and apparently expected) behavior
from printf, and cprintf, in DJGPP and other compilers?
Thanks!
/* Still waiting to learn what a 16-bit entity is called on a 32-bit
platform (since WORD has been made in an ambiguous term. */
- Raw text -