ftp.wwiv.com

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

/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / HATCH / WWIVNEWS.ZIP / 9605_2.NWS < prev

Wrap

Text File | 1996-05-25 | 41KB | 887 lines

───────────────┬─────────────────────────────────────────────┬─────────────── │ Understanding Viruses │ │ Compiled by Sam (1@2863) │ └─────────────────────────────────────────────┘ [This was taken from an FAQ I picked up on the net. It is a rather large article, which I'm posting in parts over several newsletters.] = Protection Against Viruses = ══════════════════════════ What is the best protection policy for my computer? There is no "best" anti-virus policy. In particular, there is no program that can magically protect you against all viruses. But you can design an anti-virus protection strategy based on multiple layers of defense. There are three main kinds of anti-viral software, plus several other means of protection (such as hardware write-protect methods). 1) GENERIC MONITORING programs. These try to prevent viral activity before it happens, such as attempts to write to another executable, reformat the disk, etc. Examples: SECURE and FluShot+ (PC), and GateKeeper (Macintosh). 2) SCANNERS. Most look for known virus strings (byte sequences which occur in known viruses, but hopefully not in legitimate software) or patterns, but a few use heuristic techniques to recognize viral code. A scanner may be designed to examine specified disks or files on demand, or it may be resident, examining each program which is about to be executed. Most scanners also include virus removers. Examples: FindViru in Dr Solomon's Anti-Virus Toolkit, FRISK's F-Prot, McAfee's VIRUSCAN (all PC), Disinfectant (Macintosh). Resident scanners: McAfee's V-Shield, and VIRSTOP. Heuristic scanners: the Analyze module in FRISK's F-PROT package, and SCANBOOT. 3) INTEGRITY CHECKERS or MODIFICATION DETECTORS. These compute a small "checksum" or "hash value" (usually CRC or cryptographic) for files when they are presumably uninfected, and later compare newly calculated values with the original ones to see if the files have been modified. This catches unknown viruses as well as known ones and thus provides *generic* detection. On the other hand, modifications can also be due to reasons other than viruses. Usually, it is up to the user to decide which modifications are intentional and which might be due to viruses, although a few products give the user help in making this decision. As in the case of scanners, integrity checkers may be called to checksum entire disks or specified files on demand, or they may be resident, checking each program which is about to be executed (the latter is sometimes called an INTEGRITY SHELL). A third implementation is as a SELF-TEST, i.e. the checksumming code is attached to each executable file so that it checks itself just before execution. Examples: Fred Cohen's ASP Integrity Toolkit (commercial), and Integrity Master and VDS (shareware), all for the PC. 3a) A few modification detectors come with GENERIC DISINFECTION. I.e., sufficient information is saved for each file that it can be restored to its original state in the case of the great majority of viral infections, even if the virus is unknown. Examples: V-Analyst 3 (BRM Technologies, Israel), marketed in the US as Untouchable (by Fifth Generation), and the VGUARD module of V-care. Of course, only a few examples of each type have been given. All of them can find their place in the protection against computer viruses, but you should appreciate the limitations of each method, along with system-supplied security measures that may or may not be helpful in defeating viruses. Ideally, you would arrange a combination of methods that cover the loopholes between them. A typical PC installation might include a protection system on the hard disk's MBR to protect against viruses at load time (ideally this would be hardware or in BIOS, but software methods such as DiskSecure and PanSoft's Immunize are pretty good). This would be followed by resident virus detectors loaded as part of the machine's startup (CONFIG.SYS or AUTOEXEC.BAT), such as FluShot+ and/or VirStop together with ScanBoot. A scanner such as F-Prot or McAfee's SCAN could be put into AUTOEXEC.BAT to look for viruses as you start up, but this may be a problem if you have a large disk to check (or don't reboot often enough). Most importantly, new files should be scanned as they arrive on the system. If your system has DR DOS installed, you should use the PASSWORD command to write-protect all system executables and utilities. If you have Stacker or SuperStore, you can get some improved security from these compressed drives, but also a risk that those viruses stupid enough to directly write to the disk could do much more damage than normal; using a software write-protect system (such as provided with Disk Manager or Norton Utilities) may help, but the best solution (if possible) is to put all executables on a disk of their own, protected by a hardware read-only system that sounds an alarm if a write is attempted. If you do use a resident BSI detector or a scan-while-you-copy detector, it is important to trace back any infected diskette to its source; the reason why viruses survive so well is that usually you cannot do this, because the infection is found long after the infecting diskette has been forgotten with most people's lax scanning policies. Organizations should devise and implement a careful policy, that may include a system of vetting new software brought into the building and free virus detectors for home machines of employees/students/etc who take work home with them. Other anti-viral techniques include: (a) Creation of a special MBR to make the hard disk inaccessible when booting from a diskette (the latter is useful since booting from a diskette will normally bypass the protection in the CONFIG.SYS and AUTOEXEC.BAT files of the hard disk). Example: GUARD. (b) Use of Artificial Intelligence to learn about new viruses and extract scan patterns for them. Examples: V-Care (CSA Interprint, Israel; distributed in the U.S. by Sela Consultants Corp.), Victor Charlie (Bangkok Security Associates, Thailand; distributed in the US by Computer Security Associates). (c) Encryption of files (with decryption before execution). Is it possible to protect a computer system with only software? Not perfectly; however, software defenses can significantly reduce your risk of being affected by viruses WHEN APPLIED APPROPRIATELY. All virus defense systems are tools - each with their own capabilities and limitations. Learn how your system works and be sure to work within its limitations. From a software standpoint, a very high level of protection/detection can be achieved with only software, using a layered approach. 1) ROM BIOS - password (access control) and selection of boot disk. (Some may consider this hardware.) 2) Boot sectors - integrity management and change detection. 3) OS programs - integrity management of existing programs, scanning of unknown programs. Requirement of authentication values for any new or transmitted software. 4) Locks that prevent writing to a fixed or floppy disk. As each layer is added, invasion without detection becomes more difficult. However complete protection against any possible attack cannot be provided without dedicating the computer to pre-existing or unique tasks. The international standardization of the world on the IBM PC architecture is both its greatest asset and its greatest vulnerability. Is it possible to write-protect the hard disk with only software? The answer is no. There are several programs which claim to do that, but *all* of them can be bypassed using only the currently known techniques that are used by some viruses. Therefore you should never rely on such programs *alone*, although they can be useful in combination with other anti-viral measures. What can be done with hardware protection? Hardware protection can accomplish various things, including: write protection for hard disk drives, memory protection, monitoring and trapping unauthorized system calls, etc. Again, no tool is foolproof. The popular idea of write-protection may stop viruses spreading to the disk that is protected, but doesn't, in itself, prevent a virus from running. Also, some of the existing hardware protections can be easily bypassed, fooled, or disconnected, if the virus writer knows them well and designs a virus which is aware of the particular defense. Will setting DOS file attributes to READ ONLY protect them from viruses? No. While the Read Only attribute will protect your files from a few viruses, most simply override it, and infect normally. So, while setting executable files to Read Only is not a bad idea, it is certainly not a thorough protection against viruses! Will password/access control systems protect my files from viruses? All password and other access control systems are designed to protect the user's data from other users and/or their programs. Remember, however, that when you execute an infected program the virus in it will gain your current rights/privileges. Therefore, if the access control system provides *you* the right to modify some files, it will provide it to the virus too. Note that this does not depend on the operating system used - DOS, Unix, or whatever. Therefore, an access control system will protect your files from viruses no better than it protects them from you. Under DOS and Windows 95, there is no memory protection, so a virus could disable the access control system in memory, or even patch the operating system itself. On the more advanced operating systems (Unix and OS/2) this is not possible, so at least the protection cannot be disabled by a virus. However it will still spread, due to the reasons noted above. In general, the access control systems (if implemented correctly) are able only to slow down the virus spread, not to eliminate viruses entirely. Of course, it's better to have access control than not to have it at all. Just be sure not to develop a false sense of security and to rely *entirely* on the access control system to protect you. Will the protection systems in DR DOS work against viruses? Partially. Neither the password file/directory protection available from DR DOS version 5 onwards, nor the secure disk partitions introduced in DR DOS 6 are intended to combat viruses, but they do to some extent. If you have DR DOS, it is very wise to password-protect your files (to stop accidental damage too), but don't depend on it as the only means of defense. The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM) will stop more viruses than the plain DOS attribute facility, but that isn't saying much! The combination of the password system plus a disk compression system may be more secure (because to bypass the password system they must access the disk directly, but under SuperStore or Stacker the physical disk is meaningless to the virus). There may be some viruses which, rather than invisibly infecting files on compressed disks in fact very visibly corrupt the disk. The "secure disk partitions" system introduced with DR DOS 6 may be of some help against a few viruses that look for DOS partitions on a disk. The main use is in stopping people fiddling with (and infecting) your hard disk while you are away. Furthermore, DR DOS is not very compatible with MS/PC-DOS, especially down to the low-level tricks that some viruses are using. For instance, some internal memory structures are "read-only" in the sense that they are constantly updated (for DOS compatibility) but not really used by DR DOS, so that even if a sophisticated virus modifies them, this does not have any effect. In general, using a less compatible system diminishes the number of viruses that can infect it. For instance, the introduction of hard disks made the Brain virus almost disappear; the introduction of 80286 and DOS 4.x+ made the Yale and Ping Pong viruses extinct, and so on. And there are only about 35 viruses that plague the Macintosh's, while there are over 7,000 known to the PC world. Will a write-protect tab on a floppy disk stop viruses? In general, yes. The write-protection on IBM PC (and compatible) and Macintosh floppy disk drives is implemented in hardware, not software, so viruses cannot infect a diskette when the write-protection mechanism is functioning properly. But remember: (a) A computer may have a faulty write-protect system (this happens!) - you can test it by trying to copy a file to the diskette when it is presumably write- protected. (b) Someone may have removed the tab for a while, allowing a virus on. (c) The files may have been infected before the disk was protected. Even some diskettes "straight from the factory" have been known to be infected in the production processes. So it is worthwhile scanning even write-protected disks for viruses. Do local area networks (LANs) help to stop viruses or do they facilitate their spread? Both. A set of computers connected in a well managed LAN, with carefully established security settings, with minimal privileges for each user, and without a transitive path of information flow between the users (i.e., the objects writable by any of the users are not readable by any of the others) is more virus-resistant than the same set of computers if they are not intercon- nected. The reason is that when all computers have (read-only) access to a common pool of executable programs, there is usually less need for diskette swapping and software exchange between them, and therefore less ways through which a virus could spread. However, if the LAN is not well managed, with lax security, it could help a virus to spread like wildfire. It might even be impossible to remove the infection without shutting down the entire LAN. A network that supports login scripting is inherently more resistant to viruses than one that does not, if this is used to validate the client before allowing access to the network. What is the proper way to make backups? Data and text files, and programs in source form, should be backed up each time they are modified. However, the only backups you should keep of COM, EXE and other *executable* files are the *original* versions, since if you back up an executable file on your hard disk over and over, it may have become infected meanwhile, so that you may no longer have an uninfected backup of that file. Therefore: 1. If you've downloaded shareware, copy it (preferably as a ZIP or other original archive file) onto your backup medium and do not re-back it up later. 2. If you have purchased commercial software, it's best to create a ZIP (or other) archive from the original diskettes (assuming they're not copy protected) and transfer the archive onto that medium. Again, do not re-backup. 3. If you write your own programs, back up only the latest version of the *source* programs. Depend on recompilation to reproduce the executables. 4. If an executable has been replaced by a new version, then of course you will want to keep a backup of the new version. However, if it has been modified as a result of your having changed configuration information, it seems safer *not* to back up the modified file; you can always re-configure the backup p copy later if you have to. 5. Theoretically, source programs could be infected, but until such a virus is discovered, it seems preferable to treat such files as non-executables and back them up whenever you modify them. The same advice is probably appropriate for batch files as well, despite the fact that a few batch file infectors have been discovered. The next issue will deal with facts and fibs about computer viruses -=■=- ───────────────┬─────────────────────────────────────────────┬─────────────── │ Type 2/0 Forum │ │ Edited by Sam (1@2863) │ └─────────────────────────────────────────────┘ Have a comment? Got a beef? Wanna issue long-overdue kudos? Here is the for it! Send your letters/comments/questions to Sam, 1@2863, for publication in WWIVNews. ───────────────┬─────────────────────────────────────────────┬─────────────── │ Netlimit: Good or Bad │ │ Editorial Commentary By Sam (1@2863) │ └─────────────────────────────────────────────┘ Note: The author of Netlimit was invited to submit his comments for this article but did not do so. Recently the talk on all the major sysop subs has been fueled by the controversy surrounding a program called Netlimit. For anyone who does not know, Netlimit is a program that is used to prevent nodes (referred to here as a "limited" node) that connect to and depend upon another node for their network packets (referred to here as a "limiting" node) from being able to receive any subs other than those permitted by the limiting node. Netlimit analyzes and traps any sub requests sent out from the limited node, and any sub add requests coming into the limited node from outside nodes wishing to subscribe to subs hosted by the limited node (again, other than those express- ly permitted by the limiting node). Since Netlimit does not block email, limited nodes are still free to email requests to be added to subs, but when Netlimit detects that this has occurred, it will then attempt to send out an auto-drop packet in an effort to de-subscribe the limited node from the sub they are receiving. The idea behind Netlimit is noble. It is designed to prevent the limited nodes from being able to have a free ride at someone else's expense. Without Netlimit being in place, end nodes are completely free to pick up as many subs as they like. If they are not the ones doing the long-distance callout to pick up the network packets, that forces another person to have to pay to pick up the packets for them. In the perverse entitlement-mindset of today's society, one would think that a program such as Netlimit would be welcomed with open arms. But that has not happened. And with good reason. WWIVNet is not a social experiment gone haywire, ala The Great Society. It is a private network, supported by a group of private sysops. While none of them should be expected to have to pay to support the hobby of another, allowing programs on the network that, in reality automate censorship, is not the right answer to the problem. Those who defend Netlimit's use claim that it's better to have Netlimit in place so that the limited nodes can at least have email and the subs permitted by the sysop calling out to pick up the network packets. On the surface, that seems all well and good. In reality it is censorship, and such programs can lead to devastation of the network. Assume I have a distaste for liberals. Assume I have 25 connections to me, and that each of those nodes have three connections. They may have other connections too, but through me, then through those 25 connections, four liberal-oriented subs get sent to 75 nodes downstream of me. Using Netlimit, I could easily block all of those nodes from receiving those subs. Further, by editing the outbound packet (with the Netlimit SSM's <or whatever>) in it, I could prevent anyone from ever knowing what happened. Netlimit supporters say that that is possible right now. While this is a true statement, it wold require hours of tedious work using lnet (or similar program) and manual intervention on the part of the sysop on each and every transient packet routed through his or her node. By using Netlimit, the process can be set up once and forgotten about. Netlimit supporters claim the network documentation allows them to limit the amount of traffic end nodes may pick up. This is true. But network policy also expressly states that transient packets (those coming through a node but that are not addressed for that node) may not be tampered with (other than to prevent file transfers via the net) which is exactly what Netlimit and programs like it do...tamper with packets. Based on these two points (one which allows a sysop to limit what a node may receive through him, and one which states that transient packets may not be tampered with) one can only conclude that when the policy was written, it was intended to mean that a sysop who carries the long distance traffic for another node may require that node to either limit what he subscribes to, pay a fee, or find another connection. Nowhere does it state in the network policy that the transient packets may be edited (other than as previously stated) in order to limit network traffic. The final decision regarding the future of Netlimit and other renegade software like it rests in the hands of Wayne. Presently, the use of Netlimit seems to be fairly confined to the 310 area code. They are set to have a meeting in early May to discuss the future of network traffic in that area. Let's hope for the good of everyone involved that they use their heads and come up with the right solution and stop tampering with transient network packets. For once a policy is put in place that allows for such events to occur, the beginning of the end of WWIVNet will be set into motion. -=■=- ───────────────┬─────────────────────────────────────────────┬─────────────── │ Filo's Mod of the Month │ │ by Filo (1@4000) │ └─────────────────────────────────────────────┘ The Mod of the Month is selected by Filo and represents his choice of what appears to be the most promising mod posted during the past month on Mod Net (subtype 2370). UUencoded mods are not considered for selection as part of the mod of the month due to the difficulty of including them in the WWIVnews. Mods which involve the use of related files such as ENHANCE.C, or any of the various COMMON type files are also not considered due to the amount of space required to include them here. Many of these mods have NOT been tested by Filo and are selected based on their description as a promising, practical mod. This month's selection is written by Frank Reid. ┌───────────────────────────────────────────────────────────────────────────┐ │ Mod Name: FR054.MOD Mod Author: Frank Reid WWIVnet @8213 │ │ Difficulty: Intermediate Date: March 4, 1996 │ │ WWIV Version: 4.24a │ │ Description: Searches for sub posts directed at user (a "To:" kludge). │ └───────────────────────────────────────────────────────────────────────────┘ 1. Back up your source! I take NO responsibility for ill effects of this or any of my mods. I'd be happy to help you get it working, though. This is a very tricky mod, at least in its interface with user qscan and such! 2. Description: WWIV lacks a "To:" field in its message base structure, so I set out to provide some equivalent functionality. This mod will search the subs in a user's configured qscan for "directed" replies, i.e. messages which respond to something that user posted. If the user's name is found, it displays the message and gives an opportunity to post an immediate reply. When a scan is complete, the user can clear qscan pointers and mark all subs as read. If he chooses not to do so, the qscan remains unchanged, and all messages still reflect as new. This routine works equally well on subs requiring "Real Name" in //BOARDEDIT, e.g. subs imported from Fido-type networks. 3. Mechanics: A great deal of code is from v4.24's <F>ind routine from the normal message base scan. Because I didn't want to reset qscan pointers automatically (I read all messages when I have time), and I didn't want to track global variables, it incorporates direct calls to the read message and post reply routines. For speed, searches are limited to the first 320 characters of a message (where the BY: line or something similar usually is). 4. Enhancements: Stock "get_post()" and "readfile()" routines necessarily allocate memory and read an entire message, as the resulting pointer is used to find the offset for subsequent messages. I didn't see a way of changing this without rewriting redundant routines. So, as is, this is fast on a Pentium and slow on a 286. Searchable text is "clipped" at 320 characters within the added function only. If someone wants to tackle a retrieval routine for type 2 storage which only allocates a small buffer, have at it! It will certainly speed it up! Open <MSGBASE1.C> At the very bottom of the file, add this function: void find_user_msgs(void) { char *b, ch, s[81], s1[251]; static char findstr[31]; int i, i1, i2, os, a, nn, fnd, new, sn, ac, abort, next; long len; unsigned long qscnptrx, sd; postrec p; slrec ss; abort = new = 0; nl(); if ((uconfsub[1].confnum != -1) && (okconf(&thisuser))) { ac = 1; tmp_disable_conf(1); } else ac = 0; os = cursub; for (i2 = 0; (usub[i2].subnum != -1) && (i2 < num_subs) && (!abort) && (!hangup); i2++) { cursub = i2; sn = usub[i2].subnum; if (qsc_q[sn / 32] & (1L << (sn % 32))) { next = fnd = 0; ansic(1); npr("\rSearching %s ", subboards[sn].name); if (okansi()) outstr("\x1B[K"); else { outstr(charstr(79,32)); outchr('\r'); } qscnptrx = qsc_p[sn]; if (!sub_dates[sn]) iscan1(i2, 1); sd = sub_dates[sn]; if ((!sd) || (sd > qscnptrx)) { new = 1; if (!iscan(i2)) { nl(); pl(get_string(1195)); continue; } qscnptrx = qsc_p[sn]; if (subboards[sn].anony & anony_real_name) strcpy(findstr, strupr(stripcolors(thisuser.realname))); else strcpy(findstr, strupr(stripcolors(thisuser.name))); for (i = nummsgs; (i > 1) && (get_post(i - 1)->qscan > qscnptrx); i--); if ((nummsgs > 0) && (i <= nummsgs) && (get_post(i)->qscan > qsc_p[sn])) { ansic(2); for (i1 = 0; i1 < 5; i1++) outchr(32); while ((i != nummsgs) && !abort && !hangup) { i++; checka(&abort, &next); if (!(i % 5) && (wherex() > 1)) { for (i1 = 0; i1 < 5; i1++) outstr("\b"); npr("%5.5d", i); if (!(i % 100)) { tleft(1); checkhangup(); } } b = strupr(readfile(&(get_post(i)->msg), subboards[sn].filename, &len)); memcpy(s1, b, 250); bbsfree(b); fnd = (strstr(strupr(stripcolors(get_post(i)->title)), findstr) || strstr(s1, findstr)); if (fnd) { p = *get_post(i); if ((p.ownersys != 0) || ((p.ownersys == 0) && (p.owneruser != usernum))) { msgheader(1); nl(); if (E_C) { sprintf(s, "1%u/%u0", i, nummsgs); strcat(s, charstr(12 - strlen(stripcolors(s)), '.')); strcat(s, " 2");0 } else { sprintf(s, "%u/%u: ", i, nummsgs); } osan(s, &abort, &next); ansic_x(sysinfo.msg_color); if ((p.status & (status_unvalidated | status_delete)) && (!lcs())) continue; strcpy(irt, p.title); irt_name[0] = 0; plan(p.title, &abort, &next); if (!abort) { ss = syscfg.sl[actsl]; if ((lcs()) || (ss.ability & ability_read_post_anony)) a = 1; else a = 0; nn = net_num; if (p.status & status_post_new_net) set_net_num(p.title[80]); setorigin(p.ownersys, p.owneruser); read_message1(&(p.msg), (p.anony & 0x0f), a, &next, (subboards[curlsub].filename)); if (nn != net_num) set_net_num(nn); prt(5, "Reply to message? "); ch = ynq(); switch (ch) { case 'Q': abort = 1; break; case 'Y': p = *get_post(i); grab_quotes(&(p.msg), subboards[cursub].filename); post(); resynch(cursub, &i, &p); grab_quotes(NULL, NULL); restore_msg_menu(); break; case 'N': default: nl(); break; } } } } } } } } } if (abort) { nl(); pl("Aborted."); nl(); } else { nln(2); prt(5, "Search complete..."); if (new) { prt(5, " mark messages on all subs as read? "); if (yn()) { read_status(); for (i = 0; i < max_subs; i++) qsc_p[i] = status.qscanptr - 1L; nl(); pl(get_string(25)); nl(); } } else { ansic(5); pl(" no new messages found."); } } if (ac) tmp_disable_conf(0); cursub = os; } Save <MSGBASE1.C> Open <LILO.C> This is where the user is prompted to scan for replies at logon. Search for "void logon(void)" and add these lines near the bottom of the function: == if (usub[0].subnum==-1) { == curconfsub=0; == setuconf(CONF_SUBS, curconfsub, -1); == } == } ++ nl(); ++ prt(5, "Search subs for responses to your posts? "); ++ if (yn()) { ++ nl(); ++ ansic(2); ++ pl("Space aborts search..."); ++ nl(); ++ find_user_msgs(); ++ } == rip_cls(); == autox = -1; ==} Save <LILO.C> Open <MMENU.C> Finally, we'll add a command to the main menu called //REPLIES which allows a user to search after he's logged on. Search for "void mainmenu" and add the indicated lines: == if ((strcmp(s,"NET")==0) || (strncmp(s,"NET=",4)==0)) == print_net_listing(0); ++ if (strcmp(s, "REPLIES") == 0) ++ find_user_msgs(); == if (strcmp(s,"QSCAN")==0) { Save <MMENU.C> Open <FCNS.H> Note: If you can use "MAKE FCNS" to rebuild your prototypes in FCNS.H, this step is unnecessary. Search for msgbase1.c and add the new function: ==void remove_post(void); ==int external_edit(char *fn1, char *direc, int ednum, int numlines, char *dest , char *title, int flags); ==void grab_quotes(messagerec *m, char *aux); ++void find_user_msgs(void); == == ==/* File: share.c */ Save <FCNS.H> 5. Recompile and drop me a note to say you like the mod! -=■=- ───────────────┬─────────────────────────────────────────────┬─────────────── │ A Warning Concerning │ │ Motherboard Cache │ │ By Burmese (1@15111) │ └─────────────────────────────────────────────┘ This is a warning about the stated cache size on many motherboards: Some motherboard OEM's are cranking out motherboards whose SRAM cache (L2) sizes are not what the manufacturer claims they are. Many are only putting 128k of cache on the motherboard and then tweaking the BIOS to say on startup that it is 256k (the most common size stated industry-wide). A few are even leaving out the L2 cache altogether. How to identify a motherboard with less-than-stated cache: It is almost impossible to identify whether of not a motherboard has 256k of cache on it or just 128k (or even none at all) just by looking at it. The manufacturer's typically fill up all the cache sockets with chips. Some individuals have stated on the internet that some of the 'fake' chips can be identified from their 'cheap' appearance or from the numbers stamped on the topside of each chip. This is not reliable in all cases, though. There are two basic approaches that can be used to properly identify a motherboard that is short-cached. 1) Pull the SRAM chips and test them in a chip-testing device. Some dealers have such testing equipment, most do not. Also, the manufacturer will usually have some sticker plastered over the SRAM cache chips stating that removal of said sticker will void the warranty (gee, wonder why they don't want you to poke at their chips?). Defective and fake chips, of course, will fail in such a testing device. 2) There are a number of programs available (many of which are shareware) which are designed to examine your system and detail it's components and capabilities. I use the shareware program PC CONFIG (german author). This program and some others will properly identify the size of your motherboards' SRAM L2 cache (found here & there recently as CONF802E.ZIP). Another program which will >graphically< demonstrate how large your cache is is the shareware program CCT386 (Calem Cache Tester, of french origin). This program, when run will run a benchmark program over and over, each time in a smaller 'table'. As the size of the program table shrinks, it eventually reaches a point where it is contained entirely within the L2 cache and, after that, within the processors' internal (L1) cache. As it reaches these points, the processing speed increases as less wait states are needed to retrieve data & code from the main system memory (the whole point of the L1 & L2 caches, anyway). The program will draw out a graph showing the relationship between the size of the program and the speed of execution. In a machine with 256k cache enabled the chart will show a rapid upward turn from between 512k and 256k, leveling off below 256k; and another jump between 10k & 8k. If the cache is only 128k, the initial acceleration in performance will occur between 256k and 128k. Even before performing any of these tests on your system you can get a possible indicator by browsing through the manual for the motherboard. These manuals typically contain information on how to set motherboard jumpers to accommodate various configurations, including various cache sizes. If the manufacturer doesn't want you to be able to fiddle with the cache configuration they will usually put in something like 'see your distributor regarding cache upgrades' and they will leave out crucial information relating to adjusting the jumpers for different cache sizes. The reason that the BIOS can state on bootup that the cache size is '256k' is because the manufacturers normally receive a 'base' BIOS code from the BIOS manufacturer (like AMI) and then 'tweak' that code to work with their particular motherboard. It is a simple thing for them to at that point 'fix' the BIOS so that is states that the cache size is 256k when it is, in actuality, not 256k but rather 128k or perhaps none at all. NOTE: Obviously, I am (submitting) this because, after reading some conversation on the comp.ibm.pc.hardware.chips usenet group on the topic, I decided to test my own 486-100 system (motherboard was a self-installed upgrade) and discovered that it only had a 128k cache and not the 256k cache it was supposed to have (as stated in the manual as well as on the packaging). ───────────────┬─────────────────────────────────────────────┬─────────────── │ Dear Abby │ └─────────────────────────────────────────────┘ [Got a letter for Abby? Send it to me, and I'll see that she gets it, and that your letter along with her response get published in the next WWIVNews!] ───────────────┬─────────────────────────────────────────────┬─────────────── │ Classified │ │ Ads │ └─────────────────────────────────────────────┘ A new feature here in WWIVNews is the Classified Ads Department. It's a place where utility authors can let everyone know about their most-recent offering to WWIV. This issue is a little skimpy due to negative replies, but look forward to a more-complete list next time. (Note to shareware/utility authors: If you would like you products listed here, please include a *brief* description of them <including registration fee, if any> and I will be happy to include them in the next issue, due out around March). -=■=- ───────────────┬─────────────────────────────────────────────┬─────────────── │ On the Lighter Side │ │ A Compilation by Sam (1@2863) │ └─────────────────────────────────────────────┘ How many of these quotes from (mostly) cyber-movies can you identify? Name the movie they came from. At the end there is a tiebreaker. Beyond that, if there is still a tie, the winner will be decided by random drawing. The prize is a yet-to-be-determined registration for a WSS product, and your name up in lights in the next WWIVNews! 1) "I never learned how to swim. I always thought there would be more time." 2) "It's Czechoslovakia! It's like going into Wisconsin!" 3) "Joey, do you like movies about gladiators?" 4) "Thank you sir, may I have another?" 5) "It bleeds. We can kill it." 6) "Great shot kid! That was one in a million!" 7) "Be the ball, Danny." 8) "Heeeeeeeere's Johnny!" Tiebreaker: "Help you? Who do you think brought the rope?" -=■=- ───────────────┬─────────────────────────────────────────────┬─────────────── │ Closing Thoughts │ │ Editor's Notes by Sam (1@2863) │ └─────────────────────────────────────────────┘ Well, this concludes another (albeit abbreviated) edition of WWIVNews. As many of you are aware, I recently moved from Texas to Kansas to take on a new job as WAN administrator for a multi-national corporation. Getting moved and settled in has taken a great deal of my time, and I apologize for the delay in getting this edition out. One major change is taking place here at WWIVNews. It has been decided by both Wayne and myself that WWIVNews should have a staff. So, we are officially taking applications for interested people to become a part of WWIVNews. All interested parties should email me at 1@2863. We will probably limit the number of people to five or less, so don't be disappointed if you are turned down. -=■=- ┌───────────────────────────────────────────────────────────────────────────┐ │ Closing Credits │ ├───────────────────────────────────────────────────────────────────────────┤ │ WWIVNews is an independent newsletter published every two-three months as │ │ a service to the WWIV community of sysops & users. The opinions & reviews │ │ expressed herein are the expressed views of the respective writers, & do │ │ not necessarily reflect those of the WWIVNews staff. Reproduction in whole│ │ or in part is allowed provided credits are given. All rights reserved by │ │ WWIVNews, and all articles are copyright of their respective authors. │ ├───────────────────────────────────────────────────────────────────────────┤ │ The source site for WWIVNews is Sam's BBS (913-859-9358 or 859-9476) │ │ WWIVNet Node @2863. Requests for information regarding articles & other │ │ editorial submissions, as well as back issue requests and the WWIVNews │ │ Writer's Guide, can be sent E-Mail to the WWIVNews editor, c/o 1@2863 │ ├───────────────────────────────────────────────────────────────────────────┤ │ WWIV and WWIVNet, copyright 1986,1996 by Wayne Bell │ │ Any product or company mentioned or reviewed herein are copyrighted of │ │ their respective owners, creators, and other corporate pseudoentities. │ └───────────────────────────────────────────────────────────────────────────┘ Who is General Failure and why is he reading my disk? Computer analyst to programmer: "You start coding. I'll go find out what they want." I modem, but they grew back. Modem: How a Southerner asks for seconds.