Beginning Work [djo11]

[Dan Odom]

Francois-Rene Rideau Said:

> Well, an object's class is its message handler, isn't it ?

I don't understand what you mean by that.  If you mean that a message
handler will be built in to every class, yes, I think that's the way
to go.

> But what kind of message will the kernel transmit ?

There could be a finite number of messages, like in POSIX.  Have an
integer code for each message, and pass that code.

>> Kind of like:   if (MsgHandler.ismsg ());  // Check to see if msg. is waiting.
> >                 switch (MsgHandler.message)
> >                   // etc...
> uh ?

Know any C++?  MsgHandler.ismsg () calls a function that, presumably,
checks to see if a message is waiting.  MsgHandler.message is a
variable containing the integer code for the variable.

A switch is a bad way to do it, but hey, I was in a hurry :-).

> >> P.S: One for the compiler designer.
> > 
> > Woah!  SINGULAR??!!  Am I the only one interested in the compiler????
> > Geez, I sure hope not.
> >
> > But if I must work alone, I must work alone.  Oh, well.
> > 
> Hey, he was talking about ME, not YOU ! :-)
> More seriously, we're at least two about the compiler issue (I'm preparing
> some post next)

OK.  I assumed he was referring to my statement that it would be hard
to start writing device drivers without a compiler.

We should probably communicate in email and at least start on stuff
like printf ().  When we get the kernel API, the REAL work can begin
(including the writing of the compiler itself).

>Well, I think Dennis should publish his pretty listing requirements; of course
> we can begin coding; BUT let's not forget (1) not to use C/C++ unportable
> hacks (i.e. pointer/integer typecasting, strange unions, etc); (2) let's be
> ready to conform our programs to a new language and/or style to appear; (3)
> let's include at lot of comments, so that anyone in the group can understand
> one another's production;

Especially #3.  The others are minor; because we're writing our own
compiler, we choose what will work on this system and what won't.

> > How's this:  Decide what language we'll use.  I'm in favor of C++, but
> > if you all want something else we'll use something else.  Give me the
> >  name of the language and I'll hammer out an initial spec for the RTL.
> What about Objective C ?

Objective C is fine with me (<-- It Rhymes!).  Didn't Jobs do NExTStep
in OC?

> What about these languages Gary talked about ?

No offense intended to Gary, but I don't know ANYONE who uses any of
those languages.  We want people to be able to use the OS, right?

> What about building our own HLL ?

We could, but it would take forever.

I am still in favor of splitting off in to small subgroups to work on
this thing.  Let the kernel people get the kernel spec out, and then
the rest of us will begin to work on the rest of it (the DD people on
the DDK and DD API, the compiler people on the library API, etc.).

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net