Ú¿Ú¿Ú¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿Ú¿ Ú¿ÚÄ¿ Ú¿ÚÄÄÄÄ¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿ ÉÍÍÍÍÍÍÍÍÍÍÍÍͳ³³³³³³³³³³³ÀÄ¿ÚÄÙ³³ ³³³ À¿³³³ÚÄÄÄÙ³³³³³³³ÚÄÄÄÙÍÍÍÍÍÍÍÍÍÍÍÍÍ» º 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... ). ÚÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³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] ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ Tackling DGROUP with ³ ³ External String Management ³ ³ by Elrond (8@4) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ DGROUP: The word alone is enough to send shivers down the spines of even the most experienced WWIV modders. To them, DGROUP conjures up living nightmares of installing complex modifications, only to wind up having to pull out their favorite (and largest) mods because they took up too much DGROUP space. For others, the less initiated, it brings up a several questions: For instance, what the heck is it, and how come everyone is always so caught up in it? And above all, how can I get rid of the problems it causes? Let's start from the beginning. Assuming that the vast majority of people out there really do not have even the slightest knowledge of Pascal, C, or Assembly, I will try and keep things simple. A program has several different segments of memory that are assigned to it. One of these segments is called the DGROUP, which is a group encompassing several memory segments that can be referred to as a single group. DGROUP is short for the (D)ATA GROUP, and it is where certain parts of the current (EXEC'ing) program are stored. I will not get into the sub-segments within the DGROUP, because it is enough to say that it holds parts of the program, which of course for us is WWIV. One of the major parts of any program's data is text. When a program is compiled, it is translated into the binary language (machine language) that your CPU can understand. Most of what goes into a program is actually ignored or simplified when a program is compiled, for the CPU has no use for this extra information. We only include it in our programs in order to increase the readability of the code. Addition, subtraction, variables, and the other common parts of your program are translated into their simple equivalent instructions that your CPU can understand. However, the text, or strings in your program cannot be translated to some simpler equivalent. If they were, then you obviously would not be able to read them. So, when a program is compiled, any text that gets sent to any device (be it the CRT, COM port, LPT port, whatever) is kept in its original state. If you have lots of text in your program (and BBS systems have a lot just by their very nature) then the DGROUP segment starts to get filled up rather quickly. Each character in a string takes up at least one byte of memory, so one thousand characters will take up about a kilobyte. Wayne was smart(?) enough to compile his program in a memory model that only allocates 64 kilobytes for the DGROUP segment. So, when you fill that up, your finished. No more modding. You get a compiler error, and so you are up against a brick wall. Right? To many sysops, this is exactly what they thought. If they did understand DGROUP, at least slightly, they would go rip out a big mod, like a time bank or a fancy file listing system. Then they could compile again, but they would be stuck without being able to install any more of the neat mods that come out every day. I can remember myself running around all the different support boards at the beginning of last summer looking for *SOMETHING* that would save me from that infernal compile message. I installed lots of little, very inefficient fixes - the DGROUP error went away for a mod or two, but then it was back to plague me again. Then one day Tolkien released ESM, and thus changed the way that people thought about DGROUP altogether. ESM, or External Strings Manager, is a program to help you cut down on the amount of DGROUP that WWIV takes up. The logic behind this is that if you can get the strings out of the program, and into an external file, then they will not have to be loaded every time the program is run. Whoever first came up with this idea (it was not an original) is someone we owe a lot to. With the strings out of the main program and in an external file, we virtually eliminate as much DGROUP space as we choose to - it all depends on how many strings we remove. ESM is very efficient (and FAST!!) at retrieving strings from the external file. Even on an 8 mhz. 286, there is hardly a noticeable delay while the call to get a string from the external file is executed. Plus, the ESM editor (for editing strings in your external strings file) makes it easy to change what a string says, and you don't even have to re-compile your BBS when you do it. There is only one major drawback with ESM, and that is it takes a long time to manually remove the strings from your source code and paste them into a strings file. This can take literally hours, if not DAYS, and it is a very slow and painstaking process. You cannot afford to screw up a string, or you'll wind up printing out the wrong one. That can look very funny, but is still a bit embarrassing. With the recent upgrades to ESM, however, this task can be done automatically with a special utility program (available only to registered ESM users). Using this utility, you can generate a strings file by letting the program go through and pull out the strings for you. Therefore, it is a very fast and effortless process. If you do not plan on registering ESM, there is an alternative. I have written a program which I call ASR, or Automatic Strings Remover, which does virtually the same thing. Best of all, it is free, like all the software that I write (and it looks neater, too, but that's just an opinion). A note on the side: There was a mod released some months ago onto the modnet which will allow WWIV to compile in a much larger memory model, and thus allow 1024 k of DGROUP. This will obviously be much more than you will probably ever use. But if you want my advice, I wouldn't install it. Here's why: It is way too unstandard. Installing this mod not only stops you from using the wonderful MAKE interface, but it also forces you to rewrite most of the routines in some of the major C files. Sure, the replacements are included, but they are very confusing, probably (no guarantees) not very well coded, and that much more difficult to deal with than the ESM/ASR combination. There also is the chance that other mods will conflict or not work at all with this one installed. All told, I suggest that you steer clear of it. If Wayne himself ever takes it upon himself to rewrite WWIV to support this memory model, then you we can all stop worrying about DGROUP, but that's just it - he hasn't. With ESM and its support programs, or with ESM and ASR, you can very easily eliminate those horrible DGROUP errors and get back to the business at hand, which is adding more mods, of course. Regardless of how good a modder you may be, sooner or later you will reach the limit of the DGROUP segment. Go grab ESM and ASR, install them, and then basically forget them. Then, go treat yourself by installing the biggest, most DGROUP consuming mod that you can find on the Modnet which you couldn't dare install before. Good luck with your modding! ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Where to obtain ESM and ASR: ESM, External Strings Manager Current version : 1.04 (shareware), 2.00 (registered) Author : Tolkien BBS name : The Fellowship WWIVnet : @3456 Phone number : (314) 664-5777 Auto Validation : YES WWIV support board : YES High speed modem : v32, v32bis, HST (14,400 and lower) ASR, Automatic Strings Remover Current version : 1.50 (freeware) Author : Ellrond BBS name : Silicon Valley WWIVnet : @9987 Phone number : (919) 765-8640 WWIV support board : NO Auto Validation : YES High speed modem : v32, v32bis, HST (14,400 and lower) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ 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 offerings contained three mods that really appealed to me. All three involved features that are already in NET32 but which are definitely needed in NET31 and v4.21 usage: a NETNAME in the name of the Sub, a NETNAME in E-mail response to user, and a force specific network callouts. The latter is the one that I have chosen to put here. This is another of Darrel Mobley's fine mods: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Mod Name: : DDM-0002.MOD Author : The Primerican #1 ³ ³ Difficulty : Moderate Network: WWIVnet @9402 ³ ³ WWIV Version : 4.21a Files : NETSUP.C ³ ³ ³ ³ Description : This mod allows you to force a callout to other ³ ³ network node numbers than your main network. 4.21a ³ ³ (9/12/92) does not check to see if you use the same node # ³ ³ CALLOUT4.21B in more than one network during Forced Callout "/". ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ What this does: I noticed from my WFC screen in the net pending list that if I had two nodes sharing the same number but were in different networks, the "/" Force Callout command would always force the callout to the node in the primary network. This is the second version of the mod. This will ONLY prompt you IF there are two nodes sharing the same node number within multiple networks on your system. The first mod asked the network to force from on each callout attempt, this one only asks for the network if it finds more than one network sharing the same node number. On with the mod. Disclaimer: Why bother? You KNOW to back up your source! Grin. Replace the entire void "force_callout(void)" with this void: void force_callout(void) { int i,i1,i2,i3,index,ok,sn,nn; int nv,onxi,odci,abort; float fl,fl1,fl2,ffl; long l,l1; char ch,s[81],s1[81]; char *ss,onx[20],*mmk; struct time ti; net_system_list_rec *csne; time(&l); nl(); prt(2,"Which system? "); input(s,5); sn=atoi(s); abort=0; if (sn && (net_num_max>1)) { odc[0]=0; odci=0; onx[0]='Q'; onx[1]=0; onxi=1; nv=0; ss=malloc(net_num_max); for (nn=0; nnname); } } pl("Q. Quit"); nl(); prt(2,"Which network (number)? "); if (nv<9) { ch=onek(onx); if (ch=='Q') i=-1; else i=ch-'1'; } else { mmk=mmkey(2); if (*mmk=='Q') i=-1; else i=atoi(mmk)-1; } if ((i>=0) && (i