Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!mimsy!jds
From: jds@mimsy.UUCP (James da Silva)
Newsgroups: comp.os.minix
Subject: Re: PC Minix/64KB limit
Message-ID: <15957@mimsy.UUCP>
Date: 15 Feb 89 17:53:39 GMT
References: <415@lzaz.ATT.COM> <2485@sun.soe.clarkson.edu>
Reply-To: jds@mimsy.umd.edu (James da Silva)
Organization: University of Maryland, Department of Computer Science
Lines: 77

In article <2485@sun.soe.clarkson.edu> jk0@sun.soe!clutx.clarkson.edu.UUCP
writes:
>	Who cares about swapping on the PC?  I mean it would be neat, but it
>would be SLOW (even ast said that the original had swapping but he took it out
>because it was ungoodly slow).

I believe his original version swapped to floppies!  Swapping to a decent
hard disk would not be that painful.  It would be slow, but not SLOW.

>From article <415@lzaz.ATT.COM>, by hcj@lzaz.ATT.COM (HC Johnson):
>> Ultimately, the next unsupported port of MINIX/pc will be to a PC with more
>> memory and use the ATARI version as the porting base.  I would suspect
>> that AST may shed a small tear, tho, if this were done.
>
>	Why should he shed a tear?  Minix would be much more useful if
>applications could be >64k.  More usefulness means even more users!!  More
>users means (more money) more applications!!

I'm sure that the marketing folk at Prentice Hall would agree with you, but
I don't know that Dr. "Small is Beautiful" Tanenbaum would.  Keeping the
process space limited to 64k each for Instructions and Data allowed for a
very clean design.

>	Actually, I think the point of Minix has changed.  It used to be
>a teaching OS, but it's fastly turning into a real OS (as evidenced with
>version 1.3 which is "self-supporting").

Eh?  Version 1.1 was "self-supporting", if by that you mean that it could
serve as its own development environment.  Still, I agree with you that
Minix is now perceived as much more than just a teaching OS.

>	I'm no engineer, but can't the PC address 1 meg?

Yes.

>Would it be difficult to change Minix to use this much space?

Minix does use all the memory in the machine.  I presume you mean allowing
a user program to access more than one code or data segment.  It would be
messy.  Applications that use multiple segments under DOS are relocated at
loading time, and are henceforth nailed down in memory.  This makes it
difficult to implement the Unix fork() system call.

Of course, the ST people had the same problem, and their solution could be
used on the PC as well.  And it probably will be done by someone.  Here's a
possible evolutionary path for Minix:


PC Minix (small model) --> 286 Minix --> 386 Minix --> VM Minix (paging)
	\						(386, 680x0 w/MMU)
	 \
	  v
	  ST Minix (fork hack) --> Applications PC Minix ("large" model)

You take the low road, I'll take the high road... :-) :-) ;^}

> Since it isn't Messy-Dos,could it address 1 meg without those funny
> little LIM boards?

DOS can address 1 meg without LIM boards, but IBM reserved the upper 384k
for the ROM BIOS (and BASIC) and for use by expansion boards; for example,
a CGA board which uses RAM starting at 0xB8000 for the screen.  DOS
applications can access this RAM directly.  The 640k limitation is for
general-purpose system RAM in the machine; it's not an addressing
limitation.

Since this is a limitation of the PC design, not of DOS, Minix must live
with it as well.

>--
>Jason Coughlin 
>( jk0@clutx.clarkson.edu , jk0@clutx )

Jaime
...........................................................................
: domain: jds@mimsy.umd.edu				     James da Silva
: path:   uunet!mimsy!jds