Format Driver
Volume Number: 4
Issue Number: 1
Column Tag: The Visiting Developer
Format Drivers Bring Freedom 
of Revison
By David Dunham, James Hopper, Goleta, CA
Data interchange is a real problem. Everyone likes to save information in their
own format, and no one wants to deal with anyone else’s format (e specially not to write
it!). Programs like the original version of Acta, David’s desk accessory outline
processor, support only limited file format interchange, usually via a separate
translator program. Such translation programs are very inconvenient, but there are
reasons for writing them. First, the extra code required to read additional file formats
can significantly enlarge a program while adding support for formats which most
users never need. It’s better to separate this code from the more commonly-used
parts of the program. Also, the intermediate file is necessary because many programs
don’t use the public clipboard (desk scrap) for formatted text. Second, many of these
formats are considered proprietary and are not generally available, for example
Microsoft Word 1.05. Finally, there are a lot of file formats out there -- most of us
are simply too lazy to cover all of them.
Many people work with a variety of editors, word processors, and desk
accessories, and need the ability to exchange files between them. Separate translation
programs such as the one used with WriteNow are simply too inconvenient. Macintosh
users have grown accustomed to (and deserve) a higher degree of integration between
programs. One way this can be done is to ‘teach’ the program what the data must look
like by having the program look-up the format externally to itself. In this way, the
program does not have to be revised to read or write a new format whenever someone
releases a hot new product. In this article, we will discuss an example of such a
technique used in Acta 2.0, that can be applied to other developer’s software projects
to ease the burden of being compatible. [It is hoped this article will spur someone to
write a similar article on how Pagemaker compatibility can be achieved by new word
processors without having to wait for Aldus to release a new Pagemaker version.
Wouldn’t it be neat if the word processor or graphics developer could make his product
Pagemaker compatible without Aldus having to do anything? -Ed]
Acta 2.0 handles additional data formats with format drivers, files which, like
printer drivers, reside in the system folder. Because they’re separate from the main
program, users can install only the formats required by dragging these driver files to
the system folder. As new word processors come out, the new file formats can be
supported with new format drivers, rather than a new version of Acta. Given the file
format documentation for the new word processing program, drivers to support new
formats can be produced by third party programmers such as Jim.
David will first explain format drivers using C as the target language. Jim will
then discuss a simple input format driver in Pascal, focusing on the glue required to
link functions written in C to units written in Pascal. Although this article deals with
format drivers as implemented in Acta, the concept of format drivers can be adopted in
most programs.
Additional technical information on Acta can be found in a short document
describing the format of Acta files, available from online services such as Delphi or
CompuServe, or from Symmetry Corp. For convenience, it is included at the end of this
article. This information would be useful if you’re implementing your own Acta format
driver, but you won’t need it to read this article.
Input Drivers
Acta supports two kinds of format drivers: input and output. A file can contain
resources for both, but we’ll start by looking at input drivers. An input driver’s job