3.1.4.2 Cogsys Extensions

Cogsys extensions work in exactly the same way, with a powerful new feature. Normally, the main program can access the dynamically loaded code, but never the other way around. A moment's reflection shows why this so--dynamic libraries are naturally designed to work with many different programs. For instance, a paint program may call a library to draw a JPEG image, but a web browser may also use that same library to display an image. The JPEG library doesn't know what program is calling it, and it doesn't care--there is no reason why the JPEG library would need to know, for example, what font the word processor is currently in. If it did, what would it do when it was being called by the paint program? Thus, traditional dynamically linked libraries do not access the main program; it is a one-way street only.

Because DOS does not have a dynamic loading facility, and because Cogsys must run in DOS for real time accuracy, one had to be designed from scratch. And since Cogsys extensions are used only by Cogsys, it does make sense for the extension to have access to the main program, for example, an extension may want to know the value of a Cogsys user variable. So Cogsys extensions were designed to allow two-way communication between the CXR and Cogsys.

Of course, this means that fixups must be performed in both the main program and the extension. This in turn implies that the extension must somehow know exactly where all of the pieces of the main Cogsys program were actually loaded in memory; this information is normally not available to a running program.

The "last person" who actually knew where Cogsys objects were actually positioned was the static linker. As it happens, for debugging purposes, most linkers allow the creation of a map file, which is a table which tells where each object was positioned. By saving this table and keeping it with the main program, Cogsys is able to fixup the extension and allow two-way communication.

To this description must be added that purely for reasons of efficiency and convenience, the linker map file and the extension object files are translated into special formats that make them more compact and easier to handle by custom programs that are part of the Cogsys extensions developer kit. The MKMAP (make map) program turns the linker map file into a binary map file `COGSYS3x.BIM', and the COGXRG (Cogsys extension routine generator) turns the extension's object files into `.CXR' files.

The whole process can be summarized like this:

• Cogsys Developer:
  • Compiles and Links Cogsys source files, gets executable `COGSYS.EXE'
  • Map file is saved as `COGSYS.MAP' Runs MKMAP to make `COGSYS3x.BIM'
  • `COGSYS3x.BIM' is distributed with `COGSYS.EXE'

• Extension Developer:
  • Compiles a new extension, gets object `EXT.OBJ'
  • Runs COGXRG on object file to get `EXT.CXR'

• Cogsys User:
  • Make a call to %X[EXT.CXR]
  • Cogsys loads `EXT.CXR' into memory
  • Cogsys fixes up main program references to EXT.CXR
  • Cogsys opens the binary map file, `COGSYS3x.BIM'
  • Cogsys fixes up extension references to main program
  • Extension is now ready for use by commands (like %I) that use it

The next section describes the details of creating an extension.