Info-IBMPC@C.ISI.EDU.UUCP (01/24/87)
Info-IBMPC Digest Friday, January 23, 1987 Volume 6 : Issue 4 This Week's Editor: Billy Brackenridge Today's Topics: Minix Special Edition ---------------------------------------------------------------------- [I am reprinting the original article on Minix we published a few weeks ago. Discussions on minix have been raging on usenet for the last few weeks and now there is even a mailing list devoted to minix. INFO-IBMPC doesn't limit its self to discussions of MS-DOS systems. Minix is welcome here as well, but perhaps some of the more unix oriented mailing lists are more appropriate. We will just see how things go. This looks like a great product and should be a boon to anyone teaching or wanting to learn more about operating systems. I hope Minix is a great success. It deserves the support of the network community. -wab] Date: 22 Dec 86 09:33:09 GMT From: ast@bottercs.vu.nl (Andy Tanenbaum) Subject: UNIX Clone With Source Code Available Date: 22 Dec 86 09:33:07 GMT Organization: VU Informatica, Amsterdam I have recently finished rewriting UNIX from scratch. This system, called MINIX, does not contain even a single line of AT&T code, so it can be distributed with source code. It runs on the IBM PC, XT, and AT and those clones that are 100% hardware compatible (not all, unfortunately). To the average, unsophisticated user, using MINIX is indistinguishable from using V7 UNIX. Experts will notice that some relatively less commonly used programs and features are missing. MINIX FEATURES: - System call compatible with V7 UNIX (except for a couple of minor calls) - Kernighan and Ritchie compatible C compiler is included - Shell that is functionally identical to the Bourne shell is included - Full multiprogramming (fork+exec; background jobs in shell: cc file.c & ) - Full screen editor vaguely inspired by emacs (modeless, autoinsert, etc.) - Over 60 utilities (cat, cp, grep, ls, make, mount, sort, etc.) - Over 100 library procedures (atoi, fork, malloc, stdio, strcmp, etc.) - Supports a hard disk, but also works quite well with just floppies - Contains programs to read and write MS-DOS diskettes - Full operating system source code is included - Source code for all the utilities (except C compiler) is included - System will recompile itself (requires 640K and 2 floppies or 1 hard disk) - C compiler source is available as a separate package - Kernel organization radically different from UNIX and much more modular - Software is not copy protected Furthermore, I have written a 719 page book telling you everything you ever wanted to know about operating systems in general and this one in particular. The book contains the manual pages, an appendix describing how to recompile the system from the sources supplied, a full source code listing of the operating system (253 pages), and a cross reference map. The software is available in 4 packages (book is separate): - Box of eight 360K diskettes for 640K IBM PCs (512K is sort of ok too) - Box of eight 360K diskettes for 256K IBM PCs (no C compiler) - Box of five 1.2M diskettes for the IBM PC-AT - 9 track industry standard tape (1600 bpi, tar format) All four distributions contain the full source code, about 54,000 lines, (kernel + utilities, except the compiler), virtually all of it in C. The source code for the C compiler is also available separately (as described in the book). The C compiler is NOT based on pcc at all. It is based on ACK (see Communications of the ACM, Sept. 1983, pp. 654-660). The following programs are included, among others. Like the kernel, these have all been rewritten from scratch by me, my students, people I paid to write them or in a small number of cases, were donated by other people to whom I am grateful: ar basename cat cc chmod chown cmp comm cp date dd df dosread echo grep gres head kill ln login lpr ls make mkdir mkfs mknod mount mv od passwd pr pwd rev rm rmdir roff sh shar size sleep sort split stty su sum sync tail tar tee time touch tr true umount uniq update wc The book and software are being sold by Prentice-Hall. They are NOT public domain. However, the publisher does not object to people making a limited number of copies of the software for noncommercial use. For example professors may make copies of the software for their students. Universities may exchange modified versions. You may make a few copies for your friends etc. If you want to port the software to other CPUs and sell it, you need permission from Prentice-Hall, but they will not be unreasonable. To acquire the software, go to any bookstore and ask them to order the book for you: Title: Operating Systems: Design and Implementation Author: Andrew S. Tanenbaum Publisher: Prentice-Hall (Jan. 1987) ISBN: 0-13-637406-9 In the book you will find a postcard that you can use to order the software. Please don't ask me for the software. I have already spent approximately 8000 hours over the past 5 years writing it; I don't want to spend the next 5 years duplicating floppy disks. The book costs about $35. The software is $79.95 per set, including the source code. I hope most people will consider $79.95 for the binaries and sources of something almost functionally equivalent to UNIX as being reasonable. I know of no other software package where you get 54,000 lines of source code for this price. As bugs are reported, I will send Prentice Hall new disks, so that the version they sell will remain up to date. (This also provides some incentive to buy rather than copy.) For those of you going to USENIX or UNIFORUM in Washington, D.C. January 20-23, Prentice-Hall will have a stand at the show where you can play with the software. You can also buy the stuff there, but since the P-H people drive to Washington in their own cars, they have a limited carrying capacity and they are only taking 50 copies, so get there early the first day. If anyone is interested, we could set up a newsgroup comp.os.minix to discuss minix, report bug fixes, distribute updates of individual files etc. This letter is being multiply posted to several newsgroups. I propose that the initial discussion take place in comp.sys.ibm.pc (subject: MINIX) to avoid having it spread all over the place. Besides, the only other newsgroup I read is mod.recipes. I don't think the moderator will go for floppy disk with Hollandaise sauce. Andy Tanenbaum, Vrije Universiteit, Amsterdam (mail to minix@cs.vu.nl; if your machine doesn't know where nl is [The Netherlands], try minix@vu44.uucp, but that will vanish soon) ------------------------------ From: ast@botter.cs.vu.nl (Andy Tanenbaum) Subject: MINIX Date: 10 Jan 87 22:33:17 GMT Date-Received: 13 Jan 87 09:03:08 GMT Organization: VU Informatica, Amsterdam First, I would like to apologize if I over-crossposted. I haven't posted much to the net before, so I may have done things wrong. I was under the impression that if one sends to multiple groups it cross posts them in such a way that each reader only gets the message once, even if the reader subscribes to all of them. If I am wrong will somebody please tell me how to do it (by mail). It is also possible that I messed up. Furthermore, we were having news and mail problems at the time, which may have contributed. It was my intention that a lot of people see it once, not that a few people see it many times. As to being commercial, that's true I guess, but since I am supplying 50,000 lines of source code without copy protection for $79, and I don't mind a limited amount of copying of the binary and source code, it is not in the same league as normal PC software in terms of the owners zealously guarding both binaries and sources. In fact, it is probably somewhat closer to the Free Software Foundation's way of doing things (also copyrighted) than to Lotus. I assumed (and judging by the response, probably correctly) that there would be a fair amount of interest. Sorry if I offended people. Maybe it would be best to set up comp.os.minix now. Will everyone who would want to subscribe to it send me mail. If there is a sufficient number, I will ask the local guru how one sets up a new group and try to avoid messing that up too. I will cross post this to various groups, but just stick to comp.sys.ibm.pc or comp.os.minix (depending on the reaction) in the future. Several people have asked me questions whose answers may be of general interest, so I will post them here. Q1: Can you have multiple users on a PC? A1: In theory yes. The terminal driver has an array indexed by terminal number from 0 to some maximum. At present that maximum is 1, so you have to change a constant and recompile the tty driver. Also, there is no RS232 driver (the deadline had a race with RS232 and the deadline won). Therefore such a driver has to be made, but it is quite simple. Most of the hooks and handles you need are already there, for example, when it is time to output a character on tty n, the driver calls a function pointed to by tty_struct[n].tty_devstart, so each terminal can have a different routine to actually output the character. In this way you can mix various device types. Q2: How compatible does a machine have to be to run MINIX? A2: It needs a NEC uD765 chip as floppy disk controller, a Motorola 6845 as video controller, etc. If the hard disk controller is nonstandard, the hard disk won't work, but the rest will. Machines with different I/O chips but try to hide this by presenting the same BIOS interface won't work. About a dozen different clones have been tested. MINIX worked without problems on 80% and failed on 20%. Q3: Can you call assembler routines from the MINIX C compiler in order to write drivers for new devices? A3: Yes. The C compiler uses the standard UNIX calling convention of pushing the parameters onto the stack in reverse order, so there is no problem writing bits of a program in assembler. The assembly language accepted by the MINIX assembler is identical to that of PC-IX, the "official" IBM UNIX system for the PC. Assembly routines for reading and writing I/O ports are present in the file kernel/klib88.s (port_in and port_out). Q4: What do you mean it will sort of run on a 512K machine? A4: It will boot fine and run ok with 512K, but since it doesn't swap, it won't be possible to run a lot of background jobs without running out of memory. Also, if you use make, you may discover that make + cc + the various passes that get forked off may not fit in core at once, which causes EXECs to fail and make to get an error return. This can be solved by changing the amount of stack space allocated to the compiler passes using the chmem utility. (chmem is functionally the same as in PC-IX, which works the same way.) Reducing the stack allocated to compiler passes means that some very large programs may not compile. With a 640K system, files > 50K characters have compiled. With 512K, that limit may be lower. Andy Tanenbaum (minix@cs.vu.nl) ------------------------------ From: ast@botter.cs.vu.nl (Andy Tanenbaum) Subject: MINIX - From the mouth of the horse Date: 8 Jan 87 23:11:03 GMT Organization: VU Informatica, Amsterdam I have just learned of quite a discussion going on in comp.sys.atari about porting MINIX to the Atari. For all I know a similar discussion is going on in comp.sys.amiga and elsewhere. I am cross posting this to several groups in case there are people there who are interested in porting MINIX to their machine. If you missed the original note in mod.os.unix, I have just written a UNIX clone that is available now with all the SOURCE CODE for $79.95 from Prentice-Hall. There is also a book telling how it works inside. I suggest that subsequent discussion go on in comp.sys.ibm.pc to avoid scattering it all over the place. At the very least, crosspost comments to comp.sys.ibm.pc under the subject MINIX. Later, we can set up comp.os.minix if there is enough interest. Read the comp.sys.atari group under the heading Forwarded for the last 2 weeks to get the background for this note. Although MINIX is copyright (not licensed), Prentice-Hall has agreed to permit people to make a LIMITED number of copies for educational use, home study etc. Posting the source code on the network (54K lines of C, kernel+utilities) is a no no, but if each purchased copy doesn't generated more than say, 2 or 3 copies it is ok. While this is not public domain it is a lot better than Lotus, Microsoft, Borland, and every other software company in the world's policy. About the pricing. It is clearly not shareware, but by publishing the source code on diskette, we are clearly not acting like AT&T either. I had some discussion with people like Brian Kernighan (author of the Software Tools package) and Doug Comer (author of Xinu, a little embedded operating system for the LSI-11, although not really UNIX like) and came to the following conclusion. I would like to see MINIX become widespread, so the distribution mechanism is crucial. Having a major publisher like Prentice-Hall advertise it, bring it to shows, send out junk mail, etc. will get it a lot more attention than a note on the net. Getting a commercial publisher like Prentice-Hall interested means charging something. I think in the long run, this funny, copyrighted but not real aggressive position we are taking will cause MINIX to become widespread, new software to be made for it, etc. The GNU people are upset because deep in their hearts they, too, know that people would rather pay a reasonable price for good stuff than get empty promises for free. Does anyone know how much GNU charges for its "free" software for the tape, postage, handling etc? Berkeley generally charges something like $125 for its tapes, as I recall. If GNU also charges $125 for its "free" software it seems to me that their moral indignation at Prentice-Hall's outrageous $79.95 price is somewhat weakened. I mentioned MINIX in netnews last year and I got quite a few reactions. I have also contacted lots of people for various reasons. With two exceptions, everybody congratulated me and wished me good luck. Some people, especially Martin Atkins, Charles Forsyth, and Richard Gregg gave me a lot of help, for which I am grateful. Only two people were really negative, almost bitter--both from the Free Software Foundation (names withheld because I don't believe in character assassination on a world-wide network). I am tempted to comment further, but I won't. As to the port to the Atari/Amiga/etc as far as I see, there are no technical problems with the MMU. The trouble is as follows. When you fork, the child has to go somewhere else in memory than where the parent was. Unfortunately, the child's stack contains absolute addresses, such as the return from the fork routine. If the child runs somewhere other than where the parent was, it will crash. There are a couple of solutions, the simplest of which is this. When the child is created, record in the process table where the parent was. When it is time to run the child, just swap the parent and the child, and actually run the child where it belongs. When the parent wants to run, swap them again. Although this sounds horrendous, it is not at all so bad. Swapping two 10K programs in memory might take 30 millisec. MINIX programs are small. I am a strong believer in Small is Beautiful. At the end of this note you will find the sizes of the MINIX utilities. The only big ones are the compiler passes, cpp, cem, opt, cg, and asld. Furthermore, 99.9% of the time, the child does an EXEC, at which point the operating system can put the parent back where it belongs, and put the new core image anywhere in memory. In practice, all this trick will cost is about two copies of the forked core image, and it doesn't require modifying the compiler. My experience with fragmentation is that it is not bad. MINIX doesn't swap because one of the design goals was to have it run on CHEAP hardware (meaning a 256K PC with 1 floppy disk) and floppies are not ideal as swapping devices. The MINIX memory management scheme is very simple, because the PC's hardware is primitive. A core image consists of the text, the data, a gap, and then the stack, growing downward. The stack and the data segments grow into the gap. If they meet, BOOM! In practice, very few programs have wildly growing stacks or data segments. I ran some statistics once, and for 90% of the MINIX utilities, 2K stack is plenty. On the PC, the text is limited to 64K, and the data + stack is also limited to 64K. On a 68000, there would be no need for such a limit. It comes from the 8088 architecture. All you have to do is change a couple of constants in the memory manager. The book is already out. You should be able to order it at any book store. The title is Operating Systems: Design and Implementation. The software will be out in three weeks. It went into production about three weeks ago, and it takes about six weeks. Don't ask me why. Probably the same reason as why it takes Prentice-Hall 18 months to produce a book from the finished manuscript (unless you give them camera ready copy, as I do). If you want to get the software (either on PC diskettes or 9 track tape), first order the book and then send back the business reply card (software order form) in the book. I would like to see a MINIX version for the Atari/Amiga/etc. The 68000 is clearly much better than the 8088, but the PC has a lot of software going for it. Maybe a tolerable UNIX clone might help the Atari/Amiga/etc in its fight against the monster from 8088-land. A colleague of mine at Philips has already started to port MINIX to the Atari. He is an absolutely top rate programmer, but he is VERY busy, so he doesn't have much time. I think he has already rewritten the MINIX assembly code (low level interrupt handlers, etc) for the 68000. I will check with him one of these days; he seems to be away right now. What I would like to find is someone who: (1) knows the Atari (Amiga, Macintosh, etc) hardware well (2) knows UNIX well on the outside and moderately on the inside (3) has a substantial amount of free time (4) has access to an IBM PC for testing things etc. (not essential, but helps) Perhaps such a person could do the port with a little assistance from me. Unfortunately I don't have much time either, as Prentice-Hall is bugging me to revise a book on networks I wrote a million years ago. The main things to do, other than the 68000 assembly code, are the device drivers, all of which are in C, but of course are totally different for the PC and Atari etc. The PC version doesn't use the BIOS at all, because the stupid thing doesn't use interrupts. When you start a background job up and then start up the editor in the foreground, calling the BIOS to read a character would put the whole computer in a tiny loop sitting and waiting for the keyboard to produce a character. MINIX supports the full UNIX multiprogramming, so I had to write all the drivers from scratch (in C). I suspect that the Atari BIOS isn't any better, although maybe we could use the screen output BIOS. And here we come back to the $79 again. If the person doing the port does a good job, Prentice-Hall could sell the other version on diskettes, source code and all, for the same $79 as the PC version. I have enough clout with P-H that I think I could arrange that. Needless to say, the person doing the port would be remunerated for his efforts, probably in the form of a royalty on each disk set sold. The royalty is typically only a couple of dollars, but that small amount is why capitalism works and socialism doesn't. If anyone is interested, let me know. I don't think it will be that difficult, but you have to plow through much of a very tightly written 719 page book and understand a 12,000 line program before you can even start, so it will no doubt be months of work. Also, debugging operating system code on a bare machine even a relatively nice one like the 68000, will be a fair amount of work. One other point is the compiler. The compiler is based on ACK, which is described in Communications of the ACM, Sept. 1983, pp. 654-660. ACK is a big system for writing compilers. It is being distributed by UniPress in Edison NJ and Transmediair in Utrecht, Holland. It uses the old UNCOL idea of having front ends that generate a common intermediate code and then back ends that compile from that code to the target machine. At present we have front ends for C, Pascal, Modula 2, Basic, Occam, and even a subset of Ada. There are back ends for virtually every micro around, from the 6502 to the 68020. The ACK software is owned by the university I teach at. UniPress pays them a royalty on each copy they sell (academic price is $995 for a source tape containing 6 megabytes, although Modula 2 and Occam aren't on the tape yet). Our department doesn't have much money, and we use the royalties to allow grad students to go to conferences and the like. For these reasons the compiler kit is not part of MINIX. Furthermore even the 8088 C compiler source by itself fills 4 diskettes. If the compiler source were in the MINIX distribution, that would have meant raising the basic price to over $100, very much against my idea of keeping the price low. I personally wrote MINIX in my spare time, which is why it doesn't have to follow the same rules as ACK. Nevertheless, the source of the 8088 MINIX C compiler is available as a separate package from UniPress. I suspect that the easiest way to get a 68000 C compiler is for someone at a university to have their university buy the ACK tape and use that to develop the 68000 compiler. When it is done, it will be necessary to negotiate a deal with UniPress to allow it to be sold, but I know Mark Krieger, the president of UniPress, and he is a reasonable guy, so I am sure some deal can be worked out that won't raise the price too much. He is on the net (msk@unipress.uucp) if you have questions about all this. The reason that I think this route is the easiest, is that ACK already has a backend for the 68000, so there isn't much work to be done, but you really need a VAX or a SUN or something like that to bring up the full ACK development system. The compilers that are produced aren't so big, but the compiler- compilers, and backend generators and the other meta-software doesn't really fit easily on a PC. In addition to the 6 megabytes of source code on the tape, you have to count on at least 20 megabytes of object files and working space to compile everything. The 68000 compiler has been running for years and it is pretty good. We recently rewrote the backend table for the 68000, 68010, and 68020 and the code quality seems very good (about 15% better than the C compiler Motorola sells). I haven't even thought about using the Pascal, Modula 2, Basic etc. front ends because I wanted the system to fit on, and be able to recompile itself on a system without, a hard disk. This succeeded. Technically there shouldn't be any big problem with the other front ends. Note that UniPress has TWO packages: 8088 MINIX C compiler, and full ACK. The former is 4 diskettes; the latter is 6 megabytes on a mag tape. Andy Tanenbaum (minix@cs.vu.nl, or in emergencies, minix@vu44.uucp) Sizes of the MINIX commands Program Text Data Bss Total (all sizes in decimal bytes) sync: 424 20 26 470 clr: 714 28 156 898 update: 836 42 58 936 sleep: 848 58 58 964 ln: 1070 86 74 1230 chmod: 984 98 156 1238 basename: 1060 66 156 1282 tee: 1228 82 94 1404 kill: 1240 78 156 1474 umount: 782 758 26 1566 touch: 1348 76 156 1580 sum: 1438 84 156 1678 mknod: 930 738 26 1694 mount: 890 782 26 1698 pwd: 1546 84 172 1802 mkdir: 1656 158 58 1872 split: 1656 132 130 1918 rev: 886 42 1052 1980 rmdir: 1802 196 188 2186 cat: 1212 722 540 2474 mv: 2444 244 58 2746 echo: 648 24 2076 2748 stty: 2336 260 170 2766 rm: 2468 276 30 2774 df: 2030 948 156 3134 time: 2584 666 266 3516 lpr: 1314 126 2114 3554 comm: 1822 104 2400 4326 tr: 1470 82 2852 4404 login: 3376 1436 28 4840 chmem: 3178 278 2074 5530 size: 3102 232 2208 5542 tar: 4010 456 1774 6240 head: 2762 168 3484 6414 wc: 4460 208 2104 6772 su: 3548 1498 2076 7122 dd: 4966 532 2148 7646 chown: 3522 2148 2074 7744 date: 5338 412 2104 7854 od: 5388 288 3654 9330 passwd: 4976 1764 2620 9360 pr: 5776 514 3110 9400 sort: 6404 694 2490 9588 grep: 6740 694 2208 9642 uniq: 4956 850 5150 10956 cc: 4404 826 5986 11216 cc.at: 4404 834 5986 11224 gres: 8496 768 2076 11340 tail: 4550 184 7200 11934 ar: 4900 488 11350 16738 mkfs: 8708 906 7376 16990 roff: 12742 820 4710 18272 cp: 1914 876 16412 19202 make: 15216 1976 3614 20806 shar: 980 82 20506 21568 cmp: 3372 224 18468 22064 dosread: 7440 3688 11992 23120 mined: 15680 2198 5308 23186 sh: 21536 1668 1310 24514 ls: 7164 584 17994 25742 cpp: 16896 3764 8580 29240 (Pass 1 of the C compiler) asld: 14048 7882 7412 29342 (Pass 5 of the C compiler) opt: 16400 9368 9494 35262 (Pass 3 of the C compiler) cg: 24816 22968 10520 58304 (Pass 4 of the C compiler) cem: 59856 10656 3164 73676 (Pass 2 of the C compiler) ------------------------------ From: ast@botter.cs.vu.nl (Andy Tanenbaum) Subject: MINIX Date: 12 Jan 87 12:00:41 GMT Organization: VU Informatica, Amsterdam John Diamant has asked what the difference between the various MINIX packages is. Here is a brief rundown. The binary of the operating system is identical on the 256K and 640K PC version. The only difference is that the binary of the C compiler has been deleted from the 256K version because some of the passes are normally kept on the RAM disk, and with only 256K, the RAM disk is too small to hold them. I just deleted the whole compiler, thus freeing up a little extra space on the /usr diskette. There are 3 differences between the 640K PC version and the 512K AT version: 1. The binary for the PC version has a hard disk driver for the XT type disk embedded in it. The binary for the AT version has the AT type disk driver. Both versions contain the source code for both the XT and AT drivers, so if you upgrade your XT to an AT, you just have to recompile with the other driver. 2. The AT version comes on five 1.2M diskettes instead of eight 360K diskettes. The source programs present on both are identical. 3. The initial configuration of what is on the /usr diskette and what is on the RAM disk is different. The compiler passes won't fit on the RAM disk here either with only 512K, but there is plenty of room on the 1.2M floppies. If you have a 256K or 384K machine and a friend has a 640K machine, get the 640K system and make a new root file system (for the RAM disk) yourself using mkfs. About 55K is the right size, and it should contain the same /etc and /dev as the 640K system; /bin should have only: getlf, sh, and sync. If you have 256K and two floppy disks or a hard disk, you can also copy the C compiler to a second file system, but you have to fix and recompile the little driving program cc.c because the paths of the compiler passes are built into it. If you are going to put the compiler passes in /user/lib or somewhere else, you have to change cc.c so it knows which files to EXEC. When moving the 640K PC system to a 512K AT you have to make the same change. As distributed, cc.c won't compile because I have intentionally included a line saying: !!!!_SEE_BELOW_!!! on line 30 to attract your attention to the comment explaining all this. In summary, you can use the 640K system to reconstruct a RAM disk (root device) for 256K or 384K or any other size using mkfs. You don't have to recompile the operating system. The reason for two different sets is that the RAM disk image (diskette #2) is different for 256K and 640K as described above. The only kernel tuning utility is chmem, which changes the amount of stack space allocated to a program. The mag tape has all the sources but no binaries at all. It was intended for university courses on operating systems that have to use a VAX for the student projects. The tape contains a simulator for the IBM PC (8088 interpreter plus some I/O device simulation) so students can modify MINIX on the VAX and run it on the PC simulator. I would be less than honest to suggest that interpreting a PC on a VAX is blindingly fast, but if you compile the C to assembly code and then patch up the main decode loop by hand and hack away at the condition code routine, you can help somewhat. The tape also contains software to run the file-system-only via a pipe to a test program. This runs at normal speed, but only allows the students to test the file system. Neither of these directories are available on diskette. The complete PC simulator is not a real small program :-) I have found the simulator very useful for debugging however, as it has a wealth of options for tracing, breakpoints, and other debugging. I have had a lot of mail asking about uucp. I don't have one. If anyone has a version that runs on V7 and isn't huge and works (a tall order), let me know or post it. There was also some discussion about whether or not B. Dalton deals in textbooks. They certainly do. I have bought many textbooks at some of their stores. The problem is this. Prentice-Hall, Addison-Wesley, and similar publishers mostly sell to college book stores. The discount off list price is based on the way college book stores work. B. Dalton simply says "We are big and we want a bigger discount." This causes friction. Sometimes B. Dalton gives in, sometimes the publisher gives in, and sometimes nobody gives in. If your local B. Dalton refuses to order the book, try a college book store, or Prentice-Hall's mail order dept. Andy Tanenbaum ------------------------------ From: ast@botter.cs.vu.nl (Andy Tanenbaum) Subject: MINIX Date: 13 Jan 87 18:59:08 GMT Organization: VU Informatica, Amsterdam Bruce Martin writes: > I suppose this should wait until I get the book, but I'm to interested and > impatient. > > First, does MINIX run in the protected mode on an AT? If not, are there > any plans to support it in the future? > > Secondly, has anyone given thought to adding swapping to MINIX. It > would be very useful, and with hard drives becoming so common-place, not > out of the question. It sounds like a lot of work (to me) but well worth > the trouble. > MINIX does not use protected mode on the 286, but adding it wouldn't be that hard, provided one didn't get overambitious and try to redesign the whole memory management scheme to use all those segments. I don't have the time to do it, but maybe someone else does. Although hard disks are getting cheap, so is memory. I think a better improvement would be to allow MINIX to use memory above 640K. On a system with lots of memory and fairly small programs, swapping isn't so important. Andy Tanenbaum (minix@cs.vu.nl) ------------------------------ From: ast@botter.cs.vu.nl (Andy Tanenbaum) Subject: MINIX Date: 15 Jan 87 12:01:29 GMT While developing MINIX I was offered some software from people who shall here remain nameless. This software consisted of utilities taken from AT&T UNIX with the identifiers all changed, the layout modified, and a few changes here and there. Needless to say I sent it all back, warning the authors that making cosmetic changes to AT&T code does not suddenly void their copyright. If you ever get taken to court for copyright violation the judge can easily find an impartial expert witness and ask him if in his opinion the copy was based on the original. If he says "yes" there will be trouble. The MINIX utilities and libraries were all genuinely written from scratch, without even peeking at the UNIX code. The only place you may find some resemblance is in very small subroutines like strcmp. There are not really a large number of fundamentally different algorithms for strcmp, so there will be some similarity. For larger programs like ls or even cp, there is no similarity at all. The policy on posting MINIX source code is this. Although it is copyright, if you have modified some file and think people might be interested in it, it is ok to mail or post it. The only thing to keep in mind is that a large amount of the network traffic goes over dial up phone lines, even if your site happens to be on the ARPANET. When you post something, remember that other people are paying the phone bills. If you want to post a large file, it might be a good idea to first announce it and ask people to send you mail if they are interested. If there isn't much response, mailing it to a few people is much cheaper than posting it to the whole world. On another subject, as you can imagine, I have gotten LOTS of mail, all of it very encouraging. However, one person who works for a major defense contractor said that his employer was planning to aquire MINIX to run on some PCs. Perhaps a word of caution is in order. MINIX was designed with the goal of being an educational tool, for teaching in university or corporate classes, or studying yourself. It was also designed for hackers to play with at home on their PCs, and things like that. I don't think I would like to trust the defense of the entire Western World to it. If you sort of have the vague notion that putting MINIX on your PC will suddenly turn the PC into something like the VAX running 4.3 that you use at work, you will be disappointed. What it does do, is turn the PC into something roughly comparable to a low-end PDP-11 running V7. Mark Harris posted a question concerning MINIX and the EGA board. I honestly don't know if MINIX will work with the EGA board. I don't have access to one. Since the terminal driver is very straightforward, if the EGA board makes a reasonable attempt to emulate the 6845, patching the driver shouldn't be too hard even if it doesn't work initially. Andy Tanenbaum ------------------------------ From: tower@mit-eddie.MIT.EDU (Leonard H. Tower Jr.) Date: 17 Jan 87 21:53:46 GMT Subject: diffs between FSF/GNU, MINIX, AT&T Unix In article <1026@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > ... The GNU people are >upset because deep in their hearts they, too, know that people would rather >pay a reasonable price for good stuff than get empty promises for free. First, I would like to commend ast for doing MINIX, and going a large part of the way towards giving MINIX its freedom. Second, GNU isn't an empty promise. GNU Emacs is out there. GDB (GNU's Debugger) is out there. Bison, a YACC compatible Parser Generator, is out there. The GNU C compiler (highly optimizing with VAX, 68000, and 68020 code generators) will be released soon. Etc. The remaining large undone piece is the kernel. Work has started on that, and its being leveraged off of existing code for a Unix style kernel, Trix, written at MIT a while back. GNU is a more ambitious project than MINIX, and rms hasn't had much more help than ast. Most of rms' help has been volunteer. rms has also been working on it for a shorter period of time. Third, none of the GNU people I know of are upset. We are just sad that yet more software has been chained up. >Does anyone know how much GNU charges for its "free" software for the tape, >postage, handling etc? Berkeley generally charges something like $125 >for its tapes, as I recall. If GNU also charges $125 for its "free" software >it seems to me that their moral indignation at Prentice-Hall's outrageous >$79.95 price is somewhat weakened. First, "free" doesn't refer to cost, but to the freedom of the software. Second, I would like to present some comparisons between GNU, MINIX, and Unix. I know the facts are straight for GNU, correct me on the others. GNU MINIX Unix --- ----- ---- Is source code distributed? Yes Yes For many more $$ How many copies of the source can you give away, legally? Unlimited 3-4 None Can one legally restrict use by others? No YES YES Can one legally post it on USENET? Yes NO NO Can one legally ARPA ftp it, freely? Yes NO NO Cost of non-ARPA distribution from home organization: $ 150. $ 80. Many times more. People are referred to: - the GNU Public License - the GNU Manifesto - Minix's Licensing arrangements (I have yet to see these) - AT&T and susbsidiary vendor Unix Licenses for further details. happy hacking, len tower Len Tower, Project GNU of the Free Software Foundation 1000 Mass. Ave., Cambridge, MA 02138, USA +1 (617) 876-3296 HOME: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739 UUCP: {}!mit-eddie!mit-prep!tower INTERNET: tower@prep.ai.mit.edu ------------------------------ From: ast@botter.cs.vu.nl (Andy Tanenbaum) Subject: MINIX - A Technical Description Date: 15 Jan 87 22:54:20 GMT Below is an extract of the paper I will be presenting at UNIFORUM on Jan 22. I may try to set up a BOF session on MINIX at USENIX for the benefit of people not going to UNIFORUM (I originally submitted my paper to USENIX but it was rejected because it didn't fit in anywhere). Check the listings. I am going to Palo Alto after the meetings, and won't be back reading my mail until early February. Well over 100 people have written me expressing interest in comp.os.minix. I have communicated this to the net adminstrators. Andy Tanenbaum MINIX: A CHEAP UNIX CLONE WITH SOURCE CODE Andrew S. Tanenbaum Dept. of Mathematics and Computer Science Vrije Universiteit Amsterdam, The Netherlands 1. OVERVIEW OF THE MINIX SYSTEM ARCHITECTURE UNIX is organized as a single executable program that is loaded into memory at system boot time and then run. MINIX is structured in a much more modular way, as a collec- tion of processes that communicate with each other and with user processes by sending and receiving messages. There are separate processes for the memory manager, the file system, for each device driver, and for certain other system func- tions. This structure enforces a better interface between the pieces. The file system cannot, for example, acciden- tally change the memory manager's tables because the file system and memory manager each have their own private address spaces. These system processes are each full-fledged processes, with their own memory allocation, process table entry and state. They can be run, blocked, and send messages, just as the user processes. In fact, the memory manager and file system each run in user space as ordinary processes. The device drivers are all linked together with the kernel into the same binary program, but they communicate with each other and with the other processes by message passing. When the system is compiled, four binary programs are independently created: the kernel (including the driver processes), the memory manager, the file system, and init (which reads /etc/ttys and forks off the login processes). In other words, compiling the system results in four dis- tinct a.out files. When the system is booted, all four of these are read into memory from the boot diskette. It is possible, and in fact, normal, to modify, recom- pile, and relink, say, the file system, without having to relink the other three pieces. This design provides a high degree of modularity by dividing the system up into indepen- dent pieces, each with a well-defined function and interface to the other pieces. The pieces communicate by sending and receiving messages. The various processes are structured in four layers: 4. The user processes (top layer). 3. The server processes (memory manager and file system). 2. The device drivers, one process per device. 1. Process and message handling (bottom layer). Let us now briefly summarize the function of each layer: Layer 1 is concerned with doing process management including CPU scheduling and interprocess communication. When a process does a SEND or RECEIVE, it traps to the ker- nel, which then tries to execute the command. If the com- mand cannot be executed (e.g., a process does a RECEIVE and there are no messages waiting for it), the caller is blocked until the command can be executed, at which time the process is reactivated. When an interrupt occurs, layer 1 converts it into a message to the appropriate device driver, which will normally be blocked waiting for it. The decision about which process to run when is also made in layer 1. A prior- ity algorithm is used, giving device drivers higher priority over ordinary user processes, for example. Layer 2 contains the device drivers, one process per major device. These processes are part of the kernel's address space because they must run in kernel mode to access I/O device registers and execute I/O instructions. Although the IBM PC does not have user mode/kernel mode, most other machines do, so this decision has been made with an eye toward the future. To distinguish the processes within the kernel from those in user space, the kernel processes are called tasks. Layer 3 contains only two processes, the memory manager and the file system. They are both structured as servers, with the user processes as clients. When a user process (i.e., a client) wants to execute a system call, it calls, for example, the library procedure read with the file descriptor, buffer, and count. The library procedure builds a message containing the system call number and the parame- ters and sends it to the file system. The client then blocks waiting for a reply. When the file system receives the message, it carries it out and sends back a reply con- taining the number of bytes read or the error code. The library procedure gets the reply and returns the result to the caller in the usual way. The user is completely unaware of what is going on here, making it easy to replace the local file system with a remote one. Layer 4 contains the user programs. When the system comes up, init forks off login processes, which then wait for input. On a successful login, the shell is executed. Processes can fork, resulting in a tree of processes, with init at the root. When CTRL-D is typed to a shell, it exits, and init replaces the shell with another login pro- cess. 2. LAYER 1 - PROCESSES AND MESSAGES The two basic concepts on which MINIX is built are processes and messages. A process is an independently schedulable entity with its own process table entry. A mes- sage is a structure containing the sender's process number, a message type field, and a variable part (a union) contain- ing the parameters or reply codes of the message. Message size is fixed, depending on how big the union happens to be on the machine in question. On the IBM PC it is 24 bytes. Three kernel calls are provided: - RECEIVE(source, &message) - SEND(destination, &message) - SENDREC(process, &message) These are the only true system calls (i.e., traps to the kernel). RECEIVE announces the willingness of the caller to accept a message from a specified process, or ANY, if the RECEIVER will accept any message. (From here on, ``pro- cess'' also includes the tasks.) If no message is available, the receiving process is blocked. SEND attempts to transmit a message to the destination process. If the destination process is currently blocked trying to receive from the sender, the kernel copies the message from the sender's buffer to the receiver's buffer, and then marks them both as runnable. If the receiver is not waiting for a message from the sender, the sender is blocked. The SENDREC primitive combines the functions of the other two. It sends a message to the indicated process, and then blocks until a reply has been received. The reply overwrites the original message. User processes use SENDREC to execute system calls by sending messages to the servers and then blocking until the reply arrives. There are two ways to enter the kernel. One way is by the trap resulting from a process' attempt to send or receive a message. The other way is by an interrupt. When an interrupt occurs, the registers and machine state of the currently running process are saved in its process table entry. Then a general interrupt handler is called with the interrupt number as parameter. This procedure builds a mes- sage of type INTERRUPT, copies it to the buffer of the wait- ing task, marks that task as runnable (unblocked), and then calls the scheduler to see who to run next. The scheduler maintains three queues, corresponding to layers 2, 3, and 4, respectively. The driver queue has the highest priority, the server queue has middle priority, and the user queue has lowest priority. The scheduling algo- rithm is simple: find the highest priority queue that has at least one process on it, and run the first process on that queue. In this way, a clock interrupt will cause a process switch if the file system was running, but not if the disk driver was running. If the disk driver was running, the clock task will be put at the end of the highest priority queue, and run when its turn comes. In addition to this rule, once every 100 msec, the clock task checks to see if the current process is a user process that has been running for at least 100 msec. If so, that user is removed from the front of the user queue and put on the back. In effect, compute bound user processes are run using a round robin scheduler. Once started, a user process runs until either it blocks trying to send or receive a message, or it has had 100 msec of CPU time. This algorithm is simple, fair, and easy to implement. 3. LAYER 2 - DEVICE DRIVERS Like all versions of UNIX for the IBM PC, MINIX does not use the ROM BIOS for input or output because the BIOS does not support interrupts. Suppose a user forks off a compilation in the background and then calls the editor. If the editor tried to read from the terminal using the BIOS, the compilation (and any other background jobs such as printing) would be stopped dead in their tracks waiting for the the next character to be typed. Such behavior may be acceptable in the MS-DOS world, but it certainly is not in the UNIX world. As a result, MINIX contains a complete set of drivers that duplicate the functions of the BIOS. Like the rest of MINIX, these drivers are written in C, not assembly language. This design has important implications for running MINIX on PC clones. A clone whose hardware is not compati- ble with the PC down to the chip level, but which tries to hide the differences by making the BIOS calls functionally identical to IBM's will not run an unmodified MINIX because MINIX does not use the BIOS. Each device driver is a separate process in MINIX. At present, the drivers include the clock driver, terminal driver, various disk drivers (e.g., RAM disk, floppy disk), and printer driver. Each driver has a main loop consisting of three actions: 1. Wait for an incoming message. 2. Perform the request contained in the message. 3. Send a reply message. Request messages have a standard format, containing the opcode (e.g., READ, WRITE, or IOCTL), the minor device number, the position (e.g., disk block number), the buffer address, the byte count, and the number of the process on whose behalf the work is being done. As an example of where device drivers fit in, consider what happens when a user wants to read from a file. The user sends a message to the file system. If the file system has the needed data in its buffer cache, they are copied back to the user. Otherwise, the file system sends a mes- sage to the disk task requesting that the block be read into a buffer within the file system's address space (in its cache). Users may not send messages to the tasks directly. Only the servers may do this. MINIX supports a RAM disk. In fact, the RAM disk is always used to hold the root device. When the system is booted, after the operating system has been loaded, the user is instructed to insert the root file system diskette. The file system then sees how big it is, allocates the necessary memory, and copies the diskette to the RAM disk. Other file systems can then be mounted on the root device. This organization puts important directories such as /bin and /tmp on the fastest device, and also makes it easy to work with either floppy disks or hard disks or a mixture of the two by mounting them on /usr or /user or elsewhere. In any event, the root device is always in the same place. In the standard distribution, the RAM disk is about 240K, most of which is full of parts of the C compiler. In the 256K system, a much smaller RAM disk has to be used, which explains why this version has no C compiler: there is no place to put it. (The /usr diskette is completely full with the other utility programs and one of the design goals was to make the system run on a 256K PC with 1 floppy disk.) Users with an unusual configuration such as 256K and three hard disks are free to juggle things around as they see fit. The terminal driver is compatible with the standard V7 terminal driver. It supports cooked mode, raw mode, and cbreak mode. It also supports several escape sequences, such as cursor positioning and reverse scrolling because the screen editor needs them. The printer driver copies its input to the printer character for character without modification. It does not even convert line feed to carriage return + line feed. This makes it possible to send escape sequences to graphics printers without the driver messing things up. MINIX does not spool output because floppy disk systems rarely have enough spare disk space for the spooling directory. Instead one normally would print a file f by saying lpr <f & to do the printing in the background. The lpr program insert carriage returns, expands tabs, and so on, so it should only be used for straight ASCII files. On hard disk systems, a spooler would not be difficult to write. 4. LAYER 3 - SERVERS Layer 3 contains two server processes: the memory manager and the file system. They are both structured in the same way as the device drivers, that is a main loop that accepts requests, performs them, and then replies. We will now look at each of these in turn. The memory manager's job is to handle those system calls that affect memory allocation, as well as a few oth- ers. These include FORK, EXEC, WAIT, KILL, and BRK. The memory model used by MINIX is exceptionally simple in order to accommodate computers without any memory management hardware. When the shell forks off a process, a copy of the shell is made in memory. When the child does an EXEC, the new core image is placed in memory. Thereafter it is never moved. MINIX does not swap or page. The amount of memory allocated to the process is deter- mined by a field in the header of the executable file. A program, chmem, has been provided to manipulate this field. When a process is started, the text segment is set at the very bottom of the allocated memory area, followed by the data and bss. The stack starts at the top of the allocated memory and grows downward. The space between the bottom of the stack and the top of the data segment is available for both segments to grow into as needed. If the two segments meet, the process is killed. In the past, before paging was invented, all memory allocation schemes worked like this. In the future, when even small microcomputers will use 32-bit CPUs and 1M x 1 bit memory chips, the minimum feasible memory will be 4 megabytes and this allocation scheme will probably become popular again due to its inherent simplicity. Thus the MINIX scheme can be regarded as either hopelessly outdated or amazingly futuristic, as you prefer. The memory manager keeps track of memory using a list of holes. When new memory is needed, either for FORK or for EXEC, it searches the hole list and takes the first hole that is big enough (first fit). When a process terminates, if it is adjacent to a hole on either side, the process' memory and the hole are merged into a bigger hole. The file system is really a remote file server that happens to be running on the user's machine. However it is straightforward to convert it into a true network file server. All that needs to be done is change the message interface and provide some way of authenticating requests. (In MINIX, the source field in the incoming message is trustworthy because it is filled in by the kernel.) When running remote, the MINIX file server maintains state infor- mation, like RFS and unlike NFS. The MINIX file system is similar to that of V7 UNIX. The i-node is slightly different, containing only 9 disk addresses instead of 13, and only 1 time instead of 3. These changes reduce the i-node from 64 bytes to 32 bytes, to store more i-nodes per disk block and reduce the size of the in-core i-node table. Free disk blocks and free inodes are kept track of using bit maps rather than free lists. The bit maps for the root device and all mounted file systems are kept in memory. When a file grows, the system makes a definite effort to allocate the new block as close as possible to the old ones, to minimize arm motion. Disk storage is not necessarily allocated one block at a time. A minor device can be con- figured to allocate 2, 4 (or more) contiguous blocks when- ever a block is allocated. Although this wastes disk space, these multiblock zones improve disk performance by keeping file blocks close together. The standard parameters for MINIX as distributed are 1K blocks and 1K zones (i.e., just 1 block per zone). MINIX maintains a buffer cache of recently used blocks. A hashing algorithm is used to look up blocks in the cache. When an i-node block, directory block, or other critical block is modified, it is written back to disk immediately. Data blocks are only written back at the next SYNC or when the buffer is needed for something else. The MINIX directory system and format is identical to that of V7 UNIX. File names are strings of up to 14 charac- ters, and directories can be arbitrarily long. 5. LAYER 4 - USER PROCESSES This layer contains init, the shell, the editor, the compiler, the utilities, and all the user processes. These processes may only send messages to the memory manager and the file system, and these servers only accept valid system call requests. Thus the user processes do not perceive MINIX to be a general-purpose message passing system. How- ever, removing the one line of code that checks if the mes- sage destination is valid would convert it into a much more general system (but less UNIX-like). ------------------------------ From: henry@utzoo.UUCP (Henry Spencer) Subject: V7 Syscalls List? Date: 16 Jan 87 19:38:05 GMT Organization: U of Toronto Zoology > Can anyone provide a list of the version 7 system calls? ... Here is the full list, from sysent.c of a functioning V7 (utzoo is an 11/44 running V7, although not for much longer). access acct alarm brk (also does sbrk) chdir chmod chown chroot close creat dup (also does dup2) exec (obsolete, see exece) exece (generic, includes execl, execv, execle, execve) exit fork fstat ftime getgid (also does getegid) getpid getuid (also does geteuid) gtty (obsolete; invokes ioctl internally) indir (silly kludge probably unnecessary on non-11 systems) ioctl kill link lock (lock process into memory) lseek mknod (makes directories and devices) mount mpxchan (you don't want to know... not in all V7s) nice open pause phys (map memory into user space) pipe profil ptrace read setgid setuid signal stat stime stty (obsolete; invokes ioctl internally) sync time times umask umount unlink utime wait write -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ From: ast@botter.cs.vu.nl (Andy Tanenbaum) Subject: MINIX Newsgroup Exists Date: 18 Jan 87 14:21:08 GMT The comp.os.minix newsgroup has been set up. Discussion about MINIX can now move there, leaving the comp.sys.ibm.pc people to wallow in MS-DOS. Thanks to all the people who wrote to me and posted notes in support of it. Some of the topics that might be worth discussing in comp.os.minix are: 1. Questions of general interest (for other questions, send me mail) 2. Bug reports 3. Bug fixes (it is ok to post individual files) 4. Experience with MINIX on various machines 5. Discussions about ports to different CPUs, etc. 6. Discussions about networking, news, uucp, etc., none of which exist now 7. New drivers 8. New utilities 9. Experience with MINIX for use in courses (e.g., sample student projects) The port of MINIX to the Atari ST is now fully underway. Please don't ask me when it will be done, since neither I nor the people doing it know. As with any software project, the first 99% is the easy part. I will post status reports when there is status to report. Several people have asked me whether MINIX runs on the brand XYZ clone. It has been briefly tried on a few clones, but not really thoroughly, and I wouldn't want to promise that it worked on some machine if I wasn't absolutely sure. As people get the code and try it out on various machines and with various nonstandard boards, please post your findings to comp.os.minix. The same is true of hard disks. Since MINIX directly addresses the disk controller, it will only work with controllers that are identical to the IBM XT or AT. In fact, it has only been tried on the standard XT and the (old) 6 MHz AT. I assume (hope ?) that the (new) 8 Mhz AT uses the same controller as the old one, even though the drive is larger. Similarly, I haven't tried it on the XT-286. I don't have access to these machines. Len Tower posted a message comparing GNU, MINIX, and UNIX. It may be true that even at $150, GNU is more "free" in some sense than MINIX at $80. If and when the GNU kernel, device drivers, utilities, and documentation have been written, debugged, integrated, ported to some common machine, and distributed, we can better evaluate it in other ways. Some people have been having trouble getting through to me. One person even posted a note to the world-wide net in desperation. The address to use for mail to me about MINIX is minix@cs.vu.nl. For those people whose mailer is not yet converted to domain notation, use minix@vu44.uucp, but this will vanish eventually. Andy Tanenbaum ------------------------------ From: ganesh@utah-cs.UUCP (Ganesh C Gopalakrishnan) Subject: 1. MINIX can run on.. 2. Disk part. 3. Caveats 4. 512K 5. Kudos Date: 22 Jan 87 16:43:37 GMT Organization: University of Utah CS Dept (1) I've succesfully run MINIX on the Leading Edge clone of an ordinary IBM-PC (forget the model number), an ordinary PC, and a Samsung Clone. My friends have run it on a PC-XT and a PC-AT. If you are interested, mail me a note and I'll get the exact model numbers. CAVEAT : I haven't tested and confirmed that all the device drivers would operate correctly on the clones. My OS class (45 students) is using Minix on the Leading Edges, and I will find this out soon. (2) The book (yes, I got one courtesy of PH) gives instructions on how to fool the DOS program FDISK into making multiple partitions, one for DOS, one for MINIX, etc. However, read (3). (3) THE HARD-CARD 20 SOLD BY MAYNARD COPR. isn't compatible with the driver provided for Minix. I learned this the painful way, but could return my HARD-CARD anyway (because it was also hogging too much power and causing floppy errors after long hours of use!). (4) 512 K : I've compiled some small C programs on a 512K machine. The number of processes that you can run are severely limited. You can't stop the full screen editor "Mined" because it runs out of room in an attempt to fork. There are ways of circumventing the lack of a full 640 K (by moving programs around to leave enough space on the RAM disk, etc.). I'd rather spend the extra $20 that it costs these days to get a system upgraded to 640 K, if you have the space on the memory board. (5) Finally, Kudos to Andy Tanenbaum and students for their mammoth effort. The system is really rugged and well documented. I could recompile and re-build the system with ease. The book is packed with information. I think I've run into one minor bug so far, and I will post more details after I study it closely myself. Ganesh ------------------------------ Date: 21 Jan 87 22:37 PST From: BSF.COR@OFFICE-1.ARPA Subject: MINIX Talk Computer Literacy Bookstore has asked me to pass the word that Dr. Andrew Tanenbaum will be at their new store on Wed, Jan 28, 1987 at 7:00 pm to discuss MINIX. Computer Literacy Bookstore Techmart 5201 Great America Parkway (at Tasman) Santa Clara, Ca (408) 562-5799 Bill Frantz - Key Logic ------------------------------ End of Info-IBMPC Digest ************************ -------