| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Beta 3/6 |
Telegard Bulletin Board Software, v3.03
Revision History Documentation
Copyright (C) 1997 by Tim Strike
All Rights Reserved.
3.03 Beta 3 - February 23, 1997
NOTES
I had intended on getting this beta to you late Friday, but
after spending much of the day in front of the computer, I just
couldn't finish the work I had started (and I wanted to finish
it before I sent you a version -- which worked -- but was not
at a level where I could afford to leave it for a few days and
remember where I was).
You see, the source code was a mess to begin with, and all the
new routines, the improved routines, etc. were in various
source files mixed in with the original 3.0 code, and the 2.98
series code, and even some of the 2.80 series of code where I
added JAM & Squish. Subsequently, I wanted to clean up *all*
the code, give function names common names (like chat_request,
or misc_lastcallers, etc). While doing that, I also wanted to
remove all the library cross-dependencies and layer the source
code such that each layer uses only those layers lower than it
-- this is a structured method to design, and once accomplished
does make things infinitely easier. I just didn't think it
would take *this* long. I've got a flow chart of what library
uses what other libraries, etc. and I've been layering from
that information that I've been gathering all day.
At any rate, Telegard is presently 48076 lines of source code
(C/C++, ASM and support utilities not included), spread over
74 source files. I managed to get through 51 of the source
files in a little over 10 hours (mind you, I was also adding
and optimizing much of the code I came across), and that is
the time I had alloted to do this *and* the rest of the changes
I promised (and need to complete) for this beta.
Needless to say, I'm exhausted. And since this really has no
use other than to delay my sleep (imagine that, procrastinating
from the very thing that I desire), and couple that with the
worst cross-dependancies still to come, the file & message
sections, I'm going to end this note here at 6am.
INSTALLATION NOTES
Please leave yourself an or two hour to complete the installation
and do minor tests. I suggest doing this upgrade at a time when
you'll be around to monitor your system (i.e. not before you head
off to work or go to bed) -- or in-at-least after several other
gungho sites have upgraded and say it's working okay, and even then
the changes for *your* particular system could be extensive.
This beta works here (as you can see since I've been using it to
post messages for 2 weeks now) -- HOWEVER -- this beta has *not*
been tested online, and the file section changes were *not* tested
either (I can't from here). Thus, while I have done as much alpha
testing as I possibly can at this stage, this beta still deserves
some special treatment in-that a lot of the stuff here is
experimental and a drastic change from what we're used to (this
beta is definately not PnP yet).
1. Make a backup of your data & language files (including *.MSI
and *.FSI files -- not neccessarily your entire message
section)
2. Read WHATSNEW.303 for beta-03 -- there are *many* important
changes, most notably:
i. DOOR.SYS file format was changed to represent the TRUE
format of the file. Your doors will not likely work
unless you edit your users' door records, or use the
OLDDOORS.SCR file. YOU HAVE BEEN WARNED!
ii. NEWUSERV, MSGREAD, WFCQFILE and WFCQMSG menus are all
in place -- make *sure* you install these menus on
your system! FILETAGP was *not* implemented (see
FILES section).
iii. Scan records have been changed to the new format
iv. File, message & menu systems all took some heavy
coding and need to be well tested!
v. Logging format was changed
3. Copy TELEGARD.EXE and TELEGARD.OVR over your current
executables (sorry there is no .DIF this week, but the DIFF
program blows up when there are too many changes--as in
this beta). Install __UPDATE.ZIP as usual. Update your
language files as usual.
4. Run UPDATE with the beta-02 as your option-this will update
your scan records (hopefully correctly), and adjust a few
other __NECESSARY__ datafields. The only potential
short coming is a byproduct of the all *.MSI/*.FSI storage
format--I've taken care to avoid problems, hopefully all
will work well.
NOTE: A disk cache will be helpful for this function. It
may take some time -- I can't even predict how long it will
take on any given system. On my system with 48 file areas
and 16 message areas (the test system), and 6 active users
it takes ~1 second. HOWEVER, the update must go through
every filebase and every message base once for every user.
So a disk cache will help tonnes . . .
5. Please report the space savings reported by UPDATE for both
your file section, and your message section.
6. Report any obscurities
7. If you have problems, restore your *.FSI/*.MSI files
and downgrade to 3.03.b2. Beta 3.03.b3 has substantial
changes, and while I've been running it on my local system
for almost 3 weeks now, there may be problems related to
things that I don't use, haven't tried, etc.
8. Remember to change your I##-#### ACS strings to I####, and
if you call doors by passing the USER-ID as an option,
you will need to pad the entry by using 00-~UU instead of
~UU (since the old doors will expect the leading 0's and -
which are no longer part of the userID). And no, they will
always be zeros, unless you have more than 1.6 million
users. See notes under OTHER.
TO BE DONE
1) MSGREAD and NEWUSERV menus 3.03.b03
Bonus: WFCQFILE & WFCQMSG
1a) FILETAGP menus Outstanding
2) New scan indexing 3.03.b03
2a) INDEX LIMITS RESIZE command Outstanding
3) File section update Started b01
4) Lightbar menus Outstanding
5) Script compiler Started b01
6) Script interpretter Outstanding
7) User-ID to 4 characters 3.03.b03
8) FrontDoor style logs 3.03.b03
9) Text fields to MM/DD/YYYY format Outstanding
10) Further multinode support (node-node chat?) Thinking
11) Language swapping (>64K languages) Thinking
PRIORITIES
2a) INDEX LIMITS RESIZE 3.03.b04
3) File section update 3.03.b04
1a) FILETAGP menu ?
5) Script compiler 3.03.b05
6) Script interpretter ?
4) Lightbars 3.03.b07
*) ...
LANGUAGES
+ MAKELANG upgraded to v1.15 - This version should report
duplicate text lines with both the text ID, and the first two
duplicate line #'s (if there are others, subsequent passes
will find them!). In addition, this version should report
the net space usage for the new language (i.e. does it take
up more or less space than the previous version -- and how
much!)
* See LANGUAGE.B03 for the language updates for Beta-03 (there
were lots corresponding to the new menus).
AREAS
+ The scan records are now stored in files FSCAN.DAT and
MSCAN.DAT instead of a separate file for each area. This
makes things infinitely faster in terms of file/message area
scanning (especially when many areas are not in the users
scan). It's also faster for toggling areas--and I think in
general the speed increase is a pleasant change.
The files should also be smaller than the *.FSI/*.MSI files
--instead of 3 bytes per area, per user, the algorithm now
looks something like
(round(msgareas/8) + round(fileareas/8)) * # users
plus whatever extra space you have (couple of bytes per
user), all stored in two files only. Imagine 50 file areas,
100 message areas and 300 users. The optimum space usage
under the old system compared with the new system is:
Message+File New
2048 BLK 204800 + 102400 ~10000
4096 BLK 409600 + 204800 ~10000
8192 BLK 819200 + 409600 ~16000
The new system has several disadvantages as well:
1) special routines to insert and delete from the users'
selection tables.
2) insert/delete/position can no longer be done with
other active nodes since the selection tables are
stored in memory instead of on disk for those nodes.
I have provided solutions that should work for 99.9% of the
systems and purposes with respect to these two issues.
1) my routines are in BITPLANE.PAS for modifying the
bitplanes. I haven't provided too much detail, if
you want help . . . ask.
2) see notes below
IMPORTANT NOTE (#1):
In order to ensure that nodes won't be actively reading and
misusings flags that aren't updated yet, I made it so that
the system recognizes the file TGLOCK.* in the /semaphore/
path as a lockout file. If node 1 created the lockout file,
it will be called TGLOCK.1, if node 2 created it, TGLOCK.2,
etc. If Telegard sees these lock files (either when
attempting to logon to the system, or when attempting to
enter the WFC quick-access menus), then access will be denied
and the message TGLOCK.TXT will be sent (note extension).
Telegard will delete lock files that are older than 4 hours
old -- thus, if a node for whatever reason does not remove
the lock file after it's done -- the system will detect that
after 4 hours and remove the file.
To either add (copy), delete or resposition file or message
areas the node will need to ensure the file TGLOCK.n exists.
If it does, then that node can modify the data files. If it
does not, and no other TGLOCK.* files exist, the lock file
can be created and the node can continue.
I'll put this bluntly. It is *not* elegant. Infact, it's
downright crude. But I *think* it'll work and avoid all of
the problems with this new scan format. If someone can think
of a better way of handling this, then by all means please
tell me. Other systems get around this by making the area
numbers static -- i.e. you can add areas to the end, or if
you delete an area, it stays there (you can replace it or
leave it 'deleted'). I like the simplicity of programming
that type of setup, I'm just not sure I like using it. So
please, if you have comments or suggestions, talk to me. I
don't know everything (although I admit to this being the one
problem that has held this release back--I've thought of many
things and many ways and this was the method that caused the
least problems thus far).
IMPORTANT NOTE (#2):
The UPDATE utility will give you up to 128 extra areas. If
you add that many areas in the next week or so, you will have
to wait until I can update the INDEX utility to include the
LIMITS RESIZE command, which I did not have the mind to
finish for this beta.
INFORMATION NOTE (#3):
I have decided to merge the QWK and online message area
selections for various reasons. While I realize this is not
ideal for some systems, it is ideal for most (since most use
QWK functions from TGWave, which is more functional than the
internal QWK (and faster!)--or don't use QWK at all).
*.FSI and *.MSI files can be removed once you are satisfied
with 3.03.b03 (they are in the backup you made--right?). I
don't **think** other utilities use this information
(Bluewave *might*, TGWave has an option not to-USE IT!)--if
other utilities need this information, just keep your old
*.?SI files kicking around (the information will not be
up-to-date, but I won't be writing a backwards conversion in
this case).
* Quick-access area switching now accepts a backspace to
correct any mistakes . See note below (i.e. it's all
common code now!) . . . okay, so this has nothing to do with
anything important, except that BEFORE I added the code
mentioned below, I did fix the original input prompts too. :(
+ Both the File & Message Quick-Access menus are now powered by
the menu kernel. Thus, the two new menus WFCQFILE and
WFCQMSG have been included. The menus work properly as they
are currently defined, and just use the commands which were
previously automatically called by the quick-access menus.
Other menu items & commands *might* work. The only reminder
is that commands which expect an online user fill find user
id #1 online (record 0). Since the default items on both
these menus were previously used, they are well tested--other
menu commands are not, and using them may or may not cause
system problems. You can call other menus from these menus,
but the same caveat remainds (I got lost in my main menu at
one point because there was no menu stack).
Play and enjoy -- hopefully that (a) makes things more
configurable, and (b) makes things easier on me. It
saved 3K+ of code overhead (woo-hoo). Anyone else notice the
.OVR has been slowly shrinking over the last few betas, even
though we've got more and more new features?
The menu command needed to quit these menus are any of the
hangup routines (although I'm *not* sure what else that will
cause on the system), or the new command -Z which is used to
quit from the WFC menus or to save the new user information
from the NEWUSERV menu (see later).
MESSAGES
+ Major modifications to the message areas. The changes were
to integrate the MSGREAD.MNU -- while it touches *none* of
the low-level code (i.e. message saving, message loading,
etc. is still the same), it does touch all the mid-level code
which is the reading & scanning code.
The MSGREAD.MNU has been fully integrated. It is called
wherever the old reading prompt would have been called. A
default menu has been included which closely mimics the
previous reading prompt. The commands for use on this menu
are the new R? series of commands--in addition, other menu
commands should be safe on this menu, but *please* be aware
that the more you imbed menus, the more potential problems
can occur. The only way to exit the menu is via the Ignore
Remaining or Quit commands, or by using Message Next passed
the last message. *HOWEVER*, with that said, please *safely*
experiment to your hearts desire, the new commands and the
MSGREAD menu provides a lot of power to your system.
PLEASE REPORT ANY AND ALL PROBLEMS AND ANOMOLIES YOU
ENCOUNTER!
Some side effects of all these changes:
(1) Title scanning is available in all reading modes,
including toUser/fromUser/personal/subject/text modes.
(2) Jumping around to non-scanned messages (i.e. those
which don't match the scan criteria) is now allowed in
all modes except waiting/emailscan.
(3) toUser and fromUser scans now also accept an optional
name to scan for -- (blank for users personal mail
will match either the users alias or realname). It
should be a helpful feature.
+ Message header editing was completed. It's available for all
Message SubOps or SysOps (depending on how you do the
access). NOTE: If the user does *not* meet SubOp or SysOp
access, the option will *not* come up even if the menu item
is selected (safety feature). The new option on the MSGREAD
menu is "*", and is powered by the R* menu command.
+ New toggle for message received status. The new option on
the MSGREAD menu is "$", and is powered by the R$ menu
command. NOTE: If you are the recipient of the message, the
bit will toggle OFF--however, if you re-read the message
(i.e. using "A"gain, or return to the message latter, the
received status will be set again). Once set, it is not
unset (except by this toggle).
+ New anonymous toggle: Realname or Handle, allowing the choice
at the time of posting for the user. NOTE: This method uses
the 'None' tracking mode so that ^aREALNAME and (an####) tags
are not created -- the Handle/Realname are both unique on the
originating system, and thus, it really *isn't* needed. This
toggle is even available on Netmail areas (where other
anonymous toggles are not permitted).
* Anonymous names should now work properly for Echomail &
Netmail areas (the items were previously not properly saved
for non-local areas).
* Repaired some JAM code which would sometimes lead to MBUTIL
reporting invalid JAM msg-id's (this resulted when changing
the size of the subfields, and improperly resaving the OLD
index--which while not used, would cause said warning).
* Copying/forwarding/moving a message should dynamically pack
the current area as well as the area the message was copied
to (for Squish areas only, obviously!).
* Forwarding a message should now check for write acs for the
particular message area the message is being forwarded to.
* Crossposting a message should now check for write acs for the
particular message area the message is being crossposted to.
* Forwarding/moving/copying will now (a) update the write logs,
(b) create the neccessary semaphores, and (c) write the
information to the SysOp logs.
* Deleting a message to a user will properly mark the userCRC
in the *.JDX files as zero -- this will effectively uncouple
the messages relation with the user (thus, things like the
MW;P or MW;L option will not count those deleted messages).
Undeleting a message will restore the userCRC field to the
CRC-32 of the lowercased destinee (which should restore the
original value).
NOTE: This is only useful if other JAM utilities do this --
it is how RemoteAccess handles deleting a message, so I
presume this is how it was meant to be (although, not
documented!).
* Fixed up file attaches such that the parameters passed to the
protocol use the proper format (no filename for batch
protocols, which is often why attaches via Zmodem, etc. would
report errors when used with DSZ/GSZ).
+ Message threading was added for reply chains. I don't
pretend to fully understand how the chains are linked for
messages from remote systems (some is done by MSGID, others
on subject, etc.) -- Telegard simply follows the Reply1st and
ReplyTo fields that any message has. The two new commands on
the MSGREAD menu are [,] and are powered by the menu commands
R[ and R].
[,] follow the chain -- the next regular message movement
(previous, next message, continuous, etc.) will start with
the message where you entered the thread. (i.e. reading 1648,
thread previous replies to 1245, then hit enter for next
message -- you will get 1649). The one exception is jumping
to a message #, in which case the threading is terminated and
you goto the message you requested.
* CTRL-P, T will now use /T: instead of the erroneous /C: as
the feature indicator in the line editor.
FILES
> I tried to code the FILETAGP menus, and ran into some
problems with both file tagging and file viewing, as well
as what to do while the menus are in progress -- i.e. reload
the FILETAGP menu *every* prompt (potentially slow) or just
use the menu in memory (potentially dangerous). Since many
of these problems are associated with the way I coded the
reentrant file_engine routines, I'm going to have to rethink
my strategy for this particular menu. I *think* the coding
changes I make to finish the file section changes will make
it easier to implement, and thus I've deferred the FILETAGP
menu implementation until I've completed those other changes.
* I recoded some of the core file section routines to improve
on overall system speed -- the following items have been
affected by these changes:
(1) All *.FA/*.FAD files are kept open while the user is
actively listing files. The files are only closed
when neccessary -- this reduces file open/close time
(which makes the system feel *real* sluggish). I
don't think it'll cause problems unless files are
deleted while the file is open -- to prevent this,
packing utilities must be able to open the file in
fmReadWrite+fmDenyAll mode -- if they can not (the
file is presently open), then the utility must wait
before deleting the file.
(2) Upload queues are no longer used. Uploading will
start the protocols immediately, after the upload,
the file_id.diz will be checked, and if missing a
description prompted for. No filenames or
descriptions will be entered before the transfer
starts. Bidirectional uploads use the file area
precedence of current -> UploadArea -> SysOpULArea
(latter both as setup in SystemConfig.FileSection).
The only exception to this rule is single file
transfer protocols, which require a filename before
transfer -- these will be input as required.
(3) Download queue was resized to 50 files. This should
be more adequate with today's transfer speeds (it's
2 1/2 times the previous limit).
Because of this recoding, I'm very interested in certain
things-- (a) is the file system noticably faster? (b) what
run-time errors are occuring -- and especially, are the file
tagging run-time errors still occuring? I was *never* able
to replicate these on my system!
* The validate files maintenance option is now powered by the
same update engine as most of the other maintenance items.
Please let me know of any problems.
* 'Next Area' should now work properly -- i.e. it will skip the
rest of the file being displayed and will avoid any further
pausing for the skipped area. The big problem was when the
'Pause After List' option was enabled (Next Area was not
cancelling this forced pausing prompt -- it does now!)
* Offline files will no longer receive a duplicate file tagging
number (offline files should receive NO file tagging number
at all).
* GraphicSpecification importation should now work again- when
I was optimizating a section of code, I accidentally caused
it to never run (some optimization technique!).
* Graphic Specification (GifSpec=NNNxNNN,NNNc,type) is now
represented as (xSpec=NNNxNNN,NNNc,type) instead.
DOORS
* The DOOR.SYS file (Menu DG) has been updated to reflect the
*correct* format of the DOOR.SYS file created by GAP. This
means that the REAL NAME of the user is *always* sent instead
of the realname/alias toggle we previously used, and in
addition, the handle is sent later in the DOOR.SYS file.
If you use doors which use the DOOR.SYS and also keep user
information, the new format will cause those doors not to
recognize the users as active players/etc. If this is the
case you have two options--update the 'player name' id
entries in your DOOR.SYS to use the real name instead of the
handle, or use the OLDDOORS.SCR file to create an old
DOOR.SYS compatible drop file. I honestly suggest a slow
progression to the new, and proper, drop file format.
SysOps who use R; (real name force) in their DOOR.SYS drop
file commands should have no problems--the file is of
compatible format.
* A proper DOORFILE.SCR was included which has the new REAL
NAME line for the DOORFILE.SR generation. This is used for
duplicate checking for the Solar Realm games, and certain
somebodies may not like if you put this new script in . . .
(infact, I'm honestly not sure what effect it will have).
OTHER
* Major overhaul to the internal menu routines -- this was done
not only for optimization purposes, but also to support the
many new & specialized menus that I'm going to be introducing
over the next little while -- the first of which is outlined
in the MESSAGES section, and the second is outlined below.
The main menu handler was *heavily* modified to make room for
these changes -- this is the core of the entire BBS, so test
it very well!!
Please let me know if you have problems with *any* of your
menus. If they're new problems that didn't previously exist,
send me the .MNU file so I can check it out . . .
+ The New User Information Verification code is now handled via
a menu called NEWUSERV.MNU. This menu just makes calls to
the OP menu commands to update the user information. A new
menu command, -Z, will exit from this menu loop, save the
user information and continue with the new user process (dupe
phone # checks, etc...). Several things should be noted:
* The OP menu commands operate in 'NewUser' mode -- i.e.
the same as the old methods. Thus, if you toggle items
ON/OFF via SystemConfig.NewUser, then those items will
work as expected (off, forced value, etc). This works
for all OP commands 1-25, & 80. Thus, if you disable
the date of birth field, even if you call OP 9 the
date of birth will not be prompted for.
* Menu changes, sub menus, etc. should work just *fine*.
Just remember that the user has *not* been saved yet,
and calls to other menu functions that expect the user
has been saved may, or may not, work. This is most esp.
--- PCBoard (R) v15.3/M 10
* Origin: (1:226/600)SEEN-BY: 633/267 270 5030/786 @PATH: 226/600 379/1 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.