-=> /* Quoting Mike Bilow to Frank Sexton */ <=-

 MB> The DOS4GW extender works by using the LE-format EXE, similar to the
 MB> NE-format originally defined for old Windows and OS/2 1.x, in order to
 MB> make DOS load the "real mode" stub.  OS/2 looks at that EXE and
 MB> thinks, "Oh, wow, a native OS/2 program that I don't
understand!" and
 MB> tries to handle it accordingly.  To override this behavior, just force
 MB> OS/2 to invoke COMMAND.COM first: 
 
 MB> COMMAND /C EXTPROG.EXE
 
 FS> Thanks for this explanation Mike.  I tried the above method
 FS> on my own WC 10.5 DOS4GW app from an OS/2 (Warp) command
 FS> line and it didn't work.  However, if I run it from a Batch
 FS> file (bat) from an OS/2 session it does work.  Running from
 FS> a DOS VDM always works just fine.  Is there anything that I
 FS> can do to prevent me from having to run it via a batch file
 FS> from an OS/2 window?  Something simple that is (smile). I'm
 FS> a real amateur at this.

 MB> It should work; it works here when I try it.  Maybe you need to make
 MB> sure that DOS4GW.EXE is in the DOS PATH set in AUTOEXEC.BAT, which can
 MB> be different from the OS/2 PATH set in CONFIG.SYS.  I assume that your
 MB> remaining problem is somewhat simple once you find it.

Absolutely!  It was something simple.  I had a copy of the
"real" MS-DOS COMMAND.COM in my root directory (left over
from the 2.0 Dual Boot instructions telling me to have my
Autoexec.bat copy it to my root directory each time I Dual
Boot).  Anyway, then, I *accidentally* had my root
directory listed *before* C:\OS2\MDOS in my OS/2
CONFIG.SYS.

I.E. (C:\OS2\INSTALL;C:\;C:\OS2\MDOS;)

Walla... my COMMAND command kept finding the real MS DOS
version of COMMAND.COM instead of the MDOS version.  After
re-ordering my OS/2 path, all is well.  Thanks!

-Frank

--- Blue Wave/RA v2.20