JR> I have looked at the code and it is correct as far as I am concerned.
 JR> It may be 'too simplistic' to depend on OS/2 programming APIs, of
 JR> which some are 'badly programmed', to get things right but most of us do.

The problem here is that Jim Read hasn't understood either the history or the
purpose of DosQueryAppType.  He's thinking that it reports the "type of the
application".  It doesn't.  It reports the information that is required so
that the command interpreter, or indeed any other program, can decide how to
execute the application.  It reports the "type of the executable file format".

The "32-bit" flag, FAPPTYP_32BIT, does *not* mean that the application
contains 32-bit code, which is the implication (to users who aren't
programmers) of the display by FileStar/2, any more than the
FAPPTYP_NOTWINDOWCOMPAT flag means that the application contains code to use
the physical video buffer directly.  FAPPTYP_NOTWINDOWCOMPAT simply means that 
the application *could* be not window compatible.  The IBM command interpreter 
automatically forces the use of a full-screen session for such applications.

The FAPPTYP_32BIT flag was introduced in the move to the 32-bit API in OS/2
2.0.  What it *actually* indicates is that the application is in the new (at
the time) "32-bit" executable format, the Linear Executable format.  OS/2
version 1.x only understands NE (which, ironically, stands for "New
Executable") format executable files.  But the beauty of the LX executable
format was that it could be used for *both* 32-bit *and* 16-bit applications.

The FAPPTYP_32BIT flag, and all of the other flags, are there to indicate how
the command interpreter should attempt to run the application.  An application 
with the FAPPTYP_NOTWINDOWCOMPAT flag set should be started in a full-screen
session, *just in case*.  An application with the FAPPTYP_32BIT flag set
should, similarly, only be run on OS/2 version 2.0 or later, because OS/2 1.x
won't understand the LX executable file format, and that is what the flag
means.  It *doesn't* mean that the application itself is 32-bit.

As I said before, take a look at the actual contents of CMD.EXE with a tool
such as EXEHDR or TDUMP.  You'll find that it is a classic example of a purely 
16-bit application in "Linear Executable" executable file format.  *All* of
the sections in the executable are under 64KiB in size, they *all* have the
"16:16 ALIAS" flag set meaning that they must be loaded into tiled memory, and 
*all* of the fixups are "16:16 ALIAS" (or "offset16") fixups.  (Indeed, *all*
of the fixups are to 16-bit system calls, if you care to check their
ordinals.)

The fact that FileStar/2 says that CMD.EXE is "32-bit", simply because the
FAPPTYP_32BIT flag is set, is highly misleading to the non-programmer. 
Programmers will know that the "32-bit" designation refers to the executable
file format (and that, strictly speaking, the LX format is classed as mixed
16-bit/32-bit -- as opposed to, say, the PE format which is purely 32-bit --
so FileStar/2 is still not strictly correct).  Non-programmers will think that 
it means that the *application itself* is 32-bit, exactly as you did.

If FileStar/2 wanted to do things properly, to eliminate this confusion, it
would display executables without the FAPPTYP_32BIT flag set as "NE format"
and executables with the FAPPTYP_32BIT flag set as "LX format", because that
is what the flag actually means.

If it's any encouragement to Jim, this would be one in the eye for FM/2 and
Stardock Process Commander.  If someone were to come along in the future
saying "application X is 32-bit, because FM/2 and Stardock Process Commander
both tell me that it is", we could then respond by saying "Not according to
FileStar/2 it isn't.  FileStar/2 says that it *might* be 32-bit, but that it
could equally well be 16-bit, or a 32-bit/16-bit hybrid.  And FileStar/2 gets
this stuff right, unlike FM/2 and Stardock Process Commander.".  (-:

To briefly return to the initial topic of this thread, then:  

The CMD.EXE shipped by IBM with all versions of OS/2, up to and including OS/2 
Warp 4 with the latest fixpack, and almost certainly including WSfeB as well,
is an entirely 16-bit program, despite the erroneous information displayed by
programs such as the current version of FileStar/2.  It's another 16-bit
vestige in OS/2 Warp 4 that is in need of replacement.  JP Software's 4OS2 is
a mixed 32-bit/16-bit hybrid.  But there does exist a pure 32-bit CMD, for
32-bit OS/2, that contains no 16-bit code whatsoever.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
143/1