Appendixes

Appendix A: Message Bases [Fido *.MSG] [Squish] [JAM]
Appendix B: Error codes
Appendix C: Trademarks
Appendix D: WaterGate Development

Appendix A: Message Bases

If you receive messages, you will need a place to store them. WaterGate has built in support for three different messagebase types, each with its own characteristics. None of the supported bases puts more than one area into the same base, so if one area crashes for some reason, you won't lose more than just that area.

Both the Squish base and the JAM base can be considered successors to the Hudson Message Base. The HMB was a replacement for the Fido *.MSG base, but its limit of 200 message areas and maximum size of 16Mb makes it somewhat outdated compared to the huge message traffic produced by the various networks today. The Hudson Message Base is not supported by WaterGate.

Fido *.MSG

This is the oldest format, and is defined by FTS-0001. This format needs a sub-directory for each defined area. Every message is put into a single file, so this format is not recommended for areas that receive lots of messages, especially when using standard DOS FAT formatted hard disks. These become incredibly slow when the number of files in a single directory exceeds 256.

This type of base is compatible with almost any piece of software written for Fido. So you probably want to use it for your netmail directory, to allow other programs to easily insert messages.

If you create a Fido *.MSG area, make sure you enter a valid directory name in the "Area path" field, with a terminating backslash.

Examples:

C:\WSD\NETMAIL\
C:\WSD\NETMAIL\HISTORY\

Squish

Squish was designed in 1990 by Scott Dudley, and it is used in his Maximus BBS package and Squish mail processor. It uses 4 different files for each area: <name>.SQD contains the messages and header information; <name>.SQI contains an index to the messages in the SQD file; <name>.SQL contains lastread pointers for BBS users; and <name>.SQB contains dupecheck information. The SQB file is not used by WaterGate.

A Squish base can contain up to 2^32 (2 to the 32nd power) messages, which should be enough for anybody. (Don't quote me on this one, please.) If it isn't, you probably have more serious problems.

A Squish base can re-use space occupied by deleted messages without needing repacking, so you don't need to pack a Squish base as often as other types.

If you set a maximum number of messages for a Squish area, WaterGate will automatically delete the oldest message. So, the area never contains more than the set number of messages. Don't set this number too low, because if WaterGate has to delete large numbers of messages in each run, performance will suffer. If you want maximum performance and don't care about disk space, just set the limit to 0 messages.

If you use the Squish base for an area, the "Area Path" should contain a valid directory plus an 8 character area name. Don't use any extensions (.???) in the path and don't put a backslash at the end!

Examples:

C:\BBS\SQUISH\ALTBBS	for the area ALT.BBS
C:\BBS\SQUISH\ALTBMISC	for the area ALT.BBS.MISC
etc.

JAM

JAM was designed in 1993 by Joaquim Homrighausen, Andrew Milner, Mats Birch, and Mats Wallin. Like Squish, it is designed to support up to 2^32 messages in a single message area and uses 4 different files.

It uses a <name>.JHR file to store header information; each header consists of a fixed part and a flexible part, depending on the message. Storing only a small part in the fixed header makes it relatively easy to add future enhancements to the message base. Each header contains a pointer into the <name>.JDT file, which contains the actual message. The areabase is indexed in the <name>.JDX file and lastread information is stored into the <name>.JLR file.

JAM has a (for Fido systems) new way of linking messages: instead of simply linking messages with the same subject, each message can have an unlimited number of replies to it, so that each reply is a reply to the original message. This way you can always see to which message a new message is a reply.

Example:

1 --- 2 --- 4 --- 5
|     |
|     +---- 8
|
+---- 3 --- 7
|
+---- 6
Messages 2, 3, and 6 are a reply to message 1. Message 4 and 8 are a reply to message 2. Message 5 is a reply to message 4. Message 7 is a reply to message 3.

If you use the JAM base for an area, the "Area Path" should contain a valid directory plus an 8 character area name. Don't use any extensions (.xxx) in the path and don't use a terminating backslash!

Examples:

C:\BBS\JAM\ALTBBS		for the area ALT.BBS
C:\BBS\JAM\ALTBMISC		for the area ALT.BBS.MISC
etc.

Appendix B: Error codes

Below is a description for most of the error numbers that WaterGate writes in the logfile.

This should help you understand the error message better.

Code	Description

2	File not found
3	Path not found
4	Too many open files
5	File access denied
100	Disk read error
101	Disk write error
150	Disk is write-protected
158	Sector not found
200	Division by zero
202	Stack overflow error
216	General Protection fault

Appendix C: Trademarks

All trademarks are owned by their respective owners,
ARC,ZIP          PkWare, Inc
ARJ              Robert K. Jung
Binkley          Bit Bucket Software Co.
Fido             Tom Jennings
FrontDoor        Joaquim Homrighausen, Absolute Solutions
GEcho            Gerard J. van der Land
JAM (mbp)        Joaquim Homrighausen, Andrew Milner,
                 Mats Birch, Mats Wallin
LHA              Haruyasu Yoshizaka
MS-DOS           Microsoft Corporation
PAK              NoGate Consulting
PC-DOS,OS/2      IBM
Pentium          Intel
Squish,Maximus   Scott J. Dudley
TimEd            Gerard van Essen
Waffle           DarkSide International
MailTunnel       Waterline Software Development

Appendix D: WaterGate Development

People sometimes ask me about the environment I use to develop WaterGate, so below follows a little explanation.
Back to Table of Contents.

Comments or questions? Send an e-mail to editor@wsd.wline.se.

Last updated 13 October 1996