Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!lib!thesis1.med.uth.tmc.edu From: dfenyes@thesis1.med.uth.tmc.edu (David Fenyes) Newsgroups: comp.os.coherent Subject: Re: Coherent vs. MINIX Message-ID: <5125@lib.tmc.edu> Date: 17 Jun 91 21:55:39 GMT References: <10834@idunno.Princeton.EDU> Sender: usenet@lib.tmc.edu Distribution: comp Organization: University of Texas Medical School at Houston Lines: 32 Nntp-Posting-Host: thesis1.med.uth.tmc.edu In article <10834@idunno.Princeton.EDU> rlwald@phoenix.Princeton.EDU (Robert L. Wald) writes: > >is there *anything* >that Coherent has that Minix doesn't? Is it supposed to be >more reliable? Coherent has more tools, and a C compiler that handles larger files and produces smaller code than that available for <=286 Minix. At least I've compiled code on coherent that was supposed to be too much for ACK C & asld. It has a debugger. It also has quite good telephone support, in addition to the MINIX software base, which is trivial to port in most instances. Coherent also has "loadable" device drivers that don't require recompiling the kernel. > The main problem is that Minix will support large model, and Coherent >won't until next year. I don't understand this, frankly. Large >model works on 8086's, let alone 80286's, so why can't coherent support >it? Is it because of a lack of real memory protection in an >80286? Then why does XENIX work? The "Large Model" you speak of is the Microsoft term for multiple <64K code and data segments. XENIX uses this, but can't run software with large arrays or routines (Routines that large may not exist outside of monster fortran code). It takes a lot of acrobatics to implement this, and the result is slow. Minix offers nothing of the sort. 386 addressing is not subject to 64K segment size, so processes may be arbitrarily large with no special code. This is what 386 minix is, and what 386 coherent will be. David Fenyes dfenyes@thesis1.med.uth.tmc.edu University of Texas Medical School Houston, Texas