Version 2.10 by Steven Flintham (15A) Technical information This section provides information
which most users will not need but
which may be of interest. It includes
an explanation of some of the
restrictions imposed by the program.
Changes from version 2.00
The only change from version 2.00 is
the introduction of a new file format.
Version 2.10 cannot handle files
created using earlier versions and
vice versa. The program used by the
editor to collect messages can handle
both the new and old formats. This is
partly to allow people to continue
using older versions if they wish, but
also for the reasons described below
in 'Disc space and secrecy'.
The new file format is described in
detail below. It has the disadvantage
that the message file is now extremely
large (100K), but in return for this
sacrifice it never needs to extend the
message file and so there is no
possible risk of a 'Can't Extend'
error occurring. This makes it
possible to have other files on the
same disc. When first creating a new
message file there must obviously be
enough space on the disc for it. You
may need to *COMPACT the disc first if
there is more than 100K free but not
all in one block.
Disc space and secrecy
In practice the large message file
should not be a problem, as in the
past most people were probably forced
to dedicate a whole disc to the
message file in a (not always
successful) attempt to avoid 'Can't
Extend' errors. However, if you are
sending in a lot of submissions you
may not want to waste 100K of the
submission disc on the message file.
If you need to reduce the amount of
space required by the message file you
can convert it into the old format,
which is more compact. You should keep
a copy of the new format version in
case you wish to edit any of the
messages in it.
This will not make it any easier or
harder for the editor to handle your
messages, so do not go to the trouble
of converting the message file in the
belief that a smaller file will be
quicker for the editor to deal with.
(Of course, I just might be wrong
about this; if so I'm sure he will
point it out in a future issue.)
Another reason for wanting to convert
the message file to the old format is
that in the new format, deleted
messages may still be present and
could (in theory) be read by the
editor even though they will not be
published. In the unlikely event that
this is a problem for you, converting
the file to the old format will get
rid of all the deleted messages.
To convert a new format message file
to the old format just run the program
New2Old and put the disc containing
the message file in the drive when
asked. It will be renamed to !MsgOld
so that you have a copy and afterwards
the !Mesg file will contain the
messages in the old format.
The message editor
The main limitation of the message
editor is the lack of any form of
automatic paragraph reformatting when
words are inserted and deleted. The
real difficulty is that the editor
allows the use of mode 7 control codes
to implement colour and graphics.
This means that any code to reformat
paragraphs would have to try to keep
any control codes inserted in the text
to change the colour and it would
ideally also have to avoid distorting
any graphics in the message.
Using filing systems other than DFS and ADFS
The program is only designed to work
with DFS and ADFS. If you have another
filing system then the program may
work but no guarantees can be given.
Pressing SPACE at the prompt to insert
your submission disc will leave the
current filing system selected.
The file format
If you want to write any utilities
which handle message files (or even
write your own replacement message
creation program!), the file !Mesg has
the following format:
Version byte - 0 at present (see below)
Sender's ID - a three character string
read using BASIC's INPUT £chan%, id$
command
Sender's name - a twenty character
string (padded with spaces at the end)
read using BASIC's INPUT £chan%, name$
command. It may be just spaces if the
sender wishes to remain anonymous.
The file contains a fixed number of
message 'slots', each of which may
contain a message. At present there
are 25, but you might wish to deduce
the number from the length of the file
using the formula ((EXT
£chan%)-256)/4096. The message slots
are numbered 0-24, with the nth
message slot starting at offset
256+n*4096 within the file.
Each message slot has the following
format:
Destination ID - a three character
string read using BASIC's INPUT
£chan%, id$ command
Deleted flag - a single byte (see
below)
The message itself - pure mode 7
"text" containing control codes and
terminated by a 152 byte
Your program must complain if the
version byte is not one, as this will
indicate that the file format has
changed. If you wish your program can
try to handle earlier version 0 files
as well.
The deleted flag can be any of 0, 1 or
255. 1 means that this message slot
contains random junk from when the
message file was first created. In
this case the message itself is not
present and so you cannot rely on
there being a 152 byte at any point
following the deleted flag.
A deleted flag of 0 means that this
message slot contains a valid message
which is to be published or sent on to
the recipient.
A deleted flag of 255 means that this
message slot contains a valid message
which has been deleted and will be
ignored by the message collection
program used by the editor. Message
slots with a deleted flag of 255 can
be sensibly 'undeleted' by setting
their deleted flag to 0.
When the messaging system adds a new
message to the file it first tries to
find a slot with a deleted flag of 1.
If it succeeds, the new message is
placed in that slot. If not, it tries
to find a slot with a deleted flag of
255 and uses that, replacing the old
deleted message. If this fails as well
then there are no free slots in the
file.
The message itself must obviously be
short enough to prevent it running
over into the next message slot. The
messaging system currently limits
messages to 4080 bytes.
Many thanks to Jon Ripley for his
suggestions for a new file format.
Although the new format is much
simpler and cruder than his suggestion
it is very loosely based on it.