insufficient memory for tsr

sir,
while writing my first TSR programme ,upon compiling it
gives the error message as insufficient memory.i was writing a
TSR for keyboard interrupt.it said your mem is 640k/remove
mem. resident prog/or use machine with more memory.i have
celeron 366mhz with 96mb ram,4.2gb hdd.in all TSR progs it
is giving same error message and prog does not runs.
what should i do?.

You say "TSR", I think "Tactical Studies Rules". Unless you're making some sort of strategy RPG, I have no clue what you're talking about.

let's see program doesn't have an e on it in your context. What is TSR program? Could you iterate more on what it is or show some code please? That is the only way we can help.

I think, manmohan means the following:

TSR (Terminate and Stay Resident) - Application loaded into memory to provide fast access. Well behaved TSR's will reside in memory while other applications are active.
source

TSR's run in high memory or in the HMA - in real mode the memory space between 640KB and 1024KB.

Since to run a TSR you must invoke keep() in C or DOS INT 21h - subfunction ?? (I forget) then I'm assuming you are in real mode.

You can get this error if you do not have enough HMA - possibly as a result of HIMEM.SYS not being loaded or perhaps you have too many devices loading into upper memory. Check to see how many UMBs have already been allocated.

As well your section of code that is to be placed into high memory as a TSR should be very very compact. Only store what is needed - hence any outside data within the data segment does not need to be in high memory - only the code that needs to execute.

Also do not call any interrupts from within a TSR unless you know that DOS is not currently executing one or that the CPU is not currently inside of an interrupt. This will cause DOS to re-enter itself and crash. DOS is not a re-entrant OS.

The main problem is that your OS only looks like DOS on the outside, but is in fact nothing like DOS on the inside.

TSRs became obsolete when M$ finally got around to supporting an OS which was capable of running more than one process without lots of trickery.

But since you are invoking a TSR I'm assuming that you are not in Windows. Yes, you can load TSRs in Windows prior to Windows booting up, but no it is not a good idea.

Best place for TSRs is pure DOS - for Windows check into writing programs that reside in the system tray. They are not true TSRs, thankfully, but they are the closest thing to it. But since every program in Windows is given their own slice of time on the CPU, you really cannot call them TSRs - they are simply programs that are constantly being task switched - like everything else running at that time. Only difference might be the priority placed on system tray programs.

I beg to differ. I wrote a TSR program back in the DOS days that in a console window on XP still works as written.

Here's a link to the program and it's source:
http://wpattinson.com/capslk.zip

Sure it might have worked but that is not always the case. I would not recommend loading any TSRs while inside of Windows - the entire setup is totally different.

Since DOS is merely emulated in Windows 98SE - albeit a very robust emulation unlike XP, loading TSRs is usually something that does not work well. For instance many older games that loaded drivers into the HMA for the sound to work do not work under XP - Silent Hunter is an example of one of these.

According to the DOS 6.20 tech ref manual TSRs are managed solely by DOS - which is impossible inside of a DOS session.
Also most TSRs are interrupt driven or need to be invoked somehow in DOS - either by a keypress or something like that. They are not truly running at all times in the sense of multi-tasking. DOS is not task switching for the TSR like Windows does.

You might get away with it for some applications of TSRs, but 9 times out of 10 I would say it is dangerous and that it will fail at the very least or cause some other problem later.

Now TSRs do not have to reside in the HMA - I was getting them confused with drivers.

Here is some info from the manual:

A terminate and stay resident program (often called a TSR) returns control to its parent program without relinquishing the memory that contains its code and data. The TSR program stops running, but its code and data remain in memory to be used by other programs.
...
...
...
Interrupt 21h

Function 31h - Keep Program

mov dx,MemSize ;number of paragraphs to keep
mov al,ReturnCode ;code returned by terminating program
mov ah,31h ;Keep Program
int 21h ;int 21h - call DOS

Keep Program (Function 31h) ends the current program by returning control to its parent program but leaves (keeps) the program in memory and preserves the program's resources, such as open files and allocated memory.

MemSize
Specifies the number of paragraphs of program code and data to keep in memory. If this parameter is less than 6, the function sets it to 6 before reallocating program memory.

ReturnCode
Specifies the code that is returned to the parent program. If the program terminates normally, ReturnCode should be 00h.

This function does not return.

This function carries out the following actions:

• Reallocates program memory to the amount specified my MemSize. Program memory includes only the program segment prefix (PSP) and program data and code. The reallocation does not affect the program's environment block, nor does it affect the memory allocated by the program after it was loaded.
• Flushes the file buffers but leaves files open. Any locked regions in the open files remain locked.
• Restores Termination Address (Interrupt 22h) from offset 0Ah in the PSP (pspTerminateVector field).
• Restores the address of the CTRL+C Handler (Interrupt 23h) from offset E0h in the PSP (pspControlCVector field).
• Restores the address of the Critical-Error-Handler (Interrupt 24h) from offset 12h in the PSP (pspCritErrorVector field).

After completing these actions, this function transfers execution control to the address specified by offset 0Ah in the PSP.

See Also:
Function 4B00h - Load and Execute Program
Function 4Ch - End Program
Function 4Dh - Get Child-Program Return Value
Interrupt 22h - Termination Address
Interrupt 23h - Ctrl+C handler
Interrupt 24h - Critical Error Handler

So you see a lot more is going on under the hood. Windows is not going to like any of it.