ftp.wwiv.com/ftp.wwiv.com.zip/ftp.wwiv.com/pub/HATCH/WWIVNEWS.ZIP/9209_1.NWS

Text File | 1992-09-29 | 21KB | 344 lines

                ┌┐┌┐┌┐┌┐┌┐┌┐┌────┐┌┐  ┌┐┌─┐ ┌┐┌────┐┌┐┌┐┌┐┌────┐
  ╔═════════════││││││││││││└─┐┌─┘││  │││ └┐│││┌───┘│││││││┌───┘═════════════╗
  ║  Volume 3   ││││││││││││  ││  └┼┐┌┼┘│  └┘││└───┐│││││││└───┐ September 28║
  ║   Issue 5   ││││││││││││  ││   ││││ │┌┐  ││┌───┘││││││└───┐│    1992     ║
  ╚═════════╤═══│└┘└┘││└┘└┘│┌─┘└─┐ └┼┼┘ ││└┐ ││└───┐│└┘└┘│┌───┘│═══╤═════════╝
            │   └────┘└────┘└────┘  └┘  └┘ └─┘└────┘└────┘└────┘   │
            │ Serving WWIV Sysops & Users Across All WWIV Networks │
            └──────────────────────────────────────────────────────┘
                           ┌─────────────────────┐
                           │This Month's Features│
┌──────────────────────────┴─────────────────────┴────────────────────────────┐
│ Random Factors.......................................Wayne Bell (1@1)       │
│                                                                             │
│ TechnOTES............................................WWIVnews Staff         │
│                                                                             │
│ Squashing Those Gluttony .GIF's (Part 1).............Spackle (1@1995)       │
│                                                                             │
│ Tackling DGROUP with External String Management......Elrond (8@4)           │
│                                                                             │
│ Filo's Mod of the Month..............................Filo (1@5252)          │
│                                                                             │
│ Dateline: @#$*()#!...................................Omega Man (1@5282)     │
└─────────────────────────────────────────────────────────────────────────────┘

───────────────┬─────────────────────────────────────────────┬───────────────
               │               Random Factors                │
               │   Creative Commentary by Wayne Bell (1@1)   │
               └─────────────────────────────────────────────┘

A few comments on the future directions of WWIV and WWIVnet:

The next version of WWIV will be v4.22, out probably around the beginning of
the year. It will support gating subs among networks, and subboards by name
(up to 7 chars, not starting with a digit), in addition to subs by numeric
type. (That part is already done and seems to be working - and requires net32)

I also plan on redoing the userlist, to have, in the standard structure, most
of the things that people have been adding (address, that kind of thing).
Quickscan pointers will, however, be stored in a different file. This will
allow up to 999 subs and 999 dirs in the BBS. There will be an option in INIT
to allow you to specify the max # subs/dirs, and will reformat the quickscan
file for that new number. Note that specifying more subs uses up more memory.

Net32 should be out in a month or so. It will have the new support for subs by
name, and sub gating (but requires v4.22 for that to work). There have also
been a bunch of fixes and requested enhancements (the network name is now in
the net.log file, for one).  It should also run somewhat faster unpacking
local mail, should work with multi-line systems better, will gate email, and
filter out duplicate posts.

Also, to restate a previous position of mine, please do not start up your own
network unless A) you know what you're doing and how to run it, >AND< B) it
will really be different than a currently-existing network in some way.

───────────────┬─────────────────────────────────────────────┬───────────────
               │                 TechnOTES                   │
               │        Compiled by the WWIVnews Staff       │
               └─────────────────────────────────────────────┘

...While McAfee and Norton continue to wage war against computer viruses
through software protection methods, until now the only way to prevent
infection through hardware means was to use write-protect tabs for their
only known use. Multix of Dallas, Tx has developed the ViruStop, a bus card
that offers antiviral protection by monitoring data crossing the system bus
for signs of viral activity.

...The ViruStop is an 8-bit short card that plugs into any free slot, and is
automatically invoked after the system BIOS is uploaded. Acting as a filter
of sorts, the ViruStop inspects all data prior to being processed, regardless
of whether it's operating systems, programs, or system data. Since all viruses
possess certain common characteristics, ViruStop is designed to take note of
these danger signs and other peculiar behavior patterns and suspend operations
and notifies the user of a probable viral presence.

...Since ViruStop is not a memory-resident program, and requires no TSR's or
software interface, there is no loss of RAM occurred when installed. Also,
since the bus itself is monitored directly as opposed to scanning the RAM and
peripheral memory devices (as most software-based scanning utilities do),
there is no perceivable loss of system performance caused by ViruStop.

...a side nOTE about ViruStop: word down the pipeline hints that certain
manufacturers may be offering the card as a standard feature on their new
systems. Multix reportedly has also been approached by Gateway regarding an
local bus version of the ViruStop for a new line of local bus motherboards.
As viruses can only infect through certain methods inherent to DOS that will
probably not change anytime in the near future, no upgrade to the ViruStop
will be necessary.

...ok, admit it. You've gone "ooh!" and "aaah!" and "c00l, d00d!" when you
saw those "Intel Inside" ads on TV. You have, we have, everyone has. And
with good reason, too. They're visually striking any way you look at them.
But answer this one honestly: Have these ads actually influenced your new
system purchases? According to several industry sources, the answer is
"probably not."

...Despite all the ads and hype about the satisfaction and peace of mind
one can have by using only Intel chips, most system retailers are reporting
very few specific inquiries regarding whether the processors are Intol or
not. One Computerland employee, who asked to remain nameless, commented that
"those few who do inquire in most cases turn out to be novice computer users
who obviously don't raid the fridge during the commercial breaks!"

...While the ads havn't exactly increased Intel's sales as dramatically as
Intel had hoped, computer retailers are reporting that while users aren't
turning a deaf ear and a blind eye to alternative processors, they are
showing an increasing interest in the capabilites of Intel's DX2 series of
chips. The added cost of purchasing a system with an processor manufactured
by Intel becomes a moot point only when the performance exceeds that of
the competition. Thus, the bottom line appears to be that consumers are more
interested in purchasing systems with processors with the highest performance
and the lowest cost, regardless of who manufactured them.

...One of the benefits of an internal modem is that you don't have to worry
about spilling your coffee on it in the morning. However, in exchange for
that peace of mind, you usually have to sacrifice those fancy external
readouts that not only tell you how fast your modem is leeching wares from
every BBS on your dialing directory, but impress your computer-illiterate
as well.

...Image Communications, creators of the Twincom line of modems, has provided
a solution for this dilimma. The "Twincom Dashboard" is a modem add-on that
provides the company's 14.4DFI (v32bis 14.4k internal fax/modem) with an
external status readout. This readout consists of 20 LED's. 8 of which display
the status of the basic modem functions, while the remaining 12 are used as
a "speed indicator" for data transfer rates. The Dashboard connects to the DFI
via a cable, and is available for mounting in two versions: attachment with a
Velcro strip, or molded to a face plate for mounting in a spare drive bay.

...At press time, the Dashboard works only with the Twincom DFI, but the
company is looking into adapting it to the other modems in the Twincom line
depending on consumer demand. Price was also not set at press time, but
is expected to be $79 direct from the company.

...Interested in a CD-ROM drive for your board? Then take nOTE of this: DAK
has lowered the price of the BSR 6800MX to $199. No, that's not a misprint,
either. This is reputed to be the lowest price yet for a CD-ROM drive, and
reports from DAK are that the drives are selling like hotcakes. Oddly enough,
this shouldn't come as too much of a surprise, as DAK's founder Drew Kaplan
has been both a data and audio CD-ROM advocate for quite some time.

...There's a good and a bad side to these drives, however. While they will
play regular audio CD's, the access time for data CD's is a somewhat limping
800 milliseconds - just 200ms under the Multimedia Council's specifications.
Considering the rest of the industry is gearing up for a standard access time
roughly half that of the 6800MX, this may seem a bit slow for those needing
faster access times. In fact, those who need real-time motion video playback
probably would be better off with a faster (and more expensive) drive.

...Still, for BBS usage, 800ms isn't too slow at all. To be honest, DAK's BSR
deal might be a godsend to those wishing to provide their users with as much
data as possible. With several shareware collections and periodical collectons
available on CD-ROM, each respectively containing several hundred of the latest
public domain programs and several years worth of hundreds of periodical runs,
keeping the ware leeches and info addicts happy might have become a bit easier
for sysops everywhere.

───────────────┬─────────────────────────────────────────────┬───────────────
               │  Squashing Those Gluttony .GIF's (Part 1)   │
               │             By Spackle (1@1995)             │
               └─────────────────────────────────────────────┘

This article begins 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.

──────────────────────────────────────────────────────────────────────────────

GIF Compression: The Basic Archiving Methods
────────────────────────────────────────────

So you've got a kajillion of those great-looking GIF files lying around taking
up disk space. Sure, they're always there to look at, and anyone can download
them, but what if you need to install the new Borland C++ 3.0?  I have heard
rumor to the effect that this compiling masterpiece takes up a robust 30-or-so
megs of disk space... That's a lot of space, even with today's standard 100-
and 200-meg drives. So what do you do if you want still more out of your hard
disk?  We'll explore the options here, as well as the good and bad points of
each method.

There are three basic roads you can travel... Here are a few ideas that we'll
be looking at:

  1. You can archive them using one of the many popular archiving programs
     such as PKZIP, LHA (formerly called LHARC), or ARJ.

  2. You can use GIFLITE to compress the GIF by removing the non-essential
     video information. This option allows the GIF to remain a GIF (an
     8-bit format), thereby making viewing easy.

  3. You can also use GIF2JPEG to remove non-essential information, as
     defined by the Joint Photographic Experts Group. (For more information
     regarding the JPEG standard, write to the address at the end of this
     article.)  However, JPEG is a 24-bit format and is therefore unviewable
     on practically anything but a TARGA card or a PS/2 with an XGA card.

Let's explore each of those at length...

The Archiving Method:
─────────────────────

The idea behind archiving is simple: you put files you don't necessarily need
right away into another file, which is a compressed version of the originals.
That having been said, here's a tiny comparison of the three most popular
archiving programs, PKZip, LHA (LHARC), and ARJ:

This is a directory listing of the GIF files being archived, as well as their
respective resolutions (given as Height X Width X Number of Colors):

  Filename.EXT    Size    Date     Time    Resolution
  ────────────   ──────  ──────── ──────   ─────────────
  3babes.gif     260608   6-06-90  3:52p   (640x480x256)
  calvin2.gif      8192  11-27-90 11:45a   (320x200x16)
  claudia.gif    107520   3-08-92 11:15p   (607x774x16)
  waterfal.gif    22144  10-04-89 12:47p   (576x360x4)  (interlaced)

  (Total size: 398464 bytes)

These four files were chosen as representative because there are two "standard"
GIFs (one VGA and one Super-VGA) and two odd-sized/colored ones (last two), as
well as the disk size of the GIFs (one huge, one large, one average, and one
tiny one).

For reference (i.e. where the GIFs originated), I will give short descriptions
of the files:

  3BABES  .GIF - Three bikini-clad women - digitized video or photograph
  CALVIN2 .GIF - Calvin from Calvin & Hobbes cartoon - scanned or drawn
  CLAUDIA .GIF - Claudia Shiffer - scanned image (probably retouched)
  WATERFAL.GIF - Scanned image of Escher's waterfall - INTERLACED image

Now here's a comparison of the various archives (ZIP, LZH, and ARJ) when each
of these files was added to its own archive:

  Filename.EXT    Size     Date    Time   Time to archive
  ────────────   ──────   ───────  ─────  ───────────────
  testgifs.arj   393634   6-11-92  6:38p      2:21.86
  testgifs.lzh   393252   6-11-92  6:34p      2:01.00
  testgifs.zip   398878   6-11-92  6:36p      0:59.21

As you can see, LHA does the tightest compression, with ARJ close behind.
PKZIP doesn't quite compare, but makes up for this with much faster
compression. In fact, PKZIP _ADDS_ to the size of the GIFs. That being the
case, if you're simply archiving and looking for more drive space, LHA is a
clear winner; if you're looking to save time and don't care about space, PKZIP
wins hands-down. ARJ fits somewhere in between those two. I use LHA myself for
everything but files needing PKZIP's -AV codes (such as McAfee's Viruscan,
Clean, etc.).

However, archiving has the downside that you can't load up CompuShow and view
the GIFs... you have to unarchive them first. Unarchiving with LHA and ZIP
takes essentially the same amount of time, with ARJ falling slightly behind.
Still, that's an added inconvenience. Let's look at another method of GIF
compression: GIFLITE.


The GIFLITE Method:
───────────────────

GIFLITE is a GIF compression program that basically filters out unnecessary
(or non-visible) image information. The documentation for GIFLITE does not
mention any special compression algorithms; therefore, it is my understanding
that it only removes non-vital information from the image. The difference
in GIFLITE-compressed and non-compressed images is usually not detectable by
the human eye. Therefore, GIFLITE may be considered "safe" to use, in that
the before- and after-compression images look virtually alike. There are
exceptions to this rule, however. Large, complex GIFs (1024x768x256 SVGA,
for example) tend to not only take forever to compress, they lose some of
their information. Still, at 35-50% compression, few people will harp over
a slight image quality loss.

GIFLITE also offers three different methods of compression. You can specify
these with the -mX parameter, where X is 1, 2, or 3. Method 1 (the default
if none is specified) produces an output file with maximum compression. Method
2 produces a less-compressed file, and Method 3 produces a least-compressed
file. For most GIFs, the output images are almost identical to the source
images. For some images, however, such as hand-drawn images, or images with
detailed texture, Method 2 and Method 3 will preserve more of the quality of
the original images.

GIFLITE is easy to use and useful, but if you want a backup of the original
GIF, you will either need to make a COPY, or GIFLITE can make one for you if
you use the -b parameter. If this copy is lost, however, there is no recourse
for getting it back. GIFLITE compression is irreversible, which means that you
cannot compress and then uncompress a GIF to its original state.

The upside to all this is that the image quality is almost always intact. You
can readily view the compressed image as if it was any other GIF, and there's
also the fact that you've saved yourself some precious disk space.

That having been said, let's take a look at our sample files. We'll make a
chart to show their original sizes, the post-compression size, the percent size
reduction, the time for compression, and a small comment on any post-
compression image degradation, if I can detect any (I have 20/20 or better
vision in both eyes... <grin>).

  ┌─────────┬───────────────┬───────────────┬──────────────┬──────────────┐
  │GIF File │  3BABES.GIF   │ CALVIN2.GIF   │ CLAUDIA.GIF  │ WATERFAL.GIF │
  │Resolut. │ (640x480x256) │ (320x200x16)  │ (607x774x16) │ (576x360x4)  │
  ├─────────┼───────────────┼───────────────┼──────────────┼──────────────┤
  │Method 1 │WAS  260.61 Kb │WAS  8.19 Kb   │UNREGISTERED  │WAS  22.14 Kb │
  │         │NOW  165.59 Kb │NOW  7.61 Kb   │VERSION WILL  │NOW  21.76 Kb │
  │ Redux   │36.4% reduction│7.0% reduction │NOT COMPRESS  │1.7% reduction│
  │ Time    │Time: 11:59.09 │Time:  2:02.05 │IMAGES BIGGER │Time: 22:40.29│
  │ Loss?   │Minimal loss   │No visible loss│THAN 640x480  │No loss at all│
  ├─────────┼───────────────┼───────────────┼──────────────┼──────────────┤
  │Method 2 │WAS  260.61 Kb │WAS  8.19 Kb   │UNREGISTERED  │WAS  22.14 Kb │
  │         │NOW  192.10 Kb │NOW  7.61 Kb   │VERSION WILL  │NOW  21.76 Kb │
  │ Redux   │26.2% reduction│7.0% reduction │NOT COMPRESS  │1.7% reduction│
  │ Time    │Time:  9:41.88 │Time:  2:00.78 │IMAGES BIGGER │Time: 22:39.40│
  │ Loss?   │Minimal loss   │None visible   │THAN 640X480  │No loss at all│
  ├─────────┼───────────────┼───────────────┼──────────────┼──────────────┤
  │Method 3 │WAS  260.61 Kb │WAS  8.19 Kb   │UNREGISTERED  │WAS  22.14 Kb │
  │         │NOW  204.54 Kb │NOW  7.61 Kb   │VERSION WILL  │NOW  21.76 Kb │
  │ Redux   │21.5% reduction│7.0% reduction │NOT COMPRESS  │1.7% reduction│
  │ Time    │Time:  8:00.26 │Time:  2:00.67 │IMAGES BIGGER │Time: 22:39.68│
  │ Loss?   │None detectable│None visible   │THAN 640X480  │No loss at all│
  └─────────┴───────────────┴───────────────┴──────────────┴──────────────┘

As you can see from the chart, the three compression Methods are really quite
similar for animated or digitized images, just as the documentation says.
Scanned and retouched or hand-drawn images receive quite a bit of attention,
and "suffer" a might bit of compression as well. Unfortunately, unregistered
versions of GIFLITE will not compress images greater than 640x480, so no
information is given for CLAUDIA.GIF. (Had I known that when I started this
project, I would have chosen another file.)  However, it goes to illustrate
the idea behind Shareware, which is that you should register and pay for those
programs that you use, and the fact that not all GIFs are created equal, and
none have inalienable rights to your disk space.

I can also mention that these results are quite different from the AVERAGE I
have gotten from all the compressions I've done on my board. Most of my GIFs
are like 3BABES - scanned and digitized. Those result in the biggest gains. And
when you consider a board like mine, with over 80 megs and 500 files of just
GIFs, even a small gain of 10Kb per file compressed gives an extra half a meg
of disk space. Consider also that the average percent reduction is 35-50% on
most GIFs; Think about gaining an extra 35% of your disk space back!

[To be continued in next month's issue of WWIVnews]