Date: Tue, 5 Dec 2000 11:47:02 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Graham Reeds <grahamr AT dtn DOT ntl DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: Buffering text...
In-Reply-To: <bJQW5.6102$uP1.113152@news6-win.server.ntlworld.com>
Message-ID: <Pine.SUN.3.91.1001205114632.27857C@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Mon, 4 Dec 2000, Graham Reeds wrote:

> > > Try using (1,1) and see what happens. Works fine for me, but (0,0)
> > > didn't output anything at all.
> >
> > That's because the first column and row are 1 and 1, not 0 and 0.
> >
> 
> It worked, but that doesn't explain why it worked for printf() and not
> cprintf().

Because printf's buffering makes gotoxy's effect not entirely
predictable.  Also, printf's output goes through the BIOS, and it's
quite possible that the BIOS fixes up invalid screen position before
printing something.

In contrast, cprintf writes directly to the video memory, and gotoxy
sets the starting address where the next write goes to.  So calling
cprintf after gotoxy(0,0) writes outside the addresses shown on the
screen, and thus you don't see anything.

When you output a "\r\n", the address where the text is written moves
down by one line, which brings it back into the area of video memory
that is shown on the screen.  That's why you thought that nothing is
displayed until you output a newline.