Path: utzoo!attcan!uunet!cs.utexas.edu!wuarchive!udel!princeton!idacrd!mac
From: mac@idacrd.UUCP (Robert McGwier)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: TSR's with no assembly language
Message-ID: <645@idacrd.UUCP>
Date: 20 Mar 90 16:35:24 GMT
References: <2610@unocss.unomaha.edu>
Distribution: na
Organization: idacrd, princeton, nj
Lines: 47

From article <2610@unocss.unomaha.edu>, by ho@fergvax.unl.edu (Tiny Bubbles...):
> From article <9771@wpi.wpi.edu>, by jhallen@wpi.wpi.edu (Joseph H Allen):
>>>writes:
> 
> Frankly, I'm getting sick of all the Turbo/MSC/etc. fighting.  Stick it in
> alt.flame or something.  It's all been heard before, several times...
> 
> Also, how do you find out where your TSR "ends" (so you can feed the right
> paragraph back to DOS in the TSR call)?


_PSP is a variable recognized by MSC 5.1 and I <<ASSUME>> it is also
recognized by Turbo C.  You can then take the tiny assembler fragment
posted here earlier and essentially emulate it in C.  The only time
my TSR's are really big are when I load floating pointing emulation
routines in.  I have a complete satellite tracking system, written
as a TSR, computes on the timer tick, and aims the antennas at the
satellite.  This is 16K and is full of floating point.  DO NOT FORGET
THAT IF YOU USE THE COPROCESSOR in a TSR you must first preserve
the entire state of the coprocessor of the running process and then
reinstate the TSR's state.  The inverse of this must be done on exit.
If your code can blow up, you must also steal the divide by zero and
other floating point exceptions only during the time you are executing
unless you want to have your TSR's foul ups trapped by another running
program, etc.  I find writing TSR's in C to be extremely easy in MSC 5.1,
with just a few rules such as I have pointed out here.  I have even made
use of the DOS critical section flags, etc.

On MSC 5.1 and far malloc, I have written another package, which does malloc,
frees, reallocs, etc, 58000 byte blocks and I have NEVER ONCE seen it
fail in the large model.  The total code used is 320000 bytes and I
have yet to have a single problem with MSC 5.1. I have Turbo 2 but just
can't seem to find the time to learn its vagaries and move the any code
over in order to test whether or not it is truly better or worse.  I
did find a bug in strrchr which others on the USENET have made postings
about and have fixes to the Turbo C library for this function.  IMHO,
the support from all of the compilers for Large model programs still
leaves a bit to be desired.  I am anxiously awaiting my update card to
arrive for Microsoft C 6.0.

Bob
 
-- 
____________________________________________________________________________
    My opinions are my own no matter	|	Robert W. McGwier, N4HY
    who I work for! ;-)			|	CCR, AMSAT, etc.
----------------------------------------------------------------------------