CS> There is no "sticky bit" in OS/2, but it is easy enough to simulate
 CS> this simply by blocking a thread on a named semaphore or some other
 CS> IPC object so that you can cause the process to terminate if you
 CS> want to release the memory.

 AL> Care to write me a sample?

I haven't actually written anything to do this myself, but basically you
would just add a bit of code to your program to support a switch that would
do nothing but keep the EXE loaded by blocking a single thread on an event
semaphore.  Then write support for another switch that will trigger that
event semaphore so you can have a reasonable way of terminating the first
instance of the program.

 AL> I may want to have for instance Maximus stay in memory
 AL> all the time, so the BBS is started faster when a user
 AL> is put through by the mailer....

This is certainly doable if you have the source code for the BBS. I'd have
to think about how to do it without the BBS source code. Perhaps you could
start the progress using another program that runs it as a debugged child
using DosDebug() and then stop it shortly after it starts?  That seems a
bit ugly to me, however.

 AL> Could do that by running the mailer and BBS in
 AL> separate processes, but a 'sticky bit' equivalent
 AL> would be just as effective, and easier to set up.

Maximus and the mailer already run in separate processes, but they run in
the same session.  Why not just leave a local copy of Maximus running in
the background?


--- Maximus/2 2.01wb