ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng)/ProfitPress-MegaCDROM2.B6I/BBS/NETMAIL/XRS45XT3.ZIP/OPTIMIZE.DOC

Text File | 1991-06-23 | 12.2 KB | 270 lines

  Please see the XRS*.DOC file for complete information on these settings!

  * * * * * * * *  These suggested entries must be made in "CONFIG.XRS" for
  * * NOTICE! * *  them to be effective.  The guidelines below should help
  * * * * * * * *  you optimize XRS and memory usage for your own machine!

ALSO NOTE: This document only discusses a very few parameters available to
be used in CONFIG.XRS, most of which are related to optimization of XRS on
your specific computer.  Please be sure to see CONFIG.NEW for recent new
parameters not discusses here which may be useful to you, and CONFIG.DMO
mentioned above, which is a 'model' for generic setup.


The recommendations below are everything I know about tuning XRS, and I
think I've done quite a bit of it over the past four years for people!  I
can't promise any of it will help if you don't read carefully, but I know
that if you do, your copy of XRS will be finely tuned to your personal
computer depending upon how much and what types of RAM you have available,
what type of diskettes or disks you have, etc.  These items all basically
fit into three areas - things you should (or shouldn't!) do, things people
commonly do wrong, and things most people want that are not defaults, but
extend the flexibility of the program.  XRS has grown from a very simple
program to one of almost infinite possible variations, and I will soon have
to write a free-standing "configure/setup" program, but for now this should
suffice!  Have fun, and let others know (via the "QMX_XRS" echo) how things
work best on your computer if the 'normal' options don't work well for you!
Please be sure to detail exactly *what* your hardware/software is so that
everyone can help you analyze your sitution!
                            Mike Ratledge





Swap X

  Is one of the most important options - especially if you want to use an
 external editor rather than the editor which I have integrated into XRS.
 The 'X' parameter is optional, and specifies the drive letter where you
 want to swap out the XRS program if no or insufficient LIM/EMS memory
 exists.  If it is left off, the default drive would be used.  XRS leaves
 only a 3.5k "stub" of itself in low memory, freeing all the remaining
 memory for the external program (or DOS "Shell" on the <F10> hot-key).
 Note that the exact amount of memory swapped out will vary every time you
 swap, since XRS dynamically allocates up to all available low RAM and up
 to 2.1MB of LIM/EMS (and up to 96k of XMS memory if you use an overlayed
 version).  If you don't have enough LIM/EMS available at that time, XRS
 will automatically swap to disk instead.  If you have neither (say on a
 2-360k floppy system), XRS will cancel the swap operation for future
 external program calls after informing you it is doing so.  Unless you
 know this option won't be useful for you (you have a slow hard drive and
 / or don't have any LIM/EMS to swap), you should always enable this!




PreLoad Summary

  This is probably *the* most important optimization option - especially if
 you tend to read large mailbags and/or jump around a lot (using the <J>ump
 menu-bar option after viewing a message)!  This forces XRS to initialize
 it's "Heap Expander" routines, preloading up to 2MB of summary/index info
 in LIM/EMS and/or up to available memory less 80k in low (640k) RAM.  If
 for any reason, this function fails (whether it is because you run out of
 available LIM/EMS or don't have sufficient low RAM), it automatically will
 free all space which was allocated and turn off the "preloaded" flag inside
 XRS, and XRS will use the SUMMARYx.XRS file instead of the data preloaded
 in RAM.  If you have plenty of LIM/EMS memory, this allows you to preload
 the index for 30,000+ message for instantaneous lookup, if you have 640k
 and no LIM/EMS, and use an overlayed version, you should be able to preload
 information for 2500 messages.  Again - unless you know you have small low
 RAM available (less than 640k) or seldom do any jumping around - and this
 includes reading by AREA, since it also uses the jump table - you should
 always enable this!  If you have available memory and run off diskettes,
 you *should* try to limit your mailbag size and turn this on, since XRS
 will otherwise have to continually search your diskette for information.




;No EMS

  *Don't* use this unless you have a specific LIM/EMS problem with XRS.
 In every case to date, LIM/EMS conflicts have been resolved by updating
 to a newer EMM driver if available.  If you do have a definite conflict
 and are unable to resolve it with a driver update, you *must* use this
 parameter, or somewhere along the way you will have problems!  XRS does
 not require a LIM/EMS version 4.0 driver, though - any truly up-to-date
 LIM/EMS 3.2 driver will do!




;TimeAdjust 20

  If you have an 4.77MHz 8088 CPU or a CGA with no vertical retrace in the
 hardware (i.e. "Snow"), you probably don't need to adjust this.  See the
 main documentation file for details.  This only affects how often the
 background procedures 'signal' before any are allowed to execute.




;Packer LHARC.Exe

  90% of the problems with this parameter are because people don't read the
 docs or notice you need to specify an extension (".EXE" or ".COM").  The
 .ZIP format is the *default* - if you want to use PKZip - leave this out!
 If you want to use LHArc (the older version) and PKZip would be found on
 your PATH (XRS always looks for it first) - use the above - if you want
 to use the 'new' LHA, try "PACKER LHA.EXE".





Buffer 8192

  This parameter controls the variable (user-selectable) amount of buffer
 space allocated for the BATxMAIL.XRS file (the text of all the messages)
 and can be set anywhere from 512 up to 32768.  If you have a slow hard
 disk, or run on diskettes, set it to a lower value, if you have a very
 fast ESDI or SCSI drive, set it up to the 32768 maximum - assuming you
 also have plenty (640k+) of memory, which you should is you have these
 fast (and usually large) drives!  Depending upon how you set this option
 XRS may give spectacularly fast or "square wheel" clunky access to the
 messages if you jump around or read within message groups (which most
 people do).  You may have to experiment a bit to find the optimal setting
 for your system, and you should always "tune" it if you move to another
 machine!





;Virtualize 250
;VirtualJump 100

  The defaults for list virtualization (which is new in XRS 4.50) is to
 virtualize the list only if it is more than 500 messages, and to move
 the sliding window by 1 1/2 times the screen-size (i.e. virtual page
 size - or number of messages removed from one end and added to the other
 if you scroll past the current virtual list).  Under Desqview, you may
 wish to make these smaller so that XRS runs in a smaller RAM footprint.
 The <J>ump list takes approximately 10k per 100 entries, so if you have
 plenty of RAM, you may wish to increase the defaults to avoid frequent
 paging - or eliminate paging in most cases altogether, building the whole
 list in memory each time instead.  Virtual lists allows XRS to build a
 portion of a list for a 30,000+ message mailbag, for example, and to page
 entries in and out as required as you scroll through the list.  This is
 not possible without virtualization, since that list would take 300k or
 more just for that one function (and it must be built in low RAM).





;No Clock
;No Seconds

  These two are usually not needed, but provide less "Snow" on CGA-based
 systems that don't do verticle retrace timing, or eliminate the constant
 on-screen clock ticking which throws "Screen-Speak" hardware/software for
 visually impared users off running all over the screen constantly.




<INS> <F9> Reversed

  Almost everyone prefers to have the default C_Worthy functions of <F9>
 (toggle insert/overwrite) and <INS> (paste) reversed!  Using this option
 doesn't optimize a thing, but makes those keys work more intuitively in
 the internal editor (and *only* effects them in the internal editor!).




To Name Prompt

  Most people like the ability to quote/reply to a message, but redirect
 the response to someone other than the author of the original message.
 Again - this one doesn't really optimize anything, except it makes XRS
 more flexible.  The reason this isn't the default is that previous XRS
 versions didn't have the option at all, and if I made it the default,
 people who typically never do this have to "bop through" another prompt
 for every message.




Jump Headers

  This option forces more frequent access to the "BATxMAIL.XRS" text file
 during <J>ump mode (from the "read messages" menu-bar), but displays the
 header of each message as you scroll through the resulting point and shoot
 list.  Note however that is you have a slow drive, or run on diskettes,
 this option is available for a single message by hitting <TAB>, so most
 likely you should turn the continual updating off.  Note again that this
 optimization *only* affects using the "<J>ump" menu-bar selection.  Since
 XRS does "relative jumps" inside the file rather than seeking from the
 start of the file, this option usually works well unless you have a very
 slow hard drive or diskettes only.




;list view
;page view

  These two allow you to force XRS not to use "Optimal Viewing" during
 message display.  Normally, XRS looks ahead to see how many lines are
 in each message and picks one of these modes automatically (list view
 if it's too large to fit on one screen with the menu-bar, or page view
 if it fits).  Page view displays a page-at-a-time if a message is more
 than a full screen - the mouse can only be used to continue to the next
 screen-full (and a marker keeps track of where you last were reading).
 List view displays everything in a true scrollable list, and the mouse
 can be used to skew the list up or down to read or review the message,
 however, you must use <ESC> or click the right button on the mouse to
 exit page view mode before the menu-bar appears.  Different strokes for
 different folks.  The optimal viewing is likely best - if you don't have
 a rodent, the up/down arrow keys and PGUP/PGDN, etc keys work in List
 view mode, anyway.




;Bundler RollUrOn.Exe

   Is *NOT* needed if you use the 'transparent' QWK format support via
 Rudi Kusters' "XCS" programs named "QWK2XRS.EXE" and "XRS2REP.EXE", but
 those two programs must be available somewhere on the PATH!  This is a
 further attempt to "open up" the architecture and allow people to build
 exporting bundlers other than the internal "XRS_Pack" (FTS-0001) or Rudi's
 XRS2Rep.Exe (QWK) packers, so if you have need to build something else,
 please get in touch with me.  (these two already cover "fidonet" and other
 similar network output and QWK flavor "*.REP" mail outbound mail packing)





Thread only   (this makes the "+" / "-" keys appear only for threading use)
;Threading      (this makes them thread if available, otherwise next/back)

  The way the plus and minus keys worked in all previous versions were as
 the equivalent of the "<N>ext" and "<B>ack" functions.  Version 4.50 has
 true multi-threading support, and using one of these two options enables
 either threading via plus/minus (if there is one - otherwise they act as
 before) or plus/minus *only* for threading.  The behavior can be modified
 interactively from the <F4> hot-keyed configuration window.  XRS displays
 blinking chevrons in place of the < or > thread symbols if either of these
 options are activated, so you know the plus or minus keys will thread and
 not read next or back as before.





Always                (Display Mailbag Handler on Exit)

  This is another new option in the 4.50 release, but one which you most
 likely would want to activate especially if you tend to read mail from
 multiple sources, or like to "put away" a partially read mailbag and open
 another, rather than use the default which XRS has always used (keeping
 the 'current' mailbag open and instantly available without unpacking).  If
 you typically read mail from one source, and always read them sequentially
 then you probably do not need (or want) this.