Click above to get retro games delivered to your door ever month!

/os:<size>              Internal stack size
---------------------------------------------------------------------------------

 Syntax:

 Size is the size of the internal stack.  It can range from 1 to 63.

 Description:

 The /os option specifies the size of the overlay manager internal stack
 used to store information about active, but swapped out, overlays.

 The default value of 2 (same as /os:2) is generous enough for almost all
 overlaid programs.  Only if you have a program with deeply nested
 overlays and a small overlay pool relative to the overlays being loaded
 (and thus a great deal of swapping out of active overlays) may you need
 to increase the /os value.  Each size increment is quite large (1K), so
 even if an increase above the default is necessary, usually a setting of
 /os:3 or /os:4 will suffice.

 Do not change the /os setting without good reason and an understanding
 of the implications for your program. The default setting should be
 maintained in almost all cases.

 Do not confuse the /os setting with the /st setting.  The /st option
 specifies the size of your program's stack.  If you receive a stack error
 message from your program related to stack size, you should modify the
 /st option setting rather than the /os option setting.


 Technical Notes:

 The memory allocation size for the overlay manager internal stack
 specified by /os is one kilobyte times the count value.  For example, a
 setting of /os:4 consumes 4096 bytes of memory.  You may conserve an
 additional 1K of memory for your program by reducing the /os setting
 below the default value of 2 to a setting of 1 (/os:1).  This reduction will
 slightly increase the chance of an overlay manager internal stack
 underflow error.

 If the overlay manager internal stack is set too low, a fatal overlay
 manager error will occur, the overlay manager will display error
 message feedback, and the program will terminate execution.
 Programs which inadvertently go into an infinite loop that causes active
 overlay swapout may cause a fatal overlay manager error to occur.  For
 example, an overlay calls other overlays which in turn call other
 overlays which eventually call the first overlay without returning,
 restarting the infinite loop.  The fatal overlay manager error may occur
 before other symptoms related to the infinite loop become apparent
 because the internal stack will eventually underflow as more and more
 active overlays are swapped out.  Be aware of the potential for this
 situation as it indicates a problem in your program that needs correction. 
 It is not a problem with the WarpLink overlay manager or an indication
 that you need to increase the /os value.

----------------------------------[ Example ]------------------------------------

 Allocate only 2K for the overlay stack.  Link using a response file OVLTEST1.LNK.

   warplink /os:2  @ovltest1.lnk