Thread: insufficient memory for tsr

  1. #1
    Registered User
    Join Date
    Dec 2003

    Unhappy insufficient memory for tsr

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

  2. #2
    Registered User
    Join Date
    Dec 2003
    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.

  3. #3
    Registered User linuxdude's Avatar
    Join Date
    Mar 2003
    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.

  4. #4
    Registered User Sargnagel's Avatar
    Join Date
    Aug 2002
    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.

  5. #5
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    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.

  6. #6
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    The edge of the known universe
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  7. #7
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    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.

  8. #8
    Been here, done that.
    Join Date
    May 2003
    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:
    Definition: Politics -- Latin, from
    poly meaning many and
    tics meaning blood sucking parasites
    -- Tom Smothers

  9. #9
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    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.

    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.

    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. available memory from task manager
    By George2 in forum Tech Board
    Replies: 10
    Last Post: 01-18-2008, 02:32 AM
  2. Replies: 4
    Last Post: 01-13-2008, 02:14 AM
  3. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 01:57 AM
  4. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 11:22 AM
  5. Shared Memory - shmget questions
    By hendler in forum C Programming
    Replies: 1
    Last Post: 11-29-2005, 02:15 AM