Path: utzoo!attcan!uunet!ogicse!uwm.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!usenet.INS.CWRU.Edu!bammi From: bammi@curie.ces.CWRU.Edu (Jwahar R. Bammi) Newsgroups: comp.os.minix Subject: Re: A real operating system ? Message-ID: Date: 1 Mar 90 19:26:15 GMT References: <1383@Terra.cc.brunel.ac.uk> Sender: news@usenet.ins.cwru.edu Organization: Case Western Reserve University Lines: 23 In-reply-to: eesrajm@cc.brunel.ac.uk's message of 28 Feb 90 20:19:59 GMT In article <1383@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: both MINIX-PC and MINIX-ST, and I regard the ST as superior because porting public-domain UNIX programs to it is pretty simple. No restrictions on length of variables or memory usage. The only real problem is 16-bit ints, but gcc removes this restriction. i must say i agree 100% with andy. in my opinion, minix-pc is a *toy* mainly because of the 64k segments. unfortunately, this also also effects how code gets written for minix in general. witness the definition of NULL, size_t (this is a worse than NULL) etc in the 1.5 header files. its even deeper than that: using zero for null pointers all over the place (even if NULL is used), the ACK C compiler for the St thinks that the typeof( sizeof ) is unsigned 16 bit int. Also, all the silly segment things all over the design of the kernel (note i am not complaining about clicks). i hope with the refree system we see the weeding out such system dependent code. -- -- bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi