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

   Once that the code has been generated, compiled and linked, the generated
   application will be ready to run. The name of the executable file can be
   modified in the Projects environment. The name assigned by default is
   MENU.EXE.

   There are some tricks and tips for speeding-up the application:

     . Link in protected mode (Blinker 3, ExoSpace or CauseWay).
       This can offer a performance boost of up to 70-80%. Alternatively,
       switch to using EMS when linking real-mode dynamically overlayed
       executables.

     . Compile without debug information, removing the /B compiler
       switch in the Projects - Subprojects - Options environment. This
       can offer a performance increase of approximately 30-40%.

     . Use, as the target PC, a computer with a 386 class CPU
       running at 33 Mhz with at least 2Mb of RAM. A more powerful computer
       will of course offer better performances.

     . Install a disk caching program (SmartDrive or similar).

   When MENU is run, the setup and configuration are executed in different
   sequences. The operations performed are displayed on screen. The message
   box can be disabled in the Projects-Properties environment, setting
   the Initialisation messages parameter to No.

   This initial phase can last a second or so, but it is can important to
   know the progress.

   Before continuing, a short description on the configuration file is given.

   The configuration file is read by the application at start-up. This file
   contains a set of options that are used for setting the VGA character
   font, the Table file's name, the printers, the ASCII character codes used
   for creating the CUA elements, the color palette, etc. All parameters are
   grouped in sections identified by a label.

   At start-up, the configuration file is read in different modes:

     . DBSTART.INI is searched for in the EXE sub-directory of the
       application. This is the most frequently used mode.

     . The programmer can customise the configuration file,
       assigning it a new name, therefore creating a different initialisation
       for the project or even sub-project. The new initialisation file's
       name must then be passed as a parameter to the application. The
       programmer must see to update this custom file with the eventual
       changes generated.

        Example:

   Menu MYCONFIG.INI
This represents the second mode.

     . A third mode consists in using a DOS environment variable
       indicating the path and the file name.

        Example:

   SET DBSTART=C:\WAYBILLS\MYCONFIG.INI

     . It is also possible to define specific initialisation files,
       that have the name of the section in DBSTART.INI as the file name, and
       have a .INI extension. These initialisation files are used to
       configure a particular section of the application. The configuration
       parameters set in this kind of file will take precedence over the ones
       set in DBSTART.INI.

        Example: The configuration file for a particular set of printers
       will be named PRINTER.INI, because printer is the section name
       in DBSTART.INI.

     . Lastly, if the Start-up with dBstart parameter in the
       sub-project's proprties environment is set to No, the application
       will start with internal setting, and ignore any external
       configuration files. Of course, these settings represent the bare
       minimum for running the application. On the other hand, no manual
       intervention is allowed, making the executable protected.

   The DBSTART.INI file is a text file. Its usage and syntax is similar to
   those used for Windows applications. The ";" character identifies a
   commented line. All the options, in fact, are extensively commented
   allowing the file to be easily manipulated by the programmer or the user.

   When modifying the DBSTART.INI file, two main aspects must be paid
   attention:

Loading of Fonts

   The currently set hardware font, through DOS and/or the CODE PAGE, is
   substituted with a special font that redefines the characters in order to
   enhance the visual appearance of the applications developed with dBsee. If
   the generated application displays erratic characters, this can depend
   from the font file being corrupted or invalid, or EMM386 allocating the
   memory area between A000h and A400h.

Color Palette

   The VGA adapter card has a feature, that allows to change the color
   palette of the 16 colors available. In the file DBSTART.INI, for each
   available color, the intensities of the 3 main color components
   (R=Red/G=Green/B=Blue) are shown, making up the chromatic composition.

   The modifications made allow to vary the result of the different SET COLOR
   TO instructions. For instance, by modifying the attributes of the Red
   color, it is possible to make it no longer appear as red but as any other
   chromatic tone.

   A palette configuration environment is available in both the application
   and in dBsee. The application, though, will not save the modifications
   made. Exiting the application, the changes are lost. Using dBsee, the
   changes are saved and the configuration file is updated. The changes can
   also be applied by manually editing this file.

   If the generated application runs into an error during its execution, the
   screen will maintain the configuration that it had during the course of
   the application. To bring the screen back to the normal, use the DOS
   command:

   MODE CO80

   Any TSR (Terminate and Stay Resident) loaded before executing dBsee, such
   as Norton Guides or Expert Help, and popped up within the generated
   application will show both the different colors as well as the redefined
   characters. To avoid this last inconvenience, deactivate the redefinition
   in the DBSTART.INI file, by setting FontRedefinition=No.

   The default system parameters are contained within the generated
   application under the form of a library modules. Part of these module are
   supplied in source code format, so that the parameters can be modified if
   necessary.

   Using internally set parameters is useful for fixing the configuration,
   and it also increases the performances of the application at start-up.