informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido1343.nws

1978 lines
92 KiB
Plaintext
Raw Normal View History

Initial commit
2021-04-15 13:31:59 -05:00
F I D O N E W S -- Volume 13, Number 43 21 October 1996
+----------------------------+-----------------------------------------+
| The newsletter of the | ISSN 1198-4589 Published by: |
| FidoNet community | "FidoNews" |
| _ | 1-904-409-7040 [1:1/23] |
| / \ | |
| /|oo \ | |
| (_| /_) | |
| _`@/_ \ _ | |
| | | \ \\ | Editor: |
| | (*) | \ )) | Christopher Baker 1:18/14 |
| |__U__| / \// | |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+-----------------------------------------+
| Submission address: FidoNews Editor 1:1/23 |
+----------------------------------------------------------------------+
| MORE addresses: |
| |
| submissions=> cbaker84@digital.net |
+----------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies of FidoNews or the internet gateway FAQ |
| please refer to the end of this file. |
+----------------------------------------------------------------------+
REPEAT AFTER ME: "FIDONET IS A HOBBY."
Table of Contents
1. EDITORIAL ................................................ 1
FidoNet dead ends? ....................................... 1
2. ARTICLES ................................................. 3
Response to Bob Moravsik ................................. 3
A Short *.MSG Programming Tutorial [I] ................... 4
3. REVIEWS .................................................. 11
Digital Engineering's K-384 ISDN Network Simulator ....... 11
4. COORDINATORS CORNER ...................................... 16
Nodelist-statistics as seen from Zone-2 for day 292 ...... 16
5. WE GET EMAIL ............................................. 17
Region 13 fun and games .................................. 17
Nodelist problem revisited ............................... 17
6. NET HUMOR ................................................ 20
Some New Telephone Options ............................... 20
May the Geeks be with you? ............................... 21
7. COMIX IN ASCII ........................................... 24
What price glory? ........................................ 24
8. QUESTION OF THE WEEK ..................................... 25
Who uses speech synthesizers in FidoNet? ................. 25
9. NOTICES .................................................. 26
Future History ........................................... 26
10. FIDONET SOFTWARE LISTING ................................ 27
Latest Greatest Software Versions ........................ 27
11. FIDONEWS PUBLIC-KEY ..................................... 34
And more!
FIDONEWS 13-43 Page 1 21 Oct 1996
=================================================================
EDITORIAL
=================================================================
When FidoNet began under the sole aegis of the Fido mailer program
invented by Tom Jennings, things were primitive and simple. So, too,
were the issues [or lack thereof] concerning daily FidoNet ops or
FidoNet structure and modus.
Fido, the program, came to a dead end when Tom Jennings stopped
working on it. By then, there was Opus and SEAdog and BinkleyTerm and
FrontDoor and D'Bridge, to name a few, to make what was once just
simple, unattended file transfers into the Hydra of today's FidoNet
environment. Fido is still operated by a few hardy souls out there
but it dead-ended, development-wise, for lack of interest in making
it more complicated. Opus, SEAdog, and D'Bridge all dead-ended but
are still in use because of our FidoNet standards.
Now, we have routing systems and Echomail structures and CRPs and
BBS interfaces and Internet links that make everything seem more
complicated. But is it really more complicated or are a lot of folks
just confused about what FidoNet is and does at the basic level?
FidoNet is defined by a few published standards and its weekly
Nodelist. Its glue is this weekly document. None of these things are
inherently complicated when boiled down for their oil. FidoNet exists:
1. at the will of its inventor and trademark holder, Tom Jennings;
2. for the express purpose of providing a lowest common denominator
means of telecommunicating with a minimum of hardware and software;
3. as an amateur hobby between consenting practitioners.
The standards are maintained by an internal group known as the FidoNet
Technical Standards Committee [FTSC]. This group operates under direct
license from the trademark holder, Tom Jennings. Only Tom Jennings can
cause the FTSC to change structure or responsibility.
The FTSC does NOT create standards nor does it impose standards. The
FTSC documents existing standards as they become de facto operational
practices for the majority of FidoNet participants and/or software
developers. This is something many folks don't understand or never
knew. The FTSC collects, documents, and publishes standards and
proposals. It is up the Coordinator structure to enforce those
standards. It is up to the developers to get their proposals into
wide acceptance and usage before they become standards. Proposals
[also known as FSCs] ARE NOT standards. Their implementation is
strictly voluntary. They become standards only when they become
indispensable to FidoNet ops.
There is discussion in several Echos and in these pages about whether
the FTSC as currently configured is a dead-end. Is FidoNet going
anywhere from here? Does it need to go somewhere from here? What does
it take to go somewhere else? Who will be driving this bus to
somewhere else?
I invite all the principals to take this discussion to future Issues
FIDONEWS 13-43 Page 2 21 Oct 1996
of FidoNews so all of us can better understand the dynamics and the
expectations of getting FidoNet where it needs to be.
=======
On a separate note, I got a message from Debra Turner in the FIDONEWS
Echo asking if a text description could be included with the comix in
our ASCII art section so folks using speech synthesizers to peruse
FidoNews each week could get something out of that visual area. The
answer was: absolutely! I apologize for not thinking of it. Today's
comix contain such a description and all subsequent offerings in that
section will be likewise annotated for the speech program group.
Speaking of the FIDONEWS Echo, another question came in about how to
format a message for FidoNews submission. Specifically, he wanted to
know where the filename specification went in a message to identify
where the content should go in FidoNews. The answer is: format the
submission text in the body of the message as closely as possible to
the ARTSPEC.DOC requirements, i.e. 70 columns, no high ASCII, etc.
To define what type of submission it is, put the filename as the
subject line, e.g. Subj: THISISA.JOK. All message submissions are
manually processed by your Editor to meet the physical requirements
of MAKENEWS. Including the apparent filename in the Subj: line makes
it easier for me to determine where you wish your submission to
appear. If none is included, I guess by the content and give the
output file an appropriate filename for processing.
The FIDONEWS Echo is open to all interested in FidoNews subjects and
operations and is available via your regular Zone 1 Backbone Echo
links. It is more real-time than FidoNews if you have a question.
*******
As for the moving saga, who cares? I'm still not completely moved in
but all the hitches have been standard [late movers, phone company
foul-ups, utility headaches, etc.] so I'm sure no one cares to have me
rehash it here. [grin]
ASCII art and net/computer related humor is slowly starting to trickle
in from new authors. That's great! Please keep it coming.
Enough for now. I got a late start today by attending the simultaneous
birthdays of my daughter and brother [same day, different years,
similar names {Eric and Erica}] back down in Titusville from whence I
fled three weeks ago.
Enjoy!
C.B.
-----------------------------------------------------------------
FIDONEWS 13-43 Page 3 21 Oct 1996
=================================================================
ARTICLES
=================================================================
More EP2 nonsense
By Lee Kindness, 2:259/7, lkindnes@csl.co.uk
BM> As to the practical aspect of a Zone policy why
BM> don't each of you read Section one of Policy
BM> 4.07. Local policies MUST meet certain tests.
BM> One important one is that they are REQUIRED
BM> by local conditions. Not desired, wanted,
BM> needed etc...but REQUIRED.
Please, zone 2 policy is the business of zone 2 - not a zone 1 sysop.
If anything EP2 will be a 'shell' of a policy, allowing policies
to complement it at a regional level. I'm sure you agree regional
policies make good common sense in zone 2, each region has it's own
language for a start.
Don't base you views on the policy Steve posted to FidoNews. That was
a very early 'hash' and has been long abandoned.
BM> Let me poise these questions:
Well I'll answer them for a zone 2 sysop point of view, nothing
else... (As i try to figure out what other possible view point i
have...)
BM> 1. If the people that "vote" against a Z2 EP ignore
BM> it ...then what ?
Depends if the policy is ratified as per EP1. If it is adopted
then all nodes will be subject to it. I mean just because i don't
like P4 doesn't mean i can ignore it.
BM> 2. If those people put in another Z2ep is it anymore
BM> enforceable then Woodmorepol.
Bet you're glad I'm not Z2EC, Kindnesspol doesn't have such a
harsh and evil sound ;)
If it is:
1. Submitted before Steve's and ratified as per EP1
2. Ratified as per replacement conditions is EP2
Then sure.
BM> Section one of the existing ratified policy contains
BM> wisdom. Since message flow all over the world and
BM> since any node can link to any other node via any
BM> way...how do you expect to enforce a policy that
BM> is limited by geography..as to a technology that
BM> ISN'T.
FIDONEWS 13-43 Page 4 21 Oct 1996
A zone 2 EP would apply to ZONE 2 ECHOES!!! Understand!!!
BM> Look at the foolishness in Z1. First there was
BM> an echopol attempt. It spent more time on distribution
BM> then on policy. It bombed. Then we had "boppy". The
My view is EP should focus more on distribution and technical
issues rather than 'political' stuff. I mean what is the point of
all the garbage about removing a moderator if it cannot be enforced?
BM> OK WHAT IS THE SOLUTION:
BM> So...Mr. Kindness and Mr. Woodmore. Instead of brushing
BM> off an article with childish comments. Address the
Good, i said last week - why not fix into ECHOPOL2 and make your views
count instead of taking cheap shots in FidoNews...
ECHOPOL2 was originally for the discussion of a zone 2 specific
echopolicy (and that's still its main aim) but with the Z1EC's
interest we might well end up with a global (well z1 + z2)
policy.
I think we have a broadly similar viewpoint (ie minimum politics
in Fidonet) but the difference is you're out in the cold shouting
where no one will take notice, if anything promoting Steve. In
one of your previous messages you said something about 'zone 2
flexing it's geographical muscles' - the general consensus in
ENET.SYSOP, 'about bloody time'...
Sleep well, and never mind the purple crocus juice.
-----------------------------------------------------------------
A Short *.MSG Programming Tutorial [I]
Damian Walker, 2:2502/666
One question which pops up occasionally in programming and technical
echoes is how to read and/or write netmail messages. This is one of
the principal methods of communication in Fidonet, and so it seems a
logical place to start when applying your programming skills to
Fidonet for the first time.
In this tutorial series, I hope to introduce those with moderate
programming capabilities to the world of Fidonet netmail programming,
using the *.MSG format (as defined in FTS-1) and the C programming
language.
Such knowledge could be used for a variety of purposes; you could
write a simple netmail robot or other netmail utility. A while ago,
someone even wrote a netmail MUD! In this series I'm not going to be
nearly as ambitious; a simple netmail directory list utility will
suffice for our examples.
As the series goes on you will see some C source code published.
This source code is in the public domain. Feel free to use it for
whatever purpose you wish, whether for commercial, personal or
educational purposes. Even Microsoft may use it :-)
FIDONEWS 13-43 Page 5 21 Oct 1996
The series is split up as follows:
Part [I]
Disclaimer
Introduction to the Message Format
Reading *.MSG files from the netmail directory
Finding *.MSG files in the netmail directory
Part [II]
A More Robust Routine to Read Messages
Displaying the body of messages
Using Other Header Fields
Part [III]
Writing *.MSG files
Final Message Lister
Conclusion
Disclaimer
Although I will take every precaution to ensure that the
information in this tutorial is correct, the occasional typo or plain
stupid mistake might creep in.
In the event of mangled netmail directories, reformatted hard
disks, or excessive frustration (with accompanying hair loss)
resulting from use or misuse of this information, I take absolutely no
responsibility.
Introduction to the *.MSG Message Format
The *.MSG message format is often used for netmail areas,
principally by those operating FrontDoor-style mailers for their node
or point. Users of BinkleyTerm-style mailers often have the option of
using a *.MSG area for netmail, if their mail processor supports it.
The format is defined in the document FTS-1, available from a
large number of sources. Your local friendly FTSC member should have
it, and any nearby node could also have it. Failing that, check the
Internet sites http://www.fidonet.org or ftp://ftp.fidonet.org, or as
a last resort, FReq FTS-0001.ARJ from my system (FReq's are welcome,
but it may be an international call for you).
Here is a quick run-down. In the *.MSG format, each message
occupies a single file, the filename being the message number plus the
extension '.MSG' (hence the *.MSG name). Each MSG file contains a
single header followed by the message text, and 1 ASCII NUL character.
The header is as follows:
fromusername char/36 Sender's name
tousername char/36 Recipient's name
subject char/72 Subject line
datetime char/20 Date/time stamp
timesread int/2 Times read
destnode int/2 Recipient's node number
orignode int/2 Sender's node number
cost int/2 Cost word
orignet int/2 Sender's net number
destnet int/2 Recipient's net number
destzone int/2 Recipient's zone number
origzone int/2 Sender's zone number
FIDONEWS 13-43 Page 6 21 Oct 1996
destpoint int/2 Recipient's point number
origpoint int/2 Sender's point number
replyto int/2 Reply linking information
attribute int/2 Attribute word
nextreply int/2 Next reply to this message
Early software implementations lack the zone and point information
from the header, and some modern implentations have it but don't use
it. For the purpose of this tutorial the full structure will be used,
including zone and point numbers, and technicalities of extracting
zone and point information from messages which don't use this header
information will be dealt with later.
The message text, as defined by FTS-1, doesn't have any limit on
size. It must be terminated by an ASCII NUL character (0); some
software doesn't do this so we'll have to find out how to deal with
messages from such software later on.
One aspect of Fidonet messages which impresses me is the fact
that lines are reformatted in real time by your editor. A good
message editor should produce messages in which a whole paragraph
occupies one line; these paragraphs can be reformatted to suit the
reader's screen, no matter what font, screen or window size is being
used. This is by far preferable to the clumsy reformatting codes used
by some other systems.
Paragraphs (or lines in a table) should be terminated by a single
carriage return (13) character, rather than a line feed or CR/LF pair.
This standard is not always observed by message editors, especially
those which use a standard external text editor to input the message
text-- these message editors often leave the line end markers as they
are produced by the text editor.
The message text contains kludge lines. Although most readers
will be familiar with kludge lines, I'll give a brief explanation here
for completeness' sake. Kludge lines are lines in the message text
beginning with the ASCII character 1 (^A, often shown as a smiley face
on MSDOS screens). Most, if not all, message readers filter these
lines out of the message display; you won't see them.
These lines server a number of purposes. The FMPT and TOPT
kludges offer point addressing information for messages in which the
point header information is not used. The INTL kludge provides a
similar facility for the zone information, showing both source and
destination zone addresses. The MSGID kludge serves to identify a
message explicitly.
There are some other kludge lines in use, ranging from the vaguely
useful to the downright silly. We need not consider them here. Now
for the message header in C.
/* FTS-1 message structure */
struct fts1 {
char fromusername[36],
tousername[36],
subject[72],
datetime[20];
int timesread,
destnode,
orignode,
cost,
orignet,
FIDONEWS 13-43 Page 7 21 Oct 1996
destnet,
destzone,
origzone,
destpoint,
origpoint,
replyto,
attribute,
nextreply;
};
If you're using a 32-bit compiler such as DJGPP then you'll have to
change 'int' to 'short' as all these fields are 16-bit integers. There
is a more portable way of ensuring that the correct size of integers
is used no matter what the compiler, involving pairs of 'char'
variables, but for this tutorial I'll keep things simple. For the
purposes of later examples, save this definition in a file called
"fidomsg.h"; I'll refer to it later.
Reading *.MSG files from the Netmail Directory
Reading a netmail message is, in theory, a simple task. If the
message is fully compliant with the specification, you just open the
file, read the message header, read the message text, and close the
file. A simple function to do that would look like this:
void readmsg(struct fts1 *msg, char *text, int limit,
char *filename)
{
FILE *msgfile; /* message file handle info */
msgfile = fopen(filename, "rb");
fread(msg, sizeof(struct fts1), 1, msgfile);
fread(text, 1, limit, msgfile);
fclose(msgfile);
}
Note that there is no error checking in this function at all; a more
robust function will come later. Note also that the size of the
message is limited; a more complex algorithm would be needed to read
files larger than the maximum buffer you could allocate. This
function would be called as in the following example:
#include <stdio.h>
#include "fidomsg.h"
#define MAXMSGSIZE 2048
/* include the readmsg() function here */
void main(void)
{
struct fts1 msg;
char text[MAXMSGSIZE];
readmsg(&msg, text, MAXMSGSIZE, "\\fd\\mail\\1.MSG");
printf("From: %s (%d/%d)\n", msg.fromusername, msg.orignet,
FIDONEWS 13-43 Page 8 21 Oct 1996
msg.orignode);
}
This program defines the macro MAXMSGSIZE as 2048, meaning that the
program can deal with messages up to 2k in length. Real applications
would probably need to use a bigger buffer, or a more complex
algorithm for reading large messages as described earlier.
The program also assumes that the first message in the directory
will be 1.MSG, so you'll have to make sure that this is in fact the
case. Alternatively you can modify the program to load another
message, or to be more useful, allow a message number or file to be
specified on the command line, like this:
...
void main(int argc, char *argv[])
...
readmsg(&msg, text, MAXMSGSIZE, argv[1]);
...
To make the program more robust you'd have to include some error
checking to make sure that there is at least one parameter used on the
command line, but we're drawing away from the main point of the
article so I'll leave you to figure that one out.
Finding *.MSG Files in the Netmail Directory
So far we have a program which will display a few details from a
single netmail message, as long as the message is 1.MSG or, assuming
you've experimented with the suggested modifications, as long as we
know the filename of the message.
This is a bit useless for our ultimate objective for this
article-- to list details of messages in the netmail directory. In
this task we don't know the message numbers beforehand, and of course,
we want to list more than a single message. In solving this task we
need to obtain a directory listing, and thus we must depart for a
moment from ANSI standard C; the standard libraries contain no
functions to perform this platform-specific task.
For our purposes I have chosen to use the widespread functions
findfirst() and findnext() defined in the file <dir.h>. These are
present in many DOS and UNIX dialects of C, and other dialects may
have direct equivalents (such as _dos_findfirst() and
_dos_findnext()). A cumbersome way to avoid using these is described
later; it needs a more robust message reading routine before we
attempt to implement it.
The function findfirst() takes three parameters-- a character
array containing a wildcard, a pointer to a structure containing the
file search information, and an attribute for the search. The
findnext() function takes only one parameter-- the pointer to the
structure used in findfirst(). How would we use these functions to
get a list of messages in the netmail directory? Take a look at the
following example code:
#include <stdio.h>
#include <dir.h>
void main(void)
FIDONEWS 13-43 Page 9 21 Oct 1996
{
struct ffblk f;
int done;
done = findfirst("\\fd\\mail\\*.msg", &f, FA_ARCH);
while(!done)
{
printf("Found: %s\n", f.ff_name);
done = findnext(&f);
}
}
The line containing the call to findfirst() sets up the file search
parameters-- *.msg files in the \FD\MAIL\ directory, including files
with the archive bit set (FA_ARCH). The ff_name member of the f
variable (see the printf() line) is a simple filename without a path.
The findnext() line just searches for the next occurrence of the file.
As you can see, this program will print out the names of the MSG
files, but it will not reference their contents. So the program is a
little useless, although it could be used to verify the existence of
1.MSG for the earlier example! To make the program more useful, it
would have to be combined with earlier examples:
#include <stdio.h>
#include <dir.h>
#include "fidomsg.h"
#define MAXMSGSIZE 2048
/* include the readmsg() function here */
void main(void)
{
struct fts1 msg;
struct ffblk f;
char text[MAXMSGSIZE], directory[128], wildcard[128],
msgname[128];
int done;
/* initialise directory and wilcard */
strcpy(directory, "\\fd\\mail\\");
sprintf(wildcard, "%s*.msg", directory);
/* main list output section */
done = findfirst(wildcard, &f, FA_ARCH);
while(!done)
{
sprintf(msgname, "%s%s", directory, f.ff_name);
readmsg(&msg, text, MAXMSGSIZE, msgname);
printf("%-12s From: %s (%d/%d)\n", f.ff_name,
msg.fromusername, msg.orignet, msg.orignode);
done = findnext(&f);
}
}
Notice here that I've created separate variables for directory,
FIDONEWS 13-43 Page 10 21 Oct 1996
wildcard and individual message filename. 'Wildcard' is needed to
pass to findfirst(), 'directory' is needed in two places: in the
creation of 'wildcard' and in the creation of 'msgfile', and 'msgfile'
is needed to pass to readmsg(), which expects a full filename.
Since the directory is a constant in these examples, the directory
name could be included in literal strings, but I've purposely left the
variable in there so that you can easily modify the program to obtain
it by other means-- from the command line or a configuration file,
perhaps.
As you can see, this is the full program promised at the start of
this tutorial, which lists details of messages in a netmail directory.
But the tutorial is far from over, as we haven't considered extracting
node and point information from the messages. This will be the
subject on which next week's article starts.
-----------------------------------------------------------------
FIDONEWS 13-43 Page 11 21 Oct 1996
=================================================================
REVIEWS
=================================================================
Digital Engineering's K-384 ISDN Network Simulator
Fredric L. Rice (frice@stbbs.com)
The Skeptic Tank 1:218/890.0 (818) 335-9601
Lately I've been evaluating the K-384 ISDN Network Simulator
from Digital Engineering in Ireland and thought that there
might be some netters who would be interested in this box.
It's mostly intended for the manufacturer of ISDN equipment
rather than the end user or the digital hacker yet the fact
that the puppy will provide three ISDN interfaces and six
64K Bps data connections also makes this a pretty good kind
of V.110 synchronous Terminal Adapter.
The K-384 is an ISDN network simulator, a Terminal Adapter,
and a protocol analyzer, granting the user insights into all
of the intimate details of the ISDN protocol stack: I.430,
Q.921, Q.931, and all anybody really needs of Q.932. Since
there are three ISDN interfaces on this box there can be up
to six 64K Bps calls up at any one time, pumping data to
and from the six data connections on the back panel.
It's not a real Terminal Adapter, however, and it doesn't
offer asynchronous data out the back panel. If it did then
I could ask GTE to bring in three ISDN lines and I could
run up to six 57,600 baud connections at any one time or, if
Digital Engineering elected to employ the BONDING protocol
rather than just V.110 and V.120, I could have up to three
115,200 baud connections up at any one time.
I'm going to ask Digital Engineering to think about putting
these things into their K-384 because doing so would allow
ISDN equipment manufacturers to test every aspect of their
devices fully.
The box itself has some good points and some bad points:
1) It's easy to use with near plug-and-playability.
The menus are simple to use and the analyzer offers
all the information about Layers 1, 2, and 3 that are
needed. Clearing the analyzer buffer is quick and
easy. Redisplaying the whole buffer upon exiting the
analyzer and re-entering it is a nice feature as well.
There is an LED which displays whether or not we have
Layer 1 and another LED which shows us if we have
established Layer 2. The ability to see easily if we
have Layer 2 established is kind of nice.
2) The K-384 runs cool and silent. The power supply that
I have in my sample box some times puts out a very
FIDONEWS 13-43 Page 12 21 Oct 1996
quiet high frequency whine which at times can be heard
(other people don't seem able to hear it at all.)
3) It doesn't appear to support Low-Power Mode / Warm Start
Mode. I could just be doing something wrong, of course.
There is the facility for tearing down Layer 3, Layer 2,
and Layer 1 after a duration of inactivity yet I haven't
been able to get it to successfully go into the deactive
Warm Start state.
4) It's got bugs. Some bugs are fatal and some are not.
a) Unexpected removal of the U-Interface will often cause
the K-384 to crash, requiring power-cycle. Some times
when the cable is quickly disconnected and reconnected,
the K-384 will buzz, all the B1 and B2 lights will
flicker, and then the K-384 will restart; configuration
will be lost.
b) Calling a B channel which has no physical device
plugged into it will illuminate the B channel's LED then
the K-384 will properly return a RELEASE COMPLETE yet
leave the LED illuminated. I noticed that this problem
seems to only exist on Port 2.
c) At power-up, there are times when I continue to send
ID_REQUESTs to the K-384 and the K-384 will ignore
them. Shifting the cable to the other U-Interface
connector on the K-384 fixes the problem. For example,
there are times when I talk into Port 3 of the K-384
and send dozens of ID_REQUESTs to the K-384 which will
ignores them. Moving the cable from Port 3 to Port 2
makes the device perform a Layer 1 LinkUp thereafter
the K-384 responds properly to the ID_REQUEST on Port
2. Swapping the cable back to Port 3 fixes the problem
on Port 3 since it will start to respond to the
ID_REQUESTs.
e) The "Analyzer Setup" menu contains a date/time stamp
that is constantly updated. It messes up the screen.
While in the "Analyzer Setup" menu, using the arrow keys
to traverse the menu causes the date/time stamp that's
constantly being displayed to be written over the wrong
line on the display. Though it's a minor glitch, I
tried all the different terminal emulations Procomm Plus
has and the ANSI emulators all exhibited the same
glitch.
f) Output from the K384 will send both CR/LF pairs as
well as isolated CRs. This is sloppy... very sloppy.
For example, we'll see 0D 0A 0D 0D 0A 0D in the
following. Text which follows a 0D can over-write the
previous line when the log file is sent to the printer.
FIDONEWS 13-43 Page 13 21 Oct 1996
0D 20 20 20 20 20 20 20-20 20 20 53 41 50 49 3D
. SAPI=
20 30 2C 20 54 45 49 3D-20 34 30 2C 20 43 2F 52
0, TEI= 40, C/R
3D 20 30 2C 20 50 2F 46-3D 20 30 2C 20 54 59 50
= 0, P/F= 0, TYP
45 3D 20 49 4E 46 4F 0D-0A 0D 20 20 20 20 20 20
E= INFO...
20 20 20 20 4E 28 72 29-3D 20 38 2C 20 4E 28 73
N(r)= 8, N(s
29 3D 20 37 0D 0A 0D 0D-0A 0D 20 20 20 36 31 20
)= 7...... 61
3A 20 54 45 20 43 68 20-20 33 20 4C 33 20 20 20
: TE Ch 3 L3
So there are some software issues that Digital Engineering
needs to work out of their K-384 before I would buy it. I
pulled the cover off their box to check the manufacturing
side of things and noticed that the box I'm using has version
"V1.2 LX," whatever that is.
As for the mechanics and the workmanship of the box there
are also some good things and bad things.
First off it took 14 sheet-metal screws to remove the top
lid. This is damned good because it gives the construction
of the box a great deal of strength. Because the lid rests
upon a metal strip along the front and is tied together
with 14 screws, I don't have any moral compunctions against
stacking heavy equipment on top of it. I would probably
keep the power-supply air vents uncovered, of course.
The metal strip along the front that the top lid rests upon
has a black plastic strip along its entire length giving it
a good, solid vibration killer. There's no metal-to-metal
interface tending to grind together when installed in a
test environment.
Lifting the lid off the first thing I noticed was the modular
design. If I want any combination of U-Interfaces and
S/T-Interfaced, all that Digital Engineering has to do is
pop in a small module onto their primary board and then ship
it to me. If I want to change the configuration of the
hardware interfaces in the field, all I need to do is pull
out one screw, unplug the module, and plug the new one in.
Whoever designed this piece of the product did a damn good
job. The through-hole on the screw is oblate allowing for a
good degree of travel side to side if the machining of the
container is not exactly the same every time. In so many
other products I've looked inside of there is usually only
a single screw hole -- circular -- and if the jack on a panel
doesn't exactly match-up with the cover plate, something must
be bent to make it line up. This design is superior in that
the screw hole travels until there is a mechanical alignment
and then the screw is tightened down; no bending required.
FIDONEWS 13-43 Page 14 21 Oct 1996
They're using the Mitel MT8910AC for the U-Interface and the
Mitel MT8930BE for the S/T-Interface, I noticed. I would
prefer that they had used Motorola's U-Interfaces simply
because I'm biased in favor of Motorola products but these
Mitel products are solid and reliable. All the other digital
components are manufactured in Malaysia.
The power supply is also a good design. I can't tell if
Digital Engineering buys this power supply from someone else
and installs it in their K-384 or whether they go ahead and
manufacturer it in-house. No, I unsoldered some components
next to its transformer and see that the power supply was
manufactured in Japan. 'Makes good financial sense.
Another thing I noticed while looking for who made the power
supply was the fact that there is a space for the main board's
serial number but that it's blank. There is a serial number
on the outside on a sticker but I wonder how Digital
Engineering tracks boards if they don't put serial numbers on
them. The sticker is easily removed so I could easily cheat
on my warranty, I think.
Bar far the worse thing about the workmanship is the
outrageous number of through-holes and component pins that
simply don't have enough solder in them or, in many of the
components toward the front of the box, just don't have _any_
solder in them at all. This may be the cause of some of the
unexplainable crashes I've been experiencing. It looks like
the wave-solder process just did a bad job. Every hole should
be filled entirely and every pin should be soldered down, of
course.
Just stepping through traces and pins and such with a
continuity tester shows me that all of the pins that are not
soldered onto the board nonetheless have connectivity but
with a little probe tip pressure I can make some of the pins
break contact with their etches. If I were sitting on a work
bench with hardware grunts working on it, I could expect to
have some of these pins fail. I'm guessing that because the
unsoldered pins normally have continuity with their etches,
it's why this particular box managed to make it through their
quality control.
The only other poorly done workmanship about this particular
box is the front-end components driving the data ports on the
back panel. It looks like there might have been some
component failures and so new components were manually placed
on the board to replace them. The surface mounted components
are in okay and everything works yet there are tiny peaks of
solder on most of the manually-soldered pins. It's not the
smooth slope that I'm used to seeing.
The only other thing worth mentioning is the manual. In a
word, it isn't. A manual, I mean. It's more like a reference
book for some of the major aspects of the device. There is a
PCMCIA interface and a PCMCIA ROM/FLASH card which came with
FIDONEWS 13-43 Page 15 21 Oct 1996
my K-384 which I have no idea what to do with it. The PCMCIA
connector is a good one -- it has an ejector lever and it's
firmly mounted -- no play; doesn't wiggle like so many other
PCMCIA designs I've seen. But the manual doesn't give me any
clues.
The AT commands, come to think of it, aren't enough for me
to utterly control the box remotely. I would also ask Digital
Engineering to give me more control over configuration and
control through the AT command set. I would think about
writing a Windows GUI interface for the K-384 eventually but
as it stands now, I don't have enough remote control hooks
to get inside the box's brain.
My overall summation of the Digital Engineering K-384 Network
Simulator is that I would like to personally own a couple. I
like the box. I wouldn't even mind actually paying for them
if I were doing ISDN related hardware or software development.
Before I would spend my own personal money on one, though, I
would require them to solve their software problems and their
solder-wave process problems first. If they did that I would
also ask that they employ the V.120 Rate Adaptation Protocol
so that I could do asynchronous out the back and _really_ test
all of my hardware and software designs. Then I would expect
a proper manual. After that then I could run six high-speed
links to The Skeptic Tank -- some to my Unix box and some
to the DOS box.
This company, by the way, has been most helpful in answering
my questions. Even though I asked some difficult technical
questions they managed to locate someone with the background
and knowledge to answer my questions.
I have no idea what my company pays for these boxes. Being a
software dink I don't have to worry about such things. It's
great just being able to ask for equipment and not give a damn
about the cost. Someone said that the cost was around $5,000
but he wasn't sure. There is also a 16-interface version of
this Network Simulator which I'm going to ask for eventually.
Before I would put 16 ISDN lines into my house, though, I
would just as soon have GTE bring in a T1 / E1 span and be
done with it. Ascend in Alameda, California, would probably
be my T1 equipment supplier of choice.
Digital Engineering Ltd. Unit #5
Antrim Line Business Park
Sentry Lane, Mallusk
Belfast BT36 8XX, Ireland.
Telephone: 0232 840004
FAX: 0232 838164
-----------------------------------------------------------------
FIDONEWS 13-43 Page 16 21 Oct 1996
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 292
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-264|Nodelist-271|Nodelist-278|Nodelist-285|Nodelist-292|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 11810|11826 16 |11826 0 |11666 -160 |11666 0 |38|
| 2 | 16392|16406 14 |16394 -12 |16341 -53 |16356 15 |53|
| 3 | 954| 954 0 | 951 -3 | 950 -1 | 956 6 | 3|
| 4 | 629| 629 0 | 629 0 | 610 -19 | 620 10 | 2|
| 5 | 100| 100 0 | 100 0 | 97 -3 | 97 0 | 0|
| 6 | 1020| 1020 0 | 1020 0 | 1022 2 | 1020 -2 | 3|
+----+------+------------+------------+------------+------------+--+
| 30905|30935 30 |30920 -15 |30686 -234 |30715 29 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 13-43 Page 17 21 Oct 1996
=================================================================
WE GET EMAIL
=================================================================
--- Following message extracted from NETMAIL @ 1:374/14 ---
By Christopher Baker on Thu Oct 17 19:22:38 1996
From: Joe Klemmer @ 1:109/370
To: Editor @ 1:1/23
Date: 15 Oct 96 22:16:33
Subj: Article Submission
Region 13 fun and games
By Joe Klemmer - 1:109/370
klemmerj@webtrek.com
This will be short and to the point -
The RC screwed up by not renewing the Elistings for the R13 echos.
Bob Moravsik then did what is perfectly proper by Elisting the echos
himself.
The REC then created new R13 echos to supersede the old ones. Again,
a perfectly proper thing to do.
Final outcome: The old echos are no longer part of the R13 regional
distribution and can be whatever the moderator wants them to be.
They are not "official" (whatever that is) R13 echos so whatever
happens in them means nothing to the region.
See? As I said, short and simple. Phil Dampier screwed the pooch;
Bob Moravsik did what he does best; the region adapted to correct the
situation; the problem is non-existent. To make more of it is a waste
of time and effort and only serves to cause trouble for no reason.
Joe
---
-----------------------------------------------------------------
--- Following message extracted from NETMAIL @ 1:374/14 ---
By Christopher Baker on Sun Oct 20 14:06:22 1996
From: John Souvestre @ 1:396/1
To: Christopher Baker @ 1:374/14
Date: 19 Oct 96 03:49:50
Subj: NodeList Problem
Hello Chris.
Feel free to print this in FidoNews.
FIDONEWS 13-43 Page 18 21 Oct 1996
Regards,
John
===
* Original to Ward Dossche at 2:292/854 in "netmail"
* Forwarded Sat Oct 19 1996 03:52:59 by John Souvestre at 1:396/1
cc: Bob Satti 1:153/6
David Nugent 3:632/348
Ariel Nardelli 4:905/101
Henk Wolsink of 5:7104/2
Kazuyoshi Shinada 6:730/9
Egons Bush 2:5100/8
ZONEGATE echo
FN_SYSOP echo
Hello Ward.
There has been no Zone 2 updates in the Zone 1 NodeList for over 3
months.
All problems with other zones seem to be fixed, including Zone 3
(which passes through your own system on it way here) and Zone 6. In
Zone 1, the only remaining problem is with Zone 2 updates.
> This is a matter to be sorted out among ZC's. So far ZC/1 has not
> voiced a request to get a new full segment which to me means he's
> doing OK!
What type of leadership is this? The record speaks for itself.
ZONE2.AD7 07/04/96
ZONE2.A94 07/10/96 <== Full Segment
ZONE2.AD1 07/16/96
ZONE2.AD8 07/23/96
ZONE2.AD5 07/30/96
... <== Missing...
ZONE2.AD9 08/14/96
ZONE2.AD6 08/20/96
... <== Missing...
ZONE2.AD0 09/04/96
ZONE2.AD7 09/11/96
... <== Missing...
ZONE2.AD1 09/28/96
ZONE2.AD8 10/02/96
... <== Missing...
... <== Missing...
Stop playing politics and fix the problem. Either your site or Egons
is handling the updates properly. Meanwhile, a full segment is still
needed.
Regards,
FIDONEWS 13-43 Page 19 21 Oct 1996
John
Via MsgTrack+ 1:396/1, Sat Oct 19 1996 at 08:55 UTC
-30-
-----------------------------------------------------------------
FIDONEWS 13-43 Page 20 21 Oct 1996
=================================================================
NET HUMOR
=================================================================
Some New Telephone Options
by August Abolins, [a.abolins@ieee.ca, 1:253/60]
(The following was found on another FTN-based echo system. The
posting did not indicate any credits to an original author. I have
forwared it here as it was originally posted in the echo.)
With the myriad of telephone "services" now so widely available, two
of which are actually useful <g> I present to you one interpretation
of the madness. ..AA
-=-
Would the invention of the telephone ever have gotten off the ground
if Alexander Graham Bell's first call had gone ...
Bell: Mr. Watson, come here; I want you. Voice: If you know Watson's
extension, press 1 now. If you would like to leave a message for
Watson, press 2 now ...
The telephone, which was satisfied for a century or so simply
placing and receiving calls, has become a different animal in recent
years. These days everybody has an answering machine, a speakerphone,
and a slew of other telecommunication doodads. Call waiting, Caller
ID, and last number redial are fine, but here are some options that
can't be far behind:
ON-HOLD DISRUPT. When someone puts you on hold for more than 15
seconds, a digitized voice blares over their speakerphone, "Hey!
Remember me? I don't have all day!" This option also shorts out Muzak
if it's being played.
CALL SCHMOOZING. Stuck listening to a long-winded acquaintance? Call
Schmoozing activates a speech-synthesized voice that sounds just like
you and repeats, "Uh-huh ... I see ... right" while the other party
babbles on. They think you're hanging on every word, when you're
actually getting some work done.
CALL SCHMOOZING PLUS. Your phone places call to important contacts,
trades pleasantries, probes for career-enhancing information, and ends
by saying, "You're beautiful. Let's do lunch. Don't ever change."
GOSSIP NOTIFICATION. Company rumors are automatically broadcast to
selected voice mailboxes. Time once wasted circulating gossip
translates into increased productivity.
CALL TERMINATE. Imagine being able to fire troublesome employees just
by dialing their numbers! An excellent feature for executives with
poor confrontation skills.
NETWORK EAVESDROP. A must for the paranoid manager. Whenever anyone in
the company mentions your name during a phone conversation, a voice-
FIDONEWS 13-43 Page 21 21 Oct 1996
activated tape recorder stores the call so you can review it later and
hear what people say about you.
SELECTIVE CALL DISCOURAGING. Program the numbers of people you
_really_ don't want to speak with. When they dial your number, your
phone transmits a mild electric shock through their receivers.
CELLULAR CRANK CALL. On command, your car phone can dial any other car
phone within a 30-mile radius and tell the driver his muffler looks as
though it's about to fall off.
CALL REMINDING. Store the birthdays and anniversaries of loved ones in
your telephone's memory. On the appropriate days, the phone
automatically calls them and relays heartfelt sentiments in a
digitized voice resembling yours.
CALL INTERRUPT. When you need to end a conversation quickly, a button
on your phone causes a fake operator to break in and announce that you
have an emergency call on the line from Steve Jobs.
SUBLIMINA-CALL. Periodically during a conversation, the phone plays
subliminal messages to the other party, such as "Say yes" and
"Increase my department's budget."
CHARGE FORWARDING. A quick push of a button charges any long-distance
call to the person you're calling or to friends who don't look too
closely at their phone bills.
-=-
-----------------------------------------------------------------
From: "Mike Riddle" <mriddle@novia.net>
To: "Baker, Christopher" <cbaker84@digital.net (Christopher Baker)>
Date: Sat, 12 Oct 96 08:54:31 -0500
Reply-To: "Mike Riddle" <mriddle@novia.net>
Subject: Fwd: Geekaderata
==================BEGIN FORWARDED MESSAGE==================
>Date: Thu, 10 Oct 1996 10:05:42 -0500
>From: David Galloway <David.Galloway@chron.com>
>Reply-To: David.Galloway@chron.com
>Organization: Houston Chronicle Interactive
>Subject: Geekaderata
Geekerata
(A UNIX Analog of Desiderata (Max Ehrman, 1927))
(mainly as addressed to a network process)
Badri Krishnamoorthy
badri@srtc.com
-----
FIDONEWS 13-43 Page 22 21 Oct 1996
Route placidly amid channel noise and network failures,
And remember what throughput there may be in executing all alone.
As far as possible, without overflowing buffer
Be on communicative terms with all processes.
Broadcast your data quietly and clearly
And listen(2) to others.
Even to the null and the unreachable,
They too have their requests.
Avoid long and argumentative sessions
They are burdensome to the ether.
If you compare your priority with others'
You may become vain or bitter
For always there will be greater and lesser processes than yourself.
Enjoy your CPUtime as well as your idletime.
Keep cognizance of your portmapper, however low-level
It is a constant port in the changing mappings of the network.
Exercise caution in your execution,
For the kernel is full of traps.
But let this not blind you to what swap space there is;
Many channels strive for high bandwidths, and everywhere
Computing is full of parallelism.
Be yourself. (Check with getpid(2) frequently)
Especially do not forge NFS file handles.
Neither be cynical about sockets,
For in the face of all congestion and delays
They are as powerful as STREAMS.
Take kindly the influx of new requests,
Gracefully re-prioritizing the older ones.
Nurture support of check-points to rollback from sudden crashes
But do not thrash pages due to imagined pagefaults:
Many core dumps are born of bus error or segmentation faults.
Beyond a nominal consideration,
Be nice(1) to other processes.
You are a child in the kernel space
No less than the daemons and the device drivers,
You have a right to execute here.
And whether or not it is apparent to you
No doubt the kernel is crashing, though it shouldn't.
Therefore be at peace with your programmer
However geeky you think s/he is.
And wherever your read(2)'s and recvfrom(2)'s,
In the noisy communication channels of the network,
Keep a valid (void *) buf available in your address space.
With all its stopped jobs, missing arguments and broken pipes,
It is still a UNIX shell.
FIDONEWS 13-43 Page 23 21 Oct 1996
Be backward-compatible.
Strive to be up and running always.
--
David Galloway
Houston Chronicle Interactive
mailto:David.Galloway@chron.com
http://www.chron.com/david
===================END FORWARDED MESSAGE===================
-----------------------------------------------------------------
FIDONEWS 13-43 Page 24 21 Oct 1996
=================================================================
COMIX IN ASCII
=================================================================
[For speech program users:
The picture below depicts a stylized five dollar bill where the word
dollar has been replaced with the word dullard. it is a Federal
Reverse Note from the Untied States of America.] [grin]
--- Following message extracted from NETMAIL @ 1:374/14 ---
By Christopher Baker on Fri Oct 18 11:26:40 1996
From: Dave Aronson @ 1:109/120
To: Chris Baker @ 1:18/14
Date: 17 Oct 96 23:27:26
Subj: ascii comix
CB> Date: 29 Sep 90 22:50:38
CB> From: Dave Aronson
CB> To: Jonathan Rolfe @ 906/201
CB> Subj: Re: Happy New Year
CB> _________________________________________________________________
CB>
CB> > I always wondered what the creative could do within the
CB> > constraints of ASCII! Now let's see if anyone can get some
CB> > runes together for Hallowe'en!
CB>
CB> Maybe something like:
CB>
CB> _ H A P P Y H A L L O W E E N ! !
Wow, talk about ancient history! Guess I'll finally get around to
submitting some of my original creations. First, here's payment for
my Fidonews subscription:
.--------------------------------------------------------------------.
| .-- FEDERAL REVERSE NOTE .-- |
| |_ ...... THE UNTIED STATES OF AMERICA |_ |
| __) `````````` ______ B93810455B __) |
| 2 ___ / \ 2 |
| /|~\\ / _-\\ \ __ _ _ _ __ |
| | |-< | | // \ | |_ | | | |_ |
| \|_// | |- o o| | | | `.' |__ |
| ~~~ | |\ b.' | |
| B83910455B | \ '~~| | |
| .-- 2 \_/ ```__/ .... 2 .-- |
| |_ ///// ///// //// \__\'`\/ `` //// / //// |_ |
| __) F I V E D U L L A R D S __) |
`--------------------------------------------------------------------'
-30-
-----------------------------------------------------------------
FIDONEWS 13-43 Page 25 21 Oct 1996
=================================================================
QUESTION OF THE WEEK
=================================================================
I am aware that there are folks out there reading FidoNews with speech
programs. I know these programs are also used for Netmail and
Echomail.
The Question of the Week is who uses these programs, what programs are
in use, and are any of these functions available inside mailers or
BBS or editor programs?
Please send responses as articles, Netmail, Echomail in the FIDONEWS
Echo, or email to our Internet address. See the Masthead information
at the end of each Issue of FidoNews for contact info.
Thanks.
-----------------------------------------------------------------
FIDONEWS 13-43 Page 26 21 Oct 1996
=================================================================
NOTICES
=================================================================
Future History
29 Oct 1996
Republic Day, Turkey.
5 Nov 1996
Election day, U.S.A.
5 Nov 1996
Guy Fawkes Day, England.
1 Dec 1996
Twelfth Anniversary of FidoNews Volume 1, Issue 1.
12 Dec 1996
Constitution Day, Russia
26 Jan 1997
Australia Day, Australia.
6 Feb 1997
Waitangi Day, New Zealand.
16 Feb 1997
Eleventh Anniversary of invention of Echomail by Jeff Rush.
29 Feb 1997
Nothing will happen on this day.
25 May 1997
Independence Day, Argentina
11 Jun 1997
Independence Day, Russia
1 Dec 1998
Fifteenth Anniversary of release of Fido version 1 by
Tom Jennings.
31 Dec 1999
Hogmanay, Scotland. The New Year that can't be missed.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
-- If YOU have something which you would like to see in this
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 13-43 Page 27 21 Oct 1996
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Amazingly enough, I'm still pretty much caught up. If you've sent
anything in that you haven't heard back on, it was probably eaten
up by the routed mail goblin; please resend it.
One note: Upon request, I've changed the contact for Maximus & Squish
from Gary Gilmore to "Tech" at 1:249/106. Scott Dudley really wishes
I listed internet information in the list, but I don't. I will however
give him a plug this week: http://www.lanius.com.
Phased out this week: Apple II Software
Phase-out highlights:
This week: QNX Software Deadline for info: 1 Nov 1996.
Last week: Archimedes Software Deadline for info: 25 Oct 1996.
-=- Snip -=-
Submission form for the Latest Greatest Software Versions column
OS Platform :
Software package name :
Version :
Function(s) - BBS, Mailer, Tosser, etc. :
Freeware / Shareware / Commercial? :
Author / Support staff contact name :
Author / Support staff contact node :
Magic name (at the above-listed node) :
Please include a sentence describing what the package does.
Please send updates and suggestions to: Peter Popovich, 1:363/264
-=- Snip -=-
MS-DOS:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
CheckPnt 0.5 beta O F Michiel van der Vlist
2:500/9 CHECKPNT
FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES
FrontDoor 2.12 M S Joaquim Homrighausen
2:201/330 FD
FrontDoor 2.20c M C Joaquim Homrighausen
2:201/330 FDINFO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
Imail 1.75 T S Michael McCabe 1:297/11 IMAIL
FIDONEWS 13-43 Page 28 21 Oct 1996
ImCrypt 1.04 O F Michiel van der Vlist
2:500/9 IMCRYPT
InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL
InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO
InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO
InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB
IPNet 1.11 O S Michele Stewart 1:369/21 IPNET
Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY
Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386
MakePl 1.8 N F Michiel van der Vlist
2:500/9 MAKEPL
Marena 1.1 beta O F Michiel van der Vlist
2:500/9 MARENA
Maximus 3.01 B P Tech 1:249/106 MAX
McMail 1.0g5 M S Michael McCabe 1:1/148 MCMAIL
MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP
MsgEd 4.00 O F Paul Edwards 3:711/934 MSGED
Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS
O/T-Track 2.63a O S Peter Hampf 2:241/1090 OT
PcMerge 2.7 N F Michiel van der Vlist
2:500/9 PCMERGE
PlatinumXpress 1.1 M C Gary Petersen 1:290/111 PX11TD.ZIP
RAR 2.00 C S Ron Dwight 2:220/22 RAR
RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA
Silver Xpress
Door 5.4 O S Gary Petersen 1:290/111 FILES
Reader 4.3 O S Gary Petersen 1:290/111 SXR43.ZIP
Squish 1.11 T P Tech 1:249/106 SQUISH
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL
Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE
Tobruk 0.33 T F Paul Edwards 3:711/934 TOBRUK
TriBBS 10.0 B S Patrick Driscoll 1:372/19 TRIBBS
TriDog 10.0 M S Patrick Driscoll 1:372/19 TRIDOG
TriToss 10.0 T S Patrick Driscoll 1:372/19 TRITOSS
WWIV 4.24a B S Craig Dooley 1:376/126 WWIV
XRobot 3.01 O S Joaquim Homrighausen
2:201/330 XRDOS
OS/2:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
FleetStreet 1.17 O S Michael Hohner 2:2490/2520 FLEET
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
ImCrypt 1.04 O F Michiel van der Vlist
2:500/9 IMCRYPT
Maximus 3.01 B P Tech 1:249/106 MAXP
MsgEd 4.00 O F Paul Edwards 3:711/934 MSGED
PcMerge 2.3 N F Michiel van der Vlist
2:500/9 PCMERGE
RAR 2.00 C S Ron Dwight 2:220/22 RAR2
Squish 1.11 T P Tech 1:249/106 SQUISHP
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2
Tobruk 0.33 T F Paul Edwards 3:711/934 TOBRUK
XRobot 3.01 O S Joaquim Homrighausen
2:201/330 XROS2
FIDONEWS 13-43 Page 29 21 Oct 1996
Windows (16-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
Windows (32-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
Maximus 3.01 B P Tech 1:249/106 MAXN
PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAILNT
Unix:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
ifmail 2.8f M G Eugene Crosser 2:293/2219 IFMAIL
ifmail-tx 2.8f-tx7.7 M G Pablo Saratxaga 2:293/2219 IFMAILTX
MsgEd 4.00 O F Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T F Paul Edwards 3:711/934 TOBRUK
Amiga:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
MsgEd 4.00 O F Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T F Paul Edwards 3:711/934 TOBRUK
Function: B-BBS, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
C-Compression, O-Other. Note: Multifunction will be listed
by the first match.
Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
X-Crippleware, D-Demoware, G-Free w/ Source
Old info from: 01/27/92
---------------------------------------------------------------------
MS-DOS Systems
--------------
BBS Software NodeList Utilities Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Kitten 1.01 EditNL 4.00 MailBase 4.11a@
Lynx 1.30 FDND 1.10 MSG 4.5*
Merlin 1.39n MakeNL 2.31 MsgLnk 1.0c
Oracomm 5.M.6P@ Parselst 1.33 MsgMstr 2.03a
Oracomm Plus 6.E@ Prune 1.40 MsgNum 4.16d
PCBoard 14.5a SysNL 3.14 MSGTOSS 1.3
Phoenix 1.07* XlatList 2.90 Netsex 2.00b
ProBoard 1.20* XlaxNode/Diff 2.53 OFFLINE 1.35
QuickBBS 2.75 Oliver 1.0a
RBBS 17.3b Other Utilities OSIRIS CBIS 3.02
RemoteAccess 1.11* Name Version PKInsert 7.10
SimplexBBS 1.05 -------------------- PolyXarc 2.1a
FIDONEWS 13-43 Page 30 21 Oct 1996
SLBBS 2.15C* 2DAPoint 1.50* QM 1.00a
Socrates 1.11 4Dog/4DMatrix 1.18 QSort 4.04
SuperBBS 1.12* ARCAsim 2.31 RAD Plus 2.11
SuperComm 0.99 ARCmail 3.00* Raid 1.00
TAG 2.5g Areafix 1.20 RBBSMail 18.0
TBBS 2.1 ConfMail 4.00 ScanToss 1.28
TComm/TCommNet 3.4 Crossnet 1.5 ScMail 1.00
Telegard 2.7* DOMAIN 1.42 ScEdit 1.12
TPBoard 6.1 DEMM 1.06 Sirius 1.0x
WildCat! 3.02* DGMM 1.06 SLMail 2.15C
XBBS 1.77 DOMAIN 1.42 StarLink 1.01
EEngine 0.32 TagMail 2.41
Network Mailers EMM 2.11* TCOMMail 2.2
Name Version EZPoint 2.1 Telemail 1.5*
-------------------- FGroup 1.00 TGroup 1.13
BinkleyTerm 2.50 FidoPCB 1.0s@ TIRES 3.11
D'Bridge 1.30 FNPGate 2.70 TMail 1.21
Dreamer 1.06 GateWorks 3.06e TosScan 1.00
Dutchie 2.90c GMail 2.05 UFGATE 1.03
Milqtoast 1.00 GMD 3.10 VPurge 4.09e
PreNM 1.48 GMM 1.21 WEdit 2.0@
SEAdog 4.60 GoldEd 2.31p WildMail 2.00
SEAmail 1.01 GROUP 2.23 WMail 2.2
TIMS 1.0(mod8) GUS 1.40 WNode 2.1
Harvey's Robot 4.10 XRS 4.99
Compression HeadEdit 1.18 XST 2.3e
Utilities HLIST 1.09 YUPPIE! 2.00
Name Version ISIS 5.12@ ZmailH 1.25
-------------------- Lola 1.01d ZSX 2.40
ARC 7.12 Mosaic 1.00b
ARJ 2.20
LHA 2.13
PAK 2.51
PKPak 3.61
PKZip 1.10
OS/2 Systems
------------
BBS Software Other Utilities(A-M Other Utilities(N-Z)
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Kitten 1.01 ARC 7.12 oMMM 1.52
SimplexBBS 1.04.02+ ARC2 6.01 Omail 3.1
ConfMail 4.00 Parselst 1.33
EchoStat 6.0 PKZip 1.02
Network Mailers EZPoint 2.1 PMSnoop 1.30
Name Version FGroup 1.00 PolyXOS2 2.1a
-------------------- GROUP 2.23 QSort 2.1
BinkleyTerm 2.50 LH2 2.11 Raid 1.0
BinkleyTerm(S) 2.50 MSG 4.2 Remapper 1.2
BinkleyTerm/2-MT MsgLink 1.0c Tick 2.0
1.40.02 MsgNum 4.16d VPurge 4.09e
SEAmail 1.01
FIDONEWS 13-43 Page 31 21 Oct 1996
Xenix/Unix 386
--------------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
ARC 5.21
C-LHARC 1.00
|Contact: Willy Paine 1:343/15,| MSGLINK 1.01
|or Eddy van Loo 2:285/406 | oMMM 1.42
Omail 1.00
ParseLst 1.32
Unzip 3.10
VPurge 4.08
Zoo 2.01
QNX
---
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
QTach2 1.09 QMM 0.50s Kermit 2.03
QCP 1.02
NodeList Utilities Archive Utilities QSave 3.6
Name Version Name Version QTTSysop 1.07.1
-------------------- -------------------- SeaLink 1.05
QNode 2.09 Arc 6.02 XModem 1.00
LH 1.00.2 YModem 1.01
Unzip 2.01 ZModem 0.02f
Zoo 2.01
Macintosh
---------
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FBBS 0.91 Copernicus 1.0 ArcMac 1.3
Hermes 1.6.1 Tabby 2.2 AreaFix 1.6
Mansion 7.15 Compact Pro 1.30
Precision Sys. 0.95b EventMeister 1.0
Red Ryder Host 2.1 Export 3.21
Telefinder Host Import 3.2
2.12T10 LHARC 0.41
MacArd 0.04
Mantissa 3.21
Point System Mehitable 2.0
Software OriginatorII 2.0
Name Version PreStamp 3.2
-------------------- StuffIt Classic 1.6
Copernicus 1.00 SunDial 3.2
CounterPoint 1.09 TExport 1.92
MacWoof 1.1 TimeStamp 1.6
FIDONEWS 13-43 Page 32 21 Oct 1996
TImport 1.92
Tset 1.3
TSort 1.0
UNZIP 1.02c
Zenith 1.5
Zip Extract 0.10
Amiga
-----
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
4D-BBS 1.65 BinkleyTerm 1.00 Areafix 1.48
DLG Pro. 0.96b TrapDoor 1.80 AReceipt 1.5
Falcon CBCS 1.00 WelMat 0.44 ChameleonEdit 0.11
Starnet 1.0q@ ConfMail 1.12
TransAmiga 1.07 ElectricHerald 1.66
XenoLink 1.0 Compression FFRS 1.0@
Utilities FileMgr 2.08
Name Version Fozzle 1.0@
NodeList Utilities -------------------- Login 0.18
Name Version AmigArc 0.23 MessageFilter 1.52
-------------------- booz 1.01 Message View 1.12
ParseLst 1.66 LHARC 1.30 oMMM 1.50
Skyparse 2.30 LhA 1.10 PolyXAmy 2.02
TrapList 1.40 LZ 1.92 RMB 1.30
PkAX 1.00 Roof 46.15
UnZip 4.1 RoboWriter 1.02
Zippy (Unzip) 1.25 Rsh 4.07a
Zoo 2.01 Tick 0.75
TrapToss 1.20
|Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02
Atari ST/TT
-----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FIDOdoor/ST 2.5.1 BinkleyTerm 2.40n9 ApplyList 1.00@
FiFo 2.1v The Box 1.95* Burep 1.1
LED ST 1.00 ComScan 1.04
QuickBBS/ST 1.06* ConfMail 4.10
NodeList Utilities Echoscan 1.10
Name Version FDrenum 2.5.2
Compression -------------------- FastPack 1.20
Utilities ParseList 1.30 Import 1.14
Name Version EchoFix 1.20 oMMM 1.40
-------------------- sTICK/Hatch 5.50 Pack 1.00
ARC 6.02 Trenum 0.10
LHARC 2.01i
PackConvert
STZip 1.1*
FIDONEWS 13-43 Page 33 21 Oct 1996
UnJARST 2.00
WhatArc 2.02
Archimedes
----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
ARCbbs 1.61 BinkleyTerm ARC 1.20
Odyssey 0.37 2.06f-wimp !AskFor 1.01
RiscBBS 0.9.85m BatchPacker 1.00
DeLZ 0.01
MailED 0.95
NetFile 1.00
ParseLst 1.30
Raul 1.01
!Spark 2.16
!SparkMail 2.08
!SparkPlug 2.14
UnArj 2.21
UnZip 3.00
Zip 1.00
Tandy Color Computer 3 (OS-9 Level II)
--------------------------------------
BBS Software Compression Utility Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
RiBBS 2.02+ Ar 1.3 Ascan 1.2
DeArc 5.12 AutoFRL 2.0
OS9Arc 1.0 Bundle 2.2
UnZip 3.10 CKARC 1.1
UnLZH 3.0 EchoCheck 1.01
FReq 2.5a
LookNode 2.00
ParseLST
PReq 2.2
RList 1.03
RTick 2.00
UnBundle 1.4
UnSeen 1.1
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key to old info:
+ - Netmail Capable (Doesn't Require Additional Mailer Software)
* - Recently Updated Version
@ - New Addition
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Please send updates and suggestions to: Peter Popovich, 1:363/264
-----------------------------------------------------------------
FIDONEWS 13-43 Page 34 21 Oct 1996
=================================================================
FIDONEWS PUBLIC-KEY
=================================================================
[this must be copied out to a file starting at column 1 or
it won't process under PGP as a valid public-key]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
Comment: Clear-signing is Electronic Digital Authenticity!
-----END PGP PUBLIC KEY BLOCK-----
Pending a formal decision about including 'encrypted' material inside
FidoNews from the Zone Coordinator Council, the guts of the FidoNews
public-key have been removed from this listing.
File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
1 ZMH at 1200-9600+ HST/V32B.
This section will contain only this disclaimer and instructions until
a ZCC decision is forwarded to the Editor.
Sorry for any inconvenience.
-----------------------------------------------------------------
FIDONEWS 13-43 Page 35 21 Oct 1996
=================================================================
FIDONEWS INFORMATION
=================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------
Editor: Christopher Baker
Editors Emeritii: Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar,
Tom Jennings, Sylvia Maxwell,
Donald Tees
"FidoNews Editor"
FidoNet 1:1/23
BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds)
more addresses:
Christopher Baker -- 1:18/14, cbaker84@digital.net
cbak.rights@opus.global.org
(Postal Service mailing address)
FidoNews Editor
P.O. Box 471
Edgewater, FL 32132-0471
U.S.A.
voice: 1-904-409-3040 [1400-2100 ET only, please]
[1800-0100 UTC/GMT]
------------------------------------------------------
FidoNews is published weekly by and for the members of the FIDONET
INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation
of individual articles contributed by their authors or their
authorized agents. The contribution of articles to this compilation
does not diminish the rights of the authors. OPINIONS EXPRESSED in
these articles ARE THOSE OF THE AUTHORS and not necessarily those of
FidoNews.
Authors retain copyright on individual works; otherwise FidoNews is
Copyright 1996 Christopher Baker. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only. For
use in other circumstances, please contact the original authors, or
the Editor.
=*=*=*=*=*=*=*=*=
OBTAINING COPIES: The most recent issue of FidoNews in electronic
form may be obtained from the FidoNews Editor via manual download or
file-request, or from various sites in the FidoNet and Internet.
PRINTED COPIES may be obtained by sending SASE to the above postal
address. File-request FIDONEWS for the current Issue. File-request
FNEWS for the current month in one archive. Or file-request specific
back Issue filenames in distribution format [FNEWSDnn.LZH] for a
FIDONEWS 13-43 Page 36 21 Oct 1996
particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
where mmm = three letter month [JAN - DEC] and y = last digit of the
current year [6], i.e., FNWSMAY6.ZIP for all the Issues from May 96.
Annual volumes are available as FNEWSn.ZIP where n = the Volume number
1 - 12 for 1984 - 1995, respectively. Annual Volume archives range in
size from 48K to 1.2M.
INTERNET USERS: FidoNews is available via:
http://www.fidonet.org/fidonews.htm
ftp://ftp.fidonet.org/pub/fidonet/fidonews/
ftp://ftp.aminet.org/pub/aminet/comm/fido/
You can read the current FidoNews Issue in HTML format at:
http://www.geocities.com/athens/6894/
STAR SOURCE for ALL Past Issues via FTP and file-request -
Available for FReq from 1:396/1 or by anonymous FTP from:
ftp://ftp.sstar.com/fidonet/fnews/
Each yearly archive also contains a listing of the Table-of-Contents
for that year's issues. The total set is currently about 11 Megs.
=*=*=*=
The current week's FidoNews and the FidoNews public-key are now also
available almost immediately after publication on the Editor's new
homepage on the World Wide Web at:
http://ddi.digital.net/~cbaker84/fidonews.html
There are also links there to jim barchuk's HTML FidoNews source and
to John Souvestre's FTP site for the archives. There is also an email
link for sending in an article as message text. Drop on over.
=*=*=*=*=*=*=*=*=
A PGP generated public-key is available for the FidoNews Editor from
1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18. It
is also posted twice a month into the PKEY_DROP Echo available on the
Zone 1 Echomail Backbone.
*=*=*=*=*
Anyone interested in getting a copy of the INTERNET GATEWAY FAQ may
file-request GISFAQ.ZIP from 1:133/411.0, or send an internet message
to fidofaq@gisatl.fidonet.org. No message or text or subject is
necessary. The address is a keyword that will trigger the automated
response. People wishing to send inquiries directly to David Deitch
should now mail to fidonet@gisatl.fidonet.org rather than the
previously listed address.
FIDONEWS 13-43 Page 37 21 Oct 1996
*=*=*=*=*
SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
from 1:1/23 [1:18/14] as file "ARTSPEC.DOC". ALL Zone Coordinators
also have copies of ARTSPEC.DOC. Please read it.
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
and are used with permission.
"Disagreement is actually necessary,
or we'd all have to get in fights
or something to amuse ourselves
and create the requisite chaos."
-Tom Jennings
-30-
-----------------------------------------------------------------
Reference in New Issue Copy Permalink