RE: [colorforth] To kernel, or not to kernel

[John Drake <jmdrake_98@xxxxxxxxx>]

--- Frédéric_DUBOIS <frederic.dubois@xxxxxxxxxxxxx>
wrote:
> 
> 
> > -----Message d'origine-----
> > De : Arthur W. Green [mailto:goshawk@xxxxxxxxx]
> > Envoyé : jeu. 11 mars 2004 20:51
> > À : colorforth@xxxxxxxxxxxxxxxxxx
> > Objet : Re: [colorforth] To kernel, or not to
> kernel
> > 
> > 
> > Frédéric DUBOIS <frederic.dubois@xxxxxxxxxxxxx>
> wrote...
> > 
> > >I think it is the role of the kernel to hold the
> definitions  common to
> your
> > >apps. Then it can harbor the utility apps you
> want at your fingertips,
> too.
> > >
> > I'd rather see the kernel harbor just enough code
> to bring up 
> > the virtual machineForth, and nothing else. With
> all other code as
> "high-level"
> > source, including colorForth itself, not only
> would colorForth be far
> > more versatile (and better documented than it is),
> it would 
> > be far easier
> > to move code to any platform just by
> reimplementing the 
> > hardware abstraction.
> > 
> 
> It depend on the context; if we're talking about a
> kernel to be distributed
> to others, I agree with you. If we're talking about
> _your_ kernel you use at
> home, orthogonality or minimalism is less important
> and you'll certainly
> prefer a custom one.
> 
> 	Amicalement,
> 	Frédéric

I disagree.  I want _my_ kernel as small as 
possible.  But perhaps you are using the
word "kernel" differently than I am.  For me the
"kernel" of the OS is the part that's not easily
changed.  In ColorForth the kernel, for now,
is the part written in assembler language.  
Programs do NOT have to be in the kernel to be
available at boot up.  Most operating systems 
include some type of "startup script".  For 
instance MS-DOS has "autoexec.bat".  In 
ColorForth screen 18 is loaded at startup.  
Screen 18 in turn loads other screen making 
whatever apps you want available.  For 
instance screen 18 load the "icons" app 
which is available at boot up. 

One thing I dislike about ETH Oberon is that
ETH has put far too much stuff in the kernel.
For instance string processing is in the kernel.
That wouldn't be so bad except that strings
depends on module "dates".  (That in itself
was a bad design decision.  I should be able
to use the string module without loading the
date module.  But they put date-to-string
conversion in module "Strings".  That should
be in module "dates".)  What really ticks me
off about this is that module "dates" was
implemented badly.  Sure I can write my own
"dates" module but I had the fact that the
original "dates" module is hanging around 
in memory no good reason.  (Oberon relies 
almost completely "dynamic loaded modules).

Anyway, enough ranting.  The kernel needs
to have just enough to barely get ColorForth
up and running.  Have the "apps that you want
at your fingertips" written in ColorForth
and loaded from screen 18.

Regards,

John M. Drake
for 

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you?re looking for faster
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com