Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!bobmon
From: bobmon@iuvax.cs.indiana.edu (RAMontante)
Newsgroups: comp.lang.c
Subject: Re: Where oh where is my directory
Message-ID: <18924@iuvax.cs.indiana.edu>
Date: 26 Mar 89 04:32:54 GMT
Reply-To: bobmon@iuvax.cs.indiana.edu (RAMontante)
Distribution: na
Organization: malkaryotic
Lines: 43

perrone@loligo.UUCP (Perrone Ford) <7712@pyr.gatech.EDU> :
-What I am trying to accompish is to read the directory 
-entries into a buffer and then print the buffer out in the
-middle of a graphics routine
-
-#include <stdio.h>
-#include <grphics.h>  /*  Maybe curses  */
-main () 
-{
-char *listing;
-listing = system("dir");
-initgraph = DETECT;
-initgraph(&graphdriver, &graphmode);
-outtext(listing);
-}

If I understand your intent correctly, you're waaay off base.  You seem to
want 'listing' to point to a character string containing the result of the
"dir" command, which you will then display within a graphics image.

However:  the 'system("dir")' command does not result in 'listing' pointing
to any such string.  Instead, "dir" tries hard to display its output
directly on the *screen* regardless of the screen-display mode (text,
graphics, CGA/VGA/whathaveyou).  Then 'system()' returns an *integer*
indicating whether or not the "dir" command successfully ran or not -- since
"dir" is builtin to the MSDOS command interpreter, the only way MSDOS will
claim that "dir" failed is if COMMAND.COM is missing;  a "dir" that crashes
looks successful to MSDOS.  (If that sounds absurdly irrational, then you're
beginning to understand.)

Since integers and char pointers are often similar-sized, this bogus
assignment to 'listing' will sort-of work (unless you've enabled ALL the
TurboC warnings, in which case it'll tell you of the type mismatch).
Once you go into graphics mode, you give 'outtext()' a value which it thinks
is a memory address but which in fact is either 0 or 1.  It is unlikely
that any character-string-like object starts at either of these "addresses".

Lastly, of course, the whole graphics business is particular to Turbo C (or
an equivalent package) which "knows" that it's accessing a particular
bit-mapped display.  I'm pretty sure that pANSI avoids any considerations at
all like those embodied by <graphics.h>.  (Is <curses.h> sanctioned by
pANSI?  I don't think so.)  Pure C shouldn't know whether it's driving a
bit-mapped display or an electric typewriter.