Differences between RDOFF versions 1 & 2
========================================

This document is designed primarily for people maintaining code which
uses RDOFF version 1, and would like to upgrade that code to work
with version 2.

The main changes are summarised here:

Overall format
==============

The overall format has changed somewhat since version 1, in order
to make RDOFF more flexible. After the file type identifier (which
has been changed to 'RDOFF2', obviously), there is now a 4 byte
integer describing the length of the object module. This allows
multiple objects to be concatenated, while the loader can easily
build an index of the locations of each object. This isn't as
pointless as it sounds; I'm using RDOFF in a microkernel operating
system, and this is the ideal way of loading multiple driver modules
at boot time.

There are also no longer a fixed number of segments; instead there
is a list of segments, immediately following the header.
Each segment is preceded by a 10 byte header giving information about
that segment. This header has the following format:

Length	Description
2	Type
2	Number
2	Reserved
4	Length

'Type' is a number describing what sort of segment it is (eg text, data,
comment, debug info). See 'rdoff2.txt' for a list of the segment types.
'Number' is the number used to refer to the segment in the header records.
Not all segments will be loaded; it is only intended that one code
and one data segment will be loaded into memory. It is possible, however,
for a loaded segment to contain a reference to an unloaded segment.
This is an error, and should be flagged at load time. Or maybe you should
load the segment... its up to you, really.

The segment's data immediately follows the end of the segment header.

HEADER RECORDS
==============

All of the header records have changed in this version, but not
substantially. Each record type has had a content-length code added,
a single byte immediately following the type byte. This contains the
length of the rest of the record (excluding the type and length bytes,
but including the terminating nulls on any strings in the record).

There are two new record types, Segment Relocation (6), and FAR import (7).
The record formats are identical to Relocation (1) and import (2). They are
only of real use on systems using segmented architectures. Systems using
a flat model should treat FAR import (7) exactly the same as an import (2),
and should either flag segment relocation as an error, or attempt to figure
out whether it is a reference to a code or data symbol, and set the value
referenced to the according selector value. I am opting for the former
approach, and would recommend that others working on 32 bit flat systems
do the same.