VB>I have 4dos setup as primary shell in my config.sys file...
VB>shell=c:\4dos\4dos.com c:\4dos /P
VB>In win95 I have a shortcut desktop icon setup to run 4dos, 
VB>because for some reason even though it's the primary shell 
VB>it doesn't automatically run when
VB>I open a dos prompt.
VB>Doing it this way I'm also able to open a normal MSdos box from win95 u
VB>the normal dos prompt menu option.  But the only problem I 
VB>had with this was MSDOS didn't like my 4dos prompt too 
VB>much. In the prog properties for the dos prompt where the 
VB>command line etc is specified there's a section to setup a 
VB>batch file which is automatically run. I thought I'd use 
VB>this to change the prompt to something command.com can 
VB>handle. Problem is that whenever I specify anything here 
VB>4dos always starts instead of command.com, no matter what!
VB>It doesn't matter that command.com is specified as the program command 
VB>as soon as I specify a batch file/command to be run 4dos 
VB>starts instead of command.com!   The only way I've found to 
VB>get around this is to use the /K switch after the command 
VB>line.  Is this a win95 problem or something wrong with how 
VB>I've setup 4dos?
Hi, Vic.  Your problem is a consequence of how W95 executes batch
files.
By default, W95 uses the COMSPEC environment variable to find the
command processor when a batchfile is called in a DOSbox PIF.
Since you load 4DOS through the SHELL statement in Config.Sys,
COMSPEC points to 4DOS.COM and those services are used for 
batchfiles.
Using the /K switch on the command line in the PIF overrides
the use of COMSPEC to load the batchfile -- permitting the
use of COMMAND.COM as the shell for a batchfile rather than
the command processor pointed to by COMSPEC.
Note: Open a 4DOS window.  Type SET in that window and look
      at the COMSPEC variable.
      Now type COMMAND in that window.  Watch as the COMMAND
      processor loads over 4DOS.  
      Now type SET again and look at COMSPEC.  See how the
      COMSPEC variable tracks the active command processor?
      Now type Exit to close the COMMAND processor and return
      to 4DOS.
      Type SET again and look at COMSPEC.  Back to 4DOS, as
      consistent with the active command processor, just as
      it should be.
The above works fine as long as the methodology described
above is used.  However, things break down if you make an MS-DOS
PIF loading COMMAND.COM without the /K switch, when using 4DOS
as the primary shell.
Since the COMSPEC environment variable in the master environment
(which the COMMAND.COM shell inherits) is still pointing to 4DOS.COM,
a PIF pointing to COMMAND.COM without the /K parameter is schizoid.
Note: See the "MSDOS 6.22" Helpfile for further info on the
      requirements for the /K parameter in Windows PIFs.  Type
      "Help" from the Command.Com DOSbox for further info.
      The DOS7 helpfiles are installed in the WINDOWS/COMMAND
      folder -- data as follows:
      HELP     COM           413  07-11-95  9:50a HELP.COM
      HELP     HLP       301,961  07-11-95  9:50a HELP.HLP
      
      These files are found on W95 systems with the Supplemental
      Utilities installed from the W95/W95A CD-ROM or with the
      appropriate CD-ROM Addons downloaded from the MS website.
      Please note the W95 version of the Helpfile is NOT identical
      to the real MSDOS 6.22 Helpfile, which has data as follows:
      HELP     COM           413  05-31-94  6:22a HELP.COM
      HELP     HLP       299,832  05-31-94  6:22a HELP.HLP
If you wish to use a full COMMAND.COM DOSbox with 4DOS as your
default shell, using COMMAND.COM as the batchfile processor in
that DOSbox, then make a dedicated PIF as follows:
C:\WINDOWS\COMMAND.COM /K (OPTIONAL BATCHFILE>
Default Folder: as desired.
Batchfile: CANNOT BE USED IN PIF WITH ALTERNATE SHELL
           
Voila, a *real* COMMAND.COM DOSbox with all its
limitations, operating with 4DOS as the primary
shell.
Potential Gotchas:
1. As noted above, once a PIF opens a DOSbox on the
   desktop or fullscreen, subsequent batchfiles and
   subshellloads/unloads can be performed at will.
   It is only the batchfile-load process for the
   opening of the PIF which is limited in scope.
2. Do NOT leave a DOSbox open while editing its
   PIF.
   If you do, the PIF properties of the open
   DOSbox will overwrite your changes when that
   DOSbox window is closed.
3. Edits to a DOSbox PIF will not be saved until
   cached info is written back to disk.
   Ensure that you wait for the DOSbox PIF's icon
   to "blink" before you re-open an edited dosbox
   PIF.  (normally 2-3 seconds)
Best I can do for now. 
Bill
___
 * PW * 
--- Maximus 2.02
---------------