TriTel Online Reader v2.1
(c) 1991 Elm L. Morrow
written in Turbo Pascal 5.5
utilizing RMDOOR 2.0
For TriTel v2.x
911 N. Pacific Ave #15
Crescent City, CA 95531
Voice: (707) 465-6765
I relinquish any and all responsibility for anything that may
occur due to the use of this program, correctly or incorrectly. I am
in no way libel for any damage that is attributed to the use of this
program by any and all persons.
TriTel Online Reader is ShareWare. It's not crippled or
anything, but it does let your users know that it isn't registered by
showing #UNREGISTERED# at the top of the header on the file selection
Registration is only $17 for this new version. Future upgrades
will be priced accordingly depending on how much is changed and added.
Anyone who registers now will never have to pay for another registration
of this program. Your registration number will be good for all versions.
Distribution of this program will be solely the province of the
large number of BBS's across the country. I can't afford to send disks
out to people who register. I know this sounds kind of crude, but if
you enclose your BBS number when you register along with a password to
get on your system, I'll upload the latest version (if it's different)
and send you a private message in an appropriate conference that will
list your registration information (just a reg number and name actually).
Print and fill out the form in this archive called TTREAD.REG
and mail it to:
Elm L. Morrow
911 N. Pacific Ave Apt 15
Crescent City, CA 95531
Make checks or money orders payable to: Elm L. Morrow
WHAT IT'S FOR:
This Tritel door is for viewing text files while online. At first,
you think to yourself, "that's nuts! who wants to read stuff online?"
Well, this just might change your mind.
Do you have long, important bulletins? Nobody reads them because
it's such a pain. Now they can read them with paging ability, a simple
search function and, if they decide it's important, they can download the
file straight from the door!
This, however, is not the extent to which you can use this door.
Any text file you want your users to be able to access will work. The
list of files includes a security rating, so you can have various types
of information for different levels of users. You can display files
up to about 80 Kb. If the file is larger than that it truncates it.
I'll work on giving it the ability to be more flexible as I go along,
but I think it's capable of holding large enough documents for most
I don't know what the format is for things like USA Today and any
other news service that's out there, but if they're just text files and
are within the size limit, there should be no problem using this door.
If anyone out there cares to give me the spec's on anything like this,
I'd be more than happy to work it into the reader.
I do have a filter operating that removes the TriTel @ codes from
any document it displays. This is for things like bulletins or news
files that contain these special formatting codes that you don't want
people to look at. It doesn't remove them from the file, just refuses
to display them . BTW, this filter works with the WildCAT! format
commands as well since they, coincidentally, have the same format.
Please let me know of any other codes/strings that should be watched
for and filtered out of the display.
Since this new version is multinode, you will need to have a
configuration file for each node. I have called mine TTREAD1.CFG and
TTREAD2.CFG, but you can call them anything you like.
Ahhh. Now we come to the fun part! This reader requires a few files
besides itself to run. One set is the configuration files and the other
is the list of files with descriptions and security levels that you want
to give people access to.
Here is an example configuration file:
Works of Art BBS
not registered (or a 0 or something)
EMS (or the name of a swap file)
The first line is the type of door file you are going to use. In
this case, it's PCBOARD. The full list is as follows:
PCB for PCBoard,
GAP for GAP (DOOR.SYS),
SF for Spitfire,
RBBS for RBBS, or
WC for WildCat!
Line two tells the door what directory the door file generated by
the BBS will be in. This is generally your node's main directory. For
example, Node 1 on my board is C:\TRITEL and node 2 is C:\TRITEL2.
Line three is the name of the BBS. This is also the registration
name that you must use with your registration number. More on that later.
Line four is the SysOp's name.
Line five is the speed at which your port is locked. If you don't
lock your port, then put a zero (0) on this line.
Line six is your registration number. Registration numbers are
based on a somewhat random algorithm that is based upon the characters
of your BBS's name. All of my utils have a different algorithm, so don't
get any ideas .
Line seven can hold either the word EMS (in CAPS!) or the name of
a swap file. The reader will attempt to swap itself to EMS if it can
allocate the memory. Even if you told it to grab EMS, if there isn't
enough available it will swap itself out to a file called SWAP.$$$.
If you give *any other* value on this line, it will be used as the
name of a swap file. Remember: EMS in CAPS!
The reader also needs three data files that essentially define your
list of files to view, what archivers are available and what protocols the
user can invoke in the download function. They are detailed below.
This file *must* reside in the same directory as the reader. It is a
simple text file that contains a list of entries that take this form:
The first field is obvious. You must tell the reader on what
drive and directory the file is. There is no requirement that it be
in the directory you run the viewer from.
can be up to 50 characters long, so you should
be able to get the point across. This is what the users will see when
they are selecting the file from the Selection Menu.
is the level of security a user must have to be able to
read that specific file.
This file contains the archivers that you want made available to
your users when they invoke the download function. This file is a pure
text file that *must* have single lines for each entry that take this
The first field must have the full name and path to the archiver.
You must also provide an extension. Just follow the form in the brackets
and you'll be okay.
can only be up to 20 characters long and it will be
used as the line on the menu that the user will be choosing from.
is a little more complicated. You need to provide
a command line that the archiver will use. There are two parameters that
the reader will pass to it:
%1 Name of archive
%2 Name of file to archive
is the three-character extension that archives created
with the archiver will have. (i.e. ZIP for PKZIP, ARJ for ARJ, etc...)
Here's an example of what your entries should look like:
c:\dos\pkzip.exe,PKZIP (Most Popular),%1 %2,ZIP
c:\dos\lha.exe,LHA (Very fast),a %1 %2,LZH
This file contains the list and necessary information for the
different type of protocols that the user will have at their disposal.
It is also a simple text file that contains one-line entries: