Where oh where is my directory
RAMontante
bobmon at iuvax.cs.indiana.edu
Sun Mar 26 14:32:54 AEST 1989
perrone at loligo.UUCP (Perrone Ford) <7712 at 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.
More information about the Comp.lang.c
mailing list