timk@xenitec.on.ca (Tim Kuehn) (03/30/90)
Talk about quick response! I've gotten quite a few responses to the 2 questions I posed, 1) re: changing the text color on a screen 2) the return value of "system" Both of these with respect to the Turbo C env. With respect to the first question - the problem is that one has to use "cprintf" not "printf" when writing to the console and you want to get color text out instead of the default color. Yes, it does say in the manual that one should use cprintf, but when it says use functions *like* cprintf, I would think other functions would work too. I was incorrect in that assumption. Oh well (that's what I get for not reading the fine print...) With regards to the question about return value of the "system" call, it will always return a TRUE value if it can find the command processor, and only if it can't will it return a FALSE. A couple of people suggested using "spawn" instead, however, I haven't been able to get spawn to run some of the "built-in" commands to DOS (like dir and the like). If there's a way to spawn something like that I'd be more than willing to punt the system call. ------ Now for the next questions - how - in TC - do I put the screen of an EGA/VGA into 43/50 line mode (yes - I've read the manual and it makes no mention of it that I can find!), and having accomplished that, how do I move the cursor to a location beyond the 25th line boundary? I've got another program that puts the screen into 50 line mode on my VGA setup, but gotoxy refuses to move the cursor past the 24th line on the display, and just ignores the command I issue to do so. Gettextinfo also reports the display is 25 by 80 when it's in 50 x 80 mode. ---- Thanks for the comments so far - once I get answers to these quesitons I should be ok for the rest of what I want to do. ------------------------------------------------------------------------------ Timothy D. Kuehn TDK Consulting Services 871 Victoria St. North, Kitchener, voice: (519)-741-3623 Ontario, Canada N2B 3S4 DOS/Xenix - SW/HW. uC uP RDBMS timk@xenitec.on.ca !watmath!maytag!xenitec!timk No disclaimer here - I *am* the company! ------------------------------------------------------------------------------
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (04/11/90)
In article <2718@unocss.unomaha.edu> ho@fergvax.unl.edu writes:
$Would something akin to
$execl ("c:/command.com", "command", "/c", "dir", NULL)
$work? This should pull up command.com. The /c parameter makes command
$interpret its arguments as actual commands to execute, and return control
$when it's done.
It will work some of the time, but it's an extrememly bad programming
practice to hard-code the path and filename of the command processor,
especially when the correct version of this information is passed to
your program at run-time. The above will not work
- for machines booted from disks other than C (e.g. floppy boots, some
networks)
- for networks that boot from a remote drive C and then unlink that
drive (we have such a network here at McMaster)
- for machines booted from directories other than the root directory
- for machines using a COMMAND.COM substitute such as 4DOS, although
one might want to use COMMAND.COM specifically for this if you're not
sure that the replacement has the command you want
- if you try to port your program to another OS
If you want to run internal commands, why not just use system ()?
If you don't want to, then you should at least use the COMSPEC
environment variable to determine the path for the command processor.
You can access environment variables with the getenv () function.
--
More half-baked ideas from the oven of:
****************************************************************************
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate ... for now!\n";