Tech Insider					     Technology and Trends


			      USENET Archives

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!mcvax!botter!ast
From: a...@botter.UUCP
Newsgroups: comp.os.minix
Subject: Response to news and mail
Message-ID: <1049@botter.cs.vu.nl>
Date: Sat, 31-Jan-87 18:04:10 EST
Article-I.D.: botter.1049
Posted: Sat Jan 31 18:04:10 1987
Date-Received: Sun, 1-Feb-87 16:23:48 EST
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 222

I just got back from D.C. and Palo Alto.  There was lots of news and mail.
In this note I will respond to those issues that I think may be of interest
to more people than just the person who brought it up.  There has been a lot
of discussion about somewhat metaphysical issues so far, but as more people
begin looking at the code, that should change.   P-H has the diskettes and
tape in production now.  It shouldn't be more than a couple of weeks now.
When a big company does something on a large scale, it takes longer than a
single individual doing it once.  You wouldn't believe how many iterations
it took just to get the diskette labels right, even though I gave them the
exact text in typewritten form.

I gave a paper on MINIX at UNIFORUM and a BOF session at USENIX.  The
former was attended by maybe 100 people belonging to the three piece suit
crowd.  The latter was well attended by a crowd that would probably be
more inclined toward tee shirts and sandals if there hadn't been 15 inches
of snow on the ground.  I also gave a talk on MINIX at the Computer Literacy
bookshop in Silicon Valley.  The owner of that store, Dan Doernberg, called
up P-H so many times that he actually convinced them to let him stock the
diskettes.  Call them at (408) 730-9955 for more info.  I don't believe any
other store is planning to stock them, but you can order the software by mail
using the card in the back of the book.  Things may change in a couple of
months.  P-H is slowly starting to think about having other stores stock the
software.  I'll discuss this when the dust settles.

Here are some comments in no particular order.

I tested the 1.2M diskettes on a few AT clones at the UNIFORUM show.  The
results are listed below.

Machine			Did MINIX run?		Hard disk ok?
-------			--------------		-------------
Epson Equity 3		yes			yes
BIOS silent partner	yes			yes
Honeywell AP		yes			yes
Unisys Micro IT		yes			yes
NCR PC8			yes			see note 1 below
IBM PC-AT @6MHz		yes			yes
IBM PC-AT @8MHz		yes			no
IBM XT-286		yes			no
Televideo Telenix 286	yes			no, but see note 2 below
Compaq portable 2	no			?
Compaq 386		no			?

Note 1: MINIX was consistently able to read the first 80 blocks, but 
        consistently got errors after that.  I think this means that the
        machine uses the same controller as the 6MHz AT, but the drive is
        formatted differently, or the controller can't handle implied seeks
        or something like that.  The driver will require some patching for
        this machine, but I suspect the patching will be simple once it
        is figured out what happened.

Note 2: The machine I tested didn't have Televideo's standard disk.  Since
        the person at the show was only a salesperson, he didn't know what
        kind it did have.  Nor did he know what kind they normally have. Nor
        did he know why this one didn't have what the other ones have. In
        fact there were quite a few additional things about the machine absent
        from his data base.

I was surprised (chagrined?) that IBM changed disk controller's between the
6 and 8 MHz versions.  There is certainly no technical reason for this, as
the controller they use on the 6 MHz AT also works on 8 MHz machines.  They
also changed the keyboard between the models.  The 6 MHz version has a return
key you can see with the naked eye.  I guess they perceived this as being too
clonable, so they got rid of it on the 8 MHz version.  I don't know if the
XT-286 machine uses the same disk controller as the XT, 6 MHz AT, 8 MHz AT, or  
yet a fourth one.

Amoeba and MINIX are unrelated projects.  Amoeba is a research project in
building distributed operating systems.  It is in the same general league as
the V project at Stanford and the Mach project at CMU, but it differs from
both of these in many technical ways.  See my paper in the Dec. 85 Computing
Surveys for a brief discussion of Amoeba and references to published papers.

The ACK compiler presently has front ends for C, Pascal, BASIC, Modula 2, and
Occam, as well as a subset of ADA and various other languages.  It has back
ends for the 8080, 8088, Z80, Z8000, 6800, 68000, 6502, 32016, PDP-11, VAX,
but not the 370.  There is also a highly optimizing back end for the 68020
that was just finished.  Not all of this stuff is available yet.  Ask UniPress
or Transmediair for details.  The C to 8088 compiler supplied with MINIX is
not mediocre, at least in my opinion.  What I actually said at the BOF is
that the code quality is about 15% worse than the PC-IX compiler produces.
The binaries provided with MINIX were compiled with the PC-IX compiler, so if
you recompile anything with the MINIX compiler, it will be about 15% larger.
I have made a few quick comparisons of the MINIX compiler vs. some MS-DOS
compilers, and the MINIX compiler seems to be in the middle.  Some are better
and some are worse.  The main problem with the MINIX compiler is that it
doesn't use register variables very much.

MINIX supports 64K of program space and 64K of data space, for a total of 128K.
The stack register (SS) is completely useless because if you had a third
64K segment, how could you tell if a 16-bit pointer pointed to data space or
stack space?  Thus the data segment and stack segment share the same 64K
space.  If you cross compile using PC-IX or the C86 compiler, you can have
a maximum of 128K.  With the MINIX compiler the maximum is 64K, because I
didn't have time to figure out how to make the assembler produce separate
I & D space, although in theory it should be able to.  That may get fixed
eventually.

Minor bugs have turned up in doswrite and ar.  I'll post fixes later.  In
general, it is ok to post individual files that you have debugged.  In many
cases a diff listing will be more appropriate because most net traffic uses
dial up phone lines which may be free to you, but are not free to the
organizations footing the bills.  If you find 6 bugs in a 50 line file, it is
reasonable to post the whole corrected file.  If you find 1 bug in a 1000
line file, a diff listing is more appropriate.

Although I have said this several times before, the mail and news indicate
that a number of people haven't heard it.  MINIX is copyrighted.  It is not
public domain.  However, the copyright owner, P-H, has agreed that professors
can make copies for students, and that individuals can make a couple of copies
of the sources or binaries for noncommercial use.  Other copying requires
permission, just as all copies of Lotus, Turbo Pascal, etc. do.  Posting of
small MINIX source files is ok if you have made useful improvements or fixed 
bugs.

The system calls missing from h/callnr.h fall into two categories: those
call numbers that were unused in V7, and those calls that I didn't implement.
The latter include ptrace, mpx, phys, pkon, pkoff, nice, lock, and acct, as
I recall.  The MINIX numbering is the same as V7.  This information is not
secret, incidentally.  You can buy the V7 manual in a bookstore, as AT&T had
it published by Holt, Rinehart, and Winston (ISBN 0-03-061742-1).

The Atari port is being done by people at Philips in Holland.  I hesitate to
give their addresses because I would rather that they write code than answer
mail.  For people interested in porting MINIX to other 68000s (Amiga, Macintosh
and so on), I would suggest FIRST reading the book and code carefully, THEN
running to the terminal.  By that time the Atari port may be pretty far along
and you can use it as a base, instead of the 8088 version.

While on the subject of porting MINIX, a variety of people have sent me mail
inquiring about who is doing ports to what.  I would suggest that people who
have time and interest in doing ports post messages to this group announcing
themselves and perhaps saying a bit about their backgrounds and expertise.
The Amiga, Macintosh, 286, 386, 68020, and other groups can then try to divide
the work up by mail.  There is something to be said for having more than one
group working on each CPU, in case one of them has to give up for whatever
reason.  Once the 68000 specific stuff has been finished, ports to 68000 based
CPUs will mostly require writing drivers.  As a rule, you probably won't be
able to use the ROM BIOS for disk or terminal input, because they rarely
support interrupts.  It may be possible to use the ROM BIOS for terminal
output.  I didn't go that route on the PC because the BIOS is awful.  On a
color display the screen flickers as it scrolls because the guys who wrote the
BIOS didn't understand how to program the 6845 properly.  MINIX works fine
on either a mono or color display, with no flicker on either.  There is some
kind of problem with the EGA card.  The screen goes blank periodically and
then comes back in a peculiar way.  My best guess is that it has something to
do with driver thinking the card has 4K RAM when it actually has 256K.  When
an EGA owner gets MINIX, please see if you can figure out what is going on.
I don't think this fix will be difficult, but I don't know the EGA card well.

There has been a lot of discussion about XINU and GNU here.  Some people have
naively assumed they can put the GNU utilities on top of MINIX.  I wouldn't
count on it.  First of all, they are not likely to restrict themselves to the
V7 system calls (although all programmers should really do this to ensure
portability between 4.3 and System V).  Second, there is likely to be a
problem with program size.  MINIX only supports 64K + 64K as discussed above.
I don't remember if XINU has any utilities with it, but in any case, the
system calls supported by XINU are quite different from UNIX.  I don't expect
either of these systems to have much, if anything, that we can use.

Which brings us to the next topic.  As people get the diskettes and start
running the system, no doubt many people will discover that their favorite
program is missing.  Uucp, mail, news, and networking in general certainly
are conspicuously missing.  If anyone knows of public domain versions of
these or other programs that are missing, posting information about them
would be nice.  Even nicer would be tracking them down and modifying them
to run on MINIX, and then posting them.  Before starting to rewrite something
from scratch, I would suggest posting a query to see who else is doing what.
Needless to say, do not post any copyrighted material of any kind without
permission of the copyright owner.  Diff listings probably aren't legal either
since they contain the original lines and the changed lines, and you can't
publish the original lines.

If you find errors in the book or code, please report them.  If they are
significant, post them, but in any event, send me mail.  If your router
still uses source routing, send mail to:  ...!seismo!mcvax!vu44!minix.
Incidentally, seismo definitely knows about the nl domain.

Several people have suggested setting up subgroups such as comp.os.minix.amiga,
comp.os.minix.bugs, etc.  I think such discussions are premature.  Groups are
normally split only when the volume of traffic warrants it.  For the time 
being, just choose your subject line as carefully as possible.  If the subject
is "Amiga port" or "Bug in ar.c" people will be able to figure out whether they
are interested or not.

One area that is probably going to be chaos is what happens when dozens of
people start making incompatible changes to the code.  One thing that would
help a little is to use the net to find guinea pigs to test your changes before
making them widely known.  This may improve quality a little, but I can't see
any reasonable way of co-ordinating things.  Maybe if we are really lucky,
some changes will become so popular that everyone adopts them, and others will
vanish from lack of interest.  One problem that particularly worries me is this.
At present there is really only one version of the code.  Dynamically it 
figures out if it is has a color or mono machine, an IBM or Olivetti keyboard,
an 8088 or a 80286 CPU, a 360K or a 1.2M diskette, etc.  If someone discovers
problems on the XYZ clone and puts in special code to get around it, that
code may not work on "normal" machines, so we then get two versions.  If it
is possible and not too difficult, it is much better to dynamically determine
that the current machine is different, and set some flag.  For example, in the 
file kernel/glo.h there are now declarations:
int olivetti;
int pc_at;
which are set to TRUE or FALSE (1 and 0, respectively) depending on whether
the machine has an Olivetti style keyboard or an 80286 CPU.  If the EGA board
turns out to require some nonstandard treatment, it probably would be a good
idea to dynamically discover that an EGA board is present during system
initialization (in this case in kernel/tty.c), and add a flag to kernel/glo.h
that would be set to TRUE for EGA boards.  If there is no way to dynamically
determine that you are faced with an EGA board or a Southern Analog disk
controller or whatever, at least #ifdef the special code in a consistent way.

One small request on my part.  I would appreciate it if people changing the
code would stick to the programming style of the file they are changing in
terms of layout, indentation, where the curly braces go, etc.  Please do this
even if your normal style is different.  It is much nicer for subsequent
readers if the whole file indents 2 spaces for the body of a function, rather
than having all of it indent 2 spaces except the 10 lines you added, which
use 1 tab stop or some other convention.  I mention this topic because the
layout of the code I wrote is reasonably uniform in terms of spacing, placement
and style of comments, etc., and it would be nice to keep it that way.

Andy Tanenbaum (mi...@cs.vu.nl)

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!botter!ast
From: a...@botter.cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Comments on recent news
Message-ID: <1050@botter.cs.vu.nl>
Date: Mon, 2-Feb-87 18:14:45 EST
Article-I.D.: botter.1050
Posted: Mon Feb  2 18:14:45 1987
Date-Received: Sat, 7-Feb-87 04:34:49 EST
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 84

Here are some more comments on today's news.

It is a pity that MINIX is not POSIX.  POSIX did not exist 5 years ago.
Maybe MINIX will evolve in that direction, although that may be a lot of work.

MINIX definitely understands that hard disks have partitions.  If you want
to have a drive containing both MINIX and MS-DOS partitions, that is no
problem at all.  You just put a command in /etc/rc such as
  /etc/mount /dev/hd2 /usr
to mount partition 2 (for example) on /usr when MINIX boots.   (Of course you
have to mkfs a file system there first, as described in doc/READ_ME.)

Contrary to what was posted today, you CAN remake MINIX from the standard
distribution.  The full sources of MINIX and the binary of the C compiler
are supplied.  You don't need the C compiler sources to recompile the
operating system.  Makefiles to do the recompilation are also supplied.
The whole business is discussed ad nauseum in Appendix D of the book.

Only a couple of programs use separate I & D space.  If you modify one of
these, such as the editor, you have to recompile that program with PC-IX
or an MS-DOS compiler, preferable Computer Innovations C86.    This compiler
is desirable because there are problems converting from MS-DOS .EXE format
to MINIX a.out format, and they have been solved for C86.  For other compilers
they have to be solved anew.  The main problem is that the .EXE file normally
does not contain the program text size, and we have to use a trick to get that
information into the .EXE header.  The trick is to force the first word of
the data space to be a relocatable symbol, so the program size can be derived
from the relocation information.

I talk to Mark Krieger of UniPress.  He agreed to packaging of the MINIX C
to 8088 compiler sources for about $100 to individuals.  One word of caution.
These "sources" consist of a bunch of C programs.  One of these, the front
end (/lib/cem) was produced by a compiler compiler, so it is not the "true"
source.  The compiler compiler in question, LLGEN is a large, complicated
program itself not suited for the PC, but fine on VAXes, SUNs, etc.  LLGEN
produces recursive descent compilers, so the C output is vastly more
readable than YACC output.  If you want the compiler sources to port MINIX
to some other machine, you are probably going to need the full Amsterdam
Compiler Kit, or at least the relevant back end already made.  The $100
source package is fine, however, if you just want to run the compiler on
MS-DOS or some other computer to cross compile to the 8088.  ACK is something
like 6 MB of code and requires at least 20 or 30 MB of scratch space.  It
is really beyond PC class machines, except maybe a 386.  Mark's login is msk,
not mark.

I saw a public domain version of yacc posted to comp.sources.unix today by
Mark Colburn.  It may be of interest to MINIX users.  If anyone plans to 
convert it to V7, please post your plans to avoid duplicate effort.

There has been some discussion again about MINIX vs XINU in terms of size.
MINIX consists of a message passing kernel that runs in "kernel mode"
(or would, if the PC had one).  It also has a file system and memory manager
that run in user mode, along with the utilities.  If you want a very small
bare bones system to "compete" with XINU, just use the MINIX kernel.  All
you need is the code on pages 434-478 of the book (2200 lines, which
includes the assembly code interrupt handlers, etc).  You might also want
some of the drivers listed on subsequent pages, but the first 2200 lines is
sufficient to give you a working message passing system.  The remaining
10,000 lines in the book contains drivers, the memory manager program, and
the file system.  A course on microprocessors could easily restrict itself
to the 2200 line message passing system.  As distributed, user processes
can only send messages to the file system and memory manager, but if you
want a general purpose message passing system, just remove lines 1986-1988
(easy to remember!).

Let me try to reconcile what I said about copying and the copyright notice
in the book that was posted to this group.  At my university, if I collect
a bunch of journal articles that I want reproduced for a course, the 
university repro shop won't do it, claiming that we are violating copyright
law.  The notice in the book is intended to eliminate analogous problems
with professors who want to produce 100 copies of the sources for students.
That is legal and perfectly ok.  With private individuals P-H and I are
politely requesting people to restrict themselves to making a couple of
copies.    This policy is somewhat analogous to AT&T's policy of giving
universities a special deal because universities have a special and important
role in society.  If 4 people each chip in $20 to buy a copy of MINIX from
P-H, that can't be a hardship for many people, but it does generate some
revenue while trying to keep the "open" character of the whole project.  I
suppose this is a funny compromise, but we are willing to take the chance.
Please don't abuse it (and please--no more clogging the news group with
discussions about this subject.  If you have a specific question to which
you want a specific answer, send me mail.)

Andy Tanenbaum (mi...@cs.vu.nl)

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/