1739 lines
93 KiB
Plaintext
1739 lines
93 KiB
Plaintext
ÞÛÛÝ° ÜÛÛÛÛÛÜ ÜÛÛÛÛÛÛ° ÛÛ° ÛÛ° ÜÛÛÛÛÛÛ° ÛÛ° ÛÛ° ÜÛÛÛÛÛÜ
|
|
ÛÛ° ÛÛ°°°°° ÛÛÜÜÜÜ° ÛÛÛÜ ÛÛ° ÛÛÜÜÜÜ° ÛÛ° ÛÛ° ÛÛ°°°°°
|
|
ÛÛ° ÛÛ° ÛÛßßßß° ÛÛßÛÛÛÛ° ÛÛßßßß° ÛÛ° Ü ÛÛ° ßÛÛÛÛÛÜ
|
|
ÞÛÛÝ° ßÛÛÛÛÛß ßÛÛÛÛÛÛ° ÛÛ° ßÛÛ° ßÛÛÛÛÛÛ° ÛÛÜÛÛÛÜÛÛ° °°°°ÛÛ°
|
|
ÛÛ° ÛÛ°°° ÛÛ°ÛÛ° ÛÛ° ÛÛ° ÛÛ°ÛÛ°° ßÛÛß ßÛÛß ßÛÛÛÛÛß
|
|
ÞÝ° ÞÝ° ÞÝ°ÞÝ° ÞÝ° Þ° ÞÝ°ÞÝ° ÞÝ° Þ° ÞÝ°Þ°
|
|
Ý° Þ° Ý° Þ° Ý° Þ° Þ°
|
|
|
|
The Journal of IceNET December 1994
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³The Editor's Desk ³
|
|
³ The Upper Registers Will 1@6754 ³
|
|
³ ³
|
|
³Features ³
|
|
³ Getting to WWIVcon, Cheap! Seafox 1@2459 ³
|
|
³ WWIV for OS/2 Preview East Bay Ray 323@3050 ³
|
|
³ ³
|
|
³WWIV Chronicles ³
|
|
³ Modifications for Dummies! Spotnick 1@5497 ³
|
|
³ ³
|
|
³Software/Programming ³
|
|
³ IBM OS/2 Warp v3 Will 1@6754 ³
|
|
³ ³
|
|
³Light Bytes ³
|
|
³ The REAL Sysops Guide Aldo Cella 654@7654 ³
|
|
³ Silly Strings Ima Moron 1@9661 ³
|
|
³ ³
|
|
³Special Feature ³
|
|
³ The WWIVnet Technical ³
|
|
³ Documentation (2/4) Midnight Tree Bandit 1@8411 ³
|
|
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
|
|
³ IceNEWS Staff For December 1994 ³
|
|
³ ³
|
|
³ "...Winners of the 1994 WWIVcon Award for Electronic News" ³
|
|
³ ³
|
|
³ IceNEWS Publisher - Jim 1@1 ³
|
|
³ IceNEWS Editor-In-Chief - Will 1@6754 ³
|
|
³ ³
|
|
³ IceNEWS Contributing Editors ³
|
|
³ WWIV-Specific - Spotnick 1@5497 Lite Bytes - Ima Moron 1@9661 ³
|
|
³ Software - Music Man 1@9680 ³
|
|
³ ³
|
|
³ Editor-At-Large - Crave 1@7668 ³
|
|
³ IceNEWS Production - Help Wanted ³
|
|
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
|
|
³ IceNEWS is always seeking submissions from those who have ³
|
|
³ ideas for stories. If you have any ideas that you might ³
|
|
³ like to see published, contact any IceNEWS editor or ³
|
|
³ subscribe to IceNEWS Beat, subtype IceNEWS, host @1. ³
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
|
|
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ E D I T O R ' S D E S K ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³ The Upper Registers ³ by Will 1@6754
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
Welcome to IceNEWS! We have a shorter than usual issue for you
|
|
this month, but some neat information. Seafox tells you how you and the
|
|
other sysops in your area can get to WWIVcon cheap. East Bay Ray has
|
|
provided us with a sneak peek at the new version of WWIV for OS/2. We've
|
|
got the second installment of the WWIV Technical documentation. And for
|
|
all those who are considering starting up their own BBS, we've got the
|
|
REAL sysops guide..
|
|
|
|
We've also got a comprehensive look at the features in the new
|
|
version of OS/2, Warp. While the product is not perfect (nothing is), I
|
|
think that it has the potential to be an extremely important product.
|
|
Therefore, you can expect to see more information on OS/2 Warp and
|
|
related stories over the next year.
|
|
|
|
Happy Holidays to all, and we'll be back to a more conventional
|
|
format next month.
|
|
|
|
ÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄ
|
|
|
|
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ F E A T U R E S T O R I E S ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³ Getting to WWIVcon, Cheap! ³ by Seafox 1@2459
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
|
|
Everyone understands air travel on the most basic level. You buy a ticket,
|
|
you go up in the air, you come down, you leave the plane. However, the modern
|
|
airfare climate is such a twisted morass that only people who work in it, day
|
|
to day, have a glimmer of hope in understanding it.
|
|
|
|
As a Travel Agent, I see this all of the time. The rules are so convoluted
|
|
these days that only by being informed can you ever hope to get the cheapest
|
|
fare.
|
|
|
|
MY SYSOP WENT TO WWIVCON, AND ALL I GOT WAS THIS LOUSY GIF FILE
|
|
|
|
Lets talk about groups. A group, in Travel Industry parlance, is 10 or more
|
|
people, travelling on the same flights together. If a group has 21 people, that
|
|
21st person goes free. (A great way to reward the local server sysop....)
|
|
Groups require planning. The best way to plan a group is to have a person
|
|
designated as the group leader. From there, you determine how many people are
|
|
interested in going. Then, the group leader calls his local travel agent, and
|
|
gets the fare to the destination, as well as what airlines fly there from his
|
|
home airport. (Everything is airports. A group can consist of all of
|
|
Saskatechewan, as long as they all use the same airport to fly to the
|
|
convention.) From there, the Group leader contacts everyone and advises them of
|
|
the fare. Anyone who says "Outrageous! I could buy a Yak for that much money,"
|
|
or any similar sign of toxic cashflow shock, should probably be moved into the
|
|
maybe column. From there, you get a firmer count. Then, the fun starts.
|
|
Call the travel agent again, or use whatever arrangements the convention has
|
|
planned. (WWIVcon might be developing it's own meeting desk, if the particulars
|
|
can be worked out...) Then, inform the agent of your group size, as well as
|
|
preferred flight times and carriers. Make sure to ask which ones are non-stop.
|
|
It might be worth it to make a stop in St. Louis or Houston to fly TWA or
|
|
Continental, for instance. (And of course, with proper co-ordination, you can
|
|
pick up other groups at such points, thereby subjecting the flight attendants
|
|
to an ever growing hoard of BBS'ers.....) The travel agent will call the
|
|
airlines, and negotiate a rate for your group. Be sure to ask the travel agent
|
|
what the rate is on all of the carriers you're interested in, not just one or
|
|
two. Some agents get commission overrides on particular carriers, and they will
|
|
try to steer you towards certain carriers even though the cost may be higher.
|
|
From there, you will also get a deadline. Take this deadline very seriously.
|
|
Also, you will only be able to reduce your group by 20% and still keep the
|
|
negotiated rate.
|
|
|
|
Get on this today. As space fills up, and as we get closer to the date, it
|
|
will be harder and harder to get group space.
|
|
|
|
Now, what if you're one of those people who lives in a tiny WWIV community?
|
|
This is where the Convention/Meeting Rate kicks in.
|
|
|
|
The WWIVcon staff will be negotiating Convention rates with the major
|
|
carriers. This will definitely include United, Delta, and American Airlines,
|
|
and will also probably include a few of the smaller carriers as well. (If you
|
|
know of one you want to fly on, E-mail the WWIVcon staff) Convention rates are
|
|
a compliment to Group rates, but with a twist. Group rates require everyone to
|
|
be on the same flights. The convention rate provides a percentage discount to
|
|
all people flying to a certain convention point, as long as they book their
|
|
reservation using the convention code. The usual discount is 5% for coach
|
|
class tickets, and 10% for first class seats.
|
|
|
|
ACTUAL CONTENTS MAY VARY
|
|
|
|
There are several things that you need to make sure you get. First off, you
|
|
want seat assignments and boarding passes. This ensures you the kind of seat
|
|
you want, and also saves time because you don't have to go the counter at the
|
|
airport. However, there is one good reason to go to the counter-- Exit row
|
|
seats. On some carriers, Exit rows can be assigned beforehand, but the boarding
|
|
passes can't be issued. This is to ensure that the passenger meets the exit row
|
|
criteria implemented by the FCC- physically able to open the exit doors, as
|
|
well as willing to open them and assist people in evacuating the plane in an
|
|
emergency. Exit rows offer extra legroom. You want the seats facing forward, as
|
|
the seats facing backward do not recline. The row just in front of the rear
|
|
facing exit row also don't recline.
|
|
|
|
Ask about special meal options. They are usually catered in much smaller
|
|
quantities, and as a result, usually taste much better. This is extra important
|
|
if you have dietary needs. Low fat, low salt, kosher, hindu, vegetarian,
|
|
vegan, and moslem meals are all offered by most carriers, as well as options
|
|
for fruit plates, seafood meals, and a couple of other special meals.
|
|
Make sure you get the lowest fare in the market, and if at all possible, get
|
|
one that is refundable. If you are willing to do a connection, and can't take
|
|
advantage of convention or group rates, try to get a connection through Chicago
|
|
or Atlanta. These cities have become low fare meccas since the wave of cheaper
|
|
start-up carriers have hit the markets. Names to remember are MarkAir, Valujet,
|
|
Southwest Airlines, National Airlines, and Midway Airlines. Avoid Sunjet- they
|
|
frequently lose reservations and are often not on time.
|
|
|
|
Get a frequent flyer number on whatever carrier you plan to fly on. If you
|
|
are flying TWA, and you usually fly American, you can use your advantage number
|
|
on your flight. Frequent flyer numbers give you something for nothing, and
|
|
that's always a good deal.
|
|
|
|
IT'S LATE IN THE EVENING...
|
|
|
|
Now it's less than one month before WWIVcon. Everyone else who's going in
|
|
your home town (or more importantly, airport region,) has made their
|
|
plans. They're getting a group fare, and the local server sysop is getting to
|
|
fly free as thanks for all he does. Suddenly, you realize that you are, after
|
|
all, going to be able to make it. But you can't afford full coach, and there
|
|
are no fare wars going on. What to do?
|
|
|
|
You call Travel Bargains. If you're within 30 days but not within a week,
|
|
Travel Bargains can get you a low fare on TWA. They do not handle originations
|
|
in St. Louis. (They have a really stupid reason for this......) You will need a
|
|
credit card, or be willing to Fed Ex a check. Their fares are usually 60% of
|
|
TWA's KE14NR fare. Call TWA to get the rate for that fare, ask if it's
|
|
available in "T" class, and then call Travel Bargains. Their number is 1-800-
|
|
872-8385. And if you put it off for too long, you're gonna miss it, bud.....
|
|
|
|
BIG OL' JET AIRLINER
|
|
|
|
It *is* possible to get to WWIVcon economically. The key is planning. With
|
|
WWIVcon in Buffalo, a lot of people have shown concern that it'll be too
|
|
expensive. However, the WWIVcon Site Committee has decided that Buffalo has so
|
|
much to offer that it offsets the expense. If you can possibly make it, you owe
|
|
it to yourself to try.
|
|
|
|
If you're in a big WWIV community, volunteer to be a group leader. This will
|
|
mean more people from your area will make it, and someone might get to go free.
|
|
E-mail Jim (1@1.Icenet) and let him know you want to get 20 of your closest
|
|
friends at WWIVcon.
|
|
|
|
If you're in a smaller community, get involved in the WWIVcon sub.
|
|
And if you're in Buffalo, get ready, because a whole bunch of computer nerds
|
|
are about to descend on you and want a good time.
|
|
|
|
With the information in this article, you will be much better armed to deal
|
|
with the realities and possibilities of affordable air travel. Because it's
|
|
always easier to let someone else drive............
|
|
|
|
ÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄ
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³ WWIV for OS/2 Preview ³ by Easy Bay Ray 323@3050
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
|
|
[Introductory Note by IceNEWS EIC, Will 1@6754:
|
|
|
|
A few months ago, East Bay Ray, developer of the OS/2 version of
|
|
WWIV, sent us a question and answer sheet about the product. Ray's been
|
|
busy since, and we haven't been able to obtain more information. However,
|
|
I've decided to run this information in it's entirety in order to inform
|
|
the WWIV community of what's going on in this exciting area]
|
|
|
|
|
|
Guys - This is my preliminary Q&A for WWIV for OS/2. _PLEASE_ let me
|
|
know if you can think of any other questions you or another SysOp
|
|
might like to know the answer to...
|
|
|
|
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|
|
|
|
WWIV for OS/2 - A Preview
|
|
by Jeff Garzik (East Bay Ray #323@3050 WW4Net)
|
|
|
|
Since many of you have sent me questions via e-mail, I will attempt to
|
|
describe WWIV/2 in a Q&A format.
|
|
|
|
How is the WWIV/2 user interface different?
|
|
|
|
There is no difference.
|
|
|
|
|
|
How is the WWIV /2 SysOp interface different?
|
|
|
|
There is no difference.
|
|
|
|
|
|
How is the WWIV/2 setup different?
|
|
|
|
For new installations, the SysOp will go through the normal INIT.EXE
|
|
setup procedure, and then run INITOS2.EXE to complete the
|
|
installation. For upgrades, the SysOp will merely have to run
|
|
INITOS2.EXE.
|
|
|
|
|
|
I'm upgrading to WWIV/2 - will I lose my data?
|
|
|
|
Absolutely not. WWIV/2 data files are byte-for-byte compatible with
|
|
files created with WWIV for DOS.
|
|
|
|
|
|
Will I notice any change in response times over WWIV for DOS?
|
|
|
|
On lower end machines (386s) or machines with very little RAM
|
|
(4MB-6MB), there will be very little difference in the response times.
|
|
On other machines, there will be an increase in response times and
|
|
decrease in lost characters (for the higher speed modems).
|
|
|
|
|
|
What are the minimum requirements for running WWIV/2?
|
|
|
|
OS/2 version 2.1
|
|
Any 386, 486, or Pentium machine
|
|
4 megabytes of RAM
|
|
Any WWIV-supported modem
|
|
|
|
|
|
What are the recommended requirements for running WWIV/2?
|
|
|
|
OS/2 version 2.11 (that's OS/2 v2.1 with the CSD applied)
|
|
486 or Pentium machine
|
|
8 megabytes of RAM
|
|
Any WWIV-supported modem
|
|
|
|
|
|
Will WWIV/2 run my new super-fast 19.2k or 28.8k modem?
|
|
|
|
Yes, but you currently have to lock your port at 38400. The next
|
|
version of WWIV/2 will support any speed your serial card supports.
|
|
|
|
|
|
Will WWIV/2 run native OS/2 chains?
|
|
|
|
Yes. The C chain functions (inkey(), mpl(), onek(), etc.) provided by
|
|
WWIV will be available in the form of an OS/2 DLL.
|
|
|
|
|
|
Will WWIV/2 run my current MS-DOS chains (doors)?
|
|
|
|
Yes, but expect to take a resource hit. Running an MS-DOS program
|
|
requires a much greater amount of memory than a corresponding OS/2
|
|
program.
|
|
|
|
|
|
Will OS/2 versions of the network utilities become available?
|
|
|
|
This issue is up to Wayne, not me. I have bugged him several times,
|
|
but he doesn't want to give out the source to the network utilities.
|
|
What does that mean for you? The initial version of WWIV/2 will use
|
|
the DOS network utilities -- taking up a LOT of your precious RAM. If
|
|
you are running two nodes on the same OS/2 machine (or simply running
|
|
another application while WWIV/2 is doing network stuff), expect to
|
|
take a serious performance hit. Bug Wayne so that you, the SysOp,
|
|
will have decent OS/2 network utilities when WWIV/2 is released! ;-)
|
|
|
|
|
|
How much will this glorious product cost?
|
|
|
|
Ask Filo. I'm just a byte monkey. ;-)
|
|
|
|
|
|
Will shrink capability be available in WWIV/2?
|
|
|
|
No. There is no need. OS/2 does not have a foolish 640k barrier.
|
|
|
|
ÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄ
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ W W I V C H R O N I C L E S ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³Modifications For Dummies!³ by Spotnick 1@5497
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
If there is something that I dislike about the WWIV modifications, it's that
|
|
75% of them never works on the first time you install them. For some reason,
|
|
there is always a bug somewhere in the modification, and you wasted your time
|
|
installing them.
|
|
|
|
Well, I am one of those modification author that was writing modifications
|
|
that always needs a fix, because I was having problems to extract the mod from
|
|
inside WWIV and put it in a text file. Many other authors are regular to the
|
|
"D" revision of their modifications, and sometimes there is more...
|
|
|
|
To start being careful about that, I remember receiving a e-mail that made
|
|
me realize that it would be better for me to test them before posting anything,
|
|
that what I started to do then, and also asked for beta testers to check them
|
|
out before their release. It was great, but of course, there is NOTHING that
|
|
can stop an error from getting in there.
|
|
|
|
So to you, novice or intermediate modders, even those who are well
|
|
known to produce quality modifications, you should all follow those simple
|
|
rules:
|
|
|
|
þ Never release a modification before a rough test on your own system
|
|
for a specific period of time (1 Month is good).
|
|
|
|
þ Ask some people to test the modification for you before releasing it.
|
|
|
|
þ Install your modification on a virgin copy of WWIV before releasing
|
|
it. Follow your own text file and act if you were modding for the
|
|
first time.
|
|
|
|
þ Make your modification to fit the more possible with WWIV standards
|
|
functions, avoid the "you must have *.MOD installed to use this
|
|
modification" unless it is one of your own modification, or something
|
|
very popular. Because most of the time, people don't have that
|
|
installed and will have to look everywhere to find it before
|
|
installing your modification. A kind of pain that will reduce the
|
|
activity of your own modification.
|
|
|
|
|
|
If you follow those simple rules, you will have success in the WWIV world.
|
|
Because you will be known as a bug-free modifier and people will start
|
|
trusting you. Note that there is other things that you must follow, that is
|
|
why I decided to include this ethical code for WWIV modificators. This is
|
|
generally what most Sysop uses, but in case you didn't know, here it is:
|
|
I will take my own modifications group example to follow the ethical code:
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³ WWIV Modifications Ethical Code ³
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
|
|
|
|
The Header
|
|
ÍÍÍÍÍÍÍÍÍÍ
|
|
|
|
ÚÂÄÄÄ ÄÄ Ä Ä ÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄ ùù
|
|
³³ Alternative Worlds Presents ³
|
|
ÀÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³³ Mod Name ¯ ALTW-02A.MOD ³ù
|
|
³³ Difficulty ¯ ÛÛÛÛÛ±±±±±± (5/10) ³:
|
|
³³ WWIV Version ¯ 4.24 ³³
|
|
³³ Date Affected ¯ 10/24/94 ³³
|
|
:³ Files Affected ¯ BBS.C / MODEM.C / NETSUP.C / VARS.H / XINIT.C ³³
|
|
ù³ Description ¯ VGA Waiting For Caller Screen Status Screen ³³
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅ¿
|
|
³ A French Mod Division Release - (C) 1994 FutureSoft ³³
|
|
ùù ÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄ Ä Ä ÄÄ ÄÄÄÀÙ
|
|
|
|
|
|
þ Avoid too long header: Generally, most of the Sysops hate that. The example
|
|
has a fancy header, but it isn't too long, so you can see it in less than a
|
|
half screen. DO NOT PUT COLOR CODES IN THEM! This will be a pain when people
|
|
will see it in their text editor when doing the modifications.
|
|
|
|
þ Mod Name Line: Generally, you input the filename you wish, not more than
|
|
7 letters, and it should have the extension *.MOD and not
|
|
*.WWIVVERSION, because this cause many problems to SysOp that
|
|
collects modifications. You must use a name that is
|
|
specific to your alias or system name, to avoid
|
|
incompatibility with modifications below WWIV v4.22 where
|
|
there was no ethical code. You have to put a number also
|
|
to show that this is your xth modification, and put the
|
|
revision letter if it is a revision.
|
|
|
|
ALTW-02A.MOD
|
|
^^^^ ^ ^
|
|
|___|_|____________ ALTW, specific to Alternative Worlds
|
|
| |
|
|
|_|____________ 02, this is the 2nd modification
|
|
|
|
|
|____________ A, this is revision A.
|
|
|
|
If you follow this example, it will help you on your way to
|
|
hall of fame <grin>, because it will be easy to find your
|
|
modifications on a BBS that put mods in their directories.
|
|
Double check to be sure that nobody else uses your acronym.
|
|
|
|
þ Difficulty Line: Put yourself at the time you started modding, and think
|
|
of the difficulty your modification would be to install.
|
|
You can use a graphical meter: ÛÛÛÛÛ±±±±±
|
|
or put the numbers: (5/10)
|
|
This will help novice modders to ask for help to install
|
|
some modifications, or to be more careful than others.
|
|
|
|
þ WWIV Version Line: Tell on which version you installed the modification
|
|
and TESTED the modification. Do not include future
|
|
versions of WWIV unless you are sure that it is going
|
|
to work. We saw too many people tell "should work with
|
|
v4.23" and that were using "open/read/write" without
|
|
the multi-instance modifications needed that this is
|
|
very important. On the example, you see v4.24, well,
|
|
as a Beta site of WWIV, I can assure that this will
|
|
work with v4.24. I did a small mistake by not including
|
|
the Beta number (which is áeta 3). Do not include
|
|
previous versions of WWIV unless you tested it also,
|
|
a v4.23 modifications won't necessarily work under
|
|
v4.22, so then people using v4.22 will be aware that
|
|
it is possible that the modification won't work.
|
|
|
|
þ The Date Line: Very useful for system that produce mods collection, to put
|
|
your modification in the right collection. Also shows that
|
|
it is a repost if someone post your modification again.
|
|
|
|
þ The Files Affected Line: This is very important also, it should how many
|
|
files your modification will affect, and will warn
|
|
the person if it affects any of the major *.H that
|
|
need an entire compilation. It will also help
|
|
SysOp to think if they already modified that file
|
|
before reaching the last step of your modification
|
|
and finding out that they have a totally different
|
|
function instead of yours.
|
|
|
|
þ The Description Line: A very BRIEF description of what your modification
|
|
does, not more than ONE line, keep in mind that this
|
|
is what people will check first, so you need to have
|
|
a punch line there. If your punch line is interesting,
|
|
people will check the extended description section.
|
|
|
|
þ The Name Line: Include your handle or modification group name, to know
|
|
who did that modification.
|
|
|
|
þ The Copyright Line: Now that we know that modifications can be copyrighted,
|
|
but keep in mind that all WWIV code included is
|
|
copyrighted to WWIV Software Services, you have the
|
|
right to include your own copyright notice. I suggest
|
|
you put the disclaimer at the end of the file instead
|
|
of the top, because this generally bug people very much,
|
|
only if it is more than one line.
|
|
|
|
Introduction
|
|
ÍÍÍÍÍÍÍÍÍÍÍÍ
|
|
|
|
þ The Long Description: A verbose description of what your modification will
|
|
do, generally, it is better if you include a snap
|
|
shot of what it will look like also. You need to
|
|
describe each features of your modification. Include
|
|
also multi-taskers under which your modification has
|
|
been tested. This can be very useful. You should also
|
|
put the compiler name and version that you used to
|
|
do this modification. I already did modifications that
|
|
weren't working with older versions of Turbo C.
|
|
|
|
þ Requirements: Include anything that is needed to use your modification. If
|
|
you need another place, this is the place where you put the
|
|
name of this modification. Example:
|
|
|
|
Requirements for using this modification:
|
|
|
|
- VGA Graphic Card Or Better
|
|
- VGA Monitor or Better
|
|
- WWIV v4.23 or higher (tested on v4.24 Beta 3)
|
|
|
|
þ Thanks: This is where you give credit where it is due, generally it would
|
|
be a shame to forget Wayne Bell in those lines, since it is his
|
|
software you are modifying. Also put here the name of each and
|
|
every single person you might have steel code from. This is very
|
|
important, just like when you do a report, you have to include all
|
|
your sources.
|
|
|
|
þ Upgrading Information: If your modification is a revision, you need to
|
|
tell people that installed your modification, what
|
|
to do to upgrade from previous version, which steps
|
|
to proceed, etc... this is NEEDED in each mod that
|
|
you produce.
|
|
|
|
þ Legend: Include this because it might confuse some people if you produce
|
|
modifications that doesn't use the same standards. Example:
|
|
|
|
ÚÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸
|
|
³ = ³ Existing Line ³
|
|
³ + ³ Add this line ³
|
|
³ - ³ Remove this line ³
|
|
³ * ³ Modify this line ³
|
|
ÔÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÙ
|
|
|
|
Note also that some people use 1 space between the code, and some
|
|
doesn't. There is no standard for this, but it will be a good place
|
|
to put a note about it. This won't change a thing, but make the
|
|
source code more easy to see.
|
|
|
|
þ Warning Line: Do like most of modders, include a warning line even if you
|
|
have tested your modification. Tell people to do BACKUPS of
|
|
their source before installing your modification. This is
|
|
important.
|
|
|
|
Body Of The Modification
|
|
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
|
|
|
|
þ Steps: Separate your steps so it can be easily found. We use this standard:
|
|
|
|
ÄÄÄ[Step 1]ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
So we are sure that nobody will miss a step. Don't include more than
|
|
one operation in each step. Do not include modifications to more than
|
|
one function in each step. Put at least 2 existing lines, so people
|
|
can locate more easily. It is also VERY IMPORTANT that you don't put
|
|
color codes at the end of each lines (after the ';' code generally)
|
|
even if it makes your mod ugly at the display, because this causes
|
|
pain to everyone when they try to install your modification from
|
|
an extracted post.
|
|
|
|
|
|
|
|
The End Of File
|
|
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
|
|
|
|
þ Compiler Informations: Tell people if they need to do MAKE FCNS, if there
|
|
is a change to the makefile, please tell them under
|
|
which compiler you did this modification, and also
|
|
notice if they need to do a full or partial
|
|
compilation.
|
|
|
|
þ Informations Lines: Tell people where they can reach you, name of your
|
|
BBS, phone number and network address of the main
|
|
WWIV networks you are in. You don't have to include
|
|
local networks generally, but you can do that too.
|
|
If you have a sub about your modifications, leave a
|
|
note here for people to know how to get support from
|
|
you. If you don't plan to do support, it is the place
|
|
to tell that, because you should generally get mail
|
|
from the modifications you did.
|
|
|
|
And you are done, following all those steps should end with a clear text file,
|
|
ready to post on the modification subs all around. If you upload your mod to
|
|
a system, please include in the archive a FILE_ID.DIZ or DESC.SDI inside it,
|
|
with your description. Here is the example we use in French Mod Division:
|
|
|
|
Shut-Down System For WWIV
|
|
|
|
Mod Name : ALTW-27.MOD
|
|
Difficulty ¯ Û±±±±±±±±±
|
|
WWIV Version ¯ 4.23/v4.24
|
|
Date Affected ¯ 10/25/94
|
|
|
|
A French Mod Division Release..
|
|
|
|
So people will see that when they download or list the files. Be sure that
|
|
the first line is the description, because stock WWIV version with file
|
|
tagging doesn't allow to show more than 1 line, so this is the important line.
|
|
|
|
If you post the modification, there is also an ethical code for the title you
|
|
use. I already tried to have people do it another way, and I got tons of
|
|
replies to keep it the way it is. PLEASE do that, it is very important, else
|
|
your modification may suffer from that, because it is needed for SysOps that
|
|
extract modifications do their xfer area:
|
|
|
|
Title: FILENAME.MOD: Breif Description Of Your Modification.
|
|
|
|
Once this is done, then everything should be perfect. Again, this is a
|
|
standard. You might not conform to it, but this is what should help people to
|
|
follow a code that will help the WWIV community.
|
|
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ S O F T W A R E / P R O G R A M M I N G ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³ IBM OS/2 Warp v3 ³ by Will 1@6754
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
With the release of the new version of OS/2, now officially known
|
|
as Warp, IBM has brought Operating System/2 to a new level. Warp features
|
|
enhancements and performance increases in virtually every area, with added
|
|
performance, usability features, and bonus applications. While it's
|
|
dangerous to compare Warp to an as yet unreleased product (Windows 95),
|
|
it's probably safe to say that Warp is a match for any Operating System
|
|
product that will be made available in the next year. I should note that I
|
|
made these installations over Windows for Workgroups 3.11, starting from
|
|
scratch. The current version of Warp is not designed to install over OS/2
|
|
2.1 systems.
|
|
|
|
The most noticeable enhancement to the product is that it's much
|
|
leaner in terms of memory requirements. Warp takes as much disk space as
|
|
before, but it will now successfully run (although not blazingly fast, but
|
|
tolerably so) in four megabytes of RAM. In fact, this article is being
|
|
written on a 486sx-33 laptop with four megabytes RAM running Warp, and
|
|
while there's a lot of disk swapping, it's really just as usable as
|
|
Windows for Workgroups on the same machine. Overall execution speed has
|
|
been improved (although with the additional features in the release version,
|
|
Warp does execute slightly slower than the first Beta). In tests, Warp
|
|
executed Win16 applications considerably faster than Windows NT 3.5, and
|
|
only slightly slower than Windows For Workgroups 3.11 (in fact, the difference
|
|
was not noticeable in virtually every case, except for a slight delay at
|
|
the beginning where OS/2 loads the Windows code into memory).
|
|
|
|
Device support has been greatly increased, as well. Warp comes
|
|
with a much larger variety of sound, video, SCSI, and CD-ROM drivers than OS/2
|
|
2.x. Earlier versions came with a large amount of printer drivers, and
|
|
that number has been increased as well. Warp now ships with drivers for
|
|
most Sound Card-CDROM combinations, something else that was lacking in
|
|
2.x. It should be noted that OS/2 now supports more devices right out of
|
|
the box than Windows 3.x or Windows NT, and supports many newer pieces of
|
|
hardware to boot.
|
|
|
|
The installer has been greatly improved. It now does a much better
|
|
job of auto-recognizing hardware than before. On both my systems, it
|
|
correctly identified all the hardware (it picked the wrong NEC CD-ROM
|
|
drive, but the driver it installed functioned fine) installed. Again, some
|
|
of it (such as the SCSI card) was not supported directly under 2.1. There
|
|
is also a "One Button Install" option for novice users, which will make
|
|
all the decisions for you, and then just prompt you for disks. When I
|
|
tried this, it worked fine. Multimedia install, once a seperate process,
|
|
has been integrated into the main installer, althouh some of the extra
|
|
multimedia programs (such as the Media Viewer) are installed separately as
|
|
part of the BonusPack.
|
|
|
|
The desktop has three main new features, once installed. Most
|
|
obviously, the desktop default color has been altered to teal (which,
|
|
while it may sound terrible, is actually a wonderful color for the
|
|
purpose, and I haven't bothered to change it to anything else), and all
|
|
the icons have been redone in a 3d style. This lends Warp a much more
|
|
modern look than pervious versions. A floating Launchbar has been added to
|
|
the bottom of the screen. It holds shadows of various objects (by default,
|
|
the shredder, A: drive, and some others), which you launch with one click.
|
|
You can also create drawers to hold additional objects. My Internet
|
|
drawer, for instance, has the SL/IP dialer visible on the Launchbar, and
|
|
the rest of my Internet utilities in the drawer. To see the rest of the
|
|
icons, I click on the handle and the drawer comes out. Click again to
|
|
retract it. The drawers can be dragged to any portion of the screen, to
|
|
boot. The last obvious change is on the pull-out menus that you access by
|
|
right clicking an object. The settings selection, which was previously a
|
|
submenu under the "Open" heading, now has it's own place on the main
|
|
menu. This makes training and use much easier.
|
|
|
|
Multimedia support in Warp has been greatly enhanced. The digital
|
|
video module now supports more varieties of .AVI file, and also plays
|
|
digital video files in .FLI and .MPG (MPEG) formats. A "Media Viewer" is
|
|
included in the BonusPack (see below) which acts as a light table for
|
|
multimedia files. This works by dragging image files (GIF, TIFF, PCX, etc)
|
|
into the window, where OS/2 then generates a thumbnail image. It also
|
|
provides "click here" icons for video and sound files. This worked well,
|
|
and produced accurate thumbnail representations of the images. The only
|
|
problem was when I dragged a large (over 1024x768) file onto the display.
|
|
The system slowed almost to unusability as the Viewer attempted to
|
|
generate a thumbnail. After five minutes, I rebooted.
|
|
|
|
As we've seen, Warp also includes drivers for many more sound
|
|
cards (including some relatively obscure ones) than it did previously. You
|
|
also get a stripped down copy of Person-to-Person, IBM's groupware
|
|
offering. An almost totally new set of sound files are included, as well
|
|
as several MIDI music files, including a nice jazz riff that plays during
|
|
the BonusPack installation.
|
|
|
|
Warp now includes a complete set of external applications in the
|
|
new "BonusPack". IBM Works (originally a popular stand alone integrated
|
|
package for OS/2) includes a spreadsheet, database, word processor, and
|
|
charting module. These are not "applets" like those packaged with Windows
|
|
3.1 or Windows NT - they're full strength applications, with features like
|
|
a spell checker, mail merge, and full DDE links between them. At the
|
|
product launching, one IBM representative said that the programs were
|
|
being included to demonstrate the usefulness of real 32bit OS/2
|
|
applications. They do a good job. The OLE/DDE features, perhaps the best
|
|
integrated, are fast and seamless. For example, you simply grab a chart in
|
|
the charting module with the mouse, and drag it into a word processor
|
|
document. It's instantly transferred. The is a sharp contrast with Windows
|
|
3.1 OLE, where, when this is possible at all, the transfer can take
|
|
several seconds to minutes. The integrated applications make OS/2 a one
|
|
shop software shop, as the programs are of a higher quality than those
|
|
found in some standalone integrated packages (such as Microsoft Works).
|
|
|
|
The BonusPack also includes several other applications, including
|
|
a "Lite" version of HyperAccess Communications for OS/2, FaxWorks/PM, a
|
|
system information tool, and the IBM Internet Connection. This last is
|
|
perhaps the most impressive. It essentially consists of a slightly
|
|
stripped down version of IBM TCP/IP 2.0 (providing SL/IP line
|
|
connectivity), and a set of clients. You can connect via SLIP to the IBM
|
|
provider (Advantis) or to a local provider. I took this opportunity to
|
|
setup a SLIP connect with a local vendor (The Internet Access Company of
|
|
Bedford, Mass), and it worked great. The included Internet clients range
|
|
from adequate to excellent. The Newsreader and Gopher clients are fine.
|
|
The FTP client was usable, although I decided to use a Windows based one
|
|
instead. Ultimedia Mail/2 Lite has some nice features, but was difficult
|
|
to configure and had some rough edges (for instance, no word wrap). While
|
|
it also possessed some excellent features, I decided to use Eudora (a
|
|
popular Windows based mailreader) instead.
|
|
|
|
Web Explorer/2, the World Wide Web/Mosaic client, isn't shipped
|
|
with the package. Instead, once you have Warp installed, you use the
|
|
"Retrieve Software Updates" program and download the latest Beta. This
|
|
worked well when I was first installing the package, and is how I obtained
|
|
Beta .91. When .92 was released (on November 23rd), this option gave me an
|
|
"Unable to resolve address" error, and I had to FTP the package instead. I
|
|
can only assume that this is a problem at the IBM server. The client
|
|
itself, however, is excellent. I'd been using Mosaic Netscape, and WE/2
|
|
matches it in terms of features, and surpasses it in terms of reliability. I
|
|
wasn't able to find one HTML document it couldn't handle. It runs quickly,
|
|
and supports Forms better than Netscape. It does a great job of printing
|
|
the pages as well. The WebMap (which allows you to move back to any spot
|
|
you visited previously) is wonderful. The only thing that isn't supported
|
|
(that I could find) was mailto: links, which allow you to click and send
|
|
mail. In .91, these weren't recognized, but in .92 I got an error message
|
|
saying that they weren't currently supported, so we can assume that it
|
|
will be added before the program is finished. It also takes advantage of OS/2's
|
|
threading and object-orientation features, allowing, among other things, you
|
|
to drag a .GIF file out of the program and onto your hard disk.
|
|
|
|
The one thing the Internet Connection lacks is an IRC client, but
|
|
I found a relatively good (text mode) IRC/2 client that works quite well.
|
|
The Internet Connection software contains a shell Windows Sockets DLL,
|
|
which allows you to use any standard Windows based client. The DLL is very
|
|
fast and reliable. On the whole, the software causes me much less trouble
|
|
than similar Windows based programs, and runs faster.
|
|
|
|
With it's enhanced speed and usability, not to mention bonus
|
|
applications, Warp is an excellent product. While I hate to come out this
|
|
much in favor of a product, I really can't help myself in this case. IBM
|
|
has been promising a better Windows than Windows for quite some time (it's
|
|
been a better DOS than DOS for years), and they've finally delivered. The
|
|
one sore spot is applications, which is being quickly rectified, by the
|
|
inclusion of excellent apps within the OS package itself, and an increase
|
|
in development by third parties (Borland, for instance, is porting their
|
|
Object Windows libraries to OS/2. When this is completed, we can expect a
|
|
flood of OS/2 versions of current software). Warp has the potential to
|
|
catch on, and it should - it's shameful that people should have to make do
|
|
with DOS and a shell.
|
|
|
|
Additional flavors of Warp will be released late this year and
|
|
early 1995. These include a version featuring peer to peer networking
|
|
(which, according to IBM, will be compatible with Windows for Workgroups
|
|
(NETBEUI) networks, as well as Novell and other platforms), and versions
|
|
including IBM's optimized WIN-OS2 code. There will also be a new version
|
|
supporting Symmetric Multiproccessing, in the first half of 1995 (OS/2 2.1 for
|
|
SMP is available now).
|
|
|
|
ÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄ
|
|
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ L I T E B Y T E S ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³ The REAL Sysops Guide ³ By Aldo Cella 654@7654
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
|
|
So, you want to run a BBS, do you? Got it all planned out, eh? Well,
|
|
before you start anything at all, there are a few things you ought to
|
|
remember. It seems that lately, with all the boards, AE's, and CF's going up
|
|
everywhere, quite a few sysops have forgotten or completely ignored the
|
|
unwritten code established by those early pioneering spirits of the good ol'
|
|
days. You see, no matter what hardware you use, no matter how much storage,
|
|
how fast a modem, or what software you want to run, the success or failure of
|
|
your system ultimately depends on YOU. The remainder of this file consists
|
|
not of countless obscure details on how to run your system, but of a few
|
|
short hints which should prove helpful at times. Remember, REAL sysops know
|
|
the difference between constructive criticism and insults.
|
|
|
|
* ACCESS -
|
|
One of the most frustrating things that can happen to a new user is to
|
|
log onto your board after being validated by you, only to find out that he
|
|
still doesn't have access to 80% of your system. REAL Sysops make plenty of
|
|
their system available to the average, non-privileged user.
|
|
|
|
** Corollary:
|
|
You'll always have more average users than privileged ones.
|
|
|
|
* SUBSCRIPTION FEES -
|
|
If you plan to charge a subscription fee of any kind for your system,
|
|
MAKE SURE that it's worth the money to have an account on your system! REAL
|
|
Sysops who charge subscription fees realize that their system is now a
|
|
business.
|
|
|
|
* SUBSCRIPTION FEES II -
|
|
If you are going to charge a subscription fee, MAKE SURE that you VERY
|
|
CLEARLY define exactly what it is about your system that the user is having
|
|
to pay for. REAL Sysops who charge subscription fees check out all the
|
|
legalities FIRST.
|
|
|
|
* SUBSCRIPTION FEES III -
|
|
If your system happens to have an AE, Catfur, etc., or happens to have
|
|
any phreak/hack info anywhere on it, DO NOT CHARGE ANY FEES! REAL Sysops may
|
|
take a chance here and there, but they aren't idiots.
|
|
|
|
* ADVERTISING -
|
|
Getting publicity for your system must be done carefully. Most likely,
|
|
people's first impression of your board is going to be determined by the
|
|
first few lines of your ad, so post your ad carefully. REAL Sysops understand
|
|
this, and will not sound like a used car salesman when advertising their
|
|
board.
|
|
|
|
** Corollary:
|
|
REAL Sysops know that arrogant ads will attract only arrogant users.
|
|
|
|
* ADVERTISING II -
|
|
Be decent about how you put your ad on someone's board. Make it short
|
|
and to the point, and leave it in a section which you know is read frequently
|
|
(i.e., the public board). REAL Sysops know that redundancy will irritate
|
|
intelligent people.
|
|
|
|
* SECURITY -
|
|
If possible, make every possible test of your security before you put
|
|
your system up. It is best to do most of these tests both while logged in at
|
|
the board, and again from over the phone. It also can't hurt to have other
|
|
people try to crash your system during the testing. REAL Sysops are very
|
|
thorough about this, and sleep much better because of it.
|
|
|
|
** Corollary:
|
|
Time spent perfecting your input routines is more wisely used than time
|
|
spent re-constructing your userfile after it's been blown away.
|
|
|
|
* SECURITY II -
|
|
Once your done testing, and you know your system is solid, don't make a
|
|
big deal out of it. Talking about security all the time will make users think
|
|
you're paranoid, and hackers think you're challenging them. REAL Sysops know
|
|
that discretion is as important as prevention.
|
|
|
|
** Corollary:
|
|
REAL USERS rarely ever ask a sysop about his system's security.
|
|
|
|
* VALIDATION -
|
|
Always validate within 24 hours if you can. Little is more frustrating
|
|
for a user than to log onto your board after a week has gone by, and find out
|
|
he still isn't valid. REAL Sysops always validate quickly, as it always helps
|
|
with public image.
|
|
|
|
* VALIDATION II -
|
|
NEVER, at any time, ask new users to answer why they should be given an
|
|
account on your system. REAL Sysops know that the only people who could
|
|
answer that question impressively don't even NEED to be calling your system.
|
|
|
|
** Corollary:
|
|
You can't build an ELITE board by treating users like spinach in a
|
|
strainer.
|
|
|
|
* RESTRICTED BOARDS -
|
|
If you are going to have restricted areas on your system, it's best to
|
|
make them invisible to those who can't access them. REAL Sysops would rather
|
|
do this than answer 10000000 feedback messages from users asking for access
|
|
to your restricted areas.
|
|
|
|
* ABUSERS -
|
|
From time to time, or perhaps more frequently, you'll end up having to
|
|
deal with some jerk who is making trouble on your board. REAL Sysops handle
|
|
these people swiftly and quietly before they get out of hand.
|
|
|
|
** Corollary:
|
|
REAL Sysops will only warn abusers ONCE.
|
|
|
|
* ABUSERS II -
|
|
At times, the jerk that you really want to grind into the dust hasn't
|
|
really done anything serious yet - maybe just sent you some rude complaints.
|
|
In this case, it's better not to lose your cool. REAL Sysops know that
|
|
trading insults with an idiot makes you look worse than he does.
|
|
|
|
** Corollary:
|
|
REAL Sysops never drag private matters out in front of the public eye.
|
|
|
|
* CRASHERS -
|
|
It is very likely that the day you first advertise your board, you'll
|
|
probably get a couple of attempts at crashing your system. These crashers are
|
|
doing it just for the thrill, and are counting on the fact that the security
|
|
of new systems is generally poor. REAL Sysops will have taken this into
|
|
account, and will have little to worry about.
|
|
|
|
* HACKERS -
|
|
You probably won't encounter any real hackers unless you charge a
|
|
subscription fee for your system. These people are usually more determined
|
|
than the above crashers, and are out to get someone's account on your system,
|
|
preferably one with high access. Preferably YOURS. REAL Sysops deal with
|
|
these people carefully and try not to make enemies of them.
|
|
|
|
** Corollary:
|
|
REAL Sysops know the difference between a REAL Hacker and a 12-year old
|
|
WARGAMES fanatic with an acoustic coupler.
|
|
|
|
* NOVICES -
|
|
From time to time, you'll also most likely run across people on your
|
|
board who are very new to telecommunications, and will ask very dumb
|
|
questions. REAL Sysops remember what it's like to be "unenlightened", and
|
|
will not snap out rude answers at these people.
|
|
|
|
* ADEPTS -
|
|
Eventually, you may also run into a few people who are so advanced,
|
|
it'll blow your mind. REAL Sysops know just what to do upon discovering one
|
|
of these users - QUESTION HIM! Get him to talk to you, and find out what he
|
|
knows and how it can help you.
|
|
|
|
** Corollary:
|
|
There's a difference between being inquisitive and being a pest.
|
|
** 2nd Corollary:
|
|
REAL ADEPTS don't hoard their knowledge.
|
|
|
|
* PUBLIC RELATIONS -
|
|
Many systems suffer from having a sysop who never chats with users, and
|
|
answers feedback rarely at best. REAL Sysops keep in touch with their
|
|
callers, and are respected for it.
|
|
|
|
* CUSTOMIZING YOUR SYSTEM
|
|
Adding modifications to your system is mandatory if you expect it to be
|
|
unique, and can be one of the main factors in its success. It can also be the
|
|
primary instrument of its destruction. REAL Sysops know this, and usually
|
|
follow some variation of the following rules. Follow these steps, and you'll
|
|
rarely ever have to worry about any mods you add to your board:
|
|
|
|
A. Pull an idea for a mod out of your imagination.
|
|
B. Consider how you would go about adding it to your board.
|
|
C. Try adding it in that way to a BACKUP COPY of your system.
|
|
D. Test it to see if it works. If not, you added it wrong. Back to B.
|
|
E. Test the mod to make sure it can't be used to crash your system.
|
|
F. Test the rest of your system to make sure it's still solid.
|
|
|
|
This completes the REAL Sysop's Guide. On a final note, you won't ever
|
|
have trouble recognizing a REAL Sysop. Just listen to everyone talk about a
|
|
board they really like sometime. There's probably a REAL Sysop running it.
|
|
|
|
ÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄ
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³ Silly Strings ³ by Ima Moron 1@9661
|
|
³ From Icenet Sysops Everywhere ³ Lite Bytes Editor
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
From: Morgoth #2@10408 WWIVNet
|
|
Home In Nome on my modem by the Bearing Sea!
|
|
|
|
From: Sam #1@4051 WWIVNet
|
|
MacIntosh: Computer with training wheels you can't remove.
|
|
|
|
From: The Zoo Keeper #1@20762 WWIVNet
|
|
If the answer isn't right, the question must be wrong!
|
|
|
|
From: "Adam Selene" Rodent #221@3 WWIVNet
|
|
Good...Bad...I'm the guy with the gun.
|
|
|
|
From: Octavious #1@8357 Icenet
|
|
Never put off till' tomorrow what you can avoid all together.
|
|
|
|
From: Aaron Pathfinder #18@2491 WWIVNet
|
|
Those that beat their swords into plow shares, will plow for those who don't
|
|
|
|
From: Indiana Jones #174@15131 WWIVNet
|
|
...Your tagline has been assimilated. -- The Collective
|
|
|
|
From: Pandora #424@9661 Icenet
|
|
Pandora....open my box if you can!!!
|
|
|
|
From: Jim Lilly #74@1294 WWIVNet
|
|
Worry is a dark room for developing negatives....
|
|
|
|
From: Papa Bear 1@11579 WWIVNet
|
|
(A)bort, (R)etry, (I)nfluence with a large hammer.
|
|
|
|
ÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄ
|
|
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³ WWIVnet Technical Docs ³ by Midnight Tree Bandit 1@8411
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
|
|
|
|
|
|
[IceNEWS Serialization Note - This is part two of four. Internal page numbers
|
|
have been retained for ease of reference. Page breaks, however, have been
|
|
removed.]
|
|
|
|
IV. MESSAGE PACKETS
|
|
|
|
The most important component of any network is the mail file, which
|
|
contains all the public posts, email, and network information which
|
|
makes the BBS network what it is. WWIVnet mail files consist of a
|
|
series of mail packets, each with its own header segment describing
|
|
the type and size of the packet.
|
|
|
|
There are two types of mail files in WWIVnet, each similar but
|
|
processed differently. The netmail file is the file received from
|
|
another system, and contains packets destined for that system as well
|
|
as other systems in the network (if the BBS has more than one
|
|
connect). Netmail files may be compressed, using the PKWare compres-
|
|
sion libraries. The local mail file contains the packets from the
|
|
netmail file which are destined for the BBS only.
|
|
|
|
A. Message Header
|
|
|
|
Each message sent through the network has a header. The header
|
|
tells which user/system originated the message, where it is to be
|
|
sent to, the type of message, and other information. The
|
|
structure of the header is:
|
|
|
|
typedef struct {
|
|
unsigned short tosys,
|
|
touser,
|
|
fromsys,
|
|
fromuser;
|
|
unsigned short main_type,
|
|
minor_type;
|
|
unsigned short list_len;
|
|
unsigned long daten;
|
|
unsigned long length;
|
|
unsigned short method;
|
|
} net_header_rec;
|
|
|
|
Each header is 24 bytes long. The fields, in detail, are:
|
|
|
|
tosys, touser
|
|
The destination of this message (system number and user
|
|
number, if applicable). The touser field will be zero in
|
|
all cases except for email (main_type==2) and SSMs
|
|
(main_type==15).
|
|
|
|
fromsys, fromuser
|
|
The origin of the message (system number and user number).
|
|
This contains the user number/system number combination of
|
|
who actually wrote the message. If the message is "gated"
|
|
(that is, a sub post from a system on a different network,
|
|
or email from a user in another network), 'fromuser' will be
|
|
zero.
|
|
|
|
main_type, minor_type
|
|
The type of message this is. The main type stores the
|
|
actual type (email, post), and the minor_type is used to
|
|
specify what sub-type it is. For example, the main_type for
|
|
a post is 3. The minor_type is then used to specify what
|
|
type of post it is, what subboard the post is to go on to.
|
|
A list of main and minor types is found in section IV(D),
|
|
below.
|
|
|
|
daten
|
|
The time the message was sent, stored in unix time, as the
|
|
number of seconds since Jan 1, 1970.
|
|
|
|
length
|
|
The length of the message. This includes any information
|
|
between the packet header and the message itself, such as
|
|
the sender's name, message title, and so forth. Note that
|
|
the length does not include the node list indicated by
|
|
list_len.
|
|
|
|
method
|
|
If the file is encrypted, compressed, or source-verified,
|
|
this describes the type of compression or encryption used.
|
|
This will tell NETWORK2 (or other local mail tosser) which
|
|
DEmmm.EXE to execute. DEmmm.EXE is explained in more detail
|
|
in the next section, below.
|
|
|
|
list_len
|
|
Some messages need to go to more than one system. For
|
|
example, networked posts may go to over 20 different
|
|
systems. It makes no sense to have a separate copy of the
|
|
message for each destination system, so the same copy of the
|
|
header and message is used. (This is referred to as
|
|
"stacking" the message). The list_len specifies the number
|
|
of destination systems listed. If list_len is non-zero,
|
|
then the touser and tosys fields are ignored. The list_len
|
|
is not used for e-mail to a user (main_type is 2 or 7).
|
|
|
|
When a message has only one destination system, the destina-
|
|
tion system is stored in tosys, and list_len is zero. If
|
|
there are two or more destinations, then tosys is 0, and
|
|
list_len holds the number of destination systems.
|
|
|
|
When list_len is non-zero, the list of destination systems
|
|
is stored immediately after the header, but before the
|
|
actual message itself. The length of the list is not
|
|
included in the length field in the header; the length
|
|
stored in the header is the length of the message only.
|
|
|
|
Each entry in the destination system list is two bytes long,
|
|
and is stored in the standard byte-reversed format of 80x86
|
|
chips.
|
|
|
|
For example, if a post is destined to system 1, the tosys
|
|
field will be 1, and list_len will be 0. If the post is
|
|
destined to systems 1 and 2, tosys will be 0, list_len will
|
|
be 2, and there will be 4 bytes between the header and
|
|
message. The bytes will be: 01 00 02 00 (remember,
|
|
byte-reversed format). The rest of the header will be the
|
|
same for both messages.
|
|
|
|
A packet thus consists of a net header, a destination list (if
|
|
any), and the text of the message. The length of a full message
|
|
packet is thus:
|
|
24 + 2*list_len + msg_length.
|
|
|
|
The message text (the part following the header) for a post or
|
|
email begins with information intended for the message header
|
|
shown when the message is displayed. Each piece of information
|
|
is followed by a carriage return and line feed (cr/lf) character
|
|
to separate it from the next except for the message title, which
|
|
is followed by a NUL character. For most posts and email, that
|
|
information is:
|
|
|
|
Message Title Whatever title the user gave to the post.
|
|
|
|
Sender name usually the name and number of the user who wrote
|
|
the message with the system number, in whatever
|
|
format the sending BBS uses.
|
|
|
|
Date string Formatted date the post was written, in whatever
|
|
format the BBS uses.
|
|
|
|
So the message header format for most posts and email would be
|
|
TITLE<nul>SENDER_NAME<cr/lf>DATE_STRING<cr/lf>MESSAGE_TEXT. Some
|
|
main_types have other information, as noted in the main_type
|
|
descriptions in section IV(D).
|
|
|
|
|
|
B. Mail File Processing
|
|
|
|
A WWIVnet file is simply several packets appended into one file.
|
|
Starting with NET25, the WWIVnet software supports compression of
|
|
the netmail files to help save on connection time in long
|
|
distance connections, using the PKWare Compression Libraries.
|
|
These files have a slightly different format from uncompressed
|
|
files, but the most important issue at this point is that the
|
|
first long int of a compressed file has the value 0xFFFEFFFE. If
|
|
you purchase the compression libraries from PKWare, details
|
|
covering compressed packets are found in Appendix A. Otherwise,
|
|
anyone using WWIVnet compatible software should be advised to
|
|
make sure their connect only sends them uncompressed files, and
|
|
the software should be able to detect and reject compressed
|
|
packets before attempting to process them. Since there is
|
|
nothing in the data exchange described above to warn that an
|
|
incoming packet is compressed, there is no way to detect and
|
|
prevent transfer of a compressed mail file.
|
|
|
|
Once it has been received and (if necessary) uncompressed, the
|
|
mail file should be processed following these steps:
|
|
|
|
1. Open the file, and set the current message pointer to the
|
|
beginning of the file.
|
|
|
|
2. Read in the net header (24 bytes).
|
|
|
|
3. If list_len is non-zero, read in the list following the
|
|
header (2 * list_len bytes).
|
|
|
|
4. Read in the message itself (length bytes).
|
|
|
|
5. Process the message.
|
|
|
|
6. If not the end of file, go to step 2.
|
|
|
|
To ensure the integrity of the mail file, an initial pass over it
|
|
should be done. This pass would step through each packet in the
|
|
file, reading each header and making sure no packets are
|
|
truncated. If the file ends in the middle of a packet, then it
|
|
is obviously corrupted and cannot be processed properly. At this
|
|
point, either throw away the whole file or remove the truncated
|
|
packet and process the remaining packets.
|
|
|
|
During the packet tossing, each packet needs to be marked as
|
|
processed. Thus, if analysis is interrupted before completion,
|
|
the packet analyzer can skip over those packets already processed
|
|
when run again. To mark the packet as already processed (or
|
|
deleted), set the main_type to 65535. Any packet with a
|
|
main_type of 65535 should therefore not be processed.
|
|
|
|
The analyzer should follow these steps when processing each
|
|
packet:
|
|
|
|
1. If main_type is 65535 (deleted), skip the message.
|
|
|
|
2. If list_len is non-zero, do steps 3-6 for each entry in the
|
|
list, substituting that entry for "tosys"
|
|
|
|
3. If tosys is this system, process the file locally (in the
|
|
case of NETWORK1.EXE, the message is copied to LOCAL.NET for
|
|
processing by the local packet processor).
|
|
|
|
4. If tosys is an unknown system or unreachable, put the packet
|
|
in the dead mail file.
|
|
|
|
5. If the next system to forward the packet to ("next hop") is
|
|
the system that the message was last received from, put the
|
|
packet in the dead mail file. This prevents messages from
|
|
looping
|
|
|
|
6. If the tosys is okay, put the packet into the file that is
|
|
to be sent to the next hop.
|
|
|
|
Of course, it is more complicated than that. If list_len is
|
|
non-zero, all destination systems should be processed before the
|
|
message is stored anywhere. This way, if the message has 10
|
|
destinations, each of which has the same next hop, only one copy
|
|
of the message will be printed out, that packet with 10 systems
|
|
in its destination list. Likewise, for a system with more than
|
|
one connection, if a message has 4 destination systems going
|
|
through one next hop and 3 going through another, one copy of the
|
|
message will go into each hop's file -- one with four systems in
|
|
the node list, the other with the remaining three.
|
|
|
|
The dead mail file is reprocessed whenever a network update (new
|
|
BBSlist or connection list) is received.
|
|
|
|
|
|
C. Local Mail Processing and DEmmm.EXE
|
|
|
|
Processing of local mail packets should be similar to processing
|
|
of incoming netmail packets. The main difference between netmail
|
|
tossing and local mail tossing is that the main and minor types
|
|
are ignored during netmail processing, and the list_len and node
|
|
list are ignored (since there won't be a list on local mail).
|
|
|
|
1. Open the file, and set the current message pointer to the
|
|
beginning of the file.
|
|
|
|
2. Read in the net header (24 bytes).
|
|
|
|
3. Read in the message itself (length bytes).
|
|
|
|
4. Process the message. This is done according to the
|
|
main_type and (if applicable) minor_type of the message.
|
|
|
|
5. If not the end of file, go to step 2.
|
|
|
|
A few main_types (noted below) cause return messages to be
|
|
generated to go back out to other systems. The local mail file
|
|
analyzer should place these into an interim mail file that will
|
|
be processed by the netmail file analyzer after local mail
|
|
processing has been completed. The WWIVnet local mail analyzer
|
|
(NETWORK2.EXE) puts these messages into P1.001 or P2.001. Then
|
|
NETWORK1.EXE analyzes this file and places them into outgoing
|
|
netmail files for the system's connections.
|
|
|
|
Some types of messages that contain network related files such as
|
|
updates to the nodelists and connect lists and email to all
|
|
sysops from the NC or GC. For the sake of network security,
|
|
these messages have a source-verification signature at the
|
|
beginning (using, for example, RSA or a similar algorithm).
|
|
There are several "methods" used to handle these messages, and
|
|
each requires a decryption program, or DEmmm.EXE (where "mmm" is
|
|
the encryption method, as listed in the 'method. field of the net
|
|
header). These DEmmm.EXE files MUST be supplied by the NC or GC
|
|
of each network, and each network's DEmmm.EXE are unique to that
|
|
network. That is, WWIVnet's DE1.EXE will not handle method 1
|
|
messages from WWIVLink, nor vice versa.
|
|
|
|
When a message is encountered with 'method!=0', the following
|
|
steps are taken:
|
|
|
|
1. The local packet analyzer writes out the text of the message
|
|
(no header or node list) to a temporary file (TEMPDE.XXX) in
|
|
the data directory for the relevant network.
|
|
|
|
2. A command line for calling the appropriate DEmmm.EXE is
|
|
created using the C command "sprintf(cmd, "de%u
|
|
%s/tempde.xxx", nh.method, net_data);" ('nh' is a structure
|
|
of type net_header_record, 'net_data' is the network data
|
|
directory). The command is then executed.
|
|
|
|
3. The DEmmm.EXE program is then responsible for reading the
|
|
TEMPDE.XXX in from disk, deleting it, then attempting to
|
|
decode it. Two things can then happen:
|
|
a. If the TEMPDE.XXX fails decoding (bad CRC), DEmmm.EXE
|
|
just exits (returning to the local packet analyzer).
|
|
If the analyzer finds the TEMPDE.XXX file does not
|
|
exist, the message is deleted and the program goes to
|
|
the next packet.
|
|
b. If the CRC checks out in the DEmmm.EXE program, it
|
|
writes out the decoded text into a new TEMPDE.XXX file
|
|
and exits. The local packet analyzer reads in the data
|
|
from that file and replaces the text of the message
|
|
with that, then goes ahead and processes the packet as
|
|
determined by main_type.
|
|
|
|
Network operators who wish to write EN/DE programs for their own
|
|
netwide messages may wish to consider using the RSAREF library to
|
|
develop their own source-verification scheme.
|
|
|
|
D. Main and Minor Message Types
|
|
|
|
The main and minor type of each message determines how it is
|
|
processed (where it goes, whether it's a sub post, email, or
|
|
network info, etc.). The analyzer reads the message header in
|
|
first to get the main and minor types, then performs the
|
|
operation indicated by those fields.
|
|
|
|
Here is a list of the main_ and minor_types, along with the WWIV
|
|
BBS #define name and descriptions of the processing required.
|
|
Encoding method is assumed to be zero unless otherwise noted.
|
|
Note that while these descriptions concern analyzing local mail
|
|
packets, they also apply to how to create outgoing netmail
|
|
packets. It should also be noted that some of the "UNUSED"
|
|
message types could be used by some third party software, but
|
|
they are not an official part of the WWIVnet software, so no
|
|
mention is made of them.
|
|
|
|
main_type 1 (0x0001) -- main_type_net_info
|
|
These messages contain various network information files,
|
|
encoded with method 1 (requiring DE1.EXE). Once DE1.EXE has
|
|
verified the source and returned to the analyzer, the file
|
|
is created in the network's DATA directory with the filename
|
|
determined by the minor_type (except minor_type 1).
|
|
0 -- Feedback to sysop from the NC. This is sent to the #1
|
|
account as source-verified email.
|
|
1 -- BBSLIST.NET -- Old-style node list (non-Group setup).
|
|
2 -- CONNECT.NET -- Old-style connections list (non-Group).
|
|
3 -- SUBS.LST -- List of subboards ("subs") available
|
|
through the network. This has been replaced by
|
|
main_type 9.
|
|
4 -- WWIVNEWS.NET -- An electronic magazine of sorts
|
|
distributed within some networks, usually monthly.
|
|
5 -- FBACKHDR.NET -- a header file added to network update
|
|
reports for the network.
|
|
6 -- Additional WWIVNEWS.NET text -- appended to the
|
|
existing WWIVNEWS.NET file.
|
|
7 -- CATEG.NET -- List of sub categories. WWIV's sub setup
|
|
facility uses this list so the sysop can specify what
|
|
category a netted sub falls into. The network's
|
|
SUBS.LST compiler uses this information for compiling
|
|
the subs lists sent out as main_type 9.
|
|
8 -- NETWORKS.LST -- A list of all current WWIVnet type
|
|
networks.
|
|
|
|
This message type is source-verified. That is, there is a
|
|
digital signature at the beginning of the message text which
|
|
is decoded by the DE1.EXE to verify that it has come from a
|
|
"legal" source. This helps make sure that the network info
|
|
will only come from the Network Coordinator. If the source-
|
|
verification fails, the packet is discarded.
|
|
|
|
main_type 2 (0x0002) -- main_type_email
|
|
This is regular email sent to a user number at this system
|
|
(see tosys and touser, above). Note that this type of mail
|
|
should only be received by systems that assign numbers to
|
|
users (WWIV, VBBS, etc.). BBSes in a WWIV network that only
|
|
identify users by name (PCBoard, RBBS, etc.) can only
|
|
receive email-by-name (see main_type 7, below). Email has
|
|
no minor type, so minor_type will always be zero.
|
|
|
|
Processing of the email is straightforward. The analyzer
|
|
looks for the user number indicated by the touser field. If
|
|
the number exists and the user has not been deleted from the
|
|
BBS, the message is written into the email file, addressed
|
|
to the user indicated. If the number does not exist or the
|
|
user at that number has been deleted, the packet is deleted
|
|
without processing. Alternatively, the analyzer may
|
|
generate a return message (as email) to the sender telling
|
|
him that the mail was not delivered and quoting the message
|
|
back to him.
|
|
|
|
main_type 3 (0x0003) -- main_type_post
|
|
This is a post sent from the sub host's system to the
|
|
subscriber systems, for subs that have a numeric sub-type
|
|
(subs of alphanumeric subtypes are main_type 26, described
|
|
below). The minor_type will be the numeric subtype the post
|
|
will go to.
|
|
|
|
When this type is encountered, the network analyzer should
|
|
search the BBS data files for the sub type given. When the
|
|
sub is found, the message is written into the indicated
|
|
message file in whatever format the BBS software uses. If
|
|
the sub type is not found, the message packet is simply
|
|
deleted. (There are some local mail preprocessors which
|
|
will scan the packet for messages on subs that the system
|
|
does not carry, and return the message to the host system.
|
|
An alternate mail analyzer could have such a capability
|
|
built in.)
|
|
|
|
main_type 4 (0x0004) -- UNUSED
|
|
|
|
main_type 5 (0x0005) -- main_type_pre_post
|
|
These messages are similar to main_type_3, except they are
|
|
posts en route from the subscribers to the host of a sub.
|
|
|
|
Like main_type 3, the minor_type is the numeric subtype of
|
|
the sub. Since this is from subscriber to host, list_len
|
|
will be zero.
|
|
|
|
When this type of packet is received, the local mail tosser
|
|
should look for the appropriate file which will contain the
|
|
list of subscribers to the sub (WWIV and NETxx use
|
|
N[subtype].NET) If the file is found, a main_type 3 copy of
|
|
the post is generated in an outgoing netmail file, with the
|
|
node list read from the subscriber file inserted before the
|
|
message text (and the list_len field modified reflecting the
|
|
addition of the node list). If the file cannot be found,
|
|
the analyzer assumes the BBS does not host the sub and
|
|
deletes the packet.
|
|
|
|
Many WWIV sysops use a feature of the software known as
|
|
network validation ("netval"). When a sub is set for netval
|
|
(this is found in the SUBS.DAT record for the sub), the
|
|
analyzer does not send the post out to the network. The
|
|
sysop must validate the post on the BBS, at which point it
|
|
is sent out by the BBS. This also applies to pre-posts for
|
|
main_type 26 (main_type_new_post).
|
|
|
|
main_type 6 (0x0006) -- main_type_external
|
|
This type has largely been replaced with main_type 27
|
|
(main_type_new_external), but essentially works the same
|
|
way. This will create messages that are read and processed
|
|
by an external processor. The minor_type is determined by
|
|
the program expected to work with it.
|
|
|
|
When the processor encounters this type of message, it
|
|
searches for a file that contains the names of external
|
|
programs, and the minor_types they accept, used by the BBS
|
|
(EXT_LIST.NET for the WWIVnet software). If found, the
|
|
message is written or appended to EXTERNAL.NET in the
|
|
network's data directory. The external program, when run,
|
|
should be able to find the file and process it, then delete
|
|
the file (or the portion that it uses). Note that when
|
|
there is more than one main_type 6 message in a mail file,
|
|
the EXTERNAL.NET will contain all messages of that type, so
|
|
the external message processor needs to be able to find the
|
|
relevant text within the file.
|
|
|
|
It is encouraged that programs that use external messages
|
|
use main_type 27 (main_type_new_external), which has more
|
|
robust features. Among other things, that type will create
|
|
a separate temporary file for each main_type 27 message
|
|
found, making processing of external messages simpler.
|
|
|
|
main_type 7 (0x0007) -- main_type_email_name
|
|
|
|
The other email type. The touser field is zero, and the
|
|
name is found at the beginning of the message text, followed
|
|
by a NUL character. Minor_type will always be zero.
|
|
|
|
When this type of packet is encountered, the analyzer gets
|
|
the name from the beginning of the message text and searches
|
|
through the BBS's user list to find the specified name. If
|
|
it is found, the message is written into the email file for
|
|
the BBS. If it is not, the message will be deleted or a
|
|
return email may be sent back to the sender, explaining that
|
|
the message was not delivered and quoting the email back.
|
|
|
|
The destination user's name is prepended to the beginning of
|
|
the message text, followed by a NUL, then the rest of the
|
|
usual message header info and the message text. The message
|
|
header info at the beginning of email-by-name messages is
|
|
thus DEST_USER_NAME<nul>TITLE<nul>SENDER_NAME<cr/lf>
|
|
DATE_STRING<cr/lf>MESSAGE_TEXT.
|
|
|
|
main_type 8 (0x0008) -- main_type_net_edit
|
|
This type is used by Black Dragon in conjunction with his
|
|
program NETEDIT, a utility for managing the network files on
|
|
a WWIV BBS. Minor_types are as follows:
|
|
0 -- A partial update to the BBSLIST information.
|
|
1 -- A request for BBSLIST information to be changed.
|
|
2 -- A partial update to the connection information.
|
|
3 -- A request for connection information to change.
|
|
4 -- An update to NETEDIT's registration record.
|
|
5 -- A transmittal of the installation message.
|
|
6 -- A request for to transmit a registration record.
|
|
7 -- A response to request for a registration record.
|
|
8 -- A remote request for a net analysis ("/A").
|
|
9 -- An ASCII text response to a remote analysis.
|
|
10 - Network Editor E-mail and/or automatic feedback.
|
|
11 - A message reporting an error condition.
|
|
12 - A request for installation and ver information.
|
|
13 - A request for a remote node's ALIASES.NET file.
|
|
14 - A request for a node's aliases.
|
|
15 - A response to the alias request.
|
|
For more information on the use of these types, see the
|
|
NETEDIT documentation, or email Black Dragon at @1180 on
|
|
WWIVnet or @13080 on WWIVLink.
|
|
|
|
main_type 9 (0x0009) -- main_type_sub_lst
|
|
Networks with large subs lists (over 32k) break them up into
|
|
parts and send the set out under this main type rather than
|
|
the subs.lst type under main_type 1. The minor_type
|
|
indicates the part of the subs list.
|
|
|
|
When the analyzer processes this type, it creates a file in
|
|
the appropriate network directory and copies the message
|
|
text into it. Minor_type zero creates the file SUBS.LST,
|
|
and all other minor_types create a SUBS.x file where 'x' is
|
|
the minor_type.
|
|
|
|
main_type 10 (0x000a) -- UNUSED
|
|
|
|
main_type 11 (0x000b) -- main_type_bbslist
|
|
This type is for the new-style BBSLIST files used in
|
|
networks that use the Group setup. It covers full and
|
|
partial updates sent from the Network Coordinator (NC) to
|
|
the entire network as well as update requests sent from the
|
|
Group Coordinators (GCs) to the NC. The encoding method is
|
|
either 1 (when coming from the NC) or calculated as
|
|
((minor_type % 256)+256) (when coming from the GC).
|
|
Messages of this type are source verified by DE<method>.EXE,
|
|
handled the same as main_type 1 packets are. Minor types
|
|
are as follows:
|
|
0..255 Full bbslist update sent from NC to the network.
|
|
Minor type is the Group number. Creates
|
|
BBSLIST.<minor_type> in the network data direc-
|
|
tory.
|
|
257..511 Full bbslist update sent from the GC to the NC.
|
|
Minor_type is the Group number plus 256. Creates
|
|
BBSLIST.A<minor-less-256-in-hex> in the NC's
|
|
network data directory.
|
|
513..767 Partial bbslist update sent from the NC to the
|
|
network. Minor type is the Group number plus 512.
|
|
Creates the file BBSLIST.<minor-type> in the
|
|
network data directory. This file will be merged
|
|
with the appropriate full BBSLIST file during
|
|
network analysis (described below).
|
|
In some networks, the Group updates are sent out to the
|
|
network by the GCs rather than the NC.
|
|
|
|
main_type 12 (0x000c) -- main_type_connect
|
|
This is the same as main_type 11, except it is for CONNECT
|
|
files. It also does not include partial updates, as there
|
|
are none for CONNECT files. The encoding method is also
|
|
either 1 (from NC) or ((minor_type % 256)+256) (from NC) for
|
|
this type. These packets are also source-verified, checked
|
|
by DE<method>.EXE. Minor types:
|
|
0..255 Full CONNECT update sent from NC to the network.
|
|
Minor type is the Group number. Creates
|
|
CONNECT.<minor-type> in the network data directory
|
|
(after source-verification).
|
|
257..511 Full bbslist update sent from the GC to the NC.
|
|
Minor_type is the Group number plus 256. Creates
|
|
CONNECT.A<minor-less-256-in-hex> in the NC's
|
|
network data directory (after source verifica-
|
|
tion).
|
|
In some networks, the Group updates are sent out to the
|
|
network by the GCs rather than the NC.
|
|
|
|
main_type 13 (0x000d) -- UNUSED
|
|
|
|
main_type 14 (0x000e) -- main_type_group_info
|
|
For now, this type only covers email to the members of a
|
|
particular Group by the GC, so minor type will always be
|
|
zero. Encoding method is the Group number plus 256.
|
|
Processing for this is the same as for type 1/0 messages.
|
|
They are source-verified by DE<method>.EXE.
|
|
|
|
main_type 15 (0x000f) -- main_type_ssm
|
|
WWIV BBSes also send out small messages, known as "SSMs",
|
|
across the network. These are little one-line messages
|
|
generally telling users when their mail has been read and so
|
|
forth. Some BBSes have been modified to send other types of
|
|
messages. At any rate, main_type handles these small
|
|
messages. Minor_type is always zero.
|
|
|
|
Like email, the analyzer searches for the user number in the
|
|
BBS's user list. If found, the message is written into the
|
|
SSM file for the BBS. Since this is a feature most non-WWIV
|
|
systems do not support, they can be ignored.
|
|
|
|
One feature of WWIV networking is the ability for network sysops
|
|
to send "REQs" to the hosts of subs, enabling them to automati-
|
|
cally subscribe to and drop subs they belong to. Main_types 16
|
|
through 19 handle REQs and their responses.
|
|
|
|
main_type 16 (0x0010) -- main_type_sub_add_req
|
|
This is for requests to add the sending system to a sub's
|
|
subscriber list. Minor_type will be the numeric sub type,
|
|
or zero for alphanumeric sub types. For minor_type==0, the
|
|
sub type (followed by NUL) will be the message text.
|
|
Otherwise, there should be no message text (if there is,
|
|
ignore it).
|
|
|
|
When this message type is received, the analyzer should
|
|
search for the subtype's subscriber file (N[subtype].NET for
|
|
WWIV systems). If the file is found, the system number of
|
|
the new subscriber is added, if it is not in there already.
|
|
If the add is successful, it will then look for a text file
|
|
in the data directory (SA[subtype].NET for the WWIVnet
|
|
software) that contains information the sysop wants to send
|
|
back to the subscriber. A type 18 message is sent to the
|
|
subscriber indicating status of the add request (see below)
|
|
and including the text in the SA[subtype].NET file, if one
|
|
is found. If the add is not allowed, the analyzer looks for
|
|
SR[subtype].NET and sends that text back to the requester.
|
|
If the add is otherwise unsuccessful, the type 18 message
|
|
will include the status and a short explanation of why the
|
|
add was not successful.
|
|
|
|
main_type 17 (0x0011) -- main_type_sub_drop_req
|
|
This is the same as a main_type 16 message, except that it
|
|
is sent by a subscriber wishing to drop a sub. The
|
|
minor_type is determined the same way as main_type 16.
|
|
There should be no message text, but if there is any, it is
|
|
ignored.
|
|
|
|
Processing is similar to a type 16 message. The analyzer
|
|
searches for the subtype's subscriber file, and upon finding
|
|
it removes the subscriber's system number from it, if it is
|
|
there. Status of the drop request is returned to the sender
|
|
in a main_type 19 message, with a short message appended
|
|
that explains the status.
|
|
|
|
main_type 18 (0x0012) -- main_type_sub_add_resp
|
|
This carries the status response to a main_type 16 (sub add
|
|
request). The minor_type is determined the same way as type
|
|
16 message. The first byte of message text (after the
|
|
subtype, if minor_type==0) is the status of the add request.
|
|
Possible status byte values are:
|
|
0 -- Subscriber added successfully.
|
|
1 -- This system is not the host (N[subtype].NET not found).
|
|
3 -- Not allowed to add subscribers automatically.
|
|
4 -- System number already there (can't add it again).
|
|
Since these messages also may contain a message to the
|
|
requesting sysop, the message header info at the beginning
|
|
of the message text appears as SUBTYPE<nul>STATUS_BYTE
|
|
TITLE<nul>SENDER_NAME<cr/lf>DATE_STRING<cr/lf>MESSAGE_TEXT.
|
|
In this case, SENDER_NAME will be the name of the sysop of
|
|
the system hosting the sub. 'SUBTYPE<nul>' will only be
|
|
included if the sub is an alpha subtype. And finally, note
|
|
that there is not <cr/lf> or <nul> after the status byte.
|
|
|
|
When received, the processor will send the message text
|
|
mentioned in the main_type 16 description (minus the status
|
|
byte) to the sysop as email, if the status is 0 or 3.
|
|
|
|
main_type 19 (0x0013)- main_type_sub_drop_resp
|
|
Similar to main_type 18, this carries the response to a sub
|
|
drop request, with the minor_type following the same
|
|
conventions as above. This also carries a status byte as
|
|
the message text:
|
|
0 -- Sub dropped successfully.
|
|
1 -- This system is not the host.
|
|
2 -- System number is not there (can't drop it).
|
|
3 -- not allowed to drop subscribers automatically.
|
|
The message header info in the message text is the same
|
|
format as for main_type 18.
|
|
|
|
When received, the processor will send the message text
|
|
mentioned in their main_type 17 description (minus the status
|
|
byte) to the sysop as email, is the status is 0 or 3.
|
|
|
|
main_type 20 (0x0014) -- main_type_sub_list_info
|
|
In many WWIV networks, the subs list coordinator (SLC)
|
|
occasionally sends out "pings" to all network members.
|
|
|
|
When this message type is received from the SLC (minor_type
|
|
0), the analyzer checks the BBS's sub data file. If there
|
|
are any subs hosted by the receiving system which are
|
|
flagged for inclusion in the distributed SUBS.LST, a list of
|
|
them is returned to the SLC via another main_type 20 message
|
|
with minor_type==1). When the SLC receives the reply, it is
|
|
written into SUBS.INF in the network's data directory
|
|
(appended if the file exists).
|
|
|
|
main_types 21 (0x0015) through 25 (0x0019) -- UNUSED
|
|
These were formerly reserved for the WWIVLink network for
|
|
their own updates, before they purchased NETUP (WSS's
|
|
network update software). It is not longer used by that
|
|
network.
|
|
|
|
main_type 26 (0x001a) -- main_type_new_post
|
|
Because of the growing number of networked subs on WWIVnet,
|
|
the number of available subtypes was getting scarce.
|
|
Starting with WWIV version 4.22 and NET32, alphanumeric
|
|
subtype support was added, greatly expanding the possible
|
|
subtypes. Alpha subtypes are seven characters -- the first
|
|
must be a letter, but the rest can be any character allowed
|
|
in a DOS filename. This main_type covers both subscriber-
|
|
to-host and host-to-subscriber messages. Minor type is
|
|
always zero (since it's ignored), and the subtype appears as
|
|
the first part of the message text, followed by a NUL.
|
|
Thus, the message header info at the beginning of the
|
|
message text is in the format SUBTYPE<nul>TITLE<nul>
|
|
SENDER_NAME<cr/lf>DATE_STRING<cr/lf>MESSAGE_TEXT.
|
|
|
|
It is assumed that a message coming into a host is a
|
|
prepost, and it is processed similarly to main_type 5.
|
|
Likewise, it is assumed that messages coming into a sub-
|
|
scriber system are net posts, and they are processed
|
|
similarly to main_type 3.
|
|
|
|
main_type 27 (0x001b) -- main_type_new_external
|
|
This is the new type of external message, implemented with
|
|
NET33. Like main_type 6, it creates an external file with
|
|
the message text for an external program to process. Again,
|
|
the minor_type is determined by the external program.
|
|
|
|
There is a full explanation of how these messages are
|
|
processed in Filo's WWIVnet Software Docs. In short,
|
|
similar to main_type 6, the local mail processor searches
|
|
for the minor_type in a data file (EPROGS.NET for NETxx),
|
|
and creates an external file if it is found. When the local
|
|
mail processor is finished with the local mail file, the
|
|
program associated with that minor_type will execute, with
|
|
the associated filename (with path) as a parameter.
|
|
|
|
[More Next Issue]
|
|
ÄÄÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÄÄ
|
|
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
|
|
³ IceNEWS is an independent journal published monthly as a service to ³
|
|
³ IceNET, its Sysops and users. The opinions & reviews expressed herein ³
|
|
³ are the expressed views of the respective writers. All Rights Reserved.³
|
|
³ Many product names used herein are the property of their respective ³
|
|
³ manufacturers/authors. ³
|
|
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
|
|
|
|
|