PE>
  > I shouldn't be able to specify the maximum # of file
  > handles allowed by default to a new process via my
  > config.sys, rather than my current option, which is to go
  > and disassemble every application I run, and put in a call
  > to DosSetMaxFH() (because the program author didn't).  Or
  > maybe replace cmd.exe with one of my own that does a
  > DosSetMaxFH().  It's completely bizaare.  Why is it so
  > convenient for DOS programs, and such a headache for OS/2
  > programs?
PE>

  Don't be silly.

  It's exactly as convenient in the one as in the other.  Setting FILES=
  in DOS doesn't affect the size of the file table in the PSP.  It affects
  the size of the *system* file table.  To change the size of the JFT in
  DOS, one has to make an INT 21h call.

  And the same holds true of OS/2 :  to change the per-process file table
  size, one calls DosSetRelMaxFH.  You cannot change the size of the
  system file table in OS/2 (it's not a fixed size), so there's no
  equivalent to the DOS FILES= in OS/2.

  Your gripe is with programmers who write programs that open lots of
  files, but that don't call DosSetRelMaxFH to increase their per-process
  file table size to accommodate this.  That's just poor programming
  practice.  Failing to expand the JFT on DOS using the INT 21h call (the
  default size for the JFT is 20) would have the same effect.

  I myself also have a gripe with idiot C runtime library writers who use
  statically allocated file handle tables, which means that even if you
  call DosSetRelMaxFH, the RTL doesn't let you open all of those extra
  files because it runs out of space in its internal tables.  But this is
  again poor programming practice, and is, in my experience, independent
  of operating system (Borland can screw up on any platform, it seems).

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01