Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!udel!mmdf
From: V61%DHDURZ1.BITNET@cunyvm.cuny.edu (Ronald Lamprecht)
Newsgroups: comp.os.minix
Subject: Future of Minix
Message-ID: <19654@louie.udel.EDU>
Date: 13 Jul 89 19:21:35 GMT
Sender: mmdf@udel.EDU
Lines: 49

A few weeks ago I definitely decided that Minix will be my main future OS that
I will port to every computer that I will own. The main reason is the fact that
if I detect a bug I don't have to wait half a year for the next release of
the software but can fix the bug myself (see my Flex & make post.) or ask
the author via email. I'm quite sure that Minix will not only have a future
as an educational OS but also as a serious OS because the abilities will
increase and with all the bug reports it will be one of the best debugged
systems in future.

I hope that we result in a common version for all computers as Andy announced,
but the most urgent topic to reach this aim is to define an offical set of
macros to include the different parts of sources by conditionals. ATARI_ST or PC
for example should only be used for computer specific hardware dependent code.
Code that depends on the processor family but is common to several computers
(ST,Amiga,...) should be included with another macro(one for the family, one
for every processor); code like the shadow code does neither depend on the
68000 processor nor on the ST and should therefor be included with a different
macro and not be called stshadow but simply shadow,...
Furthermore processor and especially computer device dependend stuff shouldn't
be spread over all files, but collected in a few specific modules (bad examples:
see kernel/clock.c,...).

The next important task would be to develop a new compiler, that could be
spread as public domain and is appropriated for all Minix versions.
I decided to write a compiler that supports the 680x0 with PIC (position
independent code) and PID (position independent data). I checked that this can
be done without increasing code size, a loss of performace or any other
restrictions ! As a result it would be easy to implement shared code, preload
code, shared libs and swapping on 680x0 machines. I didn't decide whether I
should take the GCC or the much smaller Sozobon source as a starting point.
I would be glad if other Minix fans would help me and especially if some
80x86 owners would join this venture (How about that Bruce -- you wrote once
that you are missing a 32 bit compiler for the 80386)

Another idea of mine is to introduce debugging stuff into all library modules.
This stuff should check all arguments and everything that is possible and
print appropriated error messages and warnings. The additional code should
be included in #ifdef DEBUG -- #endif so that it is possible to generate
a fast run-time library and a debugging library version. THe reason I want
to introduce this stuff is that the most problems that occur in porting
sources to Minix are wrong arguments in library calls (besides compiler bugs).

Of course I have a lot of other fancy ideas, but I thinks that's enough for
today and I will need all my spare time within the next half year to realize
these features.

Bitnet:  V61@DHDURZ1                               Ronald Lamprecht
UUCP:    ...!unido!DHDURZ1.bitnet!V61              Theoretische Physik
ARPAnet: V61%DHDURZ1.BITNET@CUNYVM.CUNY.EDU       (Heidelberg, West Germany)