                            QB/Pro Volume 7
                            
                            "QB Optimizer"


                        -= H I G H L I G H T S =-
                        

                 Substantially Smaller Standalone Programs
                 =========================================
              
   We supply you with several "XModules" that replace unneeded MS library 
   routines when you compile with "/O". Using all of the supplied modules can 
   result in functional programs that are less than 4K in size!

   The XModules are similar in concept to NOCOM.OBJ and SMALLERR.OBJ. See the 
   detailed explanation below.
   
   
                        OPT.EXE - Optimizer Utility
                        ===========================

    1) Optionally converts BASIC source files (no matter how messy) 
       to structured code, including indenting logical fragments.
    2) Indentation levels and tab stops are user configurable. 
    3) Optionally strip out unreferenced line numbers/labels.
    4) Optionally add line numbers for easier debugging with ON ERROR. 
    5) Optionally remove variable names from NEXT statements, for faster 
       programs. 
    6) Optionally align remarks. You select what column they start in.
    7) Optionally prints formatted listing to printer or file. Use 
       metacommands to describe output.
    8) Ideal for converting your programs for use with QB4 and BASCOM 6.
    9) Process multiple files in one run, either interactively or command 
       line driven.


                       PP.EXE - Pre-Processor Utility
                       ==============================

    1) Allows conditional compiling to provide different versions of programs
       for different clients, projects, debugging, etc. 
    2) Conditional compiling can be done using numeric or string symbols.
    3) Use $Include with SUBs and FUNCTIONs.
    4) All compiler and LINK commands become part of your source, so no more 
       batch files to worry about. We use statements similar to "metacommands",
       so there's no overhead penalty in your .EXE files.
    5) Processes in excess of 20,000 lines per minute on 386 machines with 
       18ms hard disk and almost 10,000 LPM on a 286 with a 28ms hard disk.
    6) Built in subset of MicroHelp's MAKE facility, so programs and dependent
       BASIC modules are compiled and LINKed only when necessary.
       

                     XREF.EXE - Cross Reference Utility
                     ==================================

    1) Cross references all variables and literals.
    2) Identifies physical lines in file where variables are referenced and 
       where they are changed. This assists you during debugging, since you 
       are shown all lines where variables can take on spurious values.
    3) Cross references all line numbers and labels, including SUBs and 
       FUNCTIONs.
    4) Identifies physical lines in file where labels/line numbers/procedures 
       are referenced as well as where they are located and DECLAREd.


                      Programming Tips in the Manual
                      ==============================

    QB Optimizer includes a fully indexed three-ring bound manual. One section
    of the manual is devoted to programming tips: Faster Programs, Smaller 
    Programs and Other Tips.


                             -= D E T A I L S =-

                              - The  XModules - 
			      
   LINK these modules with your program when you don't need 
   the corresponding BCOMxx.LIB routines. The number of bytes saved (shown 
   for each module) is based on BC 4.00b and LINKing with /EXEPACK. Similar 
   savings are obtained with BC 4.50 and BC 6.00x.
    
   Use all of these modules in your programs and save 16,796 bytes each! That 
   means functional programs less than 4K in size.
   
   * XERROR.OBJ is used when you don't need error trapping, redirection and 
     ^Break trapping. Saves 2284 bytes per program.
   * XFLOAT.OBJ is available when your program uses only integers and long 
     integers. Saves 9386 bytes per program. Note that there are some BASIC 
     statements, including graphics and trig, that use floating point math 
     and therefore cannot be used with this module. Because STR$() and VAL 
     cannot be used, consider using QB/Pro Volume 2, which has replacements 
     for these functions.
   * XGRAPH.OBJ is used when you don't need any graphics capabilities. Saves 
     240 bytes per program. If using XVIDEO.OBJ, this module is not needed.
   * XREDIR.OBJ is for when you don't need redirection and checking for ^Break.
     Saves 180 bytes per program.
   * XVIDEO.OBJ is used when you don't need any video related routines. For 
     example, if you use only assembler routines for screen displays, you 
     probably can use this module! Saves 2870 bytes per program. We supply 
     you with assembler equivalents of: LOCATE; SCREEN 0,0,0; WIDTH 80,43; 
     and WIDTH 80,50.
   * XINPUT.OBJ can be used when you don't need any input or screen oriented 
     routines. Also forgoes critical error handling and overflow error 
     detection. Saves 1520 bytes per program. We supply you with an assembler 
     routine that is the equivalent of INKEY$, but also returns the scan code, 
     shift status and ASCII code. Use Mach 2 and other QB/Pro Volumes to 
     perform edited input and critical error handling.
   * XINTS.OBJ, used only when you also use XINPUT.OBJ, is for when you don't 
     need BASIC's commands that deal with the timer or keyboard. Saves 768 
     bytes per program.
     
   Suppose you want to use as many XModules as you can, but you're not sure 
   which ones will work with your programs? No problem. We include another 
   utility called CHECKX.EXE that will tell you! This program is so good, 
   that it will actually identify the lines, and point to the BASIC reserved 
   words that prevent you from using a particular module!

                       - The Optimizer Utility - 
   Forget about unreadable code! OPT.EXE takes the 
   messiest source code and makes sense out of it. For starters, OPT will 
   analyze your code and indent the following structures:

    FOR/NEXT
    WHILE/WEND
    SELECT CASE..CASE..END SELECT
    IF..THEN..ELSE (into structured blocks)
    DO..LOOP
    SUB..END SUB
    FUNCTION..END FUNCTION 
    DEF FN..END DEF
    
   You select the indentation spacing (i.e., every x spaces) and tell OPT 
   whether to use TAB characters or spaces.
   
   Since OPT can be run either interactively or as a command line program, you
   have more freedom. For example, when you first get the program, you can:
   
                       OPT *.BAS; <Enter>
                       
   That command will process all *.BAS files in the current directory while 
   you're out to lunch! After that, simply run OPT with single programs when 
   you change them.
   
   If you use error trapping and line numbers, you'll want to use OPT to strip 
   out all unreferenced line numbers. This results in smaller .EXE files.
   
   If you don't like the message "Error in module xxxx at address yyyy:zzzz", 
   use OPT to temporarily add line numbers to your program for debugging 
   purposes. You even get to choose the line number increments! When you're 
   finished, use OPT again to strip the line numbers back out!
   
   Taking advantage of remark alignment, you can make your programs much more 
   readable. This means that when you are coding your programs, you can type 
   as fast as you want and put REMs wherever you want -  then let OPT 
   align them.
   
   Using standard metacommands, you can have OPT print beautifully formatted 
   program listings. You specify title, subtitles, page length and page width. 
   You can even force a page break!

                         - The Pre-Processor Utility - 
			 
   Conditional compiling has long been available to 
   programmers using languages other than BASIC. Now, for the first time, you 
   can take advantage of this extremely powerful technology!
   
   Suppose you have two clients: IBM and Sears, and each of them uses a big 
   application program you've written, but they each want slightly different 
   features in several of your SUBprograms. Up until now, you've had to 
   maintain separate versions of your program for each client, or go through 
   some inelegant tricks to get the desired .EXE files.
   
   With our Pre-processor, it's a piece of cake! Here's how it's done:
   
    TopOfProgram:
      'Name your client
      '#Client$ = IBM
  
    SUB AnySub(Parameter1)
      '#IF Client$ = IBM
           PRINT "Customer: IBM"
      '#ELSEIF Client$ = Sears
           PRINT "Customer: Sears"
      '#END IF
    END SUB

   When you want to compile for Sears, change the "Precommand" at 
   "TopOfProgram" to "Sears". When you want to compile for IBM, change it back!

   The Pre-Processor program will analyze your file and generate a temporary 
   work file that is compiled (your source code is not compiled). In the 
   example shown above, the work file will have only the appropriate code in 
   it. In other words, it will have the line that prints IBM as the customer, 
   but not the line that prints Sears. This makes for smaller, and usually 
   faster programs.

   Because of this technology, you can use $Include with SUBprograms and 
   FUNCTIONs. The Pre-Processor will read the include file and merge it into 
   the work file along with your program. BC will think that you have a single 
   program file and won't complain!

   You can also use numbers in your Precommands. As an example, suppose you 
   have a system that can be used either "single user" or "network":

    TopOfProgram:
      '#Network = 1
    LaterInProgram:
      '#IF Network
          PRINT "Network version"
      '#ELSE
          PRINT "Single user version"
      '#END IF

   Again, the work file that is compiled has only the appropriate BASIC code 
   in it, not both PRINT statements.

   Taking things one step further, you can use any of the following 
   Precommands:

    '#IF Network = 1
    '#IF Network > 1
    '#IF Network < 1
    '#IF Network <> 1
    '#IF Network >= 1
    '#IF Network <= 1
    
   Precommands are also used to specify compiler switches, LINK switches, 
   trailing object modules, leading object modules, etc. This means that the 
   Pre-processor can be used in place of all those batch files you keep 
   around. For example, suppose you have a RAM disk on drive E:, and a 
   program called FOO.BAS, and the source code for FOO.BAS includes the 
   following:

    '#CompilerName: 'BC'
    '#CompileSwitches: '/O/E'
    '#WorkPath: 'E:\'
    '#LinkSwitches: '/EXE/NOE'
    '#EXEName: 'MYPROG'
    '#EXEPath: 'C:\PROGS'
    '#LeadingObject: 'STAYQB4'
    '#TrailingObject: 'FOO2'
    '#Libraries: 'MHLIB2 MHPRO7'
    
   When you execute the Pre-Processor, it will analyze your file and create a 
   temporary work file called E:\FOO.$$$ on your RAM disk. It will then 
   generate compiler and LINK commands that look like this:

    BC /O/E E:\FOO.$$$,FOO.OBJ;
    LINK /EXE/NOE STAYQB4+E:\FOO+FOO2,C:\PROGS\MYPROG.EXE,,MHLIB2+MHPRO7;
    
   If you have LIM Expanded Memory (version 3.2 or later), or a hard disk or 
   a RAM disk, the Pre-Processor consumes only 10K during the compiling and 
   LINKing process, so don't worry about it being a memory hog.
   
   Because the Pre-Processor is smart, it will compile FOO only if the source 
   code FOO.BAS is newer than the existing FOO.OBJ module. LINKing will take 
   place only if the object modules are newer than the existing .EXE program! 
   That means it's easy to "freshen" your programs. Using the above example, 
   simply:
   
                             PP FOO <Enter>
                             
   If FOO doesn't need compiling and LINKing, the Pre-Processor will tell you 
   so and you'll be done in no time.
   
                     - The Cross Reference Utility - 
		     
   The best way to explain this program is to 
   provide you with an example. We'll start with the source code shown below 
   (XREFTEST.BAS). Note that the line numbers on the left are the physical line
   numbers in the file and are not part of the source code. They have been 
   added only to facilitate your moving between the cross reference listing 
   and the program itself:

     1 '    BAS This is a sample program designed to produce an
     2 '    interesting cross-reference file.
     3
     4  A = 1
     5  B = 2
     6  C = 3
     7 Top:
     8  D = A * B
     9  A = A + 1
    10  B$ = "Hello"
    11  C$ = " World"
    12  PRINT C$
    13  IF A < 3 GOTO Top
    14  RESTORE Bottom
    15  READ A$
    16 Bottom:
    17  DATA Cruel

  Here is the actual output produced by the XREF program:

    XREFTEST.BAS   Date: 05-25-1989   Time: 14:53:20    Page:  1

    1                   4      9
    2                   5
    3                   6     13
    @Bottom            14     16*
    @Top                7*    13
    A                   4*     8      9*     9     13
    A$                 15*
    B                   5*     8
    B$                 10*
    C                   6*
    C$                 11*    12
    D                   8*
    
  Starting from the top, here's an explanation for some of the output:

    -The literal "1" is found on lines 4 and 9.
    -The literals "2" and "3" are found on their respective lines.
    -The label "Bottom" is found on line 16 (since there is an asterisk), and 
     is referenced on line 14. The label "Top" is similarly marked.
    -The variable "A" changes value on lines 4 and 9 (since there are 
     asterisks). Note that there are two occurrences of "A" on line 9, so two 
     nines are shown.
    -A$ is changed on line 15, but there are no other references to it. 
  
   Why Should You Use XREF? In the cross reference listing there are several 
   items worth examining:

    -The literal "1" appears twice. If your program is speed critical, consider
     adding "One% = 1" to the top of your program and then substituting "One%" 
     for each occurrence of the literal "1". Using a variable is much faster 
     than using a literal, since the compiler doesn't have to generate a 
     "temporary" variable.
    -Knowing where variables are changed can help immensely when it comes to 
     debugging a program. For example, if a variable has an unusual value in 
     the middle of your program, and you don't have any idea how it happened, 
     use QuickBASIC's environment to set breakpoints on all lines that change 
     the variable and then examine the variable each time it is changed.
    -You can get rid of unnecessary variables. For example, A$ appears only on
     line 15. So why should it be in the program? Ditto for B$ and "D".
    -Similarly, you may have line labels or procedures that are not referenced
     by any other portion of your code. In that case, you may wish to remove 
     them. As an aside, we often leave unreferenced labels in our programs 
     that are used in a fashion similar to remarks. In other words, they are 
     placeholders, or navigational guides. There's nothing wrong with making 
     them into remarks, however! Just put an apostrophe in front of the label.


                            System Requirements
                            ===================

    The minimum system requirements for using QB Optimizer are:

        * An IBM PC, XT, AT, PS/2 or close compatible.
        * PC/MS DOS version 3.00 or later. 
        * Any Microsoft or IBM BASIC compiler.
        * A hard disk (fixed disk).
        * 1 Diskette drive (5.25"). 3.5" disks are available for a nominal 
          charge.
        * An 80 column monitor.
        
        
                            Special Requirements
                            ====================

    * Use of the XModules requires compiling with /O and one of: Microsoft 
      QuickBASIC (4.00b or 4.50) or the Microsoft BASIC Compiler 6.0x. In 
      fact, the modules are actually "library dependent" - you must LINK 
      with one of: BCOM41.LIB, BCOM45.LIB, BCOM60xx.LIB or BCOM61xx.LIB. 
      If Microsoft releases a newer version of either compiler, please 
      check with us for compatibility.

    * Using the "convert to structured code" feature in the OPT.EXE program 
      requires that you are using Microsoft QuickBASIC 2.0 or later.

    * Using the "Add line numbers" feature of the OPT.EXE program requires 
      that you are using Microsoft QuickBASIC 1.0 or later.
      

                             Try Before You Buy
                             ==================

    Call us and order QB/Pro Volume 7 and be sure to ask us to include our 
    demo disk. The demo consists of the following files:

        * Source code and executable program created using all of the 
          XModules. See the size for yourself.

        * Limited use versions of OPT.EXE and XREF.EXE. These demonstration 
          programs can be used on your own source code, but are limited to 
          programs of less than 200 lines in length.

        * The XREFTEST program shown above. Use the demo version of XREF.EXE 
          to create a cross reference listing.

        * A program written for use with the Pre-Processor program, including 
          the temporary work file created for compiling.

    When you receive the package, don't open the software - just try the demo 
    programs. If you're still not convinced that you need this marvelous set 
    of utilities, simply return the software unopened. We'll refund the amount 
    of the purchase, no questions asked. All you pay is shipping.

    Or, if you prefer, send us a check for $5.00 (no credit cards or COD's 
    please) and we'll send you our demo disk. If you decide to buy QB 
    Optimizer after seeing our demo, we'll credit the $5.00 towards your 
    purchase.


                             Ordering Information
                             ====================
                             
    The cost of QB/Pro Volume 7 is $89 plus $4 for UPS ground shipping. If you
    would like more information or would like to place an order, please call 
    toll-free at 1-800-922-3383, or in Georgia (404) 552-0565.
