Hello Jonathan;

Here is a copy of my correspondence with Jim Read, the
owner/programmer of FileStar/2 on your assessment of the file
recognition capabilities of his code.

[ BEGIN Quote]

From jread@gte.net Mon Nov  8 00:24:14 1999
Date: Thu, 04 Nov 1999 19:00:13 -0600 (CST)
From: Jim Read 
To: Darren Hamilton 
Subject: Re: FileStar/2 programming error

On Thu, 4 Nov 1999 10:10:18 -0800 (PST), Darren Hamilton wrote:

>I have been corresponding to Jonathan de Boyne Pollard in England via the
>Fidonet OS/2 echomail conference. He has found a programming error in
>FileStar/2. I have included his last message to me on the subject of
>detecting file types. Could you have a look at your FileStar code and see
>if it needs modification?
>
>FileStar/2 is badly programmed.  It sees that a file is a Linear Executable 
>
>FileStar/2 is being too simplistic, and is thus getting things wrong.

I have looked at the code and it is correct as far as I am concerned.
It may be 'too simplistic' to depend on OS/2 programming APIs, of
which some are 'badly programmed', to get things right but most of us
do. There is a function call to OS/2 named DosQueryAppType. It returns a
ULONG memory variable which must be masked to determine the app type.
This is from the docs: DosQueryAppType API Description:
   
pFlags (PULONG) - output 
A doubleword that will contain flags denoting the application type, as
determined by reading the executable file header specified by pszName.
Note that the call sequence passes a pointer to a location in
application memory to return the application type flags. 
pFlags is defined as follows: 
Bit       Description 
2-0       Indicate the application type as specified in the header: 
   000   FAPPTYP_NOTSPEC (0x00000000) 
         Application type is not specified in the executable header. 
   001   FAPPTYP_NOTWINDOWCOMPAT (0x00000001) 
         Application type is not-window-compatible. 
   010   FAPPTYP_WINDOWCOMPAT (0x00000002) 
         Application type is window-compatible. 
   011   FAPPTYP_WINDOWAPI (0x00000003) 
         Application type is window-API. 
   3     FAPPTYP_BOUND (0x00000008) 
         Set to 1 if the executable file has been "bound" 
         (by the BIND command) as a Family API application. 
         Bits 0, 1, and 2 still apply. 
   4     FAPPTYP_DLL (0x00000010) 
         Set to 1 if the executable file is a dynamic link 
         library (DLL) module. Bits 0, 1, 2, 3, and 5 will be set to 0.

   5     FAPPTYP_DOS (0x00000020) 
         Set to 1 if the executable file is in PC/DOS format. 
         Bits 0, 1, 2, 3, and 4 will be set to 0. 
   6     FAPPTYP_PHYSDRV (0x00000040) 
         Set to 1 if the executable file is a physical device driver. 
   7     FAPPTYP_VIRTDRV (0x00000080) 
         Set to 1 if the executable file is a virtual device driver. 
   8     FAPPTYP_PROTDLL (0x00000100) 
         Set to 1 if the executable file is a protected-memory dynamic 
         link library module. 
   9-13  Reserved. 
   14    FAPPTYP_32BIT (0x00004000) 
         Set to 1 for 32-bit executable files. 
   15    Reserved. 
  
When CMD.EXE is queried with DosQueryAppType, it returns 0x00004002.
Simply put that is a 32-bit window-compatible executable file.
As a cross-check, I looked at the file with FM/2 (yes, I have a
unregistered version that I sometimes use to check things like this
with but I don't use it for anything else) and StarDock's Process
Commander. They both report that CMD.EXE is a 32-bit file.
Of course, Jonathan de Boyne Pollard is correct in what the header
file says. But FS/2 and others are only reporting what OS/2 tells it.
BTW, the CHKDSK32.EXE file is reported to be 16-bit on my system and,
looking at its header, I would say that's right. It's not a perfect
world :-((.

End of my investigation :-)). But thanks for the concern and query.
And please report any other observations that seem wrong. I am far from
perfect in programming.

Jim
 
[END Quote]

Do you have any comments on Jim's assessment of the situation?


Regards,

Darren Hamilton

School of Library and Information Studies
The University of British Columbia

Internet e-mail: darrenah@interchange.ubc.ca

 * KWQ/2 1.2i * AMD Athlon: Proof that Intel isn't working hard enough.

--- Maximus/2 3.01
7102/1