FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1.
Copyright 1987 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067.
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them.
Everything here is subject to debate. We publish EVERYTHING
received.
Table of Contents
1. ARTICLES ................................................. 1
Fido v12 Support Echo Conference ......................... 1
An Informal History of FidoNet ........................... 2
FidoNet en Sudamerica .................................... 6
Preferred and Alternate Inbound: A Routing Proposal ...... 8
2. COLUMNS .................................................. 13
The Regular Irregular Column ............................. 13
3. NOTICES .................................................. 17
The Interrupt Stack ...................................... 17
Jewish and Hardware Echos Planned ........................ 17
Latest Software Versions ................................. 17
FidoNews 4-43 Page 1 23 Nov 1987
Just a reminder to all SysOps running Fido v12 that there is an
echomail conference dedicated to supporting you, named FIDO. It
is carried on the backbone nationally, and has Tom Jennings'
active participation.
If you have enhancements you would like to see incorporated in
future releases, just netmail them to me at 1/117 and I will
include them in a list which will be forwarded to Tom from time
to time for his comments. The list and comments will be posted
in the echomail conference every few months.
If you need advice or assistance with v12, and it isn't life
threatening or otherwise critical, you can call 1/117 or netmail
to it a copy of the question. If we can't answer it, we will ask
Tom to and get back to you. This way, we can hopefully give TJ
more time to relax (ha!).
I would like to make an open request to all utility authors to
consider v12 when they are enhancing current programs or
designing new ones. FIDO Help! is more than willing to gather
any information required to do this, and to help in any other way
feasible. If you have a utility which works with v12 and would
like to let everyone know, put a notice in the echo or netmail
1/117 and we will put it in for you. FIDO Help! will attempt to
keep an up-to-date list of what works and what it does for anyone
that is interested. More information on this will be posted in
the echo conference in the near future.
Finally, thanks to everyone who has helped to get the conference
off the ground, and especially to Tom Jennings for being actively
supportive from the start!
TJ once told me he began work on Fido around Christmas, 1983. He
wasn't sure exactly when.
In early 1984, I was preparing to put a CBBS on line for the CP/M
SIG of our computer club at Macdonnel Douglass when I was
approached by the club president to make it a club-wide BBS. The
club had a commitment from DEC for an indefinite loan of a
Rainbow. The theory was that the Rainbow had a Z-80 and could
run CP/M, so it should be able to run CBBS. When I finally got
the manuals for the Rainbow I discovered that the Rainbow's Z-80
did not have access to the I/O ports, so it could NOT run CBBS!
I immediately began a frantic search for BBS software which would
run on the Rainbow, which led me to John Madill's board in
Baltimore. There I engaged in a message exchange with Tom
Jennings, who was frantically searching for someone to write a
comm driver for FIDO_DEC.
No, I didn't do the comm driver (don't remember who did), but I
did get a copy of the first Rainbow version (which was, I think,
originally intended for John Madill's home machine -- don't know
if he ever put it up). By mid March I had it running on the
club's Rainbow 100.
I don't know when TJ began numbering Fido installations, but at
that time there were at least 6, but no more than 8. He would
not assign me a number until he could "list" me in his informal
Fido list, and I did not get a phone line assigned to the system
until sometime in April. When I could finally give him a
publishable phone number, I was listed as "Fido 10," the second
St. Louis Fido (Tony Clark was Fido 4). I began with a late
Version 3, but by the time I was listed, I think I was running
Version 5.
In May, Fido began to blossom, and by Memorial Day there were
around 15 Fidos on line. St. Louis had 5 of them -- 4, 10, 16,
17 and 22. (TJ had begun assigning Fido numbers when he mailed
out diskettes, many of which never did come on line). Curiously,
all but Tony Clark were running Fido on Rainbows!
Sometime in late May or early June I was talking on the phone
with TJ and the subject of networking the BBSs together came up.
"Wouldn't it be neat if one Fido could automatically call another
and send it messages and files -- automatic software updates!"
That night TJ logged into Fido 10 and uploaded FIDO_DEC V6, a
brand new program called FIDONET, and a new system file called
"NODELIST.BBS." With that, FidoNet was born.
Version 6 implemented a very primative amorphous network with
just one hard-wired schedule. Traffic level grew rapidly as
everyone experimented with this new toy, and it soon became
apparent that most of the time we were butting heads, and many
FidoNews 4-43 Page 3 23 Nov 1987
messages never went through. We needed more elaborate scheduling
and some means of defining message routing. But how do you
develop and do controlled testing on something like that without
spending a fortune on phone bills? St. Louis which by this time
had added a 6th Fido (51), could model a real network with local
phone calls! No other city could boast more than 2 Fidos. That
is how I became involved in difining Fido's routing language with
TJ. TJ wrote, we tested, we fed back results and needs, TJ
wrote, sometimes two releases in a day! By August we had version
7, with its routing language, ready for distribution, and FidoNet
began to change shape toward what we see today.
TJ was maintaining the nodelist. When he received a change
request, he would write it down on a small slip of paper and
stick it to the wall. Frequently the slip would fall from the
wall and disappear behind his computer, never to be seen again.
By September the nodelist was a shambles!
I'm not sure if we volunteered or WERE volunteered, but Ken and I
agreed to take over nodelist maintenance, and on September 21,
1984, we (well, mostly Ken) published the first "St. Louis
Nodelist." It took us a couple of weeks to weed out all the bad
numbers and drop-outs, but by the middle of October we had a
pretty solid nodelist. TJ had been bit once or twice with fake
node number requests. (I'm sure many of you have heard a version
of the famous "little old lady." It actually happened. He
accepted a phone request for a node number. After several
complaints from the net about no-answer, he called the number
during the day and got an earfull!) So we established our first
FidoNet policy: ya gotta request a node number via net mail. Of
course, TJ was still passing out node numbers with diskettes, and
we still had a few bad ones. It took another month to persuade
him to stop, and to publish "our policy" in the docs.
It was October or November that TJ published the first issue of
our irregular weekly newsletter, FidoNews. I don't think he had
ever intended to continue with the newsletter very long, and in
January he passed that baton to Thom. I remember at the time I
had never heard of Thom Henderson! Who the hell is he? Ken
didn't know either. Hey Ken did you ever figure out who this
Thom Henderson is? What kinda name it "Thom" anyway?
I think we were in Fido Version 8 when, in the Spring of 1985, we
were rapidly approaching Fido's 250 node limit. A nodelist that
size was becoming difficult for one man to manage and still find
time to kiss his wife occasionally! Our computer club and the
local DECUS chapter brought TJ to St. Louis to speak at a joint
meeting on April 10th and the next day we had an all-day meeting
at Ken's house.
After an 11 hour session we codified what was already taking
place. With the advent of a routing language, FidoNet was
collecting itself into local groups or "nets," usually around a
node willing to foot the bill for long-distance calls. So we
created the net/node addressing scheme. Node numbers within a
net would no longer have to be unique on FidoNet, only within the
FidoNews 4-43 Page 4 23 Nov 1987
local net. Thus the "network host" could maintain his own net
list. But that still left about 100 or so nodes scattered
throughout the hinterlands and not alligned with anybody. The
net implied routing. How about a different kind of "net" that
did NOT imply routing -- a Region. TJ reached into his knapsack
(hey, that's the way he travels, knapsack and skateboard) and
pulled out two or three hugh U.S. maps. We spread one out on the
floor and with a felt pen, began carving. We divided up the
country into ten pieces we hoped represented more-or-less equal
populations (at 10pm on a Thursday night we were not in a
scientific mood) and dreamed up names for the ten new "regions."
TJ went home and got back in the "a version a day" mode. Ken and
I put a freeze on the nodelist and began creating net and region
files and assigning new net addresses. By early May the software
was beginning to stablize and we "went public." As I recall, we
set June 15 as the cut-over date to the new addressing scheme
(with a silent prayer that we could get everything in place by
then). We found ten people willing to be regional coordinators.
We unfroze the nodelist and gave hosts a formula for assigning
node numbers (until the cut-over, they still had to be unique).
Finally the the fateful day came for us to all use the "3"
command and set our new net addresses. I was expecting total
chaos. I was not at all prepared for just how smooth the
transition happened! Oh sure, there were a few stragglers and
even a few drop-outs, but still, one day we were an amorphous
network and the next FidoNet was partitioned into local nets and
regions -- and the mail kept flowing as if nothing had happened!
It took a good deal of coordinated effort by a great many people,
and it proved we COULD function as a body!
It was about that time that TJ first suggested a membership
association. After all, we had proved we were an organization,
so why weren't we an officially sanctioned organization. I was
originally cool to the idea. Providing tee shirts and bumper
stickers was not the kind of service foundation I thought
appropriate, so I dragged my heels. With the Tsimpidis affair
still fresh in my mind I saw a need for a strong collective
voice, but I didn't have any idea how to get there.
I'm sure there were events of moment, but I don't recall much
more as 1985 slid quietly into 1986. A 500 node limit came and
went, almost without notice. TJ said "This new version (11) can
handle 1200 nodes. That ought to hold us for quite a while." We
coined the name "International FidoNet Association" and used it a
first line in the mailing address. FidoNet began appearing more
frequently in national publications Like it or not, we were a
growing force and we were being noticed. Ken began receiving
donations in the name of IFNA, and they helped defray the costs
of our new-found recognition.
Two things happened in 1986 to crystalize the IFNA concept and
one to definitely polarize it.
First, an April conversation between Ken and his accountant went
FidoNews 4-43 Page 5 23 Nov 1987
something like this: "You've got to pay income tax on these
'donations.'" "But that's not my money!" "I know, but what IS
IFNA? Can you prove to the IRS that it exists?" "Well. . .
er. . . uh. . ." Total receipts for 1985 were only a few hundred
dollars, but still, that's a non-trivial tax burden and 1986
revenues had already exceeded 1985's.
Then in May we were asked by COSUG, "How would you like to help
us put on a Sysops' Conference?" Sounded like a good idea to us
and we immediately went to work on it. Then in July they said
"Looks like we might have a small surplus. We will gladly share
it with IFNA, but we can only do that if IFNA is a bona fide not-
for-profit corporation.
So, with some trepidation, Ken filed IFNA's incorporation papers
in late July or early August. On reflection, we should have said
"Keep the money -- let's see what happens at the conference
first." Marvelous thing, hindsight.
Then came the conference in August. From that momment to this
our history becomes a blur to me. I recall that a self-appointed
IFNA spokesman put us in deeper, hotter water every time he
opened his mouth. I recall that, with no authorization save the
aforementioned spokesman's, IFNA memberships went on sale. I
recall a disasterous "business meeting." I recall Ezra putting
out the fire under the tar pot. I recall a by-laws committee, a
New Hampshire meeting, a Chicago meeting, flames, counterflames.
I recall twice throwing in the towel and twice being persuaded to
reconsider my action.
But can I put order to all of that? 'Fraid not -- it's all a
blur. Another historian will have to pick up from the
conference; one with clearer recollections (or perhaps records).
Has it all been worth it? For me, the first two years were an
unqualified success. As to the last year, only time will tell.
I think we now have the skeleton of a potentially successful, and
useful, organization. Now, lets get some meat on the bones.
Ben
I have told this abreviated history from my own perspective. I
have left out many people and events really important to the
development of FidoNet. The list is long and I will not attempt
to enumerate them for fear of omitions. You know who you are.
Most of you know who "they" are. I would simply say to all of
you -- THANK YOU.
Today there are five registered Fidonodes in South America:
one in Suriname and four in Argentina.
The growth of the net in this southlands is somewhat
limited by the "deficit of phone lines" (very high in the most
developed countries of the region).
Since right now, these countries are having a "democratic
comeback" (specially Argentina, Brazil and Uruguay), there is no
control at all over the phone lines and the establishment of new
BBS is not limited by any political reason (like there can be in
a country with a dictatorship like Chile or Paraguay, where the
gov't wants to control all the communications and may find BBS
and Email as something dangerous).
You must not expect an easy grow of nodes like in North
America, it is much more difficult to install BBSes here, and
that is determined by some facts like the deficit of phone lines
and the lack of technical support.
To change that, I (with a group of hobbyists) started a
campaign to promote BBSes and Fido all over the region. But
some things must be done soon:
- Translation of all the software needed to setup a node.
- Getting support from the gov'ts and organizations.
(we are now working on that)
The first Fido in Argentina was installed in June. To
contact IFNA it took me 3 months of researching at various
sources including CompuServe and Delphi. I finally found Harvey
Nehgila (thanks, Harv!) at CompuServe who gave me Ken Kaplan's
number (I had Fido v10j and its manual was pretty obsolete, I
tried to call 1-415-864-1418 which said was Tom Jenning's node's
for a week at NMH without success, until I dialed manually and
found out that the number was disconnected! I asked San
Francisco's operator for the new number but there wasn't a new
number...).
In June, I started to organize a National FidoNet and I
convinced four sysops in Buenos Aires to switch to Fido (that
was in September). We formed TangoNET for Buenos Aires city.
Now, there are a couple of nodes working in the second
and the third largest cities in the country, but as they don't
have direct dialing to the USA, and we don't have yet an
independent region or zone, they aren't able to join FidoNet.
That's why I'm asking IFNA to form a separate Region in Zone 1
or to form Zone 4, even if there are only 6 or 7 nodes.
FidoNews 4-43 Page 7 23 Nov 1987
We need help from experienced FidoNet sysops. Also from
the creators of at least one of the available FidoNet-
compatible BBS systems in order to get the source code and
manuals to make a version in Spanish.
If you can help, or want to know something else, please
send mail to FidoCenter (Node 368/1). Our mailing address is:
FidoNet Sudamericana
Suipacha 1322 Suite A
1011 Buenos Aires, CF
Republica Argentina
Thank you very much,
-Pablo Kleinman
Note: If you are interested in participating in the effort of
building the Network in South America please contact either
myself (368/1), Travis Good (102/851), or Juan Davila
(367/3). We also have an echo called LATINO which we'd be
happy to have you join.
PREFERRED INBOUND AND ALTERNATE INBOUND: A ROUTING PROPOSAL
(This article is NOT COPYRIGHTED and may be reproduced by anyone,
in any form, with no strings attached.)
The present scheme of regions, hosts, hubs, and nodes within
Fidonet was developed in an era when, by and large, all telephone
costs were distance-sensitive (and where the costs always
increased when your call terminated at a more distant point).
Even at that time those assumptions were not always true (due to
the use of leased lines and the generally higher cost for in-
state calls as opposed to out-of-state calls) but now that we
have PC Pursuit and AT&T's Reach Out America plan, distance is
often of no consideration in making modem calls.
Still, nets are often arranged geographically, with all BBS's in
a given region grouped together on a geographic basis. This
works well enough when an entire net is located in a major
metropolitan area, but it often does not meet the needs of Sysops
in more remote areas.
The major reason that it doesn't work well is that the backwater
Sysop's HOST is probably accessible only via the long distance
phone system, and the HOST itself may be in only a medium-sized
city. Consider, for a moment, the disadvantages that our rural
Sysop will face:
1) He will probably be expected to POLL his host for mail on a
regular basis, even though the volume of received mail may be
very low.
2) He probably does not yet have access to an alternate long
distance carrier, let alone a packet network or PC Pursuit,
so his calls to the host will be at AT&T long distance rates.
If the host is located in the same state and is some distance
away, those rates may be VERY high, even at night!
3) If the host is not in a PC-Pursuitable city, other Sysops
will charge their users to send mail through to the remote
board (if they allow it at all). This, in turn, will lower
the volume of received mail, making the prospect of having to
poll the host regularly even less attractive.
What we are talking here is COST. The Sysop who is out of the
mainstream of traffic may have expenses that are many times those
of a sysop living in a larger city. But inefficient routing can
also affect Sysops in more populated areas. For example, if your
inbound host is a long distance call (and is not PC Pursuitable),
it's still going to cost you to connect with him even though you
may be able to access other hosts (of other nets) for free or for
less money.
I'm sure that others have suggested that the whole Fidonet system
FidoNews 4-43 Page 9 23 Nov 1987
be reconfigured to take maximum advantage of PC Pursuit or Reach
Out America or some other quirk in local calling rates.
There are a couple of major problems with that, however. The
first is that if the service that the net is configured around
goes down or has a dramatic rate increase, you're right back to
inefficient routing (for example, if the proposed FCC regulations
go through and PC Pursuit is discontinued, I can guarantee you
that there will be some major changes in the way that Echomail is
being routed!). The second is that the geographic unity of a net
is not something that should be easily cast aside. It is nice
(and usually very beneficial) to be in frequent communication
with other Sysops in your own area!
Therefore, I have a proposal that would retain the present
net/hub/node structure but would allow calls to be rerouted based
on least-cost principles, where the sysop of the receiving board
is willing to put a little effort into making it happen. My
proposal involves new comments in the miscellaneous field of the
nodelist:
AI:net/node - An alternate inbound routing that MAY be used if it
is less cost to the calling board.
PI:net/node - A PREFERRED alternate inbound routing that SHOULD
be used by the calling board if it is the same cost or less cost
than host routing or direct routing. This might be used when it
is a toll call from the receiving board to the net host, but a
"free" (PC Pursuit, possibly?) call to the preferred alternate.
In either case, more than one net/node may be specified. Let me
give a hypothetical example of how such routing might save some
money. Since a picture is supposed to be worth 1,000 words and
I'm tired of typing, please refer to the following diagram of
nodes in imaginary net 999:
999/999 999/123 888/888 777/777
BACKWATER <-----> SMALLTOWN ----> HUBTOWN -----> METRO
x x
| | (TELENET (PC PURSUIT
x x ACCESS) INBOUND CITY)
HOST 999/0 (TOLL CALL)
Let's assume that BACKWATER is at the edge of nowhere, but is
within the local telephone calling area of SMALLTOWN, which is,
presumably, in the middle of nowhere! In our hypothetical
example, the Net 999 Host is a toll call for both boards but the
Sysop of the Smalltown board happens to be a business owner with
a direct line (foreign exchange or WATS, perhaps) to HUBTOWN,
which as it happens is the location of a HUB for net 888
(unfortunately, that's NOT part of the same net!). Our Smalltown
BBS operator POLLs the Hubtown node daily to pick up echoes and
whatever mail might be incidentally routed that way. Meanwhile,
the Hubtown node operator, which has access to a Telenet local
line, places a daily call via PC Pursuit to POLL node 777/777 in
METRO for mail.
FidoNews 4-43 Page 10 23 Nov 1987
Under the present setup, both the Backwater and Smalltown Sysops
would have to POLL their host to receive incoming matrix mail.
Of course, they could realign themselves to be under Net 888,
ASSUMING that the host of node 888 has no objections and the
regional coordinator(s) involved are willing to allow the
transfer - but what if, two months later, the Sysop of the
Smalltown node decides to pull the plug on his system? Then the
Backwater Sysop is left high and dry, with no connection to Net
999 and the possibility of a not-too-satisfying relationship with
Net 888.
Let's suppose, however, that our Backwater Sysop would take the
initiative to contact all of the nodes involved and set up the
following arrangement:
METRO 777/777 receives mail for Backwater - this in effect makes
the Backwater board PC Pursuitable for mail purposes - and HOLDs
it for pickup by HUBTOWN 888/888. HUBTOWN 888/888 in turn HOLDs
it for pickup by SMALLTOWN 999/123. When 999/123 receives the
mail packet, he immediately CRASHes it to 999/999 because it's a
local call. This much of it is all workable under the present
system. The only problem is that any Sysop that simply runs
Xlatlist, without knowing about this arrangement, will
automatically route mail for 999/999 to the Host (999/0) which,
as noted earlier, happens to be a toll call for the Net 999
boards in question.
Now, if our Backwater Sysop could some convince everyone to ARC
his mail TO 888/888 or 777/777, he'd be in fine shape. He
wouldn't have to Poll the host to get his mail. So how does he
do this? Under my proposal, he would place this comment in the
nodelist:
PI:888/888 777/777
This would tell other Sysops that, if it is a toll call to his
board, he would prefer that mail be routed to 888/888 or 777/777
rather than to the Net 999 Host. On the sending end, the program
that handles the mail (that would have to be written to implement
this scheme) would use this logic to route the outgoing call:
1) Is 999/999 a local/zero cost call? If so, direct route it.
2) Is 888/888 a local/zero cost call? If so, route it via
888/888.
3) Is 777/777 a local/zero cost call? If so, route it via
777/777.
4) Is the HOST (999/0) a local/zero cost call? If so, host
route it (the HOST may still receive some inbound mail for
this node, but he may be able to Arc it To a node in the
Backwater system's "free" path, if the call is also "free"
for him.)
5) If all of the above are toll calls, then check the cost
FidoNews 4-43 Page 11 23 Nov 1987
fields to determine which of routing direct to 999/999,
indirect via 888/888, indirect via 777/777, or indirect via
the host (999/0) is the least expensive and use that method.
6) Where the costs are the same, the first choice would be
direct routing. Since this was set up as a Preferred
Inbound, the second and third choices would be to route via
888/888 or 777/777. Host routing would only be used if it
was clearly the lowest cost choice for the sender.
Now let's change the scenario a bit. Suppose that the above
diagram is the same except that the HOST happens to be a local
call. In this case, the Backwater Sysop isn't out anything when
he polls the host, so he doesn't care if other boards send mail
directly to his board, or route it via his Host. The only
problem with this scenario is that the Host isn't in a PC
Pursuitable city, which means that users in distant areas have to
pay their Sysops to send mail to Backwater. Now, instead of PI:
(Preferred Inbound), the Backwater Sysop would use AI: (Alternate
Inbound). This simply reverses the priorities so that Host
routing would be preferred over the use of 888/888 or 777/777 for
inbound mail, BUT if it is a zero cost (or lower cost) call for
the originating BBS, it MAY route via one of the other two
boards.
Of course, the above describes one particular situation (any
similarity to a real-life situation is purely coincedental) but
the ability to use the PI and AI comments (one or both) in the
comment field might permit mail to flow at a lot lower cost.
More importantly, I think, is that existing Net bonds are not
destroyed and if something changes, changing the preferred or
alternate routing is as easy as making a change in the nodelist.
Now, how would a PI: or AI: be used at the sending end? Well,
the lo-tech method would be for a Sysop to manually eyeball the
nodelist and look for the PI's and AI's. Let's suppose he found
the Backwater BBS and, because he was a PC Pursuit user, could
call 777/777 for free. He would then insert a statement such as
ArcTo 777/777 999/999 in his route control file. Most Sysops
wouldn't enjoy doing this very much (although they might make the
necessary adjustments for frequently-called nodes), so I'm sure
that someone would write a utility that would scan the nodelist
(after xlatlist processing) and generate appropriate statements
for the route control file. Such a utility, when it encountered
a PI: or AI: statement, would check the cost fields of the boards
referenced by the PI: or AI: and generate any necessary
statements based on the logic outlined above. If the board with
the PI: or AI: statements happened to be a Host or a Hub, then
the routing for all boards below that host or hub would also be
checked and changed if the alternate routing could be
accomplished at lower cost. Ultimately, a new version of
xlatlist might handle all of this automatically, or a newer
version of the BBS or mail-handler program (whichever brand
you're using) might read the comments and make the necessary
adjustments in calling patterns.
FidoNews 4-43 Page 12 23 Nov 1987
As with anything, this kind of alternate routing capability could
be misused (I can envision "super" mailboards in the large PC
Pursuit cities becoming nearly impossible to reach due to
overloads), so it would have to be used with some restraint to
spread the message traffic evenly. But I also think that many
Sysops would welcome this method of reducing costs for outgoing
mail, while at the same time encouraging a freer flow of mail to
the boards in the outlying areas.
Comments on this proposal may be left to me via the BIXNET BBS
(120/64, 616-361-7500 300/1200/2400bps), although I really can't
do much more to develop it. The idea is simple, could be
implemented NOW in a limited manner, and when appropriate
software is written could be more fully implemented. For the
present, a Sysop could just ignore the PI: and AI: comments and
continue to Host route mail, or could manually make changes to
his route control file for as many boards as he cares to make the
effort. I hope that this idea will receive some consideration
among those in the Fidonet community.
-- The Regular Irregular Column --
Dale Lovell
157/504
So far, so good. It looks like I should be back to my weekly
schedule for the next few weeks. Not only should I have the time
to write, but I should also have a profusion of new software,
updates to old software, and discoveries. I'm beginning to
discover that Robert Heinlein's comments on writing are correct;
once you start writing, you can never quit. In the meantime,
let's get this monkey off my back this week.
-- Brief (Solution Systems, $195.00) --
I've been hearing about Brief for over a year from various
sources (friends, programmers, echomail) and decided it was time
to take a look at it myself. Needless to say, everyone else was
right. It is a phenomenal program and I can already see the day
coming when I won't know how I got along without it. While it is
a text editor (versus a word processor), it contains many
capabilities not found in high-end word processors. It has the
ease of use of Norton's Editor, the windowing capabilities of
Microsoft Word (more on the new version of Word in a few weeks),
and the macro capabilities of WordPerfect. Combined these
features would make many a secretary drool, yet it is clearly
designed for the programmer. This isn't to say it couldn't be
used as a word processor, just that it isn't designed for it (no
spell checker, thesaurus, etc.).
One of the first things that will clue you off to the fact
that it's a programmer's text editor is the capability to compile
the file(s) you're working on from within Brief. During the
installation you instruct Brief on what file extensions are
special (C for C programs, ASM for assembly language, etc.) and
what compiler you're using, it knows about many of the compilers
on the market today so it isn't too hard. Once you're done
editing a file all you have to do is press F10 and your
compiler's Brief macro and it will automatically compile the file
(a buffer in Brief terminology) you've been working on. Some
compilers can coexist with Brief, for others Brief unloads itself
and compiles. I've been tempted to try and tie Brief in with
Microsoft's make utility, but am holding off until I'm more
comfortable with it. An added advantage of this is Brief will
automatically locate any errors. You can look at a list of errors
in the current file and jump to the next or previous error. While
this may not be as ideal to many used to the immediacy of the
Quick/Turbo series of programs, it can be a big step forward to
those of us used to printing several pages of errors and trying
to remember if we've added 4 or 7 additional lines when we go
hunting for the next error.
FidoNews 4-43 Page 14 23 Nov 1987
Brief also excels in it's search and replace capabilities.
Where most text editors and word processors only let you decide
if it should be case sensitive and possibly allow wildcards,
Brief overflows with possibilities. When you do a search (or
search and replace) you can enter an expression. The expression
could be straight text, or you could enter one of the special
functions within Brief. For example, if you wanted to find all
the occurrences of "STR(10" and "STR(20", you would enter
"STR(1|20" and Brief would only look for those two expressions.
Some of the expressions available allow you to define groups and
character sets. If you were editing a BASIC program and wanted to
find all LOCATE commands that were using a variable you might
enter "LOCATE [~,0-9]" and it would go look for them. That last
example tells Brief to look for "LOCATE " followed by anything
except a comma or a digit. This is only a small example of the
power of these expressions. Some of the descriptions include a
means of defining a range (inclusive or exclusive) or character
set, a group (want to look for all occurrences of "him" or
"her"). In addition you can decide where you want the cursor
positioned after a search, at the beginning or end of the
characters. These capabilities are not only limited to searching
for text, but can be used when doing a search and replace as
well.
Brief also has the ability to edit an unlimited number of
files at the same time. Each file is loaded into it's own buffer
and there are several commands that allow you to switch between
the buffers or load a new buffer. This can be nice if you're
working on a program that is contained in several different
source files and have organized your hard drive properly.
Entering "b *.c" at the DOS prompt will bring up Brief and load
every file with the "c" extension into its own buffer. When
you're ready to compile just switch to the "main" program and
start the compile. All from within Brief of course! This probably
wouldn't have too impressive except that Brief also has windowing
capabilities like Microsoft Word. You can create as many windows
as your screen will allow (Brief knows about 43 line EGA
displays). Each window could show a different (or identical) part
of the same buffer or entirely different buffers, mix and match
as you please. I've gone so far as to have 8 different batch
files on the screen at once in 10 different windows. Granted they
were all small batch files, but it was impressive to see. A much
more practical use would allow a programmer to examine and edit a
call to a subroutine, the subroutine itself, and his working
notes all at the same time. If you write software and haven't
wished for this capability at least once, I'd say you've been
blessed (a condition which I decided I wasn't long ago).
While Brief is a "high-end" text editor, I believe it is
definitely worth the money. If it wasn't for the fact that I
depend on an electronic thesaurus and spell checker, I would be
tempted to give up my word processor and only use Brief. Solution
Systems bills it as "The Programmer's Editor" and is very close
to the truth. While it is definitely aimed at the programming
community, I can't help wondering if there might not be a WP-
Brief around the corner. The WP standing for word processing.
FidoNews 4-43 Page 15 23 Nov 1987
From what I've learned about Brief in the past week, it surpasses
the capabilities of most word processors in some ways and I'm not
even close to mastering the product. The macro language appears
to be one of the most powerful I've ever seen, and you can edit
your Brief macros from within Brief. I'd recommend it to anyone
who is currently developing software for a living or writes a
large amount of code. I have never before seen a text editor as
powerful as Brief. Having seen just a glimpse of its power, I
honestly can't imagine choosing to use a different text editor.
Brief macros are among the most powerful I've ever seen. I'm
currently using WordPerfect to write these columns and I go
through some unusual routines to make an ASCII file that FidoNews
can accept. I completely write and edit the text in WordPerfect.
When I'm satisfied with the column, I use WordPerfect's DOS text
printer to create a file called DOS.TXT. After renaming the file
to LOVELLnn.COL (with nn being the column number), I use a text
editor to take out all the additional spacing (headers and
footers primarily) and the FF (control-L) characters. With this
completed I have a file I can send off that Thom's newsletter
generation program will accept. In the past I've been doing this
last step manually. In case you have the same software
(WordPerfect and Brief), I'll mention that I use WordPerfect's
default page format and only change the line format to a left
margin of 0 and a right margin of 64. Sometime soon I'll include
the macro I've written that will automatically do this last step
for me. This is a good example of how software can make your life
easier. Instead of taking a few minutes, I'm only going to take a
few seconds.
-- Winding Down... --
Some of you reading this may remember the first "x-rated"
computer game, Softporn from Sierra On-Line for the Apple II
computers. Well, Sierra has done it again with "Leisure Suit
Larry in the Land of the Lounge Lizards" (Sierra On-Line,
$39.95). Many of the situations seem almost identical to Sierra's
earlier product. If you played it, you'll have a head start on
everybody else playing this game. The new twist is graphics, like
those in Sierra's King's Quest series. While the game greatly
resembles its predecessor, there's more than enough new twists
and turns to amuse everyone. I've greatly enjoyed playing Lounge
Lizards and would recommend it to any adult game players. Every
time you start the game you have to go through a short quiz.
After asking you your age, your have to answer a series of
questions. The questions are based on your age, and should be
fairly easy if your claimed age is correct. If you miss 2
questions or are under 18, the game exits. While this may not be
the greatest means of preventing "youths" from playing Lounge
Lizards, it should be adequate for most. I heartily recommend
Lounge Lizards, it is both humorous and enjoyable (as well as
being unusual).
As always, I would like to hear any comments you may have on
my columns. If it's a correction or something I missed, I'd like
a chance to set things right. I try to respond to all the mail I
FidoNews 4-43 Page 16 23 Nov 1987
receive, although sometimes it sits around awhile before I get to
it. Below you'll find my US mail, FidoNet and Usenet addresses.
If you're sending me a message through FidoNet, please mention to
your sysop that mail to me must be routed through 157/1 since I'm
a private node.
Dale Lovell
3266 Vezber Drive
Seven Hills, OH 44131
7 Dec 1987
Start of the Digital Equipment Users Society meeting in
Anaheim, CA. Contact Mark Buda at 1:132/777 for details.
9 Jan 1988
The next net 104 FidoNet Sysop Meeting. Contact Oscar Barlow
at 104/0 for information.
25 Aug 1988
(pending BoD approval) Start of the Fifth International
FidoNet Conference, to be held at the Drawbridge Inn in
Cincinnatti, OH. Contact Tim Sullivan at 108/62 for more
information. This is FidoNet's big annual get-together, and
is your chance to meet all the people you've been talking with
all this time. We're hoping to see you there!
24 Aug 1989
Voyager 2 passes Neptune.
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
The MailCom Message Center of Palo Alto, CA has started two new
echos and is looking for subscribers. The echos are Henani --
The Jewish Echo, and an Electronics Echo. Sysops interested in
carrying the Henani or Electronics echos should contact Bernard
Aboba via FidoNet mail at 143/444. Henani is meant to serve as a
forum for discussion and information on Jewish issues, religous
practices, and philosophy. The Electronics Echo is intended to
aid hobbyists and electronics professionals in designing
electronics projects or microprocessor based systems.
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays an annual specified membership fee. IFNA serves the
international FidoNet-compatible electronic mail community to
increase worldwide communications. **
Name _________________________________ Date ________
Address ______________________________
City & State _________________________
Country_______________________________
Phone (Voice) ________________________
Net/Node Number ______________________
Board Name____________________________
Phone (Data) _________________________
Baud Rate Supported___________________
Board Restrictions____________________
Special Interests_____________________
______________________________________
______________________________________
Is there some area where you would be
willing to help out in FidoNet?_______
______________________________________
______________________________________
Send your membership form and a check or money order for $25 to:
International FidoNet Association
P. O. Box 41143
St Louis, Missouri 63141
USA
Thank you for your membership! Your participation will help to
insure the future of FidoNet.
** Please NOTE that IFNA is a general not-for-profit organization
and Articles of Association and By-Laws were adopted by the
membership in January 1987. The first elected Board of
Directors was filled in August 1987. The IFNA Echomail
Conference has been established on FidoNet to assist the
Board. We welcome your input on this Conference.
The IFNA publications can be obtained by downloading from Fido
1/10 or other FidoNet compatible systems, or by purchasing them
directly from IFNA. We ask that all our IFNA Committee Chairmen
provide us with the latest versions of each publication, but we
can make no written guarantees.
System Enhancement Associates SEAdog $60.00 _____
ONLY 1 copy SEAdog per IFNA Member.
Fido Software's Fido/FidoNet $65.00 _____
ONLY 1 copy Fido/FidoNet per IFNA Member.
As of November 1, 1987 price will increase to
$100. Orders including checks for $65 will be
returned after October 31, 1987.
SUBTOTAL _____
Missouri Residents add 5.725 % Sales tax _____
International orders include $5.00 for
surface shipping or $15.00 for air shipping _____
TOTAL _____
SEND CHECK OR MONEY ORDER TO:
IFNA
P.O. Box 41143
St. Louis, Missouri 63141 USA
