DocsBoot+ developer's page
Currently, there is a preliminary version of the DocsBoot+ extension
development kit available for registered DocsBoot+ users only. If you are
a registered user, please read on. If not, why not take a moment to register
the program for which you are interested in developing extensions?
The current version of the DocsBoot+ extension development kit is
preliminary. Basically, the development kit is in the same state it was in
when it was used to develop the extensions that are inlcuded in the DocsBoot+
package. Yes, for you unbelievers, the extensions included with DocsBoot+
were developed with only what information is available in the development
kit. This seemed to be a good test of whether or not the kit was useful.
Registered users may request they be sent the
development kit by filling out this form.
We do not, at this time, support development efforts by people who do not
have a registered copy of DocsBoot+.
We are happy to answer questions or work with you on problems with the
developer's kit. Please note that we can not guide you through the
development process -- it is assumed that you have a good familiarity
with 80386 assembly language, access to a reliable assembler, and a good
understanding of basic PC architecture programming (not, in
particular, DOS programming).
For those of you interested in the package, and wonder what you can do
with it, here is a list of the basic functionality the DocsBoot+ API includes.
- Display control
- The API provides an enhanced string display
function that accomodates a simple string compression technique, embedded
colour control, and embedded cursor location control. The display functions
also correctly handle any display device the system BIOS supports (the one
limitation is that it assumes an 80*25 display).
- Disc access
- The API includes calls to read or write linear sectors
on any INT13 drive in the system, even those drives that do not support linear
access directly. Single sectors can be accessed, or many sectors can be
accessed (up to a track on a floppy, up to 127 sectors on a hard disc).
- File access
- The API provides built-in capabilities to access FAT12
and FAT16 (or compatible) filesystems, and filesystem extensions can be added
to support arbitrarily defined filesystems.
- Resident devices
- The API allows for an extension to go resident for
the duration DocsBoot+ is active (for example, to replace or enhance a function
provided by DocsBoot+), or to remain resident after DocsBoot+ is finished (for
example, to provide INT13 access to more hard discs).
- Inter-extension comminucations
- The API provides a multiplex
protocol for extensions to communicate with each other. Up to 65535
extensions can use this protocol at once (but since DocsBoot+ is limited to
operating in base memory, not this many extensions can be resident). There
is only one enforced command in the protocol (identify extension) and 256
commands are reserved, leaving 65019 available for extensions to define as
they see fit.
- Extension size
- Extensions can be as large as they want, but due
to limitations in the way they are loaded (the linear address at which they
are loaded limits their size), only the first up to 31.5KB will be loaded.
After that, an extension is responsible for swapping needed bits of itself
in. Generally, large amounts can be accomplished in a small space
(especially since this is an assembly based API), so this limit should not
be a difficult problem. Look at the included extensions -- generally, most
of the space they take is text strings for their user interfaces!
- The API is modular, so an extension can add its
own functionality to a feature the API provides, or it can replace the API
function completely with its own (the MenuPlus extension is an example of
this -- it replaces the display menu handler with its own).
The extension development kit includes several files which are detailed
- This file is the extension API documentation.
This includes detailed descriptions of all the API calls (what they do, and
what must be done by a replacement handler for things to work normally).
- This is the source for the !EXTEN.DBE that DocsBoot+
includes to allow the user to decide to load or not to load a module.
- This is the finished extension from the !EXTEN.ASM
- This is an example of using the filesystem calls.
If you are accustomed to using handles to access files, this may seem rather
an odd extension of that (the handles are pointers to large data areas!), but
it works by a similar concept.
- This is the finished extension from the FILEDEMO.DBX
- This file is included only for developers working with
both the DocsBoot+ API and the VersaBoot ][ system. Normally, you would not
need this file (unless you were loading a VB][ extension from DocsBoot+).
- This a debugging module. It is a fairly simplistic
debugger, merely showing register values, the current executing code (it does
not include a disassembler), and the current top of stack. This version of
the debugger runs on CGA or EGA/VGA displays with colour monitors (or
- This is a version of the debugger above that runs on
IBM MDA, Hercules GC, Hercules GCP, Hercules InColor, or EGA/VGA displays with
monochrome monitors (or compatible devices).
- Both of these files are description
files for the archive file the development kit comes in.
You are expected to provide appropriate assembly and linking tools. Please
note the current version of the development kit was designed around Borland's
Turbo Assembler, and will probably require changes to work with most
other assemblers. A version designed for MicroSoft's MASM is in the
You can return to the DocsWare homepage
by clicking here.
Click here for information about the DocsWare
This page maintained by Zac Schroff.
© Copyright 1996-2006 Zac Schroff, all rights reserved.