Retro video games delivered to your door every month!
Click above to get retro games delivered to your door ever month!
X-Hacker.org- Warplink version 2.6 - <b>/oht:[-]size overlay stash in xms extended memory.</b> http://www.X-Hacker.org [<<Previous Entry] [^^Up^^] [Next Entry>>] [Menu] [About The Guide]
/oht:[-]size  Overlay stash in XMS extended memory.
---------------------------------------------------------------------------------

 Syntax:

 Use - to leave memory free.  Size is the size of the overlay stash in
 kilobytes.  It can range from 0 to 16383.

 This option stashes the overlay file to XMS memory at runtime.  The
 overlays are stashed as they are loaded for the first time in the overlay
 pool, as memory allows.  Thereafter when reloaded, the overlay will be
 brought in from XMS memory rather than from disk.  Stashing can
 provide substantial speed increases in the executing program.  Partial
 stashing of some overlays in the overlay file may occur if there is not
 enough memory to stash all of them.  Overlays are stashed on a first
 loaded, first stashed-as-fits, basis.  /oht overlay file stashing will not
 occur if the overlay manager detects less than 80K free XMS or an XMS
 driver is not present.

 Use a minus sign (-) to leave the amount free.  For example, /oht:-1024
 means leave 1024K (1M) for the executing program and use the rest for
 stashing overlays, up to the space required.  The overlay manager will
 not take more XMS memory than it needs even if you specify more with
 the /oht option.  For example, if you specify /oht:4096 and the overlay
 manager only needs 640K to stash the entire overlay file, the overlay
 manager will allocate only 640K of XMS.  All XMS memory allocated
 for use by /oht is automatically freed at program termination.

 /oht is more useful in a generic sense than /ort but both can be used
 simultaneously.  /ort will stash an exact image of a swapped-out active
 overlay for return swap-in, eliminating the need for the overlay manager
 to process and fix up overlay offsets when the active overlay is brought
 back in.  Typically, you will find a much greater speed increase with
 /oht stashing, but /ort can also speed up a program if there are many
 active overlay swap-outs.  /oht allocates XMS after /ort does its 128K
 fixed allocation.  If you have a small amount of XMS, it is
 recommended that you use /oht rather than /ort.
 The /oht option has priority over the /ohp option if both are used.  If
 you specify both the /oht and /ohp options, XMS overlay stashing will
 be used unless at least 80K of free XMS is not available, at which time
 the WarpLink overlay manager will attempt to use EMS for stashing. 
 You may wish to specify both options if your program will be operating
 on a mix of machines that may have either EMS or XMS memory.

 Clipper User Note:

 An initial setting of oht:-512 for Clipper programs is recommended.
 This guarantees 512K of XMS remains for your program, plus whatever
 may be left over from stashing the overlay file.  Clipper cannot use
 XMS directly, but many memory managers, such as QEMM and
 386^Max, automatically convert XMS to EMS.  It is not recommended
 that a Clipper 5 program not have EMS available to it during execution. 
 If your program has no need for XMS or converted EMS, then use a
 large /oht setting to stash the entire overlay file.  For example, use a
 setting of /oht:9000.

 If you use the /oht option, the Clipper 5 debugger CLD.EXE will not
 function with your program.  Use WarpMod to turn this option off and
 on quickly, if necessary.



See Also: ort

Online resources provided by: http://www.X-Hacker.org --- NG 2 HTML conversion by Dave Pearson