DM>
  > DM>
  >   > JdeBP> C++ and EMXLOAD does for EMX C++.
  >   >
  >   > I would like to know how this is done - see if it can be
  >   > done for Watcom as well.  :-)
  > DM>
  >
  >  JdeBP>   Use the EXEC_LOAD flag to DosExecPgm.  It's that simple.
  >
  > Hey, neat.... :-)  Now, how would I UNLOAD it?
DM>

  DosKillProcess + DosWaitChild.

  EMXLOAD misses out the DosWaitChild step, and it's my belief that that
  is the cause of the "kernel bug" that is mentioned in the source, since
  I experienced similarly strange effects when I forgot the DosWaitChild
  in HCLOAD.

  Not that I trust system API calls using EMX C++ any more, since it
  appears that EMX wraps them.  How else to explain that

         DosExecPgm(..."gcc"...)

  mysteriously appends a ".exe" to the end of the program name ?  The only
  other explanation that I can think of is that the supplied source to
  EMXLOAD isn't the *actual* source.

  If the system API calls *are* wrapped, then EMX users don't have a leg
  to stand on when complaining of kernel bugs.  Who's to say that the
  "kernel bug" mentioned isn't simply a problem in the system API wrapper
  that EMX interposes ?

DM>
  >                                                 And how
  > would I monitor its use so that I don't unload it while
  > it's still being used?
DM>

  OS/2 will monitor its use.  No need for you to do so.  The code will
  remain "loaded" until the last process using that code exits.

DM>
  >                         Would the IDE still be able to call
  > the pre-loaded version - without unloading it?
DM>

  The pre-loaded version isn't called at all.  What pre-loading does is to
  eliminate all of the time that the OS/2 process loader would otherwise
  spend creating module images and searching along LIBPATH for DLLs. It
  also helps carry over the working set information for the process to
  successive invocations of the program.

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