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 here.

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 source file.
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 source file.
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 compatible devices).
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 works now.

You can return to the DocsWare homepage by clicking here.

Click here for information about the DocsWare pages.

This page maintained by Zac Schroff.

© Copyright 1996-2006 Zac Schroff, all rights reserved.