ftp.update.uu.se

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

/ ftp.update.uu.se / ftp.update.uu.se.2014.03.zip / ftp.update.uu.se / pub / rainbow / msdos / decus / RB141 / varug06a.arj / V6N1ASC.ASC next >

Wrap

Text File | 1992-01-16 | 71KB | 1,383 lines

Vancouver Area Rainbow Users Group N e w s l e t t e r January and February, 1992; Volume 6, Number 1 Editor: David P. Maroun, 9395 Windsor Street, Chilliwack, BC, Canada V2P 6C5; telephone (604) 792-4071 Publisher: DECUS Canada, 505 University Avenue, 15th Floor, Toronto, Ontario, Canada M5G 1X4; telephone (416) 597-3437 ----------------------------------------------------------------------------------- This newsletter is provided free of charge to members of the Vancouver personal computer local users group (Vancouver PC LUG or VANPCLUG), also called the Vancouver Area Rainbow Users Group (VARUG). The group is part of the Digital Equipment Computer Users Society (DECUS) of Canada. Membership in the local users group is free for anyone using a personal computer made by Digital Equipment Corporation or used with Digital products. Members need not live near Vancouver. Robert M. Slade retains the copyright to his articles. Any other part of this newsletter may be freely copied or distributed unaltered and with credit given to sources. While information provided is believed accurate, the editor and publisher are not responsible for contributions of other writers. ----------------------------------------------------------------------------------- Table Of Contents Page Editorial: We Remain A Local Users Group ............... David P. Maroun ... Corrections And Clarifications .............................................. In The News ................................................................. Changes In DECUS Canada ................................. Marcus Schack ..... Cheating Viri ........................................... Robert M. Slade ... Comparison Review: Virucide For MS-DOS ................. Robert M. Slade ... Comparison Review: PC-cillin For MS-DOS ................ Robert M. Slade ... Two CP/M-86 Text Analysis Programs: TXTRDR And STYLE ................................... Janet Charlton .... Memory Expansion In 80x86- Based Computers Under MS-DOS ....................... John Wilson ....... Questions And Answers ....................................................... Buy, Sell, Or Swap .......................................................... ----------------------------------------------------------------------------------- Deadlines: For our March and April issue: February 29, 1992 For our May and June issue: April 30, 1992 Almost any legible format is acceptable for submissions, but the ideal is ASCII form on magnetic materials. Diskettes or tapes should be accompanied by covering letters describing the files and indicating disk or tape format. We prefer Rainbow CP/M or Rainbow MS-DOS but can handle most other CP/M and MS-DOS formats (check about them) as well as Tandy Color Computer tapes and diskettes. ----------------------------------------------------------------------------------- Editorial: We Remain A Local Users Group By David P. Maroun In our last issue was a form for voting on changing the official status of our group from a local users group (LUG) to a special interest group (SIG). Few people voted. Those who did voted against the change. One person commented I would like to see VARUG remain a "grass roots" organization like it always has been So, for the time being at least, we remain a LUG. I thank those who took the time to reply. Robert Slade has begun a discussion of our situation with other members of DECUS. I also am participating. The discussion takes place in the VAXnotes section of MUKLUK, the DECUS Canada MicroVAX. We hope at least to promote a better understanding of our group within DECUS. ----------------------------------------------------------------------------------- Corrections And Clarifications In our previous issue, Robert M. Slade reviewed the virus protection software, Virex-PC. Since writing that review, Mr. Slade has advised: The product reviewed has now been superceded by version 2.0, which addresses most of the concerns raised, particularly that of not removing the "Stoned" virus. ----------------------------------------------------------------------------------- In The News Ashton-Tate Settles With Fox ---------------------------- A judicial arrangement has effectively ended a conflict between Ashton-Tate Corporation (now owned by Borland International Incorporated) and Fox Software Incorporated. Ashton-Tate had sued Fox for alleged breaches of copyrights on dBASE III Plus software. Fox responded with a counter-claim that Ashton-Tate had stolen Fox's FoxBase+ secrets. A consent decree involving the US Department of Justice and Borland states that Borland must end the suit if Fox ends its suit. Fox agreed to drop its counter-suit. Dealers Settle Software Piracy Suit ----------------------------------- Two Canadian computer dealers, Cotech Computers Incorporated of Toronto and Alberta Computers & Supplies of Calgary, have reached an out-of-court settlement with four US software companies. Ashton-Tate, Lotus Development Corporation, Microsoft Corporation, and WordPerfect Corporation had sued the two dealers for alleged unauthorized reproduction and distribution of copyrighted computer programs. Details of the settlement were not available. DEC And Microsoft Offer Joint Products -------------------------------------- Digital Equipment Corporation has agreed to use Microsoft's Windows NT operating system on Digital's new DECstation 5000 series workstations. The workstations use reduced instruction set processors (that is, they are RISC machines), capable of running many MS-DOS applications. Grace Hopper Dies ----------------- Grace Murray Hopper died January 1, 1992, in her home in Arlington, Virginia. She was 85 years old, and held the rank of retired rear admiral in the United States Navy. At the time of her death, she was employed as a senior consultant at Digital Equipment Corporation, and until 18 months ago was actively representing the company at industry forums, making presentations that focused on government issues and participating in corporate educational programs. In September, President George Bush awarded the National Medal of Technology to Admiral Hopper "for her pioneering accomplishments in the development of computer programming languages that simplified computer technology and opened the door to a significantly larger universe of users." She was the first woman to receive the award as an individual. Police Seize Assets Of A Bulletin Board --------------------------------------- Representatives of the Royal Canadian Mounted Police and the Canadian Alliance Against Software Theft (CAAST) have indicated that, as part of a crusade against software piracy, the RCMP seized ten personal computers, seven modems, and the software on the system from the 90 North bulletin board system operating in Montreal. Charges were pending when the announcements were made. CAAST indicated that some of the software supplied by 90 North was beta versions of commercial software not yet released to the public. Included were WordPerfect 5.0, MS-DOS 5.0, Borland C++ 2.0, dBASE IV 1.1, SCO Xenix, NetWare 3.11, and Clipper 5.0. These are protected by copyrights. ----------------------------------------------------------------------------------- Changes In DECUS Canada By Marcus Schack President, DECUS Canada Departure Of A Good Friend! --------------------------- It is with much sadness that I must announce that John de Bruijn is leaving the DECUS Canada board of directors. His resignation has been brought on by the fact the he is leaving his current position within Digital and will no longer be able to support us in the role as Digital delegate. During John's time on the board, he has repeatedly shown his support for our organization, and through his efforts, many positive changes have come about. The last one was the addition of the fourth DECUS office staff member. He fought a long, hard battle for us within Digital to get us this allocation, and through his efforts, we are only a few months away from actually having this person in the office. I know I speak for all of the board when I say that he will be greatly missed and leaves 'large shoes' to fill. We hope that he has gained as much as we have from the time we have spent working together on the board. Thank you, John! New Additions To The DECUS Canada Board Of Directors ---------------------------------------------------- I am pleased to announce that we have three new members on the DECUS Canada board of directors. They are Larry Humphries, Brian Luther, and Phil Doublet. Larry Humphries is filling the position left vacant by the departure of John de Bruijn, and will be our new Digital delegate. As I write this, he has already had a taste of our organization as we have just returned from our MANcom meeting, at which Larry had a chance to see, first hand, how we work. I hope he was as impressed with us as we were with him. Brian Luther has accepted the board nomination to fill one of the two open positions, which was created when Ruben Boiardi moved from the Leadership portfolio to the COMMcom portfolio. Brian Luther has been a very active DECUS member in the Hamilton area for quite some time and will be responsible for the Leadership portfolio, effective immediately. Phil Doublet joins us from the ranks of the National LUG Council as their newly elected chair and as such was asked to be appointed to the board as the representative from the NLC to the board. Having known Phil for many years (both of our backgrounds stem from the CalVAX days) I know that he will be an excellent board member who will bring his professional skills with him. As you can see, we have had a number of changes in the past few months and I feel that we now have a dedicated board who are looking forward to accomplishing their tasks and taking this organization forward into the future. To make it easier for all, I would like to re-introduce the current DECUS Canada board of directors: Marcus Schack President Jim Mackay Vice-President Operations Pat Stroman Vice-President Finance Dave Wilson Library Ruben Boiardi Communications (COMMcom) Brian Luther Leadership to be announced Symposium Task Force (SPCX) Phil Doublet National LUG Council (NLC) to be announced Membership Larry Humphries Digital Delegate Warren Gilbert DECUS Office Manager Mark Johnson Past President Resignation Of Alan Clifford, Vice-President, Finance ----------------------------------------------------- It is with regret and after a lot of deliberation that I must accept the resignation of Alan Clifford, Vice-President Finance, DECUS Canada. Alan's career in DECUS spans many productive and fruitful years. His major contributions were made as DECUScope editor, board member, and finally as VP Finance. It was in his last post as VP Finance that he gave his greatest contributions. Not only did he set up our new schedule for creating and following our fiscal plans, but he guided us through the long process of creating, modifying, and adopting our current strategic plan. Those who were part of the process will understand and appreciate his efforts in that area. I know we will all miss Alan and wish him all the best in his future endeavors. Thank you, Alan. NLC Elections ------------- The National Local User Group Council recently held an (electronic) election to form their executive committee, and these are the results (alphabetic): Gary Chow--OMNIVAX Philip Doublet--CALVAX Ralph Playdon--EARLUG Robert Slade--VANPCLUG Carol Young--NAPLUG Resignation of SPCX Chair and Co-Chair -------------------------------------- It is with much regret that I must announce the resignations of Marlene Arscott and Susan Kalinger. It is always a sad moment when people decide to leave a group, but even more so when they have been with us for a long time and have contributed greatly. After much discussion, Marlene and Susan felt that they had to tender their resignations, citing philosophical differences. I, on behalf of DECUS Canada, accepted their resignations effective immediately. I know, all of you will join me in wishing them well in the future and thanking them for the work that they have done for our organization in the past. They have both given a lot to DECUS. ----------------------------------------------------------------------------------- Cheating Viri By Robert Michael Slade The following is not guaranteed to keep you safe from computer viri. However, the following precautions will reduce the chance of your computer being infected, or will reduce the severity of damage you may encounter. Know your computer. Learn as much as you can about how your computer actually does operate, not simply which buttons you have to press to write a letter. In particular, learn whatever you can about the operating system. If you don't learn about the insides of your computer, you must know about the programs you are running. All of them. What is the directory structure of your hard disk like? What is your "configuration"? Do you have special "driver" programs for special equipment (which includes "rodents" in the MS-DOS world)? Do you have special "memory resident" programs that start up at "boot time", such as screen savers, screen clocks, sounds, "cut and paste" utilities? If you don't know what your computer is supposed to be running, how will you know when something that isn't supposed to be running starts up? Know thine enemy. Learn all you can about computer viri. Unfortunately, this is easier said than done. Very little solid information about viri gets into the popular media, or even the computer industry press. Specialty data security journals are very expensive, and only one ("The Virus Bulletin" from the UK) has either PCs or viri as a major emphasis. Electronic bulletin board systems (or BBS) are among the major sources of information. Do not expect much help from local users, but do check for text files such as VSUMxxxx.ZIP, VIRUSSUM.DOC, DIRTYDOZ.TXT, or MSDOSVIR.xxx. New viri, or new strains of old viri, are appearing at a rate that may soon reach 1 new strain daily, so check regularly for new information. Know who you're dealing with. Most lists of computer protection "dos and don'ts" state that you shouldn't use programs or disks that you don't know anything about. This is easy to say, but difficult to do. Not only do you have to be able to trust that the persons you are dealing with mean you no harm, but also be able to trust that the persons are competently protecting themselves against infection. Given current infection rates, more viri are being spread by "disk swapping" than by the sharing of programs. This is likely because of the fact that data are more often shared than programs are. A data diskette infected with a boot sector virus can still infect a computer, and the computer can then infect any disks it comes in contact with. Use system utilities. Of course, you have to know about your system first, but memory and disk mapping utilities can tell you a lot. Check your memory frequently, and note any changes, new entries aside from programs that should be running. Check disks for bad sectors that suddenly appear. Check your disk space to ensure that you aren't suddenly running out of room on disks that should have a lot of free space left. Use "anti-viral/anti-trojan" software, but DO NOT DEPEND UPON IT! If you do use scanning software, make sure that you update it regularly. Most good packages provide a new release about once per month. Know the differences among types of protection software and their strengths and weaknesses. Vaccine software is memory resident and watches for "suspicious" activity. It is, however, very hard to tell the difference between a word processor updating a file and a virus infecting a file. Vaccine programs may be more trouble than they are worth by continually asking for confirmation of valid activities. They also may be bypassed by viri that do "low level" programming rather than using the standard operating system "calls". Change detection software examines system and/or program files and configuration, stores the information, and compares it against the actual configuration at a later time. Most of these programs perform a "checksum" or "cyclic redundancy check" (CRC) that will detect changes to a file even if the length is unchanged. The disadvantages of this system are 1) it provides no protection, but only notification after the fact, 2) some change detection software is limited to operating system software only, 3) you must "inform" the software of any changes you make in the system, and 4) change detection software may not "see" changes made by "stealth" viri. Some versions of this software run only at "boot time", others check each program as it is run. Some of these programs attach a small piece of code to the programs they are "protecting", and this may cause programs which have their own change detection features to fail. Operation restricting software is similar to vaccine software, except that instead of watching for suspicious activities it "automatically" prevents them. As with mainframe security "permission" systems, some of these packages allow you to restrict the activities that programs can perform, sometimes on a "file by file" basis. However, the more options these programs allow, the more time they will take to set up. Again, the program must be modified each time you make a valid change to the system, and, as with vaccine programs, some viri may be able to evade the protection by using low level programming. Encrypting software writes programs and/or data onto your disks in a non-standard way and then "decrypts" the program or file when you need to use it. This means that if a virus does try to infect the system, it usually only scrambles the data and is easily detectable. Used in conjunction with operation restricting software features, encrypting software essentially changes the whole operating environment, hopefully to one that a virus cannot survive in. Again, there is the need to do a lot of work in setting up the protection system, and keeping it up to date when you make changes. (It is also possible, if the system is not configured properly to begin with, to end up with a system that you cannot use and cannot repair.) There are two major "holes" in the security of the system: 1) Some part of the system must remain "unencrypted" and is therefore vulnerable to "attack", and 2) if you start with already infected files, the system will quite happily encrypt the virus and allow it to operate. Scanning software is, paradoxically, the least protective and most useful of anti-viral software. These programs examine files, boot sectors and/or memory for evidence of viral infection. They generally look for viral "signatures", sections of program code that are known to be in specific viri but not in most other programs. Because of this, scanning software will detect only "known" viri, and must be updated regularly. Some scanning software has "resident" versions that check each file as it is run, but most require that you run the software "manually". It is also the classic case of "bolting the door after the horse is gone" since "scanners" only find infections after they occur. Why then, with all the disadvantages of scanning software, are they the most successful of anti-viral packages? Generally speaking, it is because they force the user to pay attention to the system. Again, when users rely on one particular method of protection they are most vulnerable. Do regular backups. This should go without saying, but it doesn't. And it is not that backups perform any specifically anti-viral function. Backups, however, allow you to recover data or programs after damage by a viral "logic bomb", or to recover "clean" programs after an infection. Be aware that backups of an infected file are infected, and that a program recovered from an infected backup is still infected. Scan all software before installation. Even if from a commercial software house and "shrink wrapped". "Write protect" all original software disks. BEFORE you install the software. Better yet, "write protect" the original, make a copy, protect the copy, "scan" the original AND the copy, and install from the copy. (This is not always possible with software houses who still insist on esoteric "copy protection" schemes.) DO NOT CONSIDER YOURSELF SAFE FROM INFECTION. If you do, you're in trouble. copyright 1990 Robert M. Slade ----------------------------------------------------------------------------------- Comparison Review: Virucide For MS-DOS By Robert Michael Slade Company and product: Parsons Technology 375 Collins Road NE Cedar Rapids, IA 52402 USA 319-395-9626 Virucide Summary: Menu driven scanning and disinfecting program, apparently written by McAfee Associates. Recommended for novice or intermediate users in non-critical situations, or as "first line" defence. Cost US $49.00 Rating (1-4, 1 = poor, 4 = very good) "Friendliness" Installation Ease of use 4 Help systems 3 Compatibility 3 Company Stability 2 Support 4 Documentation 3 Hardware required 4 Performance 3 Availability 3 Local Support ? General Description: A simple and relatively inexpensive virus scanning and disinfecting program. The menu driven interface provides a number of useful options, including on-screen virus information. Comparison of features and specifications User Friendliness ----------------- Installation ------------ Installation is clear and straightforward, being simply the copying of the program and related files to the appropriate disk or area. Although the manual indicates installation is to be done from drive A:, it can be performed from any drive, and to any drive, including floppies. Installation takes a longer time than one might think, given the elementary copying operation, but the installation program is clear and "well prompted". Ease of use ----------- Operation is easier than the manual indicates. The default settings are well chosen, and although there are command line switches and options that can be set on screen, they merely provide alternate avenues to the same operations. All options are available as menu items, and the menu interface provides a sense of being "in command" with all functions at the user's fingertips. Prompts are clear and informative. The "3-D windowing", although attractive, does, at times, clutter the screen and distract from the functionality by overlaying and highlighting portions of the menus that are not currently being used. Help systems ------------ There is no "help" per se, but the program is easy enough to use that this should not be a problem. One decided advantage is the "Virus Info" window, which provides a list of viri, and will bring up two or three paragraphs of information on selected viri. While useful to a novice or intermediate user, this function does not require extensive disk space, as it is simply a "boilerplate" expansion of the McAfee VIRINFO.TXT table which is supplied with the disk. (Indeed, do not make the mistake of deleting this file under the impression that it serves no purpose.) Compatibility ------------- Virucide will detect all of the most common viri, and is roughly "level" in that regard to most commercial products, although it lags behind such scanners as SCAN and FPROT. Given the association between Virucide and McAfee Associates, this is rather odd. (Version 2.0 of Virucide is dated January 28, 1991, but the copyright date on the VIRINFO.TXT file is 1989.) However, a "current" version of Virucide should prove effective against better than 99% of viri encountered. Company Stability ----------------- Parson's Technology is a mid sized software distribution house, with a very wide selection of products. Company Support --------------- Virucide was the first product actually received for review from the first group of commercial vendors contacted. Having received the May 1990 version in December, I received the January 1991 version in mid February as a "free upgrade". I have seen numerous references by users of other Parsons' products to superior customer service. Documentation ------------- The documentation is clear and concise, but at times makes the product appear to be more difficult to use than is actually the case. There is no general discussion of viral operation. Hardware Requirements --------------------- No special hardware required. Performance ----------- As above, Virucide has no particular strengths, or weaknesses, in speed of operation or numbers of viri detected. Local Support ------------- No provisions. Support Requirements -------------------- For general installation and operation, Virucide should not need any support. The novice user should be able to use the system as is, and the intermediate user will be able to make better use of the options available. General Notes The only advantage that the advanced user will find in Virucide is the "Virus Info" window as a "ready reference". However, as a "quick check" for novice or intermediate users, the product deserves consideration. copyright Robert M. Slade 1991 ----------------------------------------------------------------------------------- Comparison Review: PC-cillin For MS-DOS By Robert M. Slade Company and product: Trend Micro Devices Inc. 2421 W. 205th St., #D-100 Torrance, CA 90501 USA 213-782-8190 PC-cillin: Program change detection hardware/software Summary: A change detection and vaccine program with some scanning functions. Change detection is applied to boot sectors and partition boot records as well. System status information is stored in a hardware device connected to a parallel port. Cost US $139.00 Rating (1-4, 1 = poor, 4 = very good) "Friendliness" Installation 3 Ease of use 3 Help systems 2 Compatibility 2 Company Stability ? Support 2 Documentation 3 Hardware required 3 Performance 2 Availability 2 Local Support ? General Description: The best functioning parts of the package appear to be the scanning, and "resident scanning" operations. Not highly recommended; most suitable for novice users with operations primarily limited to a single hard disk and strictly limited disk swapping. Comparison of features and specifications User Friendliness ----------------- Installation ------------ The disk is shipped write protected, although only by a write protect tab. (The disk is not a "notchless" read-only disk.) The installation procedure is written with a "pre-infected" system in mind, and, if followed carefully, should provide against infection by any virus known to the program. (The procedure to be followed in case of partition table infection, although quite clear in its explanation of the problem, is deficient in not recommending making a backup before beginning the procedure.) PC-cillin can install from, or to, any drive, but will not install to the drive from which the installation files are being run. Installation is simple and reasonably quick. Modification to AUTOEXEC.BAT or CONFIG.SYS is simple, but non-destructive and maintains a backup file. Upon installation to a boot virus infected system, PC-cillin identified the virus, but allowed the installation to proceed. Upon "rebooting", PC-cillin alerted for the presence of a boot sector virus. Interestingly, once the disk was disinfected, PC-cillin allowed the disk to boot normally. Without having access to the encoding system used, it is difficult to say what check is used to detect a change in the boot sector. A deliberate change made in the boot sector text had no effect. The package makes provision for software updates of the "signature" programs without the need for reinstallation of the entire system. Ease of use ----------- A single program, PCC.EXE, gives access to all functions, installation, scanning (called "Quarantine" by PC-cillin) and the production of a "rescue diskette". Installation and scanning are clear and self-explanatory in operation. The making of a rescue diskette is less so, involving unnecessary disk swapping. When scanning, PC-cillin does not disinfect infected files, but does offer to delete them. The decision is left to the user. Boot sector viri on floppies are not disinfected, even if they are the "boot floppy" that PC-cillin was installed on. Repair information is apparently only stored for the hard disk PC-cillin is installed on. Because of its "background" operation, PC-cillin presents an "inverse face" (PC graphics character 02H) in the upper right hand corner of the screen when in operation. The documentation states that this display can be toggled off or on with <Alt><Tab><Backspace>, and that the operation of PC-cillin in background can be toggled on and off with <Alt><Backspace>. The message displayed by the PCCILLIN program at invocation indicates a different key sequence. Neither appears to work. Help systems ------------ None provided. Compatibility ------------- The scanning function of PC-cillin is stated to recognize 146 different viri, and it does recognize the most common viri that make up the bulk of current infections. The "vaccine" functions of the product are either very intelligent or very doubtful: The program will allow programs to modify themselves, other programs and disk boot sectors, as well as deleting program files. (Disk writing by certain programs appears to be restricted, but in testing no alarms were generated by multiple attempts to write to program files through the use of different programs and editors.) Protection of boot sectors appears limited to the "installed" hard disk: The program will not recover an infected boot sector floppy. Company Stability ----------------- Unknown. Company Support --------------- When the company first shipped the product for review, an incorrect Customs declaration for shipping to Canada delayed shipping of the review copy. The program makes provision for software updates of the "signature" programs, but does not indicate any definite way to keep customers informed. Documentation ------------- The documentation is clear and well laid out, and contains an excellent discussion of general viral operations. The progression through the book is logical, and novice users should be able to follow it clearly. Advanced users will still find items of interest in the section on general viral concepts. One complaint about the documentation concerns the binding. The book is paperback size, and very stiffly bound, with cardboard dividers between the sections. Thus the book is physically hard to read. ---------- The "disk documentation" (README.DOC file) is not up to the same standard. It is full of grammatical errors, and in some places is nearly impossible to read. Hardware Requirements --------------------- At least one parallel (printer) port is required. The "Immunizer Box" attachment is said to be transparent to user data. Performance ----------- The product is "aware" of the currently most common viri. Identification in various areas relies on known viral activity. Although memory is checked, the program does not appear to "find" memory resident viri which can also be found on disk. Vaccine or recovery activities are restricted at best. Local Support ------------- None provided Support Requirements -------------------- The program is easy enough for a novice to use and install without assistance. If a virus is found, it is recommended that experienced personnel deal with it. General Notes A great deal of thought and planning has gone into the concept and packaging of this product. Provision for the use of floppy diskettes, and a general strengthening of the "vaccine" and change detection portions of the program would benefit it immensely. copyright Robert M. Slade 1991 ----------------------------------------------------------------------------------- Two CP/M-86 Text Analysis Programs: TXTRDR And STYLE By Janet Charlton I do plenty of writing and appreciate any help I can get from spelling checkers and other text analysis programs. Some months ago, I acquired a copy of READER.LBR, which contained programs for analyzing text. READER.LBR and its contents were as follows: READER .LBR 24k ** Library directory for A0:READER .LBR 24k ** * PERSWORD.YYY 1k : READER .CYD 11k : READER .DYC 6k : STYLE3 .CYD 8k The 'Y' in the file names indicates compression by the CP/M-80 utility CRLZH.COM. After I restored the files to their original sizes, I had two CP/M-86 executable files, READER.CMD and STYLE3.CMD; READER.DOC for documentation; and PERSWORD, a list of personal words (such as 'I', 'you', and 'mother') used by READER.CMD. The documentation refers to READER.CMD also as 'TXTRDR.CMD' or 'TXTRDR3' or just 'TXTRDR'. The '3' in 'TXTRDR3' or 'STYLE3' is, I assume, the version number, and I sometimes omit it in discussing the programs. Both STYLE and TXTRDR (or READER) came from sources catering especially to DEC Rainbows, so I used the programs mostly on those machines. Did you think the documentation for text analysis programs would be a model of literary perfection? That idea crossed my mind. Alas, I found annoying flaws in READER.DOC. First of all, the author(s) is (are) not identified. When STYLE runs, it says it is "Copyright 1985,1987 By MRP", but I could find no definition for 'MRP' (the term does not appear in READER.DOC), and no other name for the author. I said before that one of the programs is called both 'READER' and 'TXTRDR', but while READER.DOC uses the two names in the same contexts, it does not explicitly say that they refer to the same program. Near its beginning, READER.DOC refers to "READER.CMD and it's companion file PERSWORD". The word "it's" should, of course, be "its". Confusion of these two is a mistake I find especially irritating. Other problems showed up later, and I will discuss them while I describe usage of STYLE and READER (that is, TXTRDR). If you just enter 'STYLE' without mentioning a file to analyze, you see the following: STYLE Copyright 1985,1987 By MRP v3.0 USE: A>style b:file.txt The preceding three lines are actually spread over most of a screen, but I omit blank space. Anyway, the display tells how to use STYLE. Entering READER (that is, TXTRDR) without mentioning a file to analyze gives the message You didn't enter a filename. Usage: READER filename.typ without intervening blank lines or double-width characters. Basically, these messages indicate that, to use STYLE or READER (TXTRDR), you just type the name of the program, without its extension, followed by the name of the file to be analyzed. For example to make STYLE.CMD analyze TEST.DOC when both files are on the current drive, type STYLE TEST.DOC and press the <Return> key. I usually operated under CP/M, but (as READER.DOC points out) both STYLE and READER (TXTRDR) run under MS-DOS with the help of Jean-Marc Lugrin's AME-86 program. I used STYLE and READER for months on many text files. Using STYLE on a file TEST.DOC produced STYLE Copyright 1985,1987 By MRP v3.0 STYLE is analyzing TEST.DOC ... Enter S for screen, or P for printer -> T E X T S T A T I S T I C S for file: TEST.DOC TOTALS Characters................ 16143 Words..................... 3149 Sentences................. 201 AVERAGES Characters/Word........... 5.13 Words/Sentence............ 15.67 MAXIMA Characters/Word........... 21 Words/Sentence............ 56 PERCENTAGES Sentences < 10............ 32 Sentences 10-30........... 62 Sentences > 30............ 4 Dialog.................... 36 Again, I have left out blank lines in the actual display, as well as cosmetics like clearing of the screen and a ringing bell. Running TXTRDR (READER) on the same TEST.DOC produced (with some cosmetics I omit): R E A D E R The following personal words are found in: TEST.DOC. -------- you i i you i i i you i you you david our mr. you your you your you your you you you your you you your your you you you your you you you you you persons you you persons you your you your your you you you their they they you you they their you they you your you you you you they you they they they they you you yourself you us they i i us they Enter S for Screen or P for Printer -> R E A D E R - Analysis of Text-File: TEST.DOC ------------------------------------------------------------- Line count: 471 Word count: 3238 Average characters/word: 5.29 Sentence count: 201 Average words/sentence: 16.11 Average syllables/word: 1.70 ============================= ============================= Reading-ease level: 46.77 Human-interest scale: 16.95 ============================= ============================= 0-30 Very difficult BA 0-10 Dull 30-50 Difficult AA 10-20 Mildly interesting 50-60 Fairly difficult HS 20-40 Interesting 60-70 Standard difficulty 9 40-60 Very Interesting 70-80 Fairly easy 7 60-100 Dramatic 80-90 Easy 6 90-100 Very Easy 5 Examining the two results reveals a problem: The two programs do not agree. For example, STYLE found 3149 words, READER found 3238; STYLE said there were an average of 5.13 characters per word, TXTRDR said 5.29; STYLE found an average 15.67 words per sentence; TXTRDR found 16.11. Another problem appeared when I ran READER on other files. The program thought that an assembly-language program had a reading-ease level of 100, which is as easy as possible. Nobody I know considers assembly-language programs easy to read! Using the programs brought out another error in the documentation file READER.DOC. It says you can redirect the output both under MS-DOS with AME-86 and under CP/M. For example, to save the analysis of MYFILE.TXT to REPORT.FIL, you type READER MYFILE.TXT > REPORT.FIL<Return>. The procedure worked well enough under MS-DOS aided by AME-86 (that is how I saved outputs for this article), but under CP/M, each attempt at redirection produced a file whose name was just spaces. I could not use the 'TYPE' command to display the file, but the file manager NSWEEP allowed me to rename to something CP/M could handle, and also let me see the contents. STYLE's output was just its help message, as if I had not named a file to analyze. READER stopped output to the file after listing the personal words; the rest of the results went either to the screen or the printer depending on which key I pressed in response to a prompt. I decided to try the two programs on other machines besides Rainbows, so I transferred STYLE, TXTRDR, and a text file to a Zenith personal computer with an 8088 processor running Concurrent CP/M-86 1.0. STYLE and READER displayed uninterpreted ANSI codes which cluttered the display somewhat, but otherwise both programs ran well. I thought the display was easy enough to read once I learned to ignore the ANSI codes. Encouraged by this result, I loaded IBM PC-DOS 2.10 in the Zenith with ANSI.SYS installed to interpret ANSI codes, and used AME-86 to run STYLE and READER. The display looked better than under Concurrent CP/M-86, though the code for double- width characters was uninterpreted. However, what appeared on the screen was echoed to the printer, just as if <Shift> <Print Screen> were pressed repeatedly. I tried again under MS-DOS 3.3 with the same result. I found I could avoid using paper by redirecting printer output to the serial port with the command MODE LPT1:=COM1: while keeping the printer connected to the first parallel port. On an AT&T 80286 computer, performance was disastrous. When I tried to run STYLE, I got a message that BASIC was not in ROM (read-only memory) and that I should reset the computer. The computer did not respond until I reset it. Conclusions ----------- Obviously, there are limitations on the usefulness of both STYLE and READER (also called TXTRDR; do you remember?). The two programs give conflicting results; TXTRDR's evaluation of ease of reading is questionable; both programs conflict to some extent with Rainbow CP/M and with other machines (the conflict is severe with the 80286 computer tested); and the documentation contains errors of omission, fact, and grammar. Nevertheless, I still run STYLE and TXTRDR on documents I create. Their opinions are interesting even if I do not always agree. Of course, the price is right: STYLE and TXTRDR are distributed free of charge, and the documentation does not even suggest paying the author. If you do wish to pay him (her? them?), his anonymity stops you. By the way: There are MS-DOS versions of both programs, apparently from the same author. I tried them too briefly to comment much. ----------------------------------------------------------------------------------- Memory Expansion In 80x86-Based Computers Under MS-DOS Prepared by John Wilson, Hyperdyne, Inc. Annandale, VA In The Beginning . . . ---------------------- In the beginning, there was the 8080 microprocessor. The 8080 was, defendably, the "first" microprocessor. (Yes, there was an 8008, and a 4004 before that, but their only surviving significance today is that they were the predecessors of the 8080.) When the 8080 was invented, memory for computers was very expensive. The 8080 could directly address 64 thousand bytes of information, which was a very great deal in those days. Few systems (or more correctly, few system owners) could afford to actually place a full 64 k of memory in their systems. But things changed quickly. The Silicon Valley guys learned to make transistors smaller and better and it became much more economically feasible to talk about fully populated 64 k machines. On the software front, things like spreadsheets and word processors were being invented. These programs were hungry for memory and the microcomputer user rapidly outgrew the 64 k box. Before going on with the story, a little digression into the origins of the 64 k limit. This limit was the direct result of the fact that the central processor unit (CPU) chip had only 16 address lines. The address lines are a set of wires coming out of the CPU which allow the CPU to indicate what item of memory it wants to read or write. In most computers, the size of the "pieces" is a byte, or 8-bit character. These 16 wires are called the address bus. The voltages on the 16 address lines are interpreted as binary numbers with the first pin representing the 1's place, the second pin representing the 2's place, the third pin representing the 4's place, and so on. The resultant number is the address being addressed by the CPU. The number of distinct patterns of 16 things, each of which can have two values, is 2 raised to the 16th power, or 65536. This number is 64 times the quantity "1 k" which is 1024. (Early on, programmers engineers decided to use the "k" as a unit of counting things like memory because it was a nice power of two and figured it was close enough to a "real" thousand that nobody would notice). The point of this story is that the original microprocessors could only address 64 k because of the simple reason that they only had 16 address lines. Why didn't they just build one with more address lines? Well it's not that simple. Those address lines had to have circuitry driving them, and other circuitry to actually generate the 16-bit addresses, and other circuitry to decode the new instructions that would use more than 16 bits, and so on, and so on. And this circuitry was made of transistors. And, unfortunately, the state of the art of chip manufacturing did not allow chips to be built with many more transistors. So, mankind waited for the silicon boys to learn how to fit more transistors on one raisin-sized chip. Meanwhile, back the ranch, the Intel Corporation, in a stroke of electromarketing genius took the basic 8080 architecture and doubled up a small portion of the internal workings of the CPU's address circuitry. They basically duplicated the address register (the transistors that hold the pattern of bits to place on the address bus), slid it left 4 bits, and added some simple circuitry to add it arithmetically to the "old" address register. An so was born the infamous Intel segment register. By making this simple kluge to the 8080, Intel created the 8086 and 8088 microprocessors which now effectively had TWENTY address lines and could therefore address 2 to the 20th locations, a little over one million bytes. This new unit was called a megabyte even those it was further away from a million than a "k" was from a thousand, but then again you bought the "k", didn't you? The 20 bit address bus allowed the new amazing spreadsheets to really do some amazing things. This, in turn allowed Intel to beat competitor Motorola to the marketplace (Motorola were expanding the address bus the "right" way in their 68000 family). This in turn led IBM to select the Intel family over Motorola's as the basis of their new PC, and the rest is history. Using the power of the 8088, the Microsoft corporation adapted the CP/M operating system to the new chip, and, using its new power, created MS-DOS. Because of a lot of reasons, the 8088 and MS-DOS took over the world. And everyone was happy. Except . . . the programmers kept getting more bold in the ways they found to use memory, and the users wanted still BIGGER spreadsheets, and started playing with things like CAD/CAM, DBMSs, artificial intelligence, desktop publishing, and so on, all of which had insatiable appetites for memory. The silicon boys kept up with the hunger by developing bigger and better CPUs, the 80286, 80386, 80486 and so on. These 80286 had a 24-bit address bus and could therefore address 16 MB of memory directly. No one could possibly want to put that much actual memory in a PC, right? In a pre-emptive first strike, they also created the 80386 which had a 32-bit address bus and could therefore address 2 to the 32 bytes or over 4 thousand million bytes! (Pow! Bam! Take THAT, power user.) The day had finally come when the CPUs sitting on desktops could finally address more memory than anyone could afford to buy. End of problem, right? Wrong. Unfortunately, there were millions and millions of the 20-bit machines out there now (in the mid-1980's). Probably more significantly there were hundreds of millions of dollars invested in MS-DOS software that did not know how to use the new 32-bit instructions and capabilities. Especially MS-DOS. (Unix and OS/2 and a number of other less well-known operating environments do use the 32-bit mode, but MS-DOS was still king). Because Intel wanted to sell more than 3 of these new chips, they wisely decided to build "modes" into the new chips to make them compatible with MS-DOS. A mode is essentially a switch, inside the CPU that turns it into another chip, insofar as all logical capability is concerned. So when you're running MS-DOS on your shiny new 386 or 486, you're still running with only 20 bits of address and consequently a 1 MB address space. This mode is called real mode and the lower 1 MB of addressable memory in real mode is called conventional memory. The solution? EMS or expanded memory specification. Expanded Memory --------------- Expanded memory is a way to allow more than 1 MB of memory to be used by MS-DOS applications. How can this be? The CPU can address only 1 million different addresses; how can I have more than one MB in my PC? The answer is that the CPU re-uses the same address to get to more than one byte of data. It does this by allowing any one address to actually be used to refer to several, distinct, physically different storage locations--but only one at a time, of course. EMS memory usually resides on special "EMS cards", like the AST "RAMPage". (I say usually because there are some clever ways of implementing EMS on 80286 and 80386 machines that don't use "special" EMS cards; this is discussed later in the section entitled "Software Approaches To EMS"). The EMS card has memory chips on it just like regular system memory cards. The difference is that the memory chips on the card are not connected directly to the CPU's address bus. These chips are actually wired to another address bus, totally contained on the card, that has more than 20 address bits, usually 24 or so. Where do these extra address bits come from? Well some of them are just passed-through system address bits. The rest come from special storage locations on board the EMS card, called page registers. How are these page registers loaded? These registers are themselves directly addressable by the CPU. To have access to a byte of data in EMS memory, the CPU first loads the page register (itself simply another location accessible by the CPU) and then makes a normal memory reference. Some of the bits come from the address bus, and the rest come from the bits previously squirreled away in the page registers. Thus, it can be seen that a given address on the regular CPU's address bus forms only part of the address needed to select a particular byte of memory on the EMS card. To uniquely identify a byte, you need to specify the regular address plus the contents of the page register. It follows that one CPU address can correspond to several EMS memory locations, each of which differs only by the contents of the page register. The CPU can thus access more than 1 MB of memory on the EMS card by using its normal address bus augmented by the page registers. How It All Fits Together ------------------------ In the early versions of EMS, all EMS memory was mapped to appear to be in a special address range in the range of all possible addresses accessible by the CPU. This was usually at addresses between D0000 and DFFFF (in hexadecimal notation). This includes 64 k possible addresses. This area of address space is called the page frame, an analogy to a frame around a picture. The page frame is logically divided into four 16 kB "pages". For the sake of simplicity in the following discussion, the multi-page nature of the page frame will not be mentioned further. The explanations apply to each page within the page frame individually. It should also be noted that, strictly speaking, the 4-page, 64 kB page frame applies only to EMS versions 3.2 and earlier. In EMS 4.0+, the page frame is not limited to just 4 pages and can, in fact, be all or partially located within the 640 kB address range normally occupied by conventional RAM. This feature is used by various multitasking overlays to DOS, such as Desqview, which actually allow program code to be paged in and out. When we say that the EMS memory is "mapped" into this range, what we mean is that the EMS card does not respond to any addresses outside this range. When an address is placed on the address bus outside this range, the EMS board remains totally passive, just as if it was not plugged in at all. When the CPU asserts an address within this range, the EMS board comes to life and responds like regular memory. When the CPU refers to the EMS address space, the CPU's address bits are used along with the page register bits to actually specify which EMS byte to reach. The net effect is to make the EMS card memory appear as a series of "banks" which can be made (one at a time) to masquerade as "real" system memory at a certain address in the range D0000-DFFFF hex. These banks are called EMS pages. Within each page, practically any byte addressed is selected by the system address bus bits that were passed through by the EMS circuitry. The particular page selected is determined by what value was previously written into the EMS page registers. All the physical EMS memory locations that respond to a common value in the page registers are said to be in the same page. That is, once that special value is loaded into the page register, any of those locations can be accessed by the CPU using normal memory read/write instructions. If another value is loaded into the page registers, a totally different set of EMS memory bytes (that is, physically different transistors) are made to respond to the same CPU addresses as before. The model that this behavior suggests is that the EMS memory, divided up into 16 k pages, exists out in limbo somewhere, and is unable to be addressed by the CPU in any way. The CPU can however invoke the right magic to instantaneously plug any one of these disembodied pages right into its addressable memory space. The magic consists of loading the Holy Page Register. The CPU can, with equal ease, banish that same page back into limbo, by putting a different value in the page registers. The thing that makes this magic useful is that any data stored in an EMS page are faultlessly remembered even after they have been banished to zombie land. And, furthermore, those data can be read by the CPU just by remapping it into the address space. This means that an MS-DOS program can juggle megabytes of memory-resident data using just 20 address bits in good old 8088 real mode. Of course at any one given instant, most of those data are in zombie land, but no matter, they can be called back from the netherworld with a simple, hardware-assisted incantation in microseconds. EMS Memory Managers Or Drivers ------------------------------ Each manufacturer of an EMS board is free to design the actual circuitry of his EMS board to suit his whim, his engineers, and his marketing plan. Most boards are different in a real, physical way from one another. The magic incantations necessary to shuffle EMS pages between here and Hoboken are different for each one. Does each application program need to know which particular brand/model of board is plugged in and what its religion is? Fortunately not. Enter the enhanced memory specification. EMS is a specification of a standardized way that applications interact with EMS hardware. This interaction is via the software interrupt feature of the 8088/MS-DOS. All applications that wish to use EMS memory call interrupt 67H the same way with the same arguments, no matter who made the board. When the interrupt is issued, control passes to the memory resident EMS management software, usually called either an EMS memory manager or EMS driver (same thing). This piece of software is unique to each brand of board and is normally supplied by the board's vendor. It is the express purpose of this piece of software to turn the standard EMS invocation arguments into the particular set of hardware incantations understood by the board. Beware mixing boards and drivers from different sources! This may work in rare circumstances but will eventually lead to consumption of excessive amounts of alcoholic beverages. Extended Memory --------------- OK. Now we know how EMS works: It expands a selected 64 kB-sized range of addresses in the CPU's address space to several megabytes by paging-in one chunk at a time. But what about "extended memory"? Actually extended memory is a much simpler concept. Remember those unused address lines in the 80286 and 80386? (MS-DOS and other real-mode applications only use the first 20 of the 80286's 24 and the 80386's 32). They were not put there for decoration. The CPU can be put in protected mode and can then use those extra address lines to address megabytes and megabytes of memory without needing the help of the special EMS hardware like page registers and private (EMS-card) address busses. In protected mode, the CPU can address all physical memory in the same, natural way. In fact, the one megabyte boundary loses all significance, except for the painful memory of what it used to be like back in that awful 20-bit real mode. Extended memory is thus just like conventional memory, just extended up to higher addresses. The down side is, of course, that MS-DOS does not know how to switch into protected mode, and wouldn't know what to do there if it did. Rectifying this shortcoming, and all its implications, is the sole reason for OS/2. Software Approaches To EMS Implementation ----------------------------------------- The discussion of EMS so far has talked exclusively about hardware approaches to EMS. In the 8088, hardware must be employed to supplement the deficiencies of that chip. In the 80286 and 80386, however, there are software-only methods to give the same capability as EMS hardware. Both approaches use extended memory for the storage of EMS page data. In the 80286, EMS memory contents are brought into the 1 MB, conventionally- addressable range by physically copying 16 kB blocks of memory to and from extended memory. The EMS "page" that the application program sees is actually a block of conventional memory that has been filled with the contents of a block of extended memory. The copying is done by a piece of software known as an EMS emulator (driver) which is usually loaded like other DOS device drivers in CONFIG.SYS. Note that to use the extended memory, the EMS driver must switch into protected mode, copy the data, then hightail it back into real mode to keep DOS happy. The extended memory blocks, in this scheme, are emulating a block of memory that would normally be physically resident on the EMS card. Note that these are not really "paged"-in in the same sense as true EMS pages, nor is there any "mapping" going on. All physical memory contents retain their actual addresses as far as the CPU is concerned, only their contents are copied back and forth. The advantage of this scheme is that EMS capability can be achieved in machines without actual EMS hardware. A disadvantage of this scheme is its performance. Whole 16 k blocks must be moved to use a new page (which takes milliseconds), in contrast to "true" EMS in which just a page register must be loaded (which takes microseconds). Another disadvantage is the fact that some precious conventional memory is consumed by the emulated page frame. In the 80386, the solution is much more elegant. In true EMS, the contents of the page registers can be thought of as a memory-mapping table. That is, the contents of the page register, in essence, point to a particular block of EMS-card-resident memory, change the page register contents, and make a new physical page show up in the page frame. The 386 was designed for operating systems much more sophisticated than MS-DOS; these operating systems take for granted the presence of memory mapping capability. The 80386 has, in fact, an internal memory mapping facility much more sophisticated than the crude, bank-oriented page registers of an EMS card. The 386's memory management unit allows any arbitrary-sized chunk of physical memory to be mapped to anywhere in the address space, including the lower 1 MB. And, most importantly, to the address where an EMS-aware application expects to find the page frame and the EMS pages contained therein. With the 80386, hardware within the CPU performs the mapping previously done by EMS hardware. Programming of the CPU's mapping registers is performed by a device driver usually known as an expanded memory manager. Memory managers are written to run on the (standard) 80386 and not some particular vendor's EMS hardware. This allows third-party vendors to produce EMS emulators for any 80386. Examples are "QEMM-386" by Quarterdeck Systems and "386-to-the-Max" by Qualitas. Finally, there is one more software approach to EMS that can be used with any machine. That approach is called virtual EMS and employs a system's hard disk as storage for EMS pages. A device driver intercepts EMS calls in much the same way as the approach described above for the 80286, except that copying is done between a page frame in conventional memory, and sectors of your hard disk. This is a clever approach, and allows EMS memory to be much greater than the amount of memory in your machine, but, because disk is thousands of times slower than semiconductor memory, this approach should only be used by the terminally desperate. Appendix -------- Not all "memory" expansion cards are EMS cards. There is another type of memory called extended memory which is used by other operating systems such as OS/2 and Unix. It is also used by a few DOS utilities, most notably IBM's VDISK RAM disk emulator. If your computer is advertised as having more than 640 kB of memory installed, it's a good bet that it's extended memory and not EMS memory. Few applications can use extended memory, although by using a software technique which will be discussed in a moment, extended memory can be made to serve as EMS memory. Before deciding on an EMS strategy, determine the type of memory your computer already has installed. Be forewarned: IBM, as usual, has a different name for extended memory (like everything else). They call it (you guessed it) expanded memory. So, if you bought it from IBM, and it's called expanded memory, it's extended memory. Everyone else pretty much sticks to standard nomenclature but to be sure, look for the phrase "EMS x.x compliant" in the documentation. The x.x is usually a number like 3.2 or 4.0. Many EMS cards allow the memory contained on them to be configured as all EMS memory, all extended memory, or a mixture. If you use VDISK or any other special programs that use extended memory, you may wish to reserve part of the board's memory for use as extended memory. Otherwise, there's really no good reason for not configuring all of your memory as EMS. (Note that EMS boards are generally more expensive than "plain" extended memory boards because of the additional circuitry required). Consult your board's users manual for the proper switch settings or software settings to give the mix you desire. EMS cards can be used in any machine, but are usually found in 8088s and 80286s because there is a better and cheaper way to go in 80386s. (Editor's note: DEC Rainbows allow using up to 917 504 characters of memory as conventional memory.) ----------------------------------------------------------------------------------- Questions And Answers Do you have a computer-related problem? Send it to us. We can publish it, and if we do not know a solution, perhaps someone else in our users group can provide one. QUESTION: Can you explain why I get error messages from the Microsoft Macro-80 assembler (M80.COM) for CP/M? I tried to assemble the file ZMP-ROB.Z80 according to the directions I have, but M80 refuses to compile. ANSWER: M80 objects to '-' in the source file's name. Try renaming to 'ROB.Z80'. QUESTION: Can I transfer files on disk from a Commodore 128 to a DEC Rainbow? I am using CP/M on both machines, but the diskette formats are different. ANSWER: Both the Commodore 128 and the Rainbow can use the IBM CP/M-86 single- sided diskette format. Our group's library has a utility, NFORMAT.COM, which allows a C128 to place this format on diskettes. QUESTION: I like to use the SETRAM utility to get a RAM drive under MS-DOS, but am hampered by the restriction to 32 files in the drive. Is there any way to get more files into a SETRAM drive? ANSWER: The 32-file limit applies only to the root directory. We have put over 100 files into a single subdirectory of a SETRAM drive. QUESTION: What hardware and software can be used with a DECmate I? In particular: Is there any software besides WPS-8 which runs on this machine? Where can one get a DF02AC or compatible modem for this DECmate? Can other modems be used? Will software for a DECmate II work with a DECmate I? ANSWER: We do not know the answers to these questions. Can readers help us? ----------------------------------------------------------------------------------- Buy, Sell, Or Swap This section is presented as a service to members. There is no charge for advertizements placed here, though donations will be accepted. Only items related to computing will be advertized; if you wish to sell an old car, we respectfully suggest that you publicize elsewhere. Advertizements are not accepted from suppliers. In accordance with DECUS policy on commercialism, we do not print prices. Ads should preferably be submitted to the editor in writing or as ASCII computer files, but may also be phoned in. ---------------------------------- FOR SALE: Superbrain computer with plenty of CP/M software. Contact Robert Deane at (604) 535-9075. FOR SALE: Poly-XFR CP/M communications software for Rainbow 100. The software is in the original package with all documentation. Three 65 536-character DRAM (memory) chips. One serial-to-parallel interface. One AC computer fan. These items are just taking up space now, so all offers will be considered. Telephone David P. Maroun at (604) 792-4071. WANTED: A PC380--just the system (cards, hard drive, and motherboard). No peripherals required. Telephone Dido Diseko at (204) 284-8100 during business hours, (204) 261-4671 after office hours. FOR SALE: Peachtree business modules for MS-DOS: PeachCalc spreadsheet, personal calendar, job cost system, and inventory control. Any offer will be seriously considered. Note: These modules require Code Blue and maximum memory to run on Rainbows. Contact David P. Maroun at (604) 792-4071. FOR SALE: One memory expansion board with a nominal capacity of 192 k, for a DEC Rainbow. Contact Ken Alger at (604) 724-3181. WANTED: Read-only memory (ROM) chips to allow a DEC LA100 printer to print 8-bit characters and to print near-letter-quality text at twelve characters per inch. Telephone David P. Maroun at (604) 792-4071. ----------------------------------------------------------------------------------- What Do You Think Of This Issue? Please tell us what you liked or did not like. The best articles were:__________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ The worst articles were:_________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ Comments or suggestions: Send your opinions to The Editor, VARUG Newsletter, 9395 Windsor Street, Chilliwack, BC, Canada V2P 6C5.