synchro.net

home *** CD-ROM | disk | FTP | other *** search

/ synchro.net / synchro.net.tar / synchro.net / main / TEXT / WWIV9210.TXT < prev next >

Wrap

Text File | 2001-07-30 | 56.1 KB | 1,037 lines

┌┐┌┐┌┐┌┐┌┐┌┐┌────┐┌┐ ┌┐┌─┐ ┌┐┌────┐┌┐┌┐┌┐┌────┐ ╔═════════════││││││││││││└─┐┌─┘││ │││ └┐│││┌───┘│││││││┌───┘═════════════╗ ║ 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. │ └───────────────────────────────────────────────────────────────────────────┘