informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/WWIVNEWS/wwiv9210.txt

1037 lines
55 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Ú¿Ú¿Ú¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿Ú¿ Ú¿ÚÄ¿ Ú¿ÚÄÄÄÄ¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿
ÉÍÍÍÍÍÍÍÍÍÍÍÍͳ³³³³³³³³³³³ÀÄ¿ÚÄÙ³³ ³³³ À¿³³³ÚÄÄÄÙ³³³³³³³ÚÄÄÄÙÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º Volume 3 ³³³³³³³³³³³³ ³³ ÀÅ¿ÚÅÙ³ ÀÙ³³ÀÄÄÄ¿³³³³³³³ÀÄÄÄ¿ October 25 º
º Issue 6 ³³³³³³³³³³³³ ³³ ³³³³ ³Ú¿ ³³ÚÄÄÄÙ³³³³³³ÀÄÄÄ¿³ 1992 º
ÈÍÍÍÍÍÍÍÍÍÍÍÍͳÀÙÀÙ³³ÀÙÀÙ³ÚÄÙÀÄ¿ ÀÅÅÙ ³³À¿ ³³ÀÄÄÄ¿³ÀÙÀÙ³ÚÄÄÄÙ³ÍÍÍÍÍÍÍÍÍÍÍÍͼ
³ ÀÄÄÄÄÙÀÄÄÄÄÙÀÄÄÄÄÙ ÀÙ ÀÙ ÀÄÙÀÄÄÄÄÙÀÄÄÄÄÙÀÄÄÄÄÙ ³
³ Serving WWIV Sysops & Users Across All WWIV Networks ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³This Month's Features³
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Random Factors.......................................Wayne Bell (1@1) ³
³ ³
³ The History Of WWIVedit..............................The Emperor (1@6470) ³
³ ³
³ TechnOTES............................................WWIVnews Staff ³
³ ³
³ Squashing Those Gluttony .GIF's (Part 2).............Spackle (1@19995) ³
³ ³
³ USERREC - The Next Generation........................Tolkien (1@3456) ³
³ ³
³ Filo's Mod of the Month..............................Filo (1@5252) ³
³ ³
³ Dateline: @#$*()#!...................................Omega Man (1@5282) ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ Random Factors ³
³ Creative Commentary by Wayne Bell (1@1) ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Yet some more v4.22/net32 news:
v4.22/net32 will gate subs among networks. We have tried that, and it does
work. Also, the subs by name does work (even when gating subs-by-name). Either
the host, or a subscriber can gate a sub. Anyone on any network can auto-reply
to a gated post, and the E-mail will go back to the author of the post. Again,
we have tried that, and it does work. ("We" being 1@1, 1@4, and 1@5252.)
net32 should go out to a more extended beta-test (SDS's mostly) in the next
week or two. Hopefully, if all goes well, it should be released in about a
month. Oh, also, net32 has full support for file locking, so people using
multi-line BBS mods will no longer have any problems relating to the net
software. (But, no, I don't currently have any plans to make the BBS multi-
line [yet].)
v4.22 now has (as stated above) post and E-Mail gating, and subs-by-name. Also,
there is a new userrec format (1k per user), which hopefully incorporates all
the various userrec modifications, so everyone can have a "standard" userrec,
and authors of WWIV add-ons won't have to worry about having numerous different
formats to support. The quickscan pointers are stored in a separate file
(user.qsc), and the max subs (and max dirs) can be set to anything from 32 to
999. Be aware, though, that setting them to 999 from 32 requires 144k more of
memory.
I am currently working on extracting embedded strings out of the BBS, and
storing them in a data file. This is mostly to support multiple languages, but
should also save a lot of memory (straight out of DGROUP, for those of you that
have problems there). v4.22 probably won't have actual multi-language support,
but it should be very close.
That will probably do it for v4.22. In programming at work (non-BBS stuff),
I've had bad experiences with the "put everything in the next version" idea,
but then again I'm currently involved in the other extreme - trying to do
things in itty-bitty pieces (and that isn't a very good idea either). v4.22
will be out sometime probably first quarter next year (Jan-Mar). There will be
a v4.23 after that. For those of you who want to know, things I'm considering
for a v4.23 are: full multi-language support; integrating a QWK reader into
the BBS; putting some large global data structures into EMS/XMS; and maybe
support for other network types (Fido, Vnet). No, I don't >PROMISE< any of
those (except multi-language support), but those are what I am considering.
(I hope PKZip 2.0 comes out before v4.22. Or at least before v4.23.)
I'd also like to take a second to remind people a bit about C programming
nomenclature. C functions are called "functions". A "void" is a valid data
type, like "int" or "real" or "long". In Pascal, each block of code is either
a function (meaning it returns a value), or a procedure (meaning that it
doesn't return a value). Therefore, in Pascal, you start these routines out
with "procedure this;" or "function that;"
In C, however, every function returns a value. Thus, if the function returns an
int, it is "int func()". If you don't care what value it returns, then you
declare the return value to be of type "void", meaning "I don't care what this
returns". So if you see "void nl()", that stands for starting FUNCTION "nl"
with a return type of "void".
Finally, an important reminder regarding HS/Link command lines. If you're using
HS/Link, you should go into INIT and edit the command lines so that they look
as shown below:
Description : HS/Link
Xfer OK code : 0
Require MNP/LAPM : N
Receive command line:
HSLINK -P%2 -E%4 -U%3
Send command line:
HSLINK -P%2 -E%4 -NU %3
Receive batch command line:
HSLINK -P%2 -E%4 -U%3
Send batch command line:
HSLINK -P%2 -E%4 -NU @%3
Bi-directional transfer command line:
HSLINK -P%2 -E%4 -@ @%3
BE VERY SURE the -NU option is present as shown on the "Send" and "Send batch"
command lines!
(Of course, it is not necessary to specify ALL command lines - you can only
specify the batch command lines if you do not wish HS/Link used for single file
transfers.)
This option is used on SEND command lines when uploads are not expected or
desired. It MUST be used on the HS/Link command lines in INIT for "Send" and
"Send batch" to ensure unwanted files cannot be uploaded.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ The History Of WWIVedit ³
³ Guest Creative Commentary ³
³ by The Emperor (1@6470) ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Back in February of 1991, I was frustrated. I had, at this point, been running
a WWIV board for 6 months, and in this time, I had always longed for a good
editor. At the time, I didn't have the funds to call long distance to download
any files.
Later that month, I got hold of the source code for some obscure editor from
another BBS here in Athens. I warped the code enough to get it to run under
WWIV, and I finally had a full editor on my system. This was all fine and
dandy until I tried to add color to it. That proved to be a dismal failure,
and so I set out to build a better editor. In early March, I built an editor
from the ground up. It never did work very well, but I considered it my first
go at writing a real full screen editor.
One night in late March, when I knew I should have been working on a project
for one of my classes, I sat down and began in earnest on what would eventually
become WWIVEdit 1.0. Eight hours later, I had a working prototype of it. It had
one major advantage over anything I had written thus far. It handled colors
elegantly.
In my design of WWIVEdit, the look and feel of it was highly influenced by
ProEdit by H. S. Smith for PCBoard. I liked the idea of having the title and
destination on the screen. This was probably one of the hardest things to code.
While at first the problem may appear easy, it is actually quite difficult. As
it stands, WWIV provides no interface for a Full Screen editor to get
information as to what it is being used for. In fact, there isn't even a
guarantee that a FSED can get information as to the current user on line.
In my initial version of WWIVEdit, the destination detection algorithm "read
the screen" to see if it could figure out where a message was going. This
worked fine, except it wasn't always obvious where a message was going from
what was on the screen. This is still a problem today, though versions 2.2 and
up provide an alternate way to get the needed information. (Note:in WWIV 4.21a,
this will be standard).
In about May of 1991, I had the editor to the point where I actually believed
it was worth giving to other people, so I contacted The Duelist (1@18258
WWIVLink) to help me with some testing. The Duelist was the person who
introduced me to WWIV my freshman year of college. I nagged him for a few
weeks to try my editor, and when I finally sent him a copy, he installed
it and had it up and running in a matter of minutes. Thus was born WWIVEdit
1.0. Only one other copy of version 1.0 was distributed, and for the life of
me, I can't remember who got it. .
Over the next several weeks, The Duelist sent me a constant stream of E-Mail
on how to improve my creation. Thus were born versions 1.1 through 1.4.
Version 1.4 and 1.6 were the first versions that were ever distributed
publicly. I got some response, but there really didn't seem to be much
interest in them.
It was about this time that I joined WWIVLink, and a month later, WWIVNet.
In that gap of time, WWIVEdit 2.0 was born. Version 2.0 contained some very
significant advances. The internals were reworked, providing cleaner, but
not perfect, formatting. Version 2.0 also was different in one very significant
way; a fact which I attribute much of its success to: I included the source
code with the editor, with no strings attached. I continue this policy today
with only one slight modification; the source code, due to its large size
isn't included in the distribution file, however is available separately.
In August of 91, one of my users said "Hey, why don't you add a spell
checker to the editor?"At the time, I laughed at him and said "Yeah. Right.
"But over the next several weeks, I got a few more requests. some from my
users, some from people on the networks. So I began to look for a file that
contained enough words to make a reasonable dictionary. Filo eventually
pointed me to a list of about 6000 words, so I got it, changed it into a
form I could use, and had a working dictionary a few weeks later. With that
feature added, I released version 2.2.
Over the next several months, I got a steady stream of suggestions on what
should be added to the next version, and in December, I had enough changes
to warrant a Beta version of 2.3. It went to all of the people who had
registered WWIVEdit up till that point, as well as a few of my favorite
beta testers. The beta version was pretty complete and free of bugs, but
I didn't feel that it was ready for public distribution. Then, over the
next 3 months, I was very busy with my school work, so I did very little
in the way of improvements.
Finally, during Spring Break of 1992, I got enough time to sit down and
work. And in early April, I had another beta version ready. This one only
had a few bugs, so I fixed them, and a few weeks later release version 2.3.
Just before release though, I added what I thought was a relatively simple
change, however, it generated a lot of apparently unrelated bugs. Since
then, I haven't released a full version, but a bug fix has been available
on my system for a few months.
By the time this makes it to press, WWIVEdit 2.4 will probably have been
released. A number of features will be added, many of them related to the
upcoming release of WWIV 4. 21a. In particular, WWIVEdit 2.4 will have support
for a quoter that has been installed in WWIV 4. 21a, support for the "Disable
Tag" feature in WWIV's //BOARDEDIT, support for BBS's other than WWIV (waffle,
Telegard, etc), and a few other bug fixes and enhancements.
After this next release, I have nothing of significance to add to WWIVEdit.
I may rework a lot of the internals to make more efficient use of memory,
and I may add support for a few more BBS's, but I have no ideas left on what
to add. I have always welcomed suggestions on how WWIVEdit can be improved,
and continue to do so.
So, if you have any suggest, comments (both positive and negative), please
feel free to Mail me at any of the following addresses:
1@6470 Net
1@16470 Link
acaldwel@oucsace. cs. ohiou. edu
acaldwel@bigbird. cs. ohiou. edu
CALDWELL@duce. cs. ohiou. edu
I would like to take a few lines to thank everyone who have sent me comments,
suggestions, bug reports, and all: Lance Halle, Trader Jack, The Duelist,
Jim Wire, Aahz, Trojan, Filo, and Wayne Bell.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ TechnOTES ³
³ Compiled by the WWIVnews Staff ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
...While the industry as a whole is trying to decide whether to support
the PCMCIA standard (the so-called "Credit Card Hard Drives", AKA "Flash
Memory") for low-power portable mass storage, Hewlett-Packard has decided to
tie an alternatively less expensive carrot on the end of the stick by
developing the smallest commercial hard drive yet released on the open market.
...Dubbed the "Kittyhawk" by HP, the drive has a platter size of 1.3 inches,
and contains two platters capable of 14MB of storage each. Although the
Kittyhawk can easily fit inside of a matchbox, it does so at the cost of one
side of platter storage; the top platter is too close to the case to allow for
a R/W head to move freely. Still, the small size allows the drive to run
at less than 3v, which is becoming a requirement for use in portables that
promise longer continuous use on battery power.
...With something that small and compact, one would probably expect the
Kittyhawk to be rather fragile. According to HP, the drive is far from
gossamer, and can take over 100 G's of shock force before incurring any
real internal damage. This helps to negate most of the remaining arguments
that PCMCIA advocates have had against using mechanical hard drives for
portable storage instead of shockproof Flash Memory cards. In fact, the drive's
size will be PCMCIA Type III compatible, thus allowing for manufacturers to
produce both versions for a relatively small difference in cost.
...It should come as no surprise then that HP's target market for the Kittyhawk
is the next generation of palmtops and hand-held pen computers. This new breed
of PC, which HP refers to as a "mobile information appliance", is reportedly
the foundation for a revamped line of HP palmtops, including an expanded
version of the popular HP95LX. Already NEC and Apple have expressed interest
in using removable Kittyhawks in future palmtop development as opposed to the
PCMCIA cards that are expected to be touted as the next "standard" within the
next couple of years.
...GSI of Irvine, CA has released a new floppy controller that promises to
allow for a "seamless installation and operation" of extra-high-density
3.5" drives in any system without the hassle of BIOS upgrading or juggling
of software drivers. The Model 11 controller has it's own onboard BIOS
aliasing manager, which eliminates BIOS incompatibilities and allows
installation as a secondary controller without conflict with the existing
floppy controller.
...The Model 11 supports up to four extra-high-density drives, and comes as
part of a "Super Floppy Upgrade Kit", which also includes a TEAC 2.88MB Floppy
Drive, one Toshiba 4MB 3.5" diskette, and connecting ribbon cables. MSRP
for the kit is $325, but street prices are expected to drop below the $300
mark by the end of the year.
...Looking towards the future a bit, IBM has announced that researchers
at the Watson Center have produced transistors that are just under 1/75,000
of the width of a human hair. Using an experimental form of electron-beam
nanolithography fabrication, the transistors produced are just under 0.1
micron in size, and may eventually pave the way for 4GB DRAMs. Don't hold
your breath for 'em, though - the current method of processing the transistors
only allows for a production run of about 35 individual chips per hour. For
actual market purposes, the process would have to produce that many *wafers*
per hour, which will probably delay the release of such chips on the market
until the latter half of this decade at the earliest.
...Texas Instruments is shipping a new 4Mb Video RAM chip that the company
hopes will become the "new standard" for VRAM by the end of 1993. The new
chip is designed to replace the existing 1Mb VRAM standard, and is expected
to allow graphics board manufacturers the resources to produce inexpensive
24-bit video adapters using much of the same existing design elements in
most popular SVGA cards. With the ability to fit 4 megs of VRAM in the space
of one with very little modding to the original 1Mb circuitry for about the
same cost, boards like the high-end Targa series and the recently-released
Video Blaster from Creative Labs, may soon find themselves outdated quicker
than their respective manufacturers expected.
...Speaking of Creative Labs, how many of you have wanted a Sound Blaster to
enhance that copy of Wing Commander or Wolfenstein 3-D, but didn't really want
all the frills of the MIDI accessory kit? If one has no real interest in music,
or actually has no musical talent, then why should you have to fork over the
dough for the MIDI accessories?
...Ok, so lack of musical talent didn't stop Nirvana from smelling like
something other than Teen Spirit. Still, Creative Labs must have heard these
wishes from a lot of potential (read: broke and untalented) customers, and
have released the Sound Blaster Pro Basic kit.
...The Pro Basic kit contains a Sound Blaster Pro board with all the non-
MIDI specific frills, including voice sampling, text-to-speech capabilities,
FM synthesized 20-voice output capacity, and basic control of audio CD's for
multimedia use. The board also will be interfaceable with CL's new Video
Blaster board for additional multimedia presentation production.
...While the MSRP for this package is $229 direct from CL, street prices have
been as low as $169. The expected side effect has been to reduce the price of
the original Sound Blaster to as low as $119 on the street. At prices like
these, expect another round of "Sound Blaster Chat Mods" to hit the Modnet
shortly after Christmas.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ Squashing Those Gluttony .GIF's (Part 2) ³
³ By Spackle (1@19955) ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
This article is the second in a three-part series of articles discussing the
various GIF (Graphics Interchange Format) picture file compression methods,
their pros and cons, and a sample test with sample GIF files. The complete
article (12K archived) is available for download at The Rubicon in Raleigh,
North Carolina at 919-676-0738 under the filename of GIFCOMPR.LZH. Sysops
are auto-validated first call. This would make an excellent G-File, and is
good download information as well.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
There is one last GIF compression method we have not looked at. Let's take
a very in-depth look into JPEG...
JPEG Compression:
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
First, a few definitions (taken from the JPG2GIF.DOC file/slightly modified):
- A CONTINUOUS TONE IMAGE is one where there aren't any sharp edges between
objects in the image. Instead, there are lots of intermediate colors around the
edges of objects. Images like this are created when you scan a photograph or
use a video digitizer with a video camera. Another property of continuous tone
images is that there aren't any large areas which are only one color; rather,
there are many subtle different shades of color.
- A DRAWN IMAGE is exactly that, an image drawn using a paint program. Drawn
images look like they are out of comic books; they have sharp edges and large
areas which are one solid color.
- JPEG compression is an image compression technique which compresses
continuous tone images. You can JPEG-compress drawn images, but the results
aren't exactly pleasing (most drawn and JPEG'd files grow by a LARGE amount!)
- GIF is a compression technique which works on both continuous tone or drawn
images. GIF compression works much better on drawn images, but most of the GIF
images in the world are continuous tone images.
Now that we have those out of the way, let's explain what JPEG is, what it
does, where it came from, etc...
The best quality JPEG images result when you start with 24-bit, undithered
images. Unfortunately, GIF does not support 24-bit images; and most of the
8-bit GIF images are dithered. In short, there are VERY few 24-bit images
floating around in the PC arena. The reason for this is that to work with them
in the first place, you need to have a Targa video board or an XGA-compatible
PS/2. Both are relatively expensive for the end user.
So, if you are using a scanner or digitizer to produce images, you can get
better compression ratios--and better quality images--if you generate 24-bit
Targa or TIFF files and then convert them to JPEG files. You can't do this
with GIF2JPG, however. (Author's Note: A separate program by the same company
[Handmade Software], called Image Alchemy, will perform this task for you.)
GIF2JPG performs basically the same task as GIFLITE--filtering out non-vital
information--but uses a standard algorithm, as defined by the JPEG committee
(see the end of this article for the JPEG address).
Unlike GIFLITE, however, GIF2JPG allows you to define a "quality factor," which
determines the amount of compression, the resulting image quality, and the
amount of image degradation. A higher quality factor will preserve more of the
image quality, while a lower quality factor will compress the file more by
removing more of the image information. While this may seem powerful, it is
also tedious and dangerous. Every GIF is different, and using a set quality
factor on each one will cause all but a few GIFs to turn out looking extremely
poor. For this reason, it is necessary to test-compress each GIF at least twice
to find a happy medium between compression and image loss. At 10 seconds (my
average) for every 10Kb being compressed (using the default factor of 55), if
I compressed all 80 megs here at The Rubicon, it would take me at least 21
HOURS!
JPEG files can be un-JPEG'd back into GIF files, and JPEG compression is almost
never (emphasis: NEVER) faster than GIFLITE compression, but it must also be
taken into account that JPEG compression is NOT a lossless compression method!
If you compress a file using JPEG and then turn around and uncompress it, the
original and the uncompressed files WILL NOT BE THE SAME. In fact, there will
be a significant amount of degradation between the two files.
Let's do a compression comparison on the same files we used with GIFLITE. We'll
use basically the same chart, with a few exceptions. We will need three
separate file size listings - the original GIF, the compressed GIF, as well as
the GIF after being uncompressed again. These will be listed as #1, #2, and #3,
respectively. We will also run four separate tests instead of three. The first
will be run using a quality factor of 20, the second using 40, the third with
the default factor of 55, and the fourth will be run using a quality factor of
75. In addition, the time to convert back to .GIF from .JPG will also be
included, listed as "UnCompres" (compression time will be listed as
"Compress").
ÚÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³GIF File ³ 3BABES.GIF ³ CALVIN2.GIF ³ CLAUDIA.GIF ³ WATERFAL.GIF ³
³Resolut. ³ (640x480x256) ³ (320x200x16) ³ (607x774x16) ³ (576x360x4) ³
ÃÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³20% Qual.³#1 260.61 Kb ³#1 8.19 Kb ³#1 107.52 Kb ³#1 22.14 Kb ³
³ ³#2 39.06 Kb ³#2 8.19 Kb ³#2 68.89 Kb ³#2 22.14 Kb ³
³ ³#3 262.58 Kb ³#3 8.19 Kb ³#3 108.43 Kb ³#3 22.14 Kb ³
³ Redux ³85.1% reduction³0.0% reduction ³36% reduction ³0.0% reduction³
³Compress ³Time: 4:14.85 ³Time: 0:24.89 ³Time: 3:20.58 ³Time: 1:42.22 ³
³Uncompres³Time: 9:48.23 ³Time: 0:02.29 ³Time: 6:55.76 ³Time: 0:02.35 ³
³ Loss? ³Considerable ³None detected ³Lots - spots ³Size distorted³
ÃÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³40% Qual ³#1 260.61 Kb ³#1 8.19 Kb ³#1 107.52 Kb ³#1 22.14 Kb ³
³ ³#2 61.21 Kb ³#2 8.19 Kb ³#2 96.44 Kb ³#2 22.14 Kb ³
³ ³#3 255.98 Kb ³#3 8.19 Kb ³#3 113.72 Kb ³#3 22.14 Kb ³
³ Redux ³77.2% reduction³0.0% reduction ³11% reduction ³0.0% reduction³
³Compress ³Time: 4:19.14 ³Time: 0:25.10 ³Time: 3:27.67 ³Time: 1:36.51 ³
³UnCompres³Time: 9:51.66 ³Time: 0:02.14 ³Time: 6:57.16 ³Time: 0:02.36 ³
³ Loss? ³Significant ³None detected ³Darker/grainy ³Size distorted³
ÃÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³55% Qual ³#1 260.61 Kb ³#1 8.19 Kb ³#1 107.52 Kb ³#1 22.14 Kb ³
³(default)³#2 74.97 Kb ³#2 8.19 Kb ³#2 107.52 Kb ³#2 22.14 Kb ³
³ ³#3 257.84 Kb ³#3 8.19 Kb ³#3 107.52 Kb ³#3 22.14 Kb ³
³ Redux ³ 72% reduction ³0.0% reduction ³0.0% reduction³0.0% reduction³
³Compress ³Time: 4:24.35 ³Time: 0:25.21 ³Time: 3:33.50 ³Time: 1:36.01 ³
³UnCompres³Time: 9:59.79 ³Time: 0:02.26 ³Time: 0:02.75 ³Time: 0:02.20 ³
³ Loss? ³VERY poor qual.³None/No Compr.!³None/No Compr!³Size distorted³
ÃÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³75% Qual ³#1 260.61 Kb ³#1 8.19 Kb ³#1 107.52 Kb ³#1 22.14 Kb ³
³ ³#2 92.08 Kb ³#2 8.19 Kb ³#2 107.52 Kb ³#2 22.14 Kb ³
³ ³#3 262.33 Kb ³#3 8.19 Kb ³#3 107.52 Kb ³#3 22.14 Kb ³
³ Redux ³ 65% reduction ³0.0% reduction ³0.0% reduction³0.0% reduction³
³Compress ³Time: 4:29.64 ³Time: 0:25.33 ³Time: 3:39.42 ³Time: 1:36.28 ³
³UnCompres³Time: 10:08.79 ³Time: 0:02.20 ³Time: 0:02.69 ³Time: 0:02.19 ³
³ Loss? ³SEE NOTE BELOW ³None/No Compr.!³None/No Compr!³Size distorted³
ÀÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Now that we've attained our results, let's examine them in more detail. We'll
go down the list by filename and quality factor (hereby known as "QF").
3BABES.GIF
ÄÄÄÄÄÄÄÄÄÄ
20 QF - Took about 4 minutes to compress from 260K down to 39K. A VERY
impressive space gain indeed, but we lost a VERY considerable
amount of image integrity. The image was discernible enough,
but I would have been very dissatisfied had I downloaded it
somewhere. It took more than twice as long to convert back to
the "original" GIF, which ended up 2K bigger than the original.
Go figure.
40 QF - Another 4 minutes to compress, with a 200K space gain. However,
contrary to what the GIF2JPG documentation says, this image was
MORE degraded than the 20 QF one, when it certainly should not
have been. Ten minutes to get the "original" back, 5K short.
55 QF - Pretty much the same as 40 QF - a 190K gain this time. Time for
compression is increasing as the QF goes up... (For some reason
that strikes me as odd - if you're NOT doing much to the file,
it should go faster, right?) Picture quality is better than
before, but still shows splotches and small portions of severe
degradation.
75 QF - Less space gain, more time to compress/uncompress. Image was NOT
fully viewable. After running the test several times on this
file with the same results (GIF had an error halfway through it),
I gave up. This is yet another bug in GIF2JPG or the accompanying
JPG2GIF.
CALVIN2.GIF
ÄÄÄÄÄÄÄÄÄÄÄ
ALL --- NO compression was ever done on this file. This is a hand-drawn
GIF, and just as the GIF2JPG docs state, hand-drawn images gain
very little from JPEG compression. A complete waste of time with
this file.
CLAUDIA.GIF
ÄÄÄÄÄÄÄÄÄÄÄ
20 QF - Three minutes compression gains about 40K. Uncompression gives
us a file 1K bigger than the original and takes twice as long.
40 QF - Only a 10K compression this time, with a 10-second increase in
compression. Uncompression is at least twice as slow, and this
time we get a file 6K bigger than the original.
55 QF - File would not compress under this QF. No gain or loss. Just
wasting more time...
75 QF - Same with this QF (and higher - I tested 80 and 90 QF to see).
WATERFAL.GIF
ÄÄÄÄÄÄÄÄÄÄÄÄ
ALL --- Another waste of time. However, nothing in the docs makes mention
of this type of file (interlaced), or the fact that GIF2JPG simply
will not compress them at all (even at 5 QF!) I consider that a
serious flaw. No space gain or loss, only a waste of CPU time.
Note also that it takes FOREVER to convert from a .JPG to a .GIF file - on
*any* machine. It took almost 10 minutes to un-JPEG the 3BABES.GIF image, and
almost 20 for the group of four! And that was for EACH TEST RUN!
Compounding that problem is the SERIOUS FACT that GIFs may be compressed,
uncompressed, compressed, transferred, uncompressed, and compressed again
an UNLIMITED number of times. You may download a GIF that has been through
the compression/decompression cycle tens of times, with no way of actually
KNOWING it!
And each time, it lost some image information. Not to mention that image loss
is a subjective item. Major loss to some is minor loss to others -- you may
think 25% quality loss is ok, but Joe Uploader may think that 80% loss is
acceptable... so you may be downloading a file that has lost 85% or more of
its original information! Do this more than a few times, and the picture may
well be completely useless.
There are other items against JPEG compression. For one, JPEG is and always was
a 24-bit image compression technique. It originated in video recording and
editing studios as a way to store information in less space with minimal
quality loss. It was NEVER intended to be used on 8-bit machines with 8-bit
images. ALL GIF images are 8-bit. Some may have been converted from 24-bit
TARGA images, but they end up as 8-bit images.
[To be concluded in next month's WWIVnews]
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ USERREC - The Next Generation ³
³ by Tolkien (1@3456) ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Editor's NOTE: As hinted at on Amber and in a recent Mail_to_all_sysops, 4.22
will feature a new userrec structure, one that will incorporate some features
previously found in major modification files such as FROM.MOD and 8COLORS.MOD.
In addition, there are certain aspects of pointer structuring that will be
handled quite differently to accommodate 4.22's ability to support up to
999 message bases.
As a service to WWIVnews' modders' contingent, the co-author of this new
structure, Tolkien, has contributed the following article detailing what this
new userrec will look like following the release of 4.22, and has included some
of the technical details behind the pointer structures as well. Modders are
advised to take note of the additions to the standard user record, and take
this opportunity to update their mods accordingly prior to 4.22's actual
release sometime in the first quarter of 1993.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Well, as you all may or may not be aware, the following is the new "super
userrec" structure for WWIV v4.22 and later. The differences merit some
discussion, thus this article. However, first, here is the new structure:
typedef struct {
char
name[31], /* user's name/handle */
realname[21], /* user's real name */
callsign[7], /* user's amateur callsign */
phone[13], /* user's phone number */
dataphone[13], /* user's data phone */
street[31], /* street address */
city[31], /* city */
state[3], /* state code [MO, CA, etc] */
country[4], /* country [USA, CAN, FRA, etc] */
zipcode[11], /* zipcode [#####-####] */
pw[9], /* user's password */
laston[9], /* last date on */
firston[9], /* first date on */
note[61], /* sysop's note about user */
macros[3][81], /* macro keys */
sex; /* user's sex */
char
res_char[78]; /* bytes for more strings */
unsigned char
age, /* user's age */
inact, /* if deleted or inactive */
comp_type, /* computer type */
defprot, /* deflt transfer protocol */
defed, /* default editor */
screenchars, /* screen width */
screenlines, /* screen height */
num_extended, /* extended description lines */
optional_val, /* optional lines in msgs */
sl, /* security level */
dsl, /* transfer security level */
exempt, /* exempt from ratios, etc */
colors[10], /* user's colors */
bwcolors[10], /* user's b&w colors */
votes[20], /* user's votes */
illegal, /* illegal logons */
waiting, /* number mail waiting */
ontoday, /* num times on today */
month, /* birth month */
day, /* birth day */
year, /* birth year */
language; /* language to use */
char
res_byte[50]; /* reserved for byte values */
unsigned short
homeuser, /* user number where user can be found */
homesys, /* system where user can be found */
forwardusr, /* mail forwarded to this user number */
forwardsys, /* mail forwarded to this system number */
net_num, /* net num for forwarding */
msgpost, /* number messages posted */
emailsent, /* number of email sent */
feedbacksent, /* number of f-back sent */
fsenttoday1, /* feedbacks today */
posttoday, /* number posts today */
etoday, /* number emails today */
ar, /* board access */
dar, /* directory access */
restrict, /* restrictions on account */
ass_pts, /* bad things the user did */
uploaded, /* number files uploaded */
downloaded, /* number files downloaded */
lastrate, /* last baud rate on */
logons, /* total number of logons */
emailnet, /* email sent via net */
postnet, /* posts sent thru net */
deletedposts, /* how many posts deleted */
chainsrun, /* how many "chains" run */
gfilesread, /* how many gfiles read */
banktime; /* how many mins in timebank */
char
res_short[50]; /* reserved for short values */
unsigned long
msgread, /* total num msgs read */
uk, /* number of k uploaded */
dk, /* number of k downloaded */
daten, /* numerical time last on */
sysstatus, /* status/defaults */
wwiv_regnum, /* user's WWIV reg number */
filepoints; /* points to spend for files */
char
res_long[56]; /* reserved for long values */
float
timeontoday, /* time on today */
extratime, /* time left today */
timeon, /* total time on system */
pos_account, /* $ credit */
neg_account, /* $ debit */
gold; /* game money */
char
res_float[32]; /* reserved for real values */
char
res_gp[100]; /* reserved for whatever */
} userrec;
Okay, there are some significant differences between this structure and all
of the ones prior. The "old" userrec (the one you are currently using) had
grown into somewhat of a kludge over time. There wasn't really any way to
avoid that, at least not without a complete change of the structure from
version to version, which was impractical at best.
So, Wayne waited a long time before agreeing to make this level of change.
The first major difference is that there are several fields that are no
longer going to be in the USER.LST file at all: the qscan pointers, the nscan
pointers, and the sysopsub field. Because of this, you would think that the
USER.LST file itself would be smaller, but planning ahead is prudent and a
hefty amount of padding spread throughout the new userrec has been added. The
reason for this should be fairly obvious: people can use or change the
padding for whatever reason they wish, but utilities that are written for
this userrec will >*still be compatible*<. This is the single most useful
improvement over the prior structures. No more incompatibility problems such
as many of us have experienced over the past few years.
You can also see that there are several fields *added* to this structure:
an enhanced set of FROM fields (with a country field, and a zipcode field
large enough to accommodate both the extended US zipcodes as well as the
Canadian zipcodes), a language field, and some general purpose statistical
fields (deletedposts, chainsrun, banktime, gfilesread, filepoints). A field
for data telephone number was also added, and the color fields were expanded
to accommodate 10 ansi colors and 10 black-and-white colors (hey, there's
10 numeric keys, why not use 'em).
*HOWEVER*, some people seem to be making the assumption that because all
these fields are now going to be stock, that Wayne himself is going to
immediately use all of them internally. Not so. Some of them, maybe even
all of them, will not see use by Wayne, almost definitely not immediately.
Many or all of these additions are because large numbers of people already
add these fields in every time anyway. It's likely (and probable) that if
you wish to make use of them, you will have to add the code to do so
yourself. The storage has simply been allocated ahead of time, in an effort
to make long-term userrec compatibility vastly easier to attain (and
maintain).
I suspect that a little bit after 4.22 is released we shall see a fair number
of modifications that implement some of these additional fields. The planned
purposes for some of the additional fields are as follows:
FIELDNAME PURPOSE
ÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
colors[10] Ten user-definable ansi colors, instead of 8 (0-9).
bwcolors[10] For consistency with the ansi colors.
deletedposts How many posts the caller has made that have been deleted by
a sysop or cosysop.
chainsrun How many "chains" the caller has executed.
gfilesread How many gfiles the caller has viewed.
filepoints How many "points" the caller has to spend on downloading
files.
banktime How many minutes the caller has "stashed" in the virtual
"bank".
language Numeric value (much like computer type) representing this
caller's default viewing language (0=English, etc).
dataphone The caller's data (or BBS) telephone number.
note General-purpose note about the caller. Not an addition, but
expanded by twenty characters.
street The caller's home street address.
city The caller's home city.
state The caller's home state.
country The caller's home country (three-character designator).
The various res_xxxx fields are reserved for additional fields of a specific
type, either for later use by Wayne, or for you to make use of without
making your userrec incompatible. Fully one third of the new userrec is
devoted to this compatibility-maintaining padding (so I, for one, won't
have a lot of pity for anyone who goes so far as to make their userrec
incompatible - you'd really have to try hard to make doing so necessary).
Wayne made all these changes, indirectly, from suggestions from others.
Actually, I asked if the time was right for this level of change and asked
if I could coordinate it if so. I was somewhat surprised when he agreed.
Since I cannot think of everything myself, I solicited suggestions from about
three dozen boards or so (a representative sampling of the entire network),
and did the above design, then submitted it to Wayne. Wayne then tweaked it
somewhat (I hadn't allocated an extra character for a null terminator for
the state and country fields, and he wanted the sysopsub moved into one of
the additional files in order to prevent unnecessary opening and closing of
files).
Hopefully this has been a semi-lucid explanation of the intended purposes of
the new fields, as well as an indicator that Wayne most certainly does take
suggestions seriously and - if they're reasonable ones - implements them,
even when the changes are this sweeping. I *highly* recommend upgrading to
v4.22 when it is released - for the userrec structure alone, even if the
ability to have sub-gating and up to 999 subs and dirs isn't enough for you.
This "next-generation" userrec will enable third-party developers to write
better software, easier and quicker, usable by more people than ever before.
The userrec enhancement alone makes the 4.22 version of WWIV the single best
upgrade (in my opinion) - ever.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ Filo's Mod of the Month ³
³ by Filo (1@5252) ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
The Mod-of-The-Month Selection represents my choice of what appears to be a
useful, practical mod to WWIV. It does not mean it is the best mod posted or
even that it works as I may not have tested it. Given the limitations of this
media, uuencoded mods are NOT eligible for selection as mod-of-the-month.
This month's mod is by Lady Danica and offers a means of e-mailing the sub host
from BOARDEDIT.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Editor's NOTE: some of the lines of code are larger than 80 characters, and
have been split by a CTRL-A. Be sure you correct these lines prior to
installing this mod.
"Thou hast been warned..."
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Mod Name: LDANICA2 Mod Author: Lady Danica 1@15286 ³
³ Difficulty: 1 file, 3x 5-line blocks Date: It's 16 Oct, 1992 ³
³ WWIV Version: v4.21a (maybe others; ask an expert, not me) ³
³ Description: Write email to sub hosts right from boardedit, if the sub ³
³ isn't autorequestable. Even adds a special "RE:" line. ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
#include WITTY_DISCLAIMER
Step 0: Just do it. The programming gods are watching you, and if you
don't do it, they'll see that and punish you for it.
Step 1: In SUBREQ.C, void sub_type_change, look for:
rem_from_files(r->type);
}
if (!ok) {
npr("\r\nYou should email 1@%u and ask to be dropped from sub type %u.
\r\n\r\n",ui, r->type);
And add this: (right after the previous excerpt, Dilbert)
/* begin LDANICA2.MOD */
npr("Would you like to write the mail now?\r\n");
if (yn())
{
sprintf(irt,"RE: Sub Type %u - DROP Request", r->type);
email(1,ui,0,0);
}
/* end LDANICA2.MOD */
Step 2: Go a bit lower down (3-4 screens), and find:
npr("\r\nAutomated add request sent to @%u\r\n\r\n",ui);
pausescr();
} else {
npr("\r\nYou should email 1@%u and ask to be added to sub type %u
.\r\n\r\n", ui, type);
And then add: [guess where?]
/* begin LDANICA2.MOD */
npr("Would you like to write the mail now?");
if (yn())
{
sprintf(irt, "RE: Sub Type %u - ADD Request", type);
email(1,ui,0,0);
}
/* end LDANICA2.MOD */
Step 3: Find this (about another screenful down):
sub_req(main_type_sub_add_req, type, ui);
} else {
npr("\r\nYou should email 1@%u and ask to be added to sub type
%u.\r\n\r\n",ui, type);
/* NOTE: above line reformatted to fit 80-columns */
And guess what you do now?
/* begin LDANICA2.MOD */
npr("Would you like to write the mail now?\r\n");
if (yn())
{
sprintf(irt,"RE: Sub Type %u - ADD request",type);
email(1,ui,0,0);
}
/* end LDANICA2.MOD */
Step 4: Don't even bother sending money; it's too late. I already died of
malnutrition and complications thereof. But, some e-mail would be
nifty; it'd look really nice on the coffin. Closed casket, as
starvation isn't pretty!
#include POINTLESS_THANKS
#include WITTY_BBS_ADD
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ Dateline: @#$*()#! ³
³ Editor's Notes by Omega Man (1@5282) ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Before I get to this month's editorial/call for articles, I'd like to take a
moment of "Mea Culprit" and correct a mistake made in last month's issue.
Apologies go out to Spackle, who is not 1@1995, but 1@19955. Somewhere in the
transfer of the document from one machine to another, a 5 got dropped between
the cracks. Sorry about any confusion caused by this error, and rest assured
it's been corrected for this and the final installment of Spackle's series on
.GIF compression techniques.
Another apology goes out to everyone who's requested back issues of WWIVnews,
and either hasn't gotten a reply or been able to log on to Klingon Empire and
download them. At this time, the "guest" account for @5282 hasn't been set up
yet, as I need to fix a nasty little bug that allowed some 13-year-old pest
to log on and change the account to suit his fancy. When this is taken care
of, the guest account will be opened for all to call and download all the
back issues of WWIVnews they can stomach! Until then, we apologize for the
inconvenience, and appreciate your patience.
On a side NOTE, the pest I mentioned is a sysop of a part-time Telegard BBS.
So go figure...
Finally, I'd like to dispel a rumor that's been going around lately about
WWIVnews. It is in no way, shape or form true that the December issue of
this electronic newsletter will contain a 32k infomercial for OS/2 that will
be indistinguishable from the normal editorial content. That sort of trick
may have been tried in the pages of _PC Magazine_, but it won't happen here,
I assure you!
So, with all apologies aside, let's get to this month's editorial/call for
articles, shall we?
As most of us know by heart, the first official network for WWIV was, of
course, WWIVnet. Founded on elements from both benevolent totalitarianism and
controlled anarchy, WWIVnet was somewhat of a different environmental approach
to BBS networking than anything previously attempted on a national level of
distribution. In retrospect, it probably should have come as no surprise when
the first rumblings of discontent were heard regarding the way WWIVnet was
being managed and utilized. It should also have come as no surprise when
roughly 150 systems abandoned ship and formed the first alternative WWIV
network, WWIVlink.
Alternative WWIV networking is therefore not a new concept. WWIVlink itself
has been around for over two years now, not to mention the fact that there have
been Usenet and Fidonet interfaces running around with varying degrees of
functionality for at least as long. Prior to 4.21a, however, running a board
with more than one WWIV network usually required either running a BBS for
each network you wished to carry - which required its own set of specialized
network executables - or modding the source using your own coding and at your
own risk. This risk, not to mention the inconvenience of having to extensively
mod the source to account for an extra network, was too great for most people.
Many felt the safest recourse was to simply run one network and be satisfied
with that.
With the arrival 4.21a in August of this year came something of a welcome
surprise: built-in multi-net capabilities. Overnight the risks and headaches
of running a BBS with more than one WWIV network virtually went out the
window. With the exception of WWIVlink, virtually all the WWIV alternative
networks could now be accessed using one BBS, and with a little extra work
gatewaying between those networks was finally within reach as well.
About the same time, Wayne used his column in _WWIVnews_ to explain his
policies regarding the registration of the netup program, as well as
his views on starting an alternative WWIV network. Wayne stressed that starting
a network wasn't all fun and games, and that it was a lot of thankless work
that took real dedication. Granted, a network coordinator's job possesses a
bit of prestige included with the satisfaction of a job well done, but there's
a lot of labor and headaches that one must go through as well as part of the
process. Running a WWIV network - or any network, for that matter - takes a
lot of dedication and hard work, and those in it for the glory and the power
probably need not bother trying to register the network source.
To further discourage those without the proper commitment and motivations from
starting networks that would be doomed from the start, Wayne also announced
that the registration fee for the netup program would be $300. Despite the price
tag, several people made serious inquiries, and one in particular resulted in
IceNET. Other, more enterprising individuals decided that the price was too
steep, and began work on their own set of third-party WWIVnet-compatible
executables. The first of these, the Network Coordinator by Doctor Fred
(FREDnet 1@1, WWIVnet 1@9800) has already been announced on several of the
National-level sysop subs, and rumors are heard through the E-mail paths
of at least two other Coordinator-configurable shareware clones of EN1 and
DE1.EXE that are currently in beta-test.
So, it should really have come as no surprise that as soon as WWIV 4.21a was
declared a stable version, that there was a population explosion in the number
of alternative WWIV networks. Overnight we saw the births of WWIVgrid, GayNet,
DrakeNet, and several other specialized networks. IceNET itself saw a massive
jump in membership, and interest grew from within WWIVlink in making the
original alternative network a bit more accessible to the WWIVnet it left
behind in disgust.
However, there has been some question of late as to whether or not the global
WWIV community of sysops and users will actually benefit from this sudden
increase in the number of available networks. Most of the sysop subs on both
the national and local levels have seen an increase in traffic regarding this
topic, and while most of the conversation has been rather devoid of the
expected combustion, the conclusions reached have been rather mixed and
somewhat incomplete.
So, as you may have guessed by now, this retrospective is an introduction of
sorts for an official call for articles. The November WWIVnews - that's next
month's issue - will be a special issue dedicated to alternative WWIV-based
networks. The technical, operational and ethical aspects of this radically
new and advanced facet of WWIV networking will be analyzed in detail in an
attempt to present the world-wide WWIV community with as complete a set of
facts and figures as possible. With this information in hand, the future of
Multinetted WWIV can be plotted with a bit more ease than the usual shots in
the dark that we've reveled over in the past.
However, for this issue to become a reality, your help is needed. This is an
official call for articles and opinion pieces on the subject of alternative
WWIV networking and WWIV 4.21a's new Multi-Net capabilities. If you are a
Coordinator for an Area, Group, Server, Zone, or even an entire Network itself,
or even if you're just an average "Joe User" who likes to haunt the networks,
you are urged to contribute your views, opinions, knowledge and information
on any aspect of this special topic. Technical articles, operational analysis
and testimonials, opinion/editorial pieces, anything relating to this topic
are requested and welcomed.
The deadline for submissions is November 24th, with the issue being sent for
distribution the following night. Those wishing to submit articles for this
special issue are also urged to request a WWIVnews Writer's Guide by E-mailing
1@5282. This guide contains valuable information on how to compose, format and
submit articles for print in WWIVnews, and no sysop or user who has the urge
to write for a networked electronic newsletter should be without at least one
copy.
Again, your assistance is appreciated in this call for articles. If you know
of an NC, ZC, SC, GC, AC, or of someone who would definitely be able to
contribute to the topic, please feel free to drop them a copy of this editorial
and let them know what's going on. As not all alternative networks receive this
newsletter even though it's part of the general WWIVnet distribution, there's
always the possibility that someone won't hear the call for articles because
it wasn't directed their way.
See you in a month, and keep those e-mails and articles coming!
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Closing Credits ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ WWIVnews is an independent newsletter published monthly as a service to ³
³ the WWIV community of sysops and users. The opinions and reviews expressed³
³ herein are the expressed views of the respective writers, and do not ³
³ necessarily reflect those of the WWIVnews staff. Reproduction in whole or ³
³ in part is allowed provided proper credit is given. All rights reserved. ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ The distribution sites for WWIVnews are the Klingon Empire BBS (512-459- ³
³ 1088), WWIVnet node @5282, and the WWIVnews Editorial Desk networked ³
³ subboard, subtype 15282 host 5282. Information regarding article and ³
³ editorial submissions, back issue requests, and the WWIVnews Writer's ³
³ Guide, can be requested in e-mail from the WWIVnews editor, 1@5282. ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ WWIV and WWIVnet, copyright 1986,1990 by Wayne Bell ³
³ Any product or company mentioned or reviewed herein are copyrighted of ³
³ their respective owners, creators, and other corporate pseudoentities. ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Reference in New Issue View Git Blame Copy Permalink