BW> Since I'm running Connect with FP40, it seems reasonable to suppose
 BW> that cmd.exe had been updated to 32-bit.

Unfortunately, for those that have paid close attention to where IBM has
concentrated its development efforts over the years, no it isn't reasonable at 
all, it is sad to say.

IBM's 16-bit CMD hasn't had any major changes made to it since the days of
16-bit OS/2.  In the transition to 32-bit in OS/2 version 2.0 the START
command gained a few extra options, and that was it.  CMD remained pretty much 
unchanged otherwise.  The only things that have changed in it since are the
special cases for the BEGINLIBPATH and ENDLIBPATH "environment variables". 
Even then, IBM modified the 16-bit system API to add two new functions for the 
16-bit CMD to use, rather than make CMD a 32-bit program so that it could use
the 32-bit system API.

IBM should not be discredited for the massive undertaking of making much of
OS/2 32-bit.  Presentation Manager and the GRE, both of which are large bodies 
of code, are 32-bit.  But IBM concentrated on a few prominent areas, and has
never fully completed the job.  Many things in OS/2 Warp 4 remain 16-bit. 
IBM's CMD is one such thing.

For some of the 16-bit vestiges still remaining in OS/2 Warp 4 there are
32-bit replacements.  For example, IBM's 16-bit SORT command (which, because
of its 16-bitness, cannot handle files over 64KiB) can be replaced by the
32-bit SORT command from the OS/2 Command Line Utilities version 2.0 (which
has no such 16-bit limitation).  Along the way, one gains several extra
features (such as the ability to specify files to be sorted on the command
line).  Similarly, IBM's 16-bit TREE command can be replaced by the 32-bit
TREE command from OS2CLU.  And again, one gains several benefits on the side
as well.

The 32-bit CMD allows us to rid ourselves of one more of these 16-bit vestiges 
in OS/2 Warp 4.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
633/260
2501/209