>Here is an interesting twist that I've come up against. Running the app as:
>\\AAAA\BBBB\CCCC\DDDD\EEEEEEEEE\FFF\GGG.EXE cause the app to fail stating that it could not find the necessary DLLs. Reducing the path by one letter launched the app without incident.

There is a limit to the size of the space allocated to hold DOS environment srings for each VDM; this size is by default relatively small. Running out of environment space will cause environemtn strings to get truncatedin unprdicatable fashions when environment variables are added or altered, which couldcuse this behavior if the PATH environment variab;e for the VDM is being shortened; the PAH affects what directorieswill be searched when a DLL is called for without giving the full path for the file. If you thin this may be happening, the spaceset aside to hold the environment strings is specified under Win9x by the SHELL entry in the CONFIG.SYS file;

SHELL=C:\Windows\COMMAND/COM /P/E:2048

tells the OS to use C:\Windows\COMMAND.COM as the systems command line interpreter (CLI), the program which acts as the OS's basic console application which the OS uses as the basic host of console command modeactivities (IOW, the program that you send DOS commands to, processes batch files, etc. It also has all the code for the "internal" console commands such as COPY, ERASE, CD etc built into it, so that when you issue the command line:

ERASE some file name

at the command line the CLI actually does it by itself without loading some other program first.

This is why many "simple" DOS commands may refuse to run from a facility such as the VFP RUN command - there's no executablefor the command, so it can't get started! In order to use these internal commands, you have to trick the OS tostart a CLI for you, which executes the command. A coupe of simpleways of getting around this. The first is to explicitly start a temporary CLI to handle it. Instead of RUN ERASE FOO.TXT, try:

RUN COMMAND /C ERASE FOO.TXT

COMMAND /C tells the OS to start a temporary CLI, passing the rest of the line to the new CLI for it to handle. the /C will make the CLI terminate immediately after issuing the command; it would wait untilthe app gives control back to DOS. Note: This does not mean that whatever it starts completed. For examle, if it starts a WinApp, the WinApp isn't dependent on the CLI/DOS resources and functions after it has been loaded. DOS could start another job while many WinApps (or even while several other DOS sessions with their own copy of the CLI) run at the same time, in theory all happy as a clam...

NB: The CLI is not always COMMAND.COM; NT and Win2K use a program named CMD.EXE, which has lots of added features, although both have a COMMAND.COM which will offer a subset of the complete functionality of CMD.EXE, essentially for backwards compatibility purposes. The COMSPEC environment variable gives the name of the OS's current default command processor, and should be used to start any internal commands using RUN. It also will protect you from yourself if the PATH environment variablemght include folder with it's own copy of the CLI from a different OS version; if you do not specifythe full path for an executable, WIndows will search for it, and the resolts of running the wrong version of the CLI will be amusing at best, annoying or frustratingmuch of the time, and reallyugly at times (usually on Friday afternoon about 4PM, just before a long weekend, for some user you can't blow off, generally when it absolutely, positively has to be fixed before Tuesday morning. Statisticians have proven that there is an exponential relationship between the complexity of the system configuration and the occurance of the error, and an inverse relationship between the value of whatever data is on the machine and the age of the most recent backup.)

The second way to run internal commands from RUN is to build a batch file and run the batch file - .BAT (or .CMD files for systems that support them) start a new copy of the CLI, which executes the batch file and stops when the batch finishes. THe CLI may not always exit cleanly; as many people have found, the CLI will often wait for the user to close the console window by hand (this behavior is dependent on settings in the .PIF file that starts the DOS session; FOXRUN.PIF will be used for the VFP RUN command if no program-specific .PIF is found for the program/batch file being run; if no FOXRUN and no app-specific .PIF exists, or no app-specific .PIF and it was started by some other means than the VFP RUN command, the system default .PIF will be used. Constructing a .PIF file is a non-trivial, platform-specific and undocumented process, so programmatically handling the task isn't always easy.

The best documentation of the .PIF format is available from the www.wosit site and in a few books like "Windows Undocumented File Formats" by Davis and Wallace (R&D Publications, ISBN 0-87930-437-5); the docs are very incomplete, and are very involved. There are some platform-specific approaches to building .PIF files; for Win9x, there is a file APPS.INF which is used to create .PIF files for specific DOS applications on the fly if needed, and it can be modified to include other items. It's discussed in some detail in "Killer Windows 95" by Wyatt et al., published by Que; ISBN 0-7897-0001-8. Unfortunately, it is not in print AFAIK now, but you may find itusing some of the book sellers that specialize in getting out-of-print titles (expensive) or in the clearance sales bin of a local bookstore or computer store (the copy I have is from 1997.) Aside from this one section, cover from pp 426-434, there's nothing compelling or special about this book, but these 8 pages were well worth the $3.95 I paid when I bought it from the discard bin at CompUSA.

NB: I have lots of books floating around here; most people who have a life, limited shelf space, or an SO who would kill them for filling large walk-in closets with boxes of books and magazines long out-of-date probably won't own a copy, and unless you're a packrat, it's outdated and went out in the trash many moons ago. We're talking about someone with Intel's "Intel486 Microprocessor Family Programmer's Reference Manual" still on hand - not buried in a box in the bsement, but on the shelf here within 10' of the desk. Sick.