🚀 go-pugleaf

In article <1992Apr15.033850.16536@uwm.edu> markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:
>In article <oddt.4@sofus.dhhalden.no> oddt@sofus.dhhalden.no (ODD ROBERT TORJUSSEN) writes:
>>We've come so far in the development, that the 'prototype' tsr is up running 
>>and seems to work ok. We're started to add some 'features' to this tsr.
>>Among the things we want to do, is letting the tsr do some system-calls
>>(to activate/start an extern program).
>>
>>This is were the problems occurs. :-(
>>
>>When certain events occur, the tsr does an system call (C function: 
>>spawnlp()). But, for some reason the tsr is not able to launchthis child 
>>process. 
>
>If it's being run on a DOS, the problem is likely the DOS.  System calls are
>usually critical regions in DOS.  If two processes happen to be concurrently
>accessing the same critical region, they could destroy the integrity of the DOS.
>
>That might be the problem.

DOS is the problem. Whenever you run a renegade process under DOS,
(a TSR is a good example), DOS does not know of it's existence and
therfore can not do the required house keeping to make it behave
along with everything else. If you want to spawn another process or
do any kind of DOS system service calls, you have two choices:

1) You can call South Mountain Software (201) 762-6965 and order
Hold Everything, which is a TSR library to spawn context switching
on the fly under TSR's, or

2) You can build into your TSR the ability to save the sate of the
machine and DOs itself and handle the context switch, plus all the
associated house keeping needed to juggle multiple threads.

Having done both, I can recommend #1 as the greatest time saver and
least stress inducer. These guys have already done the home work.
Don't reinvent the wheel.