Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!midway!ellis.uchicago.edu!cjdb From: cjdb@ellis.uchicago.edu (Charles Blair) Newsgroups: comp.os.msdos.programmer Subject: Re: MS-DOS EXEC Question Message-ID: <1990Sep21.031756.7005@midway.uchicago.edu> Date: 21 Sep 90 03:17:56 GMT References: <1990Sep7.144359.25202@jarvis.csri.toronto.edu> Sender: news@midway.uchicago.edu (News Administrator) Organization: The University of Chicago Lines: 23 In article mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >[...] >Also, PLEASE don't hardcode "C:\COMMAND.COM" into your program. Not >only does it prevent people who don't have a hard disk from using your >program (if you think they're rare, what about people with diskless >workstations or computers with a floppy only, who run stuff off the >network?), but it prevents people from using an alternate command >processor, such as 4DOS, with your program. I'd suggest that you grab >COMSPEC from the environment and try to load that, and only try to >explicitly spawn COMMAND.COM if COMSPEC doesn't exist. Maybe try grabbing SHELL next? I run the MKS toolkit, and frankly I'd prefer it if programs grabbed shell first, since COMSPEC is set to c:/command.com, and SHELL is set to c:/bin/sh.exe. But this is just peculiar to my setup. When I get command.com, I just run sh.exe on top of it, but it wastes some memory. -- Bitnet: pmrcjdb@uchimvs1 Internet: cjdb@midway.uchicago.edu