>Bill,
>
>I'm not sure if Ed's extensive answer has you all fixed up yet or not. The problem here turned out to be a hidden command.com in the root directory. You might try renaming or removing this file if you don't need dual boot on the box. Then the OS should find the right file to use in the Windows folder.
>

In addition, assuming that you're using the VFP RUN command, there's always the option to modify FOXRUN.PIF to start an instance of CMD.EXE rather than COMMAND.COM by default - the sole drawback here is that this would not work in Win9x settings, where there is no CMD.EXE

A better approach would be to use my API_APPRUN class instead of run - it invokes child processes via the CreateProcess() API call, which goes through some machinations to ensure that a valid CLI is started. The file is available for download in the Files section here on UT. It handles sorting out what to invoke much better than FOXRUN.PIF does in dual-boot scenarios.

>>That would be great. Since I sent the original message, I have found out a little more about the offending site. All other sites where this app is installed operate on PC's where DOS 6.22 was installed first, then Windows NT installed afterwards. This site, however, failed to install the DOS 6.22 first. The DOS app that is called by the batch file may be failing in that instance. The only reason I didn't follow this logic was that the DOS app worked fine in a CMD.EXE window whether called by the batch or not.