Category : BBS Programs+Doors
Archive   : FXB31.ZIP
Filename : VERS31B.DOC

 
Output of file : VERS31B.DOC contained in archive : FXB31.ZIP
Notes for Version 3.1B 4 May, 1990


1. Corrected a problem which occured when, during an upload, if the
caller was a) asked if a file was for a conference, and b) attempted
to list the conferences, the program would crash. The problem was
that a procedure which was declared 'near' had been made 'far', and
this wasn't done properly.


2. For the process of listing new files, it seems that some users of
a system in Southern California don't really care for the summary
list of file names only which is output before detailed descriptions
of files are searched for. I played with adding an option to either
output the filenames or not, following which the detailed descriptions
would be searched for and displayed. Ultimately, I didn't care for
how that turned out. What I ended up doing was to eliminate the
output of the date and time for files listed before the detailed
listing, allowing the output to be in two column format, thus perhaps
speeding the output of such a list by 50%. A middle of the road approach
in intent.


3. Clayton Winton found for me, a problem when using EMS memory
repeatedly (previous tests have not involved running with EMS for
more than an hour or two). As the day wore on, it seems that Clayton
would run out of EMS memory. Not all of it was being returned to the
system upon exit. Problem corrected.


4. Modified the character output logic for the callers. Previously,
any character output to the local screen when a caller was online was
output using Dos's screen write functions. This has been modified
such that when configured to write directly to the screen, a good bit
of the text will be written which the caller might also see is displayed
locally using direct screen writes. The exception to this is that
when ANSI.SYS graphics are to be displayed, that portion of the character
output involving the ANSI graphics is sent out using normal Dos again.
The upshot of this is that when using direct screen writes and no ANSI
graphics, local screen processing takes about 10% less time...


5. "Detuned" multitasking optimization just a wee bit here and there.
Notably, in the message processing area of the BBS program proper, and
in the FXMAIL and FXREPACK programs.


6. Observed that the FXMAIL program was asking Dos for memory before
it ran any compression program required, meaning that FXMAIL potentially
required more memory to run than it should have (enough for both the
buffer and the compression program). Moved the request for memory to
a point after the compression programs have been run to correct this
oversight.


-------------------------------------------

Notes for version 3.1A of FX-BBS: 18 Feb, 1990


The Good News: Peter Koch has finally found some hardware which takes
advantage of FX-BBS's ability to use any IRQ and any port address.

The Bad News: It's not cheap...

The board is a Qua Tech DS100. It is a 16-bit card (with the longer
edge connector), with provisions for two serial ports. It can be
configured to use almost any of the valid AT IRQ numbers up to 15, so long
as the IRQ in question is not in use by another device. The UART ports
may also be configured to be located at any address. The board comes
standard from the manufacturer with NS16450 UARTS, with the option to
upgrade to the NS16550 UART. The board also supports shared interrupts
(configuring both ports to use the same IRQ). This is not presently
supported by FX-BBS, but may be in the near future...

The board presently has a LIST cost of $195. When NS16550 UARTS are
used, the list cost of the board becomes $215.

I am now making this board available for purchase from myself, at a
discounted cost. Registered users of FX-BBS will be able to purchase it
at a further reduced cost. The actual cost is not included here since
prices can and do vary. Please contact me if you're interested in the
DS100. Note however, that because the NS16550 UART has superior features
for use in a multitasking environment, I only offer boards which are
equipped with these, adding to the cost of the unit.

This is a nice board and it may be used as a "normal" serial board if
you configure it appropriately. Even at a reduced cost however, it is
not inexpensive. You should only need to consider it if you think you'll
ever run more than four lines (or have more than four serial devices
including those running FX-BBS) on a single system, or if you want a
particularly excellent serial card. While a superior card. it will not
be usable with all programs or devices when configured for the higher
IRQs and such.


Program Changes:

IMPORTANT NOTES:

1) MEMORY REQUIREMENTS HAVE CHANGED. Due to door and conference
processing modifications described below, the amount of memory required
by the program to hold its array data has increased. You should now allow
10Kb of memory for such when considering your parameters on Screen N (up
from the previous 9Kb, and assuming you're using those parameters).

2) THE FORMAT OF THE CONFIGURATION FILE HAS BEEN SERIOUSLY CHANGED.
APPROXIMATELY 480 (yeah, four hundred and eighty) NEW PARAMETERS HAVE
BEEN ADDED TO THE CONFIG FILE. Owing to the amount of information now
contained in the file (976 ASCII lines of text), and memory limitations,
it has been necessary to reduce the maximum length of each line of the
configuration file to 36 characters.

Existing configuration files WILL be loaded by the setup program, and will
be properly saved for the most part. However... There is a problem for
some reason in converting parameters on the conference screen. Be sure
to verify that all parameters on this screen are correct. Also, any line
longer than 36 characters will be truncated to 36 characters. You will
therefore, want to verify that longer parameters are stored correctly.
Previously, all lines of the configuration file allowed comments at the
end (when edited via ASCII text editor). This is no longer permitted, not
that I think any of you actually used an ASCII editor on the files anyway.
Only the significant portion of each line of the configuration file is
saved now. The result is a significant reduction in the size of the files
generated.


PROGRAMS WHICH HAVE CHANGED SINCE THE LAST VERSION:

1. FX-BBS
2. FXBSETUP
3. EDITUSER
4. FXREPACK
5. FXMAIL
6. FXDCHECK
7. FXFILCVT (addition of version statement only)

NEW PROGRAMS FOR THIS VERSION:

1. KEYCODES
2. FXUSRINF

-----------------------------------------------------------------------------

1. The number of door programs supported has been increased to 40. A
'door' program is simply a program external to the BBS program that
one might wish to run for whatever reason. Traditionally encountered
doors are game programs most often. Sometimes database programs are
found which can be run as doors. Other external programs might be
'fortune cookie' types of programs (programs that offer some witicism,
Murphy's law, etc), programs supporting other echoed message formats
(other than FidoNet), certain types of file transfer programs perhaps,
or just about anything you might imagine.

Different catagories of doors are supported now, with the sysop
defining the 'key' (or caller input) to open or process a door. The
intent of all this whacko door processing described here is to allow
sysops to extend the functionality of their system in ways I may not
have anticipated. If you find the processing to be too confusing, you
may wish to ignore this. But at least you now have that option.
'Door keys' are processed as follows:

Doors which are to be processed from the doors menu proper are
assigned door keys of 'A' through 'Z'. These doors cannot be
selected without the caller first selecting the [O]pen door option
from the main menu. Callers cannot access these doors if they
have an access level below 2.

Doors which are assigned key values of '1' through '6' are selectable
from the main menu. Callers may access these doors regardless of
their access level.

Doors which are assigned key values of 100 through 150 are accessible
from the [F]iles menu. I don't know particularly why someone would
wish to use doors there, but they may. If, when the caller is asked
to enter the directory number they wish to view, they were to type
'105', FX-BBS would make an effort to open the door which had the
'key value' of '105' assigned to it. Callers may run these doors
regardless of access level.

A door which is assigned a key value of '+' is a 'logon door'. The
caller does not select this door for running. Instead, it is run
automatically if it exists, at the point of the program after which
bulletins and news files have been processed, and prior to the point
at which the program displays the message "Initializing Messages".
Only one such door may exist. It runs regardless of access level.

A door which is assigned a key value of '-' is a 'logoff door'.
This door is similar in almost all ways to the logon door, with the
exception that it is run after the caller has been asked whether
they wish to leave a comment for the sysop, and before the GOODBYE.TXT
file is output to them. Again, it is run regardless of access level,
and there may be only one such door.

It would be nice if doors could be associated with conferences, and
be accessible only to conference members. Presently, this can not be
done. I'm working on it.

ALL doors may be configured to be either spawned or exited to. Remember
though that re-entering the program after exiting to a door causes
FX-BBS to ask the caller for their password again. At the very least,
the logon and logoff doors should likely not be exited to then, and
other doors should be configured in this way with caution.


2. The number of conferences supported has been increased to 20.
Processing associated with conferences has not otherwise changed
significantly, with one exception: Conference membership was
previously indicated in the user record by a byte sized flag. This
flag is now 'bit sized'. If you have established conferences, you
will have to use the EDITUSER program to manually respecify conference
membership for each caller it concerns.

Note too, that LAN chatting may still be associated with conferences,
but is limited to the FIRST SIX conferences and the main menu, as
before. Adding support to FXCNFCFG and FXCOMML for 21 total conference
chat areas would a) use additional memory, and b) strain system resources,
sometimes introducing errors as a result of inadequate resources being
provided in the system's boot configuration. It would also take time
away from me which might better be used in other areas of program
development, and so has been dispensed with.


3. Added an exitlevel value for timed exits so that things could be
handled more clearly in any batch file running. Due to the increased
number of doors available, errorlevel values have changed somewhat.
Errorlevel values are now as follows:

0 - A normal exit, however this might occur...
1 - Modem is refusing to send.
2 - Premature end of configuration file.
3 - Configuration file not found.
4 - Configuration file error. Maximum line length exceeded.
5 - No user ID file name specified in configuration file.
6 - Unable to open user ID file due to an unknown error.
7 - A problem has been encountered in attempting to reclaim memory
which was freed before running an external program.
8 - Com port number is out of range.
22 - FXCOMM was not loaded into memory, but was requested for use.
23 - Insufficient memory for message editing buffer.
30,31,32,
34,35 - General EMS Memory errors (problems reported by EMS driver).
33 - Unable to allocate EMS memory as requested on Screen N.
87 - Modified program detected.
97 - Async receive buffer overflowed.
98 - A timed exit.
99 - An exit that has been requested (ALT-X).

Errorlevel values of 99 and below are reserved for abnormal termination
indicators by the BBS program proper.

Other errorlevel values are provided by door processing when a given
door is to be exited to. These values will be equal to a base value
of 100, plus the door number (1 to 40), plus ((the modem port number - 1)
* 40). More simply, doors 1 through 40 on com1 will produce exit values
of 101 through 140. Doors 1 through 40 on com2 will produce exit values
of 141 through 180. Doors 1 through 40 on com3 will produce exit values
of 181 through 220. Doors 1 through 35 on com4 will produce exit values
of 221 through 255. Errorlevel values of greater than 255 cannot be
produced it seems. Because of this, com5 exit values are the same as
those for com1, com6 exit values the same as com2, com7 the same as com3
and com8 the same values as com4. Errorlevel values are not supported
for doors 34 through 40 on com4 or com8. These combinations should be
avoided. The results of such combinations is undefined and untested.


4. Processing associated with the "Initializing Messages" area has
been sped up.


5. A sysop points out that a message is displayed sometimes on program
startup which is too rapid to really see. It says something about the
'Communications Area.' This should cause no real concern... It is
intended to be an informational message that, if one were desperate
and quick enough to stop the system at the right time, could be viewed.
For multi-line systems, it is the address in memory where the inter-
program cummunications buffer lives, and will typically live either
in screen ram, or in an area of memory obtained by FXCOMM. A similar
message is output when external door programs are exited to... A
quickly displayed message indicating the value of errorlevel is
displayed.


6. Some attention was given to speeding up com output in general and menu
processing in particular. A few instructions in the com output were
removed, or repositioned to avoid processing if possible. Menu processing
is complex. Not a great deal was possible to improve its performance,
but some tweaking was done. At 2400 baud, com output really can't go
any faster than that. So my efforts really were intended to reduce
processor time consumed by the program in its effort to get each byte
out the port...


7. Re-corrected processing associated with stacking one's password during
caller logging on. The ability to stack the password (enter it following
entry of one's name, separated by a semi-colon) was lost a version or two
back as the result of correcting another problem. Hope fixing it didn't
introduce that problem again, whatever it was...


8. Corrected a problem which resulted in the program looping following
re-entry of the program after running a door which was exited to during
a local (non-modem) logon. You followed that, right?


9. Added yet another screen to the FXBSETUP program. Let's see... Almost
all of the function key inputs which previously existed have been changed.
ALT-F3 (sysop avail) is now ALT-S for example. This should be helpful to
those of you using that "simply marvelous" 101 key keyboard on which they've
moved all the function keys as far from the shift, alt and ctrl keys as
possible, and perhaps make the inputs more meaningful as well (easier to
remember). The function key inputs which remain tied to function keys
are any which were assigned to F1, F2, ALT-F1 and/or ALT-F2 (display
menu, run program, etc).

Since most function keys were freed by this action, the ability for the
sysop to assign strings to all function keys other than F1 or F2 (and
the various shifted/alted/ctrled versions of F1 and F2) was added on
setup screen O. Each function key can have assigned to it a string
of up to 25 characters, of any form. I'd like to say before going any
further that

***YOU SHOULD NOT ASSIGN YOUR SYSOP PASSWORD TO A FUNCTION KEY***

It would be far too easy to depress the wrong key while a caller was
online and disclose this tidbit of information.

Generally, any string you wish can be stuffed into a function key. It
may be fed to the system from any point at which a keyboard input is
legal. It will be fed to the program exactly as entered in the setup
program. No carraige return will be output unless you've specified one
on the setup screen for that string. This may be done by entering a
"^M" at the point in the string you wish to have a return fed to the
program. For example, entering "STRING 1^MSTRING2" for a function key
would cause "STRING 1" to be output, followed by a return, followed by
"STRING2". Any CTRL code may be assigned to a function key in this
manner. To output a line feed, you would enter a "^J". To output a
page eject, you would enter a "^L". A tab input is represented by the
"^I" input. The various ALT-?? keystroke combinations may also be assigned
to a function key. These inputs are composed of a two key code input
to the system (as Dos was designed to generate), the first of which is
a value of zero. A value of zero may be entered for a function key by
typing the string "^@". A zero value, and any other numeric value, may
also be entered by typing "^", followed by the number you wish. To enter
a value of 48 for example, you could type "^48". The input ALT-R is
composed of two byte values of first zero (0), and second, 19. This
could be entered as either "^@^19", or "^0^19".

Function keys may not contain the inputs required to invoke say, four
other function key assignments, at least as a single assignment. That
is, each time a string associated with a function key is loaded for
processing, it will replace any previous one being processed. Function
key assignments may however, be "chained." That is, one function key
can output up to 21 characters and end with the control sequence to
of another function key, which will cause that function key's characters
to be loaded and processed. The second function key string could in turn,
chain to an additional function key string if necessary.

A simple program to show you the byte values generated by the computer
when a given key is depressed is included with the program now. This
program is called "KEYCODES.EXE". When run, it will continue to run
until CTRL-C is entered. Each time a key is depressed, numeric values
will be displayed. You may assign a particular key's code to a function
key by entering these numbers (preceded by the necessary "^" character)
in the function key string.


10. Added the ability to forward a message to another caller. To forward a
message, one must first be reading the message. After selecting the
[F]orward option, one is asked for confirmation that they wish to forward
the message. Following this, a new message header is requested, just as
if the caller were entering a new message. The message may be moved to
another message section, addressed to another individual, made private or
not, and so on. The caller is offered the opportunity to enter a two
line comment to be added to the start of the message as well. A tag is
added to the message indicating the original message section the message
was stored in, who it originally came from and was to, and the date the
message was sent. There is a minor restriction that comes with this
feature... To forward a message, there must be enough free memory available
to make a copy of the message, regardless of the message's size, up to 64Kb.
If insufficient memory exists for this, the message "Unable to Forward
Message" will be displayed. This change, along with the next, necessitated
the creation of yet another overlay in order to keep memory consumption at
its current level. Any caller may forward a message to another caller,
without regard to whether the message was originally private. I don't
know how happy I am with the way the private message forwarding logic
works... Maybe it's the case that private messages should not be
"forwardable?" Should a private message be forwarded and made public
in the process, it's possible that there could be legal problems. On
the otherhand, preventing this possibility in all cases seems overly
restrictive. Inputs please.


11. Added the ability for the sysop to move a particular message from
the message section it is currently stored in to another section.
After the message is posted in the desired section, it is deleted in
the current one (the message deleted bit flag is set). Note that this
function not allow the sysop to modify the message header in any way.
Permitting such does not seem appropriate. Should different header
information be required, it is suggested that the message be forwarded
to another caller (or to "All") in the desired message section. In the
latter case, the message will be tagged to indicate who the original
sender and receiver was. This function is only available to the sysop,
and only when logged on from the local keyboard.


12. The meaning of "Touching" a message has been slightly altered.
The previous purpose of this function was to allow an echo or netmail
message to be resent, on the assumption that it may have been lost in
the echomail trail the first time it was sent. It will still do this,
provided the message originated at your net/node. Any message may now
be touched, however... What occurs when this is done is that the date
and time the message was entered is modified to be the current date
and time so that the next time callers look for new messages, it will
show up. This dating process will occur regardless of the message in
question. Again however, the message will be resent via the echomail
process only if the message originated at your net/node. As in the
above cases, should you wish to repost a message and actually have a
dupe of the message transmitted to the world, you may accomplish this
by using the message forwarding feature, or by replying to the message
and quoting the relavent portion. In either case, your name will be
prominently displayed in the message, so that the world knows who is
responsible for its re-appearance. The Touch function, as before, can
only be used by the sysop, and only when logged on from the local
keyboard.


13. Good news and bad news...

First the good news: The size of the configuration files produced
by FXBSETUP have been drastically reduced.

The number of mail sections supported has been increased to 80.
Many echomail sysops like to have that many or more message sections
floating about. To do this and get all the parameters on the existing
screens, it was necessary to limit message section names to 25 characters,
as well as to simply cram 160 additional parameters onto screen F. Yes,
it looks a bit more cluttered, and is a bit more difficult to follow.
But I got it all in (320 parameters on one screen, and no, I'm not too
proud of that).

Now the bad news:

The addition of the 40 message areas was the straw that broke the camel's
back... The FXBSETUP program is limited to 64Kb of data, and as designed,
I exceeded that amount, meaning that FXBSETUP would not compile until I
reduced memory requirements. Obviously I'm going to have to revisit the
setup program again in the future... Maybe remove message processing all
together, or who knows what? Nothing more can be added to the file,
until the program is at least partially rewritten.

Methods of getting around this problem were limited. It was necessary
to reduce the maximum size of each parameter contained in the configuration
files to 36 characters of significant data. This means that presently,
no parameter on any screen may exceed 36 characters in length.


14. Revisited the ability of the program to exit at a given time. Found
a possible error and corrected it. Retested and all appears ok. The
window for exiting could however, be small enough to be missed. The exit
timer is not set until the current hour is less than the hour of exit.
Once the exit timer is set, the program waits for the current hour to
be greater than the exit hour. If the exit hour is 1 and a caller is
connected from 23:30 until 01:30, the exit timer would never be set.

This problem has largely been corrected by adding a bit of rudeness to
the program. Main menu processing now also watches the exit time. If
the above conditions are found to be met, another timer is set and a
"three minute warning" is issued. The main menu then watches the time
and waits for three minutes to expire. At this point, the program exits.
The status display function also watches the timer, so that if the
caller is reading messages or bulletins or whatever, the timer will
still be effective. Finally, once the three minute warning is issued,
downloads and uploads are not permitted.


15. Removed those annoying beeps when blocks of text are marked using
the ANSI editor.


16. Corrected a problem in the display of number of callers when that
number excceded 32767.


17. Corrected an ordering problem on upload verification. Previously,
the uploaded file was searched for before checking the validity of the
filename the caller specified. These two checks have been reversed.


18. Modified the "search message by subject" logic in a few different
ways.

a) Previously, the sender and receiver names were not being checked
for the specified subject. This is now done, allowing a caller to
search for messages to or from a given person or set of persons.

b) Modified the program to allow a set of subjects to be specified.
All subjects (one or more) are entered on one line. If more than
one subject is desired, the subjects must be separated by the dos
pipe character ("|"). To search for messages to or from myself for
example, along with subjects containing the keywords "msdos" and/or
"desqview", one could enter as the subjects to search for,
"roach|msdos|desqview". The search is done on an OR and not an
AND basis. Any of those subjects will cause the program to assume
the subject matter desired has been found.

c) When a subject is found, the program now outputs a message indicating
which subject was found, and whether it was found in the caller's
name, receiver's name, message subject line, or body of the message.
If found in the body of the message, the line in which the subject
was found is output as well. The caller must then depress enter,
following which the message will be displayed.


19. Logic was added to the program to change back to the original
drive and directory any time an external program is run (be it door
or file transfer program).


20. Corrected a problem causing excessive "Continue (Yes/No/Continuous)"
messages to be output sometimes when a caller had entered 'C' at logon
in order to convert graphics.


21. For reading messages by section, when the caller is asked for the
first message number to start with, added the option for callers to
enter 'N' to read new messages only. This allows for various filters
to be applied, such as read from, read to, or read by subject, to new
messages only.


22. A user reported problems with sharing violations on the main menu.
I do not doubt that the user experienced something along these lines.
However, in testing, I am unable to reproduce the problem. (Update:
it turns out the user had installed a new version of Dos, but not a new
version of Share. It took a while before he noticed that Share was
refusing to run when the system was booted. Problem corrected).


23. At the request of a user, and cause it seems like a reasonable idea,
the sysop [A]dd File function now asks if you're sure you want to save
the file description after it's been entered.


24. After [A]dding a file, the program now asks if you wish to go
ahead and [I]nstall the file. This allows you to simply place new files
into the upload directory area, enter file descriptions with the [A]dd
function, and have the desriptions placed into the dir files as required,
without using an editor, if you wish.


25. Consolidated the miscellaneous mess of odd parameters associated
with uploads and downloads into one standard popup sort of display that's
the same for all uploads and downloads. All parameters listed on the
display are the same regardless of what protocol is in use, or whether
it's an upload or download. But not all parameters will be used in each
case. For example, the "user program" parameter is generally not known,
and in fact, at the present time, is only displayed when a Sealink
upload is being done. All in all, the current display is a good
improvement over the other random sets of information, and adding
new protocols which will use the display should be somewhat simplified.


26. Several changes have been made to the FXMAIL program and the
processing it performs:

A: FXMAIL now allows you to specify multiple decompression programs
in the FXMAIL.DEF file. If the appropriate decompression command is
provided, FXMAIL attempts to use the correct one, based on information
found in the compressed mail file. Seperate decompression commands
may be specified for processing ZIP, ZOO, ARC and/or LZH type files,
with a fifth decompression method possible for any other (unknown)
mail file types. For any decompression method not desired, you should
enter the word "NONE" in the FXMAIL.DEF file for that file type.

FXMAIL continues to offer only one option for generating your own mail
packets, specified either on line 4 of the FXMAIL.DEF file, or on the
command line when FXMAIL is invoked. Also be aware that in the event the
FXMAIL.DEF file is not used (you are specifying all options via the
command line), only one decompression method may be specified.

B: Previously, FXMAIL deleted mail files once an effort had been made to
decompressed them. An effort to status check the decompression process
is now made, but relies on a proper indication of success or failure to
be returned by the decompression program. In the event the FXMAIL can
determine that a given file was not properly decompressed, the file
in question will NOT be deleted.

C: FXMAIL now processes 'tic' files which have been received. Tic
files are files produced by Barry Geller's TICK program, which describe
other files which may have been sent to your system. Most often, this
is done for files belonging to a sort of conference. For example, I
recently became a member of something called "DVNet", a collection of
systems which exchange files supporting DesqView. New DesqView related
files are received from time to time, and are accompanied by a tic file
which describes the files received, including where the file came from,
where it originated, the "area" the file belongs to, and an actual file
description in text form. This is different then from a normal file
attach, which would not be accompanied by a tic file.

For example, someone might send you a file called SAMPLE.ZIP, accompanied
by a tic file. When FXMAIL finds a tic file, it attempts to read the
information in the file. If successful, and if you've entered the
appropriate parameters in the FXMAIL.DEF file, FXMAIL will take care
of moving the file received to any other area you may have specified
(generally a caller accessible download area), will then extract the file
description from the tic file and place it into the directories you've
specified, and lastly, will leave you a message indicating that this has
been done in the message area you've specified.

Because of the additional compression commands now supported, as well
as tic file processing, the format of the FXMAIL.DEF file has changed
slightly (mostly, it has been added to). The format is now as follows:


line 1: FX-BBS configuration file name.
line 2: Drive and directory where incoming mail can be found.
line 3: Drive and directory where outbound mail is to be placed.
line 4: Compression command for use in generating mail packets.
line 5: Decompression command for ZIP mail packets.
line 7: Decompression command for ARC mail packets.
line 8: Decompression command for ZOO mail packets.
line 9: Decompression command for LZH mail packets.
line 10: Decompression command for other mail packets.

(the following lines are optional, and repeat for the number of areas
you've specified for use with tic files, up to 80 sets):

line 11: The word, "AREA"
line 12: "NAME" followed by the name of the area in question as reported in
the tic file.
line 13: "PATH" followed by the fully qualified path name where the file
is to be placed after processing.
line 14: "DIR" followed by the directory file number where the file
description is to be placed.
line 15: "SEC" followed by the message section number where a message
indicating receipt of the file is to be placed.

An example FXMAIL.DEF file follows (comments are included below, but should
NOT be in the actual FXMAIL.DEF file):

d:\fx-bbs\fx-bbs.cfg ; fx-bbs configuration file
f:\binkley\netfiles ; directory where newly received files are
f:\binkley\outbound ; directory in which outbound files are to be placed
c:\util\pkzip ; primary compression command
c:\util\pkunzip ; ZIP decompression command
c:\util\arce ; ARC decompression command
c:\util\zoo e ; ZOO decompression command
c:\util\lharc e ; LZH decompression command
NONE ; "other" decompression command
AREA ; area label
NAME DVNet ; name of an area
PATH C:\FX-BBS\DVNet ; directory where received files are to be moved to
DIR 47 ; dir file number file description is to be put in
SEC 38 ; message area where note is to be left

You should NOT have leading blanks on any line of the FXMAIL.DEF file.

FXMAIL does not delete the tic files after they have been processed. It
seems incorrect to deny you later access to these files in the event of a
problem, and so automatic deletion was omitted. When FXMAIL has completed
processing of a tic file successfully, it renames the file to have an
extension of "INS", as in "installed." You may add a "DEL *.INS" command
to your mail batch file should you wish to do this, or can do it manually
later. Any tic files which remain after FXMAIL has been run could not be
processed for some reason or another.

Neither FX-BBS nor FXMAIL has the ability to generate a tic file. Should
you wish to do this, you should obtain a copy of Mr. Geller's TICK program.
The primary reason FXMAIL now processes incoming tic files is to allow
the file description, etc to be formatted properly for use with FX-BBS.
TICK presently cannot handle multiline file descriptions, though it is
supposed to be able to at some point or another, I think. FXMAIL however,
can at the present time, process multiline file descriptions.

Final notes: The message section you tell FXMAIL to leave its tic file
related messages in should NOT be an echomail or netmail area! If you
do not wish to have messages posted for you telling you that a tic file
has been processed, specifiy a message section of 0 for the area in
question in the FXMAIL.DEF file.

Note too, that FXMAIL does not perform CRC checks of the files received,
though Mr. Geller's TICK program gnerates CRCs, and includes a seperate
program that verifies things are proper.

FXMAIL moves the file received from the netmail area to its final destination
using the MOVE program supplied with FX-BBS. FXMAIL therefore must be
able to find the MOVE program and run it in order to process things
correctly. The move program then, must either be in the current directory,
or must be in one of the directories described in your PATH statement.

FXMAIL is not presently able to recompress files received to be in a common
format. If you prefer ZIP files for example, and receive an LZH file,
you will have to convert the file and modify the directory file manually.

It's likely the case that you do not need to be concerned with tic file
processing until such time as you become a memober of a group which sends
file around in this manner.


27. Because mail processing often involves several different programs
of varying sizes, and therefore different memory requirements, I've
developed an overlay version of the FXMAIL program. Registered users who
feel a need for it may obtain it from me or from BerthaBoard.


28. Corrected a bug reported by Clayton Winton that could cause the user
file to accidently be extended beyond the proper size when changing a
caller's access level from the sysop maintenance area in the FX-BBS
program (a very good catch on Clayton's part).


29. Revisited processing associated with the lookup of caller records.
Now and again, the program has failed to find a caller when it should
have, resulting in a duplicate record being added to the user file. I
found no obvious problems, but made a change or two to some code that
might have an effect on the matter. That is, I don't know why this
problem occurs, and it shouldn't, and I don't know if I've fixed
anything...


30. I've been working on adding internal support of Zmodem, but now feel
a reduced need to add this. The latest (well, "later") versions of
Forsberg's DSZ program have much improved performance under DesqView.
DSZ is no longer such a cpu time hog. It seems as well that DSZ now
supports IRQs up through 7. The particular version I found having these
improved features was DSZ0411.ZIP. You might want to look it up if you're
running under DesqView. I'll probably be adding Zmodem support anyway,
but may take the summer off first...

In any case, the documentation for FX-BBS version 3.0 suggested that
one might wish to attempt to use the TAME program with DSZ when one is
running under DesqView. This is no longer needed, and so is not
recommended any longer.


31. Program has been tested with DesqView 2.26 and QEMM 5 (latest
releases). No significant problems observed, nor any significant
improvements in how DV or QEMM function (though I'm certain improvements
were made by Quarterdeck).


32. I've had reports from a couple of folks indicating that they have
been unable to get FX-BBS to run at all on certain XT class systems. Due
to geography, time and so on, I have been unable to perform hands on
testing of the program on the systems in question. The problem is always
the same however: The modem refuses to initialize. I have been unable
to reproduce the problem on XT systems I have access to. Thinking about
this, it seems likely that the problem relates to something I've not
thought of with regard to different UARTS or some other hardware difference
that my serial port initialization doesn't take into account (my own
code was necessary to initialize things at greater than 9600 baud, and to
support more than com1 and com2).

To help try and overcome this problem for users of such systems, I've
added a bit of code that will initialize the serial port using dos, but
only under certain conditions. First, the maximum baud rate must be 9600
or less. Second, communications optimization must be set to 0. Third,
the modem port number must be set to 1 or 2. If 1 is selected, then the
following parameters must be set as indicated here: I/O Reg Address
must be set to 0x03f8, the Interrupt Vector must be 0x0c, the Interrupt
Mask must be 0xef and the IRQ Number must be set to 4. If 2 is selected,
then the following parameters must be set as indicated here: I/O Reg
Address must be set to 0x02f8, the Interrupt Vector must be 0x0b, the
Interrupt Mask must be 0xf7 and the IRQ Number must be set to 3.

If ANY of these parameters are set to a value other than that indicated
here, Dos will be bypassed and FX-BBS will use its own modem initialization
code. Because I'm dealing with an unknown quantity here, processing
performed must be as simple as possible. FX-BBS will not check for a
16550 UART for example, and won't turn on transmit interrupts. Instead,
brute force will be used to talk to the modem. Hopefully, this will
take care of the problem for the users in question.


33. A program called FXUSRINF was written to convert FXINFOxx.INF files
into the format required for use by Milton Gameworks door programs.
The specific door program which caused me to write FXUSRINF was a game
called "Planet Busters". FXUSRINF requires two inputs. The first is
the name of the specific FXINFOxx.INF file which is to be converted,
the second is the name of the file to be output. Example:

FXUSRINF FXINFO02.INF USERINFO.TXT



  3 Responses to “Category : BBS Programs+Doors
Archive   : FXB31.ZIP
Filename : VERS31B.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/