NOTE: As for the p-System, many of these components have special
versions
for release discs, optimised for compactness and speed (and in some cases
to make the user environment easier or safer for the student). Release
discs should not be made up with development system
components on them.
- bootstrap
- The bootstrapping code on a DOS disc is usually placed
there
by the formatting process (see above).
- hidden files
- Bootable DOS discs require the two files
IBMDOS.COM
and IBMBIO.COM. Using the /S (system) option when
running FORMAT causes
them to be copied to the new disc automatically. If they are not
copied
with the disc is formatted, the program SYS.COM copies them,
but only if space has been reserved for them when the directory
was created.
NOTE: A special pair of system files is under development by
IBM to replace both the hidden files and COMMAND.COM. They are
intended for creating booting discs with only program-support
functions,
rather than interactive user-support. At this writing they have not
been successfully used for creating dialogue release discs. They do
not yet support the program-chaining functions the dialogues need.
- COMMAND.COM
- COMMAND.COM is used mostly just to
cause the AUTOEXEC.BAT file to be interpreted which calls the
dialogue's
startup; most of its functions will not
be needed by the dialogue.
- CONFIG.SYS
- CONFIG.SYS is read by DOS before
AUTOEXEC.BAT. It contains a series of settings both to give DOS
configuration information, and to cause the loading of any needed
drivers
contained in separate files. Any driver files it names (such as
ANSI.SYS or VDISK.SYS) must be available to DOS, when
the disc is booting, on the path name specified by CONFIG.SYS.
Typically this will mean placing them on the disc itself, but if
they are known to be present already in the runtime environment, they
may be used from there.
These settings are either essential or well-advised for the
applications
to be able to get the support they need from DOS.
- AUTOEXEC.BAT
- A .BAT file, or batch file, is a text
file containing a list of commands, such as would be entered at the
interactive
prompt. AUTOEXEC.BAT is the batch file that COMMAND.COM
interprets
automatically when booting is finished, if it is present on the boot drive.
It is therefore where the command(s) is/are placed that start the dialogue.
A
minimum of necessary commands is recommended, preferrably 1. They add
to
the complexity of the file's format; they are slow to execute; they can
result in a confusing screen display; and as they accumulate they become
increasingly difficult to debug.
- dialogue startup program
- The startup program is used mainly to
provide a layer of error recovery between the dialogue and DOS, in case of
unexpected, major accidents. The dialogue itself is executed by the startup,
within its environment; should it ever return, the startup presumes it has
aborted
with a crash, and promptly restarts it, rather than permitting a return to
DOS
and the DOS prompt, which would be incomprehensible to many students.
The only exception is if the DOS status code after the dialogue's return
shows
it was exited deliberately by the student; if so, the shell also immediately
exits. This is intended mainly for network environments, where the dialogue
may be one of many different programs used by lots of people. The status
code used so far is 128, which should be sufficiently far above the range
of status codes from regular DOS programs to avoid any collision of usages.
For the DOS release of the Scientific Reasoning Series, the dialogue
startup program is SRSWORLD.EXE.
- .BGI files
- The graphics support for Turbo Pascal 5.0
requires the Borland Graphics Interface file for the type
of
display that will be used at runtime. Since this could be any of the display
types that Borland supports, all the .BGI files should be included (Borland's
copyright on Turbo Pascal specifically permits .BGI files to be distributed
with
any application that uses them). They are found in the development library
directories; the development versions can be used.
Note: some of the display types Borland supports cannot actually be
automatically detected at runtime -- the point at which the graphics support
routines choose the particular .BGI file to be used . The .BGI files for
these
types should be included anyway, unless they are consuming needed disc space,
since the user's environment may nevertheless have means of using them.
Borland's manuals for Turbo Pascal 5.0 should be consulted to determine which
.BGI files these are.