Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bu.edu!m2c!wpi!jhallen
From: jhallen@wpi.wpi.edu (Joseph H Allen)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: TSR's with no assembly language
Message-ID: <9899@wpi.wpi.edu>
Date: 20 Mar 90 09:24:21 GMT
References: <2610@unocss.unomaha.edu>
Reply-To: jhallen@wpi.wpi.edu (Joseph H Allen)
Distribution: na
Organization: Worcester Polytechnic Institute, Worcester ,MA
Lines: 71

In article <2610@unocss.unomaha.edu> ho@hoss.unl.edu writes:
>From article <9771@wpi.wpi.edu>, by jhallen@wpi.wpi.edu (Joseph H Allen):
>> In article <924@ns-mx.uiowa.edu> troj@icon.weeg.uiowa.edu () writes:
>>>In <10125@portia.Stanford.EDU>,  dma@nova.stanford.edu (Domingo Mihovilovic A)
>>>writes:

>But I *am* intrigued by assertions that you can write TSR's with no
>assembly, by both languages.

>It would seem, to my untrained mind, that using any high-level language to
>write a TSR would eat up amazing amounts of memory to hold the run-time
>library.  Even the most basic TSR requires a certain amount of run-time
>kernel, on the order of a few K... doesn't it?

>Also, how do you find out where your TSR "ends" (so you can feed the right
>paragraph back to DOS in the TSR call)?

Use tiny model and peak into the paragraph prior to the PSP.  You can subtract
out _stklen and part of _heaplen to make it even smaller.

Turbo C requires a minimum of 1742 bytes to run.  Included will be the memory
allocator and command line parameter routines.  Whatever you do, don't use
printf.  It adds 6K.  If you're a real minimist you can make it less by
replacing c0t.obj with this:  

_TEXT   SEGMENT BYTE PUBLIC 'CODE'
_TEXT   ENDS
_DATA   SEGMENT WORD PUBLIC 'DATA'
_DATA   ENDS
_BSS    SEGMENT WORD PUBLIC 'BSS'
_BSS    ENDS
_LAST   SEGMENT WORD PUBLIC 'LAST'
_LAST   ENDS
DGROUP  GROUP _TEXT, _DATA, _BSS, _LAST

_TEXT   SEGMENT BYTE PUBLIC 'CODE'
        ASSUME  CS:_TEXT,DS:DGROUP,ES:DGROUP,SS:DGROUP
        org     0100h
start:
        extrn   _main:near
        jmp     _main
_TEXT   ENDS
_LAST   SEGMENT WORD PUBLIC 'LAST'
        public  _top
_top    equ     $
_LAST   ENDS
        end     start

The size of the program is the address of '_top'.  But of course, this is
cheating...  but then 1 assembly language instruction isn't all that bad.
Also most of the turbo C library won't work, but the C support functions for
far pointers, structure copying and longs will.  These are the support
object modules if you want to really trim down cs.lib:

SCOPY LXMUL DIVT LDIV LDIVT LROTL LROTR LRSH LLSH LURSH SETJMP SPUSH ROTL ROTR

(I also include SETJMP as being part of the C language and not part of
library).

The one include file that you really nead is dos.h.  It prototypes the rest of
turbo C's features which are really language features, not library.

Best of all... the debugger still works in this very tiny model.

With a slightly different startup module you can even make device drivers
(you have to change the stack to get this to work so it isn't very pretty).
I'm curious about the Microsoft C equivelent of all this is.  I didn't even
know MSC had pseudoregisters- this is a new addition in MSC 6.0 is it not? 
-- 
            "Come on Duke, lets do those crimes" - Debbie
"Yeah... Yeah, lets go get sushi... and not pay" - Duke