From dmarer@td2cad.intel.com Thu Dec  3 19:51:20 1992
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24651; Thu, 3 Dec 92 19:51:19 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Thu, 3 Dec 92 19:51:19 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Thu, 3 Dec 92 10:50:45 -0800
Received: by td2cad (5.57/10.0i); Thu, 3 Dec 92 10:53:42 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA02423; Thu, 3 Dec 92 10:58:50 PDT
Date: Thu, 3 Dec 92 10:58:50 PDT
Message-Id: <9212031858.AA02423@tdge15.intel.com>
To: dmarer@dmi.ens.fr, rideau@clipper
Subject: Re: PC BIOS functions in protected mode
Status: OR

    '
Fare,

	Howdy!  Thanx for the quick response - it's good to know that other
people out there have the same interest as me.  In fact, the next post after
mine is from someone who is developing almost the exact same idea as me for
their master's work.

	You had mentioned linux a couple of times in your reply - it's
something that sounds interesting, and I'd like to get more info about it.
Anyone you know of I could get in touch with?  It sounds like a worthwhile
adventure to volunteer my efforts towards also.  Natch, I still have plans
to develop my own system to learn more about OS's, but I also think that if
someone has already started, I'd like to pitch in any help I can!
 
>  Well, there are many books which have been written about the different chips
> on the PC motherboards and standard disk controller cards. You can't usually
> write any line of code after having read them, but if you ALSO disassemble your
> ROM and look how it does it, you shouldn't have too much problem (use sourcer or
> such).

	Hmmm...is this (sourcer?) a program available for doing those sorts of
things?  If so I'd be interested in that also...I sure don't fancy the trick
of writing my own if there's something out there already.


 
> |> 3.  What system independent things do I need to watch out for?....
>  Well, I thought you at intel shouldn't need to post a question about intel
> processors and chips. You should have all documentation and ingeneers at hand !
> But don't worry; all essential features are supported by the 386 (just don't use
> CPU cache control instructions; see any good book about the 486); you shouldn't
> have any problem (but speed) with a 386.

	Ooops, I should have made myself more clear.  I've read the docs on the
486 and 386 and know they support each other very well.  On a platform by
platform basis (I.E., from a Gateway 2000 386SX @16Mhz to a Zeos 486DX2 @33Mhz)
are there any differences I need to be aware of?  Are the hardware support
chips (standard 8253/8259 chips, PCI, local bus, whatever) compatible in such
a way that after the system has been initialzed, no special functionality is
needed?  It seems BIOS does a fine job of initializing the system, but once
initialized, do I need to care what platform I'm running on?  I'm pretty sure
the answer is no, but just checking.

>  I think the problems you will have won't be with the BIOS but with other add-on
> devices (sound card, etc) which need device drivers to run under DOS. You'll
> have to writee your own drivers !!!

	Yep, I figured that, and that's actually the exciting part of this
project.  You see, its intended to be an object-oriented OS, with heavy
emphasis on object sharing and dynamic object linking.  In addition, each
device driver is designed as its own object which is installed for applications
to use.  A list of all devices will exist somewhere, and if an application
needs, for example, a display device, it will search this list for all devices
which are descendants of the 'display' base class.  The 'display' base class
provides the virtual methods for writing to the display, and each descendant
(each video card supported) has an identical interface.  More specific objects
(for example, a display which supports real-time video) can be searched for,
allowing the application to specify as specific or as general a device as
it needs.  This same mechanism for using devices also controls multiple
application device contention (the device is remove from the list if it can
only support a limited number of simultaneous users) and supports multiple
devices of similar types (multiple display devices?) with ease.  It's a real
interesting concept, making writing device drivers accessible by the regular
programmer, not something limited to a wizard or guru.  Sound interesting?


>  At the time, I don't know at all what kind of OS you're trying to design, but
> I am very interested in anything new: it shouldn't look like DOS (of course not)
> and not even Unix: you'll never be able to compete with Unix in its own grounds.
> So don't try a C (or C-like language) based OS. Moreover, to use any language
> (if you're not going to be Unix or DOS compatible), you'll have to redesign at
> least part of the compiler (interpreter); that's what I'm currently undertaking
> myself.

	Initially it will be based on an object oriented assembler to do some
of the OS's kernel and device drivers.  This is the ONLY way to produce an
efficient (in space and speed) operating system, in my opinion.  I think this
is the reason why I'm so disgusted with OS/2 and Windows NT is because of the
sheer size of the operating system.  Initial Windows NT reports say 60MB of
hard drive space (with a 30MB permanent swap file) must be dedicated to the
operating system itself.  My GOAL for this project (and I don't know if it's
feasible or not) is to develop the kernel and basic hardware support (disk
access, com port access, etc) to fit on a single floppy, uncompressed. (1.44M)
I have a 100MB hard drive, and I can't afford to have an OS consume half of it!

	Eventually, it'll need a high-level language.  I'm thinking of
something closely related to C++, but it will be a while before I get to that
point.  The stuff that needs to be done in assembly (low level hardware access
and the kernel of the OS) will come first, and the rest will be done in some
common high level language (such as C++) for portability.  It's ALL going to
be object oriented though.

>  An OS is very difficult to design: there's not only basic i/o to redefine, but
> also all the standards for data transfer, which is the most important. Unix has
> to fight at every moment against the only (poor) 100% supported internal
> standard: ASCII caracters number 32 -> 126 !!

	That's something I haven't given much thought to, but will need to
resolve before I begin coding.  Maybe this is turning into just a feasibility
study...anyway, I'll have fun doing it!

>  You know, if you want to write an OS and don't have time to finish something
> interesting alone, you can help write existing OS like linux.

	Regardless of whether mine takes off or not, I'd like to help!  Please
direct me towards someone who can get me involved.  As you can tell, I've got
a lot of free time on my hands...

	Thanx again for your input!  Keep me posted on linux, and 'sourcer' (if
that's actually a program and not a term I'm unfamiliar with), and I'll keep
you posted on what's going on with my project.  Keep in touch!

				Dennis Marer
				dmarer@td2cad.intel.com


From dmarer@td2cad.intel.com Fri Dec  4 20:05:11 1992
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23281; Fri, 4 Dec 92 20:05:10 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 4 Dec 92 20:05:10 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Fri, 4 Dec 92 11:04:51 -0800
Received: by td2cad (5.57/10.0i); Fri, 4 Dec 92 11:07:45 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00630; Fri, 4 Dec 92 11:12:55 PDT
Date: Fri, 4 Dec 92 11:12:55 PDT
Message-Id: <9212041912.AA00630@tdge15.intel.com>
To: dmarer@dmi.ens.fr, rideau@clipper
Subject: OO Operating System
Status: OR

   '
Fare,

	Howdy!  No, I don't speak French, but I know the importance of the
accent.   I do speak a little German, but I don't think that helps us any...

>  I myself am trying to design a new OO (multi)^n-(tasking|threading)
> (parallel ?) language, so as the latter characteristic couldn't allow it
> to work under usual DOS or even Unix environment (can't be easily translated
> to C, though I should finally try by including volonteer call to run-time
> task-manager). That's why I thought about rewriting myself the OS to match
> with the demands of my language; would you mind if I took part in your project?
> I'd help you write routines but ask you insert OO-managing code.

	I would greatly appreciate your help!  I think a system desgned from
the ground up as object oriented can be much more powerful than an OO language
on top of a plain operating system.  I'm not familiar at all with parallel
languages, but am willing to learn.  I think it's something work giving serious
thought to before actually designing this OS.  Please contribute any other
ideas you have regarding this!

>> (stuff deleted about obejcts being device drivers, etc...)
>  That's what I have been waiting for for years, but couldn't find someone to
> help and too lazy to do myself. What I'd like to add, is the fact that
> executable code itself is a virtual class, with the 'execute' method, and
> thus disconnect LOGICAL objects from PHYSICAL ones (the compiler is meant to
> choose by itself the PHYSICAL representation of an object from your
> specifications, but you can still manipulate PHYSICAL object, directly or by 
> strengthening a logical object's specifications).

	Exactly!  There is no reason why the source code itself can't be
considered an object.  I think you've got some good ideas on what this system
can be made into. 

> I'd like to know what in what format the object will be stored. Could you
> send me the specs, and especially for memory allocation. My wish is keep it
> easy to change physically without changing logical use.

	Right now, it's only in the conceptual stages of design - so far I have
no specific details.  I'm starting from scratch, putting together a 'wish list'
of every feature I think needs to be included, plus getting other people's
input at to what features they think need to be included also.  This will be
used as initial specifications, then the design work will begin.

	I expect a somewhat traditional method of storing object information
could be used very effectively, but I'm still not sure on implementing multiple
inheritance.  I think I'll be able to explain more completely what I intend
as soon as I get my wish list done.  If you do me a large favor by compiling
the features you wish to see also, please send that my way and I'll combine
it with what I have so far (almost 1000 lines of text!).

>  Why not try a new language ? I currently trying to do one. Send me the
> specifications (at this time, mine are uncomplete and in french). I'd like
> to have your opinion on the syntax.

	I've thought about that...it's an intriguing idea!  Unfortunately, the
acceptance factor is also an important aspect when considering the overall
project.  C++ is fast becoming one of the most commonly used OO languages
and and is accepted as a 'standard' (pretty much).  By sticking with C++,
there is already software written for such an operating system.  I'm not
completely decided yet, but to appeal to the population (of computer people)
as a whole, I think a more popular language should be the base for the OS.
It's a good language, but probably not the best for all jobs.  Plus, it's
already been completely specified, so development time is saved there.

> I'd like to participate in the spec's (if you agree). Will you send me
> regularly your new production ?

	Absolutely!  This is quickly becoming a collaborative project.  I have
three or four people willing to help with specification and design now.  If we
all work together, I think we can do fantastic things!  This project is still
only in the conceptual design stages, NOTHING is concrete.  If you think it
should have particular capabilities or features, I would love to hear about
them.  Once everybody has put in their input, we can get together (well, not
literally since we are separated by large masses of water) and discuss which
features we'd like to incorporate.  Send me your wish list!

> Well, about sourcer, I can ftp it to you if you want to see it; but if you
> really want to use it massively, better by it (ads easy to find, I think).

	I'll look for it here or write my own simple disassembler...DEBUG works
pretty well for simple stuff, and I'd rather do this thing legally.

	Keep in touch!  I'm looking forward to your ideas.  Once I've put
together mine, I'll send them along.  Take care!

				Dennis




From dmarer@td2cad.intel.com Fri Dec 11 01:46:29 1992
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02479; Fri, 11 Dec 92 01:46:26 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 11 Dec 92 01:46:26 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Thu, 10 Dec 92 16:15:25 -0800
Received: by td2cad (5.57/10.0i); Thu, 10 Dec 92 16:18:15 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA02352; Thu, 10 Dec 92 16:23:37 PDT
Date: Thu, 10 Dec 92 16:23:37 PDT
Message-Id: <9212110023.AA02352@tdge15.intel.com>
To: M.J.Landzaat@fel.tno.nl, andreasa@dhhalden.no, andrew@rentec.com,
        ast@cs.vu.nl, ath@linkoping.trab.se, cks@hawkwind.utcs.toronto.edu,
        danodom@matt.ksu.ksu.edu, dmarer@sc9.intel.com,
        dmarer@td2cad.intel.com, dneedham@oucsace.cs.ohiou.edu,
        dpn2@po.CWRU.Edu, dspascha@eos.ncsu.edu, duzan@udel.edu,
        eanders+@cmu.edu, eric@cs.sfu.ca, eugene@nas.nasa.gov,
        geyer@inf.ufrgs.br, haydedr@wkuvx1.bitnet, heimlich@watson.ibm.com,
        huny@cco.caltech.edu, jasonp@primerd.prime.com,
        jliukkon@cc.helinski.fi, joe@erix.ericsson.se, jsl@zeus.Jpl.Nasa.Gov,
        jz1j@andrew.cmu.edu, keithf@mcs.kent.edu, kthanasi@cs.rochester.edu,
        lowega@nextwork.rose-hulman.edu, ludwig@sage.cc.purdue.edu,
        maynard@selway.umt.edu, mchst12@pitt.edu, mckeeveb@sfu.ca,
        mik@hpbbn.bbn.hp.com, mmorg@ruf.rice.edu, moncrg@rpi.edu,
        mueller@sc.ZIB-Berlin.DE, nevries@cc.ruu.nl, newlin@ecn.purdue.edu,
        paik@mlo.dec.com, peter@ficc.ferranti.com, potter@watson.ibm.com,
        rideau@clipper, roberts@brahms.amd.com, sal8@po.cwru.edu,
        spitzak@Eng.Sun.COM, steve@game.gsfc.nasa.gov,
        thssoxo@iitmax.iit.edu, tih@barsoom.nhh.no, trs@doc.imperial.ac.uk,
        verber@parc.xerox.com, winikoff@cs.mu.OZ.AU
Subject: Your dream operating system: a reality?
Status: OR

Greetings!

    My name is Dennis Marer, and I'm writing this message as an invitation to
join in a project which could change the way we use our personal computers.
Nearly fifty (yes, 50) or so of you recently expressed interest in posts I made
regarding a 'dream operating system', and your suggestions have helped me to
formulate a plan to bring this dream into reality.  It's an adventurous project
at the very least, but one I promise will be worthwhile and rewarding to
participate in.  As a side note, this project is in no way connected with Intel
or any other commercial interests, and is being undertaken in my own time.

    We're now several years into the second decade of personal computing, and
we seem to be plagued with two recurring problems which desperately need
solving.  First, many of us (with IBM PC's) are still using the original tool
which helped bring the personal computer to where it is now, MS-DOS.  While it
has served its purpose well, I believe its time to put this old friend to rest
and find a better way to accomplish our tasks.  There are some new contenders
which are able to take advantage of our more advanced machines, but this is
where the second problem can be discovered.

    Over the past 10 or so years, the capabilities of our little silicon
boxes have grown to one time unimaginable heights.  Along with the growth in
IC technology has come faster and cheaper memories, as well as larger and
more compact mass storage devices.  Computers of yesterday were restricted to
almost ridiculously small memory spaces and usually only floppy disks to hold
their precious data.  Today we have access to machines with many hundred
times more memory space and well over a thousand times more mass storage.

    Along with these changes, the applications we're running have also grown
proportionally in size.  As new features are added, more demands are placed
on our machines with respect to memory and storage space.  In addition, the
operating systems which support these applications have become more complex
to handle these advanced needs.  Of the options available today, all place
extremely high demands on a system's resources, leaving applications only
a small amount of room to work with.  Though many times more powerful than
the early ancestors of the personal computer, it feels as though our machines
today are nearly as restricted.


------------------------------ A brief history -------------------------------

    Many months ago, I began researching the 386 and 486 CPUs found in many
of our personal computers today, and discovered some startling facts: for
compatibility with MS-DOS, both are being operated in their most restrictive
mode.  My system cannot directly access memory above 1 megabyte, any sort of
multi-tasking is crude and slow, and virtual memory is a concept not easily
implemented.  These three items are what the 386+ architecture was designed
to handle best, leading me to search for a better solution.

    So far I've come up with three options.  First, I could use OS/2 or the
forthcoming Windows NT to finally take advantage of my system's protected
mode.  Unfortunately, since both of these require a huge amount of hard drive
space and 8MB of memory to run nicely, I'd most likely have to upgrade my
system.  Unix-like operating systems are now available for the 386+ platform
and can be used with X Windows as an accepted multi-user environment, though
once again at a cost.  I can safely say that at least 99% of all personal
computer users will never need multi-user capabilities, which makes such
features and the resources consumed unnecessary.  Rather than pay this
expensive price for full access to my system, I've decided the second option,
waiting to see what else comes along, may be the more wise choice.

    The third option, of course, would have been to develop a new operating
system on my own.  I bounced this idea off a few people, and all seemed very
interested in the prospect of an operating system which allows full access to
the personal computers of today without consuming too many resources itself.
I began writing the initial specifications for what I believed to be the
operating system of the 90's, and started my research.

    In an effort to gather information about bypassing BIOS in protected
mode, I posted a single message to a newsgroup and discovered something
important: I'm not the only one who is interested in such a beast.  Sighs
of relief that something is finally being done about this situation were
heard from across the globe.  Several other people had begun writing their
own operating systems also, but without significant results due to the sheer
size of such an undertaking.

    Since then, I've been working on coordinating an effort that will give
us an operating system worthy of the machines it will be run on.  I'm
contacting each and every one of you with this message to invite you to
become part of the process.  By collaborating on the specification, design,
and implementation, we could quickly develop something which has potential
to breathe new life into our personal computers.  I feel this is just in
time as we step into yet another year of the second decade of the personal
computing era.


---------------------- What we're trying to accomplish -----------------------

    From the start, I've envisioned developing an operating system which is
simple yet flexible enough to meet the needs of the programmer.  The concepts
of object-oriented programming could be seamlessly integrated into the kernel
itself, allowing extensions to this system to be made simply and painlessly.
The full features of the advanced microprocessors found in our personal
computers would finally be opened up.  Initially I've decided on the name
'Moose' for 'Multi-tasking Object oriented Operating SystEm', though a better
name could probably be found in time for its initial release.

    This will be a fully functional operating system targeted for the
personal computer environment, including a full graphical user interface and
eventually a suite of applications.  It will be developed first for IBM PC
and compatibles with a 386 or better CPU, but other environments may follow
if the initial release is received well.  By making all of Moose as system
independent as possible, applications written for one platform could be
easily ported to another.  I believe Moose should be offered as freeware
from the start, though distributing source code for the kernel is probably
not a sound idea.  Source code for device drivers and such should be made
available to the public for free as examples.  Right now there is no way to
collect and distribute funds in a fair and impartial manner.

    From the ground up, Moose will be designed with the object oriented
paradigm in mind.  Operating system concepts, such as processes and device
drivers, could be handled by Moose as objects, each with its own methods and
attributes.  For example, all video display drivers could be descendants of
a 'display' object, giving applications a singular interface to a variety
of display devices.  More complicated display devices could implement a more
suitable interface, allowing applications which are optimized for such
devices to utilize extended features as well.

    The operating system could also implement the concept of a module, which
is a collection of related functions, data, and objects.  These items could
then be linked to and shared dynamically at run-time by other modules,
requiring only a single copy of each module in memory at one time.  Dynamic
linking also would allow new or better device drivers to replace the ones
provided with the Moose system without modifying the applications which use
them.  Objects would also be freely shareable among applications.

    Complete multi-tasking capabilities might allow an application to request
a guaranteed slice of the CPU, if available.  Precise event timing would also
be available to give Moose some real-time processing capabilities.  The
features we could implement in such a system have not yet been decided, but
by carefully choosing these features we can provide ourselves with a solid
base from which to proceed with the specification and development of the
Moose operating system.


---------------------------- Getting coordinated -----------------------------

    The most important aspect of this project will be the coordination of our
efforts.  Due to the physical distance separating all of us, the best method
of communication will be through electronic mail.  Because of the sometimes
unreliable delivery and delay using this method, a hierarchical structure can
be used to reduce the communication needs.  A single coordinator will
communicate directly with the managers of several workgroups, each being
responsible for the development for a portion of the system as a whole.
Each workgroup's manager is then responsible for passing information on to
each of that group's members, and the coordinator will be responsible for
making sure the pieces from each of the workgroups will fit together.

    Instead of having the chain of command trickle down from the top of the
hierarchy to the bottom, each group will be responsible for performing a
task.  The responsibility of the manager of each group will be to coordinate
the efforts to insure each of the pieces will fit together as expected.
By trickling information instead of command, I believe we'll be much more
productive in out efforts.

    To get things started, I've assumed the position of coordinator.  I'd
like to continue at this position at least until the workgroups are set up,
and if a more appropriate choice of coordinator is found I'd be willing to
let her or him take over from that point.  I am perfectly happy to continue
where I am indefinitely because I'm becoming personally attached to this
project.  I've got some strong opinions about how the final product should
turn out, so I'd like to stay right in the middle of things.

    At this time, I'm requesting that anybody with the time and interest to
become a workgroup manager please contact me immediately, as the sooner we
develop a system of communication the sooner things will progress.  To take
on such a position does not require you to be a computer guru, but rather all
that is necessary is dedication and good organization skills.  I've listed
below the different groups I've come up with so far, so please volunteer to
lead whichever ones interest you.  Suggestions are welcome for any other
groups which may be necessary, or possibly different distributions.

        The kernel      - Overall system operation, process/device handling
        File systems    - Disk access, file access, networked file systems
        User I/O        - Display and printers, mouse, keyboard, and so on
        General I/O     - Serial and parallel ports, SCSI devices, networks
        Tools           - Assembler/compiler development and porting, etc.

    Once you've all replied, I'll make a selection of group leaders based
mostly on overall qualifications and time issues.  Someone with only a small
amount of time and good knowledge of the subject is less likely to be chosen
than someone with abundant time and less knowledge.  I feel if your time is
limited, your efforts should be put directly towards the technical aspects
of this project instead of the managerial aspects.  Please don't be offended
by my choices of group leaders, as I am trying to make these decisions in as
professional manner as I am able  Everybody is equally important here.

    I'd like for everyone else to choose a couple areas you feel qualified
to lend your expertise towards.  Whether or not you can contribute only a
little or 99% of your time, if you only plan to contribute knowledge, design
ideas, or just to write as much code as possible, know that your efforts will
be directly responsible for making the Moose operating system a success.
Everyone has the opportunity to contribute and will be recognized equally
regardless of your qualifications, so I encourage you to join us in our
quest.  Now is also a good time to recruit friends and colleagues who are
interested in our pursuit.  What you will gain from your work here will be
intense experience and absolutely no pay. :-)


------------------------------ Work done so far ------------------------------

    For the past few weeks, I've been collecting ideas from the general net
population, and more are coming in every day.  I've distributed a general
survey to several newsgroups asking for input on a 'dream operating system',
and am in the process of compiling this information.  When complete, this
'wish list' will serve as a valuable tool in specifying what features we'd
like to implement in this project.  If you haven't seen this survey posted
and would like to participate, I strongly recommend contacting me as soon as
possible.

    On 12/21/92, I expect to be finished with compiling the results, and will
post back to the original newsgroups as well as sending these results on to
you.  In addition, by this date I expect to have compiled the first revision
of what will eventually become the initial specifications for the Moose
operating system, which will be sent to you also.

    Because the period between 12/21 and 12/31 might be used for vacation by
many people, it will give each of us a good chance to ponder the wondrous
possibilities and opportunities of our project.  I suggest we begin actively
communicating again soon after the start of the new year with fresh ideas in
mind and begin ironing out features and flaws of Moose within our workgroups.


--------------------------------- What now? ----------------------------------

    I've come up with a few issues which need to be decided within the next
few weeks.  Most importantly, you need to contact me and specify what sort
of involvement you'd like to have in this project!  All levels are acceptable
though you must actively participate to be a member of a workgroup.  We can't
afford to support dead wood for efficiency reasons, so your being active is
most important to our success.

    Naturally, we ought to start collection names for this operating system
of ours which I've dubbed as 'Moose'.  Hopefully we can collect a list of
possible names within the next few months and vote on the best choice.  I
just don't think 'Moose' sounds very, well...professional?  Let me know your
ideas there, but be sure not to make it sound like 'Unix'.

    Also, I think we should decide on a name for this group, and quick.  It
will give our effort more identity, and not just seem like we're a random
bunch of people.  By sounding like an actual business, we may be able to
get better recognition than a loose collaboration of programmers.  Please
send these as soon as possible so I can compile a list to be voted on.  The
one idea I had was 'TDM Collaborations', where 'TDM' comes from the following
poem by an author whose name I forget:

                    I really hate This Damn Machine,
                        I wish that they would sell it.
                    It never does quite what I want,
                        Only what I tell it.


------------------------- Becoming further acquainted ------------------------

    I'd like to get some detailed information on all of you to keep for my
records and to distribute to everyone involved with this effort.  Please send
me this information as soon as possible also so I can compile the results
and relay it back to everyone else.  Use a format similar to the following:

Name:           Dennis Marer

E-Mail:         dmarer@td2cad.intel.com

Snail mail:     P.O. Box 1006
                Los Gatos, CA 95031-1006
                U.S.A.

Education:      B.S. Computer Engineering
                University of the Pacific, Stockton, CA

Occupation:     Software Engineer at Intel Corporation, Santa Clara, CA, USA
                Development of software to assist in the production of IC's,
                CAD based applications, placement of test circuitry and
                alignment marks for mask generation.

Specialties:    Assembly language programming (I love it!)
                Object oriented software development
                Microprocessor/controller based system hardware design
                DSP hardware and software design for digital audio:
                    - Sampling and playback, esp. oversampling techniques
                    - Music synthesis using frequency modulation
                    - Effects processing
                Text parsing with error detection/recovery algorithms
                GUI based applications in X Windows and MS Windows
                Daydreaming and thinking about things which could be...

Experience:     Been working with computers since 1982, including the
                Atari 800, IBM PC's and compatibles, Unix systems, VAX/VMS.

                Co-op experience with Siemens AG, Erlangen, West Germany.
                Worked with code and project management tools for a large
                scale software project, plus designed a tool to verify
                source code file inclusions against MAKE files.

                Co-op experience with Intel, Santa Clara, CA, USA.  Developed
                software to model the effect of infrared light through thin-
                film layers on silicon substrates to extract film composition
                information from wavelength data.

                Permanent position with Intel (currently) since June.

Languages:      English, BASIC, Fortran, Pascal, C, C++, Forth, Mainsail,
                plus 80x86, 68000, 6502, and VAX assembly languages.

Publications:   No papers or books published, no patents held.

Interests:      Computer music and MIDI applications
                Piano, synthesizers, guitar, octave mandolin
                Techno pop, modern rock, industrial, Irish traditional music
                Poetry and similar writings

Other:          Organizing absurdly huge projects... :-)


---------------------------- What you need to do -----------------------------

Here is a quick review of what you need to do after reading this message:

    * Request from me the 'dream operating system' survey if you haven't
        already participated.  I'd like as much participation as possible!

    * Send me any other suggestions regarding operating systems in general
        and this project you may have.  Specific or general, anything helps.

    * Write me a message and let me know which workgroup you would like to
        be in charge of.  Pick more than one if your interests are divided,
        or create your own if you think it's necessary!

    * Write me and let me know which workgroups you'd like to work in.  Even
        if you're a workgroup manager, you should still be involved in other
        areas.  Specify 2 or 3 areas you're most interested in.

    * Send in your vote for the name of this operating system.  I'll collect
        these for a couple of months, so you've got time on this one...

    * Send in your vote for an overall group name.  This should be done as
        soon as possible so we can get started.  Logo ideas anyone?

    * Recruit friends and colleagues to support our effort.  It's really
        important we get a good number of people directly involved with this
        work.  Theoretically, our work will progress much faster with more
        help, though at some point we should draw the line.  Suggestions?

    * Fill out the information form on yourself.  In a few days, I'll compile
        this information for everyone who has responded and distribute it
        to each and every one of you.  (After you've responded, of course!)
        I'll keep this information updated and send you fresh copies every
        so often so we've all got the same mailing lists.

    Anything you send me will be answered (or at least given a quick answer)
within 2 or 3 days at the most.  If you do not get a speedy reply, be sure
to send to original message again - it may have gotten lost.


What you can expect to receive in the near future:

    * This message, again and again and again until I finally get some
        response from you whether or not you want to participate!

    * 12/14/92, the first listing of interested parties and information
        about each member.  Feel free to start talking with each other!

    * 12/18/92, a ballot to cast your vote for our group name.  Please
        return this promptly so I can count the ballots!

    * 12/21/92, the results of the 'dream operating system' survey.

    * 12/21/92, an initial rough draft of the general Moose specifications.

    * 1/5/92, a New Year's welcome, plus the final decision on a group name.
        At this time, we'll really get started with specifications!


------------------------------------------------------------------------------

    Take care, and I hope to hear from you very soon!  All input accepted,
good and bad.  If there is something you don't like so far, let's change it!

                                Dennis Marer
                                Acting coordinator

                                dmarer@td2cad.intel.com


From dmarer@td2cad.intel.com Fri Dec 18 01:27:56 1992
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10301; Fri, 18 Dec 92 01:27:54 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 18 Dec 92 01:27:54 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Thu, 17 Dec 92 14:35:22 -0800
Received: by td2cad (5.57/10.0i); Thu, 17 Dec 92 14:38:19 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00695; Thu, 17 Dec 92 14:43:44 PDT
Date: Thu, 17 Dec 92 14:43:44 PDT
Message-Id: <9212172243.AA00695@tdge15.intel.com>
To: danodom@matt.ksu.ksu.edu, dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu,
        duzan@cis.udel.edu, eanders@cmu.edu, haydedr@wkuvx1.bitnet,
        jasonp@primerd.prime.com, mckeeveb@sfu.ca, mmorg@rice.edu,
        mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu, potter@watson.ibm.com,
        rideau@clipper, sal8@po.cwru.edu, winikoff@cs.mu.oz.au
Subject: Many Moose members mailing!
Status: OR

Greetings and welcome!

	Howdy!  Sorry about the long pause between messages...it's been very
busy (and exciting) around here!  So far, I've been sent info from about 15
people willing to work on Moose, and I think that's a comfortable size.  I've
included the full list at the end of this message, so get acquainted!

	As I expected, we've got a wide range of people to think up ideas,
which is great!  I was counting on the fact that none of us has exactly the
same kinds of experience.  Probably the most important factor is that none of
us has the same LEVEL of experience...it's my theory that if you put a group
of computer gurus together to write an operating system, only computer gurus
will be able to use it.  :-)  Even if you personally don't have the practical
or theoretical (I.E., school) experience that others might have, you're still
just as important to the success of this project.

	On a side note, I've been talking with Andy Tannenbaum (OS guru, has
written a couple of books and operating systems) about this project to get his
input on the feasibility of our undertaking.  He's been trying to convince me
it can't be done without several hundred man-years effort, but I still think
he's got the wrong approach.  He wrote Minix by himself, so between the 15 or
so of us we should be able to accomplish something also.  I thrive on projects
which are claimed to be 'impossible' because I find them much more interesting.
If you know something can be done, what's the point of doing it?

	I'm still wading through all the responses I've recieved from the
survey I posted, which has added up to several hundred pages!  I did not expect
such turnout, so it's taking a bit longer to compile the results than I had
originally anticipated.

	The first revision of the Moose general specifications is also being
compiled, and will be ready for your perusal next week.  These specs show how
I envision the system interacting as a whole, and I've tried to keep from
including specific features.  I'm seeking to capture the concept of this system
as a whole, and from there we can work out the details.  You'll all recieve
this when it's finished, and from there you can add any new suggestions you
come up with also.

	The next step is to divide us up into groups.  I think for the present,
we should all participate in developing the interface to the kernel.  It's such
an important portion of the system that we should all have a hand in shaping
how every other section (video, disk, I/O, etc) interface with it.  What I'm
looking for before we actually break into groups are SPECIFICS about what each
function does, the parameters it takes, and so on.  From there the kernel can
be implemented, as well as each sub-group having a place to work from.  Put
your thinking caps on and start thinking about what kind of interface you'd
like for the following:

	* Memory allocation - to allow allocation of memory (virtual? shared?)
		resizing of allocated blocks (is this portable?), etc.

	* Process communication - Windows uses DDE, Unix uses pipes and shared
		memory, how are we gonna do it?

	* Device management - If your application needs XXX device, how does
		it go about using this device?

	* Time management - Process scheduling and prioritizing, real time
		functions, etc.

	* Standards - Unicode character system?  (YES!)  File protection
		standards? (X.400?)  


	Just some stuff to chew on over the holidays...send me any ideas you've
got, and they'll be included!

	So what am I doing now?  Several suggestions have come up regarding
this project, the first of which was to actually start a real non-profit
organization.  It'll protect each of us in copyright situations, and I think
in general it's a good idea if this thing takes off.  I'll keep you posted as
the details work themselves out.

	We'll probably need a central place to store our work, ideally some
machine each of us can FTP to and leave stuff and retrieve stuff.  If any of
you know of such a system (mine is definitely OUT) please let me know.  Also,
it's been suggested to set up mailing lists at that system for easier contact
with all members, such as moose-general@system.whatever, or moose-kernel@...
This should ease communications.  Anybody have such access?

	Well, it's holiday season for most of us, so let's get in touch again
after January 10th or so.  This gives everyone time to get back into the swing
of things after New Years, plenty of time to put on that thinking cap and hash
out your wonderful ideas...take care, and keep in touch.  Again, if you have
any suggestions, problems, ideas, etc., let me know or send to the group as a
whole!  Hope to hear from you soon!

				Dennis


--------------------------------------------------------------------------------

Name:		Gary D. Duzan

E-Mail:		duzan@cis.udel.edu, duzan@dsh.org,
		Gary=Duzan%CSS%DHSSDSH@banyan.dsh.org

Snail Mail:	621 Shue Drive
		Todd Estates I
		Newark, DE  19713

Education:	B.S. Computer Science
		University of Delaware, Newark, DE

Occupation:	Network Administrator at Delaware State Hospital
		Managing a Banyan Vines PC network, a 386BSD mail/news
		UUCP/SMTP gateway, Gupta SQLBaser servers, and just
		about anything else computer related that needs to be
		done.

Specialities:	Keeping up with the latest in Operating Systems Research
		Griping about DOS (and any other brain damage)
		C Programming (General)
		Picking up new systems
		Helping others with projects
		Leaving personal projects half-done (though I always
		   finish things that need doing)

Experience:	Started with computers in 1981 (6th grade), including
		Apple IIs, Atari 8bits, VMS, DOS machines, Unix, and
		dabbling in any number of other systems.

		I worked a number of data entry and computer operator
		in high school and college through temporary agencies,
		which exposed me to a wide variety of systems.

		I also worked as a site assistant and senior student
		consultant during college. I unofficially helped
		manage a Sun network (since the sysadmin really didn't
		know anything about Unix) and was often consulted as
		a system guru.

		College projects included a study of Distributed
		Systems and the design of a Virtual File System
		for Minix.

		I've written C parsers and such in my spare time. My
		latest product is a utility to monitor the activity
		on a number of equivalent Sun workstations and suggest
		which to use when connecting from a terminal.

Languages:	English, BASIC, Pascal, C, C++, 6502, 65816, 8086,
		Lisp dialects

Publications:	None.

Interests:	Science Fiction/Fantasy Books and Television
		British Stuff
		Music by artists noone has heard of (mostly called NewAge,
		   though I dabble in Folk and Jazz)
		Choral Music (I've performed with groups in Carnegie Hall,
		   Finlandia Hall, Avery Fisher Hall (Lincoln Center),
		   and lots of other interesting places.)

Other:		Jumping blindly into huge projects. :-)

--------------------------------------------------------------------------------

			 ,
Name:           Francois-Rene Rideau (call me Fare)
		    '
E-Mail:		rideau@clipper.ens.fr

Snail mail:	6, rue Augustin Thierry
		75019 PARIS 
		FRANCE
		or
		(Ecole Normale Superieure)
		45 rue d'Ulm
		75230 PARIS CEDEX 05
		FRANCE

Education:	Student in Maths & C.S. at the ENS
Specialties:	Dreaming about new OO generic language OS and CPU
		Assembly language programming
Experience:	No professional experience.
		Fun with programming and unprotecting games.
Languages:	French,English,(Spanish),(Vietnamese?),
		BASIC, 6502 asm, 80x86 asm, C, Pascal, RPL, Forth, C++,
		(68000 asm) (any you want)
Publications:	humorous articles in (very) local papers
Interests:	Classical Music,
		Vietnam (me. to^i la` ngu+o+?i Vie^.t-Nam)
		Role-Playing games and making psychological SF scenarii
		books about the political Power (B de Jouvenel,Tocqueville,...)
		logic and (artificial or natural) intelligence
Other:          Participating absurdly huge projects...


--------------------------------------------------------------------------------

Name:           Steve Luzynski

EMail:          sal8@po.cwru.edu

SnailMail:      11904 Carlton Rd, #430D
                Cleveland, OH  44106

Education:      Ongoing....

Occupation:     Computer Engineering Student at Case Western Reserve 
                University. Summer employed at Harmon Electronics in Grain 
                Valley, MO doing software documentation and hardware 
                testing.

Specialities:   C++
                Graphics (can't draw em but I can program em)
                OS/2 - experience with object oriented GUIs

Experience:     First computer was an Apple //e. Wrote a full featured 
                telecommunticaions program and a idiotproof disk utility 
                program in assembly language for it.

                C and C++ on 80386 machines. Written graphics intensive 
                games and various 'make life easier' utilities.

                Assembly and PL/M microcontroller programming. Deciphered 
                10 years worth of multiauthored, zero commented code to 
                write the bible on the system it controlled.

Languages:      English, BASIC, Pascal, C, C++, 6502 assembly, 8039 
                microcontroller assembly.

Publications:   None.

Interests:      Computer everything, waterskiing, industrial music.

Current 
 projects:      Designing & implementing a play-by-email game for MSdos 
                systems in C++. Going to school. Learning to program OS/2 
                PM.


Groups:         Video, general stuff.


--------------------------------------------------------------------------------


Name:           John Newlin

E-Mail:         newlin@ecn.purdue.edu

Snail mail:     2550 Yeager Rd.  Apt. #4-5
		W. Lafayette, IN  47906
		U.S.A.

Education:      Senior in BSCEE program 
                Purdue University, W. Lafayette, IN

Occupation:     Student, dedicated to graduation in May with as little
		work as possible, and occupying my time in as many non-school
		related activities as possible.  In other words, enjoy my
		Senior year ;-)

Specialties:    Perl language programming (I love it!)
                Object oriented software development
                GUI based applications in Macintosh environment
		Software Engineering, structured analysis.
		Hey, I'm a student, I haven't had time to become
		a specialist ;-)

Experience:     Been working with computers since 1988, including the
                IBM PC's and compatibles, Unix systems, VAX/VMS, and Mac's.
                 
		 Coop experience with Thomson Consumer Electronics.
		 Worked on automated test equipment, and toyed with
		 an OO framework call Turbo Vision, for controlling
		 an IEEE-488 rack of equipment.

		 Intern with Motorola.  Wrote a client-server based
		 app with a UNIX server and a cluseter of Mac's as the
		 clients.  Of course this was through the high leve
		 interface to TCP-IP.


Languages:      English, BASIC, Fortran, Pascal, C, C++, 
                plus 80x86, 68000, 6809, Perl, sed, awk, Lisp.

Publications:   No papers or books published, no patents held.

Interests:      Biking, hiking, camping, hanging out with friends,
		wallyball, almost anything except country music,
		drinking large quantities of alcohol to induce
		a trance like state, and possibly induce a reversal
		of the esophageal muscles ;-)
		Going to class, occasionally.

Other:          sleep, when I am not wasting my life away ;-)
                Working on my political career as I am aspriting
		to become the President one day.


--------------------------------------------------------------------------------


Name:           Rob McKeever

E-Mail:         mckeeveb@sfu.ca
		rmckeeve@sfu.ca
		(either of the above ...@sfuvax.bitnet)

Snail mail:     Appt #201 - 5336 E. Hastings St.
                Burnaby, B.C. V5B 1R1
                Canada

Education:      Second year Computing Science student,
                Simon Fraser University

Occupation:     Programmer, McKeever's Software Wizardry, BC, Canada
		Developing PC-based Medical office management database systems

		Programmer, Operations & Tech. Support, Simon Fraser University
		Various odd jobs no one else wants...
		including some system security tasks, help system development
		etc.

Specialties:    UNIX-style environment development
                Macintosh (I'm ashaimed of it, really) development
                Object oriented software development
                GUI based applications in X Windows and Macintosh systems
                Daydreaming and thinking about things which could be...

Experience:     Been working with computers since 1983, including the
                PET 2001, Apple II series, IBM PC's, Macintoshes, UNIX

Languages:      English, BASIC, Fortran, C, C++,
                plus 80x86, 680x0, and 6502 assembly languages.

Publications:   No papers or books published, one patent pending

Interests:      Played Saxaphone until it was destroyed in a car accident
		Enjoy RPGs (D&D RoleMaster, etc.)
		Science Fiction novels (all sorts)
		Hacking Unix drivers, porting code (including OS's)

Other:          Organizing absurdly huge projects... :-)


--------------------------------------------------------------------------------


Name:           Dan Odom

E-Mail:         danodom@matt.ksu.ksu.edu

Snail mail:     P.O. Box 281
                Hays, KS 67601-0281
                U.S.A.

Education:      Given the fact that I feel degrees and formal education
                have nothing to do with you skill level, I am leaving
                this field blank.  I have known high school dropouts
                that could write a complete database app in C in under
                a month, and PhDs who thought that REXX was second only
                to PL/1 (geez).

Occupation:     Professional bum. :-)


Specialties:    8086 Assembly language programming (moderate skill)
                Object oriented software design
                Strong C/Unix background
                Designing software that engineers think is neat and not
                giving a damn about the 'general user'.

Experience:     Been working with computers since 1984, including the
                IBM PC's and many Unix systems (BSD-ish OSs preferred).
                Written about a zillion apps for myself.  Which
                one do you want to hear about?
                I basically just write software for myself.

Languages:      English, BASIC (mostly forgotten), Pascal (also mostly
                forgotten), C, C++, Forth (again, mostly forgotten), German
                (human language, moderate skill), 80x86 assembler, LISP.
                Learning 680x0 assembler.


Publications:   No papers or books published, no patents held.

Interests:      Computers, systems programming, Grateful Dead, telecom,
                Dead Kennedys, Jethro Tull, EE/CE, doing horribly
                perverted things in LISP and 80x86 ASM.

Other:          Other?  You mean there's something _besides_ computers
                and music? 


--------------------------------------------------------------------------------


Name -- David Paschal

email -- dspascha@eos.ncsu.edu (gone Sun Dec 13 until around Jan 3)

snail mail at NCSU:
David Paschal
NCSU Box 4021
Raleigh, NC 27607
(919) 821-7271

at home:
David Paschal
6025 Lansing Drive
Charlotte, NC 28270
(704) 364-2294

Education/occupation -- Graduate of the NC School of Science and Math (NCSSM)
Extensive computer programming experience, both independently and as "work
service" at NCSSM.
currently freshman at NC State University studying computer science

Specialties -- Intel 80x86 assembly language programming (I love it too!)  :-)
DOS "utilities" such as TSR's and related hacks.  Some more important programs
I've written include a utility that write protects a hard disk (loads from the
boot sector before DOS!), some network printing utilities (fix those %^&*
programs that don't flush the print queue!), an pretty decent subroutine library
for things like heap management, text-mode windowed video, INI configuration
file parsing, and DOS environment manager.  So far I have written two programs
with this new library -- a network login program and a software menu program
which can look for menu files on various file services on a network.

***Some of this library might be useful (with some porting to protected mode)
for your OS, especially the INI file parser.

Experience -- worked with computers since 1985 -- first a TRS-80, then IBM XT
clone, then 386 clone.  Programming experience both independently and as a
"work service" (required work study) student at NCSSM.

Languages -- mainly 80x86 assembly, but also some BASIC, C, C++, Pascal
Operating systems used -- DOS, Unix, VMS

Other interests -- cello, Deutsch.

--------------------------------------------------------------------------------


Name:           Eric Anderson
E-Mail:         eanders@cmu.edu, eanders@sura.net
Snail Mail:	10122 Renfrew Rd.
		Silver Spring, MD 20901-2049 USA.
Education:	Candidate for B.S. in Computer Science, Technical
		Writing, and a Masters in Math.
Occupation:	Primarily Student.  I also work at SURAnet supporting
		archie, writing network operations tools, and
		supporting the /usr/local there.  I also work some for
		User Services at CMU.
Specialties:	Object Oriented development
		Application level programs.
		GUI applications in X windows
		Playing with somewhat expensive machines.
Experience:	Been playning with computers since 1984-1985
		Went to Math Science Magnet Program in High School,
		Worked for NSWC, SURAnet, Sylvest, User Services at
		CMU doing various software development tasks.
		PS copy of my resume available from
		madhatter.ws.cc.cmu.edu:pub/eric/Resume.ps if you care.
		Played on everything from C64 to Sun Sparcstation
Languages:	English, BASIC, Pascal, C, C++, Forth, SML, Logo,
		Perl, Scheme, Prolog, 6502 assembler
		Unix, MS-DOS, VMS, Apple Macintoshes
Publications:	Not yet, hopefully eventually
Interests:	Learning to write better, some poetry, listening to
		all sorts of music, playing in the CMU band, Ballroom
		and other types of dancing, learning more stuff.
		PRIMARILY: Graduating in 4 years.


--------------------------------------------------------------------------------


Name:           Matt Morgan

E-Mail:         mmorg@rice.edu

Snail mail:     Wiess College
                  P.O. Box 2011
                Houston, TX 77252
                U.S.A.

Education:      Currently enrolled at Rice University (in Houston).

Occupation:     student

Specialties:    Object-oriented programming
		Machine learning
		System administration

Experience:     Worked with computers for most of my lifetime: everything
		from the Commodore 64 to the IBM ES/9000, and many things
		in between.

		(current) Student UNIX Programmer at Rice University.
		(Essentially system administration work.)

Languages:      ML, C++, C, Scheme, Forth, BASIC, and 6502 and SPARC
                assembly languages.

Publications:   One small article plus program listing for a game to play
		Othello, in Compute!, Gazette Edition, December 1991.

Interests:      Computer music and MIDI applications
                Piano/organ/synthesizer playing
		Volleyball, racquetball

--------------------------------------------------------------------------------


Name:		Peter Mueller

E-Mail:		mueller@sc.ZIB-Berlin.DE
		pm@opal.cs-tu-berlin.de

Snail Mail:	Detmolder Str. 15
		1000 Berlin 31
		Germany

Education:	Currently undergraduate of computer
		science at Technical University of
		Berlin; (well, I hope to receive my 
		graduate in May 1993 ...)

Occupation:	Currently jobbing at Konrad-Zuse Center
		for Technical Information located in
		Berlin (ZIB). I think it's too arrogant
		to declare this as a "real" occupation.

Specialties:	Ouh! Specialties? Don't you get them
		in the "real" world?
		Thinking about how one could make things
		object oriented
		Willing to learn as much as possible
		Willing to be active as much as possible
		 
Experience:	Compared with the most of you not much,
		let me see:
		IBM PC and compatibles
		Unix Systems (Especially Sun 
		workstations)
		(If it is of interest: I've programmed
		a tetris like game for MS Windows. That's my 
		"GUI Programming Experience". 
		BTW: That programming was horrible. Why
		do you have to write so much to let the
		blocks fall ...?)

Languages:	Broken English, hope it is well enough
		for the project
		C, C++, Pascal, old boy BASIC

Publications:	No papers, no books, no patents (but 
		stay tuned ...)

Interests:	Computer Music, MIDI applications
		especially composing with them,
		New Wave, Pop

--------------------------------------------------------------------------------


Name: Jason R. Pascucci
Email: jasonp@primerd.prime.com
SnailMail:  1 Universal St #2
            Framingham, MA 01701
            USA
Education: No degree. Various and random courses at various and
random Universities

Occupation: Software Engineer at ComputerVision, Framingham, MA, USA.
Support of PRIMOS OS, RiscOS, etc, etc. Conversion/Migration Consulting.
Lots and lots of other stuff.

Specialties: 50 Series Architecture (70's stuff)
             All the Normal and Slightly Silly Languages.
             Porting issues, Cross Platform Development
             High-level Design to Implementation
             Hacking.
             X internals, GUI's, etc.
             Lots of very random knowledge.

Experience: Random companies doing PC type stuff. Prime Computer/CV
for about 5 years, mostly 50 Series, about 3 years of Unix
internals. Etc, etc.

Languages: Way to many...and I get them confused sometimes.

--------------------------------------------------------------------------------


Name:          Ross Hayden

E-mail:        haydedr@wkuvx1.bitnet

Snail mail:    2001 Rockcreek Rd. Apt 2E
               Bowling Green, KY  42101-3656

Education:     BS in computer science expected December 1993
               Western Kentucky University

Specialties:   MS-DOS, OS/2 system programming; Compiler theory;
               database theory; assembly language programming

Experience:    6 years with MS-DOS, 1.5 years OS/2, 2 years Windows.
               Written many applications for fun, such as a real-time
               executive, a C preprocessor for text windowing
               routines.

Languages:     C, C++, 80X86 assembly, 6502 assembly, Pascal.

Interests:     Programming, tutoring CS students, compiler theory,
               operating system theory.  Running, weight training,
               camping, bicycle racing.


--------------------------------------------------------------------------------


Name:	Michael David Winikoff

E-mail:	winikoff@cs.mu.oz.au

Snail: 	1 Tobruk st. Bulleen 3105, Melbourne, Victoria, Australia.

Education: Finished BSc this year. Will be doing honours in 1993.

Occupation: Student :-)
	[This summer holidays I am employed by the computer science department
	 as a research assistant. I'm working on abstract interpretation of
	 Prolog]
	
Specialities: 
	(Pure Lazy) Functional programming. 

Experiance: Very little until I began my course in 1990.
	I have since spent a summer vacation avaluating the suitability of a
	relational database package for a marketting research application.

	Another summer vacation was spent researching transaction recovery
	for deductive databases. During the following year the guts of a 
	relational file system was implemented.

	This summer I am working with an abstract interpretation engine for
	Prolog.

Languages: English. C. Haskell. Prolog. ML. Parlog.
	Rusty: 68000 assembler, Pascal.

Publications: None. (yet :-)

Interests: Functional programming. (techniques, environments, operating system
			interfacing, implementation)
	Music (classical, I play piano and do some composing from time to time.)
	Role Playing (Currently Star Wars RPG)
	   
--------------------------------------------------------------------------------


   Name:           David Potter

   E-Mail:         potter@watson.ibm.com

   Snail mail:     P.O. Box 218
		   Yorktown Heights, NY 10598
		   U.S.A.

   Education:      B.S. Industrial Engineering
		   Lafayette College, Easton, PA

   Occupation:     Systems programmer at IBM T.J. Watson Research Center.
		   Systems Management, Performance Management,
		   Research into how the computer might better augment
		   human thinking.

   Specialties:    Operating systems (I love them!)
		   System performance and tuning.
		   Algorithms, (hashing, searching, etc.)
		   Process scheduling and VMM
		   State sampling user processes
		   Studying user productivity
		   Daydreaming and thinking about things which could be...

   Experience:     Been working with computers since 1963, including the
		   IBM 1620, 1130, S/360, S/370, S/390, PCs, RISC System/6000.

		   First decade spent as I.E. doing facilities planning for
		   IBM products including the System/360.

		   Second decade doing system programming for OS/MVS, especially
		   for performance management.

		   Third decade doing system programming for VM, especially
		   for performance management.  I wrote the VM/PRF tool
		   (VM/Performance Reporting Facility) for VM/XA and VM/ESA.
		   Now I am working on Unix (AIX 3 on RISC System/6000s), and
		   developing an accounting package for NIC clusters.
		   I am currently an active member of the Unix International
		   Performance Management Working Group (UI/PMWG) which is about
		   to publish a proposal for standard performance measuement enablers.

		   Permanent position with IBM (currently) since June, 1963.

   Languages:      English, Fortran, Pascal, C, C++, PL/I, Grin.

   Publications:   Several Research reports, and no books.

   Interests:      Music (Classical and Country Western)
		   Cooking
		   Puzzles
		   Hiking

*                tuktusiuriagatigitqingnapin'ngitkiptin'nga, David Potter

--------------------------------------------------------------------------------



E-Mail:         dmarer@td2cad.intel.com

Snail mail:     P.O. Box 1006
                Los Gatos, CA 95031-1006
                U.S.A.

Education:      B.S. Computer Engineering
                University of the Pacific, Stockton, CA

Occupation:     Software Engineer at Intel Corporation, Santa Clara, CA, USA
                Development of software to assist in the production of IC's,
                CAD based applications, placement of test circuitry and
                alignment marks for mask generation.

Specialties:    Assembly language programming (I love it!)
                Object oriented software development
                Microprocessor/controller based system hardware design
                DSP hardware and software design for digital audio:
                    - Sampling and playback, esp. oversampling techniques
                    - Music synthesis using frequency modulation
                    - Effects processing
                Text parsing with error detection/recovery algorithms
                GUI based applications in X Windows and MS Windows
                Daydreaming and thinking about things which could be...

Experience:     Been working with computers since 1982, including the
                Atari 800, IBM PC's and compatibles, Unix systems, VAX/VMS.

                Co-op experience with Siemens AG, Erlangen, West Germany.
                Worked with code and project management tools for a large
                scale software project, plus designed a tool to verify
                source code file inclusions against MAKE files.

                Co-op experience with Intel, Santa Clara, CA, USA.  Developed
                software to model the effect of infrared light through thin-
                film layers on silicon substrates to extract film composition
                information from wavelength data.

                Permanent position with Intel (currently) since June.

Languages:      English, BASIC, Fortran, Pascal, C, C++, Forth, Mainsail,
                plus 80x86, 68000, 6502, and VAX assembly languages.

Publications:   No papers or books published, no patents held.

Interests:      Computer music and MIDI applications
                Piano, synthesizers, guitar, octave mandolin
                Techno pop, modern rock, industrial, Irish traditional music
                Poetry and similar writings

Other:          Organizing absurdly huge projects... :-)



From dmarer@td2cad.intel.com Wed Jan 20 00:31:52 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13418; Wed, 20 Jan 93 00:31:51 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 20 Jan 93 00:31:51 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Tue, 19 Jan 93 15:30:56 -0800
Received: by td2cad (5.57/10.0i); Tue, 19 Jan 93 15:34:10 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00752; Tue, 19 Jan 93 15:40:22 PDT
Date: Tue, 19 Jan 93 15:40:22 PDT
Message-Id: <9301192340.AA00752@tdge15.intel.com>
To: rideau@clipper
Subject: Hello!
Status: OR

Fare',

First, I want to apologize for the very long delay between messages.  I've been
very busy lately, combined with vacation, as well as moving to a new apartment.
Things are starting to calm down now, but it's still pretty busy!

Second, the project is still underway!  No worries about being fired as long as
I don't let it interfere with work (which is a possibility :-), and also my
boss is interested in the results.

Third, I hope you didn't think I though you are not 'worthy' to work on it -
out of everyone in the group, you have expressed the most interest and
knowledge concerning the project!  I hate to say this, but more than half of
the people seem as if they're just 'along for the ride', and aren't really
going to participate as much as I'd like.  You are one of the people I believe
will most contribute to this project!  I am sorry to have made you feel
otherwise - I'll try to do better in keeping in touch from now on.

That reminds me...I need to contact everyone else, too.  I have been working
with one other person (actually, two at one address) on getting the video
interface underway.  You might want to contact him (them):

		ANDREAS@dhhalden.no

His name is Andreas, and he's working with another fellow named Gunnar.  They
will exclusively be working on the video interface.  I've told him about you
and your interest in this project, so he's looking forward to hearing from
you.

Actually, I'd like to discuss with you about working on the kernel of the OS.
You seem the ideal person to work with on this, given your interests.  I think
perhaps only 2 people (you and me) working on this section is the ideal number.
Any more than that is too many, in my opinion.  Are you interested?

I need to go now...we're having a power surge problem, and this computer system
may go down within the next few minutes!  Write back as soon as you receive
this so we can begin work on this 'monster'. :-)  Also get in touch with
Andreas and Gunnar, just to say 'hi' and see what's up.  Take care!

				Dennis


From dmarer@td2cad.intel.com Mon Jan 25 23:49:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09945; Mon, 25 Jan 93 23:49:31 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Mon, 25 Jan 93 23:49:31 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Mon, 25 Jan 93 14:49:16 -0800
Received: by td2cad (5.57/10.0i); Mon, 25 Jan 93 14:52:30 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00305; Mon, 25 Jan 93 14:58:50 PDT
Date: Mon, 25 Jan 93 14:58:50 PDT
Message-Id: <9301252258.AA00305@tdge15.intel.com>
To: rideau@clipper
Subject: Re:  Hello, are you still living ? Are yo still MOOSEing ? Was it a joke ?
Status: OR

Fare',

	Hello - it's Dennis again.  Are you still there?  I have sent two
messages this last week, and I hope to hear from you soon.

				Dennis

From dmarer@td2cad.intel.com Sat Jan 23 00:17:55 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24118; Sat, 23 Jan 93 00:17:54 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Sat, 23 Jan 93 00:17:54 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Fri, 22 Jan 93 15:17:44 -0800
Received: by td2cad (5.57/10.0i); Fri, 22 Jan 93 15:21:00 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00242; Fri, 22 Jan 93 15:27:16 PDT
Date: Fri, 22 Jan 93 15:27:16 PDT
Message-Id: <9301222327.AA00242@tdge15.intel.com>
To: rideau@clipper
Subject: Are you still there?
Status: OR

Fare',

	Hi...just checking to make sure you are receiving my messages.  I sent
you one a couple of days ago, but have not heard a response yet.  Just
checking...

				Dennis

From rideau Tue Jan 26 04:28:50 1993
Subject: Re: Are you still there?
To: dmarer@td2cad.intel.com (Dennis Marer)
Date: Tue, 26 Jan 93 4:28:50 MET
In-Reply-To: <9301222327.AA00242@tdge15.intel.com>; from "Dennis Marer" at Jan 22, 93 3:27 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(Fare->Dennis #9, 26/1/93)
Hello, Dennis !

>> 
>> Fare',
>> 
>> 	Hi...just checking to make sure you are receiving my messages.  I sent
>> you one a couple of days ago, but have not heard a response yet.  Just
>> checking...
>> 
>> 				Dennis
>> 

 It seems we have difficulties reaching each other.
 I've sent you a reply to the message where you talked to me about Andreas &
Gunnar, and I'm not sure you received it. Please acknowledge; I now number
this mail letter, and will number next ones until I'm sure you receive (I have
experienced some mail returns, etc, while mailing to you). 'hope you received
suggestion about a MOOSE forum, and mostly found someone to do it.
 Well, my main problem is up to now I worked in french, and all my notes were
in french. So now, here is part of it translated (my ARJfied notes are 200Kb
long).
 Here are some features I expect the system to run at high logical level
(standard language programming), and that the compiler and/or the kernel should
support:
* Objects are contained in Object Zones (OZ's); the simplest (logical) OZ is
a set, which can be physically implemented by, say, a bitmap, or a list, etc.
A more general OZ does not contain only objects, but also attributes of these
objects (which depend in nature of the OZ and of the objects): for example, a
room in a CAD program may contain objects, which each have its intrinsic shape;
but each object has its position in the room for attribute.
* standard attributes are printing/showing format (for example, for an integer,
the base hexadecimal, decimal, octal, binary, n-ary, etc; for a complex
structure involving many types of number, ...); other common attributes are
names, debug info, comments, translation into different languages, etc.
* Existence range or compute range of any object is arbitrary: any object can
be defined relatively to any other; it can be computed at any arbitrary time
(preprocessing, compile, interpret, run, more than one object in parallel or
in sequence at one time, etc).
* There is a virtual reference constructor which takes a pointer and returns
the pointed object. If the pointer is in a constant variable, you have a
virtual equivalent of physical C++ x& 's.
* There is a virtual pointer class, and thus virtual reference with virtual
pointers. You can by this mean address logically any type of variable anywhere
in the computer, etc, without changing your source program (but a big change
in a variable's nature may cause big change in optimised object code). There
may be a virtual type of pointer where the data isn't really read and written,
but given as parameter to look and modify procedures. The fact that what you
read isn't what you wrote is similar to the fact a variable may be shared
between procedures. (practical example: ln -s = symbolic link under u*ix).
* There is the standard recursive question in OO environment:the class class's
class is the class class (itself), unless it is only a subclass of class.
Well, doesn't matter if the Kernel is well written.


		   ,
		Fare

P.S. : I couldn't contact andreas & Gunnar; my mail to the address you gave me
was returned with an unknown user 550 error message. Do you confirm the good
address is ANDREAS@dhhalden.no ?

P.P.S: Happy new year ! (It's now the chinese year of the rooster or whatever)

From dmarer@td2cad.intel.com Tue Jan 26 20:01:17 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02530; Tue, 26 Jan 93 20:01:16 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Tue, 26 Jan 93 20:01:16 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 26 Jan 93 11:00:48 -0800
Received: by td2cad (5.57/10.0i); Tue, 26 Jan 93 11:03:50 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00737; Tue, 26 Jan 93 11:10:17 PDT
Date: Tue, 26 Jan 93 11:10:17 PDT
Message-Id: <9301261910.AA00737@tdge15.intel.com>
To: rideau@clipper
Subject: Re: Are you still there?
Status: OR

Fare',

	Howdy!  (whew...)  Good to hear your response - for a while there I
thought you were lost...

> (Fare->Dennis #9, 26/1/93)

This is the first message I have received since the message wondering if the
Moose project is still active.  

>  It seems we have difficulties reaching each other.
>  I've sent you a reply to the message where you talked to me about Andreas &
> Gunnar, and I'm not sure you received it.

I did not!  


> Please acknowledge; I now number
> this mail letter, and will number next ones until I'm sure you receive (I have
> experienced some mail returns, etc, while mailing to you). 'hope you received
> suggestion about a MOOSE forum, and mostly found someone to do it.

Nope, didn't get this one either... :-(

>  Well, my main problem is up to now I worked in french, and all my notes were
> in french. So now, here is part of it translated (my ARJfied notes are 200Kb
> long)....(stuff deleted)

I will read this more carefully - now I only have time to respond!

It's good to hear things are progressing - I must put my ideas down on paper
also, so I can communicate them to you also.  So far, most are still floating
around in my brain...sometimes its difficult to write these down!

> P.S. : I couldn't contact andreas & Gunnar; my mail to the address you gave me
> was returned with an unknown user 550 error message. Do you confirm the good
> address is ANDREAS@dhhalden.no ?

My mistake...

	Andreas:	ANDREASA@dhhalden.no
	Gunnar:		GUNNARH@dhhalden.no

Andreas will be gone to Oslo for the next couple of weeks due to his work -
Gunnar will still be there but I don't know how much work will be done.  Give
him a try, and see what they're up to.  They're working exclusively on the
video portion of this project, and we've discussed briefly what that will
encompass.  The rest is up to them...

> P.P.S: Happy new year ! (It's now the chinese year of the rooster or whatever)

Happy new year to you as well!  Glad to finally make contact - hope you still
have previous messages which got lost to re-send again.  Take care, and I'll
write back soon.

				Dennis

From dmarer@td2cad.intel.com Wed Jan 27 02:28:24 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12819; Wed, 27 Jan 93 02:28:23 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 27 Jan 93 02:28:23 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 26 Jan 93 17:28:17 -0800
Received: by td2cad (5.57/10.0i); Tue, 26 Jan 93 17:31:15 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01179; Tue, 26 Jan 93 17:37:53 PDT
Date: Tue, 26 Jan 93 17:37:53 PDT
Message-Id: <9301270137.AA01179@tdge15.intel.com>
To: dmarer@dmi.ens.fr, rideau@clipper
Subject: Re: Are you still there?
Status: OR

Hi Fare',


     Just now getting a chance to read what you wrote....

> (Fare->Dennis #9, 26/1/93)

>  Well, my main problem is up to now I worked in french, and all my notes were
> in french. So now, here is part of it translated (my ARJfied notes are 200Kb
> long).
>  Here are some features I expect the system to run at high logical level
> (standard language programming), and that the compiler and/or the kernel should
> support:



> * Objects are contained in Object Zones (OZ's); the simplest (logical) OZ is
> a set, which can be physically implemented by, say, a bitmap, or a list, etc.
> A more general OZ does not contain only objects, but also attributes of these
> objects (which depend in nature of the OZ and of the objects): for example, a
> room in a CAD program may contain objects, which each have its intrinsic shape;
> but each object has its position in the room for attribute.

Please elaborate on this idea!  I need more details to understand exactly how
this might work, what it will be used for, and so on.  I think I understand,
but I'm not sure - maybe some examples will help.

> * standard attributes are printing/showing format (for example, for an integer,
> the base hexadecimal, decimal, octal, binary, n-ary, etc; for a complex
> structure involving many types of number, ...); other common attributes are
> names, debug info, comments, translation into different languages, etc.

I like this idea, but I think it would be more efficient to implement these
as standard METHODS instead of standard ATTRIBUTES.  A method only adds an
entry to the virtual method table of an object, where an attribute would
add to every instance of that object.  Of course, the object would then be
able to choose whether or not it wishes to implement these methods.

By different languages, do you mean spoken or computer languages?

> * Existence range or compute range of any object is arbitrary: any object can
> be defined relatively to any other; it can be computed at any arbitrary time
> (preprocessing, compile, interpret, run, more than one object in parallel or
> in sequence at one time, etc).

Interesting idea...I wish you could expand more on this idea also so I can
better understand it.

> * There is a virtual reference constructor which takes a pointer and returns
> the pointed object. If the pointer is in a constant variable, you have a
> virtual equivalent of physical C++ x& 's.

Does this mean to actually duplicate the object being pointed to?  If so, I
agree, this is important.  Each object would need to implement its own.

> * There is a virtual pointer class, and thus virtual reference with virtual
> pointers. You can by this mean address logically any type of variable anywhere
> in the computer, etc, without changing your source program (but a big change
> in a variable's nature may cause big change in optimised object code). There
> may be a virtual type of pointer where the data isn't really read and written,
> but given as parameter to look and modify procedures. The fact that what you
> read isn't what you wrote is similar to the fact a variable may be shared
> between procedures. (practical example: ln -s = symbolic link under u*ix).

Please elaborate on this one also - it sounds similar to what I've proposed
below....


> * There is the standard recursive question in OO environment:the class class's
> class is the class class (itself), unless it is only a subclass of class.
> Well, doesn't matter if the Kernel is well written.

And of course it will be!


I hope I have not misunderstood any of your ideas - let me know if I have.
Also, I'd like to hear more of these ideas - it sounds as if we are thinking
along similar lines!


I've been thinking about the more general sense as to what objects there would
be in this system.  At the very top, the 'object' class would provide a base
class for all objects (an imlpied ancestor when none is specified) which
would describe virtual functions for displaying, copying, writing to disk,
reading from disk, and so on.  It contains no attributes (data).  A direct
descendant from this would be the 'task' object, defining a program, its
starting point, and so on.  The 'task' object also defines how a program is
loaded.  Descendant from the 'task' would be the 'device' object, which is
used to deal with all devices, physical or logical.  For example, a disk
drive is a descendant from the 'device' object; and IDE disk drive is a
descendant of the disk drive object, and so on.  Included in this are
kerboards, video display, disk drives, mice, and more.

Object could also be shared among processes.  The code needs only to be loaded
into memory once, and can be accessed by all processes.  Object instances are
a little more difficult, and must be dealt with by defining a 'sharedObject'
class which overrides the constructor and deals with multiple accesses.  The
concept of persistent objects (ones which may be accessed several times by the
same program) also follow this example.  At any one time, many parts of a
program (or even separate tasks) may use the same object, pointing to the same
instance of the object in memory.  Each constructs (instanciates) and destructs
the object individually, but the object does not actually get destroyed until
nobody references it anymore.

Files will be a use for persistent objects.  Many tasks may use the same file
at the same time, usually only reading from the file, needing only one copy of
the file (or one file buffer) in memory at one time.  Files will also be
memory-mapped for convenient access, being able to return a pointer as if the
file existed in a continuous chunk of memory.  This does not need a series of
reads & writes, but is accessed and written to using only pointers.  It's very
easy to implement on the 386!

Well, that's a bunch of ideas...hope to hear your input as well, and further
explanation of your ideas.  Take care, and keep in touch!

				Dennis

From rideau Wed Jan 27 09:58:05 1993
Subject: MOOSE
To: ANDREASA@dhhalden.no (Andreas A.), GUNNARH@dhhalden.no (Gunnar H.)
Date: Wed, 27 Jan 93 9:58:05 MET
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(To Andreas & Gunnar)
Hello happy MOOSE programmers !
 I'm Fare' (rideau@clipper.ens.fr) and I participate to this new OS project.
Firstly, I'd like to say hello ! Then, as I work in the kernel and am studying
the possibility of writing a new language, I'd like to know what is and/or
would be your usage of new language and kernel capabilities; for example
don't you find annoying rewriting many times different versions of the same
algorithm each time you just want to change a little parameter, or else, see
your program run too slow if you produce generic code ?
 Well, could you send we what you are working on; I know many people who like
graphics programming, and one who have built a whole windowing interface in
TP6.0; perhaps one of them would be happy to share your work (if you agree).
 Whatever, good luck to both of you, and greetings from France !
                                                   ,
                                                Fare
P.S.: and a happy new (chinese) year !

From rideau Sun Feb  7 19:17:53 1993
Subject: Re: Are you still there?
To: dmarer@td2cad.intel.com (Dennis Marer)
Date: Sun, 7 Feb 93 19:17:53 MET
In-Reply-To: <9301270137.AA01179@tdge15.intel.com>; from "Dennis Marer" at Jan 26, 93 5:37 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(now february the 7th, 1993)
--------------- zap zap zap ---------------

-- here's a mail  I should have sent you --
----------- at least one week ago ---------
------ no excuse; just playing NetHack ----

(Fare->Dennis #10, 28/1/93)

 Well, Hello Dennis, and sorry for (very) long delay between messages,
 These time, weeks seem to begin on wednesday and end on friday to me.
Here is my complete zoo-fied then btoa-ed notes (most of which are in french;
ask what you want me to translate).
 I've lost my week-end to install OS/2 v2.1 beta at home (AMD386/33,8-320MB);
(sorry for intel). That was no fun, and it isn't very useful (except to run
Win* shit under WinOS2, and/or having quick diskette I/O while working).


>>>  Well, my main problem is up to now I worked in french, and all my notes were
>>> in french. So now, here is part of it translated (my ARJfied notes are 200Kb
>>> long).

(that's mostly FRENCH)
(hope you have a >80 columns display to read this mail, because of >>>'s)
(btw, do you have something to automatically add or destroy groups of
chars at the beginning of each line)(I'm using lemacs at the moment)


>>>  Here are some features I expect the system to run at high logical level
>>> (standard language programming), and that the compiler and/or the kernel should
>>> support:

First, let me recall my philosophy about high-level language & the kernel.
 At high-level, you are concerned mostly with logical structures; you let the
system choose physical implementation for you, and it is meant to do it
efficiently. You may choose to let the compiler do with as few additional
information as possible; The compiler itself will then evaluate the cost of
each known implementation technique. The lgagage
explicit data is also accepted and you can help the system with extra
explanations.
 At very high-level, everything is virtual, even the more simplest operations.


>>> * Objects are contained in Object Zones (OZ's); the simplest (logical) OZ is
>>> a set, which can be physically implemented by, say, a bitmap, or a list, etc.
>>> A more general OZ does not contain only objects, but also attributes of these
>>> objects (which depend in nature of the OZ and of the objects): for example, a
>>> room in a CAD program may contain objects, which each have its intrinsic shape;
>>> but each object has its position in the room for attribute.
>>
>> Please elaborate on this idea!  I need more details to understand exactly how
>> this might work, what it will be used for, and so on.  I think I understand,
>> but I'm not sure - maybe some examples will help.

OZ are a high-level construct, and if we want to build a single base physical
implementation for it in a first version of the kernel,

>>> * standard attributes are printing/showing format (for example, for an integer,
>>> the base hexadecimal, decimal, octal, binary, n-ary, etc; for a complex
>>> structure involving many types of number, ...); other common attributes are
>>> names, debug info, comments, translation into different languages, etc.
>>
>> I like this idea, but I think it would be more efficient to implement these
>> as standard METHODS instead of standard ATTRIBUTES.  A method only adds an
>> entry to the virtual method table of an object, where an attribute would
>> add to every instance of that object.  Of course, the object would then be
>> able to choose whether or not it wishes to implement these methods.

 At high level, methods, attributes, functions, etc, are only different forms
(more or less elegant, following the context) to express the same conceptual
idea. Perhaps in nowadays languages, which forces you to define low-level data
structures, we tend to assign one high-level concept its common low-level
representation.

>> By different languages, do you mean spoken or computer languages?

Well, BOTH, of course !
 A "comment" will be a link to another definition of the same object; it can
redundant, equivalent, or concurrent to the "main" definition of the object
(which here is the raw binary representation). There even needn't always be a
main representation; in fact, between the different ones, the system will
choose which to use with those criteria: firstly, the computer must entirely
"understand" the definition, with respect to the features actually used;
secondly, the cumulated costs of the computation of the representation and of
its use must be as low as possible; if there is a doubt, choose the more
immediate representation and/or the easiest to edit/debug for the user.
 Thus, a beautiful functional language definition may come with a portable C
version of it, plus some assemblers optimized transcriptions for the most
common porcessors on the which the code will be used and/or systems where this
critical code portion may be considerably optimized (in term of speed and/or
size, etc) when hand coded.
 With this point of view, a source program can be concurrently defined in more
than one language (and/or many times the same language) with the same (logical)
interface; the system will choose the "better" between them. Among the
definitions, you can add more or less global/local equivalents in french (or
english). A global equivalent of a module may be its explanation/description;
local equivalents inside it may be comments about tricks used here and there.
Of course, there isn't any compiler from french (or english) to computer-under-
standable code, so french (english) version will always stay a comment.
 As the language is its own preprocessor, you can also build constructed and/or
embedded comments in the main code; to allow you to write code in the order you
would in the text version of the language, just use the language linking capa-
bilities in the meta- part of it to describe the program as it should be
ordered to be understandable. You won't have entire copies of the same routines
in different languages uglily alternating, or multiple occurence of a (real)
comment in each different version; but in the "good" choosen version,
everything will come fine. A graphical interface for the language (and why
continuing basing language upon linear text, not to talk about linear ASCII
text, after all ? -- if I chose to compile source texts for the language, it
was mostly because it would be too difficult to debug simultaneously the
language and the graphical interface; this means that FOR THE TIME BEING, the
language will have to be easily expressible in text; but the next revolution in
the way of thinking will be the end of the linearity in texts imposed by the
paper media, and the use of a graphal non-linear way of linking things to
others. There is no total order in ideas; not even a partial order; there are
only ideas, everyone of which uniquely, complicately interlinked with the
others, some of which can be constructed in a certain order from some base ones,
or in another order from other base ideas).

>>> * Existence range or compute range of any object is arbitrary: any object can
>>> be defined relatively to any other; it can be computed at any arbitrary time
>>> (preprocessing, compile, interpret, run, more than one object in parallel or
>>> in sequence at one time, etc).
>> 
>> Interesting idea...I wish you could expand more on this idea also so I can
>> better understand it.

 Here are some examples:
- imagine a 3D surface visualizer, which will compute many thousand times the
result of a run-time user function. Up to now, you had to make your own parser
(or get and understand one) or call a VERY costly compiler session; neither of
these is a good solution for the developer (which does not mean it is not
interesting by itself). With our system, just define a function variable; use
the STANDARD system parser with any of its (eventually modified as you like)
PREDEFINED configuration to produce a function object from a user input.
To just debug your program, use the virtual function class. It will be slow, it
will possibly re-interpret the function value string each time you call it, but
from high-level point of view, it will be the same. To optimize, ask the
compiler to think about it (in the final version) and/or tell him precisely
what YOU think is the best (the default in the optimizing final version, is to
compare what you propose to what it computed, and warn/react somehow if it
disagrees and thinks to have found better than you).
- in a generic Discrete Fourier transform, you may want to use sinus and
cosinus tables (or even tables of complex numbers of modulus 1)
- in a large application, you may have a huge database, part of it being a kind
of index varying very slowly with respect to the rest of the db, but extremely
quickly with respect to the code; this can happen inductively with parts of the
object as small as you look close. But as current systems does not include
data/code embedding at system time, it will be up to the user not to modify the
index without uptading the db organization common run-time.
- in some numerical (or combinatorial) applications, you have heavy
computations where appears constants which simplifiate considerably the
calculus, without being themselves trivial to express generically.
For example, C & Pascal only understand as constants numbers or pointers
well defined from nothingness with only standard algebraic operations;
everything else will be computed at runtime, or must be done in another;
but sometimes, the simplifying constant is not from a base type, and is
computed with slow routines (which may be nevertheless quick compared to saved
run time); common examples are a matrix appearing as the result of basic
algebraic operations which depend on the dimension of the matrix, or a
complex precomputation (sort/coding/compression/etc) of a data base.
(exercise: find your own examples)
- in a simulation (I prefer games, but some earn more money with the military),
you may have landscapes calculated from raw data; you would like to embed the
calculation of the landscape and its use in the same program object (but you'll
put them in different modules, so to optimize partial recompile). For now, the
only solution is have a makefile to manage two (at least) distinct programs
possibly sharing common libraries, etc. The make system helps you manage
everything, but does not eliminates all manual maintenance, slices your program
in small files (which eats a lot of place on the file system) forces you to
learn yet another language (even simple) that, not being powerful enough, has
you use complex shell tools to do something which at the end won't be as well
as if the language was meta-itself, not allowing you to manage efficiently
interlinked programs, generic modules, etc.

* The key-point is: there is no clear limit dividing using, modifying, and
programming. Compiling a program may involve running others and vice versa.
You'll always need one day to adapt a little part of an object, which will have
to have been properly isolated in a module when conceived, but with the module
linked with others. If the language and the the system are identically OO-ed,
all you'll need do is cut links to partially or totally disconnect modules
from others, tie new links to filter between old modules or replace an obsolete
(or too buggy) one or add a new feature, etc. If the system is well done, this
must be efficient (quick tranfert rate, partial local compile possible for a
next version, etc). Standard libraries must help you find all known frames to
interlink object, and include for each frame enough ways of coding it so as to
get a quick compact code.

>>> * There is a virtual reference constructor which takes a pointer and returns
>>> the pointed object. If the pointer is in a constant variable, you have a
>>> virtual equivalent of physical C++ x& 's.
>> 
>> Does this mean to actually duplicate the object being pointed to?  If so, I
>> agree, this is important.  Each object would need to implement its own.
>> 
 Well, sometimes, it may be useful and/or compulsory to actually duplicate an
object, and of course, their should always be a way to code an object. You may
also choose to duplicate an object in a shared system where data flow faster
or slower between different devices, to ensure the faster transfer rate with
the shortest wait time between refresh of different copies of a file, and
security with respect to hardware failure (cable problems between a computer
and a remote system, unexpected shutdown between the high speed volatile RAM,
and the slow permanent disks, etc). The most difficult are the scheduling
problem (whose place must be reserved for a further version of the system), and
the external link problem.
 I won't talk about scheduling this time (I think this can come after; perhaps
next time). But here is the linking problem: you must be able to consider a
copy of an object, the object being nothing by itself, but only by its links.
Then, when the copy uses its link, you must know either to link to the original
linked object, or to a copy of it, etc... .
  example: (originals in uppercase, copies in lowercase, second copies with two
	   letters, third copies in reversed video, fourth copies blinking ... )
	   (same name, same object)
		A--B	a--B	aa--b   ...
		|	|	|
		C	c	c
 We may also have logically different objects, which, as long as they take the
same value, will not be duplicated.
 In fact, there are two associated problems: how to physically duplicate a same
logical object (that's distributed computing), or how to logically duplicate a
logical object (that's avoiding an exponential explosion of memory allocation).

 However, what I originally meant is that even a basic logical constructor like
the one which takes a type and returns a pointer type on it is virtual. But
there's also an implicit reference constructor, as in C++: the virtual logical
type is the same, but you must use a pointer before accessing the "real"
object. For example, if their is a virtual integer A, you tell the program how
to access A rather than giving it a raw memory place to store it. From the
logical point of view, it behaves the same, but physically, you can then link
A to any set of routines allowing needed integer operations; in particular, you
can give A a physical pointer link to a variable in another program which won't
have been published following a standard method (i.e. the variable is in
registers and/or changes place during its life; another virtual variable !).


>>> * There is a virtual pointer class, and thus virtual reference with virtual
>>> pointers. You can by this mean address logically any type of variable anywhere
>>> in the computer, etc, without changing your source program (but a big change
>>> in a variable's nature may cause big change in optimised object code). There
>>> may be a virtual type of pointer where the data isn't really read and written,
>>> but given as parameter to look and modify procedures. The fact that what you
>>> read isn't what you wrote is similar to the fact a variable may be shared
>>> between procedures. (practical example: ln -s = symbolic link under u*ix).
>> 
>> Please elaborate on this one also - it sounds similar to what I've proposed
>> below....

   See previous paragraph.

>>> * There is the standard recursive question in OO environment:the class class's
>>> class is the class class (itself), unless it is only a subclass of class.
>>> Well, doesn't matter if the Kernel is well written.
>> 
>> And of course it will be!

   (I pray for it to be)

>> I hope I have not misunderstood any of your ideas - let me know if I have.
>> Also, I'd like to hear more of these ideas - it sounds as if we are thinking
>> along similar lines!

  Well, people of similar occupation in the same world are often subject to
have the same ideas, all the more as these ideas come from the same serious
lack in their common environment.

>> I've been thinking about the more general sense as to what objects there would
>> be in this system.  At the very top, the 'object' class would provide a base
>> class for all objects (an imlpied ancestor when none is specified) which
>> would describe virtual functions for displaying, copying, writing to disk,
>> reading from disk, and so on.  It contains no attributes (data).  A direct
>> descendant from this would be the 'task' object, defining a program, its
>> starting point, and so on.  The 'task' object also defines how a program is
>> loaded.  Descendant from the 'task' would be the 'device' object, which is
>> used to deal with all devices, physical or logical.  For example, a disk
>> drive is a descendant from the 'device' object; and IDE disk drive is a
>> descendant of the disk drive object, and so on.  Included in this are
>> kerboards, video display, disk drives, mice, and more.

 I agree, but I'd like to add that the "virtual" adjective should not to me
mean "with reference to a function table called \"virtual\"", but actually,
that it means that the compiler (or the top level) be able to retrieve it
from compile info. The machine code may be totally different, most table
look-ups may be short-circuited, etc.

>> Object could also be shared among processes.  The code needs only to be loaded
>> into memory once, and can be accessed by all processes.  Object instances are
>> a little more difficult, and must be dealt with by defining a 'sharedObject'
>> class which overrides the constructor and deals with multiple accesses.  The
>> concept of persistent objects (ones which may be accessed several times by the
>> same program) also follow this example.  At any one time, many parts of a
>> program (or even separate tasks) may use the same object, pointing to the same
>> instance of the object in memory.  Each constructs (instanciates) and destructs
>> the object individually, but the object does not actually get destroyed until
>> nobody references it anymore.

 Here for example, for high level users, sharedObject will be another
realisation of the virtual Object class; it will include new features, etc.
>From high level to low-level, there will be a meta-list of the named objects
and their types.

>> Files will be a use for persistent objects.  Many tasks may use the same file
>> at the same time, usually only reading from the file, needing only one copy of
>> the file (or one file buffer) in memory at one time.  Files will also be
>> memory-mapped for convenient access, being able to return a pointer as if the
>> file existed in a continuous chunk of memory.  This does not need a series of
>> reads & writes, but is accessed and written to using only pointers.  It's very
>> easy to implement on the 386!

 That's ok for big files and big memory swapping, but what to do when many many
little ( <128 bytes ) objects begin to replicate in a program ? If you let them
multiply, you will be forced to swap whole pages just for a small part of code !
Thus, you must separate little objects and big objects and/or institue strict
page alignment for all objects AAARRGGGHHH !!!
 (But somehow, one cannot escape from this problem).

 A first thing to do is treat differently small and big memory allocation
(depends on the ratio memory used/memory taken if taken in 4Kb blocks). What we
may then do to lighten memory management is use sub-memory systems. 
 Each program can allocate memory in different systems. Their is a standard
virtual memory system type, highly interlinked in its implementation with the
ObjectZone class. The crucial difference between the two is that OZ take
objects as unit, the objects being possibly of different length, while memory
systems take byte (or word, or para, or block, etc) as unit. In fact, both are
complementary way to see the same phenomonon from different but necessary
points of view.

 Standard systems are available from the Kernel, to answer frequent use; the
more used the system, the more immediate to use; but standard system makers are
available at high-level (notice that I don't, never, put apart the programming
language and the system, as both are embedded; the language syntax as well as
the system exact executing sequence may change, but what is essential is the
link between both, and that one is never complete without the other; if one is
inefficient at doing something, so will be the other; their are two faces of
the same). Those makers allow one to make a mem.sys. inside another one, toe
meet the demand with the offer.

 On the 386 version, the problem about memory allocation & tasking is mainly for
the big number of very small inndependent items: how to manage quick allocation
and use of little bits of memory and still keeping anyone of them of killing not
logically linked objects. There is also this eternal question: should their be
a global garbage collecting (GC) system ? If yes, how to implement it ?

- a basic system for 4Kb blocks using virtual memory and possibly segmentation
- a basic system transforming a big segment into usable get&dispose memory
- a system to transform get&dispose memory into garbage collecting system
- ...

>> Well, that's a bunch of ideas...hope to hear your input as well, and further
>> explanation of your ideas.  Take care, and keep in touch!
>> 
>> 				Dennis
>>
				   ,
				Fare

(Well, good luck for MOOSE, and sorry for the delay between message)
(Perhaps we should synchronise;


P.S.:
- If we are to use code from standard DOS or U*ix compilers/assemblers, we neede
know the format of the output from theses programs (different .OBJ, .TPU, .DLL,
formats under DOS, ? under Un*x ? And what of the file systems used ?

- What we should do is quickly agree upon kernel features, ask for agreement
from every member of the project while precising actual coding.

- Our current working mode is too slow. We should have a ftp site, and a regular
mailer daemon. I'm too slow myself.

From dmarer@td2cad.intel.com Thu Feb  4 20:19:24 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00990; Thu, 4 Feb 93 20:19:21 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Thu, 4 Feb 93 20:19:21 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Thu, 4 Feb 93 10:36:14 -0800
Received: by td2cad (5.57/10.0i); Thu, 4 Feb 93 10:33:15 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00657; Thu, 4 Feb 93 10:46:08 PDT
Date: Thu, 4 Feb 93 10:46:08 PDT
Message-Id: <9302041846.AA00657@tdge15.intel.com>
To: ANDREASA@dhhalden.no, danodom@matt.ksu.ksu.edu, dmarer@td2cad.intel.com,
        duzan@cis.udel.edu, garfield@sra.com, haydedr@wkuvx1.bitnet,
        mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu,
        rideau@clipper, winikoff@cs.mu.oz.au
Subject: New mailing list!
Status: OR

Greetings all!

	This is a quick message to distribute a current mailing list.  A few
of you have mentioned that there might be a site you know of which could
accomodate us with (1) a mailing list, and (2) a place to store files which
could be FTPed in and out.  If you do, let me know now...if you don't, I'll
have to set up an account which will will cost me about $20/month plus about
$0.04/month/kbyte stored.  (I'd prefer the free route, but the service is
nice with the paid account.)  Give me a yell if you know of someone!


Major Contributors: (150% effort and above)
-------------------------------------------------------------------------------
	Andreas Arff		ANDREASA@dhhalden.no
	Gary Duzan		duzan@cis.udel.edu
	David Garfield		garfield@sra.com
	Ross Hayden		haydedr@wkuvx1.bitnet
	Dennis Marer		dmarer@td2cad.intel.com
	Rob McKeever		mckeeveb@sfu.ca
	John Newlin		newlin@ecn.purdue.edu
	Dan Odom		danodom@matt.ksu.ksu.edu
	Fare' Rideau		rideau@clipper.ens.fr
	Michael Winikoff	winikoff@cs.mu.oz.au

Other Contibutors: (Under 150% due to time constraints)
-------------------------------------------------------------------------------
	Peter Mueller		mueller@sc.ZIB-Berlin.DE	(105%)

	I haven't heard from everybody, but I expect a few more responses in
the near future.  I'm working on putting together the initial specifications
(revision 0) so I will send those off to everybody in a day or two.  (Depends
how motivated I am tonight... :-)  From there, we'll all be able to get an
idea of the "big picture", and discuss what needs to be changed and firm up
some details.  Nothing at this point is set in concrete - it's all up for
discussion, so contribute those great ideas!  We'll keep revving it until we've
decided as a group nothing more can be changed, and then start internal design.
So far it's about 10 pages long, plus I'll add some more tonight...are you sure
none of you has an FTP site we can use?  I can't wait!

	Things to think about: Which languages to implement? My preference is
C++ which will be a standard by the time we're done (hopefully), but that's
also up for debate.  Also, still taking suggestions for group names and
product names.  Now is the time to send them in!

	Also, I've talked with several people interested in cross-porting this
project to the Motorola processor at the same time we're writing for the 386.
(Forgive me Intel!)  I think this is an excellent idea!  Unforunately I don't
have 68k access...

	Keep in touch!

				Dennis


From dmarer@td2cad.intel.com Tue Feb  9 23:50:16 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16147; Tue, 9 Feb 93 23:50:13 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Tue, 9 Feb 93 23:50:13 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 9 Feb 93 14:43:40 -0800
Received: by td2cad (5.57/10.0i); Tue, 9 Feb 93 14:46:56 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01677; Tue, 9 Feb 93 14:53:30 PDT
Date: Tue, 9 Feb 93 14:53:30 PDT
Message-Id: <9302092253.AA01677@tdge15.intel.com>
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
Subject: Moose specs: Revision 0!
Status: OR

Howdy,

	Here it is.  After many weeks of waiting, I can finally send to you
the specifications for the Moose operating system project...revision 0, of
course!  Actually, this is more of a revision -72, as it has *tons* of work
left to be done on it.  Last night I finally 'finished' it to a point where
I could send it to all of you and get your input.

	Careful - it's over 600 lines long at this point...give yourself
quite a bit of time to read it and understand it.  Once you have, I'd like
your *detailed* input on my ideas.  Anything you think should be changed,
let me know & we'll talk about it.  If you think parts need to be added,
removed, anything, let me know and we'll do it.  This is the document from
which we'll be creating an operating system, so it needs to include every
detail, every facet, every nuance of the interface to the operating system.
At this point, it does not!  It will probably take several weeks (months?)
to iron out all of the details, but we can start work as soon as the basic
details about the OS are set in concrete.

	Keep in touch - hopefully with your suggestions (and the remainder
of my ideas) I'll have revision 1 out by this time next week.  We'll keep
going until we're done, even if that means hundreds of revisions... :-)

-------------------------------------------------------------------------------

                     Moose Operating System
                     Initial Specifications
                       Revision 0, 2/8/93


I. General Specifications

A. Introduction

     The Moose operating system will be a compact, flexible, and
powerful operating system.  It is being designed as a replacement
for older operating systems available for the personal computing
arena, such as DOS.  Many of its features will be similar to
existing products, combining the end-user simplicity of the
Macintosh with the networking and multi-user strength of Unix, as
well as the graphical user interfaces found in X Windows, Microsoft
Windows, and OS/2.

     Many of the strengths of the Moose operating system stem from
the fact that it will be designed from the ground up with the
object oriented paradigm (OOP) in mind.  Common system entities
such as devices and files will each be treated as objects, each
with their own methods and attributes.  Devices with similar
functions can be implemented with identical interfaces, allowing
programs written for one device to work universally with all
devices of its class.

     For example, a program which creates a graphical screen
display would be able to use the same code to generate a printout
or send a fax just by referencing a different device object.  On
the other hand, complex devices could also be given more elaborate
interfaces to allow maximum efficiency in accessing hardware.  A
certain amount of universal portability might be lost in this case,
but the application programmer would be left to choose the
appropriate method to meet his or her needs.

B. Resource Requirements

     One failing of many recent operating systems is the vast
amount of resources necessary just to support the operating system
itself.  This detracts from the usefulness of a system as a whole,
leaving less room for applications.  Since today most personal
computers are sold with between 2MB and 8MB of memory, an operating
system and its basic drivers should consume no more than 25% of
available RAM.  This equates to 512k of RAM on a basic system, and
hard drive requirements should also follow similar guidelines,
limiting necessary usage to 25%.  Unnecessary device drivers, even
those supporting standard devices such as floppy disks or video
cards, should only be loaded onto disk or into memory as the user
deems necessary.

     As applications grow more and more complex, software designers
argue that they require additional resources to support their
needs.  Most graphical user interfaces, for example, are quite
complicated and require considerable effort on the part of the
application programmer to develop software for.  In many ways
modern applications do require more resources, but these could be
reused and shared among similar applications, significantly
reducing the total overhead involved.

C. Platform Issues

     This project will be developed concurrently for two major
microprocessors, the Intel 386 and the Motorola 680?0.  This will
insure the system design will be flexible and avoid features which
cannot easily be implemented on other popular architectures.  Once
the basic system has been designed and implemented for both
platforms, much of the application code can be shared between the
two to reduce the amount of work necessary in creating a complete
system.

>> Which base Motorola 680x0 should be used?  020?  030?  The final
>> decision should depend on (1) which is prevalent today? (2)
>> which can easily support features such as multi-tasking, virtual
>> memory, etc without external hardware?  The idea is to simplify
>> our design task without alienating a large population... :-)

     At this time it is also important to note that since there are
relatively few differences between the 386 and 486, no distinction
will be made between the two.  Features which are specifically
found in the 486 and not the 386 will not be used to in order to
promote greater portability.  As the Pentium microprocessor is
released, certain enhancements may be added to improve performance,
and the same holds true for future versions of the Motorola
devices.

     As far as possible, the kernel will be designed and
implemented with a generic platform in mind.  For example, even
though most Intel 386 systems targeted will be IBM PCs and
compatibles, every effort will be taken to insure most of the code
will also work on other 386 based systems.  This holds even more
true for the Motorola platforms, as both the Macintosh and Amiga
and a variety of other systems are built around this device.

D. Design Principles

     Many of the design principles which will be used are taken
from the text "Operating Systems" by Andy Tannenbaum.  In
particular, the operating system should act as only as a virtual
extension of the physical machine and as a manager for the
machine's resources.  Actual responsibilities will include memory
allocation and access, hardware access, task handling and swapping,
and task protection and priority levels.  This will supply a
framework for a complete, flexible operating system which can be
easily extended.

     The two most important features designed into the Moose
operating system will be simplicity and flexibility.  For one, a
simple design with good expansion capabilities will be easier to
design and maintain than a more complex one which implements every
possible feature.  The fewer features implemented, the fewer
problems will arise, and the better the system as a whole will run. 
A simple design does not necessarily sacrifice power, and a
flexible system allows new features to be added easily.  For
example, both Microsoft Windows and OS/2 implement code
compatibility with other popular 80x86 based operating systems. 
This dedicates resources which could otherwise be available to
applications, reducing the power of the system.  In a flexible
system, the user could add such capabilities as desired.

     As mentioned before, Moose will be developed with the object
oriented paradigm in mind where all system entities will be treated
as objects, especially devices such as video displays, keyboards
and mouses, local and networked disk drives, and communication
ports.  Objects will be implemented in such a way that they are
useful by an object oriented language such as C++ or an object
oriented implementation of Pascal, and so on.  This would
eventually allow objects developed in one language to be shared
among applications written in another language.

     Mechanisms such as encapsulation, single and multiple
inheritance, and polymorphism will be defined at the operating
system level, increasing the reusability and utility of objects in
general.  At the same time, only one copy of an object's code will
need to exist in memory at once in order for it to be used by
several tasks simultaneously.

E. Protection Hierarchy

     Three distinct priority levels will exist in this operating
system, each of which will be protected from the others through a
variety of mechanisms.  At any one time, each task in the system
will be operating at a specific privilege level which specifies the
extent of memory and hardware access it is granted.  A task will
not be able to change its privilege level, but will be allowed
access to a number of functions which operate at a higher privilege
level, returning to the original level once a function has
completed.  This will allow even under privileged tasks to perform
common system functions such as memory allocation and device
access.

     The most privileged level will be reserved for use by the
operating system and its services, which is called the "kernel"
level.  It will require full access to a system's resources, and
will be responsible for performing functions essential to
operation.  In addition, the kernel itself will be inherently non-
portable, needing to know the intimate details about the
microprocessor being used and specifically the platform being run
on.  For these reasons and also for speed concerns, the kernel
portion of the operating system will be written entirely in
assembly language.

     At the middle "device" privilege level, device drivers will
require some special memory privileges and direct access to
specific portions of hardware.  While the operating system will not
implicitly grant each device driver full hardware access, one will
certainly be able to request access to those areas that are
necessary.  This will be used to avoid conflicts between various
drivers as well as to prevent misbehaving software from accessing
hardware which could interfere with normal operating system
functions.

     Application software will operate at the most restricted
level, the "user" level, requiring no direct hardware access or
special memory access.  This means that applications will rely on
device drivers and the kernel itself to perform all privileged
functions.  For this reason, only the system administrator will be
allowed to install and activate such device drivers and portions
of the kernel.  An interesting side effect of this is that the
application designer is almost forced to write software without
respect to the platform it is being developed for, resulting in
high reusability.


II. The Kernel

     The heart of the Moose operating system will be the kernel,
a small and important part responsible for performing functions
essential to the operation of the system as a whole.  It's primary
function is to share resources between tasks, including memory,
devices, and CPU time.  Any operations not directly related to
resource management will be implemented as device drivers or in
operating system libraries.

     It is important the kernel be as small and as efficient as
possible, so its implementation may be as varied as the types of
microprocessors it runs on.  Regardless, its interface will be
constant across platforms, increasing portability of applications
written for the Moose operating system.  The kernel will be divided
into the following logical sections: 

          General Memory Management
          Shared Memory Management
          Device Memory Management
          Memory Transfer (DMA)
          System Clock

A. General Memory Management

     Within the Moose operating system, virtual memory will be
employed to maximize flexibility and to help multiple tasks
coexist.  Infrequently used portions of memory may be swapped to
a hard disk or other mass storage device to allow use by other
tasks, and some portions may need to be relocated about physical
memory to provide optimal compaction and to reduce fragmentation
of memory blocks.

     Most tasks will never need to call these functions explicitly
as a certain amount of memory will be allocated to each upon
initialization, depending on the compiler used.  This larger block
of memory should then be broken up by the task into smaller, more
useable pieces, removing a lot of the burden from the kernel. 
Tasks which need additional or possibly extraordinarily large
blocks of memory are free to allocate these as necessary.

     It's important to note that in most implementations, a
difference will exist between a logical address as seen by a task,
and a physical address, as used to actually address physical
memory.  This mechanism is what allows virtual memory and
protection of memory between tasks.  The task never needs to know
that the logical address it uses to access memory is not directly
related to a physical memory address, as the kernel and related
paging hardware will perform the address translation transparently.

     Just a handful of functions will be necessary to supply a task
at any privilege level with the means for utilizing memory.  These
functions may be called from all privilege levels, including the
most restricted "user" level.  All memory allocated will be
accessible only by the requesting task and its parent or children
tasks, allowing no other tasks access to this memory.

1. Allocating memory

     Memory will be allocated from the system free memory heap by
requesting a block of memory with a specific attributes, as
specified in the 'flags' parameter, and a particular 'size'.

          block address = MemoryAllocate(flags,size)

     The 'flags' parameter specifies the attributes of the block,
but at this time only limited choices exist.  Each pair of choices
is mutually exclusive, where selecting one will automatically
override the other.

          MEM_VIRTUAL    Block utilizes virtual memory (default).
          MEM_PHYSICAL   Block exists in physical memory.

     By default, memory blocks will be marked with the MEM_VIRTUAL
flag, allowing them to be freely moved about in memory and swapped
to disk or some other mass storage device for later retrieval.  The
operating system and other tasks will coexist best when virtual
memory can be utilized for memory blocks, especially ones.  This
frees seldom used memory for use by other tasks.

     A memory block can be locked within physical memory by
specifying the MEM_PHYSICAL flag.  This is useful in time critical
applications or by device drivers which require all parts of a
memory block to exist in physical memory at one time, even though
portions of the block may still be relocated as necessary.  Using
this feature will degrade the flexibility of the rest of the system
in terms of memory management, and should be used sparingly. 
Unless absolutely necessary, memory blocks of 1 megabyte in size
or larger should never be marked with the MEM_PHYSICAL flag.

     It is important to note that the total number of bytes
allocated in a block may be larger than the number specified by the
'size' parameter.  To simplify and expedite memory management, only
large chunks of memory will be allocated at one time, usually
varying between 1k and 8k in size, depending on the host platform. 
This means that to reduce the total application overhead, only a
small number of large memory requests should be made by one task. 
There will be a limit on the total number of memory allocations
made by a single task and in the system as a whole, so efforts
should be made by applications to consolidate memory usage.

     The starting address of the memory block will be returned by
this function.  If the allocation fails a null address is returned,
indicated by an address of zero.

2. Reallocating memory

     Once a block of memory has been allocated, its allocated size
will be modifiable, taking from or replacing to the system free
memory heap.  Note that this function will also deal with memory
in blocks between 1k and 8k in size, meaning the size of the
resulting block could be larger than the requested 'size'.  The
original address returned by the original call to MemoryAllocate()
will still be valid and point to the start of the allocated block.

          status = MemoryReallocate(size)

     The status returned indicates the success or failure of the
reallocation of a block of memory.  As with most functions, a zero
value indicates failure while a non-zero value indicates success.

     This function will have certain implementation problems on
systems which do not support virtual memory.  Since the
reallocation of large blocks of contiguous memory depends on the
location of neighboring blocks, this function will most likely
often fail on such systems.  However, most modern systems do
include virtual memory hardware in one form or another, so this
should not be a problem.

3. Freeing memory

     Once through with a block of memory, a task will be able to
free it back into the system free memory heap.  This will
invalidate the address and allow other processes to utilize this
memory.  Note that all memory allocated by a task will be
automatically freed to the system when the task exits, but it is
still good programming practice to implicitly free this memory.

          status = MemoryFree(block address)

     Again, a zero status will indicate some error, while a non-
zero status will indicate success.

B. Device Memory Management

     Device drivers and other tasks operating at the device
privilege level may need special capabilities to insure they
operate efficiently and (sometimes) properly.  It is often
important that a device is serviced as quickly as possible,
requiring a memory block always be in physical memory, which can
be accomplished by marking the block with the MEM_PHYSICAL flag. 

     Many other devices, especially those using DMA or similar
transfer by hardware external to the CPU, may require a memory
block to exist in a contiguous memory space at a fixed position. 
Due to hardware limitations, some memory blocks may even need to
exist between a range of physical memory address.  For example, the
8237 DMA controller on the IBM PC platform is only capable of
transferring to and from memory in the first 1 megabyte of physical
memory.  These requirements facilitate the need for some special
functions accessible by tasks running at the device privilege level
or higher.

     Devices will often require the implicit use of a specific
physical address or range of addresses for proper operation, and
these addresses may exist either in regular memory space or in I/O
space.  Some processors, such as the Motorola 68000, may not
differentiate these two address spaces.  Because of this, the
interface will be dependent of the processor being used, and will
be discussed indivdually on a processor by processor basis.  This
is not a problem as most devices are bound to a single platform
anyway.

1. Allocating memory: Device privilege level specific flags

     When allocating memory using the MemoryAllocate() function,
tasks operating at the device privilege level are given a few more
flags to choose from.

          MEM_FRAGMENTED      Memory block is fragmented (default).
          MEM_CONTIGUOUS      Memory block is contiguous.

     A block of memory may be made contiguous so it will occupy a
contiguous series of physical memory addresses.  The starting
address of the block within physical memory will also be fixed to
an address, meaning the block cannot be moved by the kernel to
allocate other memory requests.  This will be useful for device
drivers which utilize DMA or similar transfer by hardware external
to the CPU.   Note that making a block of memory contiguous will
imply that block is located entirely in physical memory, regardless
of whether or not the block has its MEM_PHYSICAL flag set or not.

>> Special DMA memory requirements: 8237 can only xfer under 1Meg?

C. Shared Memory Management

>> How should this be done?

D. Memory Transfers (DMA)

>> How should this be done?

E. System Clock and Event Scheduling

>> How should this be done?

F. Interrupt Handling

>> How should this be done?



III. Objects

     An object in the Moose operating system will be defined as
the encapsulation of a data structure (attributes) with the
functions (methods) dedicated to manipulating that data, known as
a class.  New, derived classes will be able to inherit the data and
functions from one or more previously defined base classes while
possibly redefining or adding new attributes and methods.  This
will create a hierarchy of classes using both single and multiple
inheritance, if necessary.  Finally, a single method can be
implemented differently by several different classes in a hierarchy
in a way appropriate to those classes to achieve polymorphism.

     Strictly speaking, the operating system will define nothing
more than a standard format for storing a class and a methodology
for accessing its attributes and methods in a meaningful way.  No
enforcement of these policies will actually be done to allow for
maximum flexibility and efficiency.  If objects are not implemented
correctly by an application or device driver, the loss will be only
functionality of that particular software.  While it would be
possible to implement standard functions within the kernel for
accessing objects, this is certainly not practical.

>> Actual format of the object?  VMT access?

     The operating system will define the interface to standard
classes, many of which will be implemented in the operating system
library.  Concrete ojects such as files, semaphores, timers, and
interrupt handlers will be implemented in the operating system
library for immediate use by the application programmer.  The
remainder of the objects defined by the operating system are
classified as devices, and will be discussed thoroughly in the
following section.

1. Files

>> Anybody have ideas on how files can be implemented as persistent
>> objects?  How about memory mapped I/O?

2. Semaphores

     A semaphore object will be implemented by the operating system
library to further enhance its multitasking capabilities.  This
will provide a simple way for tasks to coordinate the usage of
shared resources.  It will contain only two simple functions, as
shown below.  A semaphore is initialized with some predefined
value, always positive, usually one for mutual exclusion.

     When a task wishes to access a semaphore, it decrements the
semaphore's value by one.  If the resulting semaphore value is
positive, the task is allowed to enter its critical region. 
However, if the semaphore count is negative after decrementing, the
task is placed in a list of tasks waiting on the semaphore and is
made to sleep until the semaphore is incremented back to zero and
the task is given control.  Once the task has control, it is woken
from its sleep and may enter its critical section.

          semaphore@Down()

     Once the critical section has been completed, the task may
relinquish control of the semaphore by incrementing its value by
one.  The next task in the waiting list will then be woken and
allowed to enter its critical section.

          semaphore@Up() 

3. Timers

     A useful object for accurately reporting time elapsed since
a particular event will be the timer object.  This object will
utilize the event scheduling capabilities of the kernel while
providing a simple interface to the programmer.

     Essentially, a timer has two states, running and stopped. 
When a timer is created, it is stopped and has an internal count
of zero.  When a timer is started, its internal count is
synchronized with the system clock, from which an accurate count
of time elapsed since it was started can be calculated.  Once
started, a timer can be stopped, and once stopped it can be
continued to resume count where it left off.  Finally, the elapsed
time can explicitly be set to some predetermined value.

          timer@Start()
          timer@Stop()
          timer@Continue()
          timer@SetElapsedTime(time)

     The time elapsed since a running timer has been started or
the time elapsed before a running timer was stopped can be easily
found, allowing a task to interactively check a timer for progress.

          time = timer@ElapsedTime()

     Using a timer, it is then possible to schedule events to occur
relative to the start of a timer.  If the timer is stopped, pending
events will automatically be rescheduled until later.  Explicitly
changing the elapsed time will delete past events and reschedule
future events to their new times.  Events are unscheduled in a
similar manner.

          status = timer@ScheduleEvent(time,handler,object)
          status = timer@UnscheduleEvent(time,handler,object)

     Period events are also supported by the timer object, allowing
the caller to specify an offset from which to begin the events, as
well as a period.  These are also unscheduled in a similar manner.

          status = timer@SchedulePeriodic(ofs,period,handler,obj)
          status = timer@UnschedulePeriodic(ofs,perios,handler,obj)


IV. Devices

     One of the most important feature of Moose is the way it deals
with devices, both logical and physical.  Input, output, storage,
and communication device classes are defined by the operating
system, each of which are a descendant of the device object.

     When the system starts up, instances of all devices used by
the system will be created and placed in the device list.  New
device drivers may be added and unused device drivers will be able
to be removed or reconfigured at any time without rebooting the
system.  Note that since device drivers are semi-privileged
software, they can only be manipulated through the use of a
privileged account.  The administrator of devices will also be able
to specify which users or groups of users have access to a
particular device.

A. The Device Object

B. Display Output Devices

     A proper definition of the state of the display output devices
would be an object-oriented GUI similar to X11, only much easier
to use. :-)

C. User Input Devices

     With the standard user input devices, it would be ideal to
allow keyboards, mouses, and other pointer devices to all interact
with the system in a similar manner.  Especially for traversal and
moving about the screen, no difference from the programmers
perspective should be apparent.

D. Mass Storage Devices

     Mass storage devices will include floppy drives, standard IDE
and SCSI hard drives, CD-ROM drives, and many others.

E. Filesystem Devices

     The filesystem device defined by the operating system is
intended to provide a single, standardized interface to a multitude
of filesystems, similar to Unix's Virtual File System (VFS)
interface.  The ability to switch between filesystems quickly and
efficiently is important in this case to correspond to the user
changing a floppy disk or a CD-ROM.  Many types of filesystems will
be directly supported, including the standard Unix file systems,
the Fast File System (FFS), the MS-DOS file system, the Amiga file
system, the Macintosh file system, and possibly many more.  As for
a native filesystem, the Viva File System (VIFS) is an experimental
filesystem which combines high speed and low overhead to make
itself ideal for a multi-user environment than many existing
filesystems.

F. Data Link Devices

     The data link devices defined by the operating system will
correspond to the OSI (Open Systems Interconnection) layer 2,
providing for the reliable transfer of data across a physical link. 
These devices will send blocks of data, or frames, with the
necessary synchronization, error control, and flow control. 
Examples of these devices would be serial and parallel ports.

G. Network Devices

     The network devices defined by the operating system will
correspond to the OSI layer 3, which provides the upper layers with
independence from the data transmission and switching technologies
used to connect systems.  These devices will be responsible for
establishing, maintaining, and terminating connections.  Examples
would include X.25 and the Department of Defense's IP (Internet
Protocol).

H. Transport and Session Devices

     On top of the network devices, the transport and session
devices defined by the operating system will correspond to the OSI
layers 4 and 5, which provides reliable, transparent transfer of
data between end points, end-to-end error recovery and flow
control, as well as the control structure for communication between
applications.  These logical devices will establish, manage, and
terminate connections between cooperating applications.  Examples
would include the Department of Defense's TCP (Transmission Control
Protocol) and the ISO session and TP (Transmission Protocol)
layers.


V. Libraries

     One important system object will be the library, which is
essentially a collection of functions, data, and objects.

     A library may be explicitly loaded into memory so it will be
available when needed, or it may be loaded at the time when it is
referenced.  When a library is loaded into memory it is given a
global data area which can be accesses by all instances of the
library.  A library reference count is created and initialized to
0, or to 1 if the library should stay in memory after it is de-
referenced.  Initialization of the library takes place at this time
also.

     Each time a library is linked to by another library, a new
instance is created.  Local data area specifically for that
instance is allocated and the internal library instance count is
incremented.  When the library instance is no longer needed, the
internal library instance count is decremented.  When the library
instance count reaches zero, the library is removed from memory.

B. Locating a library

     Before linking, a library must first be located.  The internal
list of libraries is searched, followed by a search of the system
path.  If found, an attempt is made to link to the library.  If the
link fails because of an interface mismatch, the search continues. 
This allows multiple libraries with identical names to coexist,
provided their interfaces are significantly different.


C. Dynamic library linking

     Naturally, internal references within a library would be
resolved at compile time, but external references are resolved when
the library is loaded.  When linking to a library, it must first
be located in memory or loaded from disk, resolving its own
references if necessary.  Next, the library itself is asked to
resolve a group of references and check to see that the interface
is correct.

     When a library is created, items declared as external are
placed in the library's interface so they may be accessed by other
libraries.  An interface can be entirely explored using the
library's methods, finding out about data items and types,
functions and the type of each parameter, as well as full
information about objects.  In this way, compilers could extract
the library's interface directly from the library.

     Other methods should be available to provide quick linking
between libraries, automatically checking to make sure if the
interface matches what is expected.  However, minor interface
changes such as new items being added or unused items being removed
are allowed.  The entire interface to a library does not need to
be checked when linking, only those items being linked to.

From dmarer@td2cad.intel.com Wed Feb 10 00:20:12 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17466; Wed, 10 Feb 93 00:20:11 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 10 Feb 93 00:20:11 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 9 Feb 93 15:20:06 -0800
Received: by td2cad (5.57/10.0i); Tue, 9 Feb 93 15:23:30 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01711; Tue, 9 Feb 93 15:30:08 PDT
Date: Tue, 9 Feb 93 15:30:08 PDT
Message-Id: <9302092330.AA01711@tdge15.intel.com>
To: rideau@clipper
Subject: Messages received
Status: OR


Fare',

	Hi!  Just a quick note to let you know I have received messages from
you, 3 to be exact: #10, a response to the new mailing list, and a uuencoded
file containing your language proposal.  I'll read these later this week
(Tuesdays are really busy for me) and get back to you - hopefully you will
already have recieved my specs as well, so I'm looking forward to hearing
your ideas as well.  Take care!

				Dennis

From duzan@udel.edu Wed Feb 10 05:27:06 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24451; Wed, 10 Feb 93 05:27:04 +0100
Return-Path: <duzan@udel.edu>
Received-Date: Wed, 10 Feb 93 05:27:04 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa17119; 9 Feb 93 23:19 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa02278; 10 Feb 93 4:15 GMT
Received: from sol.cis.udel.edu by oin.cis.udel.edu id aa19165;
          10 Feb 93 4:10 GMT
To: Dennis Marer <dmarer@td2cad.intel.com>
Cc: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        duzan@cis.udel.edu, garfield@sra.com, udel.edu!wkuvx1.bitnet!haydedr,
        mckeeveb@sfu.ca, mueller@sc.zib-berlin.de, newlin@ecn.purdue.edu,
        rideau@clipper, winikoff@cs.mu.oz.au, duzan@udel.edu
Subject: Re: Moose specs: Revision 0! 
In-Reply-To: Your message of "Tue, 09 Feb 93 14:53:30 PDT."
             <9302092253.AA01677@tdge15.intel.com> 
Date: Tue, 09 Feb 93 23:10:20 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302100410.aa19165@oin.cis.udel.edu>
Status: OR


   Ok, before going into the specifics, I just want to make a general
comment or two. First of all, there is no mention of a mechanism for
interprocess communication (or, if you prefer, object invocation,)
scheduling, and control. Personally, I prefer a blocking RPC with
lightweight processes (objects.) We should probably have some sort of
shepherd objects to manage groups of objects (like Unix signals.) All
objects should inheirit a set of control methods with default
functions, and the shepherd should have access to them. We also need to
specify some security mechanism  to restrict access to object methods.

=>                     Moose Operating System
=>                     Initial Specifications
=>                       Revision 0, 2/8/93

   We gotta get rid of that name. Dennis seemed to like my suggestion
of 'Midgard', in honor of the mythical serpent that encircled the
Earth.

=>     For example, a program which creates a graphical screen
=>display would be able to use the same code to generate a printout
=>or send a fax just by referencing a different device object.  On
=>the other hand, complex devices could also be given more elaborate
=>interfaces to allow maximum efficiency in accessing hardware.  A
=>certain amount of universal portability might be lost in this case,
=>but the application programmer would be left to choose the
=>appropriate method to meet his or her needs.

   This is a tall order, but ultimately the ideal case. It will take
some very careful and exhaustive design work to pull it off.

=>     As applications grow more and more complex, software designers
=>argue that they require additional resources to support their
=>needs.  Most graphical user interfaces, for example, are quite
=>complicated and require considerable effort on the part of the
=>application programmer to develop software for.  In many ways
=>modern applications do require more resources, but these could be
=>reused and shared among similar applications, significantly
=>reducing the total overhead involved.

   This brings up the question of the general user interface. Do we
support a character-mode interface? I believe that a GUI (graphical
shell) should present object methods to the user, so if we do implement
a character-mode shell, it should have a syntax to reflect the object
method invocation semantics.
   As for the graphics primitives, we should probably start from those
provided by existing graphics accelerator hardware as a minimal set.
The video driver should provide these services and advertise any
additional ones that it can do fast.  However, any objects that use the
additional services should be ready to ignore or emulate (from the
minimal set) them in case the video driver doesn't provide them.

=>                                         The kernel will be divided
=>into the following logical sections: 
=>
=>          General Memory Management
=>          Shared Memory Management
=>          Device Memory Management
=>          Memory Transfer (DMA)
=>          System Clock
            Object Method Invocation/Interprocess Communication

   This might be doable at the device driver level, but it might be
better to put it in the kernel so it can take advantage of hardware-
specific optimizations (e.g. remapping, a la Mach.) It will be an
interesting task to come up with a method that translates well to
different hardware.

=>1. Files
=>
=>>> Anybody have ideas on how files can be implemented as persistent
=>>> objects?  How about memory mapped I/O?

   If page faults and page flush calls can be rerouted to a shepherd
object, it can translate them into file system operations (along
with an allocate/free page call.) This could take care of both (since
they can be viewed as the same thing, anyway.)

=>E. Filesystem Devices

   Operating Systems researchers have gone nuts in creating new
file systems. There should be more than enough to choose from.

=>F. Data Link Devices
=>G. Network Devices
=>H. Transport and Session Devices

   Do we want to provide intra-machine drivers for these? Should
they be a standard IPC mechanism?

   So what language do we write the high-level stuff in? Should it
matter? Can we make it not matter?

   If any of this makes any sense, it is most likely some strange
accident.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From rideau@clipper Wed Feb 10 12:48:57 1993
Received: from galion.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09940; Wed, 10 Feb 93 12:48:52 +0100
From: rideau@clipper (Francois-Rene Rideau)
Return-Path: <rideau@clipper>
Received-Date: Wed, 10 Feb 93 12:48:52 +0100
Message-Id: <9302101148.AA09940@clipper.ens.fr>
Subject: Re: Moose specs: Revision 0!
To: dmarer@td2cad.intel.com (Dennis Marer)
Date: Wed, 10 Feb 93 12:48:51 MET
Cc: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
In-Reply-To: <9302092253.AA01677@tdge15.intel.com>; from "Dennis Marer" at Feb 9, 93 2:53 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

 Hello, happy MOOSERS (or whatever we are) !
 Here are my 


>> 	Here it is.  After many weeks of waiting, I can finally send to you
>> the specifications for the Moose operating system project...revision 0, of
>> course!  Actually, this is more of a revision -72, as it has *tons* of work
>> left to be done on it. [...]
 I agree with revision -72.

>> -------------------------------------------------------------------------------
>> 
>>                      Moose Operating System
>>                      Initial Specifications
>>                        Revision 0, 2/8/93
>> 
>> 
>> I. General Specifications

 Well, I've read your first specifications. I must agree with most of it, as
you explained how to take the best from the intel 386 processor to build an
operating system. But I think your mixing up the 386 implementation with the
system itself.
 If we are to rewrite a system (and moreover, if it is to be ported to many
platforms, including 680x0 based computers), we musn't define it frome
its particular implementation on machines we have mainly because of economical
issues. I think we must define the system from high-level, and then use the
hardware the best we can to implement it; else, we will have a DOS-like
hardware-level system, which we will have either to abandon or to be
compatible with when we will want to improve it.
 DOS is directly programmed with 8088 assmebly language; Unix is programmed
with C; MacOS is OO styled programmed with Pascal. In every case, the system
and the language are thought together, and each adapted to the other.
 It will be the same with MOOSE. Whatever language you choose to program
with (I mean high-level stuff, not the Kernel, which is bound to be mainly
done in assembly), it with shape your system. If you don't choose any
language, the default will be assembly, and you'll be as unportable and
unimprovable as DOS. If you choose C, you won't do better than U*ix. Perhaps
C++ can do better, but it inherits much from C low-level philosophy, and
won't give you a clean high-level OO system.
 What I mean is you must conceive your language (or at least, define how to
use existing language in a clean way) if you want to create a truly new
system (please tell me if I am mistaken). To me, if the system is really to
be the first truely OO based system, object managing should be included in
the kernel itself (see HP28, HP48 calculators, with the which many and I
discovered objects); if you let the user choose to apply or not OO philosophy,
then your system won't really be OO'ed. It's up to us to define what this
language should be like (I have my own ideas), what it should allow, or
forbid (except for device driver programmers). The system will then be
portable at this programming language level; whatever machine will support the
programming language (whether interpreted or compiled, or semi-compiled) and
have a sufficient (little) kernel for I/O will automatically be able to run
the system; I should even suggest a standard intermediate object code for
compiling, which would enable systematic separation of front end and back end
of compilers under the system (but the feasability of this must still be
studied).

 To conclude, I think we mustn't rush doing what would be the kernel of a
system whose features aren't defined yet. Let's define the high-level object
orientation of the system before we write the kernel (more precisely, let's
not write something in the kernel we should have to change completely because
it will not fit high-level system requirements).

		   ,
		Fare
	(rideau@clipper.ens.fr)


From dmarer@td2cad.intel.com Wed Feb 10 19:08:22 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23813; Wed, 10 Feb 93 19:08:20 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 10 Feb 93 19:08:20 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Wed, 10 Feb 93 10:05:18 -0800
Received: by td2cad (5.57/10.0i); Wed, 10 Feb 93 10:08:47 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00324; Wed, 10 Feb 93 10:15:20 PDT
Date: Wed, 10 Feb 93 10:15:20 PDT
Message-Id: <9302101815.AA00324@tdge15.intel.com>
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca,
        mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
Subject: Re:  OSPREY?
Status: OR

> Hi.

Hi!

>> The project I've been working on for the past couple of years is called
> OSPREy.  It stands for Operating System PRojEct.  Perhaps that would be
> a candidate for a name?

I love it!  It's really going to be tough to choose a name...so many options!
I believe this will be the most difficult part of the project... :-)

> Also, I would like to nominate myself to archive all the correspondence
> of the project: email, news postings, etc.

You're welcome to it!

>  Also, I think we should
> get someone to maintain the Specifications document on a "full time"
> basis.  Again, I'll do this if no one else does.

I'll volunteer for that one - since I've already started the specs, plus I
love writing technical docs.  Call me crazy...

> This project offers a unique opportunity.  If this group can become
> organized and maintain a well structured documented project, it has an
> excellent chance of being a major OS contender.

I agree - if not, at least we'll have a great OS to experiment with ourselves.

> I have more ideas on organization if you guys (and gals?) think its
> worthwhile.

Let's hear 'em!

				Dennis

From UKCC.uky.edu!WKUVX1.BITNET!haydedr Thu Feb 11 23:22:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00373; Thu, 11 Feb 93 23:22:24 +0100
Return-Path: <UKCC.uky.edu!WKUVX1.BITNET!haydedr>
Received-Date: Thu, 11 Feb 93 23:22:24 +0100
Received: from ukcc.uky.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 7557; Thu, 11 Feb 93 17:20:04 EST
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 9843;
 Thu, 11 Feb 93 17:20:01 EST
Received: by WKUVX1.BITNET (MX V3.2-alpha) id 7134; Thu, 11 Feb 1993 16:21:00
          CST
Sender: haydedr@WKUVX1.BITNET
Date: Thu, 11 Feb 1993 16:20:58 CST
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
        mueller@sc.ZIB-Berlin.DE, mckeeveb@sfu.ca, garfield@sra.com,
        duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
        ANDREASA@dhhalden.no
Cc: haydedr@WKUVX1.BITNET
Message-Id: <00967FB0.F9C35C60.7134@WKUVX1.BITNET>
Subject: Re: Moose Revision 0!
Status: OR

Howdy Moosers!

I like revision -72 a lot, except for some areas that seem to conflict
somewhat.

First off, there is a mention of how we're aiming to support the 2-8MB
RAM PC market, yet we want multi-user support.  8MB, in my estimation,
seems a little bit small for multiple users.  And, does it seem we
need multi-user support in the PC arena anyway?

Also, should we take into consideration the design of the Motorola chips
before we begin?  I say this because I know the 386 much better than the
680X0s, and I'd like to follow the task and memory management facilites
provided by the 386 as closely as we can; however, if the two
architectures differ significantly in those areas (say, if the 680X0s
don't have any hardware task switching capabilities), then maybe we
shouldn't use the 386 facilities either.  It seems there may have to be
a balance struck between the two architectures (unless we just want to
write it for the 386, then port it later).  My envisionment of Moose is
that, on the PC end anyway, it will be primarily interrupt driven.  I
don't think we can do it that way on the 68000 series.  This is a
fundamental difference, and this alone could cause us to essentially
have to write two completely different kernels which may not support all
the same features between them.  The main question I'd like to ask of
all of us is this: do we expoit the 386 for all it has, or do we look
for a least common denominator between the two architectures and aim
for that?

Also, our OS will not run on anything less than a 386SX, so is there
perhaps a similar cutoff in the Motorola chips.  I mean, is there such
a difference between, say, the 68020 and the 68030, that we should not
develop for anything less than the 68030?

And, about Mac support, isn't the user interface part of a Mac OS in
ROM?

Section E concerns scheduling.  I'd like to see four priority classes.
We could have a time-critical class, then perhaps some type of
class where we could let threads run that need to run before those of
a user class, such as server maintenance threads and the like, then of
course a user class, and finally a daemon or idle thread class.  Within
each priority class we'd have just a simple round-robin dispatching.
Sound like it will fly?

Anyway, I've talked on a low level here, but I think there a some very
low-level questions such as these that need to be considered early on,
just as those high-level design considerations.

Thanks,
Ross Hayden
haydedr@wkuvx1.bitnet

From duzan@udel.edu Fri Feb 12 00:06:18 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01646; Fri, 12 Feb 93 00:06:17 +0100
Return-Path: <duzan@udel.edu>
Received-Date: Fri, 12 Feb 93 00:06:17 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa26251;
          11 Feb 93 18:04 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa29374;
          11 Feb 93 22:59 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa09511;
          11 Feb 93 22:55 GMT
To: Francois-Rene Rideau <rideau@clipper>
Cc: Dennis Marer <dmarer@td2cad.intel.com>, ANDREASA@dhhalden.no,
        csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu, duzan@cis.udel.edu,
        garfield@sra.com, udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca,
        mueller@sc.zib-berlin.de, newlin@ecn.purdue.edu, winikoff@cs.mu.oz.au
Subject: Re: Moose specs: Revision 0! 
In-Reply-To: Your message of "Wed, 10 Feb 93 12:48:51 +0700."
             <9302101148.AA09940@clipper.ens.fr> 
Date: Thu, 11 Feb 93 17:55:03 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302112255.aa09511@gloin.cis.udel.edu>
Status: OR

=> Well, I've read your first specifications. I must agree with most of it, as
=>you explained how to take the best from the intel 386 processor to build an
=>operating system. But I think your mixing up the 386 implementation with the
=>system itself.
=> If we are to rewrite a system (and moreover, if it is to be ported to many
=>platforms, including 680x0 based computers), we musn't define it frome
=>its particular implementation on machines we have mainly because of economica
l
=>issues. I think we must define the system from high-level, and then use the
=>hardware the best we can to implement it; else, we will have a DOS-like
=>hardware-level system, which we will have either to abandon or to be
=>compatible with when we will want to improve it.

   I couldn't agree more. If portability is a goal, then we can't build
the design around the features of a particular architecture. We need to
look at concepts first and link them to methodologies later, though we
would so well to keep in mind the capabilities of modern architectures
in general. But then, you can hardly blame Dennis. After all, he works
for Intel. :-)

=> DOS is directly programmed with 8088 assmebly language; Unix is programmed
=>with C; MacOS is OO styled programmed with Pascal. In every case, the system
=>and the language are thought together, and each adapted to the other.
=> It will be the same with MOOSE. Whatever language you choose to program
=>with (I mean high-level stuff, not the Kernel, which is bound to be mainly
=>done in assembly), it with shape your system. If you don't choose any
=>language, the default will be assembly, and you'll be as unportable and
=>unimprovable as DOS. If you choose C, you won't do better than U*ix. Perhaps
=>C++ can do better, but it inherits much from C low-level philosophy, and
=>won't give you a clean high-level OO system.

   True, but what can we do? If we can get a compiler for a good
object-oriented language that will compile on a number of different
machine, that would be great, but not, I think, too likely. I suppose
we could try to get a number of language/compiler design people to whip
up a language and GCC front-end for us to use if we really wanted to,
or maybe use an existing language and develop a GCC front-end for it. I
hate to say it, but C++ looks like the way to go for now. As long as we
specify the interfaces and abide by them, we should be able to make it
language-independant. It might be a good idea to develop a Smalltalk
interface in parallel.

=> To conclude, I think we mustn't rush doing what would be the kernel of a
=>system whose features aren't defined yet. Let's define the high-level object
=>orientation of the system before we write the kernel (more precisely, let's
=>not write something in the kernel we should have to change completely because
=>it will not fit high-level system requirements).

   Agreed. And likewise, let's not design high-level facilities that
are natural on one platform but aren't easily implemented on others.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From duzan@udel.edu Fri Feb 12 00:58:40 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02970; Fri, 12 Feb 93 00:58:39 +0100
Return-Path: <duzan@udel.edu>
Received-Date: Fri, 12 Feb 93 00:58:39 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa28527;
          11 Feb 93 18:54 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa29902;
          11 Feb 93 23:51 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa10992;
          11 Feb 93 23:49 GMT
To: "Dr. Hayden" <udel.edu!wkuvx1.bitnet!haydedr>
Cc: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
        mueller@sc.zib-berlin.de, mckeeveb@sfu.ca, garfield@sra.com,
        duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
        ANDREASA@dhhalden.no
Subject: Re: Moose Revision 0! 
In-Reply-To: Your message of "Thu, 11 Feb 93 16:20:58 CST."
             <00967FB0.F9C35C60.7134@WKUVX1.BITNET> 
Date: Thu, 11 Feb 93 18:48:40 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302112349.aa10992@thorin.cis.udel.edu>
Status: OR

=>First off, there is a mention of how we're aiming to support the 2-8MB
=>RAM PC market, yet we want multi-user support.  8MB, in my estimation,
=>seems a little bit small for multiple users.  And, does it seem we
=>need multi-user support in the PC arena anyway?

   Good question. I think it goes without saying that we need some
protection mechanism, but how far should we go, and what should the
mechanism be? Access Rights Lists? Capabilities? User/Group/World a la
Unix? A simple User vs. Supervisor mechanism? Capabilties seem to make
sense in an object-oriented system, but they may be more powerful than
we want.
   Personally, I am of the opinion that any system that is going to be
on a network should have some security, especially if it is going to
provide network services. Ideally, an object system should extend
through a network to access objects on another system, and that would
require security. This is obviously not a feature for the base system,
but it should be possible to add it later.

=>Also, should we take into consideration the design of the Motorola chips
=>before we begin?  

   I think I covered this in an earlier note.

=>Also, our OS will not run on anything less than a 386SX, so is there
=>perhaps a similar cutoff in the Motorola chips.  I mean, is there such
=>a difference between, say, the 68020 and the 68030, that we should not
=>develop for anything less than the 68030?

   This is a good question. Does anyone have a suggestion for a
reference for the 680x0 series?After the 80386 and the 680x0, we can
start on the Sparc, RS/6000, MIPS, Alpha, and the Cray. :-)

=>And, about Mac support, isn't the user interface part of a Mac OS in
=>ROM?

   I imagine there is a way to bypass the ROM routines.

=>Section E concerns scheduling.  I'd like to see four priority classes.
=>We could have a time-critical class, then perhaps some type of
=>class where we could let threads run that need to run before those of
=>a user class, such as server maintenance threads and the like, then of
=>course a user class, and finally a daemon or idle thread class.  Within
=>each priority class we'd have just a simple round-robin dispatching.
=>Sound like it will fly?

   Sounds pretty straightforward to me.

=>Anyway, I've talked on a low level here, but I think there a some very
=>low-level questions such as these that need to be considered early on,
=>just as those high-level design considerations.

   That's what we're here for.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From UKCC.uky.edu!WKUVX1.BITNET!haydedr Fri Feb 12 20:43:02 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16118; Fri, 12 Feb 93 20:43:00 +0100
Return-Path: <UKCC.uky.edu!WKUVX1.BITNET!haydedr>
Received-Date: Fri, 12 Feb 93 20:43:00 +0100
Received: from ukcc.uky.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 3099; Fri, 12 Feb 93 14:07:13 EST
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 9597;
 Fri, 12 Feb 93 14:07:12 EST
Received: by WKUVX1.BITNET (MX V3.2-alpha) id 10957; Fri, 12 Feb 1993 13:09:38
          CST
Sender: haydedr@WKUVX1.BITNET
Date: Fri, 12 Feb 1993 13:09:33 CST
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
        mueller@sc.ZIB-Berlin.DE, mckeeveb@sfu.ca, garfield@sra.com,
        duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
        ANDREASA@dhhalden.no
Cc: haydedr@WKUVX1.BITNET
Message-Id: <0096805F.6696B680.10957@WKUVX1.BITNET>
Subject: Re: Moose Revision 0!!
Status: OR

From:   MX%"newlin@ecn.purdue.edu" 12-FEB-1993 10:43:52.55
To:     HAYDEDR
CC:
Subj:   Re: Moose Revision 0!

Return-Path: <@VM.CC.PURDUE.EDU:newlin@ecn.purdue.edu>
Received: from PURCCVM.BITNET (MAILER) by WKUVX1 (MX V3.2-alpha) with BSMTP;
          Fri, 12 Feb 1993 10:43:17 CST
Received: from PURCCVM by PURCCVM.BITNET (Mailer R2.08) with BSMTP id 4853;
          Fri, 12 Feb 93 11:31:20 EST
Received: from lucky.ecn.purdue.edu by VM.CC.PURDUE.EDU (IBM VM SMTP V2R1) with
          TCP; Fri, 12 Feb 93 11:31:18 EST
Received: by lucky.ecn.purdue.edu (5.65/1.32jrs) id AA22481; Fri, 12 Feb 93
          11:31:50 -0500
From: <newlin@ecn.purdue.edu>
Message-ID: <9302121631.AA22481@lucky.ecn.purdue.edu>
Subject: Re: Moose Revision 0!
To: <haydedr@WKUVX1.BITNET>
Date: Fri, 12 Feb 93 11:31:50 EST
In-Reply-To: <00967FB0.F9C35C60.7134@WKUVX1.BITNET>; from "Dr. Hayden" at Feb
    11, 93 4:20 pm
X-Mailer: ELM [version 2.3 PL11]

>Also, our OS will not run on anything less than a 386SX, so is there
>perhaps a similar cutoff in the Motorola chips.  I mean, is there such
>a difference between, say, the 68020 and the 68030, that we should not
>develop for anything less than the 68030?

  The 68030 is only different from the '020 in that it has an
  MMU on board, where the '020 needs external support.

>And, about Mac support, isn't the user interface part of a Mac OS in
>ROM?

  Yup.  And parts of the ROM are not re-entrant.  (ICK!)

-John Newlin
 newlin@ecn.purdue.edu

PS- I don't have an alias set up for the list yet, could you forward this?


From dmarer@td2cad.intel.com Fri Feb 12 22:33:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19028; Fri, 12 Feb 93 22:33:00 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 12 Feb 93 22:33:00 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Fri, 12 Feb 93 13:11:28 -0800
Received: by td2cad (5.57/10.0i); Fri, 12 Feb 93 13:14:47 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00405; Fri, 12 Feb 93 13:21:25 PDT
Date: Fri, 12 Feb 93 13:21:25 PDT
Message-Id: <9302122121.AA00405@tdge15.intel.com>
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca,
        mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
Subject: (forwarded) RE: Moose revision 0!
Status: OR

----- Begin Included Message -----

From: <newlin@ecn.purdue.edu>
Message-ID: <9302121631.AA22481@lucky.ecn.purdue.edu>
Subject: Re: Moose Revision 0!
To: <haydedr@WKUVX1.BITNET>
Date: Fri, 12 Feb 93 11:31:50 EST

>Also, our OS will not run on anything less than a 386SX, so is there
>perhaps a similar cutoff in the Motorola chips.  I mean, is there such
>a difference between, say, the 68020 and the 68030, that we should not
>develop for anything less than the 68030?

  The 68030 is only different from the '020 in that it has an
  MMU on board, where the '020 needs external support.

>And, about Mac support, isn't the user interface part of a Mac OS in
>ROM?

  Yup.  And parts of the ROM are not re-entrant.  (ICK!)

-John Newlin
 newlin@ecn.purdue.edu

PS- I don't have an alias set up for the list yet, could you forward this?


----- End Included Message -----


From cis.udel.edu!udel.edu!duzan Sat Feb 13 02:19:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24314; Sat, 13 Feb 93 02:19:00 +0100
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Sat, 13 Feb 93 02:19:00 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id ab06130;
          12 Feb 93 20:12 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa15978; 13 Feb 93 1:11 GMT
Received: from sol.cis.udel.edu by daffy.cis.udel.edu id aa10808;
          13 Feb 93 1:10 GMT
To: Dan Odom <danodom@matt.ksu.ksu.edu>
Cc: Winikoff <winikoff@cs.mu.oz.au>, Rideau <rideau@clipper>,
        Newlin <newlin@ecn.purdue.edu>, Mueller <mueller@sc.zib-berlin.de>,
        Mckeeveb <mckeeveb@sfu.ca>, Garfield <garfield@sra.com>,
        Duzan <duzan@cis.udel.edu>, Dmarer <dmarer@td2cad.intel.com>,
        Andreasa <ANDREASA@dhhalden.no>
Subject: Re: Moose (You guys...) 
In-Reply-To: Your message of "Fri, 12 Feb 93 17:46:31 CST."
             <9302122346.AA02651@matt.ksu.ksu.edu> 
Date: Fri, 12 Feb 93 20:09:51 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302130110.aa10808@daffy.cis.udel.edu>
Status: OR

=>
=>1)  Device Drivers:  We need to have user-installable device drivers.
=>      I personally prefer the Unix style of device driver, but the MS-DOS
=>      style isn't bad (it's just not as good, IMHO).  This way, we don't
=>      have to include ANY I/O in the kernel; we can have a device
=>      named 'STDOUT' or 'TTY' or 'CON', and that device will
=>      represent the screen.  Our C RTL can then send output from
=>      printf (), etc. to that device.

   We will need some basic device support for bootstrapping, but beyond
that I agree.

=>2)  Rather than saying 'This OS is a GUI!', I think that we should allow
=>      the user to write his/her own shell.  I personally would like
=>      a csh-ish interface; I could add my own.  One of my friends likes
=>      the X interface; he could add his own X-like interface.

   
   Anyone with enough spare time can build their own interface to
practically any system (with the possible exception of MacOS,) so I
don't see why we should be any different. The question is, what do WE
build. If we have an object-oriented system then we should show it off
with object-oriented shells and GUI.

=>3)  Making the kernel object-oriented would be a real pain in the rear,
      and also increase the amount of required memory.  I say that
=>      we do a traditional kernel, and then write OO shells for it in
=>      C++ and ObjectPascal.  That way, we'd still be able to code like:
=>
=>         class MyInputDevice : public GenericInputDevice
=>           {
=>              ...
=>           }
=>
=>      but the kernel could be kept simple.

   I agree that the basic kernel itself needn't be object-oriented, as
long as it has an object-oriented interface and support for system and
user objects.

=>4)  We need to spend quite a bit of time on the high-level specifications
=>      before we move on to the low-level stuff.  Let's not worry about
=>      implementation stuff until we've got the abstract stuff down.

   I think we've reached a concensus on this point.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From rideau Sat Feb 13 13:06:26 1993
Subject: Re: Project Name
To: dmarer@td2cad.intel.com (Dennis Marer)
Date: Sat, 13 Feb 93 13:06:26 MET
Cc: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
	dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
	garfield@sra.com, haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca,
	mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu, rideau@clipper,
	winikoff@cs.mu.oz.au
In-Reply-To: <9302101815.AA00324@tdge15.intel.com>; from "Dennis Marer" at Feb 10, 93 10:15 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR


From rideau Sat Feb 13 13:21:51 1993
Subject: Re: Project Name
To: rideau@galion.ens.fr (rideau)
Date: Sat, 13 Feb 93 13:21:51 MET
Cc: dmarer@td2cad.intel.com, ANDREASA@dhhalden.no, csjjlay@mtsu.edu,
	danodom@matt.ksu.ksu.edu, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
	garfield@sra.com, haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca,
	mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu, rideau@clipper,
	winikoff@cs.mu.oz.au
In-Reply-To: <no.id>; from "rideau" at Feb 13, 93 1:06 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(I've mixed up my mail, please excuse for previous null mail)

Dennis quotes an anonymous friend:
>> > Hi.
>> Hi!
Lo !

>> > The project I've been working on for the past couple of years is called
>> > OSPREy.  It stands for Operating System PRojEct.  Perhaps that would be
>> > a candidate for a name?
>> 
>> I love it!  It's really going to be tough to choose a name...so many options!>> I believe this will be the most difficult part of the project... :-)

Well... I think we should concentrate on the rest of it. When we have advanced
in the program, it should certainly be easier to find a name, corresponding to
its features.

>> > Also, I would like to nominate myself to archive all the correspondence
>> > of the project: email, news postings, etc.
>> You're welcome to it!

Hey, Dennis, why don't name the happy volonteer ? Or should it be a secret !?

>> >  Also, I think we should
>> > get someone to maintain the Specifications document on a "full time"
>> > basis.  Again, I'll do this if no one else does.
>> 
>> I'll volunteer for that one - since I've already started the specs, plus I
>> love writing technical docs.  Call me crazy...



>> > This project offers a unique opportunity.  If this group can become
>> > organized and maintain a well structured documented project, it has an
>> > excellent chance of being a major OS contender.
>> 
>> I agree - if not, at least we'll have a great OS to experiment with ourselves.
>> 
>> > I have more ideas on organization if you guys (and gals?) think its
>> > worthwhile.
>> 
>> Let's hear 'em!
>> 
>>                              Dennis

Then Gary D. Duzan <duzan@udel.edu> says:

>   Ok, we've had on-and-off discussions on a name for the project. I'd
> like to take a quick poll to see which of several recently proposed
> names you prefer. This will in no way be a binding vote (I think the
> net-term is Straw Poll,) but if everyone wants the same thing, then we+
> should probably go with it.
>   Please reply to me (duzan@cis.udel.edu) with your preference:
>
>       MOOSE
>       OSPREy
>       Midgard
>        Other: Please Specify
Well, why not
   the OOPS (for example OO Programming (Programmed ?) System
or the BOOST: Better Object Operating SysTem
or the MTOIS (write "empty - O - 1 - 2") multitasked object integrated system
or the NT-EPT (one letter after MS-DOS)
or the VOJY (idem for Unix) ? = Virtual Object JoY or anything else.
if you want, we can call it GOD, OBJECT, NEW, BEST, ...  if you want, you can.

>   I'll post a summary of the results at the end of next week (Feb 19.)

>   While I'm here, we might as well discuss decision-making for the
> project. I'd say that issues should be decided by 2/3 majority
> concensus whenever possible. When impossible, it might be expedient
> to have Dennis or someone else in the position to make arbitrary
> dicisions from among the more popular views. We will also need
> someone to keep track of the design decisions and compile them into a
> design document for the group to follow. The alternative is endless
> debate, an unclear design, and little (if any) actual group code.

Here is a very important issue, indeed !
Hey, there why not concentrate on the thing, not its name. When it's well
begun and we see better what it is, we'll be able to find a proper name
which will reflect the content of it; meanwhile, let's continue call it
as we want.

               ,
            Fare

From rideau Sat Feb 13 15:29:16 1993
Subject: Re: Moose Revision -72
To: haydedr@WKUVX1.BITNET (Dr. Hayden)
Date: Sat, 13 Feb 93 15:29:16 MET
Cc: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
	mueller@sc.ZIB-Berlin.DE, mckeeveb@sfu.ca, garfield@sra.com,
	duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
	ANDREASA@dhhalden.no, haydedr@WKUVX1.BITNET
In-Reply-To: <00967FB0.F9C35C60.7134@WKUVX1.BITNET>; from "Dr. Hayden" at Feb 11, 93 4:20 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Greetings, Happy Moosers, from the frenchman who wants a new language.

[...]
Here is my reply to the latest news I received from MOOSE (it is a bit long).

"Dr. Hayden" <haydedr@WKUVX1.BITNET> sayz:
> [...]
>  First off, there is a mention of how we're aiming to support the 2-8MB
> RAM PC market, yet we want multi-user support.  8MB, in my estimation,
> seems a little bit small for multiple users.  And, does it seem we
> need multi-user support in the PC arena anyway?

 I agree that we need support multi-user as soon as possible; but we don't
need 8MB for multiple users if they share libraries. Assuming multiple users
essentially use the same programs and features, only user-specific data must
be present twice in (virtual) memory which isn't much in "normal" use.


> Also, should we take into consideration the design of the Motorola chips
> before we begin?  I say this because I know the 386 much better than the
> 680X0s, and I'd like to follow the task and memory management facilites
> provided by the 386 as closely as we can; however, if the two
> architectures differ significantly in those areas (say, if the 680X0s
> don't have any hardware task switching capabilities), then maybe we
> shouldn't use the 386 facilities either.  It seems there may have to be
> a balance struck between the two architectures (unless we just want to
> write it for the 386, then port it later).  My envisionment of Moose is
> that, on the PC end anyway, it will be primarily interrupt driven.  I
> don't think we can do it that way on the 68000 series.  This is a
> fundamental difference, and this alone could cause us to essentially
> have to write two completely different kernels which may not support all
> the same features between them.  The main question I'd like to ask of
> all of us is this: do we expoit the 386 for all it has, or do we look
> for a least common denominator between the two architectures and aim
> for that?
 The problem is very important, and I think everyone of us must have it
in mind; however, I propose another solution: after having agreed on
high-level features (accessible in our standard language; C++ as it seems
to be going to be; something new I'd like), we implement it the best we can
on each machine, using the full power of the processor. But particularities
of processors should NOT be used in the HIGH LEVEL standard.


> Also, our OS will not run on anything less than a 386SX, so is there
> perhaps a similar cutoff in the Motorola chips.  I mean, is there such
> a difference between, say, the 68020 and the 68030, that we should not
> develop for anything less than the 68030?
> And, about Mac support, isn't the user interface part of a Mac OS in
> ROM?

 If we abide by the "standard is high level" principle that I am supporting,
there can be different kernels running on different 680x0's; there can even
be someday a kernel for the 8088 if someone is fool enough to write it. Of
course, we should first concentrate on 386 and 680x0 (x=0,2,3 ?) kernels. As
for Mac support, or more generally support under an existing OS, the only
problem at running Moose (or whatever we call it) as a sub-OS should be
speed, and, firstly this will save development time for early versions, and
finally, once one have seen it run even slow, it will be so good he will want
to run it as main system (or so he should).

> Section E concerns scheduling.  I'd like to see four priority classes.e
> We could have a time-critical class, then perhaps some type of
> class where we could let threads run that need to run before those of
> a user class, such as server maintenance threads and the like, then of
> course a user class, and finally a daemon or idle thread class.  Within
> each priority class we'd have just a simple round-robin dispatching.
> Sound like it will fly?
 HEY, WHAT DO YOU THINK ABOUT THIS:
 My personal opinion is the most important and difficult classes to define
will be the executable code classes. What is bad at ancient languages is
that they each support only one aspect of executable code (imperative
infix, prefix or post-fix notation code as in C, Pascal, or FORTH; functional
notation as in LISP or ML, etc; backtracking as in Prolog; ... ); moreover,
they always create a big gap between code and data, whereas one would like
to do with code the same he can do with data, and vice versa (in C, you
cannot compile small bits of code at execution; neither can you move or
code/decode chunks of code; or analyse it... ) ; finally, very few languages
understand massive multithreading where virtually every item has one or more
threads running or waiting for it. In the other way, data types don't for
the moment include exceptions as is done for code in C++ or CAML, etc; they
don't have as powerful virtual capabilities as methods in OO languages, etc.
 The OOing Kernel should include all these features. To me, it is the most
important in the project; if we just wanted 32 bit multitasking I/O, we else
would have chosen using linux, plus X-Windows for the GUI if needed, or IBM's
half-OS. What can be new is this and just this: standard OOion in the Kernel
(to me, the Kernel isn't the IO routines; just the class manager, including
executable classes and thus multithreading; all other parts of the OS must be
clear with respect to object managing).


> Anyway, I've talked on a low level here, but I think there a some very
> low-level questions such as these that need to be considered early on,
> just as those high-level design considerations.
>
Both low-level and high-level questions must be thought with the other one
in mind. For now, we can define general low-level directives, but we mustn't
start implementing a function without having defined its high-level
features and access.

> Thanks,
> Ross Hayden
> haydedr@wkuvx1.bitnet



Then Gary D. Duzan <duzan@udel.edu> writes (quoting me):

> [...]
>> DOS is directly programmed with 8088 assmebly language; Unix is programmed
>> with C; MacOS is OO styled programmed with Pascal. In every case, the system
>> and the language are thought together, and each adapted to the other.
>>  It will be the same with MOOSE. Whatever language you choose to program
>> with (I mean high-level stuff, not the Kernel, which is bound to be mainly
>> done in assembly), it with shape your system. If you don't choose any
>> language, the default will be assembly, and you'll be as unportable and
>> unimprovable as DOS. If you choose C, you won't do better than U*ix. Perhaps
>> C++ can do better, but it inherits much from C low-level philosophy, and
>> won't give you a clean high-level OO system.
> 
>    True, but what can we do? If we can get a compiler for a good
> object-oriented language that will compile on a number of different
> machine, that would be great, but not, I think, too likely. I suppose
> we could try to get a number of language/compiler design people to whip
> up a language and GCC front-end for us to use if we really wanted to,
> or maybe use an existing language and develop a GCC front-end for it. I
> hate to say it, but C++ looks like the way to go for now. As long as we
> specify the interfaces and abide by them, we should be able to make it
> language-independant. It might be a good idea to develop a Smalltalk
> interface in parallel.

What I propose is making a front end, and have the produced intermediate code
unoptimizedly compiled, or interpreted, or sent to GCC (if we find out how to
do it), or to make a compiler from our high-level language to C (the compiler
will include itself calls to the kernel for multithreading). What would be great
for a later version is that intermediate code be standard itself, so that
recompile of portable applications is quicker and safer, and that the Kernel is
more language independent (even if their is a currently privileged high-level
language); moreover, having a new language will only demand a new front end; and
separate teams can work over front and back ends, meeting only to enhance
intermediate code. Intermediate code must then be a virtual standard, with for
only upward compatibility requirement that an earlier version be compiled to a
later in a time proportional to the size.


Now, Gary quotes Dennis' first specs
>>      As applications grow more and more complex, software designers
>> argue that they require additional resources to support their
>> needs.  Most graphical user interfaces, for example, are quite
>> complicated and require considerable effort on the part of the
>> application programmer to develop software for.  In many ways
>> modern applications do require more resources, but these could be
>> reused and shared among similar applications, significantly
>> reducing the total overhead involved.
>
>   This brings up the question of the general user interface. Do we
> support a character-mode interface? I believe that a GUI (graphical
> shell) should present object methods to the user, so if we do implement
> a character-mode shell, it should have a syntax to reflect the object
> method invocation semantics.
 I believe much of the work can be done in generic text or graphic windozes.
Text is still useful: quick, and available on old terminals.

>    As for the graphics primitives, we should probably start from those
> provided by existing graphics accelerator hardware as a minimal set.
> The video driver should provide these services and advertise any
> additional ones that it can do fast.  However, any objects that use the
> additional services should be ready to ignore or emulate (from the
> minimal set) them in case the video driver doesn't provide them.
No ! The video driver should emulate itself what the hardware does not include;
else what would a video driver be for ?

>>                                          The kernel will be divided
>> into the following logical sections: 
>> 
>>           General Memory Management
>>           Shared Memory Management
>>           Device Memory Management
>>           Memory Transfer (DMA)
>>           System Clock
>>           Object Method Invocation/Interprocess Communication
Hey ! Where did you put the OO Management !? and the multithreading stuff !?
It isn't a small accessory device; it's the central point of what should be
new and great in the OS !

>> F. Data Link Devices
>> G. Network Devices
>> H. Transport and Session Devices
>
>   Do we want to provide intra-machine drivers for these? Should
> they be a standard IPC mechanism?
Of course there should be ! We must have a high-level protocol for IPC;
up to the kernel makers to implement it on each machine.

>   So what language do we write the high-level stuff in? Should it
> matter? Can we make it not matter?
 The greater part of the OS is written in high-level language, the more portable
the OS will be. So we must choose such a language, and choose it well.
 The easiest solution is C++, but C++ is too low-level; so it's ok for Kernel
stuff but it won't fit for really high-level programming the OS.



	 ,
      Fare

(soon to come my high-level specs)

From rideau@clipper Sat Feb 13 13:22:02 1993
Received: from galion.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15361; Sat, 13 Feb 93 13:21:52 +0100
From: rideau@clipper (Francois-Rene Rideau)
Return-Path: <rideau@clipper>
Received-Date: Sat, 13 Feb 93 13:21:52 +0100
Message-Id: <9302131221.AA15361@clipper.ens.fr>
Subject: Re: Project Name
To: rideau@galion.ens.fr (rideau)
Date: Sat, 13 Feb 93 13:21:52 MET
Cc: dmarer@td2cad.intel.com, ANDREASA@dhhalden.no, csjjlay@mtsu.edu,
        danodom@matt.ksu.ksu.edu, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca,
        mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
In-Reply-To: <no.id>; from "rideau" at Feb 13, 93 1:06 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(I've mixed up my mail, please excuse for previous null mail)

Dennis quotes an anonymous friend:
>> > Hi.
>> Hi!
Lo !

>> > The project I've been working on for the past couple of years is called
>> > OSPREy.  It stands for Operating System PRojEct.  Perhaps that would be
>> > a candidate for a name?
>> 
>> I love it!  It's really going to be tough to choose a name...so many options!>> I believe this will be the most difficult part of the project... :-)

Well... I think we should concentrate on the rest of it. When we have advanced
in the program, it should certainly be easier to find a name, corresponding to
its features.

>> > Also, I would like to nominate myself to archive all the correspondence
>> > of the project: email, news postings, etc.
>> You're welcome to it!

Hey, Dennis, why don't name the happy volonteer ? Or should it be a secret !?

>> >  Also, I think we should
>> > get someone to maintain the Specifications document on a "full time"
>> > basis.  Again, I'll do this if no one else does.
>> 
>> I'll volunteer for that one - since I've already started the specs, plus I
>> love writing technical docs.  Call me crazy...



>> > This project offers a unique opportunity.  If this group can become
>> > organized and maintain a well structured documented project, it has an
>> > excellent chance of being a major OS contender.
>> 
>> I agree - if not, at least we'll have a great OS to experiment with ourselves.
>> 
>> > I have more ideas on organization if you guys (and gals?) think its
>> > worthwhile.
>> 
>> Let's hear 'em!
>> 
>>                              Dennis

Then Gary D. Duzan <duzan@udel.edu> says:

>   Ok, we've had on-and-off discussions on a name for the project. I'd
> like to take a quick poll to see which of several recently proposed
> names you prefer. This will in no way be a binding vote (I think the
> net-term is Straw Poll,) but if everyone wants the same thing, then we+
> should probably go with it.
>   Please reply to me (duzan@cis.udel.edu) with your preference:
>
>       MOOSE
>       OSPREy
>       Midgard
>        Other: Please Specify
Well, why not
   the OOPS (for example OO Programming (Programmed ?) System
or the BOOST: Better Object Operating SysTem
or the MTOIS (write "empty - O - 1 - 2") multitasked object integrated system
or the NT-EPT (one letter after MS-DOS)
or the VOJY (idem for Unix) ? = Virtual Object JoY or anything else.
if you want, we can call it GOD, OBJECT, NEW, BEST, ...  if you want, you can.

>   I'll post a summary of the results at the end of next week (Feb 19.)

>   While I'm here, we might as well discuss decision-making for the
> project. I'd say that issues should be decided by 2/3 majority
> concensus whenever possible. When impossible, it might be expedient
> to have Dennis or someone else in the position to make arbitrary
> dicisions from among the more popular views. We will also need
> someone to keep track of the design decisions and compile them into a
> design document for the group to follow. The alternative is endless
> debate, an unclear design, and little (if any) actual group code.

Here is a very important issue, indeed !
Hey, there why not concentrate on the thing, not its name. When it's well
begun and we see better what it is, we'll be able to find a proper name
which will reflect the content of it; meanwhile, let's continue call it
as we want.

               ,
            Fare

From csjjlay@knuth.mtsu.edu Sat Feb 13 18:27:22 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22854; Sat, 13 Feb 93 18:27:20 +0100
Return-Path: <csjjlay@knuth.mtsu.edu>
Received-Date: Sat, 13 Feb 93 18:27:20 +0100
Received: from knuth.mtsu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by knuth.mtsu.edu (Smail3.1.28.1 #6)
	id m0nNQfV-000cwAC; Sat, 13 Feb 93 11:28 CST
Message-Id: <m0nNQfV-000cwAC@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: Re: Project Name
To: rideau@clipper (Francois-Rene Rideau)
Date: Sat, 13 Feb 1993 11:28:44 -0600 (CST)
Cc: csjjlay@knuth.mtsu.edu (JJ Lay)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 2945      
Status: OR

Francois-Rene Rideau said:
: >> > The project I've been working on for the past couple of years is called
: >> > OSPREy.  It stands for Operating System PRojEct.  Perhaps that would be
: >> > a candidate for a name?
: >> 
: >> I love it!  It's really going to be tough to choose a name...so many options!>> I believe this will be the most difficult part of the project... :-)
: 
: Well... I think we should concentrate on the rest of it. When we have advanced
: in the program, it should certainly be easier to find a name, corresponding to
: its features.

Point taken.  What if the nature of the project changes and the name we
choose absolutely doesn't fit???  Whatever name comes up in the Feb 19th
result can be the unofficial name for now.
  
: >> > Also, I would like to nominate myself to archive all the correspondence
: >> > of the project: email, news postings, etc.
: >> You're welcome to it!
: 
: Hey, Dennis, why don't name the happy volonteer ? Or should it be a secret !?

Well, my name is JJ Lay and it isn't a big secret, I don't think.  See
below for my email address.
  
: >> > I have more ideas on organization if you guys (and gals?) think its
: >> > worthwhile.
: >> 
: >> Let's hear 'em!

Well, I sent them to Dennis and haven't heard from anyone else!  My
alias is obviously not working correctly.  WOuld you mind forwarding the
message to everyone (including me I didn't even receive a copy).

: >   While I'm here, we might as well discuss decision-making for the
: > project. I'd say that issues should be decided by 2/3 majority
: > concensus whenever possible. When impossible, it might be expedient
: > to have Dennis or someone else in the position to make arbitrary
: > dicisions from among the more popular views. We will also need
: > someone to keep track of the design decisions and compile them into a
: > design document for the group to follow. The alternative is endless
: > debate, an unclear design, and little (if any) actual group code.
: 
: Here is a very important issue, indeed !
: Hey, there why not concentrate on the thing, not its name. When it's well
: begun and we see better what it is, we'll be able to find a proper name
: which will reflect the content of it; meanwhile, let's continue call it
: as we want.

							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team


From ANDREASA@sofus.dhhalden.no Sun Feb 14 16:26:51 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28145; Sun, 14 Feb 93 16:26:50 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Sun, 14 Feb 93 16:26:50 +0100
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <25299-0@fenris.dhhalden.no>; Sun, 14 Feb 1993 16:24:04 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930214162331.352; 14 Feb 93 16:23:47 -100
Message-Id: <MAILQUEUE-101.930214162321.320@sofus.dhhalden.no>
To: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.ZIB-Berlin.DE, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 14 Feb 93 16:23:22 +0100
Subject: MOOSE
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Project name..., well I'm quite satisfied with MOOSE at the moment, and I
don't think it is very important to find another name for it at the
moment. That is not, should I say, the crucial part of the development.
Let's be creative, a new name isn't.

I suppose most of you have read the rev. -72 a couple of times by now.

About the language question; Not! I say, it isn't a question. There is no
need for a new language, tell me what reasons there are to build one.
Are there no languages that can fill our needs?
I did some testing the either day. I wrote some asm. code to do a specific
task, then I did the same thing with some C code. I used Borland C(++) and
compiled via assembler. Guess if I was supprised Borland generated better
assembler than me. I have heard rumors that compilers generated better code
than assembler programmers, but I never belived it could be true. In
addition the compiler made use of 386 specific commands in a way I had never
thought of. I'm no assembler guru, have never been, and will probably never
become, but that my code were so much larger....
Listen to what I say, don't overestimate ourselfes. The borland compiler
has had a couple of years on it's neck now, and it doesn't generate the
fastest code either, but anyway it outcoded my code. (I havn't done any
asm.programming for over a year now so...)
Let us use a compiler that has _few_ bugs(!!!), that generates clever code,
and has support for the 386. If you still belive that you are coding much
better than a compiler, compile via assembler, and fix the few unclever
code-parts that has been generated.
That is my advise.


About part D. of the rev. -72, "Design principles".
The OS should, in addition to what Dennis mentions, keep track of the
resources used by any application, so that the system will be able
to unload the resources that are left after an application crash, and thereby
save resources and make the system more fool proof.


About part  II, the Kernel - A. General Memory Management
Dennis mentions something about compiler dependance and memory allocation.
If some of you have been programming Windows, you are familiar with .def
files, definition files. Each program source code has got one of these.
They tells the windows shell what code parts that should be swapped to
disk first.
Imagine a dialog with the user. The user goes through this dialog one or
two times in a month, then there are no need for this code to reside in
memory at all, until the user requests it. Now, an OS could use several
algorithms to make sure that this code part will be put onto disk pretty
fast. Now algorithms are a good thing, but they don't know a thing about
the world, or the program at all, do they. No, but the programmer(s) knows
everything about the use of the program that is worth knowing, doesn't he.
Right. Instead of making smart-dumb algorithms who finds out what code
parts should be unloaded, the programmer marks the code blocks with
priority levels. These levels then makes the desicion data for the unloading
algorithm. After all, the programmer knows best, doesn't he... :->


Have a nice day everyone.

Arff

sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--


From rideau Sun Feb 14 17:51:29 1993
Subject: Re: What are the goal of MOOSE
To: ANDREASA@dhhalden.no
Date: Sun, 14 Feb 93 17:51:30 MET
Cc: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
	haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
	danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
	mueller@sc.ZIB-Berlin.DE, csjjlay@mtsu.edu, dspascha@eos.ncsu.edu
In-Reply-To: <MAILQUEUE-101.930214171344.416@sofus.dhhalden.no>; from "ANDREASA@dhhalden.no" at Feb 14, 93 5:13 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Hello again, dear friends; here is my public answer to Andreas' call.

>> One thing that is clear like norwegian mountain rivers are, we don't know
>> what we are doing, do we.
>> 
>> Everybody says, let's give her a name, then everybody says, let's not. We
>> must define what features this babe shall have. And they are right. Name
>> doesn't matter, not yet anyway.
>> Then everybody says, it should have this feature and it should have that,
>> and then I don't agree with you about that, or I do. Maybe, maybe not.
>> Maybe she'll never be born in other places than in our own imagination, and
>> that is possible where it should end, I don't know?v
>> Do you wan't to give birth to this child? Are you sure she won't become a
>> bastard,... and then an orphan......
>> Let's not, I repeat, let's not let this happen, so maybe it's time to tell you
>> why, and what, if you haven't thought of it by yourself yet.
>> One part is missing, and do you, do all of us, do we all know what? Maybe.
>> Should this child be a UN*X like piece of work, considering the way it should
>> work? Or an OS/2, or a Mac? Get my point? What is the goal?????
>> What is the meaning to give birth to a child if we don't know the
>> meaning of life?
>> 
>> 
>> We must define a usergroup. Who do we want to use this OS. Should it be
>> targeted UNIX gurus, or PC fans, or Mac fans, or Atari fans (not the 8bit
>> Dennis, the 16 bit version :-), I actually had one of thoose 8 bit myself,
>> a wonderful machine, don't you think so? :-)
>> 
>> Let's face the facts, as looked upon through my eyes.
>> We are developing for the PC based market, aren't we. We are talking Mac,
>> PC, Amiga, we are talking 68020, 030 and 80386. The 80386 is commonly
>> equiped with an isa/eisa bus. Ide hard disk controller, svga card and mouse.
>> What do we know of the common PC users of today?
>> They sit with the mouse in the right hand pointing and clicking. Staring at
>> those awful windows. There are some exceptions, us - the programmers.
>> We like to have the power in the keyboard, not in the mouse, when we work.
>> And in that way, we are quite unique in the way we are using computers.
>> Most people use computers because they want something done, not because
>> computers are, as we do :-)
>> See my point. Are we going to build an OS that looks like UglyBuggly MS-DOS,
>> or as terrible, and half as powerful, as unix. Who are we targetin' at?
>> Is this OS only for programmers.
>> I say, let us _try_ to save the world from the powerful and bad and ugly
>> Gates Ghost.
>> Let's face it, 90 percent of us might want a text ui, because it is faster
>> (and better in all ways), but 90 percent of the computerusers in the world
>> don't want a text ui, _if_ it makes the computer more difficult to
>> communicate with.
>> Do you see my point, let's not discuss names and features now. We have
>> many different views, and since nobody pays us, we can use our mind freely.
>> Let's find out who is going to use our child.
>> 
>> I vote (not for a name:-) that we develop/dedicate this OS for all programmers
>> that build userfriendly programs under windows, and hates it because it is too
>> combersome, takes to much time and crashes to often.
>> I vote for making this program understandable for 99 percent of the 386
>> computerusers, not 5 percent of them.
>> 
>> 
>> 
>> When it comes to desicion, Dennis invited me to join this adventure, and
>> he asked me to come up with ideas. I don't want to put Dennis in the role
>> of a dictator, so I say 2/3 of us must agree/disagree when we comes
>> to decisions, and either give Dennis veto, or a weight vote.
>> When it comes to who should compile these revision etc. let Dennis continue
>> as long as he wants. After all, we are all invited by him alone.
>> 
>> 
>> Now, say whatever you want about what I have written. Take a printout of it
>> and use it as toilet paper, or anything else, I don't care, but let us
>> find out what the purpose of MOOSE is. If we don't it may still be structured
>> as heaven, but become a hack worse than hell...
>> 
>> Arff
>> sig.'s in for 1000 miles service
>>         --Andreas Arff          andreasa@sofus.dhhalden.no--
>> 
>> 
 I think you hit the spot; I can't agree more than I do with you.
Everyone of us has his own ideas about the OS. I think we all want something
truely new, and each wants to add the features he most missed in the OSes
he used. We should try to understand each other's viewpoint, but also the needs
of everyday simple users (not system programmers). To achieve mutual
understanding (we must be sure we're on for one and only one OS), perhaps each
of us should mail his wishes to the group; we shall try to have coordinators
for subjects (to update a global list of agreements and disagreements, problems
asked and solutions found about his particular topic); but at this level, all
subjects are heavily interlinked, so that solutions to problems in different
part of the OS may not be independent each from the other (then coordinators
must coordinate). Each file should be available by ftp or e-mail in
their entire latest version, or diffs with respect to the month's reference
version (is there someone in the group able to implement this ?)
 I'm myself ready to collect suggestions about the object implementation; or to
send them to the one who'll take the job.

	     ,
	  Fare




From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sat Feb 13 01:34:49 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23305; Sat, 13 Feb 93 01:34:47 +0100
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sat, 13 Feb 93 01:34:47 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa04315;
          12 Feb 93 19:27 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa15732; 13 Feb 93 0:23 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa17344;
          13 Feb 93 0:19 GMT
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca,
        mueller@sc.zib-berlin.de, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
Subject: Re: Moose specs: Revision 0! (forwarded)
Date: Fri, 12 Feb 93 19:19:20 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302130019.aa17344@thorin.cis.udel.edu>
Status: OR


   JJ accidentally sent this only to me.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




------- Forwarded Message

Received: from louie.udel.edu by sol.cis.udel.edu id aa07811;
          12 Feb 93 13:19 GMT
Received: from knuth.mtsu.edu by louie.udel.edu id aa09576; 12 Feb 93 8:18 EST
Received: by knuth.mtsu.edu (Smail3.1.28.1 #6)
	id m0nN0JW-000cz0C; Fri, 12 Feb 93 07:20 CST
Message-Id: <m0nN0JW-000cz0C@knuth.mtsu.edu>
From: JJ Lay <csjjlay@knuth.mtsu.edu>
Subject: Re: Moose specs: Revision 0!
To: "Gary D. Duzan" <duzan@udel.edu>
Date: Fri, 12 Feb 1993 07:20:17 -0600 (CST)
In-Reply-To:  <9302112255.aa09511@gloin.cis.udel.edu> from "Gary D. Duzan" at Feb 11, 93 05:55:03 pm
X-Mailer: ELM [version 2.4 PL17]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3035      

Gary D. Duzan said:
: => DOS is directly programmed with 8088 assmebly language; Unix is programmed
: =>with C; MacOS is OO styled programmed with Pascal. In every case, the system
: =>and the language are thought together, and each adapted to the other.
: => It will be the same with MOOSE. Whatever language you choose to program
: =>with (I mean high-level stuff, not the Kernel, which is bound to be mainly
: =>done in assembly), it with shape your system. If you don't choose any
: =>language, the default will be assembly, and you'll be as unportable and
: =>unimprovable as DOS. If you choose C, you won't do better than U*ix. Perhaps
: =>C++ can do better, but it inherits much from C low-level philosophy, and
: =>won't give you a clean high-level OO system.
: 
:    True, but what can we do? If we can get a compiler for a good
: object-oriented language that will compile on a number of different
: machine, that would be great, but not, I think, too likely. I suppose
: we could try to get a number of language/compiler design people to whip
: up a language and GCC front-end for us to use if we really wanted to,
: or maybe use an existing language and develop a GCC front-end for it. I
: hate to say it, but C++ looks like the way to go for now. As long as we
: specify the interfaces and abide by them, we should be able to make it
: language-independant. It might be a good idea to develop a Smalltalk
: interface in parallel.

Or as you mentioned come up with a new language that will implement all
the features and constructs we need and want.  There is a lot of
research going on in the languages field and perhaps we gould take some
of the best from each.  I personally would enjoy doing this and am sure
there are others who would.  Let me here how everyone else feels!

: => To conclude, I think we mustn't rush doing what would be the kernel of a
: =>system whose features aren't defined yet. Let's define the high-level object
: =>orientation of the system before we write the kernel (more precisely, let's
: =>not write something in the kernel we should have to change completely
: =>because it will not fit high-level system requirements).
: 
:    Agreed. And likewise, let's not design high-level facilities that
: are natural on one platform but aren't easily implemented on others.

Yes.  Let's take our time and do this right!
							------
							JJ LAY

- ------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
ASSTNT MICROCOMPUTER MANGR             MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
- ------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team


------- End of Forwarded Message


From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sat Feb 13 01:47:31 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23622; Sat, 13 Feb 93 01:47:29 +0100
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sat, 13 Feb 93 01:47:29 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa05074;
          12 Feb 93 19:47 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa15856; 13 Feb 93 0:43 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa17481;
          13 Feb 93 0:39 GMT
To: JJ Lay <csjjlay@knuth.mtsu.edu>
Cc: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca,
        mueller@sc.zib-berlin.de, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
Subject: Re: Moose specs: Revision 0! 
In-Reply-To: Your message of "Fri, 12 Feb 93 07:20:17 CST."
             <m0nN0JW-000cz0C@knuth.mtsu.edu> 
Date: Fri, 12 Feb 93 19:39:19 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302130039.aa17481@thorin.cis.udel.edu>
Status: OR

=>Gary D. Duzan said:
=>: 
=>:    True, but what can we do? If we can get a compiler for a good
=>: object-oriented language that will compile on a number of different
=>: machine, that would be great, but not, I think, too likely. I suppose
=>: we could try to get a number of language/compiler design people to whip
=>: up a language and GCC front-end for us to use if we really wanted to,
=>: or maybe use an existing language and develop a GCC front-end for it. I
=>: hate to say it, but C++ looks like the way to go for now. As long as we
=>: specify the interfaces and abide by them, we should be able to make it
=>: language-independant. It might be a good idea to develop a Smalltalk
=>: interface in parallel.
=>
=>Or as you mentioned come up with a new language that will implement all
=>the features and constructs we need and want.  There is a lot of
=>research going on in the languages field and perhaps we gould take some
=>of the best from each.  I personally would enjoy doing this and am sure
=>there are others who would.  Let me here how everyone else feels!

   We have to be careful not to overextend ourselves. We are, after all,
a fairly small group. If we're going to do this then we should probably
advertise in comp.lang.* for some language/compiler design people to
join us. We could do parallel development something like this:

OS Group                                Language Group
--------                                --------------
OS Specification Discussion             Language Specification Discussion
OS Prototyping in Draft Language        GCC Front-End Development
   and Begin Assembly Implementation
OS Implementation in Language           Native OS Compiler Port
Expanded Device Driver/GUI              Programming Tool/Shell
   Implementation                          Development

   Or something like that, anyway. It would be nice to have a good,
solid language to work from. We just have to decide if we want to
do it or not.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dmarer@td2cad.intel.com Sat Feb 13 02:27:59 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24487; Sat, 13 Feb 93 02:27:58 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Sat, 13 Feb 93 02:27:58 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Fri, 12 Feb 93 17:23:56 -0800
Received: by td2cad (5.57/10.0i); Fri, 12 Feb 93 17:27:13 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00533; Fri, 12 Feb 93 17:34:02 PDT
Date: Fri, 12 Feb 93 17:34:02 PDT
Message-Id: <9302130134.AA00533@tdge15.intel.com>
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca,
        mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
Subject: Re: Moose (You guys...)
Status: OR

>    We will need some basic device support for bootstrapping, but beyond
> that I agree.
> (stuff deleted)
>    Anyone with enough spare time can build their own interface to
> practically any system (with the possible exception of MacOS,) so I
> don't see why we should be any different. The question is, what do WE
> build. If we have an object-oriented system then we should show it off
> with object-oriented shells and GUI.
>(stuff deleted) 
>    I agree that the basic kernel itself needn't be object-oriented, as
> long as it has an object-oriented interface and support for system and
> user objects.
>(stuff deleted)
>    I think we've reached a concensus on this point.

I think so also!  Even though I intended this to be (originally) an OOP GUI
based OS, it's more practical and logical to make the kernel as simple as
possible and leave that stuff for additions.  The kernel should *know* about
objects, and be able to handle them, but it shouldn't *really* be OOP.
Sounds good!

			Dennis

From cis.udel.edu!udel.edu!duzan Sat Feb 13 02:40:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24781; Sat, 13 Feb 93 02:40:26 +0100
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Sat, 13 Feb 93 02:40:26 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa06589;
          12 Feb 93 20:32 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa16051; 13 Feb 93 1:31 GMT
Received: from sol.cis.udel.edu by daffy.cis.udel.edu id aa10940;
          13 Feb 93 1:31 GMT
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca,
        mueller@sc.zib-berlin.de, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
Subject: Project Name
Date: Fri, 12 Feb 93 20:31:10 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302130131.aa10940@daffy.cis.udel.edu>
Status: OR


   Ok, we've had on-and-off discussions on a name for the project. I'd
like to take a quick poll to see which of several recently proposed
names you prefer. This will in no way be a binding vote (I think the
net-term is Straw Poll,) but if everyone wants the same thing, then we
should probably go with it.
   Please reply to me (duzan@cis.udel.edu) with your preference:

       MOOSE
       OSPREy
       Midgard
        Other: Please Specify

   I'll post a summary of the results at the end of next week (Feb 19.)

   While I'm here, we might as well discuss decision-making for the
project. I'd say that issues should be decided by 2/3 majority
concensus whenever possible. When impossible, it might be expedient
to have Dennis or someone else in the position to make arbitrary
dicisions from among the more popular views. We will also need
someone to keep track of the design decisions and compile them into a
design document for the group to follow. The alternative is endless
debate, an unclear design, and little (if any) actual group code.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From rideau@clipper Sat Feb 13 13:06:29 1993
Received: from galion.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15016; Sat, 13 Feb 93 13:06:26 +0100
From: rideau@clipper (Francois-Rene Rideau)
Return-Path: <rideau@clipper>
Received-Date: Sat, 13 Feb 93 13:06:26 +0100
Message-Id: <9302131206.AA15016@clipper.ens.fr>
Subject: Re: Project Name
To: dmarer@td2cad.intel.com (Dennis Marer)
Date: Sat, 13 Feb 93 13:06:26 MET
Cc: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca,
        mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
In-Reply-To: <9302101815.AA00324@tdge15.intel.com>; from "Dennis Marer" at Feb 10, 93 10:15 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR


From csjjlay@knuth.mtsu.edu Sat Feb 13 18:36:40 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23078; Sat, 13 Feb 93 18:36:39 +0100
Return-Path: <csjjlay@knuth.mtsu.edu>
Received-Date: Sat, 13 Feb 93 18:36:39 +0100
Received: from knuth.mtsu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by knuth.mtsu.edu (Smail3.1.28.1 #6)
	id m0nNQoL-000cwAC; Sat, 13 Feb 93 11:37 CST
Message-Id: <m0nNQoL-000cwAC@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: Test alias
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com
Date: Sat, 13 Feb 1993 11:37:52 -0600 (CST)
Cc: haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 787       
Status: OR

Please send me a reply if you receive this.  My aliasing doesn't seem to
be working all that well.  Thanks!

							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team


From csjjlay@knuth.mtsu.edu Sat Feb 13 18:37:05 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23089; Sat, 13 Feb 93 18:37:04 +0100
Return-Path: <csjjlay@knuth.mtsu.edu>
Received-Date: Sat, 13 Feb 93 18:37:04 +0100
Received: from knuth.mtsu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by knuth.mtsu.edu (Smail3.1.28.1 #6)
	id m0nNQos-000cwEC; Sat, 13 Feb 93 11:38 CST
Message-Id: <m0nNQos-000cwEC@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: Re: Project Name (fwd)
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com
Date: Sat, 13 Feb 1993 11:38:26 -0600 (CST)
Cc: haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 2931      
Status: OR

JJ Lay said:
>From csjjlay Sat Feb 13 11:23:27 1993
Message-Id: <m0nNQaL-000cwAC@knuth.mtsu.edu>
From: csjjlay (JJ Lay)
Subject: Re: Project Name
To: duzan@udel.edu (Gary D. Duzan)
Date: Sat, 13 Feb 1993 11:23:22 -0600 (CST)
Cc: csjjlay (JJ Lay)
In-Reply-To:  <9302131441.aa16537@ori.cis.udel.edu> from "Gary D. Duzan" at Feb 13, 93 09:41:21 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1806      
Content-Length: 1806

Gary D. Duzan said:
: 
: =>~ftp/MOOSE/docs/      this would be our specs and other relevant OS
: =>                      information including the questionaire
: =>~ftp/MOOSE/resumes/   information about the people involved
: =>~ftp/MOOSE/archives/  archives of all the email postings by week
:    I don't think 'resumes' is quite right; it sounds like we are all
: looking for a job. :-) We will, I suppose, also want someplace to put
: the code as it is being developed.

New hiearchy:
~ftp/MOOSE/                  the root
~ftp/MOOSE/docs/             same as above
~ftp/MOOSE/people/name       instead of resumes.  Can also be a
                             directory for people to stick "unofficial"
                             patches that they  have written.
                             e.g. ~ftp/MOOSE/people/csjjlay
~ftp/MOOSE/email/            instead of archives
~ftp/MOOSE/sources/          the source code
~ftp/MOOSE/binaries/         compiled OS code
~ftp/MOOSE/images/           bootable disk images for those who would
                             rather leave their hard drive alone.

What else am I missing?
							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team



							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team


From csjjlay@knuth.mtsu.edu Sat Feb 13 18:37:21 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23099; Sat, 13 Feb 93 18:37:20 +0100
Return-Path: <csjjlay@knuth.mtsu.edu>
Received-Date: Sat, 13 Feb 93 18:37:20 +0100
Received: from knuth.mtsu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by knuth.mtsu.edu (Smail3.1.28.1 #6)
	id m0nNQp9-000cwFC; Sat, 13 Feb 93 11:38 CST
Message-Id: <m0nNQp9-000cwFC@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: Re: Project Name (fwd)
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com
Date: Sat, 13 Feb 1993 11:38:42 -0600 (CST)
Cc: haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3985      
Status: OR

JJ Lay said:
>From csjjlay Sat Feb 13 11:28:49 1993
Message-Id: <m0nNQfV-000cwAC@knuth.mtsu.edu>
From: csjjlay (JJ Lay)
Subject: Re: Project Name
To: rideau@clipper.ens.fr (Francois-Rene Rideau)
Date: Sat, 13 Feb 1993 11:28:44 -0600 (CST)
Cc: csjjlay (JJ Lay)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 2945      
Content-Length: 2945

Francois-Rene Rideau said:
: >> > The project I've been working on for the past couple of years is called
: >> > OSPREy.  It stands for Operating System PRojEct.  Perhaps that would be
: >> > a candidate for a name?
: >> 
: >> I love it!  It's really going to be tough to choose a name...so many options!>> I believe this will be the most difficult part of the project... :-)
: 
: Well... I think we should concentrate on the rest of it. When we have advanced
: in the program, it should certainly be easier to find a name, corresponding to
: its features.

Point taken.  What if the nature of the project changes and the name we
choose absolutely doesn't fit???  Whatever name comes up in the Feb 19th
result can be the unofficial name for now.
  
: >> > Also, I would like to nominate myself to archive all the correspondence
: >> > of the project: email, news postings, etc.
: >> You're welcome to it!
: 
: Hey, Dennis, why don't name the happy volonteer ? Or should it be a secret !?

Well, my name is JJ Lay and it isn't a big secret, I don't think.  See
below for my email address.
  
: >> > I have more ideas on organization if you guys (and gals?) think its
: >> > worthwhile.
: >> 
: >> Let's hear 'em!

Well, I sent them to Dennis and haven't heard from anyone else!  My
alias is obviously not working correctly.  WOuld you mind forwarding the
message to everyone (including me I didn't even receive a copy).

: >   While I'm here, we might as well discuss decision-making for the
: > project. I'd say that issues should be decided by 2/3 majority
: > concensus whenever possible. When impossible, it might be expedient
: > to have Dennis or someone else in the position to make arbitrary
: > dicisions from among the more popular views. We will also need
: > someone to keep track of the design decisions and compile them into a
: > design document for the group to follow. The alternative is endless
: > debate, an unclear design, and little (if any) actual group code.
: 
: Here is a very important issue, indeed !
: Hey, there why not concentrate on the thing, not its name. When it's well
: begun and we see better what it is, we'll be able to find a proper name
: which will reflect the content of it; meanwhile, let's continue call it
: as we want.

							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team



							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team


From ANDREASA@sofus.dhhalden.no Sun Feb 14 17:15:17 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29249; Sun, 14 Feb 93 17:15:15 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Sun, 14 Feb 93 17:15:15 +0100
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <25843-0@fenris.dhhalden.no>; Sun, 14 Feb 1993 17:14:21 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930214171347.448; 14 Feb 93 17:14:04 -100
Message-Id: <MAILQUEUE-101.930214171344.416@sofus.dhhalden.no>
To: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.ZIB-Berlin.DE, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 14 Feb 93 17:13:44 +0100
Subject: What are the goal of MOOSE
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

One thing that is clear like norwegian mountain rivers are, we don't know
what we are doing, do we.

Everybody says, let's give her a name, then everybody says, let's not. We
must define what features this babe shall have. And they are right. Name
doesn't matter, not yet anyway.
Then everybody says, it should have this feature and it should have that,
and then I don't agree with you about that, or I do. Maybe, maybe not.
Maybe she'll never be born in other places than in our own imagination, and
that is possible where it should end, I don't know?
Do you wan't to give birth to this child? Are you sure she won't become a
bastard,... and then an orphan......
Let's not, I repeat, let's not let this happen, so maybe it's time to tell you
why, and what, if you haven't thought of it by yourself yet.
One part is missing, and do you, do all of us, do we all know what? Maybe.
Should this child be a UN*X like piece of work, considering the way it should
work? Or an OS/2, or a Mac? Get my point? What is the goal?????
What is the meaning to give birth to a child if we don't know the
meaning of life?


We must define a usergroup. Who do we want to use this OS. Should it be
targeted UNIX gurus, or PC fans, or Mac fans, or Atari fans (not the 8bit
Dennis, the 16 bit version :-), I actually had one of thoose 8 bit myself,
a wonderful machine, don't you think so? :-)

Let's face the facts, as looked upon through my eyes.
We are developing for the PC based market, aren't we. We are talking Mac,
PC, Amiga, we are talking 68020, 030 and 80386. The 80386 is commonly
equiped with an isa/eisa bus. Ide hard disk controller, svga card and mouse.
What do we know of the common PC users of today?
They sit with the mouse in the right hand pointing and clicking. Staring at
those awful windows. There are some exceptions, us - the programmers.
We like to have the power in the keyboard, not in the mouse, when we work.
And in that way, we are quite unique in the way we are using computers.
Most people use computers because they want something done, not because
computers are, as we do :-)
See my point. Are we going to build an OS that looks like UglyBuggly MS-DOS,
or as terrible, and half as powerful, as unix. Who are we targetin' at?
Is this OS only for programmers.
I say, let us _try_ to save the world from the powerful and bad and ugly
Gates Ghost.
Let's face it, 90 percent of us might want a text ui, because it is faster
(and better in all ways), but 90 percent of the computerusers in the world
don't want a text ui, _if_ it makes the computer more difficult to
communicate with.
Do you see my point, let's not discuss names and features now. We have
many different views, and since nobody pays us, we can use our mind freely.
Let's find out who is going to use our child.

I vote (not for a name:-) that we develop/dedicate this OS for all programmers
that build userfriendly programs under windows, and hates it because it is too
combersome, takes to much time and crashes to often.
I vote for making this program understandable for 99 percent of the 386
computerusers, not 5 percent of them.



When it comes to desicion, Dennis invited me to join this adventure, and
he asked me to come up with ideas. I don't want to put Dennis in the role
of a dictator, so I say 2/3 of us must agree/disagree when we comes
to decisions, and either give Dennis veto, or a weight vote.
When it comes to who should compile these revision etc. let Dennis continue
as long as he wants. After all, we are all invited by him alone.


Now, say whatever you want about what I have written. Take a printout of it
and use it as toilet paper, or anything else, I don't care, but let us
find out what the purpose of MOOSE is. If we don't it may still be structured
as heaven, but become a hack worse than hell...

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--


From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sun Feb 14 18:50:16 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01898; Sun, 14 Feb 93 18:50:15 +0100
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sun, 14 Feb 93 18:50:15 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa01506;
          14 Feb 93 12:08 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa03552;
          14 Feb 93 17:05 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa24929;
          14 Feb 93 17:05 GMT
To: ANDREASA@dhhalden.no
Cc: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.zib-berlin.de, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
Subject: Re: MOOSE 
In-Reply-To: Your message of "14 Feb 93 16:23:22 +0100."
             <MAILQUEUE-101.930214162321.320@sofus.dhhalden.no> 
Date: Sun, 14 Feb 93 12:03:23 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302141705.aa24929@gloin.cis.udel.edu>
Status: OR

=>About the language question; Not! I say, it isn't a question. There is no
=>need for a new language, tell me what reasons there are to build one.
=>Are there no languages that can fill our needs?

   Perhaps. C or Assembly will certainly do for the kernel itself, but
if we are going to have an object-oriented system, then it would be
nice to have an object-oriented language to implement higher-level
objects and applications. We would need something free, fast, and
portable. GCC 2.3.3 (C, C++, Objective C) meets these requirements, but
C++ isn't that pretty. Does anyone have experience with Objective C? I
would certainly advise against building a language from scratch.
However, if we have the resources, it might make sense to develop a GCC
front-end for an existing object-oriented language in parallel with the
kernel development.

=>I did some testing the either day. I wrote some asm. code to do a specific
=>task, then I did the same thing with some C code. I used Borland C(++) and
=>compiled via assembler. Guess if I was supprised Borland generated better
=>assembler than me. I have heard rumors that compilers generated better code
=>than assembler programmers, but I never belived it could be true. In
=>addition the compiler made use of 386 specific commands in a way I had never
=>thought of. I'm no assembler guru, have never been, and will probably never
=>become, but that my code were so much larger....

   Yep, that's what computers are good for: tedious, boring, tasks that
follow a lot of strict rules. With modern processors, there are more
things to worry about when generating assembly, including things like
instruction ordering and filling branch delay slots. GCC 2.3.3 even has
an option to generate code optimized for a 486 that still runs on a 386.
And when you really do need to access specific instructions, you can
always imbed assembly code in the C.

=>Let us use a compiler that has _few_ bugs(!!!), that generates clever code,
=>and has support for the 386. If you still belive that you are coding much
=>better than a compiler, compile via assembler, and fix the few unclever
=>code-parts that has been generated.
=>That is my advise.

   I tend to agree, but Dennis seems to an assembly-masochist. :-)

=>About part  II, the Kernel - A. General Memory Management

   There are other ways of taking care of this problem. In a virtual
system, one option is to swap in code as needed. Sections of code
that are always used (referred to as the 'Working Set') can be loaded
first. The trick is creating the mechanism to specify the working set.
After the program is done with a section of code, it will eventually
be flushed by an LRU page replacement algorithm.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sun Feb 14 22:09:37 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06710; Sun, 14 Feb 93 22:09:35 +0100
Return-Path: <dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sun, 14 Feb 93 22:09:35 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id ab07089;
          14 Feb 93 16:05 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa04410;
          14 Feb 93 21:02 GMT
Received: from sol.cis.udel.edu by dori.cis.udel.edu id aa08830;
          14 Feb 93 20:58 GMT
To: ANDREASA@dhhalden.no
Cc: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.zib-berlin.de, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
Subject: Re: What are the goal of MOOSE 
In-Reply-To: Your message of "14 Feb 93 17:13:44 +0100."
             <MAILQUEUE-101.930214171344.416@sofus.dhhalden.no> 
Date: Sun, 14 Feb 93 15:57:51 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302142058.aa08830@dori.cis.udel.edu>
Status: OR

=>One thing that is clear like norwegian mountain rivers are, we don't know
=>what we are doing, do we.

   Well, that would be about par for me. :-)

=>Everybody says, let's give her a name, then everybody says, let's not. We
=>must define what features this babe shall have. And they are right. Name
=>doesn't matter, not yet anyway.

   I've been pushing a bit for a name to help unify and solidify the
group. It is a lot easier to say "I'm working on Project X" than to say
"I'm working with Joe Random Group to put together the Foobar System."
When I say "GNU", you know what I am talking about, even though the
name doesn't specify it's goals. What's in a name? A rose by any other
name would smell as sweet. But would you want to call it "That Red
Flower"?  A name is just something to focus upon. That and the fact
that I really don't like "MOOSE". :-)

=>Then everybody says, it should have this feature and it should have that,
=>and then I don't agree with you about that, or I do. Maybe, maybe not.
=>Maybe she'll never be born in other places than in our own imagination, and
=>that is possible where it should end, I don't know?
=>Do you wan't to give birth to this child? Are you sure she won't become a
=>bastard,... and then an orphan......

   There is nothing wrong with being a bastard or an orphan. Obscurity
is survivable, if not particularly desirable. So long as the child is
one to be proud of.

=>One part is missing, and do you, do all of us, do we all know what? Maybe.
=>Should this child be a UN*X like piece of work, considering the way it should
=>work? Or an OS/2, or a Mac? Get my point? What is the goal?????
=>What is the meaning to give birth to a child if we don't know the
=>meaning of life?

   With this philosophy, we would never have to worry about
overpopulation. :-)

=>We must define a usergroup. Who do we want to use this OS. Should it be
=>targeted UNIX gurus, or PC fans, or Mac fans, or Atari fans (not the 8bit
=>Dennis, the 16 bit version :-), I actually had one of thoose 8 bit myself,
=>a wonderful machine, don't you think so? :-)

   I'm a veteran Atari 8-bitter, myself, and I'd have to agree with
you on that point. However, I'm not certain that we need to define our
audience. The only thing the audience ever sees is the User Interface
and the Applications. We should have plenty of work to do before we get
to anything that the user will see.

=>Let's face the facts, as looked upon through my eyes.

   Facts, as seen through anyone's eyes, are perceptions.

=>We are developing for the PC based market, aren't we. We are talking Mac,
=>PC, Amiga, we are talking 68020, 030 and 80386. The 80386 is commonly
=>equiped with an isa/eisa bus. Ide hard disk controller, svga card and mouse.

   Yeah, sounds pretty standard. However, if somehow we manage to get
people to like our system, we will probably want to be able to port
it to some of the more powerful systems.

=>What do we know of the common PC users of today?

   Far too much, in my experience. :-)

=>Is this OS only for programmers.

   The OS should always be for the programmers; the user interface
should be for the users.

=>I say, let us _try_ to save the world from the powerful and bad and ugly
=>Gates Ghost.

   David vs. Goliath? :-)

=>Let's face it, 90 percent of us might want a text ui, because it is faster
=>(and better in all ways), but 90 percent of the computerusers in the world
=>don't want a text ui, _if_ it makes the computer more difficult to
=>communicate with.

   So we make both. The stuff underneath stays the same. As long as we
know from the start that we want to support both and build in the
required functionality, we should be fine.

=>Do you see my point, let's not discuss names and features now. We have
=>many different views, and since nobody pays us, we can use our mind freely.
=>Let's find out who is going to use our child.

   My point would be that people don't use an OS, they use applications.
Even if we write the perfect OS, no one is going to use it if there are
no applications available for it. If wide acceptance is going to be a
primary goal, then we are going to need an application programming
group once we start getting close to release.

=>I vote (not for a name:-) that we develop/dedicate this OS for all programmer
s
=>that build userfriendly programs under windows, and hates it because it is to
o
=>combersome, takes to much time and crashes to often.

   That is certainly an admirable goal.

=>I vote for making this program understandable for 99 percent of the 386
=>computerusers, not 5 percent of them.

   I hope you mean the interface, and not the code. :-)

=>When it comes to desicion, Dennis invited me to join this adventure, and
=>he asked me to come up with ideas. I don't want to put Dennis in the role
=>of a dictator, so I say 2/3 of us must agree/disagree when we comes
=>to decisions, and either give Dennis veto, or a weight vote.
=>When it comes to who should compile these revision etc. let Dennis continue
=>as long as he wants. After all, we are all invited by him alone.

   Deja vu all over again. :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From UKCC.uky.edu!WKUVX1.BITNET!haydedr Mon Feb 15 06:21:53 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24027; Mon, 15 Feb 93 06:21:52 +0100
Return-Path: <UKCC.uky.edu!WKUVX1.BITNET!haydedr>
Received-Date: Mon, 15 Feb 93 06:21:52 +0100
Received: from ukcc.uky.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 9124; Sun, 14 Feb 93 23:38:09 EST
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 8656;
 Sun, 14 Feb 93 23:38:08 EST
Received: by WKUVX1.BITNET (MX V3.2-alpha) id 15707; Sun, 14 Feb 1993 22:40:32
          CST
Sender: haydedr@WKUVX1.BITNET
Date: Sun, 14 Feb 1993 22:40:13 CST
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
        mueller@sc.ZIB-Berlin.DE, mckeeveb@sfu.ca, garfield@sra.com,
        duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
        ANDREASA@dhhalden.no
Cc: haydedr@WKUVX1.BITNET
Message-Id: <00968241.73ED1200.15707@WKUVX1.BITNET>
Subject: MOOSE details!
Status: OR

Yo!

Well all, I don't know about all you, but I'm ready to get started on
some concrete design work (admittedly my desire to get right into
coding has proved detrimental to me on previous large-scale projetcts,
so please tell me if I'm jumping too far ahead, or too far back :-).

So, here's my best and most current "definition" of Moose:

"Moose will be a fully interrupt driven, preemptive, priority-based
multithreaded system."

Now I know this is a very broad definition, and it missed a lot (such
as networking support).  But does it sound good?  Is it going to be
preemptive?  Will it be multi-threaded?

I've also kind of worked out some pseudo code like scribblings of the
path through the scheduler.  I've tried to give precise definitions to
my terms such as "session," "process," and "thread," etc.  I've
labeled where exactly a context switch can occur, etc.  And I've
already posted my ideas on priority classes.

So what do you all think?  Should I type in all my scribblings and
send them out, or is it still way too early for that stuff?  And is
the kernel the first thing we should design?  I have my ideas, as we
all do, so I vote we start doing some down-to-earth design work.

So far I've come up with this:
The kernel should be coded in C/asm.
As much of the system from there should be object based (C++ my vote).
It will supply a GUI and command-line shells.
We will read DOS FAT file systems.

Is this complete?  Is anything incorrect?  I think we should begin to
focus and get things like these out in the open, and slowly begin to
narrow down and better define our OS.


Thanks all,
Ross Hayden
haydedr@wkuvx1.bitnet

From winikoff@cs.mu.OZ.AU Mon Feb 15 06:52:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24615; Mon, 15 Feb 93 06:52:00 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 15 Feb 93 06:52:00 +0100
Received: from mulga.cs.mu.OZ.AU by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA06200
	Mon, 15 Feb 1993 16:43:52 +1100 (from winikoff)
Message-Id: <9302150543.6200@mulga.cs.mu.OZ.AU>
Subject: Test - Please ACK.
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
Date: Mon, 15 Feb 93 16:43:51 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

Please let me know if you recieve this.

Thanks.
--------------------------------------------------------------------------------
Software Engineering: Quality through Deforestation.
"If you know what you're doing it ain't research"
							Musician
Michael Winikoff					Amiga 500 Owner
winikoff@cs.mu.oz.au					Role player

From winikoff@cs.mu.OZ.AU Mon Feb 15 07:05:21 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24894; Mon, 15 Feb 93 07:05:20 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 15 Feb 93 07:05:20 +0100
Received: from mulga.cs.mu.OZ.AU by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA06600
	Mon, 15 Feb 1993 16:57:03 +1100 (from winikoff)
Message-Id: <9302150557.6600@mulga.cs.mu.OZ.AU>
Subject: MOOSE
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
Date: Mon, 15 Feb 93 16:57:02 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR


> Flower"?  A name is just something to focus upon. That and the fact
> that I really don't like "MOOSE". :-)

Why? It's memorable. It's humourous. What else do you want?
A horrible acronym  that was obviously put together? :-)

> 
>    Yeah, sounds pretty standard. However, if somehow we manage to get
> people to like our system, we will probably want to be able to port
> it to some of the more powerful systems.

Yes.

> 
> =>Is this OS only for programmers.
> 
>    The OS should always be for the programmers; the user interface
> should be for the users.

Yes and no. The details of the system calls are irrelevant to the user.
The fact that the OS provides (Eg.) multitasking is VERY relevant to the 
user. 

In other words the conceptual model and services provided are relevant.

>    David vs. Goliath? :-)
> 

Uhh, more like a lone pilot in a X-wing vs. the death star.
[How many billions is microsoft worth these days?]

> 
>    My point would be that people don't use an OS, they use applications.
> Even if we write the perfect OS, no one is going to use it if there are
> no applications available for it. If wide acceptance is going to be a
> primary goal, then we are going to need an application programming
> group once we start getting close to release.

Yes and no. If it is very easy to develop applications for the system then
you'll have a lot more applications (hopefuly shareware/PD) being developed
by people non-professionaly.

This is obviously influenced by how common the OS is.

I do agree though that we need a starting base set of aplications.
> 
> =>I vote for making this program understandable for 99 percent of the 386
> =>computerusers, not 5 percent of them.
> 
>    I hope you mean the interface, and not the code. :-)

I vote for making the OS INTERFACE understandable to 99% of programers.

--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Mon Feb 15 07:16:39 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25110; Mon, 15 Feb 93 07:16:37 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 15 Feb 93 07:16:37 +0100
Received: from mulga.cs.mu.OZ.AU by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA06853
	Mon, 15 Feb 1993 17:04:48 +1100 (from winikoff)
Message-Id: <9302150604.6853@mulga.cs.mu.OZ.AU>
Subject: MOOSE
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
Date: Mon, 15 Feb 93 17:04:47 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR


> About part D. of the rev. -72, "Design principles".
> The OS should, in addition to what Dennis mentions, keep track of the
> resources used by any application, so that the system will be able
> to unload the resources that are left after an application crash, and thereby
> save resources and make the system more fool proof.

Yes. It allready does this for memory.
There's little point (IMHO) in doing this for memory but not for other resources

> 
> 
> About part  II, the Kernel - A. General Memory Management
> Dennis mentions something about compiler dependance and memory allocation.
> If some of you have been programming Windows, you are familiar with .def
> files, definition files. Each program source code has got one of these.
> They tells the windows shell what code parts that should be swapped to
> disk first.
> Imagine a dialog with the user. The user goes through this dialog one or
> two times in a month, then there are no need for this code to reside in
> memory at all, until the user requests it. Now, an OS could use several
> algorithms to make sure that this code part will be put onto disk pretty
> fast. Now algorithms are a good thing, but they don't know a thing about
> the world, or the program at all, do they. No, but the programmer(s) knows
> everything about the use of the program that is worth knowing, doesn't he.
> Right. Instead of making smart-dumb algorithms who finds out what code
> parts should be unloaded, the programmer marks the code blocks with
> priority levels. These levels then makes the desicion data for the unloading
> algorithm. After all, the programmer knows best, doesn't he... :->

I don't like this ...
	(1) It's a hack
	(2) The programmer can't anticipate what other's do with his/her
		program -- if I use the program in a different way the 
		performance is likely to be ABYSMAL.
	(3) Why not make life easier for the programmer?

	And I didn;t even mention that programmers DON'T know everything about 
	their code (otherwise debugging would be dead easy :-) or that they
	can't anticipate the size/speed of memory/disks or what other programs
	are going to be using up memory at the same time.
> 
> 
> Have a nice day everyone.
> 
> Arff
> 
> sig.'s in for 1000 miles service
>         --Andreas Arff          andreasa@sofus.dhhalden.no--
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From ANDREASA@sofus.dhhalden.no Mon Feb 15 10:16:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29380; Mon, 15 Feb 93 10:16:24 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 15 Feb 93 10:16:24 +0100
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <10085-1@fenris.dhhalden.no>; Mon, 15 Feb 1993 10:14:42 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930215101420.512; 15 Feb 93 10:14:24 -100
Message-Id: <MAILQUEUE-101.930215101413.480@sofus.dhhalden.no>
To: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.ZIB-Berlin.DE, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 15 Feb 93 10:14:13 +0100
Subject: Re: What are the goal of MOOSE
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

>    I've been pushing a bit for a name to help unify and solidify the
> group. It is a lot easier to say "I'm working on Project X" than to say
> "I'm working with Joe Random Group to put together the Foobar System."
> When I say "GNU", you know what I am talking about, even though the
> name doesn't specify it's goals. What's in a name? A rose by any other
> name would smell as sweet. But would you want to call it "That Red
> Flower"?  A name is just something to focus upon. That and the fact
> that I really don't like "MOOSE". :-)
Get your point, but as Fare'(?) said, if we shall give it a name that
correspond to its features, describes its inner workings, we should define
what these are first? Still, I love MOOSE.

>    With this philosophy, we would never have to worry about
> overpopulation. :-)
Obviously the Chinese and Indians knows the meaning of life.:-)

>    Facts, as seen through anyone's eyes, are perceptions.
Perceptions, ok then.
>
> =>We are developing for the PC based market, aren't we. We are talking Mac,
> =>PC, Amiga, we are talking 68020, 030 and 80386. The 80386 is commonly
> =>equiped with an isa/eisa bus. Ide hard disk controller, svga card and mouse.
>
>    Yeah, sounds pretty standard. However, if somehow we manage to get
> people to like our system, we will probably want to be able to port
> it to some of the more powerful systems.

Not unlikely, do you take care of the Alpha part...
Let's make the system before we start to port it, is that ok for you all?

> =>What do we know of the common PC users of today?
>
>    Far too much, in my experience. :-)

I'm not to sure about that...

> =>Is this OS only for programmers.
>
>    The OS should always be for the programmers; the user interface
> should be for the users.

I can't say I agree, even I get unsure when I start early versions of
WordPerfect, or Lotus 123, and I am a programmer.
And for that reason, I never use a program that can't compile my scribblings
:-)

>    David vs. Goliath? :-)

Yeap, but the other way in a sense. Most (programers) people that I talk
with, hate windows, so they shouldn't be hard to convince, if it's good
enough...

>    So we make both. The stuff underneath stays the same. As long as we
> know from the start that we want to support both and build in the
> required functionality, we should be fine.

If we make both things we risc ending up with a new Windows, suffering from
the OS.
"Windows NT from those who brought you Windows"
...
"Windows from those who brought you Edlin"

>    My point would be that people don't use an OS, they use applications.
> Even if we write the perfect OS, no one is going to use it if there are
> no applications available for it. If wide acceptance is going to be a
> primary goal, then we are going to need an application programming
> group once we start getting close to release.

Yes, but how should we enforce a standard user interface for the apps, if
we don't put some restrictions on what can be done. (See my part with
WordPerfect) Without a standard ui, it will not get accepted.

>    I hope you mean the interface, and not the code. :-)
Don't be to sure :-) SuperCard for the masses... :-( sorry, just kidding...

Got to do some work.

Have a nice day.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--


From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon Feb 15 14:50:59 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07670; Mon, 15 Feb 93 14:50:56 +0100
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 15 Feb 93 14:50:56 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id ab14741; 15 Feb 93 8:50 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa13419;
          15 Feb 93 13:47 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa02947;
          15 Feb 93 13:43 GMT
To: "Dr. Hayden" <udel.edu!wkuvx1.bitnet!haydedr>
Cc: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
        mueller@sc.zib-berlin.de, mckeeveb@sfu.ca, garfield@sra.com,
        duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
        ANDREASA@dhhalden.no
Subject: Re: MOOSE details! 
In-Reply-To: Your message of "Sun, 14 Feb 93 22:40:13 CST."
             <00968241.73ED1200.15707@WKUVX1.BITNET> 
Date: Mon, 15 Feb 93 08:43:20 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302151343.aa02947@bifur.cis.udel.edu>
Status: OR

=>So, here's my best and most current "definition" of Moose:
=>
=>"Moose will be a fully interrupt driven, preemptive, priority-based
=>multithreaded system."
=>
=>Now I know this is a very broad definition, and it missed a lot (such
=>as networking support).  But does it sound good?  Is it going to be
=>preemptive?  Will it be multi-threaded?

   Sounds like a good place to start, anyway. I don't know if the
kernel itself needs to be multithreaded since most of the functionality
will be implemented in higher-level objects, but those objects should
certainly be multithreaded.

=>So what do you all think?  Should I type in all my scribblings and
=>send them out, or is it still way too early for that stuff?  And is
=>the kernel the first thing we should design?  I have my ideas, as we
=>all do, so I vote we start doing some down-to-earth design work.

   I'd say, go ahead and post them. Then we can discuss whether they
are appropriate to the project.

=>So far I've come up with this:
=>The kernel should be coded in C/asm.

   Agreed.

=>As much of the system from there should be object based (C++ my vote).

   Fair enough, I suppose.

=>It will supply a GUI and command-line shells.

   Good. Applications should be encouraged to use the GUI, while
utilities should use character mode. We will need to decide whether
to support switching from GUI-mode to full screen text on the console.

=>We will read DOS FAT file systems.

   Yes, I think this would be wise, as long as it isn't the primary file
system.

=>Is this complete?  Is anything incorrect?  I think we should begin to
=>focus and get things like these out in the open, and slowly begin to
=>narrow down and better define our OS.

   It is far from complete, I'm sure, but what you have stated sounds
good. We have to define it at some point, so we might as well start now.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon Feb 15 15:13:39 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08314; Mon, 15 Feb 93 15:13:37 +0100
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 15 Feb 93 15:13:37 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa15184; 15 Feb 93 9:10 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa13570;
          15 Feb 93 14:07 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa03042;
          15 Feb 93 14:06 GMT
To: Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au>
Cc: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca,
        mueller@sc.zib-berlin.de, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
Subject: Re: MOOSE 
In-Reply-To: Your message of "Mon, 15 Feb 93 16:57:02 EST."
             <9302150557.6600@mulga.cs.mu.OZ.AU> 
Date: Mon, 15 Feb 93 09:06:03 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302151406.aa03042@bifur.cis.udel.edu>
Status: OR

=>
=>> Flower"?  A name is just something to focus upon. That and the fact
=>> that I really don't like "MOOSE". :-)
=>
=>Why? It's memorable. It's humourous. What else do you want?
=>A horrible acronym  that was obviously put together? :-)

   No, but I think it is a little too much like GNU, and we should have
a name that can be taken seriously. The legendary Bullwinkle J. Moose
hasn't done much for the credibility for the species. :-)

=>>    The OS should always be for the programmers; the user interface
=>> should be for the users.
=>
=>Yes and no. The details of the system calls are irrelevant to the user.
=>The fact that the OS provides (Eg.) multitasking is VERY relevant to the 
=>user. 
=>
=>In other words the conceptual model and services provided are relevant.
=>
   True enough, but I think that the better the UI, the less the user
will have to worry about the services, and simply take them for granted.

=>>    David vs. Goliath? :-)
=>
=>Uhh, more like a lone pilot in a X-wing vs. the death star.
=>[How many billions is microsoft worth these days?]
=>
   Would you believe:  David vs. the Death Star. :-)

=>I do agree though that we need a starting base set of aplications.

   And the better the applications, the better the acceptance of the
system as a whole.

=>> =>I vote for making this program understandable for 99 percent of the 386
=>> =>computerusers, not 5 percent of them.
=>> 
=>>    I hope you mean the interface, and not the code. :-)
=>
=>I vote for making the OS INTERFACE understandable to 99% of programers.

   Absolutely. Well, at least those with a clue about objects.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon Feb 15 15:46:31 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09525; Mon, 15 Feb 93 15:46:29 +0100
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 15 Feb 93 15:46:29 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id ac16197; 15 Feb 93 9:41 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa13776;
          15 Feb 93 14:37 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa03150;
          15 Feb 93 14:37 GMT
To: ANDREASA@dhhalden.no
Cc: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.zib-berlin.de, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
Subject: Re: What are the goal of MOOSE 
In-Reply-To: Your message of "15 Feb 93 10:14:13 +0100."
             <MAILQUEUE-101.930215101413.480@sofus.dhhalden.no> 
Date: Mon, 15 Feb 93 09:36:48 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302151437.aa03150@bifur.cis.udel.edu>
Status: OR

=>Not unlikely, do you take care of the Alpha part...
=>Let's make the system before we start to port it, is that ok for you all?

   Well, if you want to buy me an Alpha, I'll port the system to it. :-)
Yes, we should certainly build it before we start porting it, but if
portability is a goal, then we should keep that in mind while putting
together the design.

=>> =>What do we know of the common PC users of today?
=>>
=>>    Far too much, in my experience. :-)
=>
=>I'm not to sure about that...

   Ok, then, not as much as we need to know, but more than we want to.
:-)

=>If we make both things we risc ending up with a new Windows, suffering from
=>the OS.
=>"Windows NT from those who brought you Windows"
=>...
=>"Windows from those who brought you Edlin"
=>
   Yes, but we have the advantage of starting from scratch knowing
(roughly, anyway) where we are headed. And we haven't brought anyone
anything yet.

=>Yes, but how should we enforce a standard user interface for the apps, if
=>we don't put some restrictions on what can be done. (See my part with
=>WordPerfect) Without a standard ui, it will not get accepted.

   Hmmm. Probably true. We should certainly at least set up a basic
framework for manipulating objects in the GUI. However, I'm not sure
application developers would appreciate us forcing them into a
straightjacket when they want to write a program.

=>Got to do some work.

   What's that? :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From ANDREASA@sofus.dhhalden.no Mon Feb 15 18:03:56 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13940; Mon, 15 Feb 93 18:03:54 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 15 Feb 93 18:03:54 +0100
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <18654-0@fenris.dhhalden.no>; Mon, 15 Feb 1993 17:58:43 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930215175811.288; 15 Feb 93 17:58:24 -100
Message-Id: <MAILQUEUE-101.930215175806.256@sofus.dhhalden.no>
To: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.ZIB-Berlin.DE, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 15 Feb 93 17:58:06 +0100
Subject: Re: What are the goal of MOOSE
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> =>Yes, but how should we enforce a standard user interface for the apps, if
> =>we don't put some restrictions on what can be done. (See my part with
> =>WordPerfect) Without a standard ui, it will not get accepted.
>
>    Hmmm. Probably true. We should certainly at least set up a basic
> framework for manipulating objects in the GUI. However, I'm not sure
> application developers would appreciate us forcing them into a
> straightjacket when they want to write a program.

The user will probably appreciate us for forcing the developers into a
strightjacket :-)
The goal must be, as I see it, to provide the user with a homogenous
interface, whether in text or graphics, and to provide the programer with
a set of classes that will enforce a homogenous interface, and still
make it flexible to use/customizable and easy to program.

If the OS is going to be multitasking, we must be able to present information
from several tasks at a time. The need for threading will be minimized if
the user can't work with several programs at a time.
We all agree we must use multitasking and threading. It is still possible to
do this in a completly text-based os, but it will not be as effective as in
a graphics based os(, for the user).
The ideal thing were if everybody had 21'' monitors with accelerated
graphics card beeing able to handle resolutions greater than 1000 in every
direction, but that's ideal, isn't it.

> =>Got to do some work.
>    What's that? :-)
Look in a dictionary. That's the way I learned the meaning of the word. :-)

Somebody is missing me at his mailing list, could you please fix it?

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--


From csjjlay@knuth.mtsu.edu Mon Feb 15 22:57:33 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA21836; Mon, 15 Feb 93 22:57:32 +0100
Return-Path: <csjjlay@knuth.mtsu.edu>
Received-Date: Mon, 15 Feb 93 22:57:32 +0100
Received: from knuth.mtsu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by knuth.mtsu.edu (Smail3.1.28.1 #6)
	id m0nODpt-000d50C; Mon, 15 Feb 93 15:58 CST
Message-Id: <m0nODpt-000d50C@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: MUSIC revision -INFINITY
To: haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
Date: Mon, 15 Feb 1993 15:58:44 -0600 (CST)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 4501      
Status: OR

JJ Lay said:
>From csjjlay Mon Feb 15 15:58:25 1993
Message-Id: <m0nODpV-000d51C@knuth.mtsu.edu>
From: csjjlay (JJ Lay)
Subject: MUSIC revision -INFINITY
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
	dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com
Date: Mon, 15 Feb 1993 15:58:20 -0600 (CST)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3390      
Content-Length: 3390


Welcome to:

		MUSIC - MOOSE USer InterfaCe

What follows is a set of general guidelines for building the user
interface.  Feel free to flame me if I left out something
important (because I did).  This was written to help move this
group along in writing specifications documents.

MUSIC will be a completely graphical user interface.  There will
be no command line prompt whatsoever UNTIL the gui is finished.
This I feel is the fundamental problem with current OS's.  They
write and OS using a text command prompt and then slap the GUI
on next.

I. What the user sees
	All system objects will be represented as icons on the
	screen.  These include but are not limited to:
	* Data Objects
	* Directories
	* Executable Objects
	* Processes
	* Devices

	Processes communicate to a user via Windows.  Windows
	can hold: buttons, switches, text, etc.  i.e., anything!
	Windows can have menus: both pulldown and popup.

II. How the processes get input
	The user interface will be event driven.  The objects
	will each have a routine that will be activated when a
	certain activity happens to them.  e.g., a window sits
	idle until the user clicks on the "Close" icon.  The
	window's Close_window routine is then called.  Keyboard
	input goes to the current active window or the Interface
	Manager depending on the situation.

III. How processes create these objects
	There will be an Interface Manager that keeps track of which
	processes own which windows and icons.  No process will be
	allowed access to another's windows or icons unless certain
	rules are followed.  e.g., the Root Window that will hold
	all other windows and icons will be declared as SHAREABLE by
	the Interface Manager so that other processes can use it.

IV. Some examples of things one can do
	Say a user needs to email a text file but wants to run it
	through a text formatter first.  She would click on the
	text formatting program icon to bring up a menu of methods
	that this icon has.  She chooses "OUTPUT TO:" and then
	clicks on the email program icon.  She chooses the text
	formatting icon again and this time chooses "INPUT FROM:"
	and clicks on the document.  The text formatter then formats
	the document, pipes it to the email program which takes it and
	asks for a "Destination address", "Subject", etc. and then
	mails it.
	This implies a building block type approach to shell programs.
	Even complex applications that follow all the rules can be used
	in this manner.

V. What is missing
	Everything!  This is a rough idea of some of the things our user
	interface will (should?) do.  I emailed this severely lacking
	document only to get more ideas and feedback.  Am I on the right
	track?  What else should there be?

	

							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team



							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team


From ANDREASA@sofus.dhhalden.no Tue Feb 16 12:02:42 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17887; Tue, 16 Feb 93 12:02:40 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Tue, 16 Feb 93 12:02:40 +0100
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <07620-0@fenris.dhhalden.no>; Tue, 16 Feb 1993 12:00:44 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930216120012.352; 16 Feb 93 12:00:25 -100
Message-Id: <MAILQUEUE-101.930216120002.320@sofus.dhhalden.no>
To: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.ZIB-Berlin.DE, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 16 Feb 93 12:00:02 +0100
Subject: Re: MUSIC revision -INFINITY
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> Welcome to:
>
>         MUSIC - MOOSE USer InterfaCe

Good name for it.

> MUSIC will be a completely graphical user interface.  There will
> be no command line prompt whatsoever UNTIL the gui is finished.
> This I feel is the fundamental problem with current OS's.  They
> write and OS using a text command prompt and then slap the GUI
> on next.

This is exactly what I feel.

I agree with part I.

> II. How the processes get input
>     The user interface will be event driven.  The objects
>     will each have a routine that will be activated when a
>     certain activity happens to them.  e.g., a window sits
>     idle until the user clicks on the "Close" icon.  The
>     window's Close_window routine is then called.  Keyboard
>     input goes to the current active window or the Interface
>     Manager depending on the situation.

I have been looking on a solution very similar to this, even though I maybe
have elaborated it more so please read.
I work with the graphics part, or have done so far. I have thought up a set
of classes. One of these classes is a window class (fantastic isn't it :-)
that has a number of functions of the type CloseIconClicked, MenuToggeled
etc. These functions will do the events transparent, and the developer don't
even need to know that the system is event driven.
The constructor in a class will take all event functions and put them in
lists. These lists will be mantained by the device drivers.
The mouse driver will mantain a list of functions, pointer to functions
actually, and whenever there is a click event, it will traverse its list
of items/functions that responds to a click, and when the mouse driver finds
an item that lies within the area of the mouse click, it will call the
functions.
How effective this will be, I admittably don't know, and I'm not sure I want
to know either. I'm affraid that having all input-devices scanning lists
all the time will be pretty time consuming.
Of course I have thought of this too :-)

(Mouse) Device Driver Item List
   |
   ------------------------------------------------ <- Window-list
            |
            | <- A window
  -------------------------------
  | <- Button  | <- ScrollBar   | <- Another Window
  0            0                |
                                |
                            --------- More Items...


Whenever the driver finds which Window-list the element are in, it starts to
traverse the windows "private" list for the items in this window, til it
finds an item, or til it finds out that the main window should have the
message.
How does this sound, a tree like structure in way?
This could be enforced for mice, keybords, com-ports, parallell-ports etc.
Only the type of classes will be important. The com-port device will have
a com-port class.
This list type thing could be implemented in at least one other way, that
might be better because it don't lend itself to much upon the driver, and
it is more OO, but the structure itself will mainly be mantained.
The driver has a list of pointers to objects, and the objects have pointers
to other objects inside themself. A recursive definition that will decrease
the work for the device driver.

> III. How processes create these objects
>     There will be an Interface Manager that keeps track of which
>     processes own which windows and icons.  No process will be
>     allowed access to another's windows or icons unless certain
>     rules are followed.  e.g., the Root Window that will hold
>     all other windows and icons will be declared as SHAREABLE by
>     the Interface Manager so that other processes can use it.

I'd rather put the owner rights into the main window. Then the main window can
ask it's childs for access to a resource. In addition I assume that there will
be functions for some sort of dual piping/dynamic information interchange, so
that one window can ask another window (even in another machine..., at
another part of the world..., or even in the space shuttle... :) for
information. This could include any type of information/data.

IV.

I can't say I agree very much with that part. I see the objects, but I'm not
sure that it is as much OO as possible. Lets discuss this part because
I'm not sure what's the best method, the Mac way, the NeXT way or the way
presented her.



V. Resource requirements for the GUI. Was: V. What is missing
Since this will be a GUI, the minimum display will be graphical. Now do we
think it is neccesary to support Hercules, CGA, EGA, PGA, MCGA? I say no.
If it is going to be a gui, the user will need all space he can get on his
screen, else there will be no place for him to do what he really wants.
Therefore I say minimum VGA resolution. But there are more things than
resolution to things. Colors are equally important. I see myself writting a
GUI with about 16 reserved colors, that a user can't alter (easily).
So if he wants to display a picture, he will have to use the system palette,
if he don't want to screw up the screen of course. Dithering will not be
satisfying because we need one color with several different brightnesses,
say 4 shades of gray a couple of shades of blue etc. So I say minimum SVga,
if that is ok for you of course. I belive that almost everybody that have a
386 also have a SVga card. This will give us 256 colors, minimum for any card.
If you really want, I can do some codeing for vga to, but it will be without
any joy...:-\
Flame of if you feel for it. I can take it (I hope :-)


VI. Design specifics.
Guideline no.1
The screen is a resource. The user has got a limited amount of it, therefore
the gui should enforce programs not to steal this screen area. The gui in
itself should not take more place than is neccessary.

Idea no. 1
Caption is the most unimportant tool in a window. A caption steals valuable
resources. So does the menu. The "best" way is the Mac way/the X-way, but it
isn't especially OO/easy. Therefore I suggest that we combine the menu and
the caption into one toggelable line, as the Amiga OS does.



VII. What is missing
Same as V. in last message :-)

type flames.txt  > andreasa@dhhalden.no

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--


From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Tue Feb 16 13:34:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20757; Tue, 16 Feb 93 13:34:25 +0100
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Tue, 16 Feb 93 13:34:25 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa11220; 16 Feb 93 7:27 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa27293;
          16 Feb 93 12:23 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa04751;
          16 Feb 93 12:21 GMT
To: JJ Lay <csjjlay@knuth.mtsu.edu>
Cc: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca,
        mueller@sc.zib-berlin.de, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
Subject: Re: MUSIC revision -INFINITY 
In-Reply-To: Your message of "Mon, 15 Feb 93 15:58:20 CST."
             <m0nODpV-000d51C@knuth.mtsu.edu> 
Date: Tue, 16 Feb 93 07:21:23 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302161221.aa04751@gloin.cis.udel.edu>
Status: OR

=>
=>Welcome to:
=>
=>		MUSIC - MOOSE USer InterfaCe
=>
=>What follows is a set of general guidelines for building the user
=>interface.  Feel free to flame me if I left out something
=>important (because I did).  This was written to help move this
=>group along in writing specifications documents.

   This is roughly the same vision of a GUI that I had in mind. Now,
assuming this basic GUI structure, what OS facilities do we need to
support it? We will need some method of communication between the
program object and the window object. Since window access is
restricted, we will need some method of authorization (authentication?)
in order to enforce the proper restrictions.
   We should not put the cart before the horse. An OS is not a GUI
(unless, of course, you take the Microsoft view.) Instead, let's keep
in mind that our horse is going to have to pull a cart, and spec out
the horse accordingly. Also, if we stick to the minimal kernel, object-
oriented idea, I should be able to ride the horse without having to
pull a cart behind me. A cart is no good without a horse (unless you
want to pull it yourself.) I'd extend the metaphor further, but that
would just be beating a dead horse. :-)
   I'm not sure that JJ's message went to the whole list, so I've
expanded the CC: field. If you got the reply and not the original, I
can send you a copy, if you like.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Tue Feb 16 14:52:59 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23472; Tue, 16 Feb 93 14:52:57 +0100
Return-Path: <ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Tue, 16 Feb 93 14:52:57 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa14334; 16 Feb 93 8:48 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa27648;
          16 Feb 93 13:44 GMT
Received: from sol.cis.udel.edu by ori.cis.udel.edu id aa03383;
          16 Feb 93 13:41 GMT
To: ANDREASA@dhhalden.no
Cc: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.zib-berlin.de, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
Subject: Re: MUSIC revision -INFINITY 
In-Reply-To: Your message of "16 Feb 93 12:00:02 +0100."
             <MAILQUEUE-101.930216120002.320@sofus.dhhalden.no> 
Date: Tue, 16 Feb 93 08:41:23 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302161341.aa03383@ori.cis.udel.edu>
Status: OR

=>> MUSIC will be a completely graphical user interface.  There will
=>> be no command line prompt whatsoever UNTIL the gui is finished.
=>> This I feel is the fundamental problem with current OS's.  They
=>> write and OS using a text command prompt and then slap the GUI
=>> on next.
=>
=>This is exactly what I feel.

   I must have missed this bit when I went through the original the
first time. Here I must disagree. There is no reason why a well
designed operating system should be specifically text-oriented or
graphics-oriented. A simple text interface would let us get the system
running sooner and allow for testing without having to wait for the GUI
to be completed. As long as we know that the text interface is not
going to be the primary user environment, we should be fine.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From UKCC.uky.edu!WKUVX1.BITNET!haydedr Tue Feb 16 17:31:04 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29015; Tue, 16 Feb 93 17:31:02 +0100
Return-Path: <UKCC.uky.edu!WKUVX1.BITNET!haydedr>
Received-Date: Tue, 16 Feb 93 17:31:02 +0100
Received: from ukcc.uky.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 8715; Tue, 16 Feb 93 11:29:14 EST
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 7844;
 Tue, 16 Feb 93 11:29:13 EST
Received: by WKUVX1.BITNET (MX V3.2-alpha) id 20913; Tue, 16 Feb 1993 10:30:36
          CST
Sender: haydedr@WKUVX1.BITNET
Date: Tue, 16 Feb 1993 10:30:33 CST
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
        mueller@sc.ZIB-Berlin.DE, mckeeveb@sfu.ca, garfield@sra.com,
        duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
        ANDREASA@sofus.dhhalden.no
Cc: haydedr@WKUVX1.BITNET
Message-Id: <0096836D.DA3B6D40.20913@WKUVX1.BITNET>
Subject: Re: What are the goal of MOOSE
Status: OR

>ANDREASA@dhhalden.no writes:
>
>If the OS is going to be multitasking, we must be able to present information
>from several tasks at a time. The need for threading will be minimized if
>the user can't work with several programs at a time.

Now, it seems to me that we can only have at most 1 process at any
given time whose logical devices are mapped on to the physical
devices.  Of course, in a graphical environment you can *see* multiple
things going on, but I don't see how we can have more than 1 window at
a time as the "foreground" window.  And, if we decide that only one
window is in the foreground at any time, then I think threading will
still be very beneficial.  In an application, for instance, I could
launch a thread to handle user I/O, another for disk files, etc.  This
acheives much better I/O overlapping, the system is more active, and
we just have better overall system concurrency.


>> =>Got to do some work.
>>    What's that? :-)
>Look in a dictionary. That's the way I learned the meaning of the word. :-)

Well hey, I'll have to check up on that sometime... (learn somethin
new every day!)

>
>Somebody is missing me at his mailing list, could you please fix it?

Oops, sorry I believe it was me.  My mailer says you're
andreasa@dhhalden.no, but your signature has .sofus in there.  Hope
you get this!

Ross Hayden
haydedr@wkuvx1.bitnet

From UKCC.uky.edu!WKUVX1.BITNET!haydedr Tue Feb 16 17:35:13 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29113; Tue, 16 Feb 93 17:35:11 +0100
Return-Path: <UKCC.uky.edu!WKUVX1.BITNET!haydedr>
Received-Date: Tue, 16 Feb 93 17:35:11 +0100
Received: from ukcc.uky.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 8764; Tue, 16 Feb 93 11:34:33 EST
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 8869;
 Tue, 16 Feb 93 11:34:33 EST
Received: by WKUVX1.BITNET (MX V3.2-alpha) id 20980; Tue, 16 Feb 1993 10:37:00
          CST
Sender: haydedr@WKUVX1.BITNET
Date: Tue, 16 Feb 1993 10:36:58 CST
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
        mueller@sc.ZIB-Berlin.DE, mckeeveb@sfu.ca, garfield@sra.com,
        duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
        ANDREASA@sofus.dhhalden.no
Cc: haydedr@WKUVX1.BITNET
Message-Id: <0096836E.BF87FD00.20980@WKUVX1.BITNET>
Subject: Re: Moose version -INFINITY
Status: OR

"Gary D. Duzan" <duzan@udel.edu> writes:
>
>=>
>=>Welcome to:
>=>
>=>             MUSIC - MOOSE USer InterfaCe
>=>

>   This is roughly the same vision of a GUI that I had in mind. Now,
>assuming this basic GUI structure, what OS facilities do we need to
>support it? We will need some method of communication between the
>program object and the window object. Since window access is
>restricted, we will need some method of authorization (authentication?)
>in order to enforce the proper restrictions.
>   We should not put the cart before the horse. An OS is not a GUI
>(unless, of course, you take the Microsoft view.) Instead, let's keep
>in mind that our horse is going to have to pull a cart, and spec out
>the horse accordingly. Also, if we stick to the minimal kernel, object-
>oriented idea, I should be able to ride the horse without having to
>pull a cart behind me. A cart is no good without a horse (unless you
>want to pull it yourself.) I'd extend the metaphor further, but that
>would just be beating a dead horse. :-)

But I thought it was a Moose! ;-)

Ross Hayden
haydedr@wkuvx1.bitnet

From dmarer@td2cad.intel.com Tue Feb 16 23:34:40 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08571; Tue, 16 Feb 93 23:34:39 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Tue, 16 Feb 93 23:34:39 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 16 Feb 93 14:30:46 -0800
Received: by td2cad (5.57/10.0i); Tue, 16 Feb 93 14:34:12 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00210; Tue, 16 Feb 93 14:40:58 PDT
Date: Tue, 16 Feb 93 14:40:58 PDT
Message-Id: <9302162240.AA00210@tdge15.intel.com>
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, dspascha@eos.ncsu.edu, duzan@cis.udel.edu,
        garfield@sra.com, haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca,
        mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu, rideau@clipper,
        winikoff@cs.mu.oz.au
Subject: 2/16/92 Moose Update
Status: OR

Howdy all!

	Well, it's me again - sorry I haven't put too much input into the
discussions this last week, but I've been busy with work, plus moving into a
brand new office!  My workstation is *finally* working, and I have waded
through the almost 45 messages I've received since last week....

	Sounds like we've got some great discussion going!  Let me just say
one thing to get started - for now, the name of this project is "Moose", and
will remain that until *much* further down the road.  We're all familiar with
it, it catches people's attention, and there's no reason to change yet.
No more discussion worrying about what it'll be called, since we haven't even
specified what it will do yet!  We can always pick a better name later.

	I did some research about the Motorola processors to see which one
should be used as our 'base' processor.  It appears as if the 68020 is the
idea choice, with good usage in PCs and other platforms.  There are some
pitfalls to beware of though - some of the MMU functions obtainable with the
68851 math coprocessor are *not* available in the 68030 (which has a built-in
math coprocessor), plus there is one instruction which has been omitted.  Not
a problem, as I understand most people didn't use this instruction anyway.
It supports full 32-bit addressing and data path, *nearly* equivalent to the
capability of the 386, IMHO.  We should have little trouble implementing
something on one chip which can't be easily duplicated on the other.  Looking
at the history of things, it seems Motorola included some of the more complex
stuff (memory management units, math copros) in their chips earlier on... :-)

	Many apologies about the first revision of the specs - there were a
lot of omissions and a lot of stuff which shouldn't have been there!  We'll
fill in the blanks later...I do want to clarify one thing: anything that
looked like an 'object' in that document was not intended to be part of the
kernel.  Eg, the 'timer' object and the 'semaphore' object were intended to
be *extensions* to the kernel, and not part of the kernel itself.  In the
next revision I'll separate the two more clearly, keeping the kernel as clean
and as pure as possible.

	One thing I've heard many of you mention is to make this less of an
object oriented operating system - I agree, the kernel should not be object
oriented.  There is even little benefit from making, for example, a task an
object within the system - however, I'd like to see the kernel to be able to
recognize objects though!  If, for instance, virtual memory were implemented,
the kernel might be provided with a hard drive object to swap to and from.
It can use objects in the system, but does not have to.  Seem like a good idea?

	I've been doing a little research into distributed processing also -
the idea of being able to use objects existing on other systems really
appeals to me.  In particular, display devices should be sharable among
networked systems (like X-Windows) so I'll propose a method of doing this
in the next revision of the specs.  (Just thought I'd tease you with that!)

	Another point of concern is whether or not this OS is going to be a
graphics based system or a text based system - that's a simple answer: neither!
The operating system should be written as if there are *no* devices connected
to the CPU, as if the entire machine were memory, basic interrupt and control
hardware, and the CPU.  Everything else, I mean *everything* else, is an
extension to the operating system.  This way the OS could be used for a server,
an embedded controller application, a run-of-the-mill PC, or the most
elaborate and complicated hardware setup without changing the kernel.  This
is the most practical design approach, and will also help porting to other
platforms.  If we want to make a GUI (which we probably will) this will be
as an extension.  We'll also want to make a text-based interface (either a
windowed interface like DesqView or a standard "terminal"-like interface) for
use in less interactive platforms, like servers, remote dialup, etc.

	Personal note: I can *guarantee* this system will work better and
have less bugs if we make this sort of distinction between kernel and 
extensions.  This is (IMHO) a major failing of OS/2 and Windows.  I also think
Windows NT would have benefited from being designed in this way, and would
gain more acceptance as the "universal" operating system for all platforms.
To be honest, I wouldn't be working on *this* project if it were. :-)

	I've been working on the next revision of the specifications, including
stuff I left out last time, adding all of your suggestions, and restructuring.
I'm also writing everything in the present tense (instead of the future tense)
so that when complete, these specs will also double as a programmers guide.
It will be nice to have a good portion of the documentation done before
anything else! :-]

	Thanx for the organization suggestions for the FTP site - still no
offers on free sites, so I've taken the liberty of setting up a site at a local
company which offers those services.  It costs only about $20/month to me, so I
don't mind paying this.  I'll act as the administrator, setting up the
directories and stuff, and there will be another FTPable account (with a
password) for each of you to log on with.  You'll be able to read info from
everywhere, but able to write only to limited areas.  There are some storage
charges ($0.04/kilobyte/month) so it's to my advantage to be the only person
with full access.  I'll let you all know when it's ready for use!

	One more thing - so far most of what I've written in the specs is the
programming interface to the kernel and basic extensions.  I think many of
you feel a more general overview needs to be included.  I need your input for
this portion, as I work better with the nuts and bolts, the actual functions
and calling interfaces of software.  Give me your suggestions of what to write,
and I'll write it - or, if you wish to write a portion of the specs, let me
know.  I'm content doing it myself with your input, but your writing skills
are also appreciated.  If you just want to write notes, I'll also transcribe
those into a "document" if you wish.  As you'll find out, I'm a real freak
about proper documentation - have I mentioned how much you'll need to comment
your source code...? :-(

	I expect it'll take about the next two weeks until the next revision
of the specs are done.  Let's talk more about what you expect they should
include, and when they're finished I'll upload them to the FTP site.  I'll be
keeping *three* copies of everything (on the FTP site, on my PC, and on floppy)
so there is little chance of losing everything!  We should also have an
'official' mailing list very soon.... (Rob, how is that coming? :-)

	Take care all, and keep those ideas flowing!

				Dennis



From winikoff@cs.mu.OZ.AU Wed Feb 17 00:47:19 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10687; Wed, 17 Feb 93 00:47:17 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Wed, 17 Feb 93 00:47:17 +0100
Received: from mulga.cs.mu.OZ.AU by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA16616
	Wed, 17 Feb 1993 10:36:46 +1100 (from winikoff)
Message-Id: <9302162336.16616@mulga.cs.mu.OZ.AU>
Subject: MOOSE -- more comments
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
Date: Wed, 17 Feb 93 10:36:45 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

Hi!
More comments from the land down under ...

------------------
Important things first ... why do we want a "serious" (read stuffy, suit etc.)
name? We've allready decided to target our OS at PROGRAMMERS not suits ...

------------------

MUSIC
~~~~~~

(1) Event driven -- yes. The actual method where the UIMS calls routines 
provided by the application is called "call back functions" and is the way X
does things. I'd prefer to do things the mac/Amiga way -- the application reads
from an input event queue and decides what to do with the stuff on it's own.
Why? Apart from concurrentcy problems (the driver shouldn't call a function 
while a previous function is executing otherwise we have to write programs with
concurrency in mind) call back functions are simply not as versatile.
The "language" used to declare them cannot be as flexible as a full programming
language which is what we have to play around with using the Mac/Amiga event
queue approach.

Regards Andreas' suggestion of having the device drivers call functions:
I don't like it (sorry!) -- it's essentially an implementation of call back
functions that slows down and more importantly complicates device drivers.


Oh, and in general avoid doing things the X way just in case we might end up 
like X -- 
   respectively; see {glob}).  2. [after the name of an earlier
   window system called `W'] An over-sized, over-featured,
   over-engineered and incredibly over-complicated window system
   developed at MIT and widely used on UNIX systems.
[TNHD]

(2) Pipes -- YES. The actual details of the user interface actions to do this
should perhaps be made simpler but the idea should definately be there.

--------------------

I agree strongly with Gary about putting the cart b4 the horse.
Since the system is designed to be flexible we should find that the kernel
we design should be capable fo supporting a GUI -- if this is not the case
then we have failed to produce a flexible and extensible system.

-------------------

I've just read through Dennis' latest post.
Great work! 
I'm looking forward to the next version (negative infinity plus one? :-)

one comment regards Motorola processors: There exist "EC" (economy) versions
of the processors which typically don't have MMUs -- unfortunately these are
used in Amigas which kinda makes virtual memory impossible on a run of the mill
Amiga.
(It is possible to upgrade to an MMU though ...)

I'll start work on an overview document -- hopefully I'll have it ready sometime
next week.

Keep up the good work and the discussions!

Michael

--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From udel.edu!udel.edu!duzan Wed Feb 17 00:50:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10769; Wed, 17 Feb 93 00:50:28 +0100
Return-Path: <udel.edu!udel.edu!duzan>
Received-Date: Wed, 17 Feb 93 00:50:28 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa07671;
          16 Feb 93 18:46 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa04648;
          16 Feb 93 23:45 GMT
To: "Dr. Hayden" <udel.edu!wkuvx1.bitnet!haydedr>
Cc: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
        mueller@sc.zib-berlin.de, mckeeveb@sfu.ca, garfield@sra.com,
        duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
        ANDREASA@sofus.dhhalden.no
Subject: Re: Moose version -INFINITY 
In-Reply-To: Your message of "Tue, 16 Feb 93 10:36:58 CST."
             <0096836E.BF87FD00.20980@WKUVX1.BITNET> 
Date: Tue, 16 Feb 93 18:45:12 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302162345.aa04648@sol.cis.udel.edu>
Status: OR

=>"Gary D. Duzan" <duzan@udel.edu> writes:
=>>   This is roughly the same vision of a GUI that I had in mind. Now,
=>>assuming this basic GUI structure, what OS facilities do we need to
=>>support it? We will need some method of communication between the
=>>program object and the window object. Since window access is
=>>restricted, we will need some method of authorization (authentication?)
=>>in order to enforce the proper restrictions.
=>>   We should not put the cart before the horse. An OS is not a GUI
=>>(unless, of course, you take the Microsoft view.) Instead, let's keep
=>>in mind that our horse is going to have to pull a cart, and spec out
=>>the horse accordingly. Also, if we stick to the minimal kernel, object-
=>>oriented idea, I should be able to ride the horse without having to
=>>pull a cart behind me. A cart is no good without a horse (unless you
=>>want to pull it yourself.) I'd extend the metaphor further, but that
=>>would just be beating a dead horse. :-)
=>
=>But I thought it was a Moose! ;-)

   Fine.

:%s/horse/moose/g
:%s/cart/sleigh/g

:-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Wed Feb 17 01:42:57 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12251; Wed, 17 Feb 93 01:42:56 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Wed, 17 Feb 93 01:42:56 +0100
Received: from mulga.cs.mu.OZ.AU by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA17902
	Wed, 17 Feb 1993 11:33:19 +1100 (from winikoff)
Message-Id: <9302170033.17902@mulga.cs.mu.OZ.AU>
Subject: MOOSE - and SANTA
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
        dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE,
        newlin@ecn.purdue.edu, rideau@clipper, winikoff@cs.mu.oz.au
Date: Wed, 17 Feb 93 11:33:19 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR


[Stuff about MOOSE's horses and carts/sleighs deleted]

Can anyone find a part of the system that we can name SANTA?

How about the user interface - Screen ANd Terminal Administrator? :-)


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From mckeeveb@sfu.ca Wed Feb 17 02:49:11 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13739; Wed, 17 Feb 93 02:49:09 +0100
Return-Path: <mckeeveb@sfu.ca>
Received-Date: Wed, 17 Feb 93 02:49:09 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from monashee.sfu.ca by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21200; Tue, 16 Feb 93 17:47:11 -0800
Received: by monashee.sfu.ca (920330.SGI/911001.SGI)
	for dspascha@eos.ncsu.edu id AA24782; Tue, 16 Feb 93 17:45:17 -0800
From: mckeeveb@sfu.ca
Message-Id: <9302170145.AA24782@monashee.sfu.ca>
Subject: MOOSE mailing list
To: duzan@udel.edu (Gary D. Duzan)
Date: Tue, 16 Feb 93 17:45:17 PST
Cc: ANDREASA@dhhalden.no, dmarer@td2cad.intel.com, duzan@cis.udel.edu,
        garfield@sra.com, udel.edu!wkuvx1.bitnet!haydedr, mckeeveb@sfu.ca,
        newlin@ecn.purdue.edu, danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.zib-berlin.de, rideau@clipper, csjjlay@mtsu.edu,
        dspascha@eos.ncsu.edu
In-Reply-To:  <9302161341.aa03383@ori.cis.udel.edu>; from "Gary D. Duzan" at Feb 16, 93 8:41 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

OK, I've set up a mailing list for those involved with MOOSE.

It's address: moose-programmers@sfu.ca
Subscriptions: owner-moose-programmers@sfu.ca

I'll add everyone who is currently receiving this mailing
unless I get requests otherwise.

-- 
-Rob McKeever	rmckeeve@sfu.ca
                mckeeveb@sfu.ca



From mueller@sc.ZIB-Berlin.DE Wed Feb 17 14:10:43 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09386; Wed, 17 Feb 93 14:10:40 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 17 Feb 93 14:10:40 +0100
Received: from sc.ZIB-Berlin.DE by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA23826; Wed, 17 Feb 93 14:07:45 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA01036; Wed, 17 Feb 93 14:07:44 +0100
Date: Wed, 17 Feb 93 14:07:44 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9302171307.AA01036@sc.zib-berlin.dbp.de>
To: ANDREASA@dhhalden.no, danodom@matt.ksu.ksu.edu, dmarer@sc9.intel.com,
        duzan@cis.udel.edu, garfield@sra.com, haydedr@wkuvx1.bitnet,
        mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu,
        rideau@clipper, winikoff@cs.mu.oz.au
Subject: A few thoughts ...
Status: OR

Hello Moose World!

I think, I'm currently the only one who is not able to
give 150 % of his time for the project. So I get bombed
with your mails. Thanks folks, it was a great 
literature!

What I've recognized so far are several ideas, thoughts,
and hick-hacks about so many things. There are talks about
which graphic card to use or which language is the best or
how to develop a nice GUI or TUI. Sorry, I feel we should
concentrate more on general design decisions. How can you
design a GUI when you're not knowing the basics?

I've expected more discussion about the kernel. How should
process execution and interprocess communication (what about
[remote] object invocation?) be implemented? How is it possible
to make the kernel as small and "featherweight" as possible?
What about deviding the kernel into a second part: A Nucleus
which only implements process execution and powerful and efficient
interprocess communication (which should be in fact be treated as
a message to an object). Then there is the kernel, providing 
additional functionality as Memory Management. Why should all
such memory stuff like virtual, shared, etc. be implemented within
the nucleus or even the kernel? What about a user who doesn't need
virtual memory, because his/her applications are small? Must he/she
live with a performance lack, because the system runs all through
the virtual memory manager's code?

What about the interface TO the kernel? How should this be 
designed? How do you want to contact remote objects? One solution
is to provide name server objects, which can be connected 
hierarchical. What about object migration? Message passing?

Well, sorry that I wrote this damping mail. And please, I don't
want to kill your euphoria. Keep the discussion running and let me
hear your thoughts.

Thanks for your time,

Peter

From dmarer@td2cad.intel.com Sat Feb 20 01:09:13 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29635; Sat, 20 Feb 93 01:09:12 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Sat, 20 Feb 93 01:09:12 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21067; Fri, 19 Feb 93 16:01:55 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Fri, 19 Feb 93 16:01:30 -0800
Received: by td2cad (5.57/10.0i); Fri, 19 Feb 93 16:04:59 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01857; Fri, 19 Feb 93 16:11:49 PDT
Date: Fri, 19 Feb 93 16:11:49 PDT
Message-Id: <9302200011.AA01857@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: This is a test of the Moose broadcasting system...
Status: OR

Howdy all!

	Please respond ASAP when you receive this!

				Dennis

From mueller@sc.ZIB-Berlin.DE Mon Feb 22 10:12:33 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA05493; Mon, 22 Feb 93 10:12:32 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 22 Feb 93 10:12:32 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24641; Mon, 22 Feb 93 01:09:37 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA03356; Mon, 22 Feb 93 09:31:12 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA00257; Mon, 22 Feb 93 09:31:11 +0100
Date: Mon, 22 Feb 93 09:31:11 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9302220831.AA00257@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Test
Status: OR

Hello, 

I think, I'm in trouble with my mail server. Could
you please send an ACK, wehen you received this?

Thanks,

Peter

From UKCC.UKY.EDU!WKUVX1.BITNET!haydedr Mon Feb 22 14:38:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14433; Mon, 22 Feb 93 14:38:23 +0100
Return-Path: <UKCC.UKY.EDU!WKUVX1.BITNET!haydedr>
Received-Date: Mon, 22 Feb 93 14:38:23 +0100
Received: from ukcc.uky.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from UKCC.UKY.EDU by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 6039; Mon, 22 Feb 93 08:37:45 EST
Received: from WKUVX1.BITNET (NJE origin MXMAILER@WKUVX1) by UKCC.UKY.EDU
 (LMail V1.1c/1.7e) with BSMTP id 3669; Mon, 22 Feb 1993 08:37:44 -0500
Received: by WKUVX1.BITNET (MX V3.2-beta) id 8940; Mon, 22 Feb 1993 07:40:28 CST
Sender: haydedr@WKUVX1.BITNET
Date: Mon, 22 Feb 1993 07:40:26 CST
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: winikoff@cs.mu.oz.au, rideau@clipper, newlin@ecn.purdue.edu,
        mueller@sc.ZIB-Berlin.DE, mckeeveb@sfu.ca, garfield@sra.com,
        duzan@cis.udel.edu, dmarer@td2cad.intel.com, danodom@matt.ksu.ksu.edu,
        ANDREASA@sofus.dhhalden.no
Cc: haydedr@WKUVX1.BITNET
Message-Id: <0096880D.14DD53C0.8940@WKUVX1.BITNET>
Subject: Is the mailing list working?
Status: OR

Hey all,

I haven't received any mail from anyone in almost two weeks, but I
have received a few test messages from people who don't think their
mailers are working.

This leads me to believe there may be something wrong with
moose-programmers@sfu.ca.  I haven't received any mail from there.  Is
is just me?

Thanks,
Ross Hayden

From dmarer@td2cad.intel.com Mon Feb 22 16:44:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19424; Mon, 22 Feb 93 16:44:28 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Mon, 22 Feb 93 16:44:28 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA29673; Mon, 22 Feb 93 07:39:46 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Mon, 22 Feb 93 07:39:44 -0800
Received: by td2cad (5.57/10.0i); Mon, 22 Feb 93 07:43:21 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA02015; Mon, 22 Feb 93 07:50:08 PDT
Date: Mon, 22 Feb 93 07:50:08 PDT
Message-Id: <9302221550.AA02015@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: The Moose line - seems to be working.
Status: OR

Howdy all!

	Just to drop a quick note - seems like I've heard replies from most of
you from my first test of the Moose mailing list.  If you didn't know, its:

		moose-programmers@sfu.ca

	Thanx to Rob McKeever (mckeeveb@sfu.ca) for setting this up for us!

	Yes, it has been very quiet the past week - I've only gotten a handful
of messages discussing the Moose stuff.  I guess everyone is busy writing down
ideas, eh?  The specs are coming along slowly (couldn't work on them all
weekend) but surely.  Also have ordered tons of more information on the 386,
and will be getting info soon on the Motorola chips as well.

	I hope this silence means you're all busy working up ideas!  I expect
to have the new rev of the specs done by Monday the 1st of March (next Monday).
Keep your ears peeled!

				Dennis

From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon Feb 22 18:57:18 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25091; Mon, 22 Feb 93 18:57:17 +0100
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 22 Feb 93 18:57:17 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06184; Mon, 22 Feb 93 09:25:27 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa25746;
          22 Feb 93 12:22 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa01403;
          22 Feb 93 17:19 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa22302;
          22 Feb 93 17:14 GMT
To: moose-programmers@sfu.ca
Subject: Re: Returned mail: Service unavailable 
In-Reply-To: Your message of "Wed, 17 Feb 93 17:00:43 +1100."
             <9302212317.29041@mulga.cs.mu.OZ.AU> 
Date: Mon, 22 Feb 93 12:14:41 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302221714.aa22302@bifur.cis.udel.edu>
Status: OR


   Anyone want to explain this message?

=>   ----- Transcript of session follows -----
=>While talking to whistler.sfu.ca:
=>>>> RCPT To:<moose-programmers@sfu.ca>
=><<< 554 :include:up... Cannot open up: No such file or directory
=>554 moose-programmers@sfu.ca... Service unavailable

=>I mailed this a while back and haven't seen it or responses to it.
=>Just in case it wasn't forwarded to everyone I'm remailing it now.

   I don't recall seeing it before, so it is good that you resent it.

=>> Regards writing the kernel in assembler -- we can break the kernel up into
=>> machine dependent and machine independent parts and write only the former i
n
=>> assembler.
=>> 
=>> I think the less assembler we use the better.

   I'm afraid Dennis will be feeling like we are ganging up on him by
now. :-/

=>> As our resident time lord has pointed out there is very little on processes
=>> and IPC.

   Well, without them we'd be redesigning MS-DOS. We don't want that, now
do we? :-]

=>> > most restricted "user" level.  All memory allocated will be
=>> > accessible only by the requesting task and its parent or children
=>> > tasks, allowing no other tasks access to this memory.
=>> 
=>> No. I don't like allowing other tasks access to memory by default.
=>> I'd rather that the default was no access and that shared memory was explic
itly
=>> requested.

   Agreed. Personally, I'd rather not expose the user to shared memory
at all.

=>> I like the MEM_PHYSICAL flag.

   If we restrict it properly, it could be useful. We may also want a
MEM_PERSIST flag to indicate that a page should be written to stable
media soon after modification (though I'm not certain how easy this
would be to implement.)

=>> > 'size' parameter.  To simplify and expedite memory management, only
=>> > large chunks of memory will be allocated at one time, usually
=>> > varying between 1k and 8k in size, depending on the host platform.
=>> 
=>> This is a implementation decision. I feel that we should either
=>> (1) Make a fixed decision across all platforms
=>> Or preferably
=>> (2) Design the system in such a way that the size of memory allocation does
=>> not make a difference to the user.

   I'd suggest the latter, and while not explicitly stated, I think it
is implied above.

=>> >      The starting address of the memory block will be returned by
=>> > this function.  If the allocation fails a null address is returned,
=>> > indicated by an address of zero.
=>> 
=>> Firstly there is scope for a bug here -- consider what happens if the syste
m
=>> allocates a task memory beginning at (virtual) memory location 0 ...

   Simple enough to fix: just don't do that. :-)

=>> Secondly and more importantly we need a system wide standard facility for
=>> communicating back error types and causes -- In order to have sensible 
=>> error reporting we need to return some kind of error code.

   Agreed. If it can be integrated with language-based exception
mechanisms, even better.

=>> > E. System Clock and Event Scheduling
=>> > 
=>> > >> How should this be done?
=>> 
=>> Have a device to handle this. 

   Maybe we should call them "system modules" instead of "devices". The
latter can be a subset of the former, that being the set of scheduled
objects with special system priveleges.

=>> > F. Interrupt Handling
=>> > 
=>> > >> How should this be done?
=>> 
=>> I favor a simple interrupt routine that "converts" an interrupt to a messag
e.
=>> Of course some interrupts WILL need to be handled by an interrupt routine b
ut
=>> in general they should be converted into messages.
=>> I feel that this will simplify the writing of device drivers.

   Agreed.

=>> Objects:
=>> I like the approach of simply defining a standard format.

   Abstract classes?

=>> > from its sleep and may enter its critical section.
=>> > 
=>> > 	semaphore@Down()
=>> > 
=>> 
=>> Why the "@" in semaphore@Down ?

   I would assume it is meant to be a method activation operator (i.e.
invocing method "Down" of object "semaphore".)

=>> Nothing is said about how semaphores are created/destroyed.
=>> More seriously nothing is said about how semaphores end up being shared
=>> between two tasks.

   Assuming we have an object name space, they could be located and
referenced like any other object (however that turns out to be.)

=>> Should we have spinlocks too?

   They probably wouldn't buy us a whole lot in a single processor
system.

=>> User input:
=>> 	It is useful to be able to insert input filters -- processes through
=>> 	which input events pass before being sent to their destination.
=>> (Uses: Screen savers, macro recorders, shortcuts ...)

   This shouldn't be particularly difficult.

=>> File systems:
=>> 	One issue that hasn't been raised is crash recovery.
=>> 	I suggest people have a look at Amoeba's file system -- they store
=>> 	files contiguously sacrificing disk space for speed.

   Keep in mind that Amoeba file servers also have 128 Meg of RAM. I
don't think Amoeba's file system design decisions are appropriate to
this project, though we can always add it later. We do need to keep
failures in mind, though.

=>> ----------------------------------
=>> 
=>> Libraries:
=>> 	I'm sorry. I didn't understand this too well.
=>> 	Can you please explain them. 
=>> 	IN particular I'm uncertain as to the difference between objects and 
=>> 		libraries -- libraries seem to be just typed objects which
=>> 		sounds like what you were trying to avoid in ...

   My guess would be that libraries are meant to be linked (or mapped)
into objects' virtual space to provide functionality via standard
function calls, while objects would provide functionality via an IPC
mechanism. Providing IPC via libraries can be a powerful technique,
allowing access to system objects through normal language mechanisms.
However, it can also be a language trap when the library becomes the
standard interface (e.g. Unix/C.)

=>> >   So what language do we write the high-level stuff in? Should it
=>> > matter? Can we make it not matter?
=>> 
=>> We MUST make it not matter. An OS that only supports one language isn't goi
ng
=>> to be useful.

   I didn't mean to imply that we should only support one high-level
language; I meant to point out that our choice of high-level
implementation language could shape the overall high-level perception
of the system. On the other hand, if we did it right, it might not.

=>> I disagree - I feel that the kernel should be designed first with the
=>> applications in mind.
=>> Lets face it -- this is a chicken and egg problem: The kernel and the
=>> applications (including device drivers) depend on each other's design.
=>> The solution is to start with the kernel (which doesn't actually use the de
vice
=>> drivers and so can be designed without knowing the precise interface) and t
hen
=>> designing the device drivers. This process is then iterated to a fixpoint.

   I think the only real solution is to design the whole system
together. Naturally, the kernel will have to be built first, followed
by system objects and some native development tools, and then the GUI
and applications. The simpler we make the kernel, the sooner we can get
to the higher-level work, but we need to be certain that we have the
proper low-level tools to build our applications.

=>> Regards the Mac OS being in ROM - we can simply let it boot and THEN take o
ver.

   And after all that work that Apple put into it. :-)

=>> (1) What audience are we aiming this OS at?
=>> 	My original understanding was standalone PCs but then you mentioned
=>> 	various network drivers.

   I'd guess that in 5 years you will be hard pressed to find a
standalone PC. People are starting to discover services like Prodigy
(no laughing or vomitting, please :-) and I'd imagine that the trend
will continue.  Eventually, fiber optics will allow data networking for
most homes, and businesses are already tending toward PC LANs. I'd say
that we are missing a great opportunity if we ignore networking in our
design.

=>> 	Do we plan to support (Eg.) diskless workstations?

   I wouldn't call it a priority, but I don't see why we couldn't do it.

=>> (2) We need to have a configuration facility to make installation of new 
=>> 	software/devices/hardware totally painless.

   This is an impossible goal on the ISA architecture. :-(

=>> 	(1) An application doesn't need to know what it's running on

   A computer, of course, silly. :-)

=>> Persistent objects subsume both processes and files.
=>> Getting rid of the concept of the files is (IMHO) a strong forward step.

   Don't let John Ousterhout hear you say that. :-)  (Inside Joke Alert!)

=>> One idea which may simplify swapping is to use a single address space acros
s
=>> all objects -- possibly even the one corresponding to where they are stored
=>> on disk.

   There is certainly a need for a global naming scheme, but I'd be
wary of using pointers in a heterogeneous networked system. Also, some
architectures would support single address spaces better than others.
There may also be a danger of running out of address space (though 32
bits should do for the average user.)

=>> (5) Objects must be first class -- we MUST be able to store objects in vari
ables	, pass 'em to functions etc.
=>> 	The implementation will of course use pointers. This might be a good
=>> 	place to start thinking about capabilities.

   Capabilities are certainly worth considering, especially in an object-
oriented system: You get object naming and access control in one shot.
I'm not sure how you would relate them to pointers.

=>> (6) Security: It hasn't been mentioned yet.
=>> 	Do we want it?
=>> 	To what degree?

   If we are going to support networking, we should have it.
Regardless, we need interface controls to keep the system stable in the
presense of anti-social programs. A capability-based security system
like Amoeba's shouldn't cost too much if we optimize for the local
case.

=>> (7) I/O redirection:
=>> 	Idea: Have the following convention: when an object is started it 
=>> 	is given by it's creator the objects representing stdin stdout etc.
=>> 	(It may be more appropriate to think of screen, kbd etc.)
=>> 	This lets us easily do I/O redirection -- simply have the shell
=>> 	substitute say, a file for the keyboard or a printer for the screen etc
.
=>> 
=>> 	[Note: The list of initial objects could perhaps include ALL objects 
=>> 	used (Eg. file system) for maximum flexibility -- this would then also
=>> 	let us run a program in an isolated environment ... good defence agains
t
=>> 	trojan horses]

   This is certainly worth considering. Of course, if we get rid of the
concept of a file, then we won't have a "file system", we'll have an
object name space, which is a more general concept (though an equivalent
one, given the Unix purist (e.g. Ousterhout) view.)

=>> (8) Microkernel:
=>> 	Seems to be the way we're heading. Good.
=>> 	
=>> 	* Efficient IPC is important

   Immensely, given a large number of medium to light weight objects.

=>> 	* Possible interface:
=>> 		send	-- sends a message to an object
=>> 		receive	-- returns the next object. Pauses caller if none
=>> 				available.
=>> 		call	-- Like a send but does a context switch to the receive
r
=>> 			for extra speed 

   Standard non-blocking semantics?

=>> (9) Process communication and synchronisation -- a proposal
=>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=>> 		
=>> Comments?

   Do we really have the need to pass structures with pointers between
objects? The Mach approach might be more fitting: map messages from the
sender's address space into the recipient's address space and send a
pointer to the mapped space to the recipient (when the message is large
enough to justify the overhead of mapping.) Generally, I prefer to stick
to communication semantics rather than ad hoc shared memory communication.

=>> (10) Do we support distributed applications? How?

   A complicated question. As long as we provide good communication
semantics, we could build the support on later.

=>> (11) Where is non-deterministic behavior expressed and how?

   It is generally expressed in humans, from my experience. :-)

=>> (12) Do we support some notion of "signal" -- ie. pre-empting messages?
=>> 	Should we? (I don't know)
=>> 
=>> (13) Should we be providing threads? (I don't think so but am open to debat
e)

   I'm a member of the Threads/Blocking RPC camp as opposed to the
Message Passing camp. Under this philosophy, signals could be
implemented as calls to a control thread (which could potentially fork
another thread to handle the signal.) I believe that system objects can
certainly benefit from multithreading, and it can be a powerful tool
for programming in general.

=>> Last but not least ... the name MOOSE.
=>> 
=>> I like it. It's MEMORABLE.
=>> 
=>> Can people please tell me why they don't like the name?
=>> [Or if they do like it please speak up!]

   I've given up my name-changing campaign. There was no concensus at
all in the straw poll, and it isn't too bad, I guess.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Tue Feb 23 01:17:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07028; Tue, 23 Feb 93 01:17:26 +0100
Return-Path: <dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Tue, 23 Feb 93 01:17:26 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08807; Mon, 22 Feb 93 16:09:50 -0800
Resent-Message-Id: <9302230009.AA08807@whistler.sfu.ca>
Received: from sol.cis.udel.edu by louie.udel.edu id aa13488;
          22 Feb 93 19:02 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa09272; 23 Feb 93 0:00 GMT
Received: from sol.cis.udel.edu by dori.cis.udel.edu id aa03431;
          22 Feb 93 23:56 GMT
Received: from louie.udel.edu by sol.cis.udel.edu id aa04798;
          22 Feb 93 20:07 GMT
Received: from hermes.intel.com by louie.udel.edu id aa02639;
          22 Feb 93 15:03 EST
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Mon, 22 Feb 93 11:21:03 -0800
Received: by td2cad (5.57/10.0i); Mon, 22 Feb 93 11:24:36 -0800
From: Dennis Marer <dmarer@td2cad.intel.com>
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA02085; Mon, 22 Feb 93 11:31:24 PDT
Date: Mon, 22 Feb 93 11:31:24 PDT
Message-Id: <9302221931.AA02085@tdge15.intel.com>
To: duzan@udel.edu
Subject: Just can't get enough of that Moose!
Resent-To: moose-programmers@sfu.ca
Resent-Date: Mon, 22 Feb 93 18:55:57 -0500
Resent-From: "Gary D. Duzan" <duzan@udel.edu>
Status: OR

Howdy all!

	Yet another message here...

>Do I have to do anything to subscribe to the list service?  I thought I read
>something in a message sent to me that anybody who got that particular message
>had already been subscribed.  I have gotten two messages from
>postmaster@cs.mu.oz.au that say something like
>
>While talking to whistler.sfu.ca:
>>>> RCPT To:<moose-programmers@sfu.ca>
><<< 554 :include:up... Cannot open up: No such file or directory
>554 moose-programmers@sfu.ca... Service unavailable
>
>and then a forwarded message containing some discussion regarding Moose.

	I was getting these messages too for a while - doesn't seem to happen
now.  You're all already subscribed, and can use this address to send mail!
Give it a whirl!

> =>> Regards writing the kernel in assembler -- we can break the kernel up into
> =>> machine dependent and machine independent parts and write only the former i
> n
> =>> assembler.
> =>> 
> =>> I think the less assembler we use the better.
> 
>    I'm afraid Dennis will be feeling like we are ganging up on him by
> now. :-/

Nope - not a problem.  I understand dislike for assembly because traditionally
it's more difficult to implement and maintain.  

I'd still like to see it written in assembler though... :-)  My basic reason
for this is speed and space efficiency.  I don't know how to argue this...
let me think on it!

> =>> As our resident time lord has pointed out there is very little on processes
> =>> and IPC.
> 
>    Well, without them we'd be redesigning MS-DOS. We don't want that, now
> do we? :-]

Yikes!  No thank you!  I've still only got a little on IPC and processes, so
throw your ideas in *now*.  I've got most of the process management in the
new revision of the specs, but I'm drawing a blank on IPC and shared memory.

> =>> > most restricted "user" level.  All memory allocated will be
> =>> > accessible only by the requesting task and its parent or children
> =>> > tasks, allowing no other tasks access to this memory.
> =>> 
> =>> No. I don't like allowing other tasks access to memory by default.
> =>> I'd rather that the default was no access and that shared memory was explic
> itly
> =>> requested.
> 
>    Agreed. Personally, I'd rather not expose the user to shared memory
> at all.

On second thought, you are correct.  When a child process allocates some memory
its parent should not have access to it.
 
> =>> I like the MEM_PHYSICAL flag.
> 
>    If we restrict it properly, it could be useful. We may also want a
> MEM_PERSIST flag to indicate that a page should be written to stable
> media soon after modification (though I'm not certain how easy this
> would be to implement.)

Hey neat!  I like that idea!  Persistent objects in the making...

How are we going to restrict these sorts of things?  It's easy to say a process
can have no more than, for example, 1 meg of non-virtual memory, but what if
it needs more than that?  Any suggestions?  Maybe its dependent on if the
process is a regular application, device driver, etc?

> =>> > 'size' parameter.  To simplify and expedite memory management, only
> =>> > large chunks of memory will be allocated at one time, usually
> =>> > varying between 1k and 8k in size, depending on the host platform.
> =>> 
> =>> This is a implementation decision. I feel that we should either
> =>> (1) Make a fixed decision across all platforms
> =>> Or preferably
> =>> (2) Design the system in such a way that the size of memory allocation does
> =>> not make a difference to the user.
> 
>    I'd suggest the latter, and while not explicitly stated, I think it
> is implied above.

Maybe we shouldn't even mention block size.  Yes, its an implementation issue
(sorry) cause the 386 works nicely for virtual memory in 4k blocks. :-)
This makes resizing memory blocks *very* easy...of course, somebody mentioned
is the MemoryResize() capability even necessary?  Yes, it's nice but is it
necessary?

> =>> >      The starting address of the memory block will be returned by
> =>> > this function.  If the allocation fails a null address is returned,
> =>> > indicated by an address of zero.
> =>> 
> =>> Firstly there is scope for a bug here -- consider what happens if the syste
> m
> =>> allocates a task memory beginning at (virtual) memory location 0 ...
> 
>    Simple enough to fix: just don't do that. :-)

NULL doesn't have to be zero either!  Even C accounts for the fact that if NULL
is *not* zero, statements like the following will work:

	char *p;

	if (!p)			/* check for NULL p */
	    do something;

Ok, so make no assumptions about what the value of a NULL pointer will be,
just that there exists one single address which is considered NULL (invalid).

On most systems, NULL will be zero (Motorola and Intel).  On the Intel, a
long pointer (segment:offset) of all zeros will cause a protection fault.
Short pointers (just offset) have to be dealt with the the tasks themselves.

Oh...are we going to call them tasks or processes?  I prefer tasks because of
the term multitasking.  Not important... :-)

> =>> Secondly and more importantly we need a system wide standard facility for
> =>> communicating back error types and causes -- In order to have sensible 
> =>> error reporting we need to return some kind of error code.
> 
>    Agreed. If it can be integrated with language-based exception
> mechanisms, even better.

Great!  I was thinking that, just no time to add it to the specs.

> =>> > E. System Clock and Event Scheduling
> =>> > 
> =>> > >> How should this be done?
> =>> 
> =>> Have a device to handle this. 
> 
>    Maybe we should call them "system modules" instead of "devices". The
> latter can be a subset of the former, that being the set of scheduled
> objects with special system priveleges.
> 
> =>> > F. Interrupt Handling
> =>> > 
> =>> > >> How should this be done?
> =>> 
> =>> I favor a simple interrupt routine that "converts" an interrupt to a messag
> e.
> =>> Of course some interrupts WILL need to be handled by an interrupt routine b
> ut
> =>> in general they should be converted into messages.
> =>> I feel that this will simplify the writing of device drivers.
> 
>    Agreed.

Sounds like a good idea...but we'd need to clarify the concept of a message.
Any takers?

> =>> Objects:
> =>> I like the approach of simply defining a standard format.
> 
>    Abstract classes?
> 
> =>> > from its sleep and may enter its critical section.
> =>> > 
> =>> > 	semaphore@Down()
> =>> > 
> =>> 
> =>> Why the "@" in semaphore@Down ?
> 
>    I would assume it is meant to be a method activation operator (i.e.
> invocing method "Down" of object "semaphore".)

Ummm...actually, just a notation I made up.  I means the method called 'Down'
in the object called 'semaphore'.  Sorry to be unclear about that - it was just
to distinguish it from any other function we might have called 'Down'.

> =>> Nothing is said about how semaphores are created/destroyed.
> =>> More seriously nothing is said about how semaphores end up being shared
> =>> between two tasks.
> 
>    Assuming we have an object name space, they could be located and
> referenced like any other object (however that turns out to be.)

This all boils down to the IPC and shared memory issue...

> =>> Should we have spinlocks too?
> 
>    They probably wouldn't buy us a whole lot in a single processor
> system.

What if we did go to a multiple processor system?  Wouldn't they be
transparent to the user?  (Forgive if this is my mistake...little rusty)

> =>> User input:
> =>> 	It is useful to be able to insert input filters -- processes through
> =>> 	which input events pass before being sent to their destination.
> =>> (Uses: Screen savers, macro recorders, shortcuts ...)
> 
>    This shouldn't be particularly difficult.
> 
> =>> File systems:
> =>> 	One issue that hasn't been raised is crash recovery.
> =>> 	I suggest people have a look at Amoeba's file system -- they store
> =>> 	files contiguously sacrificing disk space for speed.
> 
>    Keep in mind that Amoeba file servers also have 128 Meg of RAM. I
> don't think Amoeba's file system design decisions are appropriate to
> this project, though we can always add it later. We do need to keep
> failures in mind, though.

I've found a file system (experimental) which is (1) extremely quick compared
to FFS, (2) very efficient with disk space, and (3) quite recoverable in the
event of a crash!  It's called the Viva File System, and was developed by a
couple of graduate students.  When I get the FTP site set up, I'll put the
docs I've collected so far on VIFS (VIva File System) in there.  What it comes
down to is that if the system goes down while writing a file, you will
probably lose the data which was being written (of course) but everything else
is secure.  I think it's an ideal file system for this environment, but we'll
have to see.  It's still experimental (but has been tested)...

> =>> Libraries:
> =>> 	I'm sorry. I didn't understand this too well.
> =>> 	Can you please explain them. 
> =>> 	IN particular I'm uncertain as to the difference between objects and 
> =>> 		libraries -- libraries seem to be just typed objects which
> =>> 		sounds like what you were trying to avoid in ...
> 
>    My guess would be that libraries are meant to be linked (or mapped)
> into objects' virtual space to provide functionality via standard
> function calls, while objects would provide functionality via an IPC
> mechanism. Providing IPC via libraries can be a powerful technique,
> allowing access to system objects through normal language mechanisms.
> However, it can also be a language trap when the library becomes the
> standard interface (e.g. Unix/C.)

Open foot, insert mouth.  Sorry, I wrote the section on libraries a couple of
months ago, and just stuck it in at the last minute.  I'll be more clear...

> =>> >   So what language do we write the high-level stuff in? Should it
> =>> > matter? Can we make it not matter?
> =>> 
> =>> We MUST make it not matter. An OS that only supports one language isn't goi
> ng
> =>> to be useful.
> 
>    I didn't mean to imply that we should only support one high-level
> language; I meant to point out that our choice of high-level
> implementation language could shape the overall high-level perception
> of the system. On the other hand, if we did it right, it might not.

As long as the interface can be used by virtually any high-level language, it
*shouldn't* matter.  For example, no system call should use variable length
parameter lists [ void function(int a,...); ] because languages like Pascal
can't support them (very well).  

>> =>> Regards the Mac OS being in ROM - we can simply let it boot and THEN take o
> ver.
> 
>    And after all that work that Apple put into it. :-)

Maybe we could convice people to pry out that Mac ROM and stick in a more
generic one?  Hee hee.... :-)

> =>> (1) What audience are we aiming this OS at?
> =>> 	My original understanding was standalone PCs but then you mentioned
> =>> 	various network drivers.
> 
>    I'd guess that in 5 years you will be hard pressed to find a
> standalone PC. People are starting to discover services like Prodigy
> (no laughing or vomitting, please :-) and I'd imagine that the trend
> will continue.  Eventually, fiber optics will allow data networking for
> most homes, and businesses are already tending toward PC LANs. I'd say
> that we are missing a great opportunity if we ignore networking in our
> design.

One problem IBM PC/DOS has is no network support.  My brother makes a living
(full time) trying to keep a single small company's PC (both Macs and IBMs)
networked together.  This is a big job, and it shouldn't be.  I consider a
modem a "network device", and it should be treated any differently than a
FDDI fiber optic LAN.  Networking is the interconnectivity of computers,
not necessarily 50 office computers running from a single disk server (though
it could be), not my PC connected to a Cray-3 via fiber network (though I wish
it were :-), but maybe just one PC to another through a modem.

Hmmm...I may be putting my brother out of work here... :-(

> =>> (2) We need to have a configuration facility to make installation of new 
> =>> 	software/devices/hardware totally painless.
> 
>    This is an impossible goal on the ISA architecture. :-(

No - I disagree.  Nothing is impossible...just because it hasn't been done yet
doesn't mean we can't do it.  There has to be a way to accomplish it!  I just
don't know what that is yet... :-)



Anyway, just some thoughts.  Hopefully everything will be a *lot* more clear
in the next version of the specs.  Look for it a FTP sites in your neighborhood
in the near future! :-)  Take care...hope to hear some replies!

				Dennis

From dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Tue Feb 23 02:09:46 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08186; Tue, 23 Feb 93 02:09:45 +0100
Return-Path: <dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Tue, 23 Feb 93 02:09:45 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12630; Mon, 22 Feb 93 17:04:31 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa16272;
          22 Feb 93 19:54 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa09665; 23 Feb 93 0:50 GMT
Received: from sol.cis.udel.edu by dori.cis.udel.edu id aa03630;
          23 Feb 93 0:46 GMT
To: moose-programmers@sfu.ca
Subject: Re: Just can't get enough of that Moose! 
In-Reply-To: Your message of "Mon, 22 Feb 93 11:31:24 PDT."
             <9302221931.AA02085@tdge15.intel.com> 
Date: Mon, 22 Feb 93 19:46:14 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302230046.aa03630@dori.cis.udel.edu>
Status: OR

=>> 
=>>    Well, without them we'd be redesigning MS-DOS. We don't want that, now
=>> do we? :-]
=>
=>Yikes!  No thank you!  I've still only got a little on IPC and processes, so
=>throw your ideas in *now*.  I've got most of the process management in the
=>new revision of the specs, but I'm drawing a blank on IPC and shared memory.
=>
   In an object system, IPC is going to be vital.

=>>    If we restrict it properly, it could be useful. We may also want a
=>> MEM_PERSIST flag to indicate that a page should be written to stable
=>> media soon after modification (though I'm not certain how easy this
=>> would be to implement.)
=>
=>Hey neat!  I like that idea!  Persistent objects in the making...
=>
=>How are we going to restrict these sorts of things?  It's easy to say a proce
ss
=>can have no more than, for example, 1 meg of non-virtual memory, but what if
=>it needs more than that?  Any suggestions?  Maybe its dependent on if the
=>process is a regular application, device driver, etc?
=>
   System per-object quotas?

=>Oh...are we going to call them tasks or processes?  I prefer tasks because of
=>the term multitasking.  Not important... :-)
=>
   How about objects? It's an object-oriented system, right?

=>> =>> I favor a simple interrupt routine that "converts" an interrupt to a me
ssag
=>> e.
=>> =>> Of course some interrupts WILL need to be handled by an interrupt routi
ne b
=>> ut
=>> =>> in general they should be converted into messages.
=>> =>> I feel that this will simplify the writing of device drivers.
=>> 
=>>    Agreed.
=>
=>Sounds like a good idea...but we'd need to clarify the concept of a message.
=>Any takers?
=>
   Well, if what we have thought of as a processes/task is going to be
an object in our system, then a message (RPC call) is an object method
call (implementation details aside.)

=>> =>> > from its sleep and may enter its critical section.
=>> =>> > 
=>> =>> > 	semaphore@Down()
=>> =>> > 
=>> =>> 
=>> =>> Why the "@" in semaphore@Down ?
=>> 
=>>    I would assume it is meant to be a method activation operator (i.e.
=>> invocing method "Down" of object "semaphore".)
=>
=>Ummm...actually, just a notation I made up.  I means the method called 'Down'
=>in the object called 'semaphore'.  Sorry to be unclear about that - it was ju
st
=>to distinguish it from any other function we might have called 'Down'.
=>
   I thought I said that. :-)

=>> =>> Nothing is said about how semaphores are created/destroyed.
=>> =>> More seriously nothing is said about how semaphores end up being shared
=>> =>> between two tasks.
=>> 
=>>    Assuming we have an object name space, they could be located and
=>> referenced like any other object (however that turns out to be.)
=>
=>This all boils down to the IPC and shared memory issue...
=>
   Yep.

=>> =>> Should we have spinlocks too?
=>> 
=>>    They probably wouldn't buy us a whole lot in a single processor
=>> system.
=>
=>What if we did go to a multiple processor system?  Wouldn't they be
=>transparent to the user?  (Forgive if this is my mistake...little rusty)
=>
   Actually, spin locks don't need to bother with the OS at all. They
are a brute-force lock mechanism that can be implemented in any old chunk
of shared memory. We shouldn't have to worry about them for a while.

=>Hmmm...I may be putting my brother out of work here... :-(
=>
   I don't think he need worry just yet. :-)

=>> =>> (2) We need to have a configuration facility to make installation of ne
w 
=>> =>> 	software/devices/hardware totally painless.
=>> 
=>>    This is an impossible goal on the ISA architecture. :-(
=>
=>No - I disagree.  Nothing is impossible...just because it hasn't been done ye
t
=>doesn't mean we can't do it.  There has to be a way to accomplish it!  I just
=>don't know what that is yet... :-)
=>
   Well, I work in PC support and administration, and with IRQ, I/O,
RAM, ROM, and DMA settings and conflicts to deal with, the OS is
irrelevant.  Of course, once the hardware is sorted out and you have
the numbers, we should make it easy to configure the OS.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Tue Feb 23 05:24:43 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12932; Tue, 23 Feb 93 05:24:41 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 23 Feb 93 05:24:41 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19894; Mon, 22 Feb 93 20:17:22 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA17055
	Tue, 23 Feb 1993 15:16:58 +1100 (from winikoff)
Message-Id: <9302230416.17055@mulga.cs.mu.OZ.AU>
Subject: Re: Just can't get enough of that Moose!
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 23 Feb 93 15:16:56 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9302221931.AA02085@tdge15.intel.com>; from "Dennis Marer" at Feb 22, 93 11:31 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> >Do I have to do anything to subscribe to the list service?  I thought I read
> >something in a message sent to me that anybody who got that particular message
> >had already been subscribed.  I have gotten two messages from
> >postmaster@cs.mu.oz.au that say something like
> >
> >While talking to whistler.sfu.ca:
> >>>> RCPT To:<moose-programmers@sfu.ca>
> ><<< 554 :include:up... Cannot open up: No such file or directory
> >554 moose-programmers@sfu.ca... Service unavailable
> >
> >and then a forwarded message containing some discussion regarding Moose.

That's me -- sorry.
I at one stage sent a message to the mailing list b4 it was correctly setup
and had the message bounced.

Since I didn't have another copy of the message of the message I remailed the
bounce.

OH BTW - IF ANDREASA IS READING THIS CAN HE PLEASE REPLY TO ME?
I'VE HAD A NUMBER OF MESSAGES THAT I'VE SENT DIRECTLY TO HIM RETURNED TO ME
AFTER A WEEK


> Nope - not a problem.  I understand dislike for assembly because traditionally
> it's more difficult to implement and maintain.  

Traditionaly?!
Some people do seem to be able to handle assembler as well as high level
languages.
Us mortals however find HLLs a lot easier to use.

Oh - and you haven't mentioned portability ... :-)

> 
> I'd still like to see it written in assembler though... :-)  My basic reason
> for this is speed and space efficiency.  I don't know how to argue this...
> let me think on it!

The single counterargument I have is that efficiency in many cases is more a 
function of the algorithm then of the code -- a good paging algorithm in, say,
smalltalk will give better system performance then a bad one in assembler.

Of course this is not allways true and code size can occaisonly be reduced
by using assembler -- usually this is only becuase the compiler doesn't 
bother taking out library functions that aren't used.

Note that on RISC it is hard to do better then a good compiler ...

> >    Well, without them we'd be redesigning MS-DOS. We don't want that, now
> > do we? :-]

SHOCKHORRORFEARLOATHING :-)

> How are we going to restrict these sorts of things?  It's easy to say a process
> can have no more than, for example, 1 meg of non-virtual memory, but what if
> it needs more than that?  Any suggestions?  Maybe its dependent on if the
> process is a regular application, device driver, etc?

Hmmm. If we have virtual memory then the amount of physical memory used by the
process is irrelevant - of course the more memory thet is being used the more
paging but that;s life.

There is a problem with MEM_PHYSICAL -- the simplest solution is to only 
allow device drivers to use the flag and not place a limit -- we are working 
under the assumption that device driver writers know what they're doing.

> 
> Oh...are we going to call them tasks or processes?  I prefer tasks because of
> the term multitasking.  Not important... :-)

My feeling is that tasks are "lighter" things whereas processes are relatively
"heavy". If we are only going to support one form of process/task/thread then
the name doesn't really matter.

Process seems to be the more commonly used (at least in the Un*x world)

> > 
> >    Maybe we should call them "system modules" instead of "devices". The
> > latter can be a subset of the former, that being the set of scheduled
> > objects with special system priveleges.

Hmm. I think I detect the need for a glossary of terms :-)

> > =>> in general they should be converted into messages.
> > =>> I feel that this will simplify the writing of device drivers.
> > 
> >    Agreed.
> 
> Sounds like a good idea...but we'd need to clarify the concept of a message.
> Any takers?

Message: something that is sent to an object -- sort of like a call.
You could define it by it's operations:
	send(objectid,data)
	recieve(data,&sender's-id)

The open issue is how to comunicate the data -- if it's a few bytes all's well
for larger data you need to either set up a shared address space region or
copy the data.

> 
> Ummm...actually, just a notation I made up.  I means the method called 'Down'
> in the object called 'semaphore'.  Sorry to be unclear about that - it was just
> to distinguish it from any other function we might have called 'Down'.

Hmm -- shouldn't this be language dependant or are we just using a generic
notation for design purposes?

> >    Assuming we have an object name space, they could be located and
> > referenced like any other object (however that turns out to be.)
> 
> This all boils down to the IPC and shared memory issue...

Yes.

> 
> > =>> Should we have spinlocks too?
> > 
> >    They probably wouldn't buy us a whole lot in a single processor
> > system.

No they would -- a semaphore requires a system call whereas a spinlock doesn't.
This makes spinlocks significantly faster.

> 
> What if we did go to a multiple processor system?  Wouldn't they be
> transparent to the user?  (Forgive if this is my mistake...little rusty)

I'm not sure what exactly you mean.

Some things should be transparent to the user -- if two processes try to 
access a "file" simulatneuosly the system should do something sensible.

Spinlocks/semaphores are the mechanism used by the system to co-ordinate so 
this "something sensible" happens.

They are also used for writting applications that involve multiplt cooperating
tasks/processes.


> > =>> File systems:
> > =>> 	One issue that hasn't been raised is crash recovery.
> > =>> 	I suggest people have a look at Amoeba's file system -- they store
> > =>> 	files contiguously sacrificing disk space for speed.
> > 
> >    Keep in mind that Amoeba file servers also have 128 Meg of RAM. I
> > don't think Amoeba's file system design decisions are appropriate to
> > this project, though we can always add it later. We do need to keep
> > failures in mind, though.
> 
> I've found a file system (experimental) which is (1) extremely quick compared
> to FFS, (2) very efficient with disk space, and (3) quite recoverable in the
> event of a crash!  It's called the Viva File System, and was developed by a
> couple of graduate students.  When I get the FTP site set up, I'll put the
> docs I've collected so far on VIFS (VIva File System) in there.  What it comes
> down to is that if the system goes down while writing a file, you will
> probably lose the data which was being written (of course) but everything else
> is secure.  I think it's an ideal file system for this environment, but we'll
> have to see.  It's still experimental (but has been tested)...

Next question: Do we have some notion of transactions, atomicity etc.
(a 'la database systems)

> >> =>> Regards the Mac OS being in ROM - we can simply let it boot and THEN take o
> > ver.
> > 
> >    And after all that work that Apple put into it. :-)

And after all that work Micro$oft put into Windows ... :-)

> > =>> (1) What audience are we aiming this OS at?
> > =>> 	My original understanding was standalone PCs but then you mentioned
> > =>> 	various network drivers.
> > 
> >    I'd guess that in 5 years you will be hard pressed to find a
> > standalone PC. People are starting to discover services like Prodigy
> > (no laughing or vomitting, please :-) and I'd imagine that the trend
> > will continue.  Eventually, fiber optics will allow data networking for
> > most homes, and businesses are already tending toward PC LANs. I'd say
> > that we are missing a great opportunity if we ignore networking in our
> > design.

I was commenting on the choice of standards which (I think) were Unix type
standards. I (probly) am wrong here.

> > =>> (2) We need to have a configuration facility to make installation of new 
> > =>> 	software/devices/hardware totally painless.
> > 
> >    This is an impossible goal on the ISA architecture. :-(

Huh? Why? 

> 
> No - I disagree.  Nothing is impossible...just because it hasn't been done yet
> doesn't mean we can't do it.  There has to be a way to accomplish it!  I just
> don't know what that is yet... :-)

That's the spirit!!!!


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From ANDREASA@sofus.dhhalden.no Tue Feb 23 13:53:49 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03666; Tue, 23 Feb 93 13:53:47 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Tue, 23 Feb 93 13:53:47 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA00334; Tue, 23 Feb 93 04:50:18 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <27713-0@fenris.dhhalden.no>; Tue, 23 Feb 1993 13:50:08 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930223133940.480; 23 Feb 93 13:49:36 -100
Message-Id: <MAILQUEUE-101.930223133936.448@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 23 Feb 93 13:39:36 +0100
Subject: Some thoughts about MOOSE
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

There has been some discussion of the device, it's definition and how it
should work. I have already made a posting mainly regarding this in the
MUSIC thread.

I belive the OS should be made convenient for the programmer to work with.
There shouldn't be a large overhead to launch a small program, as in Windows.
It should be transparent for the programmer what environment he works with.
I.e. if he makes a UNIX program using ansi c, the program should be easliy
ported to Moose without any major changes.
It should be transparent that moose is eventdriven/message driven. And here
comes the part that I'd like to see implemented into Moose (not by myself:-).

What are the standard input devices:
 - Keyboard
 - Mouse
 - Com-port
 - Parallell-port
 - Networking (as I see it, Moose should support networking)
 - Any other??

Someone maybe would prefere to put some of the inputdevices into one device-
driver. How we should do this, I'll let others more competent to decide.
Take the keyboard. It is almost always used so it is a good example.
Say there are five tasks running. Two of them wants to scan the inputdevice
constantly, the application that has got input-focus and a screen saver.
In an eventdriven system, an application will wait for a message. If this
is a keyboard message it will branch over to a keyboard handling routine.
This is quite cumbersome for the programmer to do, that is my opinion anyway.

To make the scenario working the keyb. device must have some sort of list
to what tasks should get the message. Then it puts the message into the
message que to the application that has requested input.

If we make the system 100% OO, we could get around this smoothly.
The device still has a list, but not to event-ques but to an object.
The object that has requested input.
If we look at the application as a set of objects, there will be a main-
object, a window object etc. All these objects has inherited an input object.
An objects input part is activated whenever the user uses the keyboard.
The device tells the object what the input was.
Take a screen with two or more input-fields. If each input-field is an object
only the activated input-field gets the input.

I belive all input-devices could work in a similar fashion.

Any comments. Is it possible to do. I think if we could, there would be no
limit to the potential success of MOOSE among programmers, and that is the
door to go if we would like to see it used worldwide :-)

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From dmarer@td2cad.intel.com Tue Feb 23 18:03:45 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14477; Tue, 23 Feb 93 18:03:45 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Tue, 23 Feb 93 18:03:45 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 23 Feb 93 09:03:33 -0800
Received: by td2cad (5.57/10.0i); Tue, 23 Feb 93 09:07:08 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA02229; Tue, 23 Feb 93 09:13:57 PDT
Date: Tue, 23 Feb 93 09:13:57 PDT
Message-Id: <9302231713.AA02229@tdge15.intel.com>
To: rideau@clipper
Subject: Re: This is a test of the Moose broadcasting system...
Status: OR

Hi Fare',

	Just got your message, thanx!  I'll sit down and read it tonight or
tomorrow, it looks like there are a lot of good ideas there.  Take care and
keep in touch!

				Dennis

From cis.udel.edu!udel.edu!duzan Tue Feb 23 23:21:37 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27682; Tue, 23 Feb 93 23:21:36 +0100
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Tue, 23 Feb 93 23:21:36 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA04670; Tue, 23 Feb 93 14:16:34 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa17403;
          23 Feb 93 17:12 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa26029;
          23 Feb 93 22:11 GMT
Received: from sol.cis.udel.edu by bugs.cis.udel.edu id aa03863;
          23 Feb 93 22:10 GMT
To: Moose Project <moose-programmers@sfu.ca>
Subject: Re: Just can't get enough of that Moose! 
In-Reply-To: Your message of "Tue, 23 Feb 93 15:16:56 EST."
             <9302230416.17055@mulga.cs.mu.OZ.AU> 
Date: Tue, 23 Feb 93 17:10:03 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302232210.aa03863@bugs.cis.udel.edu>
Status: OR

=>
=>Traditionaly?!
=>Some people do seem to be able to handle assembler as well as high level
=>languages.
=>Us mortals however find HLLs a lot easier to use.
=>
=>Oh - and you haven't mentioned portability ... :-)
=>
   To be fair, the majority of the kernel itself will be doing hardware
twiddling, so there isn't as much cause to make it portable as the rest
of the system. It would, however, be a starting place for a port if it
were in an HLL.

=>> How are we going to restrict these sorts of things?  It's easy to say a pro
cess
=>> can have no more than, for example, 1 meg of non-virtual memory, but what i
f
=>> it needs more than that?  Any suggestions?  Maybe its dependent on if the
=>> process is a regular application, device driver, etc?
=>
=>Hmmm. If we have virtual memory then the amount of physical memory used by th
e
=>process is irrelevant - of course the more memory thet is being used the more
=>paging but that;s life.
=>
   And we should restrict or limit anything with such a drastic impact
on system performance.

=>There is a problem with MEM_PHYSICAL -- the simplest solution is to only 
=>allow device drivers to use the flag and not place a limit -- we are working 
=>under the assumption that device driver writers know what they're doing.
=>
   We might be better off this way. We may want to consider a call that
maps a particular physical space into the virtual space, instead. This
would certainly have to be restricted.

=>> Oh...are we going to call them tasks or processes?  I prefer tasks because 
of
=>> the term multitasking.  Not important... :-)
=>
=>My feeling is that tasks are "lighter" things whereas processes are relativel
y
=>"heavy". If we are only going to support one form of process/task/thread then
the name doesn't really matter.
=>
=>Process seems to be the more commonly used (at least in the Un*x world)
=>
   Actually, under Mach, at least, the opposite is true: tasks are the
kernel-scheduled, heavyweight objects, while processes are scheduled
within the task.

=>> >    Maybe we should call them "system modules" instead of "devices". The
=>> > latter can be a subset of the former, that being the set of scheduled
=>> > objects with special system priveleges.
=>
=>Hmm. I think I detect the need for a glossary of terms :-)
=>
   Doubtless true, but we should probably decide what we want to do
before defining terms. Otherwise, we would probably end up with a
complete OS dictionary.

=>> > =>> Should we have spinlocks too?
=>> > 
=>> >    They probably wouldn't buy us a whole lot in a single processor
=>> > system.
=>
=>No they would -- a semaphore requires a system call whereas a spinlock doesn'
t.
=>This makes spinlocks significantly faster.
=>
   But if there is only one processor, who is going to release the lock
while you are spinning on it? You would end up spinning until the next
context switch, at least, wasting the rest of the time slice. Of course,
if you mean spinning on a hardware event, that is different.

=>Next question: Do we have some notion of transactions, atomicity etc.
=>(a 'la database systems)
=>
   Not in the kernel, I think (unless we want exactly-once IPC semantics)
but we should be able to add them later.

=>I was commenting on the choice of standards which (I think) were Unix type
=>standards. I (probly) am wrong here.
=>
   What do you mean by "Unix type standards"?

   I'll put together my ideas on processes an IPC and post them when I
get a chance.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Tue Feb 23 23:35:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28315; Tue, 23 Feb 93 23:35:25 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 23 Feb 93 23:35:25 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05756; Tue, 23 Feb 93 14:29:49 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA19528
	Wed, 24 Feb 1993 09:29:34 +1100 (from winikoff)
Message-Id: <9302232229.19528@mulga.cs.mu.OZ.AU>
Subject: Re: Just can't get enough of that Moose!
To: moose-programmers@sfu.ca (Moose Project)
Date: Wed, 24 Feb 93 9:29:32 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To:  <9302232210.aa03863@bugs.cis.udel.edu>; from "Gary D. Duzan" at Feb 23, 93 5:10 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

>    To be fair, the majority of the kernel itself will be doing hardware

Yes but I feel it can be encapsulated into a small module.

> twiddling, so there isn't as much cause to make it portable as the rest
> of the system. It would, however, be a starting place for a port if it
> were in an HLL.

> =>process is irrelevant - of course the more memory thet is being used the more
> =>paging but that;s life.
> =>
>    And we should restrict or limit anything with such a drastic impact
> on system performance.

No. The obvious restriction is not to have virtual memory. If the user wants to
use more memory then s/he has then s/he pays the price in speed.
I don't see any point in providing virtual memory and then saying you can only
use it to a certain extant.

>    We might be better off this way. We may want to consider a call that
> maps a particular physical space into the virtual space, instead. This
> would certainly have to be restricted.

Sounds good.

>    Actually, under Mach, at least, the opposite is true: tasks are the
> kernel-scheduled, heavyweight objects, while processes are scheduled
> within the task.

Standards .. pick your favorite :-)

> =>
> =>Hmm. I think I detect the need for a glossary of terms :-)
> =>
>    Doubtless true, but we should probably decide what we want to do
> before defining terms. Otherwise, we would probably end up with a
> complete OS dictionary.

Hmm. But if we don't we could end up with a comunication problem. 
:-)

>    But if there is only one processor, who is going to release the lock
> while you are spinning on it? You would end up spinning until the next
> context switch, at least, wasting the rest of the time slice. Of course,

Whoops! You're right. (I was using spinlocks last year -- the work WAS on
a multiprocessor)

> if you mean spinning on a hardware event, that is different.
> 
> =>Next question: Do we have some notion of transactions, atomicity etc.
> =>(a 'la database systems)
> =>
>    Not in the kernel, I think (unless we want exactly-once IPC semantics)
> but we should be able to add them later.

Doubt. These things are hard to add later.

> 
> =>I was commenting on the choice of standards which (I think) were Unix type
> =>standards. I (probly) am wrong here.
> =>
>    What do you mean by "Unix type standards"?

Standards which in my mind are more in the world of workstations then personal
computers.

As I said - I'm rather vague in networks.

> 
>    I'll put together my ideas on processes an IPC and post them when I
> get a chance.
> 
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 
> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From dmarer@td2cad.intel.com Tue Feb 23 23:58:02 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28882; Tue, 23 Feb 93 23:58:01 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Tue, 23 Feb 93 23:58:01 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07582; Tue, 23 Feb 93 14:53:05 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 23 Feb 93 14:52:56 -0800
Received: by td2cad (5.57/10.0i); Tue, 23 Feb 93 14:56:21 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00698; Tue, 23 Feb 93 15:03:16 PDT
Date: Tue, 23 Feb 93 15:03:16 PDT
Message-Id: <9302232303.AA00698@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re: Just can't get enough of that Moose!
Status: OR

Hi!

	Gary, I can't wait to see the IPC stuff! :-)

	Just one point to make more clear:

> >    And we should restrict or limit anything with such a drastic impact
> > on system performance.
> 
> No. The obvious restriction is not to have virtual memory. If the user wants to
> use more memory then s/he has then s/he pays the price in speed.
> I don't see any point in providing virtual memory and then saying you can only
> use it to a certain extant.

	It think the problem is not with virtual memory.  The problem is in
a system which utilizes virtual memory but allows tasks to allocate memory
which is guaranteed to always exist in physical memory (using MEM_PHYSICAL).
This means less space is available for virtual memory to play around in.
Consider if on a PC with 4MB physical memory I did:

		MemoryAllocate(3*1024*1024,MEM_PHYSICAL);  // Allocate 3 megs

	The rest of the system would be screwed.  I don't want to restrict
physical memory to just device drivers (like with the other MEM_ flags) but
there's no good way to limit how much physical memory a task can use.  I can
see the need for this type of memory (audio and video applications) but those
require special device drivers anyway.  Can anybody think of a reason a normal
application might require a portion of its memory to be physical?   Is there
any application which just plain wouldn't work if it couldn't respond to some
event fast enough?

> > =>
> > =>Hmm. I think I detect the need for a glossary of terms :-)
> > =>
> >    Doubtless true, but we should probably decide what we want to do
> > before defining terms. Otherwise, we would probably end up with a
> > complete OS dictionary.
> 
> Hmm. But if we don't we could end up with a comunication problem. 
> :-)

I'll volunteer to start to work on that glossary - it sortof goes hand in hand
with the specs.  Can anyone give me the precise definition of a thread?  My
OS book doesn't really define it well...thanx!


				Dennis

From cis.udel.edu!udel.edu!duzan Wed Feb 24 00:25:22 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29941; Wed, 24 Feb 93 00:25:21 +0100
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Wed, 24 Feb 93 00:25:21 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA10347; Tue, 23 Feb 93 15:22:01 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa20183;
          23 Feb 93 18:19 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa26698;
          23 Feb 93 23:16 GMT
Received: from sol.cis.udel.edu by bugs.cis.udel.edu id aa04276;
          23 Feb 93 23:12 GMT
To: Moose Project <moose-programmers@sfu.ca>
Subject: Re: Just can't get enough of that Moose! 
In-Reply-To: Your message of "Wed, 24 Feb 93 09:29:32 EST."
             <9302232229.19528@mulga.cs.mu.OZ.AU> 
Date: Tue, 23 Feb 93 18:11:44 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302232312.aa04276@bugs.cis.udel.edu>
Status: OR

=>>    And we should restrict or limit anything with such a drastic impact
=>> on system performance.
=>
=>No. The obvious restriction is not to have virtual memory. If the user wants 
to
=>use more memory then s/he has then s/he pays the price in speed.
=>I don't see any point in providing virtual memory and then saying you can onl
y
=>use it to a certain extant.
=>
   I think we are having a context problem. I'm referring to allocating
physical memory, not virtual memory (which is, I believe, the idea
behind MEM_PHYSICAL.) Allowing unrestricted allocation of physical
memory rather defeats the purpose of virtual memory.

=>>    But if there is only one processor, who is going to release the lock
=>> while you are spinning on it? You would end up spinning until the next
=>> context switch, at least, wasting the rest of the time slice. Of course,
=>
=>Whoops! You're right. (I was using spinlocks last year -- the work WAS on
=>a multiprocessor)
=>
   Well, you're one up on me; I've only read about them.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Wed Feb 24 01:29:23 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01788; Wed, 24 Feb 93 01:29:22 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Wed, 24 Feb 93 01:29:22 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA16301; Tue, 23 Feb 93 16:23:22 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA22204
	Wed, 24 Feb 1993 11:23:13 +1100 (from winikoff)
Message-Id: <9302240023.22204@mulga.cs.mu.OZ.AU>
Subject: Re: Just can't get enough of that Moose!
To: moose-programmers@sfu.ca (Moose Project)
Date: Wed, 24 Feb 93 11:23:11 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9302232303.AA00698@tdge15.intel.com>; from "Dennis Marer" at Feb 23, 93 3:03 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 	It think the problem is not with virtual memory.  The problem is in
> a system which utilizes virtual memory but allows tasks to allocate memory
> which is guaranteed to always exist in physical memory (using MEM_PHYSICAL).

Yes.

> This means less space is available for virtual memory to play around in.
> Consider if on a PC with 4MB physical memory I did:
> 
> 		MemoryAllocate(3*1024*1024,MEM_PHYSICAL);  // Allocate 3 megs
> 
> 	The rest of the system would be screwed.  I don't want to restrict
> physical memory to just device drivers (like with the other MEM_ flags) but
> there's no good way to limit how much physical memory a task can use.  I can
> see the need for this type of memory (audio and video applications) but those
> require special device drivers anyway.  Can anybody think of a reason a normal
> application might require a portion of its memory to be physical?   Is there
> any application which just plain wouldn't work if it couldn't respond to some
> event fast enough?

Anything "realtime" by definition.
Multimedia.
You'd probly want network stuff to have a fast response time.

I think limiting physical memory to device drivers is quite reasonable.


> 
> I'll volunteer to start to work on that glossary - it sortof goes hand in hand
> with the specs.  Can anyone give me the precise definition of a thread?  My
> OS book doesn't really define it well...thanx!

A process that completely shares the address space of it's parent?
(minus the stack and registers)

> 
> 
> 				Dennis
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From cis.udel.edu!udel.edu!duzan Wed Feb 24 01:44:14 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02167; Wed, 24 Feb 93 01:44:12 +0100
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Wed, 24 Feb 93 01:44:12 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14996; Tue, 23 Feb 93 16:07:24 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa21704;
          23 Feb 93 18:45 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa27005;
          23 Feb 93 23:41 GMT
Received: from sol.cis.udel.edu by bugs.cis.udel.edu id aa04414;
          23 Feb 93 23:36 GMT
To: moose-programmers@sfu.ca
Subject: Re: Just can't get enough of that Moose! 
In-Reply-To: Your message of "Tue, 23 Feb 93 15:03:16 PDT."
             <9302232303.AA00698@tdge15.intel.com> 
Date: Tue, 23 Feb 93 18:36:24 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302232336.aa04414@bugs.cis.udel.edu>
Status: OR

=>                                        Can anybody think of a reason a norma
l
=>application might require a portion of its memory to be physical?   Is there
=>any application which just plain wouldn't work if it couldn't respond to some
=>event fast enough?
=>
   The whole class of real-time applications would need to be
restricted to physical memory. We may want to allow for a system with
no pager (i.e. restricted to virtually mapped physical memory) to cover
this need.

=>I'll volunteer to start to work on that glossary - it sortof goes hand in han
d
=>with the specs.  Can anyone give me the precise definition of a thread?  My
=>OS book doesn't really define it well...thanx!
=>
   Threads (i.e. lightweight processes) are basically subprocesses
sharing code and data space. There is a wide variety of features that
threads packages implement, and a large number of packages. Ones that
pop to mind are Mach's C-Threads, Posix threads, Sun's LWP library
(ugh), and Amoeba's threads. They are generally used to express logical
parallelism within the larger process (task, object.)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From ANDREASA@sofus.dhhalden.no Wed Feb 24 12:45:18 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA26982; Wed, 24 Feb 93 12:45:17 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 24 Feb 93 12:45:17 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08115; Wed, 24 Feb 93 03:39:11 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <19915-0@fenris.dhhalden.no>; Wed, 24 Feb 1993 12:38:20 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930224123751.416; 24 Feb 93 12:37:46 -100
Message-Id: <MAILQUEUE-101.930224123742.384@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 24 Feb 93 12:37:42 +0100
Subject: Re: Just can't get enough of that Moose!
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Hi everybody.

> > No. The obvious restriction is not to have virtual memory. If the user wants to
> > use more memory then s/he has then s/he pays the price in speed.
> > I don't see any point in providing virtual memory and then saying you can only
> > use it to a certain extant.
>
>     It think the problem is not with virtual memory.  The problem is in
> a system which utilizes virtual memory but allows tasks to allocate memory
> which is guaranteed to always exist in physical memory (using MEM_PHYSICAL).
> This means less space is available for virtual memory to play around in.
> Consider if on a PC with 4MB physical memory I did:
>
>         MemoryAllocate(3*1024*1024,MEM_PHYSICAL);  // Allocate 3 megs
>
>     The rest of the system would be screwed.  I don't want to restrict
> physical memory to just device drivers (like with the other MEM_ flags) but
> there's no good way to limit how much physical memory a task can use.  I can
> see the need for this type of memory (audio and video applications) but those
> require special device drivers anyway.  Can anybody think of a reason a normal
> application might require a portion of its memory to be physical?   Is there
> any application which just plain wouldn't work if it couldn't respond to some
> event fast enough?

I have two comments on the memory issue. First how we should implement the
allocation code, and secondly virtual vs. physical memory.
There are 4 different PLs in a 386++ processor. I suggest that the 3 lowest
PLs can use the MemoryAllocate, MemoryReAllocate and MemoryFree calls, and
the fourth uses standard commands as new or malloc. In addition we have a
memory device that serves the purpose of memory management in PL level 2
(counting lowest priority level as beeing 0).
When an app starts it allocates some space, and contigous calls to alloc,
realloc and free then calls MemoryAllocate, MemoryReAllocate and MemoryFree as
needed, having it's own "stack" served by the memory device. When the space-
request grows over the stack space limit it calls MemoryReAllocate, and asks
for a larger amount of memory.


An app should allocate memory in physical mem as long as there are physical
mem available. The algorithms in the memory management device decides whether
or not, disk should be swapped.
I can see that some systems require fast response, and therefore will want to
have much data in mem, but if the response time is crucial, they will probably
already have a fast harddisk and a large amount of mem anyway. Considering
this, it might not be a need for the MEM_PHYSICAL flag in PL 3.

Maybe you shouldn't pay to much attention to my ideas about Memory Management
since this is my first OS project, and MM has never been my biggest interrest
:-), but my "common sense" says this could work pretty well.
Now a question to you all about the GUI device.
What kind of graphics capabilities do you have?
Do you prefer Amiga or X-menus? (Just to say, I'm no Amiga fan :-)
Of course Mac and Windows menus is an alternative, but is it a real
alternative?
Me and Dennis have discussed the possibility of making a virtual 8086 to get
the bios graphics initialization routines. Considering there are about 12
different graphics chipsets producers (with maybe 2 to 6 different chips each)
there would be a huge amount of time only to find out the correct register
values, and I have very limited access to other chips than ATI :-(.
Of course the bios code would only be neccessary as long as there aren't
finnished code for all chipsets. Hopefully I can get other netters to help me
with this part.
Please respond by mail about your chipset, what kind of menu you would like
etc. Name the mail, 'Graphics query 1'.

I must fire my last shot at the moosers who want a textbased system :-(, but
I have to. Living in the small kingdom of Norway, the land where people kills
whales as regulary as others goes to work. The land where polarbears walks on
the streets. The land that has got all gold-medals in the Ski World
Championship in Falun this year :-]. The land that uses omlaut a, aa and o,
and for the countries of europe, japan the mozlem countries and african
countries. It would be nice if all apps could support Unicode, instead of
having to remap the character table twice a day. Beeing able to write a letter
in arabic, then in kanji, or any other alphabet, how are you going to support
this in textmodus? Remap the character table all the time, stealing valuable
resources?
Ok, I know some of you will flame me for this one, but please don't. This is
a serious problem in many countries, beeing a slave of the ANSI comitte.
I know it is possible to remap the character table etc., and I have done it
before, but the world would be much more easy if we had a two byte character.
Give me another reason than speed, and I might listen more careful.

BTW, now when I have said this, will an integer correspond to 4 bytes or
will it correspond to 2, as it does under uglybuggly dos.

> > > =>Hmm. I think I detect the need for a glossary of terms :-)
> > > =>
> > >    Doubtless true, but we should probably decide what we want to do
> > > before defining terms. Otherwise, we would probably end up with a
> > > complete OS dictionary.
> >
> > Hmm. But if we don't we could end up with a comunication problem.
> > :-)
I wouldn't mind a glossary. What is IPC?

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From mueller@sc.ZIB-Berlin.DE Wed Feb 24 13:11:22 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28175; Wed, 24 Feb 93 13:11:21 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 24 Feb 93 13:11:21 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08742; Wed, 24 Feb 93 04:07:11 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA09196; Wed, 24 Feb 93 13:06:53 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA04611; Wed, 24 Feb 93 13:06:52 +0100
Date: Wed, 24 Feb 93 13:06:52 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9302241206.AA04611@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Just can't get enough of that Moose!
Status: OR

> From winikoff@cs.mu.OZ.AU Tue Feb 23 23:35:20 1993
> Subject: Re: Just can't get enough of that Moose!
> To: moose-programmers@sfu.ca (Moose Project)
> Date: Wed, 24 Feb 93 9:29:32 EST
> From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
> X-Mailer: ELM [version 2.3 PL0]
> Content-Length: 2968
> 
> >    To be fair, the majority of the kernel itself will be doing hardware
> 
> Yes but I feel it can be encapsulated into a small module.

Agreed. Lets call it nucleus ;-)

> 
> > twiddling, so there isn't as much cause to make it portable as the rest
> > of the system. It would, however, be a starting place for a port if it
> > were in an HLL.
> 
  
> >    Actually, under Mach, at least, the opposite is true: tasks are the
> > kernel-scheduled, heavyweight objects, while processes are scheduled
> > within the task.
> 
> Standards .. pick your favorite :-)

Ok. Here I go: I prefer the term task which consists of several threads. A task is a 
heavyweight thing (don't want to say process :-). A thread is lightweight, thus thread
scheduling is very fast whereas task scheduling is much more slowly for the reason of
full context switches. Maybe we can think of another featherweight process type. 
(Sorry, I will precise this idea in a later mail. Now it's only a thought coming up to 
my brain ...)

> 
> > =>
> > =>Hmm. I think I detect the need for a glossary of terms :-)
> > =>
> >    Doubtless true, but we should probably decide what we want to do
> > before defining terms. Otherwise, we would probably end up with a
> > complete OS dictionary.
> 
> Hmm. But if we don't we could end up with a comunication problem. 
> :-)

Agreed. Maybe we should all add a glossary in front of our mails ;-)

>
> [Stuff about spin locks deleted. I've no experience with them.] 
 
> > =>Next question: Do we have some notion of transactions, atomicity etc.
> > =>(a 'la database systems)
> >    Not in the kernel, I think (unless we want exactly-once IPC semantics)
> > but we should be able to add them later.

Isn't it possible to create, for example, a transaction object which could be used
as an environment in which communication can took place safely? But I see the problem
when the kernel isn't safe at all.

> 
> > 
> > =>I was commenting on the choice of standards which (I think) were Unix type
> > =>standards. I (probly) am wrong here.
> > =>
> >    What do you mean by "Unix type standards"?
> 
> Standards which in my mind are more in the world of workstations then personal
> computers.
> 
> As I said - I'm rather vague in networks.
> 
> > 
> >    I'll put together my ideas on processes an IPC and post them when I
> > get a chance.

Fine.

Peter



From dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed Feb 24 13:17:55 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28323; Wed, 24 Feb 93 13:17:54 +0100
Return-Path: <dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 24 Feb 93 13:17:54 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08875; Wed, 24 Feb 93 04:14:43 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa29510; 24 Feb 93 7:14 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa06671;
          24 Feb 93 12:12 GMT
Received: from sol.cis.udel.edu by dori.cis.udel.edu id aa11572;
          24 Feb 93 12:12 GMT
To: moose-programmers@sfu.ca
Subject: Re: Just can't get enough of that Moose! 
In-Reply-To: Your message of "24 Feb 93 12:37:42 +0100."
             <MAILQUEUE-101.930224123742.384@sofus.dhhalden.no> 
Date: Wed, 24 Feb 93 07:12:18 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9302241212.aa11572@dori.cis.udel.edu>
Status: OR

=>BTW, now when I have said this, will an integer correspond to 4 bytes or
=>will it correspond to 2, as it does under uglybuggly dos.
=>
   Supposedly this would vary with system and compiler, but I would
say that 32 bit (4 byte) integers would be the norm in the initial
implementation(s).

=>I wouldn't mind a glossary. What is IPC?
=>
   Inter-Process Communication.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Wed Feb 24 13:26:41 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28646; Wed, 24 Feb 93 13:26:40 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 24 Feb 93 13:26:40 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09058; Wed, 24 Feb 93 04:23:20 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA09240; Wed, 24 Feb 93 13:22:54 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA04639; Wed, 24 Feb 93 13:22:53 +0100
Date: Wed, 24 Feb 93 13:22:53 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9302241222.AA04639@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Moose: A Short Question
Status: OR

Hello Moosers!

I think, I'm currently the only one who is not able to
give 150 % of his time for the project. So I get bombed
with your mails. Thanks folks, it was a great 
literature!

What I've recognized so far are several ideas, thoughts,
and hick-hacks about so many things. There are talks about
which graphic card to use or which language is the best or
how to develop a nice GUI or TUI. Sorry, I feel we should
concentrate more on general design decisions. How can you
design a GUI when you're not knowing the basics? (I know you
will flame me for that ;-)

I've expected more discussion about the kernel. How should
process execution and interprocess communication (what about
[remote] object invocation?) be implemented? How is it possible
to make the kernel as small and "featherweight" as possible?
What about deviding the kernel into a second part: A Nucleus
which only implements process execution and powerful and efficient
interprocess communication (which should be in fact be treated as
a message to an object). Then there is the kernel, providing 
additional functionality as Memory Management. Why should all
such memory stuff like virtual, shared, etc. be implemented within
the nucleus or even the kernel? What about a user who doesn't need
virtual memory, because his/her applications are small? Must he/she
live with a performance lack, because the system runs all through
the virtual memory manager's code?

What about the interface TO the kernel? How should this be 
designed? How do you want to contact remote objects? One solution
is to provide name server objects, which can be connected 
hierarchical. What about object migration? Message passing?

Well, sorry that I wrote this damping mail. And please, I don't
want to kill your euphoria. Keep the discussion running and let me
hear your thoughts.

Thanks for your time,

Peter

From ANDREASA@sofus.dhhalden.no Wed Feb 24 14:05:36 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00519; Wed, 24 Feb 93 14:05:34 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 24 Feb 93 14:05:34 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09657; Wed, 24 Feb 93 05:01:11 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <23912-0@fenris.dhhalden.no>; Wed, 24 Feb 1993 14:01:01 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930224140030.448; 24 Feb 93 14:00:27 -100
Message-Id: <MAILQUEUE-101.930224140027.416@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 24 Feb 93 14:00:27 +0100
Subject: To clear some things out (No flame :-)
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Maybe you are wondering what this crazy Norwegian is doing here, mostly
discussing GUIs, while everybody else discuss the kernel.

The truth is I said to Dennis, I wasn't particulary interested in the kernel,
but in the development of a GUI, and this was in early 1993.

So it was "decided" that I should work on the graphics part parallell with
Dennis working on the kernel. That's way I send out these mails etc.

Ok.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From dmarer@td2cad.intel.com Wed Feb 24 17:16:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08073; Wed, 24 Feb 93 17:16:00 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 24 Feb 93 17:16:00 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15027; Wed, 24 Feb 93 08:11:17 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Wed, 24 Feb 93 08:11:12 -0800
Received: by td2cad (5.57/10.0i); Wed, 24 Feb 93 08:14:51 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00807; Wed, 24 Feb 93 08:21:38 PDT
Date: Wed, 24 Feb 93 08:21:38 PDT
Message-Id: <9302241621.AA00807@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re: Just can't get enough of that Moose!
Status: OR

Hi everyone!

	I have had an idea about memory allocation which may prove to be
somewhat entertaining - so far the kernel is able to only allocate large
blocks of memory.  In fact, I've modified the 'interface' (I use that term
very loosely so far, nothing is set in stone yet) so that the memory block
'size' parameter specifies the number of kilobytes instead of the number of
bytes.  (What's the point of specifying bytes if the system is going to
round up to kilobytes anyway?)  Working in larger chunks makes the kernel
more efficient any.

	So you've got a large chunk of memory at address X that you've
allocated - how to break this into smaller pieces?  Create an object which
manages this memory for you.  The object's address is *also* X, and it is
entirely in charge of allocating memory from that block - doing the malloc()
and free(), if you will.  Also, the object would automatically resize the
block of memory when necessary (by calling MemoryReallocate).  Here's the
interface I propose (forgive the C++ code, it's only being used for clarity):

	class memory_manager {
	public:
	    memory_manager(size,attributes);	// Same as MemoryAllocate
	    ~memory_manager();			// Destructor, of course
	    void *Allocate(size);		// Size in bytes this time
	    void *Reallocate(size,address);	// Returns a new pointer
	    void Free(address);			// Free allocated memory
	};

	Then (check this out!) a C implementation of malloc(), realloc(), and
free() could be implemented like this:

memory_manager *taskMemory = new memory_manager(10,MEM_VIRTUAL); // 10k heap

#define malloc(size)		(taskMemory->Allocate(size))
#define realloc(size,address)	(taskMemory->Reallocate(size,address))
#define free(address)		(taskMemory->Free(address))

	The heap would automatically grow and shrink as necessary to meet
the needs of the program.  Oh, and calloc() would be a real function call,
implemented in a C library.

	To make myself clear: this would *not* be part of the kernel!  This
would be part of an operating system library which programs could link to.
This object enhances the functionality of the kernel but is not necessary
for its operation.  This is where the kernel stops and the operating system
begins!

	Any feedback?

> An app should allocate memory in physical mem as long as there are physical
> mem available. The algorithms in the memory management device decides whether
> or not, disk should be swapped.
> I can see that some systems require fast response, and therefore will want to
> have much data in mem, but if the response time is crucial, they will probably
> already have a fast harddisk and a large amount of mem anyway. Considering
> this, it might not be a need for the MEM_PHYSICAL flag in PL 3.

I guess what it comes down to is whether we want a system capable of lightning
speed response at the expense of multiple tasks and users, or one capable of
average speed while allowing many multiple users and tasks to coexist.

Lightning speed: Keep MEM_PHYSICAL, put a few restrictions on it.
Average speed:   Restrict MEM_PHYSICAL to more privileged software.

> Maybe you shouldn't pay to much attention to my ideas about Memory Management
> since this is my first OS project, and MM has never been my biggest interrest
> :-), but my "common sense" says this could work pretty well.

No kidding - this is my first OS project too!  :-)  I'm torn - it would be
nice to give all users equal access to all resources, but it seems the 'first-
come-first-served' approach is going to work better for the PC.  Maybe the
rules for restricting physical memory usage could be flexible, to be configured
when a system is set up?  I'm thinking of a multi-user environment, but it's
also got to be flexible for a single-user system...


> It would be nice if all apps could support Unicode, instead of
> having to remap the character table twice a day.

I think Unicode is a reasonable standard to agree on - ASCII is definitely
not the 'ideal' choice for a new operating system...  Let's support our
friends in Europe and give 'em those oomlauts!

> BTW, now when I have said this, will an integer correspond to 4 bytes or
> will it correspond to 2, as it does under uglybuggly dos.

Hmmm...every machine I could think of that I'd want to use has at least a 
32-bit word size.  Just a hint though - the Penitum has a 64-bit data bus!
(This is public info, I'm not divulging any Intel secrets... :-)  I think the
best approach is to define the interface in terms of 'at least': say, for
example, this value is *at least* 32-bits in size.  This means if you write
an application that counts on the value being larger than 32-bits, you are
in trouble when you try to port it... :-(

	byte:		always 8 bits.
	char:		always 16 bits (remember Unicode?)
	short word:	at least 16 bits.
	word:		at least 32 bits.
	long word:	at least 64 bits.

Any comments on that?

Got to run....work to be done!


			Dennis

From ANDREASA@sofus.dhhalden.no Wed Feb 24 20:10:21 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15868; Wed, 24 Feb 93 20:10:18 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 24 Feb 93 20:10:18 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06817; Wed, 24 Feb 93 10:56:57 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <28732-0@fenris.dhhalden.no>; Wed, 24 Feb 1993 19:56:44 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930224195615.480; 24 Feb 93 19:56:09 -100
Message-Id: <MAILQUEUE-101.930224195606.448@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 24 Feb 93 19:56:06 +0100
Subject: Re: Just can't get enough of that Moose!
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> Hi everyone!
  ^^^^^^^^^^^^Make that my own :-)
[Stuff deleted about memory management]
>     Any feedback?
Exactly what I ment :-)
> > An app should allocate memory in physical mem as long as there are physical
> > mem available. The algorithms in the memory management device decides whether
> > or not, disk should be swapped.
> > I can see that some systems require fast response, and therefore will want to
> > have much data in mem, but if the response time is crucial, they will probably
> > already have a fast harddisk and a large amount of mem anyway. Considering
> > this, it might not be a need for the MEM_PHYSICAL flag in PL 3.
>
> I guess what it comes down to is whether we want a system capable of lightning
> speed response at the expense of multiple tasks and users, or one capable of
> average speed while allowing many multiple users and tasks to coexist.
>
> Lightning speed: Keep MEM_PHYSICAL, put a few restrictions on it.
> Average speed:   Restrict MEM_PHYSICAL to more privileged software.

If you have a realtime system and need lightning speed, you will probably
have a harddisk that will make up for the speed needed, even though you cannot
use the MEM_PHYSICAL flag.
Or we can make a council that decides whether or not an app can use MEM_P :-).
Or we can let devicedrivers only use the MEM_P flag, and if somebody needs
lightning speed he makes his own memory management device.

> > It would be nice if all apps could support Unicode, instead of
> > having to remap the character table twice a day.
>
> I think Unicode is a reasonable standard to agree on - ASCII is definitely
> not the 'ideal' choice for a new operating system...  Let's support our
> friends in Europe and give 'em those oomlauts!

The Kingdom of Norway, the land where polarbears walks on the streets and
where every man has killed his own whale hopes for the same positive response
from you others (at least from Peter and Fare').

> Hmmm...every machine I could think of that I'd want to use has at least a
> 32-bit word size.  Just a hint though - the Penitum has a 64-bit data bus!
> (This is public info, I'm not divulging any Intel secrets... :-)  I think the
> best approach is to define the interface in terms of 'at least': say, for
> example, this value is *at least* 32-bits in size.  This means if you write
> an application that counts on the value being larger than 32-bits, you are
> in trouble when you try to port it... :-(
>
>     byte:       always 8 bits.
>     char:       always 16 bits (remember Unicode?)
>     short word: at least 16 bits.
>     word:       at least 32 bits.
>     long word:  at least 64 bits.
>
> Any comments on that?

A small one :-)
I don't like the 'byte' type, if possible I would prefer a short char.

>             Dennis

Arffsig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From UKCC.UKY.EDU!WKUVX1.BITNET!haydedr Wed Feb 24 21:04:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17313; Wed, 24 Feb 93 21:04:29 +0100
Return-Path: <UKCC.UKY.EDU!WKUVX1.BITNET!haydedr>
Received-Date: Wed, 24 Feb 93 21:04:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ukcc.uky.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12251; Wed, 24 Feb 93 11:58:03 -0800
Received: from UKCC.UKY.EDU by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 4782; Wed, 24 Feb 93 14:53:00 EST
Received: from WKUVX1.BITNET (NJE origin MXMAILER@WKUVX1) by UKCC.UKY.EDU
 (LMail V1.1d/1.7f) with BSMTP id 9126; Wed, 24 Feb 1993 14:20:10 -0500
Received: by WKUVX1.BITNET (MX V3.2-beta) id 17977; Wed, 24 Feb 1993 13:22:47
          CST
Sender: haydedr@WKUVX1.BITNET
Date: Wed, 24 Feb 1993 13:22:45 CST
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: moose-programmers@sfu.ca
Cc: haydedr@WKUVX1.BITNET
Message-Id: <009689CF.3B7ECE00.17977@WKUVX1.BITNET>
Subject: Moose Glossary
Status: OR

Hello!

I've had a bad case of flu for the last two days now, so I logged on
today to find I had only 25 mail messages.  Needless to say, I'll be
reading a while :-)

I've enjoyed the discussion on memory management, and I'll post my
summary as soon as I make one ;-)  (I've got a bunch of ideas, but
it's hard to transmit them unless they're written out).

As far as a glossary goes, I'd like to pose the following definitions
to help in our discussion of Moose "kernelology":

o  Session - this is our unit of I/O device sharing, if you will.
   Each session contains all the needed logical devices (keyboard, video
   buffer, etc).  Processes (defined later) perform user I/O on these
   devices only.

o  Process - this is the unit of resource management for Moose.  A
   process is created by starting a program.

o  Thread  - unit of processor dispatching.  So essentially, a process
   doesn't really run, but a thread does.  Processor time is allocated
   to threads, not to processes.

Here's a simple diagram of the realtionship between the three terms:

+--------------------------------------+
|                Process               |
| +---------------+                    |
| |Process virtual|                    |
| |address space  |                    |
| +---------------+                    |
|                                      |
| +--------+   +--------+   +--------+ |
| |Thread 1|   |Thread 2|...|Thread n| |
| +--------+   +--------+   +--------+ |
|                                      |
| +----------------------------------+ |
| |Logical device handles, semaphores| |
| +----------------------------------+ |
+--------------------------------------+

How's that look?  I personally like lotsa good documentation, so I'll
probably make several diagrams like these.

Later,
Ross


From winikoff@cs.mu.OZ.AU Thu Feb 25 23:38:02 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00486; Thu, 25 Feb 93 23:38:01 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 25 Feb 93 23:38:01 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05634; Thu, 25 Feb 93 14:30:59 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA06760
	Fri, 26 Feb 1993 09:30:24 +1100 (from winikoff)
Message-Id: <9302252230.6760@mulga.cs.mu.OZ.AU>
Subject: Misc (and graphics 1)
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 26 Feb 93 9:30:22 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <MAILQUEUE-101.930224123742.384@sofus.dhhalden.no>; from "ANDREASA@dhhalden.no" at Feb 24, 93 12:37 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> Hi everybody.
> 
> 
> I have two comments on the memory issue. First how we should implement the
> allocation code, and secondly virtual vs. physical memory.
> There are 4 different PLs in a 386++ processor. I suggest that the 3 lowest
> PLs can use the MemoryAllocate, MemoryReAllocate and MemoryFree calls, and

No. All PLs shouls use the system calls -- as a programmer you'd use new/malloc
which the compile would implement using the system calls.

> the fourth uses standard commands as new or malloc. In addition we have a
> memory device that serves the purpose of memory management in PL level 2
> (counting lowest priority level as beeing 0).
> When an app starts it allocates some space, and contigous calls to alloc,
> realloc and free then calls MemoryAllocate, MemoryReAllocate and MemoryFree as
> needed, having it's own "stack" served by the memory device. When the space-
> request grows over the stack space limit it calls MemoryReAllocate, and asks
> for a larger amount of memory.

This is language dependant -- some languages don't actually use stacks.
(Eg. Scheme can be implemented using only a heap, FORTRAN doesn't need a stack
[Maybe modern FORTRANs do?])

> 
> 
> An app should allocate memory in physical mem as long as there are physical
> mem available. The algorithms in the memory management device decides whether

Of course -- virtual memory schemes will not swap out pages unless one is trying
to use more memory then physically exists.
If you allways do stuff that completely fits into your physical memory then 
virtual memory won't actually do any swapping.

> or not, disk should be swapped.
> I can see that some systems require fast response, and therefore will want to
> have much data in mem, but if the response time is crucial, they will probably
> already have a fast harddisk and a large amount of mem anyway. Considering
> this, it might not be a need for the MEM_PHYSICAL flag in PL 3.

In a relatively heavily loaded system (IE one which doesn't have as much 
physical memory as one would like :-) pages WILL get swapped out.
Some applications have a requirement that they never have to wait that fraction
of a second for a page of theirs to be read in from swap space (= disk).
Can you imagine the delay as a sample player waits for the disk?
It would be audible.

> Maybe you shouldn't pay to much attention to my ideas about Memory Management
> since this is my first OS project, and MM has never been my biggest interrest

Ditto. Probly so for most of us - that's why it's so much fun :-)

> :-), but my "common sense" says this could work pretty well.
> Now a question to you all about the GUI device.
> What kind of graphics capabilities do you have?
> Do you prefer Amiga or X-menus? (Just to say, I'm no Amiga fan :-)

What's the difference between Amiga and Mac menus? (apart from having 
another mouse button in the Amiga)

Personally I'd like to have menus where you click once to bring up the menu then
release the button and click again to select.
I find it awkward to drag the mouse around while holding the button down.
Anyone else have this problem?

> Of course Mac and Windows menus is an alternative, but is it a real
> alternative?
> etc. Name the mail, 'Graphics query 1'.
> 
[Stuff about unicode plea deleted]
Yes. We should use Unicode.

> 
> BTW, now when I have said this, will an integer correspond to 4 bytes or
> will it correspond to 2, as it does under uglybuggly dos.

Definately 4.

> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Thu Feb 25 23:42:42 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00560; Thu, 25 Feb 93 23:42:41 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 25 Feb 93 23:42:41 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06023; Thu, 25 Feb 93 14:36:29 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA06911
	Fri, 26 Feb 1993 09:36:05 +1100 (from winikoff)
Message-Id: <9302252236.6911@mulga.cs.mu.OZ.AU>
Subject: Re: Just can't get enough of that Moose!
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 26 Feb 93 9:36:03 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9302241206.AA04611@sc.zib-berlin.dbp.de>; from "Peter Mueller" at Feb 24, 93 1:06 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> > 
> > Yes but I feel it can be encapsulated into a small module.
> 
> Agreed. Lets call it nucleus ;-)

Good name.

> > > =>Next question: Do we have some notion of transactions, atomicity etc.
> > > =>(a 'la database systems)
> > >    Not in the kernel, I think (unless we want exactly-once IPC semantics)
> > > but we should be able to add them later.
> 
> Isn't it possible to create, for example, a transaction object which could be used
> as an environment in which communication can took place safely? But I see the problem
> when the kernel isn't safe at all.

I was thinking of file operations -- I suppose it applies though to any applic
that operates on a number of objects.

TRansaction support to me means that if an application begins operating
on a number of files/objects then
(1) If the application fails midway then it's changes are undone
(2) Other applications attempting to use the same objects are handled in some
	way (Eg. told the objects are locked, given old information)

IN the context of files implementing this type of stuff is usually done using 
logs -- any operation is logged with enough information to undo it.
(Or redo it in the case that a transaction completes but it's changes are still
in memory and the system crashes)

This shouldn't be too hard to add to the file system seeing as it'll be 
replaceable but will involve a fair amount of work.

I feel that providing industrial strength recovery isn't really neccessary.
Some form of file/object locking is needed though.



--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Thu Feb 25 23:47:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00646; Thu, 25 Feb 93 23:47:29 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 25 Feb 93 23:47:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06599; Thu, 25 Feb 93 14:44:05 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA07087
	Fri, 26 Feb 1993 09:43:42 +1100 (from winikoff)
Message-Id: <9302252243.7087@mulga.cs.mu.OZ.AU>
Subject: Re: Just can't get enough of that Moose!
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 26 Feb 93 9:43:41 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <MAILQUEUE-101.930224195606.448@sofus.dhhalden.no>; from "ANDREASA@dhhalden.no" at Feb 24, 93 7:56 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> 
> If you have a realtime system and need lightning speed, you will probably
> have a harddisk that will make up for the speed needed, even though you cannot
> use the MEM_PHYSICAL flag.

No. Harddisks are by definition orders of magnitude slower then memory/CPU.
If you want speed you get enough memory so your application won't need to 
be paged out.

> The Kingdom of Norway, the land where polarbears walks on the streets and
> where every man has killed his own whale hopes for the same positive response
> from you others (at least from Peter and Fare').

How many whales have you killed? :-)
And did you know they were a protected species? 


From rideau@clipper Wed Mar  3 03:07:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22072; Wed, 3 Mar 93 03:07:29 +0100
Return-Path: <rideau@clipper>
Received-Date: Wed, 3 Mar 93 03:07:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20046; Tue, 2 Mar 93 18:02:04 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303030201.AA22011@clipper.ens.fr>
Subject: HLL,LLL+ far11
To: moose-programmers@sfu.ca
Date: Wed, 3 Mar 93 3:01:51 MET
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Hello, dear friends
 Here are hints about what Objects should do under MOOSE, according to me:
O's should be able to do anything a past, present or future language will
be able to ask it, so that the OOing Kernel should be complete and 
extensible. These ideas are not well ordered by now, but  I hope there'll be
no understanding problem. These requirement include HLL,LLL and Kernel
requirements mixed together. I think the Kenel should manage anything the HLL
may do (even a type's syntax should be available as one of the type's method)
but you may think otherwise; tell me why; I think it must, because of
object portability; if OOing is available at low-level, the LLL standard
would be stronger, and IOC easier.
- Next to the running Kernel, there will be a OO managing unit able not
only to us, but create, verify, Objets and do non-trivial things on them;
it should also manage "virtual" objects and not only physical ones.
- O's should be generic: you can have type as parameter and/or results,
and have other types/parameters depending on a parameter type.
- the type of the object need not precede the object in physical memory;
however, with an object,s ID should come everything about the object,
including the type, etc. physical length of an object is a function
available for all O's (possibly varying with time), and usable since HLL.
a raw list of objects each preceded by its full type&info should be a valid
HLL type.
- objects (inclding types) need not be fully calculated/expanded: the
object "f(1)" where f is an integer function over integers, may be a valid
(virtual) integer.
- the language should know of imlicit variables: if a proc. uses a global,
static or eternal variable, this variabe will be known as an implicit
variable of the proc; you can also have default valued variables, variables
whose value depends on the other, .. Many syntaxes may describe the same
O., so that types should include more than just content info:
OBJECTS (including types) CAN HAVE "COMMENTS"; comments include object
read/write info, object equivalencies (other equivalent objects - useful
for portability: the system will choose which equivalent object best fits
the hardware), constraints on object, etc. Of course, comments need not be
present in physical memory togethe with the object; only a (virtual) pointer
to them need.
- more generally, you can specify logical constraints upon your variables:
you can force x=2y+1, for example where x and y are variables, or type(x)=y,
etc. You can label constraints and/or give them parameters so as to specify
when they apply or not. The Kernel should be able to maintain the lists
of constraints and generate constraints.
- (physical/virtual) subtypes may be accepted: for example a number from 2 to 7
is a subtype of integers; a C source is a subtype of ASCII texts, which may
automatically be a subtype of Unicode texts, as ASCII is a (virtual) subset of
Unicode; real numbers form a virtual subtype of complex numbers (even if in
the impl' complex number are built fro real numbers), etc.
- names are accepted at LL, though not the only way to access an object,
for obvious speed reasons.
- automatic lowest cost type cast should be achieved in the OO : each
function has a "cost" which may be asked by the Kernel (standard method);
when a program wants to cast an object to a type, the Kernel should be able
to find the shortest paht (if exists) between current and wanted type of the
O. It will suppose that all diffrent casts constructible with the casting list
given are equivqlent. The casting list may depend on the context.
- automatic casting from physical impl' to virtual us should be compatible
with multi* data integrity and security => there are sharing mecanisms.
Functions on sequences (=files) may tell which part of the input file musn't
be modified by another, and which part of the output file is valid at the time.
The most secure thing when we don't know is to make a function work with a
(virtual) local copy of the current value of the object given. In a garbage
colleting environment, this is no problem.
- Security: a host will know if it has compiled a program from HL or LL,
or if it had directly machine code. It will ask confirmation before
executing programs it's known from too low level only. user can give
glbal or conditionnal confirmatin (i.e* always ok/ ok for now but ask later/
maintain a list of parameters it was ok with/ in the most general case, ok
according to some function of the (explicit and implicit=the dictionnary)
parameters , etc)

 Well, please tell your mind about all that, say what pleases you, what you
dislike; flame at me if you would. Whatever, do it as soon as possible:
the soonest we agree on HL specs, the sooner we can define precisely LL
specs and begin to work. I hope this will be before the end of the month.
 
			   ,
			Fare, 200% time mooser, who should ne studying
						differential geometry !

From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Thu Mar  4 16:04:39 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24344; Thu, 4 Mar 93 16:04:36 +0100
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Thu, 4 Mar 93 16:04:36 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03705; Thu, 4 Mar 93 06:59:43 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id bt26432; 4 Mar 93 9:45 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa09731; 4 Mar 93 12:10 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa01802;
          4 Mar 93 12:06 GMT
To: moose-programmers@sfu.ca
Subject: Processes and Communication (2)
Date: Thu, 04 Mar 93 07:06:35 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303041206.aa01802@thorin.cis.udel.edu>
Status: OR


   I don't think this went out properly the first time I posted it,
so here it is again. If you get it twice, I apologize.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




   This is an overview of my vision for processes and interprocess
communication in the MOOSE system. It is far from being a complete
specification, and I encourage discussion of the various features. I
have intentionally left out any implementation details or actual
example interface code so that we can decide on the abstract model
first and move on to the implementation once the model is ironed out.

   Entities in the MOOSE system are referred to as 'objects'. The
interface to an object is composed entirely of 'methods'. One object
communicates with another by 'invocing' a method on another object.
Invocation is accomplished through Remote Procedure Calls, or 'RPC'.
An invoced method is called a 'thread'.

   Objects represent protected units of functionality in MOOSE. With
the exception of inheirited (non-virtual) base class code (libraries),
each object has a completely private, non-shared address space. The
kernel is reponsible for scheduling objects and providing resources as
needed. Each object has a specific protection level which determines
how the object's threads may directly modify the system hardware.

   An RPC call will contain information such as a remote object name,
the remote object's method name, permission information, and a set of
arguments to the method. The invocing thread is blocked, the message is
delivered to the destination object, the object executes the method
with the given arguments, and passes the return value (or error code)
in a message as a reply to the calling thread. Note that passing
pointers isn't useful, since objects have disjoint data spaces. There
are, however, techniques to improve performance when passing large data
items.

   The thread is the basic unit of execution within an object. A thread
can invoce a method of another object via an RPC. The calling thread is
blocked until the call is completed, but the other threads are allowed
to continue. The call is received by a thread in the target object that
waits for calls to that particular method. Threads can create other
threads to execute while others are blocked. This allows the object to
continue processing while waiting on the result, while maintaining
procedure call semantics.

   An object is created by an RPC call to an object with access to the
scheduler and resource allocator. An object with such access may also
destroy an object by descheduling it an deallocating its resources.
Each object will have an initial set of object names. This will
generally include the name of an object that holds the names of other
objects. Each object should include a method to determine the names of
its other methods.

From winikoff@cs.mu.OZ.AU Thu Mar  4 17:55:37 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27662; Thu, 4 Mar 93 17:55:36 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 4 Mar 93 17:55:36 +0100
Received: from chenas.inria.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by chenas.inria.fr (5.65c8d/92.02.29)
	via Fnet-EUnet id AA06400; Thu, 4 Mar 1993 12:34:25 +0100 (MET)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA27372; Thu, 4 Mar 93 03:26:40 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA00479
	Thu, 4 Mar 1993 22:26:19 +1100 (from winikoff)
Message-Id: <9303041126.479@mulga.cs.mu.OZ.AU>
Subject: Re: memory, video, and a few thoughts
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 4 Mar 93 22:26:18 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <2b91ab9d.davgar@davgar.UUCP>; from "davgar@uunet.UU.NET" at Mar 1, 93 1:22 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> I will again say: You can't allocate memory (address space)

OK, then we are allocating address space -- this would seem to imply that
the problem is then one for the compiler rather then the kernel.

> because it already exists!  It is just invalid.  Memory
> allocation is the process of changing invalid memory into valid
> memory.  All that should be returned is the error code.
> Additionally, address zero (and the nearby low addresses) should
> be reserved as invalid addresses, so chasing NULL causes an

Good idea

> immeadiate error.  (One of VMS's best desicisions, pity we can't
> also make hex 00 an invalid instruction...)
> 
> the size must (should) be exact.  Perhaps:
>         u16             at least 16 bits, unsigned integer
>         s32             at least 32 bits, signed integer
>         f32             at least 32 bits, floating point
>         u8e             exactly 8 bits, unsigned integer
> About the only thing that should require an exact size is
> something networked.

I think were confusing language and OS issues -- the OS has no real reason to
provide anything other then, say, 32 bits -- the language can subdivide this
any way it likes.


>         u18             at least 18 bits, unsigned integer
> We should support EVERY non-exact size up to the maximum
> supportable by the achitecture.  This particular type is useful
> to represent the time of day.
> 
> ---------------
> Both these complaints can be answered in the same way.  The
> feature (character set remapping and virtual memory) does not get
> invoked (save for one-time uses) until needed.

What ANDREAS was saying was that we SHOULDN'T implement extended character sets
that way -- rather we should have a 16 bit character set from the very start.

This is makes it smoother to use for non english (or extended english) character
sets.

> 
> While I am on the subject, I will say again that if Moose is a GUI
> only system I will disassociate myself from Moose.  I admit that
> Moose needs GUI support, but it needs text support as well.  I am
> not going to give up on Moose and text-based capabilities until
> forced.

I think we should plan to provide text capabilities -- invariably they'll be 
finished b4 the gooey.
We'll probably have a text UI for debugging purposes anyway --  I think 
programmers (especially those intending to modify the kernal/write devices
etc. would appreciate having the text UI 

--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From rideau@clipper Fri Mar  5 04:40:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12215; Fri, 5 Mar 93 04:40:29 +0100
Return-Path: <rideau@clipper>
Received-Date: Fri, 5 Mar 93 04:40:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA01328; Thu, 4 Mar 93 19:33:59 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from corvette.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12136; Fri, 5 Mar 93 04:33:51 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303050333.AA12136@clipper.ens.fr>
Subject: Re: Processes and Communication (2)
To: duzan@udel.edu (Gary D. Duzan)
Date: Fri, 5 Mar 93 4:33:53 MET
Cc: moose-programmers@sfu.ca
In-Reply-To:  <9303041206.aa01802@thorin.cis.udel.edu>; from "Gary D. Duzan" at Mar 4, 93 7:06 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Here is my reply to our Time Lord:
>>    This is an overview of my vision for processes and interprocess
>> communication in the MOOSE system. It is far from being a complete
>> specification, and I encourage discussion of the various features. I
>> have intentionally left out any implementation details or actual
>> example interface code so that we can decide on the abstract model
>> first and move on to the implementation once the model is ironed out.


>>    Entities in the MOOSE system are referred to as 'objects'. The
>> interface to an object is composed entirely of 'methods'. One object
>> communicates with another by 'invocing' a method on another object.
>> Invocation is accomplished through Remote Procedure Calls, or 'RPC'.
Why remote or whatever ? That's Microsoft-like name for things: they give
technical names to impress common users, and to show beginner programmers
that a technique much spoken about (because too longly and unjustly left
in the company's previous software) has (at last) been used.

>> An invoced method is called a 'thread'.
I think `invoked' should be righter.

>>    Objects represent protected units of functionality in MOOSE. With
>> the exception of inheirited (non-virtual) base class code (libraries),
(it's inherited)
>> each object has a completely private, non-shared address space. The
Hey ! You're interfering with implementation. From external view, the object
must cope with its methods. From high level, there are private members
(code or data), but even addressing space should be (IMHO) low-level enough
to be implementation dependant: we must also know that most processors
don't have the same protection scheme as the 386, when they have; so we
should rely on LLL interpreting and compiling to enforce non-interfering
between objects. That means LLL should be `high-level' enough to know
bounded arrays (not like C arrays).

>> kernel is reponsible for scheduling objects and providing resources as
>> needed. Each object has a specific protection level which determines
>> how the object's threads may directly modify the system hardware.
To me, the Kernel should only connect objects to resources; the resource
managers provide what they have how they will. Object threads should NOT
modify the hardware anyhow; device drivers are there for that; object
threads should handle neither less nor more than their `local' own members.

>>    An RPC call will contain information such as a remote object name,
>> the remote object's method name, permission information, and a set of
>> arguments to the method. The invocing thread is blocked, the message is
>> delivered to the destination object, the object executes the method
>> with the given arguments, and passes the return value (or error code)
>> in a message as a reply to the calling thread. Note that passing
>> pointers isn't useful, since objects have disjoint data spaces. There
>> are, however, techniques to improve performance when passing large data
>> items.
 Again, identifying objects should be all to the impl'; IMHO, HLL provides
only `virtual' pointer types (among the which naming); but naming as only ID
for an object is too costly both in speed and memory, and doesn't prevent
more form bugs than any other pointing devices, it's only more directly
readable by humans (I'm FOR naming, but not as primary system pointing).
IDs should depend on implementation; for the 386 (only), I recommend a
a 32 or 64 bit word; it may be just an offset in some common segment (for
a 'we trust all assembly, what we do not trust is interpreted' system),
a 16 bit (Descriptor Table pointer/system index), and 16 bit segment pointer
(for a 'do what you want inside your object, but IOC is through the Kernel
only' system), or the same plus offset, or whatever.
 (by D.T. pointer, I mean first 4K in DT can be standard, while the remaining
is remapped in virtual memory)

>>    The thread is the basic unit of execution within an object. A thread
>> can invoce a method of another object via an RPC. The calling thread is
>> blocked until the call is completed, but the other threads are allowed
>> to continue. The call is received by a thread in the target object that
>> waits for calls to that particular method. Threads can create othere
>> threads to execute while others are blocked. This allows the object to
>> continue processing while waiting on the result, while maintaining
>> procedure call semantics.
 That's only allowing Kernel-managed sleeping for threads.

>>    An object is created by an RPC call to an object with access to the
>> scheduler and resource allocator. An object with such access may also
>> destroy an object by descheduling it an deallocating its resources.
 Why so powerful objects ? An object may only destroy its own members; it
may of course willingly accept to destroy it on another ones' demand, but
that's another problem. Of course, the programmer may always be able to
ultimately call a persuasive enough object to obtain what he wishes.
>> Each object will have an initial set of object names. This will
>> generally include the name of an object that holds the names of other
>> objects. Each object should include a method to determine the names of
>> its other methods.
That's my hierarchical dictionnaryy stuff: of course I agree; but again
naming shouldn't be the only pointing way.

From winikoff@cs.mu.OZ.AU Fri Mar  5 06:07:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19307; Fri, 5 Mar 93 06:06:59 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 5 Mar 93 06:06:59 +0100
Received: from mulga.cs.mu.OZ.AU by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA25228
	Fri, 5 Mar 1993 16:06:35 +1100 (from winikoff)
Message-Id: <9303050506.25228@mulga.cs.mu.OZ.AU>
Subject: Re: Processes and Communication (2)
To: rideau@clipper (Francois-Rene Rideau)
Date: Fri, 5 Mar 93 16:06:34 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303050333.AA12136@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 5, 93 4:33 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> Why remote or whatever ? That's Microsoft-like name for things: they give
> technical names to impress common users, and to show beginner programmers
> that a technique much spoken about (because too longly and unjustly left
> in the company's previous software) has (at last) been used.

A little unfortunate, however it's a standard name so people kow what you;re
talkin g about.

> 
> >> An invoced method is called a 'thread'.
> I think `invoked' should be righter.

I think `righter' should be `more correct' :-)

> Hey ! You're interfering with implementation. From external view, the object

Some issues are sufficiently important that you can't abstract 'em.
Each process having it's own address space is possible on all MMU equiped
systems.

I am still opposed to having the system based around an interpreter.
Sure, it simplifies the solutions to some problems however the efficiency 
cost is prohibitive.

> must cope with its methods. From high level, there are private members
> (code or data), but even addressing space should be (IMHO) low-level enough
> to be implementation dependant: we must also know that most processors
> don't have the same protection scheme as the 386, when they have; so we
> should rely on LLL interpreting and compiling to enforce non-interfering
> between objects. That means LLL should be `high-level' enough to know
> bounded arrays (not like C arrays).
> 
> >> kernel is reponsible for scheduling objects and providing resources as
> >> needed. Each object has a specific protection level which determines
> >> how the object's threads may directly modify the system hardware.
> To me, the Kernel should only connect objects to resources; the resource
> managers provide what they have how they will. Object threads should NOT
> modify the hardware anyhow; device drivers are there for that; object
> threads should handle neither less nor more than their `local' own members.

Hey -- we're allowing device drivers to be objects -- that should be a  
plus :-)


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From rideau@clipper Fri Mar  5 06:45:46 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20748; Fri, 5 Mar 93 06:45:45 +0100
Return-Path: <rideau@clipper>
Received-Date: Fri, 5 Mar 93 06:45:45 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05153; Thu, 4 Mar 93 21:40:36 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from corvette.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20691; Fri, 5 Mar 93 06:40:33 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303050540.AA20691@clipper.ens.fr>
Subject: Re: Processes and Communication
To: winikoff@mulga.cs.mu.OZ.AU (Michael David WINIKOFF)
Date: Fri, 5 Mar 93 6:40:31 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <9303050506.25228@mulga.cs.mu.OZ.AU>; from "Michael David WINIKOFF" at Mar 5, 93 4:06 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(the message I reply to seems not to have been posted to the mailing list, so
if it quoted entirely)
Michael Winnikoff says:
>> 
>> > Why remote or whatever ? That's Microsoft-like name for things: they give
>> > technical names to impress common users, and to show beginner programmers
>> > that a technique much spoken about (because too longly and unjustly left
>> > in the company's previous software) has (at last) been used.
>> 
>> A little unfortunate, however it's a standard name so people kow what you;re
>> talkin g about.
>>
>> > 
>> > >> An invoced method is called a 'thread'.
>> > I think `invoked' should be righter.
>> 
>> I think `righter' should be `more correct' :-)
(oops !)

>> > Hey ! You're interfering with implementation. From external view, the object
>> 
>> Some issues are sufficiently important that you can't abstract 'em.
>> Each process having it's own address space is possible on all MMU equiped
>> systems.
MOOSE should be portable enough to be ported to other architectures than MMU
based, be it older or newer (to be) architectures. Of course, on a non-MMU
computer, you will be forced not to trust code not compiled (or interpreted)
on local host).

>> I am still opposed to having the system based around an interpreter.
>> Sure, it simplifies the solutions to some problems however the efficiency e
>> cost is prohibitive.
I don't think it is prohibitive at all, provided heavy calculus is compiled.
IMHO, you don't need have optimized code to properly run the system: OF COURSE
TIME-CRITICAL ROUTINES MUST BE COMPILED, either system or user routines; but
these can be more easily compiled from low-level code; so we come up with a
LLL standard: the system (and/or the user) chooses when to partly compile or
interpret code. HL routines often gain nothing at compile and may loose
efficiency and genericity, even speed (see my interpreting by RET, more rapid
than any CALL sequence). Whereas interpreting is very cheap in memory,
portable, easy for security, communication, extension. With little redundancy,
LLL programs can be as easily compiled as interpreted, so there's no need to
fear for a specialized code which would fit either compiling or interpretinge
but not both. The interpreter is also a very useful tool for system booting.
Once the system is stable, it's time more to compile. What I mean is we don't
need that much speed NOW.

>> > must cope with its methods. From high level, there are private members
>> > (code or data), but even addressing space should be (IMHO) low-level enough
>> > to be implementation dependant: we must also know that most processors
>> > don't have the same protection scheme as the 386, when they have; so we
>> > should rely on LLL interpreting and compiling to enforce non-interfering
>> > between objects. That means LLL should be `high-level' enough to know
>> > bounded arrays (not like C arrays).
>> > 
>> > >> kernel is reponsible for scheduling objects and providing resources as
>> > >> needed. Each object has a specific protection level which determines
>> > >> how the object's threads may directly modify the system hardware.
>> > To me, the Kernel should only connect objects to resources; the resource
>> > managers provide what they have how they will. Object threads should NOT
>> > modify the hardware anyhow; device drivers are there for that; object
>> > threads should handle neither less nor more than their `local' own members.
>> 
>> Hey -- we're allowing device drivers to be objects -- that should be a  
>> plus :-)
'f course

>> --------------------------------------------------------------------------------
>> Michael Winikoff
>> winikoff@cs.mu.oz.au
>> Computer science honours. University of Melbourne, Australia.
>> 


From winikoff@cs.mu.OZ.AU Fri Mar  5 07:30:10 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA21232; Fri, 5 Mar 93 07:30:08 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 5 Mar 93 07:30:08 +0100
Received: from chenas.inria.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by chenas.inria.fr (5.65c8d/92.02.29)
	via Fnet-EUnet id AA09232; Thu, 4 Mar 1993 13:25:33 +0100 (MET)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA29093; Thu, 4 Mar 93 04:18:27 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA01241
	Thu, 4 Mar 1993 23:13:42 +1100 (from winikoff)
Message-Id: <9303041213.1241@mulga.cs.mu.OZ.AU>
Subject: Reply to Fare' -- LONG
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 4 Mar 93 23:13:40 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9302272341.AA02171@clipper.ens.fr>; from "Francois-Rene Rideau" at Feb 28, 93 12:41 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> >> > Giving device drivers their own priority -- good.
> >> >
> Ok, but WHO (what processes) can set up device drivers ?
> if anyone can call its own local driver, there's no more security. See (1)

THis comes back to security -- any comments/suggestions?
THe concept of a superuser is a relatively simple (if rather insecure) way
of doing things.
Of course we'll have to introduce the notion of process ownership ...


Alternatively we can decide that this is a single user system so anyone logged 
in from the console is "safe" ...

> I know - tell me more if you know others). That's why the system should offer
> many different capabilities of allocating memory, from raw reservation of
> contiguous physical memory (to device drives) to garbage collecting-aware

NO! The kernel should offer a single simple and (hopefully) sufficiently 
general method that is used by all.
Why? It is not possible to anticipate the needs of all languages so we should 
make the system "extensible" in some way -- given that this is done it is
a waste to stuff some of the language specific memory allocation into the
kernel.


[Stuff about us copying Unix and how bad MS-DOS and MacOS are deleted ...]

(1) There's no need to go around insulting DOS and Mac -- we all know DOS's
shortcomings and the Mac was a good idea at the time.
(besides -- I do now some computer scientists that love Macs)

(2) The reason why Unix is so popular is that the original (small) Unixes 
had a number of good ideas (that tend to be taken for granted these days)
[Eg. device independant I/O]
Unix DOES have weak areas -- I see nothing wrong though in copying Unix's strong
areas.

> There we come to an important point: error handling. Of course, old OSes
> (stands for Old Shit ?), being based upon C, couldn't integrate this concept,
> neither could they understand anything sensible about HL programming (nor
> LL programming with respect (?) to DOS - Double Old Shit (OS/2 being half-old
> shit). Recent language like ADA, later version of (true) C++ and CAML do
> include exception handling, and many HLL I don't know certainly do. I like
> very much that of CAML (not knowing the others - tell me - 't'should be
> mostly taken from the same language as for C++, but CAML should be better
> because of automatic genericity as opposed to C++'s template hack). The
> Kernel should include exception handling as a standard, so that objects
> can exchange not only usual data, but also exceptional data (notice that
> these language do not allow embedding exception in data itself by declaration
> of exceptional format as should accept the language I vouch for (of course,
> their are ways to obtain equivalent results, but then why not repeat we all
> use Turing Machine equivalent languages ?)

Were designing an OS - not a langueg.
I'll come back to this point again, I think you're trying to throw a lot
of what properly belongs in a language into the kernel -- thereby imposing
a uniform object oriented view on all users of the OS.

Personally I will disassociate myself from MOOSE if we decide to enforce
OO programming on everything ... I feel that OO is overhyped.

Personally I'd much rather use a Very-High-Level-Language like Haskell --
OOPLs are based around imperative languages and are lower level as a result.

> 
> (BTW, who do have read my HL specs, and what do you think of it ? Do flame
> its flaws, you're welcome, but do encourage what pleases you in it too.
> Do not hesitate to ask for more precisions)
> (NB: CAML is a particular version of ML integrating imperative programming
> as well as declarative one; we work with it at the School (Ecole Normale
> Superieure) in its CAML light 0.5 implementation by Xavier Leroy & Damien
> Doligez; it's available for example at ftp: nuri.inria.fr - neither place
> nor time to tell more about it here; unhappily, the syntax being to concise
> it very dirty, as opposed to lisp's lots of insipid and stubborn parentheses).

I've used SML for a moderately large project ... my personal opinions:
(1) SML's syntax is *HORRIBLE* -- it's got all the rebundancy of Pascal ...
Haskell's or Miranda's syntax is HEAPS nicer.
(2) Exceptions should be reserved for programming in the Large and possibly 
removed -- trying to isolate an exception is a major pain.
(3) Ditto for side effects -- one of the bugs that I had to isolate involved
a function that modified it's argument being called without first making a copy
of the argument

Objects:
> >> > I like the approach of simply defining a standard format.
> Well, if not, this would no more really be OO'ed, and be another DOS, waiting
> to be (VERY quickly) obsolete !
> OO standardness is compulsory. To be in advance with other existing OS
> projects, we must also include NOW genericity (for the which C++ templates
> are only a hack) and logical programming (the most common use is find how
> to find the "best" path to transform a virtual object into another, knowing
> the elementary virtual transformations available and their physical cost).

Yet another OO fanatic ... :-)
I repeat -- objects are not magic ...

> >> > 
> >> > Why the "@" in semaphore@Down ?

Sorry -- I forgot to add ":-)"

> 
> >> > Should we have spinlocks too?
> On multiprocessor systems, of course, but that's a kernel implementation
> concern; let's not mix specs and its impl' again !

Yes -- however if we neglect them then the kernel on a multiprocessor will 
have a different interface to the kernel on a monoprocessor.
I suppose this would b einevitable anyway though .. :-(

> How complicated !
> Again, let's program it by layer. The lowest (kernel) layer does a Andreas
> says. Then, you can have a filter monopolize the lower-level resource to emit
> events on a queue, then if you want, mix that queue into a general event queue
> for stubborn processes to un-multiplex the global queue, as stupid current
> systems do. YES, you CAN do it ! But once you see there are simpler, easier
> means to handle data, by piping data just where you want, you WON'T use the
> centralizing algorithm. Everything is easier, neater, quicker, better, when
> objects just fit one into the other.

Think of it as a server object for timed events.
BTW I/O events have nothing to do with this -- the kernel could easily send
them directly to the correct address when they are generated.
I feel however that this addressing should be centralised rather then be 
scattered among the various device drivers
(1) It means less repeated work in the device drivers
(2) It's simpler to keep track of and maintain.

> Of course again there are several layers ! Every program uses just the
> one it pleases. Every layer has a standard interface; every interface can
> be filtered for programs not to interfere each with the other.

The existance of multiple layers hasn;t been mentioned yet.
I don't consider this obvious or even desirablefor efficiency reasons.
Each layer of indirection multipllies by the inefficiency of the previous layers

> Well, there's a difference between supporting a language and have it as a
> primary language. ANY system can run ANY language as long as it's powerful
> enough. You CAN run AppleSoft BASIC on a Unix WorkStation; but you just WON'T,
> because it's without any interest but historical. That should be the same for
> MOOSE and C/C++: of course you can still use C, but you won't be able to
> -directly- use all its power with such a LL dirty language, and you will have
> to include many a library to interface both. Moreover, standard LLLing allows
> easy implementation of ANY language you want, by providing a fore part of a
> compiler from the new language to any (combination of) existing standard layer
> of THE PL.

And there's a difference between supporting (allowing to conveniantly interface
to OS services) and being able to run by writing our own abstract kernel 
interface ...

> MOOSE should be Pee O aRe Tee A Bee eL Ee. However, we all come to have 386
> PC's, because cloning has made these stupid computers CHEAP and STANDARD.
> But, we'd love  to be able to run our new standard OS on an even CHEAPER,
> NON-STANDARD, BETTER computer (like, say, the Amiga or RISC machines).

I hate to say this but the AMiga isn't better -- the A600 and A1200 are based
around antique processors (68000 and 68020 respectively) and don't have anMMU.
Note that to the best of my knowledge NONE of the AMigas have MMUs.

The good thing about Amigas is the operating system 
 
> >> > Persistent objects subsume both processes and files.
> >> > Getting rid of the concept of the files is (IMHO) a strong forward step.
> see what I said above about Unix, files, and objects.
> 
> >> > One idea which may simplify swapping is to use a single address space across
> >> > all objects -- possibly even the one corresponding to where they are stored
> >> > on disk.
> >> > Of course most of the address space will be inaccessible ...
> >> > 
> >> > The main advantage of this scheme is that it makes shared memory simpler to 
> >> > program with -- otherwise pointers have to be avoided since the addresses
> >> > will differ from process to process.
> >> > 
> >> > [But see arenas later]
> Again, that's for implementation eyes only. See (1b)

Nope -- it affects the semantics of shared memory that will be visible to 
appplications.

> >> > (8) Microkernel:
> >> > 	Seems to be the way we're heading. Good.
> 't'should be able to run even on my HP28 ! Of course, you won't have any
> tools, then, hardly a few devices for the simplest I/O.

No -- Microkernel doesn't refer to the final system size.
It refers to the system architecture.
A microkernel design simply means that the kernel provides a minimal set
of services (Eg. memory management, multitasking and IPC) and other
system services (EG. file systems) are implemented outside of the kernel.

> Hey, this has few to do with an OS specs: Very Unportable ! Let's leave this to
> LLL implementation(s): sure it can be used, but we don't use assembler hacks
> -only- for the fun of it, but also to find HL requirements. What do 680x0
> programmers would say if they heard you with these 386 tricks ?
> There's only one thing at HL: you may want to allocate an object, and you may
> want to publish it, so that others can see it where you put signs.

Caught out on this one -- I have never programmed a 386 and i have programmed
a 68000 -- I guess that makes me a 680x0 programmer :-)


A problem that has to be handled when using shared memory is that pointers 
into the shared memory region are not normally valid across processes and 
hence one cannot store data structures in the shared memory region that use
pointers -- this differs significantly from the semantics of normal memory.

My suggestion ensures that shared memory has (in this respect) the same 
semantics as normal memory.

> >> > (13) Should we be providing threads? (I don't think so but am open to debate)
> what are threads/tasks but little/large objects ? Why build such a distinction

Threads share data space whereas tasks/processes don't.
Tasks are objects.
Threads would correspond to concurrent method activation within an object.
SInce the data is shared between the threads locking becomes important.

> * about DOS FAT systems:
> Some talk about reading/writing it. Of course, this is obvious on 386 based
> computers. But DOS FAT is so @#$^#$%^& that no sensible people would willingly
> use an OS with it as a main FS. Whatever FS is choosen to work on, this should
> be included as a device driver, not in the Kernel.

For the moment DOS compatibility is a definite plus.

> 
> 
> * Could one explain a poor ignorant frenchman the joke about Moose ?
> ('heard you talk about a Mr Moose; who was it ? )

Some american cartoon ... :-)

> 
> * dmarer:
>  Keep the Kernel as pure as possible: OK.
>  Allow non-OO programming: ??
>  - if it means device drivers are not bound to be OO clean, and heavy
>  computation need not look multiple method tables at each iteration, ok;
>  but if it means there is not a standard compulsory class hierarchy
>  from low level raw data classes to high level virtual classes for system
>  calls, I don't agree anymore !

Again -- you're forcing any users of the system to use an OO language.
I don't like that.
If you want an OO only environment, I suggest you get hold of something like
Smalltalk, Actors or Self -- all of which are pure OO languages which provide
an OO based environment.

> 
>   That's a general method for protection, which is after all only a "view" of
> sharing objects. To enhance this, you may add a key to names so an aggressive
> program not be able to pirat you because you use common names.

That's what capabilities are.


>  In fact, I think the Kernel Set should be exactly the C/ASM coded methods for
> handling low-level objects: tasks/thread/procedures (executable code in
> general, including stack management, and exception handling), memory
> allocation, object typing, virtual pointers and naming (including subnaming
> and polymorphism, linking and unlinking object to the running system (imagine
> the coding/decoding needed to load/save an object from the running session
> from/to mass memory). Nothing more.

Nothing MORE?!
I do not think that object typing, polymorphism etc. belong in the kernel.
Object typing should be done at compile time.
If you want an interprative system that can be written but you shouldn't
FORCE the system to do interpratation.


To summarise my comments:

The main problem is that you are confusing language and OS issues.

An OO operating system does NOT mean (IMHO) that all the support for OO 
langauges should be built into the OS (and certainly not into the kernel)

To me it means that the OS should provide some operations that make it easy
to implement persistant objects.

-------

* You should allow the freedom to do things at compile time for efficiency
reasons.

* You should allow the use of non OO languages -- otherwise you don't have a
generic OS -- you have an OO programming environment.

------

* The kernel should be minimal. It WILL have a resemblence to Unix in some areas
simply because in some areas Unix has done things in a good way.

Note that objects come ABOVE the kernel.

You don't want to have the kernel enforce complex semantical policies.
By lifting up such things into the compiiers you gain in efficiency and more 
importantly in maintainability.


Requiring the kernel to do polymorphic type checking and inheritance is like
requiring an OS to run structured code ... 

Michael
winikoff@cs.mu.oz.au


From winikoff@cs.mu.OZ.AU Fri Mar  5 07:51:13 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA21461; Fri, 5 Mar 93 07:51:12 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 5 Mar 93 07:51:12 +0100
Received: from mulga.cs.mu.OZ.AU by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA28519
	Fri, 5 Mar 1993 17:50:46 +1100 (from winikoff)
Message-Id: <9303050650.28519@mulga.cs.mu.OZ.AU>
Subject: Re: Processes and Communication
To: rideau@clipper (Francois-Rene Rideau)
Date: Fri, 5 Mar 93 17:50:45 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303050540.AA20691@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 5, 93 6:40 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> Michael Winnikoff says:

Winikoff -- only one "n" ... thanks! :-)

> >> Some issues are sufficiently important that you can't abstract 'em.
> >> Each process having it's own address space is possible on all MMU equiped
> >> systems.
> MOOSE should be portable enough to be ported to other architectures than MMU
> based, be it older or newer (to be) architectures. Of course, on a non-MMU
> computer, you will be forced not to trust code not compiled (or interpreted)
> on local host).

This is a matter of specification -- we have to decide whether or not we 
would like MOOSE to run on non-MMU machines.

I think not -- most (all?) new machines have MMUs and memory protection  is
quite useful for a programmer.
(It;s also ESSENTIAL for a secure multi user system)

Any comments from anyone else?

> 
> >> I am still opposed to having the system based around an interpreter.
> >> Sure, it simplifies the solutions to some problems however the efficiency e
> >> cost is prohibitive.
> I don't think it is prohibitive at all, provided heavy calculus is compiled.
> IMHO, you don't need have optimized code to properly run the system: OF COURSE
> TIME-CRITICAL ROUTINES MUST BE COMPILED, either system or user routines; but
> these can be more easily compiled from low-level code; so we come up with a
> LLL standard: the system (and/or the user) chooses when to partly compile or
> interpret code. HL routines often gain nothing at compile and may loose
> efficiency and genericity, even speed (see my interpreting by RET, more rapid
> than any CALL sequence). Whereas interpreting is very cheap in memory,
> portable, easy for security, communication, extension. With little redundancy,
> LLL programs can be as easily compiled as interpreted, so there's no need to
> fear for a specialized code which would fit either compiling or interpretinge
> but not both. The interpreter is also a very useful tool for system booting.
> Once the system is stable, it's time more to compile. What I mean is we don't
> need that much speed NOW.

Mixing interpreting and compiling creates additional complexity.
I would like to think that this issue is orthogonal (ie. independant of) 
the OS.
The benefits of interpretation that are claimed are:
(1) Code size
(2) Flexibility
(3) Portability
(4) Security
(5) Communication
(6) Extension

I don't feel that code size is such an issue.
Portability can be catered to at the language level -- I don't see any advantage
to providing portabiity by having different machines emulate a common abstract
machine.

Security is irrelevant -- as long as you allow the existance of compiled
code you have to provide memory protection to have security anyway.


A side note, having a machine independant "assembly language" is a good idea.
The main problem is that we have to ensure that
(1) It is implementable efficiently on all machines we would be porting to
(2) It doesn't make impossible (or inefficient) operations which are supported
by the machines.

Ie. if machine A has an efficient way of doing X which machine B doesn't have
then a global LLL will force us to ignore the efficient way of doing X.

For instance if machine A supports array indexing but B doesn't then LLL can 
either offer array indexing and be inefficient on B or not offer array indexing
and have the compiler for A having to recognise a sequence of instructions
as representing an array reference which can be efficiently compiled.

> 

--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From mueller@sc.ZIB-Berlin.DE Fri Mar  5 11:35:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA26926; Fri, 5 Mar 93 11:35:26 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Fri, 5 Mar 93 11:35:26 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11609; Fri, 5 Mar 93 01:51:51 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA29259; Fri, 5 Mar 93 10:51:47 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA18087; Fri, 5 Mar 93 10:51:46 +0100
Date: Fri, 5 Mar 93 10:51:46 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303050951.AA18087@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: IPC in MOOSE
Status: OR

Hi,

I've already started a private discussion with Gary about his IPC
ideas. In my opinion one should specify the design of IPC in a more
higher abstract level. Don't start discussions if it is efficiently 
programmable or whatsoever. It's specification time: Let's first define
what we want and then see how we can get it.

(I would prefer the term remote object invocation (ROI) and not IPC for
discussion on how remotely access an object. To Fare: "remote" in this
context are all objects, which are not within an application's scope and
which location must be found (see below). And it is not a MicroSoft term.)

>    This is an overview of my vision for processes and interprocess
> communication in the MOOSE system. It is far from being a complete
> specification, and I encourage discussion of the various features. I
> have intentionally left out any implementation details or actual
> example interface code so that we can decide on the abstract model
> first and move on to the implementation once the model is ironed out.
> 
>    Entities in the MOOSE system are referred to as 'objects'. The
> interface to an object is composed entirely of 'methods'. One object
> communicates with another by 'invocing' a method on another object.
> Invocation is accomplished through Remote Procedure Calls, or 'RPC'.
> An invoced method is called a 'thread'.
> 

I think, that's too deep. Let's simply say, that an object must be able
to invoke another object's method. (I don't like to mention how this should
be done, via RPC or not.)

>    Objects represent protected units of functionality in MOOSE. With
> the exception of inheirited (non-virtual) base class code (libraries),
> each object has a completely private, non-shared address space. The
> kernel is reponsible for scheduling objects and providing resources as
> needed. Each object has a specific protection level which determines
> how the object's threads may directly modify the system hardware.
> 
>    An RPC call will contain information such as a remote object name,
> the remote object's method name, permission information, and a set of
> arguments to the method. The invocing thread is blocked, the message is
> delivered to the destination object, the object executes the method
> with the given arguments, and passes the return value (or error code)
> in a message as a reply to the calling thread. Note that passing
> pointers isn't useful, since objects have disjoint data spaces. There
> are, however, techniques to improve performance when passing large data
> items.

That's again too deep. Naming should be done by another object, eg. a 
NAME_SERVICE. This must exist, because objects must be able to publish 
themselves or their methods to the outer world. Thus, an object X which
want to be published invoke a methods of the NAME_SERVICE, which makes X
known within the NAME_SERVICE's scope:

+---+              +--------------+
| X |---publish--->| NAME_SERVICE |
+---+              +--------------+

If an object Y wants to use X it first must determine X's location. Therefore
it asks its NAME_SERVICE, which returns X location:

+---+                           +--------------+
|   |---ask for X's location--->|              |
| Y |                           | NAME_SERVICE |
|   |<---return X's location----|              |
+---+                           +--------------+

Now Y can simply invoke a method from X:

+---+             +---+
| Y |---invoke--->| X |
+---+             +---+

With this design it is possible only to contact published objects. More: You
have to contact the right NAME_SERVICE to get a desired object's location. 
Think of several applications (which are O B J E C T S), which all have their 
own NAME_SERVICE available. Several objects with the same name may coexist
even with different functionality but the application's local NAME_SERVICE
secures, that the application is only able to invoke methods of well known
objects. 

Of course it is possible to "link" NAME_SERVICE objects. So it is possible to
create hierachical or other name scopes. If an object's location cannot be
resolved within the first (ie. smallest) scope the next higher NAME_SERVICE
is automatically invoked.

What I currently left out is, how an object received knowledge of "its"
NAME_SERVICE. (Or to be precise: Which NAME_SERVICE provides the knowledge
of the desired object.) If you want, I can try to present you a design
idea.



>    The thread is the basic unit of execution within an object. A thread
> can invoce a method of another object via an RPC. The calling thread is
> blocked until the call is completed, but the other threads are allowed
> to continue. The call is received by a thread in the target object that
> waits for calls to that particular method. Threads can create other
> threads to execute while others are blocked. This allows the object to
> continue processing while waiting on the result, while maintaining
> procedure call semantics.

That's again too deep for the first ROI specification.

> 
>    An object is created by an RPC call to an object with access to the
> scheduler and resource allocator. An object with such access may also
> destroy an object by descheduling it an deallocating its resources.
> Each object will have an initial set of object names. This will
> generally include the name of an object that holds the names of other
> objects. 

Hmm, what does object creation have to do with ROI? (BTW: In my opinion
an application which cannot receive access to an object, simply create an
instance of a new one. Then the object can make itself available via the 
application's NAME_SERVICE or a predefined one. Of course the application
object already know the object's location and can invoke methods immediately.)

> Each object should include a method to determine the names of
> its other methods.

NO! Publish all methods which should be accessable by other objects to the
NAME_SERVICE! Seperate the services (provided by objects) and it's management
(provided by NAME_SERVICEs). Without such separation each time you include
a new service you must also change the determination method. Don't mix up
services and their availability.
 
Cheers,

Peter 

From rideau@clipper Fri Mar  5 23:27:33 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15474; Fri, 5 Mar 93 23:27:31 +0100
Return-Path: <rideau@clipper>
Received-Date: Fri, 5 Mar 93 23:27:31 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14325; Fri, 5 Mar 93 14:15:35 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from corvette.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15151; Fri, 5 Mar 93 23:15:23 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303052215.AA15151@clipper.ens.fr>
Subject: Re: Processes and Communication
To: winikoff@mulga.cs.mu.OZ.AU (Michael David WINIKOFF)
Date: Fri, 5 Mar 93 23:15:25 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <9303050650.28519@mulga.cs.mu.OZ.AU>; from "Michael David WINIKOFF" at Mar 5, 93 5:50 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(in reply to Michael Winikoff - with one ``n'' only)
>> > >> Some issues are sufficiently important that you can't abstract 'em.
>> > >> Each process having it's own address space is possible on all MMU equipede
>> > >> systems.
>> > MOOSE should be portable enough to be ported to other architectures than MMU
>> > based, be it older or newer (to be) architectures. Of course, on a non-MMU
>> > computer, you will be forced not to trust code not compiled (or interpreted)
>> > on local host).
>> 
>> This is a matter of specification -- we have to decide whether or not we
>> would like MOOSE to run on non-MMU machines.
>> 
>> I think not -- most (all?) new machines have MMUs and memory protection  is
>> quite useful for a programmer.
>> (It;s also ESSENTIAL for a secure multi user system)
>> 
>> Any comments from anyone else?
(that's always the good'ole question: what is in spec's and what is in impl')

>> > >> I am still opposed to having the system based around an interpreter.
>> > >> Sure, it simplifies the solutions to some problems however the efficiency e
>> > >> cost is prohibitive.
>> > I don't think it is prohibitive at all, provided heavy calculus is compiled.
>> > IMHO, you don't need have optimized code to properly run the system: OF COURSE
>> > TIME-CRITICAL ROUTINES MUST BE COMPILED, either system or user routines; but
>> > these can be more easily compiled from low-level code; so we come up with a
>> > LLL standard: the system (and/or the user) chooses when to partly compile or
>> > interpret code. HL routines often gain nothing at compile and may loose
>> > efficiency and genericity, even speed (see my interpreting by RET, more rapid
>> > than any CALL sequence). Whereas interpreting is very cheap in memory,
>> > portable, easy for security, communication, extension. With little redundancy,
>> > LLL programs can be as easily compiled as interpreted, so there's no need to
>> > fear for a specialized code which would fit either compiling or interpretinge
>> > but not both. The interpreter is also a very useful tool for system booting.
>> > Once the system is stable, it's time more to compile. What I mean is we don't
>> > need that much speed NOW.
>> 
>> Mixing interpreting and compiling creates additional complexity.
 Additional to what ? Do you think the unix system with its thousands languages
(C,sh,csh,awk,perl,ed,...,...), each having a totally separated (i.e. redone
entirely, with all subsequent redundancy) is simpler ? Not to talk about DOS
where no language is standard, only executable code.
Complicating a very little bit the base system, and adding at the same time a
useful debugging and/or everyday programming tool sounds sensible to me. What
do the others think ? What does Dennis think ?
>> I would like to think that this issue is orthogonal (ie. independant of)
>> the OS.
 Again, if the OS  brings but another interface to hardware to comply with, what's
the use for it: we already have plenty of common featured OSes, with plenty of
processes and IPC. We mustn't think system OO features as a diktat forcing you to
use OO language and programming; they should be a new freedom, not a new chains:
now programs should be able to interchange data AND code at the same time,
dynamically and without having to recompile everything to add just a single simple
quick routine. Programs are not bound to use system OO tehcnique (at least not
internally; standard run-time libraries will be provided for every existing language
to interface the system), but at last they CAN use them, and not have to reprogram
them entirely and run apart from the other app's you would have liked to share
objects with.

>> The benefits of interpretation that are claimed are:
>> (1) Code size
>> (2) Flexibility
>> (3) Portability
>> (4) Security
>> (5) Communication
>> (6) Extension

>> I don't feel that code size is such an issue.
That's not an issue, but a pleasant extra !

>> Portability can be catered to at the language level -- I don't see any advantage
>> to providing portabiity by having different machines emulate a common abstract
>> machine.
THAT'S a language-level portability ! It should be low-level enough to be compiled
efficiently, high-level enough to allow Inter-Object-Communication. The impl'
should include required redundancy for quick interpretation.

>> Security is irrelevant -- as long as you allow the existance of compiled
>> code you have to provide memory protection to have security anyway.
Nope, if you're sure the compiler put the required checks (not too many checks
but just what is needed); that's why a compiled program must have been ensured
by the local host before execution (which ultimately sums up to a popup menu
to ask the user his opinion)

>> A side note, having a machine independant "assembly language" is a good idea.
>> The main problem is that we have to ensure that
>> (1) It is implementable efficiently on all machines we would be porting to
>> (2) It doesn't make impossible (or inefficient) operations which are supported
>> by the machines.
If the LLL was too low-level, it wouldn't be portable anyore.
>> Ie. if machine A has an efficient way of doing X which machine B doesn't have
>> then a global LLL will force us to ignore the efficient way of doing X.
On the opposite, the LLL would give a standard means to access the resource both
on A and B !
>> For instance if machine A supports array indexing but B doesn't then LLL can 
>> either offer array indexing and be inefficient on B or not offer array indexing
>> and have the compiler for A having to recognise a sequence of instructions
>> as representing an array reference which can be efficiently compiled.
As it is easier and safer to translate high-level objects to low-level ones than
the converse, I'd say the LLL should manage HL objects

Well, make up your mind everybody and tell your opinion.

			     ,
			  Fare
		200% time mooser-programmer.








From rideau@clipper Fri Mar  5 23:43:36 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15845; Fri, 5 Mar 93 23:43:35 +0100
Return-Path: <rideau@clipper>
Received-Date: Fri, 5 Mar 93 23:43:35 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15536; Fri, 5 Mar 93 14:33:49 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from corvette.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15609; Fri, 5 Mar 93 23:33:41 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303052233.AA15609@clipper.ens.fr>
Subject: Re: IPC in MOOSE
To: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Date: Fri, 5 Mar 93 23:33:42 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <9303050951.AA18087@sc.zib-berlin.dbp.de>; from "Peter Mueller" at Mar 5, 93 10:51 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>> Hi,
>> 
>> I've already started a private discussion with Gary about his IPC
>> ideas. In my opinion one should specify the design of IPC in a more
>> higher abstract level. Don't start discussions if it is efficiently 
>> programmable or whatsoever. It's specification time: Let's first define
>> what we want and then see how we can get it.
>> 
>> [...]
>> >    Entities in the MOOSE system are referred to as 'objects'. The
>> > interface to an object is composed entirely of 'methods'. One object
>> > communicates with another by 'invocing' a method on another object.
>> > Invocation is accomplished through Remote Procedure Calls, or 'RPC'.
>> > An invoced method is called a 'thread'.
>>
>> I think, that's too deep. Let's simply say, that an object must be able
>> to invoke another object's method. (I don't like to mention how this should
>> be done, via RPC or not.)
ok for RPC being an excess; but the remaining seems good to me.

>> >    Objects represent protected units of functionality in MOOSE. With
>> > the exception of inheirited (non-virtual) base class code (libraries),
>> > each object has a completely private, non-shared address space. The
>> > kernel is reponsible for scheduling objects and providing resources as
>> > needed. Each object has a specific protection level which determines
>> > how the object's threads may directly modify the system hardware.
the system should provide the resources; but the Kernel shall only establish
a link between asker and provider. As for protection level, why not accept
the you can use an object's methods iff you possess its ID ? It may be
clearer, more portable, easier to implement on a generic system, etc.

>> >    An RPC call will contain information such as a remote object name,
>> > the remote object's method name, permission information, and a set of
>> > arguments to the method. The invocing thread is blocked, the message is
>> > delivered to the destination object, the object executes the method
>> > with the given arguments, and passes the return value (or error code)
>> > in a message as a reply to the calling thread. Note that passing
>> > pointers isn't useful, since objects have disjoint data spaces. There
>> > are, however, techniques to improve performance when passing large data
>> > items.
Again, I suggest to implement a standard second way for errors and exceptions,
with an exception handler routine stack.

>> That's again too deep. Naming should be done by another object, eg. a 
>> NAME_SERVICE. This must exist, because objects must be able to publish 
>> themselves or their methods to the outer world. Thus, an object X which
>> want to be published invoke a methods of the NAME_SERVICE, which makes X
>> known within the NAME_SERVICE's scope:
>> 
>> +---+              +--------------+
>> | X |---publish--->| NAME_SERVICE |
>> +---+              +--------------+
>> 
>> If an object Y wants to use X it first must determine X's location. Therefore
>> it asks its NAME_SERVICE, which returns X location:
>> 
>> +---+                           +--------------+
>> |   |---ask for X's location--->|              |
>> | Y |                           | NAME_SERVICE |
>> |   |<---return X's location----|              |
>> +---+                           +--------------+
>> 
>> Now Y can simply invoke a method from X:
>> 
>> +---+             +---+
>> | Y |---invoke--->| X |
>> +---+             +---+
>> 
>> With this design it is possible only to contact published objects. More: You
>> have to contact the right NAME_SERVICE to get a desired object's location. 
>> Think of several applications (which are O B J E C T S), which all have their 
>> own NAME_SERVICE available. Several objects with the same name may coexist
>> even with different functionality but the application's local NAME_SERVICE
>> secures, that the application is only able to invoke methods of well known
>> objects. 
>> 
>> Of course it is possible to "link" NAME_SERVICE objects. So it is possible to
>> create hierachical or other name scopes. If an object's location cannot be
>> resolved within the first (ie. smallest) scope the next higher NAME_SERVICE
>> is automatically invoked.
>> 
>> What I currently left out is, how an object received knowledge of "its"
>> NAME_SERVICE. (Or to be precise: Which NAME_SERVICE provides the knowledge
>> of the desired object.) If you want, I can try to present you a design
>> idea.
again, I do agree with Peter's remark, but else support Gary's views (perhaps
are we going to agree upon that 'dictionnary' stuff as I call it - call it as
you may).

>> >    The thread is the basic unit of execution within an object. A thread
>> > can invoce a method of another object via an RPC. The calling thread is
>> > blocked until the call is completed, but the other threads are allowed
>> > to continue. The call is received by a thread in the target object that
>> > waits for calls to that particular method. Threads can create other
>> > threads to execute while others are blocked. This allows the object to
>> > continue processing while waiting on the result, while maintaining
>> > procedure call semantics.
>> 
>> That's again too deep for the first ROI specification.
Well Gary's just anticipating on implementation.

>> >    An object is created by an RPC call to an object with access to the
>> > scheduler and resource allocator. An object with such access may also
>> > destroy an object by descheduling it an deallocating its resources.
>> > Each object will have an initial set of object names. This will
>> > generally include the name of an object that holds the names of other
>> > objects. 
>> 
>> Hmm, what does object creation have to do with ROI? (BTW: In my opinion
>> an application which cannot receive access to an object, simply create an
>> instance of a new one. Then the object can make itself available via the 
>> application's NAME_SERVICE or a predefined one. Of course the application
>> object already know the object's location and can invoke methods immediately.)
>> 
>> > Each object should include a method to determine the names of
>> > its other methods.
>> 
>> NO! Publish all methods which should be accessable by other objects to the
>> NAME_SERVICE! Seperate the services (provided by objects) and it's management
>> (provided by NAME_SERVICEs). Without such separation each time you include
>> a new service you must also change the determination method. Don't mix up
>> services and their availability.
Uh, well, both ! It may be useful to ask the method's name directly to the
object without having to look through the whole table (but both methods are
equivalent; you can build the name list from the objects with a method list
method; or you can build a method list method from a name list; so to me,
that's up to implementation)

>> Cheers,
>> 
>> Peter 
>> 


From cis.udel.edu!udel.edu!duzan Sat Mar  6 01:34:32 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18068; Sat, 6 Mar 93 01:34:31 +0100
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Sat, 6 Mar 93 01:34:31 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA23290; Fri, 5 Mar 93 16:29:28 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa21098; 5 Mar 93 19:21 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa04224; 6 Mar 93 0:20 GMT
Received: from sol.cis.udel.edu by bugs.cis.udel.edu id aa17440;
          6 Mar 93 0:18 GMT
To: moose-programmers@sfu.ca
Subject: Re: Processes and Communication (2) 
In-Reply-To: Your message of "Fri, 05 Mar 93 04:33:53 +0700."
             <9303050333.AA12136@clipper.ens.fr> 
Date: Fri, 05 Mar 93 19:17:50 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303060018.aa17440@bugs.cis.udel.edu>
Status: OR

=>>>    Entities in the MOOSE system are referred to as 'objects'. The
=>>> interface to an object is composed entirely of 'methods'. One object
=>>> communicates with another by 'invocing' a method on another object.
=>>> Invocation is accomplished through Remote Procedure Calls, or 'RPC'.
=>Why remote or whatever ? That's Microsoft-like name for things: they give
=>technical names to impress common users, and to show beginner programmers
=>that a technique much spoken about (because too longly and unjustly left
=>in the company's previous software) has (at last) been used.
=>
   I called it that because that is what it is called. RPC is a well
known Operating Systems concept, not a product, protocol, or
implementation.

=>>> An invoced method is called a 'thread'.
=>I think `invoked' should be righter.
=>
   Quite right. I was shooting for the root word of invocation and missed
slightly. Isn't English wonderful?

=>To me, the Kernel should only connect objects to resources; the resource
=>managers provide what they have how they will. Object threads should NOT
=>modify the hardware anyhow; device drivers are there for that; object
=>threads should handle neither less nor more than their `local' own members.
=>
   Putting device access in special priveleged objects increases the
flexibility and aids the configuration of the system.

=>>>    The thread is the basic unit of execution within an object. A thread
=>>> can invoce a method of another object via an RPC. The calling thread is
=>>> blocked until the call is completed, but the other threads are allowed
=>>> to continue. The call is received by a thread in the target object that
=>>> waits for calls to that particular method. Threads can create othere
=>>> threads to execute while others are blocked. This allows the object to
=>>> continue processing while waiting on the result, while maintaining
=>>> procedure call semantics.
=> That's only allowing Kernel-managed sleeping for threads.
=>
   Where did I say that?

=>>>    An object is created by an RPC call to an object with access to the
=>>> scheduler and resource allocator. An object with such access may also
=>>> destroy an object by descheduling it an deallocating its resources.
=> Why so powerful objects ? An object may only destroy its own members; it
=>may of course willingly accept to destroy it on another ones' demand, but
=>that's another problem. Of course, the programmer may always be able to
=>ultimately call a persuasive enough object to obtain what he wishes.

   The more functionality we move to objects, the more flexible the
system becomes. Actually, it is theoretically possible to have a
system with no kernel at all (given proper hardware protection
mechanisms.) In such a system, everything is just a piece of code.
That would be the ultimate in system flexibility. Of course, since
it is a terribly radical idea, a lot of people (including many on
this list :-) won't care for it. I can live with that. :-)

=>>> Each object will have an initial set of object names. This will
=>>> generally include the name of an object that holds the names of other
=>>> objects. Each object should include a method to determine the names of
=>>> its other methods.
=>That's my hierarchical dictionnaryy stuff: of course I agree; but again
=>naming shouldn't be the only pointing way.

   What would you suggest adding that would preserve the basic notion
of objects interacting through calls to methods?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From cis.udel.edu!udel.edu!duzan Sat Mar  6 01:44:10 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18235; Sat, 6 Mar 93 01:44:09 +0100
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Sat, 6 Mar 93 01:44:09 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA23871; Fri, 5 Mar 93 16:40:15 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa21481; 5 Mar 93 19:37 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa04276; 6 Mar 93 0:36 GMT
Received: from sol.cis.udel.edu by bugs.cis.udel.edu id aa17546;
          6 Mar 93 0:34 GMT
To: moose-programmers@sfu.ca
Subject: Re: Processes and Communication 
In-Reply-To: Your message of "Fri, 05 Mar 93 06:40:31 +0700."
             <9303050540.AA20691@clipper.ens.fr> 
Date: Fri, 05 Mar 93 19:34:38 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303060034.aa17546@bugs.cis.udel.edu>
Status: OR

=>>> Some issues are sufficiently important that you can't abstract 'em.
=>>> Each process having it's own address space is possible on all MMU equiped
=>>> systems.
=>MOOSE should be portable enough to be ported to other architectures than MMU
=>based, be it older or newer (to be) architectures. Of course, on a non-MMU
=>computer, you will be forced not to trust code not compiled (or interpreted)
=>on local host).
=>
   The conceptual model should assume an available hardware protection
mechanism. Each implementation should use available mechanisms as
appropriate. Implementation on systems without hardware protection
should preserve the conceptual model even though it can't really
enforce it.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From MAILER-DAEMON@dmi.ens.fr Sat Mar  6 02:46:17 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18873; Sat, 6 Mar 93 02:46:14 +0100
Return-Path: <MAILER-DAEMON@dmi.ens.fr>
Received-Date: Sat, 6 Mar 93 02:46:14 +0100
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Date: Sat, 6 Mar 1993 02:45:47 +0100
From: Mail Delivery Subsystem <MAILER-DAEMON@dmi.ens.fr>
Message-Id: <199303060145.AA07034@dmi.ens.fr>
To: rideau@clipper
Cc: Postmaster@dmi.ens.fr
Subject: Returned mail: User unknown
Status: OR

   ----- Transcript of session follows -----
While talking to whistler.sfu.ca:
>>> RCPT To:<mooser-programmers@sfu.ca>
<<< 550 <mooser-programmers@sfu.ca>... User unknown: Invalid argument
550 <mooser-programmers@sfu.ca>... User unknown

   ----- Unsent message follows -----
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received-Date: Sat, 6 Mar 1993 02:45:47 +0100
Received: from corvette.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18855; Sat, 6 Mar 93 02:45:42 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303060145.AA18855@clipper.ens.fr>
Subject: ORG,KER+ far12
To: winikoff@mulga.cs.mu.OZ.AU (Michael David WINIKOFF)
Date: Sat, 6 Mar 93 2:45:44 MET
Cc: mooser-programmers@sfu.ca
In-Reply-To: <9303041213.1241@mulga.cs.mu.OZ.AU>; from "Michael David WINIKOFF" at Mar 4, 93 11:13 pm
X-Mailer: ELM [version 2.3 PL11]

Here's my reply to Michael's reply.
He flamed me; I somehow deserved it as I called for answers, even flames.
I also must clarify (and sometimes change) my point of view to take into
account his arguments.


>> > >> > Giving device drivers their own priority -- good.
>> > Ok, but WHO (what processes) can set up device drivers ?
>> > if anyone can call its own local driver, there's no more security. See (1)
>> THis comes back to security -- any comments/suggestions?
>> THe concept of a superuser is a relatively simple (if rather insecure) way
>> of doing things.
>> Of course we'll have to introduce the notion of process ownership ...

I prefer the more general 'you know its ID, you can use it' phylosophy. Then
you can have a 'user' object with the list of its known objects being limited
to some objects, and some aspects only of objects not entirely owned.


>> Alternatively we can decide that this is a single user system so anyone logged 
>> in from the console is "safe" ...

Well, we should have a superuser console; but the common user shouldn't need
use it in everyday life if the system is stable (if he has access to it).



>> > I know - tell me more if you know others). That's why the system should offer
>> > many different capabilities of allocating memory, from raw reservation of
>> > contiguous physical memory (to device drives) to garbage collecting-aware

>> NO! The kernel should offer a single simple and (hopefully) sufficiently 
>> general method that is used by all.
>> Why? It is not possible to anticipate the needs of all languages so we should 
>> make the system "extensible" in some way -- given that this is done it is
>> a waste to stuff some of the language specific memory allocation into the
>> kernel.

Hey ! who told you the Kernel should do that ? Of course the Kernel won't
provide any memory allocation routine; it will only branch you to the memory
device you need (only a basic device being available on a basic system).



>> [Stuff about us copying Unix and how bad MS-DOS and MacOS are deleted ...]

>> (1) There's no need to go around insulting DOS and Mac -- we all know DOS's
>> shortcomings and the Mac was a good idea at the time.
>> (besides -- I do now some computer scientists that love Macs)
(I don't hate Macs; I like them, but an unextended Mac is only an
unprogrammable toy, and the development kit is much more awful than the
standard user interface).

>> (2) The reason why Unix is so popular is that the original (small) Unixes 
>> had a number of good ideas (that tend to be taken for granted these days)
>> [Eg. device independant I/O]
>> Unix DOES have weak areas -- I see nothing wrong though in copying Unix's strong
>> areas.

What I wouldn't want us to copy is not only one or another of those OSes'
flaws, but mostly their philosophy, which leads to what we already have. I
think if you follow unix philosophy for example, you won't do better than
a twenty year old still evolving product on the which many a group work.

>> > There we come to an important point: error handling. Of course, old OSes
>> > (stands for Old Shit ?), being based upon C, couldn't integrate this concept,
>> > neither could they understand anything sensible about HL programming (nor
>> > LL programming with respect (?) to DOS - Double Old Shit (OS/2 being half-old
>> > shit). Recent language like ADA, later version of (true) C++ and CAML do
>> > include exception handling, and many HLL I don't know certainly do. I like
>> > very much that of CAML (not knowing the others - tell me - 't'should be
>> > mostly taken from the same language as for C++, but CAML should be better
>> > because of automatic genericity as opposed to C++'s template hack). The
>> > Kernel should include exception handling as a standard, so that objects
>> > can exchange not only usual data, but also exceptional data (notice that
>> > these language do not allow embedding exception in data itself by declaration
>> > of exceptional format as should accept the language I vouch for (of course,
>> > their are ways to obtain equivalent results, but then why not repeat we all
>> > use Turing Machine equivalent languages ?)

>> Were designing an OS - not a langueg.
 Yes, but to me the OS (not only the Kernel, but the OS as a whole) should
provide languages with everything they may need. If the system is as passive
as unix, you only force app writers to do the stuff you refused to do. The
result will be less efficiency or more effort from the app writer (if he is
willing to optimize things), and no communication possible between apps, as
each had to redesign its features.
 To me OS and language issue are linked.
 That's perhaps an essential point to agree or disagree with.
 I propose we have a vote on it (see end of the letter)

>> I'll come back to this point again, I think you're trying to throw a lot
>> of what properly belongs in a language into the kernel -- thereby imposing
>> a uniform object oriented view on all users of the OS.
>> 
>> Personally I will disassociate myself from MOOSE if we decide to enforce
>> OO programming on everything ... I feel that OO is overhyped.
>> 
>> Personally I'd much rather use a Very-High-Level-Language like Haskell --
>> OOPLs are based around imperative languages and are lower level as a result.
>> 
>> > 
>> > (BTW, who do have read my HL specs, and what do you think of it ? Do flame
>> > its flaws, you're welcome, but do encourage what pleases you in it too.
>> > Do not hesitate to ask for more precisions)
>> > (NB: CAML is a particular version of ML integrating imperative programming
>> > as well as declarative one; we work with it at the School (Ecole Normale
>> > Superieure) in its CAML light 0.5 implementation by Xavier Leroy & Damien
>> > Doligez; it's available for example at ftp: nuri.inria.fr - neither place
>> > nor time to tell more about it here; unhappily, the syntax being to concise
>> > it very dirty, as opposed to lisp's lots of insipid and stubborn parentheses).
>> 
>> I've used SML for a moderately large project ... my personal opinions:
>> (1) SML's syntax is *HORRIBLE* -- it's got all the rebundancy of Pascal ...
>> Haskell's or Miranda's syntax is HEAPS nicer.
of course ML has a horrible syntax, but it has interesting characteristics
to implement if we are to facilitate language implementation and (what is
more important) standard inter-language communication .

>> (2) Exceptions should be reserved for programming in the Large and possibly 
>> removed -- trying to isolate an exception is a major pain.
>> (3) Ditto for side effects -- one of the bugs that I had to isolate involved
>> a function that modified it's argument being called without first making a copy
>> of the argument

>> Objects:
>> > >> > I like the approach of simply defining a standard format.
>> > Well, if not, this would no more really be OO'ed, and be another DOS, waiting
>> > to be (VERY quickly) obsolete !
>> > OO standardness is compulsory. To be in advance with other existing OS
>> > projects, we must also include NOW genericity (for the which C++ templates
>> > are only a hack) and logical programming (the most common use is find how
>> > to find the "best" path to transform a virtual object into another, knowing
>> > the elementary virtual transformations available and their physical cost).
>> 
>> Yet another OO fanatic ... :-)
>> I repeat -- objects are not magic ...

They're no magic, they're a fast data AND CODE interchange protocol.
Sometimes I HATE the limitations OO programming has upon my code (see Borland
products and their OO coding); but then I see it is because of the
implementation which allows only one coding for the same object; compiled
private objects should be optimized, not like public objects, so that the
limitation disappears.


>> > >> > Should we have spinlocks too?
>> > On multiprocessor systems, of course, but that's a kernel implementation
>> > concern; let's not mix specs and its impl' again !
>> 
>> Yes -- however if we neglect them then the kernel on a multiprocessor will
>> have a different interface to the kernel on a monoprocessor.
>> I suppose this would b einevitable anyway though .. :-(

If I understand, a spinlock is the same principle as the whole task managing
stuff: one at a time has access to the resource; so having a sub-task manager
should be the same as having a spinlock. If not, can someone detail spinlock
functionment ?


>> > How complicated !
>> > Again, let's program it by layer. The lowest (kernel) layer does a Andreas
>> > says. Then, you can have a filter monopolize the lower-level resource to emit
>> > events on a queue, then if you want, mix that queue into a general event queue
>> > for stubborn processes to un-multiplex the global queue, as stupid current
>> > systems do. YES, you CAN do it ! But once you see there are simpler, easier
>> > means to handle data, by piping data just where you want, you WON'T use the
>> > centralizing algorithm. Everything is easier, neater, quicker, better, when
>> > objects just fit one into the other.

>> Think of it as a server object for timed events.
>> BTW I/O events have nothing to do with this -- the kernel could easily send
>> them directly to the correct address when they are generated.
That's what happens, but the address changes dynamically with the environment.

>> I feel however that this addressing should be centralised rather then be
>> scattered among the various device drivers
>> (1) It means less repeated work in the device drivers
>> (2) It's simpler to keep track of and maintain.

(1) less repeated work, no as in both systems every event is managed once by
just the proper code (so the distance between interrupt and catcher is lesser,
equal in the worst case) (common standard libraries can avoid redundant
coding)
(2) Yes and no; by separating unlinked events, we may allow separated
debugging, etc; Both systems are equivalent to a filter; but (partly or
wholly) centralizing from this system is cheap/immediate, whereas the
converse is slow.


>> > Of course again there are several layers ! Every program uses just the
>> > one it pleases. Every layer has a standard interface; every interface can
>> > be filtered for programs not to interfere each with the other.

>> The existance of multiple layers hasn;t been mentioned yet.
(there it has :-) (what do the other think about it)
>> I don't consider this obvious or even desirablefor efficiency reasons.
>> Each layer of indirection multipllies by the inefficiency of the previous layers

Hey, but we're not in a DOS chaining where every layer must intercept the
previous and call it afterwards; each layer can be called directly, and if
it uses a sublayer, that should not be slower (only possibly quicker) than
if an app has to do it itself. Layer does not necessarily means filter, and
when filter there is, it can be optimized at compile time to short-circuit
calls when possible (so there is no delay in communication unintercepted
by the filter).


>> > Well, there's a difference between supporting a language and have it as a
>> > primary language. ANY system can run ANY language as long as it's powerful
>> > enough. You CAN run AppleSoft BASIC on a Unix WorkStation; but you just WON'T,
>> > because it's without any interest but historical. That should be the same for
>> > MOOSE and C/C++: of course you can still use C, but you won't be able to
>> > -directly- use all its power with such a LL dirty language, and you will have
>> > to include many a library to interface both. Moreover, standard LLLing allows
>> > easy implementation of ANY language you want, by providing a fore part of a
>> > compiler from the new language to any (combination of) existing standard layer
>> > of THE PL.

>> And there's a difference between supporting (allowing to conveniantly interface
>> to OS services) and being able to run by writing our own abstract kernel 
>> interface ...

YES, and that's why we really should support ANY language to achieve perfect
communication between ANY programs.



>> > MOOSE should be Pee O aRe Tee A Bee eL Ee. However, we all come to have 386
>> > PC's, because cloning has made these stupid computers CHEAP and STANDARD.
>> > But, we'd love  to be able to run our new standard OS on an even CHEAPER,
>> > NON-STANDARD, BETTER computer (like, say, the Amiga or RISC machines).
>> 
>> I hate to say this but the AMiga isn't better -- the A600 and A1200 are based
>> around antique processors (68000 and 68020 respectively) and don't have anMMU.
>> Note that to the best of my knowledge NONE of the AMigas have MMUs.

It depends on the PC and the Amiga; but I'm not going to have a flamewar
on this subject in this mailing list.

>> The good thing about Amigas is the operating system 

YES, and the copros (and the fact the OS runs perfectly with the copros)



>> > >> > Persistent objects subsume both processes and files.
>> > >> > Getting rid of the concept of the files is (IMHO) a strong forward step.
>> > see what I said above about Unix, files, and objects.
>> > 
>> > >> > One idea which may simplify swapping is to use a single address space across
>> > >> > all objects -- possibly even the one corresponding to where they are stored
>> > >> > on disk.
>> > >> > Of course most of the address space will be inaccessible ...
>> > >> > 
>> > >> > The main advantage of this scheme is that it makes shared memory simpler to 
>> > >> > program with -- otherwise pointers have to be avoided since the addresses
>> > >> > will differ from process to process.
>> > >> > 
>> > >> > [But see arenas later]
>> > Again, that's for implementation eyes only. See (1b)
>> 
>> Nope -- it affects the semantics of shared memory that will be visible to 
>> appplications.
What is so transcendantal about sharing memory ?
if you know the object's intimate ID, you can read/write directly to it; if
many know, they all can. That's all, no comment. Is there something great
about it ? Sharing memory should be but a restricted aspect of sharing and
exchanging objects.


>> > >> > (8) Microkernel:
>> > >> > 	Seems to be the way we're heading. Good.
>> > 't'should be able to run even on my HP28 ! Of course, you won't have any
>> > tools, then, hardly a few devices for the simplest I/O.
>> 
>> No -- Microkernel doesn't refer to the final system size.
>> It refers to the system architecture.
>> A microkernel design simply means that the kernel provides a minimal set
>> of services (Eg. memory management, multitasking and IPC) and other
>> system services (EG. file systems) are implemented outside of the kernel.

I misinterpreted our comrad's words. So much for me ! But I'd still like the
Kernel plus few simple devices to fit an HP calculator !



>> > Hey, this has few to do with an OS specs: Very Unportable ! Let's leave this to
>> > LLL implementation(s): sure it can be used, but we don't use assembler hacks
>> > -only- for the fun of it, but also to find HL requirements. What do 680x0
>> > programmers would say if they heard you with these 386 tricks ?
>> > There's only one thing at HL: you may want to allocate an object, and you may
>> > want to publish it, so that others can see it where you put signs.
>> 
>> Caught out on this one -- I have never programmed a 386 and i have programmed
>> a 68000 -- I guess that makes me a 680x0 programmer :-)

>> A problem that has to be handled when using shared memory is that pointers
>> into the shared memory region are not normally valid across processes and
>> hence one cannot store data structures in the shared memory region that use
>> pointers -- this differs significantly from the semantics of normal memory.
>> 
>> My suggestion ensures that shared memory has (in this respect) the same
>> semantics as normal memory.

But this forces objects to align at MMU page ! That's too much limitating
OOing, which should accept objects any sizes (most of which will be tiny, as
subpart of larger objects)



>> > >> > (13) Should we be providing threads? (I don't think so but am open to debate)
>> > what are threads/tasks but little/large objects ? Why build such a distinction

>> Threads share data space whereas tasks/processes don't.
>> Tasks are objects.
>> Threads would correspond to concurrent method activation within an object.
>> Since the data is shared between the threads locking becomes important.

Again, that seems a totally arbitrary distinction: you always share
something with someone (or else, the process has NO interest); UI programs
would like to share windowing memory with the main UI device; piped programs
can happily run with a shared memory pipe, etc; there's no limit to sharing
little or big objects. On the opposite, you'll never want to share
everything (at least, you won't have the same stack and/or registers). So
threads and tasks are no absolute concepts, but relative ones: if you share
memory with another one, you're a thread to it, if not you're a task ! That
becomes ridiculous. If unix created two words, it's because of a unix badly
fixed misconception, not because of an improvement.



>> > * about DOS FAT systems:
>> > Some talk about reading/writing it. Of course, this is obvious on 386 based
>> > computers. But DOS FAT is so @#$^#$%^& that no sensible people would willingly
>> > use an OS with it as a main FS. Whatever FS is choosen to work on, this should
>> > be included as a device driver, not in the Kernel.
>> For the moment DOS compatibility is a definite plus.
Yes, and in the future, OS/2, linux, * compatibility also; and an emulator
would be even greater; but this has nothing to do with the Kernel, and DOS
FAT shouldn't be our primary FS (which does not mean we cannot have a generic
FS running inside DOS FAT system, as any other FS)

>> > * Could one explain a poor ignorant frenchman the joke about Moose ?
>> > ('heard you talk about a Mr Moose; who was it ? )
>> Some american cartoon ... :-)

Is there nothing more about it ?


>> > * dmarer:
>> >  Keep the Kernel as pure as possible: OK.
>> >  Allow non-OO programming: ??
>> >  - if it means device drivers are not bound to be OO clean, and heavy
>> >  computation need not look multiple method tables at each iteration, ok;
>> >  but if it means there is not a standard compulsory class hierarchy
>> >  from low level raw data classes to high level virtual classes for system
>> >  calls, I don't agree anymore !

>> Again -- you're forcing any users of the system to use an OO language.
>> I don't like that.
NO, I'm forcing the INTERFACE to be OOed; for computations and all that, you
may do as you please; C, assembler, fortran, whatever, there is no problem;
we could even develop compilers for these which would give public access to
non-OO variables with OO methods (for example, what inside compiled code is
an integer array will appear externally as an integer array object); thus,
you won't even have to think about interfacing; it will be done automatically
when asked.


>> If you want an OO only environment, I suggest you get hold of something like
>> Smalltalk, Actors or Self -- all of which are pure OO languages which provide
>> an OO based environment.

I DON'T want an oo ONLY environment, but an oo CAPABLE environment, where
independant apps can nevertheless interchange data without the poor user
having to write a data format translation program each time (provided he is
proficient enouh, he has sufficient documentation about coding and efficient
algorithms to decode, and tricks to implement those algorithms, etc).


>> >   That's a general method for protection, which is after all only a "view" of
>> > sharing objects. To enhance this, you may add a key to names so an aggressive
>> > program not be able to pirat you because you use common names.
>> That's what capabilities are.

Uh ... what are you calling capabilities ?



>> >  In fact, I think the Kernel Set should be exactly the C/ASM coded methods for
>> > handling low-level objects: tasks/thread/procedures (executable code in
>> > general, including stack management, and exception handling), memory
>> > allocation, object typing, virtual pointers and naming (including subnaming
>> > and polymorphism, linking and unlinking object to the running system (imagine
>> > the coding/decoding needed to load/save an object from the running session
>> > from/to mass memory). Nothing more.

>> Nothing MORE?!
>> I do not think that object typing, polymorphism etc. belong in the kernel.
>> Object typing should be done at compile time.
>> If you want an interprative system that can be written but you shouldn't
>> FORCE the system to do interpratation.

If we are one day able to have a standard interchange format for data&code, it
is compulsory to include it in base system (I'm not talking about the Kernel
only, but also the set of standard devices available). If we are to quickly
interchange code, we cannot afford compiling a HLL program each time; so a LLL
is good; if the LLL CAN be interpreted (but is also aimed at compiling), it
is all the better, as it saves great amount of time for HL routines.
(that's infinitely more efficient than, say, a shell&awk script). I'm not
trying to impose an interpretative only system. I'd hate that. But I'm
also pretending that writing the interpreter before the compiler is easier,
and we don't need lightning speed to first boot the system. When the system
is stable, we can begin compiling everything.



>> To summarise my comments:
>> 
>> The main problem is that you are confusing language and OS issues.

I don't think I'm CONFUSING them, but I sure am linking them.
I'd like the others to bring their viewpoint upon this critical point.
Support me, question me, criticize me, flame me; but please reply as
Michael did.


>> An OO operating system does NOT mean (IMHO) that all the support for OO
>> langauges should be built into the OS (and certainly not into the kernel)
>> 
>> To me it means that the OS should provide some operations that make it easy
>> to implement persistant objects.

What do you call "some operations", and "persistant objects". To me,
you have no OOed OS if every language is going to completely reimplement
their objects; you only have an OS with an annoying OOed interface (as
with the Mac for many aspects).


>> * You should allow the freedom to do things at compile time for efficiency
>> reasons.

I never thought otherwise.


>> * You should allow the use of non OO languages -- otherwise you don't have a
>> generic OS -- you have an OO programming environment.

I have the same answer, and I have spoken about that just before.


>> * The kernel should be minimal. It WILL have a resemblence to Unix in some areas
>> simply because in some areas Unix has done things in a good way.

yes, but it won't be a unix clone by just following unix philosophy.


>> Note that objects come ABOVE the kernel.

Above the KERNEL, I don't know. But IMO certainly not above the basic system
(kernel+device) set.


>> You don't want to have the kernel enforce complex semantical policies.
>> By lifting up such things into the compiiers you gain in efficiency and more
>> importantly in maintainability.

By having (simple) semantical policies enforced you can at last have a
transparent system where apps truely can communicate with each other
(and not only merge results as most "advanced" current systems only do).

>> Requiring the kernel to do polymorphic type checking and inheritance is like
>> requiring an OS to run structured code ...

Uh ?


>> Michael
>> winikoff@cs.mu.oz.au
>> 
	   ,
	Fare
	(rideau@clipper.ens.fr)
	200% time moose programming froggy
	(but I never ate any frog's leg)


----------------------------------------------------------------------------
P.S.
 By now, we should be able to have a decision summarizing process. I'd like
Dennis (or someone else) to be a referee for our major decisions, and keep
up to date vote reports on important questions.
 The first thing is to agree on the question's formulation. The moderator
will put the formula (or formulas) he and the main parties think fit the
best to define the problem. Then, he will list solutions proposed, even
silly ones, with unanimously agreed comments about these solutions. Then
will come a list of raw votes (including haven't voted or neutral lists).
Then will come each one's opinion. Finally, official current MOOSE position
will be stated. As a note, a list of messages detailing each ones' view on
the problem can follow.
 Well, something like this should be done; now, I certainly haven't done
the best choices. Do not hesitate to propose changes, in the form as in the
contents.

----------------------------------------------------------------------------
VOTE #1

PROBLEM:
 What's the OO part of the system to you ?

POSSSIBLE ANSWERS:
 1) Nothing. The OS simply shouldn't be OOed at all.
 2) The interface only. The OS is divided into object which you access
 through  methods. Programs do as they wish and we trust them to be OOed
 (that is, you can dream !). The interface will then only be a brighter
 but slower interface to a standard OS.
 3) Compile level standard. There will be a HL PL  standard; each time
 you add a new object class to  the system, you must recompile it and
 add a device driver. If there is a major incompatibility with previous
 classes, the whole set of incompatible classes will have to be compiled
 again. Code and data won't be able to be interchanged together. Objects
 will have to be expressed in the standard HL PL to run, so that there
 will be HLLs to the HLPL compilers as there are HLL to C compilers under
 unix.
 4) HLL standard with opaque implementation. Almost the same as before;
 but the objects are implemented at system level. However the way they
 are depends on system implementation and is opaque to normal
 user/programmer. Code and data will be able to be interchanged
 together, but on same kind of hosts only; you will have to recompile
 everything and translate data when you change hardware.
 5) LLL standard. Low-level here means near to compiling (interpreting)
 requirements, not that objects aren't accessible. Objects are
 accessible through standard LLL features. LLL can be quickly compiled
 or even more quickly interpreted if for a few times only. LLL has a
 standard format which allows code&data quick common interchange
 between different hardware supporting the OS. You don't need slow
 HLL to standard HLPL compilers, only easy to do HLL to LLL compilers;
 a good LLL compiler will then be a common back-end for every existing
 language. Developpers can concentrate on optimizing it. Equal
 efficiency at compiling and interpreting is achieved through
 language redundancies.

VOTES:
(numbers can be reallocated, as long as the whole file is updated)
 - 1)
 - 2)
 - 3)
 - 4)
 - 5) Fare' Rideau
 - not concerned)
 - haven't voted) everyone else !
	Andreas Arff
        Gary Duzan
        David Garfield
        Ross Hayden
        Dennis Marer
        Rob McKeever
        John Newlin
        Dan Odom
        Michael Winikoff
        Peter Mueller
	('hope nobody was forgotten)


OPINIONS:
 - Fare': To me, OOing should be what makes MOOSE fundamentally new and good.
 It should at last enable data & CODE interchange (as data is nothing without
 its caretaking code)
 
CURRENT MOOSE POSITION:
 Too few have expressed their opinion for a Moose position to be taken.
 Moreover, Dennis hasn't taken part into the debate yet.

MESSAGE POINTING:
 began in message ORG,KER+ far12
 Fare's opinion in far12
-----------------------------------------------------------------------------

From ANDREASA@sofus.dhhalden.no Sat Mar  6 12:41:49 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03729; Sat, 6 Mar 93 12:41:48 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Sat, 6 Mar 93 12:41:48 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA10074; Sat, 6 Mar 93 03:37:29 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <29113-0@fenris.dhhalden.no>; Sat, 6 Mar 1993 12:37:23 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930306123709.416; 06 Mar 93 12:37:22 -100
Message-Id: <MAILQUEUE-101.930306123700.384@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 6 Mar 93 12:37:00 +0100
Subject: Re:ORG,KER+ far12
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Hello everybody.

> >> > >> > Giving device drivers their own priority -- good.
> >> > Ok, but WHO (what processes) can set up device drivers ?
> >> > if anyone can call its own local driver, there's no more security. See (1)
> >> THis comes back to security -- any comments/suggestions?
> >> THe concept of a superuser is a relatively simple (if rather insecure) way
> >> of doing things.
> >> Of course we'll have to introduce the notion of process ownership ...

Don't like the idea of a superuser, a chain is never stronger than its weakest
link. It's better if we could make the OS replace the superusers most powerful
rights.
As I see it, we have a dictionary with a list of possible device drivers,
as harddisk, soundcard etc. If a program has its own device driver it first
looks into the dictionary, is there any device drivers that can fulfill what
I want to do? If, add myself to the dictionary as a passive device, else
add myself as an active device.
The dictionary must have dictionary entries for a huge set of possible
device drivers. If we want, we can tag our own device drivers as
non-changeable to make the os more secure. Then only a superuser could change
the entries.
Now I see one problem that can/will arise, a device not mentioned in the
dictionary, but then the superuser could add it into the dictionary.
This might look like a cumbersome way of doing things, but that is the way
I'd like it. It is flexible and requires very little human involvment.
The OS could support calls like CheckForDictionaryEntry (xxx),
AddToDictionaryEntry (xxx, yyyy).

> I prefer the more general 'you know its ID, you can use it' phylosophy. Then
> you can have a 'user' object with the list of its known objects being limited
> to some objects, and some aspects only of objects not entirely owned.

See my part over.

> >> Alternatively we can decide that this is a single user system so anyone logged
> >> in from the console is "safe" ...
>
> Well, we should have a superuser console; but the common user shouldn't need
> use it in everyday life if the system is stable (if he has access to it).

See my part over.

> >> > I know - tell me more if you know others). That's why the system should
> >> > offer
> >> > many different capabilities of allocating memory, from raw reservation of
> >> > contiguous physical memory (to device drives) to garbage collecting-aware
>
> >> NO! The kernel should offer a single simple and (hopefully) sufficiently
> >> general method that is used by all.
>
> Hey ! who told you the Kernel should do that ? Of course the Kernel won't
> provide any memory allocation routine; it will only branch you to the memory
> device you need (only a basic device being available on a basic system).

As long as the kernel can give amounts of code to the system, we don't
actually care what happens to that memory amount, does we. I vote for
Fare's(with appostrof over the 'e' :-) way of doing it concerning this issue.

> >> [Stuff about us copying Unix and how bad MS-DOS and MacOS are deleted ...]

Should agree of a name Fare' for MS-DOS, I would prefer to call it
ugglybuggly dos. :-)

> >> (1) There's no need to go around insulting DOS and Mac -- we all know DOS's


> >> > There we come to an important point: error handling. Of course, old OSes
> >> > (stands for Old Shit ?), being based upon C, couldn't integrate this concept,
> >> > neither could they understand anything sensible about HL programming (nor
> >> > LL programming with respect (?) to DOS - Double Old Shit (OS/2 being half-old
> >> > shit). Recent language like ADA, later version of (true) C++ and CAML do
> >> > include exception handling, and many HLL I don't know certainly do. I like
> >> > very much that of CAML (not knowing the others - tell me - 't'should be
> >> > mostly taken from the same language as for C++, but CAML should be better
> >> > because of automatic genericity as opposed to C++'s template hack). The
> >> > Kernel should include exception handling as a standard, so that objects
> >> > can exchange not only usual data, but also exceptional data (notice that
> >> > these language do not allow embedding exception in data itself by declaration
> >> > of exceptional format as should accept the language I vouch for (of course,
> >> > their are ways to obtain equivalent results, but then why not repeat we all
> >> > use Turing Machine equivalent languages ?)

Let's design a critical event device, of the style I've already proposed.
A tree-structured function list (? :-). When a critical event appers it
just calls the function linked, belonging to the app, or just a standard
function, if the app hasn't added one to the device.

> >> Were designing an OS - not a langueg.
True enough, but what is an OS without any accesible functions from the
outside world. An OS and nothing more. A vast screen with no apps :-)

> >> I'll come back to this point again, I think you're trying to throw a lot
> >> of what properly belongs in a language into the kernel -- thereby imposing
> >> a uniform object oriented view on all users of the OS.
> >>
> >> Personally I will disassociate myself from MOOSE if we decide to enforce
> >> OO programming on everything ... I feel that OO is overhyped.
It depends on the way we implement to objects...
> >> Personally I'd much rather use a Very-High-Level-Language like Haskell --
> >> OOPLs are based around imperative languages and are lower level as a result.
No language discussion please, as you said, we are not designing a language,
but an OS.

> >> Objects:
> >> > >> > I like the approach of simply defining a standard format.
> >> > Well, if not, this would no more really be OO'ed, and be another DOS, waiting
> >> > to be (VERY quickly) obsolete !
> >> > OO standardness is compulsory. To be in advance with other existing OS
> >> > projects, we must also include NOW genericity (for the which C++ templates
> >> > are only a hack) and logical programming (the most common use is find how
> >> > to find the "best" path to transform a virtual object into another, knowing
> >> > the elementary virtual transformations available and their physical cost).
> >>
> >> Yet another OO fanatic ... :-)
> >> I repeat -- objects are not magic ...
But they can be very helpful from time to time...

> >> > How complicated !
> >> > Again, let's program it by layer. The lowest (kernel) layer does a Andreas
> >> > says. Then, you can have a filter monopolize the lower-level resource to emit
> >> > events on a queue, then if you want, mix that queue into a general event queue
> >> > for stubborn processes to un-multiplex the global queue, as stupid current
> >> > systems do. YES, you CAN do it ! But once you see there are simpler, easier
> >> > means to handle data, by piping data just where you want, you WON'T use the
> >> > centralizing algorithm. Everything is easier, neater, quicker, better, when
> >> > objects just fit one into the other.
I liked that part "does an Andreas say".

Have to go now. I'll continue in another mail. Have a nice weekend.


Arff

sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From rideau@clipper Sat Mar  6 17:40:52 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08836; Sat, 6 Mar 93 17:40:51 +0100
Return-Path: <rideau@clipper>
Received-Date: Sat, 6 Mar 93 17:40:51 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14276; Sat, 6 Mar 93 08:37:51 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from corvette.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08751; Sat, 6 Mar 93 17:37:42 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303061637.AA08751@clipper.ens.fr>
Subject: Re:ORG,KER+ far12
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Sat, 6 Mar 93 17:37:43 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <MAILQUEUE-101.930306123700.384@sofus.dhhalden.no>; from "Andreas Arff" at Mar 6, 93 12:37 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>> Hello everybody.
>> 
>> Don't like the idea of a superuser, a chain is never stronger than its weakest
>> link. It's better if we could make the OS replace the superusers most powerful
>> rights.
>> As I see it, we have a dictionary with a list of possible device drivers,
>> as harddisk, soundcard etc. If a program has its own device driver it first
>> looks into the dictionary, is there any device drivers that can fulfill what
>> I want to do? If, add myself to the dictionary as a passive device, else
>> add myself as an active device.
>> The dictionary must have dictionary entries for a huge set of possible
>> device drivers. If we want, we can tag our own device drivers as
>> non-changeable to make the os more secure. Then only a superuser could change
>> the entries.
>> Now I see one problem that can/will arise, a device not mentioned in the
>> dictionary, but then the superuser could add it into the dictionary.
>> This might look like a cumbersome way of doing things, but that is the way
>> I'd like it. It is flexible and requires very little human involvment.
>> The OS could support calls like CheckForDictionaryEntry (xxx),
>> AddToDictionaryEntry (xxx, yyyy).
I think we can solve ths problem by each object having its own local 'virtual'
dictionary. Then the 'superuser' (not inevitably a system special object)
will only be a console (program somehow inteacting with the user to have
anything he wants done - an intepreted language is compulsory here for the
shell, so why not the same as the LLL, with special libraries added ?) with
EVERYTHING in its dictionnay. From there, the 'supeuser' can (manually or
automatically) export non dangerous names to more public parts of the
dictionary.

>> > I prefer the more general 'you know its ID, you can use it' phylosophy. Then
>> > you can have a 'user' object with the list of its known objects being limited
>> > to some objects, and some aspects only of objects not entirely owned.
>> 
>> See my part over.
>> 
We seem to agree !
What of the other moose-programmers ? or won't they also be moose-specifiers ?


>> > >> > [...] That's why the system should offer many different
>> > >> > capabilities of allocating memory, from raw reservation of
>> > >> > contiguous physical memory (to device drives) to garbage
>> > >> > collecting-aware [...]
>> >
>> > >> NO! The kernel should offer a single simple and (hopefully)
>> > >> sufficiently general method that is used by all.
>> >
>> > Hey ! who told you the Kernel should do that ? Of course the
>> > Kernel won't provide /* added: itself */ any memory allocation
>> > routine; it will only branch you to the memory device you need
>> > (only a basic device being available on a basic system).
>> 
>> As long as the kernel can give amounts of code to the system, we don't
>> actually care what happens to that memory amount, does we. I vote for
>> Fare's(with appostrof over the 'e' :-) way of doing it concerning this
>> issue.
(actually, that's not an apostrophe but a french acute accent, which doesn't
exist within the 0-127 ASCII character set ;-( )


>> > >> > There we come to an important point: error handling. Of course, old OSes
>> > >> > (stands for Old Shit ?), being based upon C, couldn't integrate this concept,
>> > >> > neither could they understand anything sensible about HL programming (nor
>> > >> > LL programming with respect (?) to DOS - Double Old Shit (OS/2 being half-old
>> > >> > shit). Recent language like ADA, later version of (true) C++ and CAML do
>> > >> > include exception handling, and many HLL I don't know certainly do. I like
>> > >> > very much that of CAML (not knowing the others - tell me - 't'should be
>> > >> > mostly taken from the same language as for C++, but CAML should be better
>> > >> > because of automatic genericity as opposed to C++'s template hack). The
>> > >> > Kernel should include exception handling as a standard, so that objects
>> > >> > can exchange not only usual data, but also exceptional data (notice that
>> > >> > these language do not allow embedding exception in data itself by declaration
>> > >> > of exceptional format as should accept the language I vouch for (of course,
>> > >> > their are ways to obtain equivalent results, but then why not repeat we all
>> > >> > use Turing Machine equivalent languages ?)
>>
>> Let's design a critical event device, of the style I've already proposed.
>> A tree-structured function list (? :-). When a critical event appers it
>> just calls the function linked, belonging to the app, or just a standard
>> function, if the app hasn't added one to the device.
That's it ! But/and each thread can add a leaf/branch to the tree, so that
what I have proposed is having the tree-structure be a sub-structure of the
threading structure.

>> > >> Were designing an OS - not a langueg.
>> True enough, but what is an OS without any accesible functions from the
>> outside world. An OS and nothing more. A vast screen with no apps :-)
>> 
>> > >> I'll come back to this point again, I think you're trying to throw a lot
>> > >> of what properly belongs in a language into the kernel -- thereby imposing
>> > >> a uniform object oriented view on all users of the OS.
>> > >>
>> > >> Personally I will disassociate myself from MOOSE if we decide to enforce
>> > >> OO programming on everything ... I feel that OO is overhyped.
>> It depends on the way we implement to objects...
(I don't like people like MS and the such, who talk a lot about OO, but
don't ever implement it a correct way for the common of us to use, so that
their OOing is only an added limitations in lieu of an added freedom.
Apart from that, I see nothing bad at OOing, if properly implemented for
optimizing a compile-time)

>> > >> Personally I'd much rather use a Very-High-Level-Language like Haskell --
>> > >> OOPLs are based around imperative languages and are lower level as a result.
>> No language discussion please, as you said, we are not designing a language,
>> but an OS.

>> > >> Objects:
>> > >> > >> > I like the approach of simply defining a standard format.
>> > >> > Well, if not, this would no more really be OO'ed, and be another DOS, waiting
>> > >> > to be (VERY quickly) obsolete !
>> > >> > OO standardness is compulsory. To be in advance with other existing OS
>> > >> > projects, we must also include NOW genericity (for the which C++ templates
>> > >> > are only a hack) and logical programming (the most common use is find how
>> > >> > to find the "best" path to transform a virtual object into another, knowing
>> > >> > the elementary virtual transformations available and their physical cost).
>> > >>
>> > >> Yet another OO fanatic ... :-)
>> > >> I repeat -- objects are not magic ...
>> But they can be very helpful from time to time...
and as I repeat, they are the only known means to
correctly communicate code together with data. And
without code, data is useless.

>> > >> > How complicated !
>> > >> > Again, let's program it by layer. The lowest (kernel) layer does a Andreas
>> > >> > says. Then, you can have a filter monopolize the lower-level resource to emit
>> > >> > events on a queue, then if you want, mix that queue into a general event queue
>> > >> > for stubborn processes to un-multiplex the global queue, as stupid current
>> > >> > systems do. YES, you CAN do it ! But once you see there are simpler, easier
>> > >> > means to handle data, by piping data just where you want, you WON'T use the
>> > >> > centralizing algorithm. Everything is easier, neater, quicker, better, when
>> > >> > objects just fit one into the other.
>> I liked that part "does an Andreas say".
of course it was a mistype: we should all have read 'AS Andreas says'.
>> Have to go now. I'll continue in another mail. Have a nice weekend.
>> 
>> 
>> Arff
>> 
>> sig.'s in for 1000 miles service
>>         --Andreas Arff          andreasa@dhhalden.no--
   ,
Fare
-- Franc,ois-Rene' Ba^n Rideau D+a(.ng Vu~ --
(Following the Vietnamese convention for placing accents/modifiers
after the letter, as ASCII is only 127 characters, including
forbidden control characters and line limitation, so 95 (32-126)
useable codes only. Down with stubborn ASCII !)



From udel.edu!cis.udel.edu,!udel.edu!duzan Sat Mar  6 17:51:12 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09025; Sat, 6 Mar 93 17:51:11 +0100
Return-Path: <udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sat, 6 Mar 93 17:51:11 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14457; Sat, 6 Mar 93 08:48:24 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa27302; 6 Mar 93 11:47 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa12473; 6 Mar 93 16:43 GMT
Received: from sol.cis.udel.edu by ra.cis.udel.edu id aa05935;
          6 Mar 93 16:43 GMT
To: moose-programmers@sfu.ca
Subject: OO?
In-Reply-To: Your message of "Sat, 06 Mar 93 02:45:47 +0100."
             <199303060145.AA07034@dmi.ens.fr> 
Date: Sat, 06 Mar 93 11:43:12 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303061643.aa05935@ra.cis.udel.edu>
Status: OR

=>If I understand, a spinlock is the same principle as the whole task managing
=>stuff: one at a time has access to the resource; so having a sub-task manager
=>should be the same as having a spinlock. If not, can someone detail spinlock
=>functionment ?

   It is a multiprocessor locking protocol. A simple example is
test-and-set. A test-and-set is an atomic action that tests a particular
value and if is passes the test, sets it to a new value. For example, a
spin lock initially holds the value FALSE, indicating no processes in the
critical section. The first process to grab the lock will execute a
test-and-set. Since the lock is FALSE, it is set to TRUE and the process
continues into the critical section. A second process (on another
processor) attempts to enter the critical section by executing its own
test-and-set. Since the lock is TRUE, it may not enter, so it enters a
tight loop (spin) of test-and-set operations. When the first process has
completed the critical section, it sets the lock to FALSE. The second
process's next test-and-set operation will then succede, setting the lock
to TRUE and allowing the secon process into the critical section. Since
test-and-set is an atomic operation, more than one process(or) can spin
on a given lock and only one can acquire it at a time. This isn't the
most efficient spinning protocol, but it covers the basic idea.

=>>> > * Could one explain a poor ignorant frenchman the joke about Moose ?
=>>> > ('heard you talk about a Mr Moose; who was it ? )
=>>> Some american cartoon ... :-)
=>
=>Is there nothing more about it ?
=>
   The show in question is The Bullwinkle Show, featuring the adventures
of Rocky the Flying Squirrel and Bullwinkle Moose. The show was known
for its extensive use of puns.
   I think the similarity in tha names MOOSE and GNU may have something
to do with it as well.

=>>> >   That's a general method for protection, which is after all only a "vie
w" of
=>>> > sharing objects. To enhance this, you may add a key to names so an aggre
ssive
=>>> > program not be able to pirat you because you use common names.
=>>> That's what capabilities are.
=>
=>Uh ... what are you calling capabilities ?
=>
   Capabilities are a method for naming and protection. Holding a
capability for an object names the object and gives you specific
permissions to access it. Amoeba and OS/400 are examples of capability
based object systems.

=>>> An OO operating system does NOT mean (IMHO) that all the support for OO
=>>> langauges should be built into the OS (and certainly not into the kernel)
=>>> 
=>>> To me it means that the OS should provide some operations that make it eas
y
=>>> to implement persistant objects.
=>
=>What do you call "some operations", and "persistant objects". To me,
=>you have no OOed OS if every language is going to completely reimplement
=>their objects; you only have an OS with an annoying OOed interface (as
=>with the Mac for many aspects).

   It is not our job to provide standard objects to every existing and
future object-oriented language. We have to draw a line between the
system and the applications somewhere. Also, I see no need to impose a
class heirarchy on the system itself. We should create a space in which
independent objects can exist, operate, and interact via tightly
controlled interfaces. We can then integrate the interface into
languages as required. I don't agree that persistence is the primary
goal, but it is a good one.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From rideau@clipper Sat Mar  6 21:56:57 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13304; Sat, 6 Mar 93 21:56:56 +0100
Return-Path: <rideau@clipper>
Received-Date: Sat, 6 Mar 93 21:56:56 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20084; Sat, 6 Mar 93 12:40:56 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303062040.AA12971@clipper.ens.fr>
Subject: GEN,ORG far13
To: duzan@udel.edu (Gary D. Duzan)
Date: Sat, 6 Mar 93 21:40:50 MET
Cc: moose-programmers@sfu.ca
In-Reply-To:  <9303061643.aa05935@ra.cis.udel.edu>; from "Gary D. Duzan" at Mar 6, 93 11:43 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Hello, fellow moose-programmers !
(see, I've been prolific this week to catch up with my not answering for
two weeks)(but you weren't much chatty this week)

-- ORG - moose organization - part --
 I see that my message numbering isn't used.
Well, I know that it isn't pretty, and I don't like it myself;
but I think we should find a means to file messages by subject
and author, and then stick to it. The format should allow future
automatic treatment by a filing software which would record
messages by author, subject, keywords, votes, sub-problems,
then link messages to replies, question to answers, and
maintain (with a moderator's help, here) for each problem an
up-to-date sum of all that have said (and not cancelled/replace)
about that problem.
 In this message's subject, GEN stands for general principles,
that is moose philosophy and what we expect it to do (not how
it will; no details).

-- GEN - moose general principle - part --

In his message "OO ?" (6/3/93), Gary Duzan sez:

> [description of a spinlocks]
> [about the "moose" name]
> [about capabilities]
Thank you for your explanations.
Maybe someone should detail on capabilities and how they are
implemented, to compare with the dictionary point of view.

>>> An OO operating system does NOT mean (IMHO) that all the support for OO
>>> langauges should be built into the OS (and certainly not into the kernel)
>>> To me it means that the OS should provide some operations that make it easy
>>> to implement persistant objects.
>> What do you call "some operations", and "persistant objects". To me,
>> you have no OOed OS if every language is going to completely reimplement
>> their objects; you only have an OS with an annoying OOed interface (as
>> with the Mac for many aspects).
>  It is not our job to provide standard objects to every existing and
> future object-oriented language. We have to draw a line between the
> system and the applications somewhere. Also, I see no need to impose a
> class heirarchy on the system itself. We should create a space in which
> independent objects can exist, operate, and interact via tightly
> controlled interfaces. We can then integrate the interface into
> languages as required. I don't agree that persistence is the primary
> goal, but it is a good one.
 (Again, can you detail on object persistence then, as compared to
the generic object format I propose ?)
 I must explain my point of view, as I don't know if we disagree on a
(fundamental) choice, or if we just don't understand each other (or
worse: if both).

 To me, an OS is an interface between the programs (that is, nearer or
farther, the user) and the hardware, and for programs between each other.
 We see with previous systems that what wasn't proposed as a standard with
the basic system (as is delivered with the system package) could never
get properly dynamically exchanged; hardly can it be filed if there is an
international standard (example: pictures, more recently sound, in the
near future, animations). No high-level standard could be achieved as no
generic enough language was found to EFFICIENTLY replace all others (and
it most probably never exist), and a high-level standard cannot support
inter-platform data communication. So
 For example DOS don't manage anything;
 To show how embedding code and data IS useful, you can imagine how
horrible it is for an user to see that existing apps don't have ALL
the required features to treat his data, and that he only have choice
between rewriting his own app (which even if he can will take a great
amount of time and/or money, and won't even allow him to communicate
his data to others !), or manually maintaining references through a huge
database and not having the app do correctly the work expected and having
your data take much more place than needed and still be limited in
single entry size. Let me give you an example I know well before
I continue with general ideas.

 My mother and I currently ARE in this case with DOS,Unix and MacOS alike.
My mother works in vietnamese and in french. But if most french accents are
present in most character 128-256 ASCII extension (though not with a
standard coding and with conversion problems, unsolved when text is
embedded in a non all ASCII file), vietnamese characters aren't: if you
want a code for each letter-accent combinatin, that's 131 characters to
add to ASCII). Under all systems, vietnamese specific text processors exist.
Each includes commands the same as existing text-processors under the
same system; but it won't be able to use improvements of the orgininal
editor, and the author will have to maintain it manually (if he would);
moreover, you can't use the standard format together with the vienamese
format (as they are incompatible) so you must have two distinct programs
(and you may know that lemacs, for example is 16 MB) on your disk and/or
running in memory. That's properly ridiculous. Moreover, each software
has its own coding, so that you have to translate from one to the other
through external utilities (and no 'you change it in a window, and it is
updated in the other' stuff possible), when they exist, because the one
who designed his format wasn't aware of what the others did.
  Utilities under DOS allow to remap the ASCII set and the keyboard to use
vienamese; so you can use a standard DOS software with vienamese, provided
you don't use french at the same time (as my mother does), and provided
the software goes through standard calls from screen/keyboard IO, which
fewer and fewer software do, as DOS calls are slow, stupid, uncomplete,
bugged, etc. So in practice, those utilities aren't very useful. There
also are Unix vietnamese terminals, which is better, but their facilities
won't apply with standard 7 bit unix software, and you can't use french,
etc. Only the Mac is good at this and largely beats all the others, as you
can add your own fonts and keyboard settings; my mother now uses MS Word 5
(that is a STANDARD software) and with a vietnamese font, and can send it
to her colleagues, and use it in ANY C.A.P. program (whereas with a few
bugs to correct manually, which may or may not be corrected in another
version). (the same may exist under MS Losedows, but local keyboard
remapping may not be as good, and I couldn't find utilities to do
keyboard&font editing&installing as with the Mac).
 Of course, every software has its own format, and you can't always
find a translator from a format to another. Moreover, translation
becomes impossible when the text is embedded in a non ASCII only file
(say, my mother dbase file containing the (huge) list of her books in
english, french, and (what is most important) vietnamese, about VN).

 Well, every one doesn't have the same problem, and the vietnamese problem
can be (partly) solved with unicode. But there are many many similar
problems (for example mathematical and/or symbolic expressions and graphs).
And you can be sure there will always be a need for new data formats. So
if the system doesn't allow a standard generic interface for data AND
accompanying code, you will forever have to recompile your apps each
time you want to include a new data format, provided the app was built
to accept change (because IT had the OO system the OS failed to implement)
and you have the app's sources (not all are public) and someone was
patient enough to implement a patch for each application you use.
When the gap between end-user objects and system capabilities becomes too
large, there will just be another funny groups like moose who'll want to
rewrite the system again from top to bottom !
 That's no fun. Object embedding should NOT be let entirely to application
writers or we're not getting anywhere. Of course apps should be able to
use as they will local variables; of course they can publish new object
formats; but there should be a format-describing standard so that
automatic format translation (including real-time exchange with the 'same'
object being accessed in different formats in more than one window) is
easy with as few user work as possible (none is ok). Of course you can't
foresee everything; that's why the format itself must be extensible, and
flexible; it should not so much describe how raw data is organized (which
can be horrible; see a LZ compressed sequential access only file), but
how it can be accessed, and what properties it has (logical propeties,
scheduling limitations, quick or slow aspects); it should be generic
so that you can build general purpose apps (to stick to my example,
the database should be able not only to keep french/vietnamese data, but
also to sort it the french/vietnamese way, which is not a mere
lexicographical on the letter order, as yo take accent order after
letter order, and letter order not being harware coding number order,
as some letters have been deplaced above the 7 bit limit).
 You won't ever be able to dynamically manage data, and/or to manage
subdata otherwise, so that the system is unuseful. We're not building
a system JUST to implement a new trick we like; we're also building a
useful and easy system for the end-user, both computer-scientist or not.

 Moreover, I don't see what a NEW OS would bring but that. All the rest,
Unix that; and Unix is widely spread, and has good implementations on
any computer, including PC's (see linux), Mac's, Amiga's, etc. You just
want standard calls for threading, small files, your language and/or
a GUI ? Just write (yet another :-) library to do it and a server to
centralize calls from multiple end-users; don't bother rewriting all the
system. And most probably an existing extension of Unix does it; you
just have to find it on the net and recompile it. You don't find it
standard or extensible enough ? Haha ! Then now YOU ask for the standardness
and extensibility you previously refused when writing the system.

 Well, I hope moose is not going to correct only implementation problems
(that is just better implementing what was to slow/clumsy under previous
systems), but also and mostly conceptual problems (that is, what makes
other systems a nuisance to use, and what forces you to go round the system
instead of using it).

		     ,
		  Fare,
	200% time moose programmer,
	   computing day-dreamer.

P.S. I dont have time to re-rea all that, so excuse me if there are mistakes,
mistypes, omissions, etc. An added correction may come.

From fate@ccwf.cc.utexas.edu Sun Mar  7 14:21:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA05407; Sun, 7 Mar 93 14:21:33 +0100
Return-Path: <fate@ccwf.cc.utexas.edu>
Received-Date: Sun, 7 Mar 93 14:21:33 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from happy.cc.utexas.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07908; Sun, 7 Mar 93 05:19:15 -0800
Received: by happy.cc.utexas.edu (5.61/1.34/CCWF 1.21)
	id AA03120; Sun, 7 Mar 93 07:19:06 -0600
Date: Sun, 7 Mar 93 07:19:06 -0600
From: fate@ccwf.cc.utexas.edu (Murphy's Law)
Message-Id: <9303071319.AA03120@happy.cc.utexas.edu>
To: moose-programmers@sfu.ca
Subject: Just one little thing
Status: OR

(Excuse me if this doesn't get out, or gets Fubared along the way..)
 
On a different vein from what we have been discussing, but one that should
be considered is the format / use of executionable code.  While having
objects for them is just about a given, it remains the task of the 
kernel to load and execute programs, otherwise, the o/s will be about worthless
without "applications" 
 
So, a suggestion would be to implentate, FORCED public/private key authorization
of any application that would have a priority level over the lowest one.
While allowing for applications to be debugged / developed, but not allowing
viruses/worms/ other friendly things that chew away on your data.
 
As far as graphical/text interface goes, this seems that it should be 
related to the concept of a shell.. either a cmmmand.com equivalent, or a
"finder" equivalent.  to use examples from O/Ss that I suffer with.  This
would load a library into memory that would handle display calls.  If 
some features of the display library are necessary, ie, graphics, and the user
is running in text mode, there could be a loader program that would load up the 
library for graphics and remove it when no longered needed..  And those with
fast machines, or masochists, could enjoy the slow updating of a pixel base
interface.
 


From rideau@clipper Sun Mar  7 15:06:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06217; Sun, 7 Mar 93 15:06:33 +0100
Return-Path: <rideau@clipper>
Received-Date: Sun, 7 Mar 93 15:06:33 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08195; Sun, 7 Mar 93 06:04:24 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from galion.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06187; Sun, 7 Mar 93 15:04:15 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303071404.AA06187@clipper.ens.fr>
Subject: Re: Just one little thing
To: fate@ccwf.cc.utexas.edu (Murphy's Law)
Date: Sun, 7 Mar 93 15:04:15 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <9303071319.AA03120@happy.cc.utexas.edu>; from "Murphy's Law" at Mar 7, 93 7:19 am
X-Mailer: ELM [version 2.3 PL11]
Status: O

>> 
>> (Excuse me if this doesn't get out, or gets Fubared along the way..)
>>  
>> On a different vein from what we have been discussing, but one that should
>> be considered is the format / use of executionable code.  While having
>> objects for them is just about a given, it remains the task of the 
>> kernel to load and execute programs, otherwise, the o/s will be about worthless
>> without "applications" 
Yes, we do have to consider this; but tha's kernel considerations and we
didn't even agree on the OOness of the kernel.
 My opinion is that code descriptors allow any possible means to pass 
parameters (through a stack, through registers, through a global variable,
etc. The execution handler should translate parameters as they should be
for the called function to operate. Of course, we must define the our own
preferences for the moose coding. I suggest using registers for quick
operations, a stack (not inevitably ss:esp) for common other operations, or
even typed stacks for OO operations (that is, an integer stack, a fp stack,
a typed object stack, etc). We'll what's the more efficient while coding.
This should be totally implementation dependent.
 As for C/Pascal parameter poping or not, I propose we rather say that
a C function returns its parameters before its usual result.


>> So, a suggestion would be to implentate, FORCED public/private key
>> authorization
>> of any application that would have a priority level over the lowest one.
>> While allowing for applications to be debugged / developed, but not allowing
>> viruses/worms/ other friendly things that chew away on your data.
What we were converging to is a dictionary of accessible functions: every
objects has access to a version of the dictionary. A method can thus be
more or less private (there's no more two possible states, but an infinity
of them at touch !) depending on wha dictionaries  it appears in.

>> As far as graphical/text interface goes, this seems that it should be 
>> related to the concept of a shell.. either a cmmmand.com equivalent, or a
>> "finder" equivalent.  to use examples from O/Ss that I suffer with.  This
 We suffer so much with those that I'd prefer the relation between our shell
and those to be more than distant.
 To me, the interpreter should be more like an interpreter (with both
infix and postfix notations if possible) which would allow to directly
call the objects in the dictionary; of course, all the useful stuff will
have been put in the shell dictionary. This also allow to have a shell
both standard and extensible.

>> would load a library into memory that would handle display calls.  If 
>> some features of the display library are necessary, ie, graphics, and the user
>> is running in text mode, there could be a loader program that would load up the 
>> library for graphics and remove it when no longered needed..  And those with
>> fast machines, or masochists, could enjoy the slow updating of a pixel base
>> interface.
I think we agreed to have a the same time GUI and a TUI (that is windows in a
text screen) and shells running inside terminals. The text windows are useful
when you use a computer with an old low-resolution (eg CGA) screen, or a
text-only screen (ever have used a vt100 ?).

		   ,
		Fare

BTW, who am I replying to ?
who is using this pseudonym Murphys's Law, fate@* ?
(just btw)
(it was well done anyway)


From oin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon Mar  8 13:34:15 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06125; Mon, 8 Mar 93 13:34:14 +0100
Return-Path: <oin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 8 Mar 93 13:34:14 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06027; Mon, 8 Mar 93 04:30:16 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa29265; 8 Mar 93 7:23 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa01719; 8 Mar 93 12:23 GMT
Received: from sol.cis.udel.edu by oin.cis.udel.edu id aa10943;
          8 Mar 93 12:22 GMT
To: moose-programmers@sfu.ca
Subject: Re: Object Sharing via File System (djg3) 
In-Reply-To: Your message of "Mon, 08 Mar 93 00:58:09 EST."
             <2b9ae07a.davgar@davgar.UUCP> 
Date: Mon, 08 Mar 93 07:22:27 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303081222.aa10943@oin.cis.udel.edu>
Status: OR

=>A possible means of making data objects available to other processes:
=>
=>It is possible for
=>
=>   1) All processes to be objects.
=>
=>   2) Objects to be in the logical file system.
=>
=>   3) Objects themselves be asked what objects are below them in the
=>      file system.

   This is basically the idea of a naming service object as expressed
in my brief discussion of capabilities. I'd suggest picking up a copy
of the Amoeba papers; they have already dealt with all of this. You can
get the compressed PostScript files via anonymous FTP in
ftp.cs.vu.nl:amoeba/papers. They put more emphasis on the remote case,
which isn't as relevant to our project, but they generally have some
good ideas.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From fate@ccwf.cc.utexas.edu Mon Mar  8 18:33:09 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15233; Mon, 8 Mar 93 18:33:08 +0100
Return-Path: <fate@ccwf.cc.utexas.edu>
Received-Date: Mon, 8 Mar 93 18:33:08 +0100
Received: from foghorn.cc.utexas.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by foghorn.cc.utexas.edu (5.61/1.34/CCWF 1.21)
	id AA28362; Mon, 8 Mar 93 11:32:25 -0600
Date: Mon, 8 Mar 93 11:32:25 -0600
From: fate@ccwf.cc.utexas.edu (Murphy's Law)
Message-Id: <9303081732.AA28362@foghorn.cc.utexas.edu>
To: rideau@clipper
Subject: Re: Just one little thing
Cc: moose-programmers@sfu.ca
Status: OR

>Yes, we do have to consider this; but tha's kernel considerations and we
>didn't even agree on the OOness of the kernel.
> My opinion is that code descriptors allow any possible means to pass 
>parameters (through a stack, through registers, through a global variable,
>etc. The execution handler should translate parameters as they should be
>for the called function to operate. Of course, we must define the our own
>preferences for the moose coding. I suggest using registers for quick
 
Well, parameters are going to be a sticky (no pun on gooey intemnded) issue..  
 
Maybe have a kernel call to get paramenters, as opposed to the CP/Mish PSP idea.

>What we were converging to is a dictionary of accessible functions: every
>objects has access to a version of the dictionary. A method can thus be
>more or less private (there's no more two possible states, but an infinity
>of them at touch !) depending on wha dictionaries  it appears in.

My point was that before a method would be loaded, it could be checked 
for unauthrozied changes..
 
>text screen) and shells running inside terminals. The text windows are
>useful when you use a computer with an old low-resolution (eg CGA) screen,
>or a text-only screen (ever have used a vt100 ?).

I have a CGA, and I have used a VT52.  *shuuder*  I now do most of my
work on a monochrome 386SL-25 and use the cga for remote debugging.

>who is using this pseudonym Murphys's Law, fate@* ?
>(just btw)

I'm Erik..  I just used the pseudonym because i could... 


From ANDREASA@sofus.dhhalden.no Mon Mar  8 21:35:19 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19373; Mon, 8 Mar 93 21:35:18 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 8 Mar 93 21:35:18 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03946; Mon, 8 Mar 93 12:31:48 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <09791-9@fenris.dhhalden.no>; Mon, 8 Mar 1993 21:31:20 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930308212949.896; 08 Mar 93 21:31:20 -100
Message-Id: <MAILQUEUE-101.930308212947.352@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 8 Mar 93 21:29:47 +0100
Subject: arf2 Re:ORG,KER+ far12
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Hello Again, continuing my last message

> >> I feel however that this addressing should be centralised rather then be
> >> scattered among the various device drivers
> >> (1) It means less repeated work in the device drivers
> >> (2) It's simpler to keep track of and maintain.

I agree on both your points, and I could add another one,
(3) It gives a more "generic" interface when you want to add a function to it.

But I don't think it should be done this way anyway, beacuse it will be
a very sensitive colossus. A small error and all devices could go to hell.
I think it is easier for each device driver developer to maintain it's own
list/tree. You won't get any overhead when the device raises an event.
The devices will live their own life in a way.
If we have a centralized address server we'll have to do more code to get it
work. The list/tree would be larger thus increasing the time used to traverse
it.
Of course we should have a library for the device driver developer so he won't
have to build everything on his own.


> >> > MOOSE should be Pee O aRe Tee A Bee eL Ee. However, we all come to have 386
> >>
> >> I hate to say this but the AMiga isn't better -- the A600 and A1200 are based
>
> >> The good thing about Amigas is the operating system
>
> YES, and the copros (and the fact the OS runs perfectly with the copros)

I deleted most of your text here, becuse it is irrelevant. That is not what
Fare ment. It should be portable, but of course there must be some sort of
limit regarding what features the prosessor have, have not.
It wasn't important whether it was an Amiga or anything else. Looking forward
to launch moose on a NeXT:-).


> >> > >> > (13) Should we be providing threads? (I don't think so but am open to debate)
> >> > what are threads/tasks but little/large objects ? Why build such a distinction
>
> >> Threads share data space whereas tasks/processes don't.
> >> Tasks are objects.
> >> Threads would correspond to concurrent method activation within an object.
> >> Since the data is shared between the threads locking becomes important.
>
> Again, that seems a totally arbitrary distinction: you always share
> something with someone (or else, the process has NO interest); UI programs
> would like to share windowing memory with the main UI device; piped programs
> can happily run with a shared memory pipe, etc; there's no limit to sharing
> little or big objects. On the opposite, you'll never want to share
> everything (at least, you won't have the same stack and/or registers). So
> threads and tasks are no absolute concepts, but relative ones: if you share
> memory with another one, you're a thread to it, if not you're a task ! That
> becomes ridiculous. If unix created two words, it's because of a unix badly
> fixed misconception, not because of an improvement.

Then let us define the MOOSE thread. Someone feeling it is his mission in this
life? I'll start a thread about them, see my next message.



> >> > * about DOS FAT systems:
> >> > Some talk about reading/writing it. Of course, this is obvious on 386 based
> >> > computers. But DOS FAT is so @#$^#$%^& that no sensible people would willingly
> >> > use an OS with it as a main FS. Whatever FS is choosen to work on, this should
> >> > be included as a device driver, not in the Kernel.
> >> For the moment DOS compatibility is a definite plus.
> Yes, and in the future, OS/2, linux, * compatibility also; and an emulator
> would be even greater; but this has nothing to do with the Kernel, and DOS
> FAT shouldn't be our primary FS (which does not mean we cannot have a generic
> FS running inside DOS FAT system, as any other FS)

File systems.
Ok, a device can make any type of partitoning (?) he want, dos/mac/unix.
The reasons we make it dos compatible is because we run dos. What if we had
to redo the whole filesystem, the way we want to have it, before we start
coding on moose, for the reason we don't like it.
The point is not to be dos compatible, the point is _we_don't_have_to_build_
_something_new_before_we_start_the_real_work.
When moose is working more or less ok, we can/should change the file system.

> >> > * Could one explain a poor ignorant frenchman the joke about Moose ?
> >> > ('heard you talk about a Mr Moose; who was it ? )
> >> Some american cartoon ... :-)
>
> Is there nothing more about it ?
I see we europeans must stick together:-)


> >> >  In fact, I think the Kernel Set should be exactly the C/ASM coded methods for
> >> > handling low-level objects: tasks/thread/procedures (executable code in
> >> > general, including stack management, and exception handling), memory
> >> > allocation, object typing, virtual pointers and naming (including subnaming
> >> > and polymorphism, linking and unlinking object to the running system (imagine
> >> > the coding/decoding needed to load/save an object from the running session
> >> > from/to mass memory). Nothing more.
>
> >> Nothing MORE?!
> >> I do not think that object typing, polymorphism etc. belong in the kernel.
> >> Object typing should be done at compile time.
> >> If you want an interprative system that can be written but you shouldn't
> >> FORCE the system to do interpratation.

The most important thing is to keep the kernel as clean as possible.
Summing up what I think we agree in.
Kernel should contain:
1) MultiTasking, LL memory routines (both virtual and physical).
   Some kind of messaging for kernel events that affects the running tasks.
I'll come back to this in my next mail.

> If we are one day able to have a standard interchange format for data&code, it
> is compulsory to include it in base system (I'm not talking about the Kernel
> only, but also the set of standard devices available). If we are to quickly
> interchange code, we cannot afford compiling a HLL program each time; so a LLL
> is good; if the LLL CAN be interpreted (but is also aimed at compiling), it
> is all the better, as it saves great amount of time for HL routines.
> (that's infinitely more efficient than, say, a shell&awk script). I'm not
> trying to impose an interpretative only system. I'd hate that. But I'm
> also pretending that writing the interpreter before the compiler is easier,
> and we don't need lightning speed to first boot the system. When the system
> is stable, we can begin compiling everything.
Sounds like a good strategy.

> >> To summarise my comments:
> >> The main problem is that you are confusing language and OS issues.
>
> I don't think I'm CONFUSING them, but I sure am linking them.
> I'd like the others to bring their viewpoint upon this critical point.
> Support me, question me, criticize me, flame me; but please reply as
> Michael did.

We mustn't write a system that is only that, uninterfacable to anything else
but itself and we mustn't write a system where only one language is supported.
I think if we can have a low level of abstraction in device code, no one is
going to interface it through low level routines anyway - if not writeing
his whole own HL interface library :-).
I think that if we create many functions that does little, the compiler
vendor is more free to do what ever he wants with them and that is good,
but on the other way, it can be used in ways we didn't expected and hence
bad.
So, for some code - write very low level functions that the vendor has to
assemble to do something at all, and for other - provide a higher level of
abstraction.
One example. Memory management. Have three functions, AllocMem, FreeMem and
ReAllocMem that allocates "large" chunks (from 1kB to 4GB/0xffff large for
intel).
For keyboards, have a higher level of functions as GetKey, not the type of
function GetPointerToKeyboardBuffer.
Now if I totaly missed what you ment...sorry:-).

> >> * You should allow the use of non OO languages -- otherwise you don't have a
> >> generic OS -- you have an OO programming environment.
>
> I have the same answer, and I have spoken about that just before.
mOOse! Not saying we must OO everything, maybe we should call it mose?
There is something in the name that says OO SystEm.

> >> Note that objects come ABOVE the kernel.
>
> Above the KERNEL, I don't know. But IMO certainly not above the basic system
> (kernel+device) set.
Agreed, but if someone want to make an OO'ed device for their MucetyMuc
device.

> >> You don't want to have the kernel enforce complex semantical policies.
> >> By lifting up such things into the compiiers you gain in efficiency and more
> >> importantly in maintainability.
>
> By having (simple) semantical policies enforced you can at last have a
> transparent system where apps truely can communicate with each other
> (and not only merge results as most "advanced" current systems only do).
>
> >> Requiring the kernel to do polymorphic type checking and inheritance is like
> >> requiring an OS to run structured code ...
>
> Uh ?

We just write a data exchange device ABOVE the kernel that does all this,
I can't imagine even in my wildest dreams that the kernel is interested in
what the task would want to do, as long as it don't requires the kernel to do
it :-).

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From ANDREASA@sofus.dhhalden.no Mon Mar  8 22:06:40 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19878; Mon, 8 Mar 93 22:06:40 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 8 Mar 93 22:06:40 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06855; Mon, 8 Mar 93 13:03:16 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <10368-0@fenris.dhhalden.no>; Mon, 8 Mar 1993 22:03:09 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930308220251.352; 08 Mar 93 22:03:08 -100
Message-Id: <MAILQUEUE-101.930308220243.320@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 8 Mar 93 22:02:43 +0100
Subject: KER,THREAD arf 1 - Thread definition
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Actually I'm not the one that should start this thread (hahaha) but someone
must/should.

Thread definition:
A thread is a part of a task that can _act_ as a separate task in the meaning
of program execution, but is a method in a program and shares the program
data and code-space.
Meaning of program execution means that it has got its own entry in the task-
list.
The thread must contain abilities to lock and unlock data, and the code that
initializes the thread should be able to do so before the thread start its own
execution.

Add your point of view, and I'll try to compile something at the end of
the week.

Now flame on (anyway this is my comprehension of threads).

Why am I doing this...?

Arff

PS. Keep your messages small. I think we should rather send one message for
each thing we want to discuss. Hope you feel the same.
DS

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From winikoff@cs.mu.OZ.AU Tue Mar  9 06:05:56 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA05155; Tue, 9 Mar 93 06:05:54 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 9 Mar 93 06:05:54 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06140; Mon, 8 Mar 93 20:58:14 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA08010
	Tue, 9 Mar 1993 14:57:55 +1000 (from winikoff)
Message-Id: <9303090457.8010@mulga.cs.mu.OZ.AU>
Subject: PLEASE READ THIS ONE
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 9 Mar 93 14:57:54 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
Priority: Urgent
X-Mailer: ELM [version 2.3 PL0]
Status: OR


Hi people -- just replying to a number of mails.

We've been having a lot of argument recently about various details.

The reason, I think, is that we don't have a common conceptual image of
what the system should end up being.

Different people's proposals suggest different systems -- everything from 
an OO based application sharing layer sitting above a conventional hardware
abstractor through a small single user Unix to a distributed multi user 
system.

Can we drop detailed issues and talk about conceptual models for the moment?

I'd like everyone to stop and think about what type of system they'd invisage
MOOSE as -- how would you summarise it's ESSENCE?

Then try to explain your view to everyone else.

I think if we can compromise on a common view we'll be half way to desining
the system.
(Ok, third of the way. ... would you believe a quarter? :-)

I'd particularly like Dennis (who has been rather quiet lately) to try
and get across his conceptual model.

To start the ball rolling here's mine ... I would like to emphasize that
mine is a kinda vague defaulty thing -- I'm quite open to suggestions 
and other viewpoints ...

What I had in mind was a system where executable code is the standard
however you'd have kernel calls to send messages to other processes/objects

Internally an object is a piece of code with no constraints. 
It (the object) gets called from other objects.

We have more flexibility then (EG) MS-DOS since an object has multiple entry 
points as opposed to a single "run -- exit" sequence.

We provide inter-application communication by having standard object 
sementics -- much like device independant I/O allows us to write programs
that will work on both files, terminals, pipes etc.
Call this polymorphism if you will.

The fundumentals are
	* Multitasking (otherwise you can't have inter-application 
			communication)
	* mountable devices
	* Remote Object Invocation (or whatever you want to call it)

Michael

From winikoff@cs.mu.OZ.AU Tue Mar  9 06:07:10 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA05175; Tue, 9 Mar 93 06:07:08 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 9 Mar 93 06:07:08 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06270; Mon, 8 Mar 93 21:01:33 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA08099
	Tue, 9 Mar 1993 15:00:53 +1000 (from winikoff)
Message-Id: <9303090500.8099@mulga.cs.mu.OZ.AU>
Subject: Re: Processes and Communication
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 9 Mar 93 15:00:52 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303052212.AA15109@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 5, 93 11:12 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> >> I think not -- most (all?) new machines have MMUs and memory protection  is
> >> quite useful for a programmer.
> >> (It;s also ESSENTIAL for a secure multi user system)
> >> 
> >> Any comments from anyone else?
> (that's always the good'ole question: what is in spec's and what is in impl')

I'd like to think of it as a simplifying assumption -- it's fairly safe
to assume that machines will have MMUs, it (probly) simplifies some design
to do so - so why not?

> Nope, if you're sure the compiler put the required checks (not too many checks
> but just what is needed); that's why a compiled program must have been ensured
> by the local host before execution (which ultimately sums up to a popup menu
> to ask the user his opinion)

You're relying on compiler correctness.
Furthermore you're requiring all programs to do run time checking when for many
(most?) machines out there the checking can be done by hardware.
THis results in an unneccessary speed loss.


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Tue Mar  9 06:18:59 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06290; Tue, 9 Mar 93 06:18:58 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 9 Mar 93 06:18:58 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06705; Mon, 8 Mar 93 21:11:00 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA08910
	Tue, 9 Mar 1993 15:10:38 +1000 (from winikoff)
Message-Id: <9303090510.8910@mulga.cs.mu.OZ.AU>
Subject: Re: ORG,KER+ far12
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 9 Mar 93 15:10:38 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303060145.AA18855@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 6, 93 2:45 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> Here's my reply to Michael's reply.
> He flamed me; I somehow deserved it as I called for answers, even flames.
> I also must clarify (and sometimes change) my point of view to take into
> account his arguments.

Sorry, my appologies, as is usual in such things it was simply a case
of misunderstanding.

> What I wouldn't want us to copy is not only one or another of those OSes'
> flaws, but mostly their philosophy, which leads to what we already have. I
> think if you follow unix philosophy for example, you won't do better than
> a twenty year old still evolving product on the which many a group work.

Hmm, you're right.

>  I propose we have a vote on it (see end of the letter)

No. I think we should get everyone understanding you're proposal well.
I for one am still not certain exactly what you're saying.
Voting and having everyone follow the result when people don't understand 
the proposals is a bad move -- you'll have people like myself trying to 
use a design model they don't understand fully ...


From winikoff@cs.mu.OZ.AU Tue Mar  9 06:27:18 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06437; Tue, 9 Mar 93 06:27:17 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 9 Mar 93 06:27:17 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07066; Mon, 8 Mar 93 21:20:32 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA09498
	Tue, 9 Mar 1993 15:20:18 +1000 (from winikoff)
Message-Id: <9303090520.9498@mulga.cs.mu.OZ.AU>
Subject: Re: GEN,ORG far13
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 9 Mar 93 15:20:16 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303062040.AA12971@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 6, 93 9:40 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
>  To me, an OS is an interface between the programs (that is, nearer or
> farther, the user) and the hardware, and for programs between each other.
>  We see with previous systems that what wasn't proposed as a standard with
> the basic system (as is delivered with the system package) could never
> get properly dynamically exchanged; hardly can it be filed if there is an
> international standard (example: pictures, more recently sound, in the
> near future, animations). No high-level standard could be achieved as no
> generic enough language was found to EFFICIENTLY replace all others (and
> it most probably never exist), and a high-level standard cannot support
> inter-platform data communication. So
>  For example DOS don't manage anything;
>  To show how embedding code and data IS useful, you can imagine how
> horrible it is for an user to see that existing apps don't have ALL
> the required features to treat his data, and that he only have choice
> between rewriting his own app (which even if he can will take a great
> amount of time and/or money, and won't even allow him to communicate
> his data to others !), or manually maintaining references through a huge
> database and not having the app do correctly the work expected and having
> your data take much more place than needed and still be limited in
> single entry size. Let me give you an example I know well before
> I continue with general ideas.
> 
[stuff deleted]
> 
>  Well, every one doesn't have the same problem, and the vietnamese problem
> can be (partly) solved with unicode. But there are many many similar
> problems (for example mathematical and/or symbolic expressions and graphs).
> And you can be sure there will always be a need for new data formats. So
> if the system doesn't allow a standard generic interface for data AND
> accompanying code, you will forever have to recompile your apps each
> time you want to include a new data format, provided the app was built
> to accept change (because IT had the OO system the OS failed to implement)
> and you have the app's sources (not all are public) and someone was
> patient enough to implement a patch for each application you use.
> When the gap between end-user objects and system capabilities becomes too
> large, there will just be another funny groups like moose who'll want to
> rewrite the system again from top to bottom !
>  That's no fun. Object embedding should NOT be let entirely to application
> writers or we're not getting anywhere. Of course apps should be able to
> use as they will local variables; of course they can publish new object
> formats; but there should be a format-describing standard so that
> automatic format translation (including real-time exchange with the 'same'
> object being accessed in different formats in more than one window) is
> easy with as few user work as possible (none is ok). Of course you can't
> foresee everything; that's why the format itself must be extensible, and
> flexible; it should not so much describe how raw data is organized (which
> can be horrible; see a LZ compressed sequential access only file), but
> how it can be accessed, and what properties it has (logical propeties,
> scheduling limitations, quick or slow aspects); it should be generic
> so that you can build general purpose apps (to stick to my example,
> the database should be able not only to keep french/vietnamese data, but
> also to sort it the french/vietnamese way, which is not a mere
> lexicographical on the letter order, as yo take accent order after
> letter order, and letter order not being harware coding number order,
> as some letters have been deplaced above the 7 bit limit).
>  You won't ever be able to dynamically manage data, and/or to manage
> subdata otherwise, so that the system is unuseful. We're not building
> a system JUST to implement a new trick we like; we're also building a
> useful and easy system for the end-user, both computer-scientist or not.

This is analogous to device independance.
Consider a program that works on pictures.
You can't seriously expect it to do something useful with a sound file.

Bascically what I'm saying is that a typical program/application should
be polymorphic in the sense that it'll work on any data type that has
sufficiantly close sementic properties.

(Much like Unix programs work on files/terminal/pipe)

I agree that this is a good idea.

I think Amiga OS 3.0 has done something along these lines. Anyone have more 
details?


> 
>  Moreover, I don't see what a NEW OS would bring but that. All the rest,
> Unix that; and Unix is widely spread, and has good implementations on
> any computer, including PC's (see linux), Mac's, Amiga's, etc. You just
> want standard calls for threading, small files, your language and/or
> a GUI ? Just write (yet another :-) library to do it and a server to
> centralize calls from multiple end-users; don't bother rewriting all the
> system. And most probably an existing extension of Unix does it; you

Good point.

The conclusion of this is that we shouldn't bother writting the system
from the bottom up but build it based on some multitasking OS.

Any comments?

The impression I got from Dennis' original mail was that he didn't want to
do this since Unix'es tended to be big.


> just have to find it on the net and recompile it. You don't find it
> standard or extensible enough ? Haha ! Then now YOU ask for the standardness
> and extensibility you previously refused when writing the system.
> 
>  Well, I hope moose is not going to correct only implementation problems
> (that is just better implementing what was to slow/clumsy under previous
> systems), but also and mostly conceptual problems (that is, what makes
> other systems a nuisance to use, and what forces you to go round the system
> instead of using it).
> 
> 		     ,
> 		  Fare,
> 	200% time moose programmer,
> 	   computing day-dreamer.
> 
> P.S. I dont have time to re-rea all that, so excuse me if there are mistakes,
> mistypes, omissions, etc. An added correction may come.
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Tue Mar  9 06:40:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06615; Tue, 9 Mar 93 06:40:25 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 9 Mar 93 06:40:25 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07360; Mon, 8 Mar 93 21:30:32 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA10945
	Tue, 9 Mar 1993 15:29:34 +1000 (from winikoff)
Message-Id: <9303090529.10945@mulga.cs.mu.OZ.AU>
Subject: Re: arf2 Re:ORG,KER+ far12
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 9 Mar 93 15:29:33 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <MAILQUEUE-101.930308212947.352@sofus.dhhalden.no>; from "Andreas Arff" at Mar 8, 93 9:29 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> The most important thing is to keep the kernel as clean as possible.

Yes, I agree strongly -- simplicity is very important.

In the words of Ken Thompson -- "when in doubt use brute force"

> Summing up what I think we agree in.
> Kernel should contain:
> 1) MultiTasking, LL memory routines (both virtual and physical).
>    Some kind of messaging for kernel events that affects the running tasks.
> I'll come back to this in my next mail.
> 
> 
> > >> * You should allow the use of non OO languages -- otherwise you don't have a
> > >> generic OS -- you have an OO programming environment.
> >
> > I have the same answer, and I have spoken about that just before.
> mOOse! Not saying we must OO everything, maybe we should call it mose?
> There is something in the name that says OO SystEm.

Sure -- what I am arguing is that we should be free to write our objects 
in a non-OO language.

I think we've just got a problem with terminology ... what do you mean 
by an OO OS? :-)



--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From dmarer@td2cad.intel.com Tue Mar  9 19:01:56 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27756; Tue, 9 Mar 93 19:01:55 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Tue, 9 Mar 93 19:01:55 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.185.65.3] by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28115; Tue, 9 Mar 93 09:58:51 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 9 Mar 93 09:58:48 -0800
Received: by td2cad (5.57/10.0i); Tue, 9 Mar 93 10:02:26 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00226; Tue, 9 Mar 93 10:09:32 PDT
Date: Tue, 9 Mar 93 10:09:32 PDT
Message-Id: <9303091809.AA00226@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re: arf2 Re:ORG,KER+ far12
Status: OR

Hi - just a quick response...

> Sure -- what I am arguing is that we should be free to write our objects 
> in a non-OO language.

Not a problem.  Just look at what an object is, *really*...in C++ a pointer
to a data structure, and all of its calls are normal function calls with
a "hidden" parameter.  Right now I'm writing tons of software for work in
C with an object oriented style.  For example, consider the following:

anObject->function(a,b,c);	/* This is a non-virtual function */

When you look at the code generated, it translates to:

function(anObject,a,b,c);

(Kindof...in the case of multiple inheritance, things are a little more
sticky, as "anObject" must be translated to reference the proper VMT.)

Objects can be written in any language - COBOL or assembly if you like.
They're nothing more than data structures and functions with the details
or the "magic" of calling a function for an object removed from your
sight.  In a non-OO language you must face these details again.

Dennis

From dmarer@td2cad.intel.com Tue Mar  9 19:05:46 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27828; Tue, 9 Mar 93 19:05:45 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Tue, 9 Mar 93 19:05:45 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.185.65.3] by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28446; Tue, 9 Mar 93 10:01:49 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 9 Mar 93 09:48:13 -0800
Received: by td2cad (5.57/10.0i); Tue, 9 Mar 93 09:51:50 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00221; Tue, 9 Mar 93 09:58:55 PDT
Date: Tue, 9 Mar 93 09:58:55 PDT
Message-Id: <9303091758.AA00221@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re:  PLEASE READ THIS ONE
Status: OR

Hi Moosers,

> The reason, I think, is that we don't have a common conceptual image of
> what the system should end up being.
> 
> Different people's proposals suggest different systems -- everything from 
> an OO based application sharing layer sitting above a conventional hardware
> abstractor through a small single user Unix to a distributed multi user 
> system.
> 
> Can we drop detailed issues and talk about conceptual models for the moment?

But its much more fun to talk details... :-)

> I'd like everyone to stop and think about what type of system they'd invisage
> MOOSE as -- how would you summarise it's ESSENCE?
> 
> Then try to explain your view to everyone else.
>
> I'd particularly like Dennis (who has been rather quiet lately) to try
> and get across his conceptual model.

:-)  Yep, this is true.  Forgive the silence, I've got some rather stressful
situations upon me at the moment.  Still working, thinking, eating, and
breathing Moose, just not being very vocal.

Here's my ideas: (from the ground up)

I envision Moose as a flexible operating system.  The heart of it is the
kernel which takes care of all that stuff kernels are good at: memory and
device handling, task handling, and nothing more.  This is a pure interface
to the machine and it must support the concept of an object.  It will not
be all that much different than other kernels except in the way it handles
the objects...

The kernel needs to understand what I call modules and libraries.  These are
identical in definition to Unix modules and libraries: a module contains a
collection of related functions, data, and objects.  What is different about
Moose modules is the interface.  All "external" functions, data, and objects
are included in the interface in exact detail - this includes data types and
sizes of all function parameters, heirarchy of objects, and so on.  The
private objects not included in the interface are not directly accessible,
but everything in the interface is described in enough detail such that
load-time or run-time linking to a module is possible.

A library is just a collection of modules...nothing special there. :-)
Maybe an entire library is loaded into memory at once with all references
between modules predetermined, or maybe modules are loaded one at a time
and dependencies cause other modules to be loaded.  I don't know - maybe
this is something which should fall under the next category...

The most important library in our system will be the system library.  This
will include functions and objects to make the system useful.  For example,
a semaphore object might be included here.  Objects to perform IPC would
also be found here, not in the kernel.  Disk drive object prototypes,
file system object prototypes, keyboard object implementation, mouse
object prototypes, memory management objects, and on and on and on.  Not
all of this has to be done using objects, but why not?  ;-)  This library
defines the operating system, the kernel is there only to support it.

(Some of the above were listed as prototypes, where we would define only
 "pure" objects with no implementation.  I don't want XXX video device
  driver in the operating system library even if there's a good chance
  I'd use it.  Each video device could be implemented as an object in
  its own library as a descendant of the pure video object.)

On top of the operating system, most definitely, absolutely, positively
*not* within the operating system, exists things such as the user
interface.  Be default, the operating system includes *no* interface!
Most of us will want one though :-] and I'd prefer to see both text and
graphics.

>> Ideally, I'd like to see a well enough designed interface such that
   a program written for a GUI using buttons, scroll bars, windows, and
   other GUI concepts could be run without modification and without
   recompiling under a windowing Text User Interface (TUI).  As long
   as the GUI version does not use the primitive graphics functions
   this is entirely possible.

Overall, I envision a system which is logical and uncomplicated to use.
The interface to every layer of software is *simple* and *flexible*,
not requiring (in the case of, for example, X Windows) seven or eight
books open on my desk at all times to write software with.  Seriously!
(I do write X software, and I do have this many books to reference...)

I believe this should be the software designer's operating system not
the end-user's operating system.  Windows is *great* as far as the
end-user is concerned, and O/2 2.1 is *even better*.  Really!  But,
have you ever tried to write a Windows Application?  From my point of
view, it's not a good programmers interface.  The user interface is
simple to duplicate and well defined enough that we ought to be
more concerned with the software interface, which affects issues in
software development such as development time and frustration.

Have I said enough?  I could go on for a while yet...

Hope this has gotten my ideas across - I'll try to be more active
in discussion now, but I think Michael has gotten an important point
across which I think we were missing.  The concept is important,
the details are the easy part...

Dennis











From buster.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed Mar 10 00:53:58 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06330; Wed, 10 Mar 93 00:53:57 +0100
Return-Path: <buster.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 10 Mar 93 00:53:57 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA29035; Tue, 9 Mar 93 15:50:19 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa05305; 9 Mar 93 18:48 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa26676; 9 Mar 93 23:44 GMT
Received: from sol.cis.udel.edu by buster.cis.udel.edu id aa13093;
          9 Mar 93 23:41 GMT
To: moose-programmers@sfu.ca
Subject: Re: Processes and Communication (2) 
In-Reply-To: Your message of "Tue, 09 Mar 93 15:01:47 EST."
             <9303090501.8132@mulga.cs.mu.OZ.AU> 
Date: Tue, 09 Mar 93 18:41:40 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303092341.aa13093@buster.cis.udel.edu>
Status: OR

=>> 
=>> 
=>>    The more functionality we move to objects, the more flexible the
=>> system becomes. Actually, it is theoretically possible to have a
=>> system with no kernel at all (given proper hardware protection
=>> mechanisms.) In such a system, everything is just a piece of code.
=>> That would be the ultimate in system flexibility. Of course, since
=>> it is a terribly radical idea, a lot of people (including many on
=>> this list :-) won't care for it. I can live with that. :-)
=>
=>Please expound -- this could be interesting and possibly worth doing ...
=>
   I'm mainly thinking about something like the system described in the
paper "A Micro Kernel Architecture for Next Generation Processors",
presented in Proceedings of the USENIX Workshop on Micro-Kernels and
Other Kernel Architectures, and "Coordination Languages and their
Significance", presented in Communications of the ACM, February 1992
(Volume 35, Number 2.) In case you haven't read these articles (which
is likely, I suppose, given the audience (no offense intended -- I'm
just an OS research weenie)) I'll ramble a bit again.
   Imagine a system that automatically changes the protection level
when the code enters a particular code area. Each protected block of
code would provide a special block of memory containing jump
operations. This block would allow other code to execute it, and
executing it causes a protection switch, so when the CPU hits the jump
target, the processor will be executing with a new set of rights.
Hence, communication would be via normal function calls. Even if this
communication mechanism isn't used, any secure communication method
between entities with different protection levels would suffice for a
complete system. One entity could have memory allocation rights, while
another might have access to a particular device, while others may
provide high-level services. Accessing these resources is simply a
matter of communicating with the entities that provide them.
   Please keep the flames down to simmer; this is all hypothetical/
theoretical stuff, and won't necessarily apply to MOOSE. However,
there may be some ideas we can use in there somewhere.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From buster.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed Mar 10 02:26:46 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08086; Wed, 10 Mar 93 02:26:34 +0100
Return-Path: <buster.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 10 Mar 93 02:26:34 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05513; Tue, 9 Mar 93 17:22:36 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa09495; 9 Mar 93 20:20 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa27398; 10 Mar 93 1:16 GMT
Received: from sol.cis.udel.edu by buster.cis.udel.edu id aa13659;
          10 Mar 93 1:15 GMT
To: moose-programmers@sfu.ca
Subject: Re: Processes and Communication (2) 
In-Reply-To: Your message of "Tue, 09 Mar 93 16:48:58 PDT."
             <9303100048.AA00400@tdge15.intel.com> 
Date: Tue, 09 Mar 93 20:14:56 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303100115.aa13659@buster.cis.udel.edu>
Status: OR

=>Hi!
=>
=>>    Imagine a system that automatically changes the protection level
=>> when the code enters a particular code area. Each protected block of
=>> code would provide a special block of memory containing jump
=>> operations. This block would allow other code to execute it, and
=>> executing it causes a protection switch, so when the CPU hits the jump
=>> target, the processor will be executing with a new set of rights.
=>
=>For anyone who has familiarity with the 386, you know how incredibly
=>easy this is to accomplish!  [ et cetera ... ]

   Actually, my first reference (from the USENIX Workshop Proceedings)
mentions that their initial implementation would use the segment
mechanism in the 386. (Eventually they plan to use a flat 64-bit
address space with a special MMU.)

=>>    Please keep the flames down to simmer; this is all hypothetical/
=>> theoretical stuff, and won't necessarily apply to MOOSE. However,
=>> there may be some ideas we can use in there somewhere.
=>
=>I can't think of any other way to accomplish what we need to do without
=>some sort of mechanism like this.  It's completely transparent to the
=>programmer and even to the compiler.  I like it!

   For those systems that can't support this mechanism, we could put a
virtual procedure call (a VPC, for those who don't like the name RPC
:-) in the path. We could even tack the rights portion of a capability
to the VPC if we wanted to do so. Regardless, we will want some sort of
abstract interface to hide the details.
   If you have access to a technical library, I'd suggest looking up
the articles I mentioned earlier. Together, they suggest the
possibility of the next generation kernelless operating system, which I
see as a significant step (though time will tell in which direction.)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Wed Mar 10 03:28:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08948; Wed, 10 Mar 93 03:28:51 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Wed, 10 Mar 93 03:28:51 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08286; Tue, 9 Mar 93 18:17:40 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA13109
	Wed, 10 Mar 1993 12:17:25 +1000 (from winikoff)
Message-Id: <9303100217.13109@mulga.cs.mu.OZ.AU>
Subject: Re:  PLEASE READ THIS ONE
To: moose-programmers@sfu.ca (Moose Project)
Date: Wed, 10 Mar 93 12:17:23 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303091758.AA00221@tdge15.intel.com>; from "Dennis Marer" at Mar 9, 93 9:58 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> Hi Moosers,
> > Can we drop detailed issues and talk about conceptual models for the moment?
> 
> But its much more fun to talk details... :-)

But not as productive ... :-)

> > I'd particularly like Dennis (who has been rather quiet lately) to try
> > and get across his conceptual model.
> 
> :-)  Yep, this is true.  Forgive the silence, I've got some rather stressful
> situations upon me at the moment.  Still working, thinking, eating, and
> breathing Moose, just not being very vocal.
> 
> Here's my ideas: (from the ground up)
> 
> I envision Moose as a flexible operating system.  The heart of it is the
> kernel which takes care of all that stuff kernels are good at: memory and
> device handling, task handling, and nothing more.  This is a pure interface
> to the machine and it must support the concept of an object.  It will not

How exactly? What does supporting the concept of an object mean at this level?

> be all that much different than other kernels except in the way it handles
> the objects...
> 
> The kernel needs to understand what I call modules and libraries.  These are
> identical in definition to Unix modules and libraries: a module contains a
> collection of related functions, data, and objects.  What is different about
> Moose modules is the interface.  All "external" functions, data, and objects
> are included in the interface in exact detail - this includes data types and
> sizes of all function parameters, heirarchy of objects, and so on.  The
> private objects not included in the interface are not directly accessible,
> but everything in the interface is described in enough detail such that
> load-time or run-time linking to a module is possible.

Why do we need to have all the types declared?
The argument here is that an application using a library has to be aware
of the semantics of the object it's using anyway -- if someone wants to
use a different library it'll have to have the same semantics anyway.

(The Amiga's libraries are just collections of functions. The data types
they take and the number of arguments (and which registers to pass them in)
is documented in manuals. 
Usage looks a little like: [Psuedo code]

baseptr_for_somelibrray = open_library("somelibrary.library")
librarycall(arg1, arg2)
/* Typically the C compiler recognises library calls and patches them to use
** the libraryptr and makes use of the right registers.
** One would have to use various data types that are defined in include files
*/

BTW, I'm just raising a point -- in practice you really need the includes
(and to be programming in a C like language) to do things easily ...

[Disclaimer -- I'm not really an Amiga programmer -- yet ...]


> 
> A library is just a collection of modules...nothing special there. :-)
> Maybe an entire library is loaded into memory at once with all references
> between modules predetermined, or maybe modules are loaded one at a time
> and dependencies cause other modules to be loaded.  I don't know - maybe
> this is something which should fall under the next category...
> 
> The most important library in our system will be the system library.  This
> will include functions and objects to make the system useful.  For example,
> a semaphore object might be included here.  Objects to perform IPC would
> also be found here, not in the kernel.  Disk drive object prototypes,
> file system object prototypes, keyboard object implementation, mouse
> object prototypes, memory management objects, and on and on and on.  Not
> all of this has to be done using objects, but why not?  ;-)  This library
> defines the operating system, the kernel is there only to support it.

Yes. I'd argue though for splitting this up.
Have a separate library for (eg.) semaphores , disk, memory management
etc.

> 
> (Some of the above were listed as prototypes, where we would define only
>  "pure" objects with no implementation.  I don't want XXX video device
>   driver in the operating system library even if there's a good chance
>   I'd use it.  Each video device could be implemented as an object in
>   its own library as a descendant of the pure video object.)
> 
> On top of the operating system, most definitely, absolutely, positively
> *not* within the operating system, exists things such as the user
> interface.  Be default, the operating system includes *no* interface!
> Most of us will want one though :-] and I'd prefer to see both text and
> graphics.
> 
> >> Ideally, I'd like to see a well enough designed interface such that
>    a program written for a GUI using buttons, scroll bars, windows, and
>    other GUI concepts could be run without modification and without
>    recompiling under a windowing Text User Interface (TUI).  As long
>    as the GUI version does not use the primitive graphics functions
>    this is entirely possible.
> 
> Overall, I envision a system which is logical and uncomplicated to use.
> The interface to every layer of software is *simple* and *flexible*,
> not requiring (in the case of, for example, X Windows) seven or eight
> books open on my desk at all times to write software with.  Seriously!
> (I do write X software, and I do have this many books to reference...)

Yes -- I agree with this goal .. let's do it! 

> 
> I believe this should be the software designer's operating system not
> the end-user's operating system.  Windows is *great* as far as the
> end-user is concerned, and O/2 2.1 is *even better*.  Really!  But,
> have you ever tried to write a Windows Application?  From my point of
> view, it's not a good programmers interface.  The user interface is
> simple to duplicate and well defined enough that we ought to be
> more concerned with the software interface, which affects issues in
> software development such as development time and frustration.
> 
> Have I said enough?  I could go on for a while yet...
> 
> Hope this has gotten my ideas across - I'll try to be more active
> in discussion now, but I think Michael has gotten an important point
> across which I think we were missing.  The concept is important,
> the details are the easy part...

Once you have the concepts that is ... :-)


The part that I find is still unclear is the role of "objects" in the system.
The rest is a fairly conventional OS -- I'm not saying this is bad, if it 
designed properly (ie. to be simple) it can (and will) be exactly what we want
-- something that's a pleasure to write applics under.

Most of the problems we've had have been with the role of objects.


> 
> Dennis
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From buster.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed Mar 10 13:40:59 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00661; Wed, 10 Mar 93 13:40:58 +0100
Return-Path: <buster.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 10 Mar 93 13:40:58 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25173; Wed, 10 Mar 93 04:37:44 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa10984; 10 Mar 93 7:31 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa05533;
          10 Mar 93 12:26 GMT
Received: from sol.cis.udel.edu by buster.cis.udel.edu id aa17241;
          10 Mar 93 12:24 GMT
To: moose-programmers@sfu.ca
Subject: Re: Processes and Communication (2) 
In-Reply-To: Your message of "Wed, 10 Mar 93 12:32:02 EST."
             <9303100232.14002@mulga.cs.mu.OZ.AU> 
Date: Wed, 10 Mar 93 07:24:16 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303101224.aa17241@buster.cis.udel.edu>
Status: OR

=>What is the advantage of having no kernel as opposed to a micro-kernel?
=>Sounds as if someone said "micro-kernels are better then typical bloated
=>kernels hence having no kernel must be better still" :-)

   Well, you'd have to agree that it is a radical idea, and there will
always be young upstarts like myself that will jump at anything that
goes against the establishment. :-) I think the basic idea it that if
you can build a system that is quick and efficient without a kernel,
then you'll end up with a more flexible system if you get rid of it.
It also logically separates the different parts of the kernel
(scheduler, memory manager, communications, etc.) into manageble and
easily replaceable chunks, just like microkernels do for higher-level
services.  However, keep in mind that it isn't even unanimously agreed
upon that microkernels are the way to go, much less non-kernels.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Wed Mar 10 14:02:10 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01320; Wed, 10 Mar 93 14:02:09 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 10 Mar 93 14:02:09 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25398; Wed, 10 Mar 93 04:57:22 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA08732; Wed, 10 Mar 93 13:57:16 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA07216; Wed, 10 Mar 93 13:57:15 +0100
Date: Wed, 10 Mar 93 13:57:15 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303101257.AA07216@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Processes and Communication (2)
Status: OR

 
> =>What is the advantage of having no kernel as opposed to a micro-kernel?
> =>Sounds as if someone said "micro-kernels are better then typical bloated
> =>kernels hence having no kernel must be better still" :-)
> 
>    Well, you'd have to agree that it is a radical idea, and there will
> always be young upstarts like myself that will jump at anything that
> goes against the establishment. :-) I think the basic idea it that if
> you can build a system that is quick and efficient without a kernel,
> then you'll end up with a more flexible system if you get rid of it.
> It also logically separates the different parts of the kernel
> (scheduler, memory manager, communications, etc.) into manageble and
> easily replaceable chunks, just like microkernels do for higher-level
> services.  However, keep in mind that it isn't even unanimously agreed
> upon that microkernels are the way to go, much less non-kernels.
> 

The microkernel came up, when OS researchers ask, what to do *not* into
the OS's kernel. They declare the kernel to be "small", thus micro, in comparison
with older OS's such as UNIX. (But: If you have a look into Mach kernel, which
is declared as a microkernel, you will shake your head. I've heard of 30000 lines of 
code (no comments). Is this really micro?) Well, actually there's a trend from
monolithic to microkernel based systems.

In distributed OS there's a real reason to provide a very small (nano-) kernel.
As there are many nodes which must run at least the kernel a big and heavy one
isn't useful. Too much overhead (especially on those multiprocessor systems). The
system must be highly flexible and the kernel small. (In PEACE the kernel is about
3000 lines of code big. And that's all, which must run on a node! All other 
things are added only when they're needed. The authors say: The kernel must provide
process execution and fast IPC. That's all. No scheduling, no memory management,
no protection. ... and it works.)

In our project, the microkernel will provide a very dynamic OS in terms like,
adaptability, scalability and others. It will give us the possibility to create
an OS as needed.

>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 
> 
> 
> 

From UKCC.UKY.EDU!WKUVX1.BITNET!haydedr Wed Mar 10 16:50:23 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06286; Wed, 10 Mar 93 16:50:22 +0100
Return-Path: <UKCC.UKY.EDU!WKUVX1.BITNET!haydedr>
Received-Date: Wed, 10 Mar 93 16:50:22 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ukcc.uky.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28289; Wed, 10 Mar 93 07:26:49 -0800
Received: from UKCC.UKY.EDU by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 8848; Wed, 10 Mar 93 10:26:06 EST
Received: from WKUVX1.BITNET (NJE origin MXMAILER@WKUVX1) by UKCC.UKY.EDU
 (LMail V1.1d/1.7f) with BSMTP id 5541; Wed, 10 Mar 1993 10:15:56 -0500
Received: by WKUVX1.BITNET (MX V3.2) id 10632; Wed, 10 Mar 1993 09:18:03 CST
Date: Wed, 10 Mar 1993 09:18:01 CST
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: moose-programmers@sfu.ca
Message-Id: <009694AD.5CB7C980.10632@WKUVX1.BITNET>
Subject: Re: Processes and Communication (2)
Status: OR

Hello all!

Three days ago I just got over a 2 week long case of the flu, and I
have been _swamped_ with makeup work.  Sorry I haven't been
participating much.  I promised a workup of a memory management scheme
I've been working on.  I'll get it out very soon ;-)

"Gary D. Duzan" <duzan@udel.edu> writes:

>   I'm mainly thinking about something like the system described in the
>paper "A Micro Kernel Architecture for Next Generation Processors",
>presented in Proceedings of the USENIX Workshop on Micro-Kernels and
>Other Kernel Architectures, and "Coordination Languages and their
>Significance", presented in Communications of the ACM, February 1992
>(Volume 35, Number 2.) In case you haven't read these articles (which
>is likely, I suppose, given the audience (no offense intended -- I'm
>just an OS research weenie)) I'll ramble a bit again.

Gary,

Do you know where I can get a hold of that USENIX paper?  That sounds
very interesting.

>   Imagine a system that automatically changes the protection level
>when the code enters a particular code area. Each protected block of
>code would provide a special block of memory containing jump
>operations. This block would allow other code to execute it, and
>executing it causes a protection switch, so when the CPU hits the jump
>target, the processor will be executing with a new set of rights.
>Hence, communication would be via normal function calls. Even if this
>communication mechanism isn't used, any secure communication method
>between entities with different protection levels would suffice for a
>complete system. One entity could have memory allocation rights, while
>another might have access to a particular device, while others may
>provide high-level services. Accessing these resources is simply a
>matter of communicating with the entities that provide them.

This can easily be implemented on the 386, if we decide to use that
feature.  Does anyone know if the Motorola chips can do this as well?
I have a very good book, published by Intel, called "80386 System
Software Writer's Guide," that explains this concept.  Perhaps it's
time to give ol Motorola lit a call.

>   Please keep the flames down to simmer; this is all hypothetical/
>theoretical stuff, and won't necessarily apply to MOOSE. However,
>there may be some ideas we can use in there somewhere.
>
>                                        Gary Duzan
>                                        Time  Lord
>                                    Third Regeneration
>                         Humble Practitioner of the Computer Arts
>

AS soon as I get past all these makeup assignments (and spring break!)
I plan to start participating much more.

Thanks,
Ross

From ANDREASA@sofus.dhhalden.no Wed Jan 27 20:03:13 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09236; Wed, 27 Jan 93 20:03:12 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 27 Jan 93 20:03:12 +0100
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <25037-0@fenris.dhhalden.no>; Wed, 27 Jan 1993 20:03:03 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930127200247.448; 27 Jan 93 20:03:02 -100
Message-Id: <MAILQUEUE-101.930127200236.416@sofus.dhhalden.no>
To: rideau@clipper (Francois-Rene Rideau)
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 27 Jan 93 20:02:36 +0100
Subject: Re: MOOSE
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> (To Andreas & Gunnar)
> Hello happy MOOSE programmers !

Oh well, who are you. We are not into this. You must have mistaken us for
beeing somebody else. MOOSE? I've never heard of such a thing, and beeing
mailed by a frog, what could be worse - get your waisted bandwith out of here!
Just kidding :-) (Hope you don't offend ;-)

I'm Andreas.
Good to hear from you! I sincerly wish I could speak french, but I don't :-(.


>  I'm Fare' (rideau@clipper.ens.fr) and I participate to this new OS project.
> Firstly, I'd like to say hello ! Then, as I work in the kernel and am studying
> the possibility of writing a new language, I'd like to know what is and/or
> would be your usage of new language and kernel capabilities; for example
> don't you find annoying rewriting many times different versions of the same
> algorithm each time you just want to change a little parameter, or else, see
> your program run too slow if you produce generic code ?

What I'd like most of all is C++. A fast one. Most of the low level functions
will be written in asm. anyway.

>  Well, could you send we what you are working on; I know many people who like
> graphics programming, and one who have built a whole windowing interface in
> TP6.0; perhaps one of them would be happy to share your work (if you agree).

Why not. The biggest problem at the moment is; how do you set gfx-mode.
There are about 50(!) registers that you must change, I have come up with a
new angle on how to solve it, that I'm going to test out. If any of your
friends has got code to do this, I would scream of joy and happines.

If your friends are interrested to join us, make them conntact me, but I
don't want 20 mails saying I once used Borland's graphics library, rather one
saying he is an expert in S-VGA.
Preferrably he should have some experience in programming GUI (as windows,
os2, Mac.).
To the last I mayby should say, I'm not an ace programming gfx, but having
programmed windows for almost two years, I'm ready to do something with it,
and it may cost me effort, and lower grades, but I will learn a lot of things
and I can say - I have tried something to get rid of Windows, the worst GUI,
and programming environment ever made. Sold by large advertisments.


Tell me a little about you. I'm a little bit short on time at the moment,
would wish there were 40hour days.
>  Whatever, good luck to both of you, and greetings from France !
>                                                    ,
>                                                 Fare
> P.S.: and a happy new (chinese) year !


 Mail you tomorrow, from "the Man who lives among the polarbears".

 Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--


From ANDREASA@sofus.dhhalden.no Thu Jan 28 08:53:18 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00861; Thu, 28 Jan 93 08:53:17 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Thu, 28 Jan 93 08:53:17 +0100
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <06863-0@fenris.dhhalden.no>; Thu, 28 Jan 1993 08:53:10 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930128085256.352; 28 Jan 93 08:53:09 -100
Message-Id: <MAILQUEUE-101.930128085247.320@sofus.dhhalden.no>
To: rideau@clipper (Francois-Rene Rideau)
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 28 Jan 93 08:52:47 +0100
Subject: Re: MOOSE
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Good morning Francois

> >> >  Well, could you send we what you are working on; I know many people who like
> >> > graphics programming, and one who have built a whole windowing interface in
> >> > TP6.0; perhaps one of them would be happy to share your work (if you agree).
>
> >> Why not. The biggest problem at the moment is; how do you set gfx-mode.
> >> There are about 50(!) registers that you must change, I have come up with a
> >> new angle on how to solve it, that I'm going to test out. If any of your
> >> friends has got code to do this, I would scream of joy and happines.
> (can you
> >> If your friends are interrested to join us, make them conntact me, but I
> >> don't want 20 mails saying I once used Borland's graphics library, rather one
> >> saying he is an expert in S-VGA.
>  Well, I have more than one friend working on SVGA, but they can't agree with
> each other as they don't have the same card. The only one who can work on any
> machine is the one who exploits standard VGA compatible modes (by the way, is
> there a 512x368 or such mode on VGA or SVGA ?)

Then both of your friends are welcome. The problem with plain VGA is the
number of colors, and the resolution; They are not good enough, so I figured
that the best way of getting colors and resolution would be to use S-VGA. Now,
each S-VGA card differs from the others in some way. E.g. none of them
does the same thing the same way. So if they have different cards, that is
better. We have to make some sort of a screen driver for the different
cards. The reason why Dennis wants to build MOOSE was, he had found out that
no existing OS took full advantage from his i386 machine. The reason why I
want to do the same is having programmed in Windows for 2 years is enough,
it must be possible to come up with a better way of doing things, and to use
the capabilities of a modern gfx-cards - without to much effort.

> >> Preferrably he should have some experience in programming GUI (as windows,
> >> os2, Mac.).
> (It's not the same friend who specialized in GUI)
Creating a whole windowing system is a large project, and he must be quite
a good programmer, doing it on his own. I'm interrested in what he could do
for us. One of my first letters from Dennis this year (not the chinese one:-)
was saying - Andreas, to many people show interrest, without wanting to do
anything, getting a free ride. We must scale down.
We are two people working on the display part at the moment. Therefore I'm
a little bit careful saying "come to me everybody and we'll do it together".
One day you'll stand there with somebody not doing his part :-(.

> >> Tell me a little about you.
>  I'm working at developping a high-level language together with the kernel
> which will implement its feature.
>  Main high-level features are:
> - The language is meta-itself; looks like the macro part of macro assembler,
> but has the same syntax as the language.
> - The language is as generic as possible.
> - This includes logical inheritance (not only physical one, as in C++), typed
> templates (and more generally, parametered objects, including classes, with
> expansion at compile possible).
> - syntax lightened by polymorphism and contextual implicit parameters.
>
> (about C++, are you using the Borland C++-- stuff, or a true C++ with
> templates, exceptions, etc).
No, Borland.

> The problem with my friends is none of them has mail capability. Ask them
> help through my address.

I would like to get more information about your friends working with s-vga,
what cards they use etc. I'm also interested in what card you use.
And your friend with the windowing system.

"the Man who lives among the polarbears".
     Arff

PS. What's your full name? Francois-Rene Rideau or Fare'?
DS.


sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--


From ANDREASA@sofus.dhhalden.no Wed Feb 10 19:28:36 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24552; Wed, 10 Feb 93 19:28:34 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 10 Feb 93 19:28:34 +0100
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <18165-0@fenris.dhhalden.no>; Wed, 10 Feb 1993 19:22:29 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930210192202.352; 10 Feb 93 19:22:18 -100
Message-Id: <MAILQUEUE-101.930210192156.288@sofus.dhhalden.no>
To: dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com,
        haydedr@wkuvx1.bitnet, mckeeveb@sfu.ca, newlin@ecn.purdue.edu,
        danodom@matt.ksu.ksu.edu, winikoff@cs.mu.oz.au,
        mueller@sc.ZIB-Berlin.DE, rideau@clipper
From: ANDREASA@dhhalden.no
Organization: Ostfold College
Date: 10 Feb 93 19:21:56 +0100
Subject: My thoughts about revision 0.0
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

B. Resource requirements
As for the vague estimate on hardware, concerning the harddisk. Preferably
under 5 MB for the basic system. Now saying only 25% for a minimum hardware.

Utilization of S-VGA. Most people have S-VGA, so there will seldom be
necessary to buy extra hardware. Few programs utilize svga because of the
actual lack of a hardware standard, but that shouldn't be a major problem. Not
yet anyway...

C. Platform Issues

I must say I don't know very much about the 680x0 series, but I like the idea.
As you probably now, there will be no 68050, instead Motorola is going to
launch their 68060 as their replacement for 68040. My question now. How large
differences will there be in the processor architecture, concerning the
succesor and the already existing ones. Not because it has very much with the
issue as such, but it might come to have.
What do you now, and how could it affect our work?

Then Dennis mentions the Mac. Is it possible to replace the MacOS. Isn't it a
rom based OS?

D. Design Principles
When it comes to design principles. I see the point Fare' comes with, but
if you take a look at the Protection Hierarchy you could see that it won't
make any larger difference what language is used. For us, as programers of
kernel parts, device drivers etc. we need the flexibilty of C++, beacuse of
the fact that it is close to the hardware. If we enforce the rule;
"No tasks at the 'user' level (see part E. of Introduction) can manipulate
hardware directly. The only way a program in the 'user' level can access
hardware is through objects in the lower Privilege Levels"
I'm using Privilege Levels (PL) the same way as the Intel literature does,
with lower meaning the layer below.
Then it won't matter what language you use, because no one will be able to
use the hardware directly, without makeing their own device first, and devices
are public.
Do you get my point???

E. Protection Hierarchy
Why not four PL levels? I agree with the one you suggested, but on the other
hand, I prefer having higher priority for devices needed for the OS function-
ality, than equal for normal extra device drivers, and OS device drivers.
That would make things harder to change at will, in a released product.
And others won't be able to do it.

Section III
2. Semaphores
You must have a way of identifying the resource you are going to use the
semaphore on. A resource Handel (ugghh, I hate them :-), a filename, etc.

3. Timers
There must be two timers. One that measures the time the task use, and
one that measures the total real world time.
In some programs you might want to know how long time the program needed for
task, and if you measures the elapsed time, you must subtract the time that
went to other tasks and to the kernel.
Then you have the other situation, where you want to measure time as the
quantity the user have to live with :-)

That's about it. Some ideas, suggestions, enhancements and questions.

Have a nice day.

Arff

BTW. I liked 'Midgard' too, if you want I can post a .wav file with the
correct pronuncation (?) to you :-), I live there, you know....:-)
Greatings from the land where polar bears walks on the streets...

sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--


From winikoff@cs.mu.OZ.AU Mon Feb 22 00:22:53 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15594; Mon, 22 Feb 93 00:22:51 +0100
Received-Date: Mon, 22 Feb 93 00:22:51 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12607; Sun, 21 Feb 93 15:18:01 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA29041
	Mon, 22 Feb 1993 10:17:06 +1100 (from winikoff)
Message-Id: <9302212317.29041@mulga.cs.mu.OZ.AU>
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA25159
	Wed, 17 Feb 1993 17:00:43 +1100 (from Postmaster)
Date: Wed, 17 Feb 1993 17:00:43 +1100
From: Mail Delivery Subsystem <Postmaster@cs.mu.OZ.AU>
Subject: Returned mail: Service unavailable
Return-Path: <Postmaster@cs.mu.OZ.AU>
To: winikoff@cs.mu.OZ.AU
Status: OR

   ----- Transcript of session follows -----
While talking to whistler.sfu.ca:
>>> RCPT To:<moose-programmers@sfu.ca>
<<< 554 :include:up... Cannot open up: No such file or directory
554 moose-programmers@sfu.ca... Service unavailable

------- Received message follows ----

Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA25157
	Wed, 17 Feb 1993 17:00:43 +1100 (from winikoff)
Return-Path: <winikoff>
Subject: Re: MOOSE - comments (REPOST)
To: moose-programmers@sfu.ca (Moose Project)
Date: Wed, 17 Feb 93 17:00:42 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]

I mailed this a while back and haven't seen it or responses to it.
Just in case it wasn't forwarded to everyone I'm remailing it now.

This is comments on the original draft and a few following mails.

Michael

- ----------------------------------------------
> 
> 
> Comments on design and comments so far
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Sorry I've been a little slow to react -- here are my thoughts.
> Some ideas are at the end -- if you're not interested in wading through the
> comments please skip to the end and read the ideas.
> 
> I haven't set up an alias yet -- could you please forward this to everyone.
> 
> Thanks
> Michael
> Aka, Merlin, Lord of Chaos, Prince of Amber.
> 	Computer Designer and creator of Ghostwheel. :-)
> 
> ----------------------------------
> 
> >  The two most important features designed into the Moose
> > operating system will be simplicity and flexibility.  For one, a
> 
> Simplicity and flexibility are not features they are design guidelines.
> The way to have them in a system is to have them guide all the other design
> decisions we make.
> 
> ----------------------------------
> 
> > C. User Input Devices
> > 
> >      With the standard user input devices, it would be ideal to
> > allow keyboards, mouses, and ...
> 
> Please - Mice. Not Mouses. :-)
> 
> ----------------------------------
> 
> ** Could you please explain how object inheritance is done at the OS level?
> In particular how it is done SAFELY?
> 
> ----------------------------------
> 
> Regards writing the kernel in assembler -- we can break the kernel up into
> machine dependent and machine independent parts and write only the former in
> assembler.
> 
> I think the less assembler we use the better.
> 
> ----------------------------------
> 
> Giving device drivers their own priority -- good.
> 
> 
> ----------------------------------
> 
> As our resident time lord has pointed out there is very little on processes 
> and IPC.
> 
> 
> ----------------------------------
> 
> >  Most tasks will never need to call these functions explicitly
> > as a certain amount of memory will be allocated to each upon
> > initialization, depending on the compiler used.  This larger block
> > of memory should then be broken up by the task into smaller,
> 
> No. It's simpler to have the compiler insert code which at runtime calls
> AllocateMemory and uses it's own data structures to subdivide it.
> Automatic allocation of memory isn't needed at all let alone in the kernel.
> 
> Bear in mind that users should never use system calls -- the compile should
> provide (eg.) malloc and implement it reasonably.
> Doing that using the system calls is the problem of the compile writer.
> 
> ----------------------------------
> 
> > most restricted "user" level.  All memory allocated will be
> > accessible only by the requesting task and its parent or children
> > tasks, allowing no other tasks access to this memory.
> 
> No. I don't like allowing other tasks access to memory by default.
> I'd rather that the default was no access and that shared memory was explicitly
> requested.
> 
> My two reasons are
> (1) Robustness -- by allowing a whole hierarchy to read/write a process' memory
> 	it becomes possible for one of these processes doing something wrong and
>  	crashing the entire hierarchy.
> (2) Security. 
> 
> ----------------------------------
> 
> I like the MEM_PHYSICAL flag.
> 
> ----------------------------------
> 
> > There will be a limit on the total number of memory allocations
> > made by a single task and in the system as a whole, so efforts
> > should be made by applications to consolidate memory usage.
> 
> This is policy rather then mechanism.
> I think it is better to say "there will be a mechanism by which processes can
> have a limit set on the amount of memory they may allocate"
> 
> ----------------------------------
> 
> > 'size' parameter.  To simplify and expedite memory management, only
> > large chunks of memory will be allocated at one time, usually
> > varying between 1k and 8k in size, depending on the host platform.
> 
> This is a implementation decision. I feel that we should either
> (1) Make a fixed decision across all platforms
> Or preferably
> (2) Design the system in such a way that the size of memory allocation does
> not make a difference to the user.
> 
> ----------------------------------
> 
> 
> >      The starting address of the memory block will be returned by
> > this function.  If the allocation fails a null address is returned,
> > indicated by an address of zero.
> 
> Firstly there is scope for a bug here -- consider what happens if the system
> allocates a task memory beginning at (virtual) memory location 0 ...
> 
> Secondly and more importantly we need a system wide standard facility for
> communicating back error types and causes -- In order to have sensible 
> error reporting we need to return some kind of error code.
> 
> ----------------------------------
> 
> Is realloc necessary? Can someone come up with a situation where it is 
> essential or even important?
> 
> ----------------------------------
> 
> > E. System Clock and Event Scheduling
> > 
> > >> How should this be done?
> 
> Have a device to handle this. 
> The advantages of doing things in devices are
> 	(1) The kernel is smaller and simpler
> 	(2) We can change our mind later and write a different device and
> 		easily add it to the system.
> 
> ----------------------------------
> 
> > F. Interrupt Handling
> > 
> > >> How should this be done?
> 
> I favor a simple interrupt routine that "converts" an interrupt to a message.
> Of course some interrupts WILL need to be handled by an interrupt routine but
> in general they should be converted into messages.
> I feel that this will simplify the writing of device drivers.
> 
> ----------------------------------
> 
> Objects:
> I like the approach of simply defining a standard format.
> 
> ----------------------------------
> 
> Files:
> 	Actually persistent objects subsume files.
> 	(Simply have an object with one of it's attributes being an array of
> 		bytes and methods including "read" and "write")
> [More about this later]
> 
> ----------------------------------
> 
> > from its sleep and may enter its critical section.
> > 
> > 	semaphore@Down()
> > 
> 
> Why the "@" in semaphore@Down ?
> 
> 
> ----------------------------------
> 
> Nothing is said about how semaphores are created/destroyed.
> More seriously nothing is said about how semaphores end up being shared
> between two tasks.
> 
> Should we have spinlocks too?
> 
> ----------------------------------
> 
> Timers: These seem to be quite complicated.
> I feel that timers can be put into a device rather then being in the kernel.
> 
> One possible (simpler) interface:
> 
> 	eventid = schedule(time,event)
> 	status  = remove(eventid)
> 	eventid = schedulerelative(time_delta, event)
> 	time    = gettime()
> 
> In order to simulate timers have a process that does a gettime when it receives
> a message.
> 
> In order to simulate periodic events have the the receiver of the message 
> reschedule itself.
> 
> I'm not certain whether we need facilities to determine how much time a process
> has consumed.
> If we do it will have to be in the kernel since it involves the process 
> scheduler.
> 
> ----------------------------------
> 
> > B. Display Output Devices
> > 
> >     A proper definition of the state of the display output devices
> > would be an object-oriented GUI similar to X11, only much easier
> > to use. :-)
> 
> NO!!!!
> The user interface is a USER program for flexibility.
> The display should offer graphics primitives.
> (Eg. line, text, blit ...)
> 
> ----------------------------------
> 
> User input:
> 	It is useful to be able to insert input filters -- processes through
> 	which input events pass before being sent to their destination.
> (Uses: Screen savers, macro recorders, shortcuts ...)
> 
> ----------------------------------
> 
> File systems:
> 	One issue that hasn't been raised is crash recovery.
> 	I suggest people have a look at Amoeba's file system -- they store
> 	files contiguously sacrificing disk space for speed.
> 
> ----------------------------------
> 
> Libraries:
> 	I'm sorry. I didn't understand this too well.
> 	Can you please explain them. 
> 	IN particular I'm uncertain as to the difference between objects and 
> 		libraries -- libraries seem to be just typed objects which
> 		sounds like what you were trying to avoid in ...
> 
> >      Strictly speaking, the operating system will define nothing
> > more than a standard format for storing a class and a methodology
> > for accessing its attributes and methods in a meaningful way.  No
> > enforcement of these policies will actually be done to allow for
> > maximum flexibility and efficiency.  If objects are not implemented
> > correctly by an application or device driver, the loss will be only
> 
> 
> 
> ----------------------------------
> ----------------------------------
> 
> That concludes my comments on the initial spec.
> 
> I've got a few comments on the various comments that other people have made
> so far.
> 
> Also I'd like to throw a few ideas after that.
> 
> 
> ----------------------------------
> 
> Gary Duzan
> ~~~~~~~~~~
> 
> I think we SHOULD provide a CLI (Command Line Interface) -- their very useful
> when porting Unix based software.
> 
> >   So what language do we write the high-level stuff in? Should it
> > matter? Can we make it not matter?
> 
> 
> We MUST make it not matter. An OS that only supports one language isn't going
> to be useful.
> 
> 
> ----------------------------------
> 
> Fare'
> ~~~~~
> 
> Agree. The system should be written in a HLL. C has had an influence on Unix etc
> 
> > To conclude, I think we mustn't rush doing what would be the kernel of a
> > system whose features aren't defined yet. Let's define the high-level object
> > orientation of the system before we write the kernel (more precisely, let's
> > not write something in the kernel we should have to change completely because
> > it will not fit high-level system requirements).
> 
> 
> I disagree - I feel that the kernel should be designed first with the
> applications in mind.
> Lets face it -- this is a chicken and egg problem: The kernel and the
> applications (including device drivers) depend on each other's design.
> The solution is to start with the kernel (which doesn't actually use the device
> drivers and so can be designed without knowing the precise interface) and then
> designing the device drivers. This process is then iterated to a fixpoint.
> 
> 
> ----------------------------------
> 
> Regards the Mac OS being in ROM - we can simply let it boot and THEN take over.
> 
> 
> ----------------------------------
> 
> Some ideas and suggestions -- PLEASE READ THIS BIT
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> (1) What audience are we aiming this OS at?
> 	My original understanding was standalone PCs but then you mentioned
> 	various network drivers.
> 	Do we plan to support (Eg.) diskless workstations?
> 
> (2) We need to have a configuration facility to make installation of new 
> 	software/devices/hardware totally painless.
> 	This of course, will not be in the kernel however I thought it
> 	worth mentioning.
> 	We should set things up so that either
> 	(1) An application doesn't need to know what it's running on
> 	(2) An application can easily find out what services the system provides
> 	
> 	This is particularly important since an application may find that
> 	certain device drivers have not been mounted.
> 
> (3) (I've mentioned this b4) We need a facility for returning error codes
> 	when a system call fails.
> 
> (4) Objects, Files, address spaces and all that jazz ...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Persistent objects subsume both processes and files.
> Getting rid of the concept of the files is (IMHO) a strong forward step.
> 
> One idea which may simplify swapping is to use a single address space across
> all objects -- possibly even the one corresponding to where they are stored
> on disk.
> 
> Of course most of the address space will be inaccessible ...
> 
> The main advantage of this scheme is that it makes shared memory simpler to 
> program with -- otherwise pointers have to be avoided since the addresses
> will differ from process to process.
> 
> [But see arenas later]
> 
> (5) Objects must be first class -- we MUST be able to store objects in variables	, pass 'em to functions etc.
> 	The implementation will of course use pointers. This might be a good
> 	place to start thinking about capabilities.
> 
> (6) Security: It hasn't been mentioned yet.
> 	Do we want it?
> 	To what degree?
> 
> (7) I/O redirection:
> 	Idea: Have the following convention: when an object is started it 
> 	is given by it's creator the objects representing stdin stdout etc.
> 	(It may be more appropriate to think of screen, kbd etc.)
> 	This lets us easily do I/O redirection -- simply have the shell
> 	substitute say, a file for the keyboard or a printer for the screen etc.
> 
> 	[Note: The list of initial objects could perhaps include ALL objects 
> 	used (Eg. file system) for maximum flexibility -- this would then also
> 	let us run a program in an isolated environment ... good defence against
> 	trojan horses]
> 
> (8) Microkernel:
> 	Seems to be the way we're heading. Good.
> 	
> 	* Efficient IPC is important
> 	* Possible interface:
> 		send	-- sends a message to an object
> 		receive	-- returns the next object. Pauses caller if none
> 				available.
> 		call	-- Like a send but does a context switch to the receiver
> 			for extra speed 
> 		spawn (or create_object) 
> 		kill	-- destroys an object, freeing it's resources
> 		self	-- returns the id of the caller. One use is "kill(self)"
> 				instead of a special exit call.
> 		alloc	-- AllocateMemory
> 		free	-- FreeMemory
> 
> The main missing calls in the interface are process communication and 
> synchronisation.
> 
> 
> (9) Process communication and synchronisation -- a proposal
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 		
> Process communication requires an efficient means of passing large 
> amounts of information between processes.
> 
> The one commonly used is shared memory -- the problem is that pointers don't
> work.
> 
> I would like to suggest a variation which I'd like to call "arenas"
> The idea is that the arena is like shared memory except that when created 
> it is specified to which virtual memory addresses the arena should be bound.
> 
> Any process that attaches to the arena has it mapped to the same virtual memory
> addresses so pointers can be safely used as long as they remain pointing within
> the arena.
> 
> Regards synchronisation -- semaphores are a fairly common primitive.
> Rather then having objects we can simply have operations "up" and "down" that
> take a pointer to an integer.
> 
> By convention the first 4 bytes of an arena can be used as a semaphore for
> mutual exclusive access to the arena. This is only a convention and is not 
> enforced anywhere.
> 
> Comments?
> 
> 
> (10) Do we support distributed applications? How?
> 
> (11) Where is non-deterministic behavior expressed and how?
> 
> (12) Do we support some notion of "signal" -- ie. pre-empting messages?
> 	Should we? (I don't know)
> 
> (13) Should we be providing threads? (I don't think so but am open to debate)
> 
> 
> Last but not least ... the name MOOSE.
> 
> I like it. It's MEMORABLE.
> 
> Can people please tell me why they don't like the name?
> [Or if they do like it please speak up!]
> 
> 
> --------------------------------------------------------------------------------
> Michael Winikoff
> winikoff@cs.mu.oz.au
> Computer science honours. University of Melbourne, Australia.
> 

------- Received message ends    ----


From rideau Tue Feb 23 05:58:09 1993
Subject: Re: This is a test of the Moose broadcasting system...
To: dmarer@td2cad.intel.com (Dennis Marer)
Date: Tue, 23 Feb 93 5:58:09 MET
In-Reply-To: <9302200011.AA01857@tdge15.intel.com>; from "Dennis Marer" at Feb 19, 93 4:11 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

ASAP !
(and sorry for the delay)
 By the way, I think you didn't receive my last mail to the group, for I
did not add your name in my mailing alias ('twas before the mailing list)
(the alias was taken from one of your letter's header). If you did, don't mind
this message. I send you last version here (not including my next posting
to the mailing list); use gnu diff to know what's new since last version you
received.

 Read you soon,
   ,
Fare

--- here, included last version of my specs ---
Hello, Dennis & the Moosers !
 Here are my wishes for the new OS.
 You'll see that I think the OS and the language stuff are interlinked. IMHO,
you can't conceive one without conveiving the other.

 As I speak french and am not completely fluent at english, I will commit many
mistakes. Do not hesitate to correct my english, it will help me improve it,
and you won't have to translate ill-written and difficult-to understand
english as you read my letters.
 As I study math, I don't really care for how you NAME things (though I have
some opinions about what would fit the best and not recall unwanted things).
Just tell me if you name something otherwise from me, or let's have some
discussion.

 I do not ask to forget C/C++, but to use them with another spirit (more
generic and more multithreading/parallel), in expectation of a quick
replacement.

 A wish is preceded by ***, subwishes by *, arguments for them follow,
begun by --> (tell me if you use another format, to harmonize transfer)

 I think we'd better divide our specs following the subject and/or logical
layer of the objects discussed.

 This file isn't finished yet, but I send it anyway.

/************************* General structure  *******************************/

*** ANYTHING is LOGICAL, virtual.
*** there is a UNIFYING notion for ANYTHING, even EXECUTABLE CODE, even
ITSELF. call it CLASS, OBJECT, FUNCTION, SCHEME, TYPE, FUCK or any name you
like, call it GOD if you want, but there it is: it exists, it just EXISTS !

*** a STANDARD NEW STACK LANGUAGE is given, both as handy do-anything language
to exchange and manipulate data between windows, as scripts for common
utilities, and as standard intermediate language for compilers.
-->Why a STANDARD language ?
 A standard intermediate code for compilers allows to have common front part
for a compiler in any specific language independently of hardware; it allows
to have the same terminal part of the compiler for different languages. This
was a dream in the time of early compilers; it is a nightmare with C.
-->Why a NEW language
 At this time we have C/C++ but it isn't a good language as it doesn't give
the compiler enough info to do both code optimization and protection checking
or program proof.
 All this will help VERY much further compiler designers (if the language is
well designed).
--> Why a STACK language ?
a stack language is easy/immediate to interpret, and/or transform back to
tree for further optimization. It is easy to obtain as compile object code,
and easy to use as compile source code (if you add powerful enough
declaration stuff to just FORTH).

* If you have a good language interpreter, no more need for a stupid shell
which does not do anything and systematically calls external files ! No more
need to know the different syntaxes of all the different utilities.


/**************************** Logical stuff *********************************/

****** ANYTHING is primarily LOGICAL, then PHYSICAL
* Actually, there are many layers of logical links between objects,
but at the opposite of today's OS and non OO enough languages, the primary
layer is the LOGICAL one, NOT the PHYSICAL one. When you conceive something,
you begin to think about how it will link to others; it is up to the language
and the system below to

*** I PROPOSE WE ACTUALLY BEGIN PROGRAMMING FROM THE UPPER, LOGICAL BOUND:
Let's have our system work within another old one (DOS/Unix).
 We can still begin programming from the other, hardware bound, and the
two programming will join in the middle, but LET'S NOT BEGIN HARDWARE
PROGRAMMING BEFORE LOGICAL CONCEPTION.

*** <std_example.h> you can have a file as a text string and vice versa, so
that anything you programmed for a file can be used with a string.
 To begin with, Let's just translate DOS/Unix files to logical low-level
files.
*** <std_example.h> once a physical support has been defined
files on it are automatically and IMPLICITELY defined when needed, for any
file storing standard (with defaults depending on the physical support).
Then, you can read an Apple ][ DOS 3.3 file in a MS-DOS .DSK file if you
just have defined it once, and use it as a standard file in any common
application program.

*** More generally, every logical structure or algorithm in Knuth's
"the Art of Computer Programming" will be included in standard files.

*** some structures can be cast to others:
sequences to array, array to sequence, list to record, record to list,
list to set, set to list, etc.
 The system will know all these standard logical casts, and will execute them
itself if/when needed. He will choose itself (considering the info given by
the user) what format to use for the data, if you translate once and work with
the translated data, or if you translate calls to the object's method as they
come (depends on which takes more memory or time, and how much time or memory
you have to do the job,...).
 Many a physical format do match with a logical structure, but each operation
on it then takes different times to execute, that's why
*** SCHEDULING IS INCLUDED IN THE SYSTEM, AND THUS IN THE LANGUAGE.
(or vice-versa)

*** Files are only a representation among others of logical objects. You can
reference an object in a file as any other object. The system will know if
it has to expand part of the file or the whole file to real memory.

*** The system contains a huge number of more or less interlinked objects.
Each has a separate life, but can live only as long as (more or less directly)
linked to an object known to live (the running system, mass memory).

/********************** Standard objects in the Kernel *********************/

TASKS,THREADS,PROCEDURES
*** A program byte has not only one char input and one char output (and
possibly one error char output). It may have any number of implicit or
explicit input or output (with many defaults if not entirely told by the user)
of any nature (not only raw char streams ...).


/*************************** Physical implementation ***********************/

*** We must include (before the end of the project, but obviously not at the
beginning) every possible physical format of each logical structure previously
defined.

MEMORY ALLOCATION
*** This include in particular MEMORY ALLOCATION.
There is a logical class called OBJECT ZONE, which will have different
implementation. an OBJECT ZONE can contain others, and so on. Each program
will have its own choosen to be the quickest and/or the less memory user.
For a first time let's define only one OZ type, which won't be appropriate
for any particular use, but which will do anything you can expect from an
OZ, from bare allocation to garbage collection with pointer updating when
full.
* Let's also define sub-OZ which contains only part objects of the OZ.

CLASS SYSTEM
*** Let's define the Class class, its axioms and its constructors.
*** Logical Basic Classes and Constructors
THEOREMS
- Arbitrary precision integer number (staticly typed)
- n-modulus integer (staticly typed)
- Arbitrary precision real number (staticly typed)
- Enumerated types (staticly typed)
CONSTRUCTORS
- Record
- List
- case-union
- Array
- Reference (no arithmetic)
- Explicit Virtual Function: (a function without border effect)
OTHER STANDARD LOGICAL CONSTRUCTORS
- Record,Lists,Arrays with carry report
- Set
- Arbitrary precision integer number (dynamically fixed)
- Arbitrary precision real number (dynamically fixed)
- Strings (=character lists=low-level text files)
- Queues, Deques, Stacks, etc.
SYSTEM CLASSES
- Object
- Class
- Container
 - Object Zone (logical container)
 - Memory System (physical container)

*** Physical Basic Classes and constructors (on the PC)
AXIOMS
- boolean
- local int types (depends on the implementation)
- character type
- local real number types
CONSTRUCTORS
- Array
- record
- union
- physical_pointer

/************************ SHELL / USER INTERFACE ****************************/

*** Let's have a STACK Language shell: it is then easy to combine results
from previous operations, then treat them.
 I remember when I changed from Apple ][ to MS-DOS, I was first VERY depressed
because I couln't do small calculation at the DOS prompt, neither could I
use files and run programs in BASICA, whereas in Applesoft, I could use the
full file system, and even call Assembler.
 Now I have some tools in my PC for VERY simple calculations, or VERY
complicated ones, but I must still use my 10 TIPS (thousands instructions per
second) HP48 for calculations rather than not my 3 MIPS computer for
quick immediate calculation involving some memory and/or handy computing.
What a shame for MS-LOS !
 With Unix, this problem is less present, because with X-Window you can copy
calculations from a window to another, so that you can build programs which
all do a very little thing, and pipe one into another and cut/paste in
between. The problems are: it only understands ASCII, and moreover ASCII codes
from 32 to 126 only (others are non-standard) ! You swap the whole system and
launch a full task for just stupid calculations. THAT eats computer time.
* But you can still have Unix-like commands: when the interpreter sees an
instruction, if first asks it if it wants to parse the rest of the line !
* The MacIntosh's cut/paste is only a push/pop with a 1 level deep stack !

*** In a standard program, you can DYNAMICALLY change any of the inputs ore
outputs. For example, first put a wait input/output which just waits when
called. Then, the user replaces it by whatever he wants. To verify how the
program behaves, (to debug, to ensure that a long task you launch isn't
unuseful, etc), just put between the input of a program and the output of
another that is linked a intermediate edit/wait/view program that allows you
to see and modify if you want the data flow.

*** of course, we will have a graphical interface at the end; but the
graphical interface is only a means among other to use the stack language
interface: instead of a mere cut/paste, you push/pop from a stack to another;
even more generally, you transfer data from a queue/file/stack/variable to
another; each having a read and a write procedure.

*** keyboard can be shared between more than one user: allows sharing the
terminal. Useful for games, useful when many people share the same computer,
etc. (idem as for screen, with multiple windows). More generally, input and
output devices can be shared. You can have someone using the main keyboard
but function keys and the keypad; another one with the keypad, a third one
with function keys (if they are on the side of the keyboard), others with
respectively the mouse and joysticks. Of course, you can also have more than
one keyboard and/or screen.


/******************************** TOOLS *************************************/

SUBSYSTEMS:
*** (in a distant future) you will just be able to open any other logical
system in a window: PC-DOS, Unix, MacOS, Apple ][ ProDOS, CP/M 80, *OS* will
be supported.
 Programming the sub-OS in the intermediate stack language will allow to port
them to any computer; we will (only) need a good microprocessor emulator
(which will be the execute method of the specific microprocessor class,
inherited by the generic executable code class).
*** But the MOST IMPORTANT OS to emulate is itself: the Kernel must be such
that an OS session can contain another one. That's fun for debugging as well
as simulating itself in a game, or anything; moreover, it's ideal for multiple
sessions in one and multitasking (let the system just contain many times
itself and you're done).

COMPRESSION:
*** The standard objects will include compression algorithm, and the
programmer will be able to transparently compress/put in overlay, etc, parts
of his programs/data, following the algorithm he thinks best fit (for example,
a big random access help file can be coded this way: first, group words and
assign a code for frequently used words. Huffmanize remaining characters.
Huffmanize words. Lempel-Ziv one-block texts and compare. Allow skipping an
unefficient previous step).

/**************************** Little tricks *****************************/

* Directories are a logical structure.
Then a compressed and/or tar'ed file can be a directory (better to use
read-only, but writeable if you wish). This is VERY useful when a directory
must contain a lot of libraries, or a great number of small files (imagine a
program with 1000 modules each a two screen page ascii source file; if you
allocate 1 2Kb disk block/file, it is 2Mb; if you put all the
stuff in a single file, it is but 1Mb; if you compress each file with an
algorithm appropriate for its type (language used) and/or LZ, it will be
300Ko, and quickly readable; moreover, disk access and/or swapping is
limited.


/*************************** Actual Programming *****************************/

* We don't need do all physical representation of every logical structure
now or include scheduling either. Let's just keep a place for it when we have
time, so that we won't have to do it all again then.
* for the moment, let's just do something that works, even VERY slowly, and
with very limited physical format. Let's not even choose optimized format for
our implementation, just have it work and be short to write and easy to modify
later.

** How to manage Multithreading in an unadapted language as C/C++.
let's call regularly the multi-threading manager in our C++ code (do not let
a large loop without a call), with a #define'd word.
(for example PAUSE).
** Further, we can have a translator from C++ to our better language.


/*************************** Hardware interface ****************************/

Here for the 386 version.
*** Will we use flat model or multiple segment model ?
(we can mix models)

--> FOR the FLAT model
 Everything is easier with pointers: they are shorter, pointer arithmetic
is easy and fast.
--> AGAINST the FLAT model
 No memory protection for inter objects exchange

* As I recommend huge use of tiny object, you can't use FLAT model everywhere,
i.e. you can't mix objects which are not SURE of each other, not having been
compiled together. It's impossible to manage it with the FLAT model, except if
you require page alignment for objects which must interfere (that's worse than
previous paragraph alignment !!!). That's why I recommend using the other
model. (but simple programs can still work in FLAT model).

* We can also have the STACK LANGUAGE interpreter run in the FLAT mode, as
we may insure ourselves that compiled programs are correct with respect of
object protection; or have the version of the interpreter check itself if
the instructions are correct.

* Then what of the GDT and the LDT ?
I thought about it and arrived to the conclusion that each Task has its own
GDT, and each Thread its own LDT, or something like that. A common object may
involve one or two threads, and a huge object, but most tiny objects will only
use the current thread's environment.
 The problem is that when a object calls another one, BOTH want to be sure thee
call is correct. If only one object wanted it, everything would be easier.
Most problems can be solved at compile time, but there will always be execution
time link (that's what the user is for), so that beware !
 As range check is easy to handle, the question is mostly about pointers
modification: if someone sets pointers in a mess inside a pointer updating
garbage collecting system, everything may behave unpredictably !
 Then what if multiple objects with multiple LDT's (or GDT's) must interact ?
That's why I think GDT and LDT are deeply unadapted too OO system programming.
Well, we'll have to call the system so that it changes the DT; use some
descriptors as variables. Then we come to
* systematically call the system for object interaction (the system must be
fast, then). If we do that, we do not need as much DT manipulation, and we can
keep a 32 bit key for each object, keeping a standard size for pointers.


/***************************** MY LANGUAGE *********************************/

Here are specifications for the future language I'd like to use.

*** My Language is Meta-itself: a program in the language, when compiled,
produces another, more low-level. As the language includes low-level stuff,
compiling will be a rewriting of the program to use le low-level instructions.
* ADVANTAGES: The language is its own preprocessor. It is easy to CALCULATE
what will become constants; this is NOT an add-on feature.
* DISADVANTAGES: The compiler may not always stop if the Meta-itself stuff is
used; but you're not forced to use Meta-Itself feature randomly; tools are
included (nesting operations, etc) to build clean recursive reference; 
As the compiler is written in the language itself, you can use the same usual
and you can still high (or low)-level
debug the compiler if you do and it doesn't stop. Moreover, the compile
debugger shows you what part of source code is dangerously meta-ing itself.

*** Physical and logical adjectives have only a relative meaning: some objects
are more basic than other. Highly logical objects are standards.

*** It allows multiple possible logical structure for a physical object, and
multiple possible physical implementations for a logical object. The compiler
is meant to find itself (with your help for better results) the best
implementation.
ADVANTAGES: you don't have to look at details anymore (but you still can).
Instead of building one by one parts of a program (which you're still able to
do if you want), you begin to draw its general scheme, then you precise it.
DISADVANTAGES: ? (note that you can still advice the compiler, or force him
to an implementation; use run-time feed-back, etc; ask him to ask you useful
info for optimization, etc)

*** You can program by constraint (in the future).
for example, it must understand things like (x,y)=z with x,y reals, z complex,
or x=y+2, x+y=1, xy=2, or x+y=2, x-y=-4, etc.

------ bip bip other features
- Integrates code as a virtual object type (-> automodifiable programs in
particular)
- types may accept parameters.
- Any object may be created/evaluated at any time/level from compile time to
local procedure execution.
- Ideally, every object lives in parallel with every other; compiler
determines which can live sequentially or not. (THIS is incompatible with any
existing language and OS, which accept parallel tasks only by swapping
megabytes of memory, and leaves local mutual protection of objects up to you
programmer !)

From rideau@clipper Mon Mar  1 11:30:40 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22090; Mon, 1 Mar 93 11:30:37 +0100
Return-Path: <rideau@clipper>
Received-Date: Mon, 1 Mar 93 11:30:37 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14573; Mon, 1 Mar 93 02:00:26 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from galion.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02171; Sun, 28 Feb 93 00:41:20 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9302272341.AA02171@clipper.ens.fr>
Subject: MOOSE KER,*+ far10
To: moose-programmers@sfu.ca
Date: Sun, 28 Feb 93 0:41:23 MET
X-Mailer: ELM [version 2.3 PL11]
Status: OR

I have 50 Moose message to answer, accumulated since Feb 14 !
So here is my replies to all the ideas emitted with the which I don't
agree (or to the which I want to add something important), after
one week to far away from my computer, and another one too near to it.
   ,
Fare

(I have	 extracted pats of the longest letter, but I also answer to other
points)

-(0a)------------------------------------------------------------------------
>>
>>    ----- Transcript of session follows -----
>> While talking to whistler.sfu.ca:
>> >>> RCPT To:<moose-programmers@sfu.ca>
>> <<< 554 :include:up... Cannot open up: No such file or directory
>> 554 moose-programmers@sfu.ca... Service unavailable
>> 
>> ------- Received message follows ----
>> 
>> Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA25157
>> 	Wed, 17 Feb 1993 17:00:43 +1100 (from winikoff)
>> Return-Path: <winikoff>
>> Subject: Re: MOOSE - comments (REPOST)
>> To: moose-programmers@sfu.ca (Moose Project)
>> Date: Wed, 17 Feb 93 17:00:42 EST
>> From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
>> X-Mailer: ELM [version 2.3 PL0]
>> 
>> I mailed this a while back and haven't seen it or responses to it.
>> Just in case it wasn't forwarded to everyone I'm remailing it now.
>> 
>> This is comments on the original draft and a few following mails.
>> 
>> Michael
>> 
>> --------------------------------------------------------------------

>> [...]

>> > >  The two most important features designed into the Moose
>> > > operating system will be simplicity and flexibility.  For one, a
>> > 
>> > Simplicity and flexibility are not features they are design guidelines.
>> > The way to have them in a system is to have them guide all the other design
>> > decisions we make.
>> >
I agree with both; simplicity and flexibility should guide our choices.
see my topic about OOness and genericity (2) at the end of the message.

>> > ** Could you please explain how object inheritance is done at the OS level?
>> > In particular how it is done SAFELY?
>> >
 At the end of this letter, I should add a (long) topic about my views
upon OO and protection (1) (numbers reversed because one put before
the other)
 
>> > Regards writing the kernel in assembler -- we can break the kernel up into
>> > machine dependent and machine independent parts and write only the former in
>> > assembler.
>> > 
>> > I think the less assembler we use the better.
(that should be obvious, for portability reasons)


>> > Giving device drivers their own priority -- good.
>> >
Ok, but WHO (what processes) can set up device drivers ?
if anyone can call its own local driver, there's no more security. See (1)

>> > >  Most tasks will never need to call these functions explicitly
>> > > as a certain amount of memory will be allocated to each upon
>> > > initialization, depending on the compiler used.  This larger block
>> > > of memory should then be broken up by the task into smaller,
>> >
>> > No. It's simpler to have the compiler insert code which at runtime calls
>> > AllocateMemory and uses it's own data structures to subdivide it.
>> > Automatic allocation of memory isn't needed at all let alone in the kernel
If MOOSE isn't like MS-LOSS, it should include a good dynamical memory alloca-
tion. In the MicroShit operating garbage, you have only one type of (low-level)
slow @+*=%&$ memory allocation system, and if you're not pleased with what
DOS gave you, you must do it all again yourself.
MOOSE should include a large number of different (but similar) memory
allocation zones, for different use needed: as (I don't remember who) justly
points out, different languages, different approaches of computer art need
use memory differently; C and Pascal use a impicit stack and an explicit heap;
functionnal languages (like LISP, ML, and others I don't know) need a implicit
heap with a garbage collecting organization; (those two approaches are the main
I know - tell me more if you know others). That's why the system should offer
many different capabilities of allocating memory, from raw reservation of
contiguous physical memory (to device drives) to garbage collecting-aware
lending of virtual memory (inside apps). See my opinion about OOness and
genericity (2)
. 
>> >
>> > Bear in mind that users should never use system calls -- the compile should
>> > provide (eg.) malloc and implement it reasonably.
>> > Doing that using the system calls is the problem of the compile writer.
(of course, but don't forget either that the system should be conceived for
tomorrow's compilers to do it easily and efficiently)

>> > ----------------------------------
>> >
>> > > most restricted "user" level.  All memory allocated will be
>> > > accessible only by the requesting task and its parent or children
>> > > tasks, allowing no other tasks access to this memory.
>> >
>> > No. I don't like allowing other tasks access to memory by default.
>> > I'd rather that the default was no access and that shared memory was explicitly
>> > requested.
>> > 
>> > My two reasons are
>> > (1) Robustness -- by allowing a whole hierarchy to read/write a process' memory
>> > 	it becomes possible for one of these processes doing something wrong and
>> >  	crashing the entire hierarchy.
>> > (2) Security. 
  To me all that discussion is good only for old bulky OSes of the ancient days
(Unix and its heirs). To me there are no definite huge tasks separate one from
the other, and communicating with great difficulty and slowness through
clumsy special files. To me there is a huge number of small object each
interacting with its few neighbours, and sharing a little bit of info with
them. For simpleness purpose (as well in conception, implementatin, as in use)
objects are more or less hierarchically grouped when possible: virtual
groupings as well as physical one; many groupings being able to overlap; but
as these groupings DO overlap (for example, different ressources each are
accessed by different set of objects), it would be stupid to privilege one
of these groupings in relation with the others (i.e. privilege a particular
resource), telling that objects are in the same process if and only if they
are grouped together in that particular way of grouping objects, and forcing
objects to use named (slow) files and pipes to communicate outside their
groups, and forcing you to rewrite entirely resource handling INSIDE the so-
called process.
 What you all moosers are doing and I don't agree at all is copying Unix
concepts. Unix an old system which (as DOS) has a long genetical history
(but not as DOS, that of a green slime monster), with defect accumulating,
and tricks more and more complcating everyone's life to correct them. It is
stupid, clumsy and bulky; it gives you bulldozers to smash flies, but isn't
able to lend you any tool both standard (an app fitting the others) and good
for little precision work.  With DOS, you know what you have: nothing; but
with Unix, you don't, unless you could read 3 tons of manual pages (far more
than Mac documentation) so that you lose a GREAT amount of time to interface
with the system, through a badly documented system. Unix is a computer
oriented system: you must learn all the machines bugs and hacks to use it;
MacOS is a stupid-user oriented system, so that you don't have many things to
learn, because you can't do many things either ; and of course, DOS is a
non-oriented system, designed to yield the greatest profit with the least
work, and so complicated and buggy you won't trust any second hand soure to
reproduce its horrible behaviour.
 Let's not copy it those OSes' respective flaws. If I did want Unix on my PC,
I'd use linux (sure I would, and certainly will if MOOSE goes in the same
mistakes as its predecessors). But Unix really isn't an OS to dream of; it is
just the only true OS (not like DOS) available with standard (and free !)
apps and tools; but personaly, I'm SO sick of Unix !

>> > I like the MEM_PHYSICAL flag.
 I don't since I have my opinion about how DISTINCT layers of memory allocation
systems should exist the ones inside the others, with as much independance as
possible between them. Low-level programs allocate low-level (physical) memory
zones, high-level progs allocate HL (logical, virtual) memory zones, etc at
each "level" of programming.
 Moreover, this is a hack, and we shouldn't mix specifications and
implementation (as Peter Mueller justly pted out). What would be its
significance in a (highly envisageable) MOOSE kernel a a subsystem of another
more common and/or harware-built OS (Unix on many workstations, MacOS,
IBM&Apple's next system) ?
 Let's not mix the two anymore (did we not say MOOSE should be portable ?).
 
>> > > There will be a limit on the total number of memory allocations
>> > > made by a single task and in the system as a whole, so efforts
>> > > should be made by applications to consolidate memory usage.
>> > 
>> > This is policy rather then mechanism.
>> > I think it is better to say "there will be a mechanism by which processes can
>> > have a limit set on the amount of memory they may allocate"
 To me, you can parametrize the interface beween apps (herarchical groups of
object) and memory; you put an intemediate request analyser between the two,
and that's all. 'sholdn't have anything to do with the Kernel. My solution
is that there be a standard common inteface for memory zones (see the mail
with my HL specs).

>> > > 'size' parameter.  To simplify and expedite memory management, only
>> > > large chunks of memory will be allocated at one time, usually
>> > > varying between 1k and 8k in size, depending on the host platform.
>> > 
>> > This is a implementation decision. I feel that we should either
>> > (1) Make a fixed decision across all platforms
>> > Or preferably
>> > (2) Design the system in such a way that the size of memory allocation does
>> > not make a difference to the user.
Of course (2) ! We're not bulding a low-level (next abbreviated LL) but HL
(will stand for high-level) standard for MOOSE !
Such questions shouldn't occur so the answe is obvious !
Next time, just state the answer (and if you really do want it, quote the
question and then tell for the nth time why the answer is obvious).

>> > >      The starting address of the memory block will be returned by
>> > > this function.  If the allocation fails a null address is returned,
>> > > indicated by an address of zero.
>> > 
>> > Firstly there is scope for a bug here -- consider what happens if the system
>> > allocates a task memory beginning at (virtual) memory location 0 ...
>> > 
>> > Secondly and more importantly we need a system wide standard facility for
>> > communicating back error types and causes -- In order to have sensible 
>> > error reporting we need to return some kind of error code.
There we come to an important point: error handling. Of course, old OSes
(stands for Old Shit ?), being based upon C, couldn't integrate this concept,
neither could they understand anything sensible about HL programming (nor
LL programming with respect (?) to DOS - Double Old Shit (OS/2 being half-old
shit). Recent language like ADA, later version of (true) C++ and CAML do
include exception handling, and many HLL I don't know certainly do. I like
very much that of CAML (not knowing the others - tell me - 't'should be
mostly taken from the same language as for C++, but CAML should be better
because of automatic genericity as opposed to C++'s template hack). The
Kernel should include exception handling as a standard, so that objects
can exchange not only usual data, but also exceptional data (notice that
these language do not allow embedding exception in data itself by declaration
of exceptional format as should accept the language I vouch for (of course,
their are ways to obtain equivalent results, but then why not repeat we all
use Turing Machine equivalent languages ?)

(BTW, who do have read my HL specs, and what do you think of it ? Do flame
its flaws, you're welcome, but do encourage what pleases you in it too.
Do not hesitate to ask for more precisions)
(NB: CAML is a particular version of ML integrating imperative programming
as well as declarative one; we work with it at the School (Ecole Normale
Superieure) in its CAML light 0.5 implementation by Xavier Leroy & Damien
Doligez; it's available for example at ftp: nuri.inria.fr - neither place
nor time to tell more about it here; unhappily, the syntax being to concise
it very dirty, as opposed to lisp's lots of insipid and stubborn parentheses).

>> > Is realloc necessary? Can someone come up with a situation where it is 
>> > essential or even important?
Easy to find: imagine a simple prog' begins by a huge recursive calculus,
using, say, 3megs of stack (let's say it's not optimized for recursive
stack usage, as should be able to compile my HLL). Then, the result is saved,
and a 1Kb largely suffises. Not only should the stack be reallocated, not to
occupy 3 idle megs in swap space, but the Task Manager (I'm talking about
the low-level manager of harware tasks - a close extension to the Kernel,
particularly on the 386 version) should do it by himself (except for possible
compatibility with hacks like reading previously poped values ...)

>> > > E. System Clock and Event Scheduling
>> > > 
>> > > >> How should this be done?
>> > 
>> > Have a device to handle this. 
>> > The advantages of doing things in devices are
>> > 	(1) The kernel is smaller and simpler
>> > 	(2) We can change our mind later and write a different device and
>> > 		easily add it to the system.
(obvious)

>> > > F. Interrupt Handling
>> > > 
>> > > >> How should this be done?
>> > 
>> > I favor a simple interrupt routine that "converts" an interrupt to a message.
>> > Of course some interrupts WILL need to be handled by an interrupt routine but
>> > in general they should be converted into messages.
>> > I feel that this will simplify the writing of device drivers.

 Well, Andreas has proposed a very fine system; as I understood it (perhaps
mixing sit up with my own ideas), you tell each IO manager what routine to
link to the device; instead of using a slow and uneasy common server/client
architecture, where the one does it all and the others just use it and can't
add anything to it, you have a more balanced architecture, where everyone
gives exactly what it has, and takes what it needs (sounds someho
communistic; funny, isn't it ? but the flaw about social utopias was men can't
totally trust each other in real life. Now, clean OO objects surely can, if
the user trusted the one who designed the software he uses...).
 If an object wants to use a message architecture, well, he can do it, and
won't have to do it all by himself (well, in any system, you can redo all by
yourself; that's not using the system but going round it): standard routines
will do that for him. For this to be efficient, OO genericity should be
present at system level: LLL compilers and interpreters available.

To me, here's the privilege hierarchy:

* (if we are to et a 4 level one)
Kernel < System < Libraries < User (no need of Apps)

* to sharpen this outlook:
Kernel exec/mem   LLL interpreter
         Input/Output     LLL compiler   HLL semi-compileree
 		    Devices	  Libraries
                                            User interface="Applications"
     					               common human being


exec/mem: the CPU resource manager, including low-level memory handling &
  task/thread switching
Input/Output: other hardware resource manager
LLL: Low level language - both interpreted & compiled
HLL: High level language - semi-compiled to LLL.
Devices: fast machine code routines
Libraries: LLL interpreted routines/low privilege executable code if exists
Apps: LLL interpreted code
Human being: external random number generator. Some generate HLL, a few use
 LLL.


 Another aspect of this (andreas' and now my) idea is that you transmit code
as easily as previous systems could exchange binary data. This is a standard
feature and standard LLL is here to harmonize it all, weather interpreted
(for debugging purposes/ when performing lossless HL tasks/ when code changes
so often compile time is greater than interpreting time loss) or compiled
(speed with portability and OO maintenance easiness). Previous system made
an arbitrary distinction between data and code (which Turing himself fought
in his first machine); this differentiation was worsened by the CISC
conception with its random stupidly complicated instruction set ( Hey,
Dennis, will you tell that to your intel comrades ? :-) (in fact, I think
they know perfectly well at intel how CISC is horrible and bulky; but they
also know that MS-LOSS compatibility is its golden eggs chicken). To get
back to our topic, the intermediate LLL should be so simple as to dispell
this strong artificial barrier between code and data (which OO embedding
only began to attack).
 To sum up, I think Andreas' approach is definitely the good one (even if
he did not -consciously- think about all its linked concepts). I learnt that
there are many many such thing we know somehow, but we can't use at the best
until we write them down and pronounce them aloud.

>> > Objects:
>> > I like the approach of simply defining a standard format.
Well, if not, this would no more really be OO'ed, and be another DOS, waiting
to be (VERY quickly) obsolete !
OO standardness is compulsory. To be in advance with other existing OS
projects, we must also include NOW genericity (for the which C++ templates
are only a hack) and logical programming (the most common use is find how
to find the "best" path to transform a virtual object into another, knowing
the elementary virtual transformations available and their physical cost).

>> > Files:
>> > 	Actually persistent objects subsume files.
>> > 	(Simply have an object with one of it's attributes being an array of
>> > 		bytes and methods including "read" and "write")
>> > [More about this later]
 The Unix idea was "files are everything", that is, all you can manipulate is
huge, bulky files, with 1Kb size units; when they saw what the user wanted
to manipulate is big number of little data objects, they added little ASCII
string computing in their shell; and to be used the one with the others,
programs all have to input/output ASCII text, ("Everything MUST be expressed as
ASCII", as their is no automatic multitasking compliant file translation system
available) with (moreover) external (slow) not-so-standard (or
worse:compatible!) utilities to handle small strings through a
huge-file-designed FS ! All that is a great bullshit, and that computer
power demand and waste make me vomit.
 A true system's motto should be the opposite: "Everything is an object" (call
it file, call it unit, call it scheme, call it GOD, I don't give a damn; but
it just exists !), so that anything you feed the system with, huge files or
tiny objects, is somehow UNDERSTANDABLE by the system and any generic OO
compliant software.

>> > > from its sleep and may enter its critical section.
>> > > 
>> > > 	semaphore@Down()
>> > > 
>> > 
>> > Why the "@" in semaphore@Down ?
Don't be so upset because of notations. When we have finished internal
specifications, we'll have plenty of time to discuss interface conventions.
(But I favor the same notation for methods as for data fields: why
differentiate each from the other ?)

>> > Nothing is said about how semaphores are created/destroyed.
>> > More seriously nothing is said about how semaphores end up being shared
>> > between two tasks.
The same way any objects get to share any information. See the (1) topic below.

>> > Should we have spinlocks too?
On multiprocessor systems, of course, but that's a kernel implementation
concern; let's not mix specs and its impl' again !

>> > Timers: These seem to be quite complicated.
>> > I feel that timers can be put into a device rather then being in the kernel.
(see what you said before about interrupts in general; this is good also for
timer interrupts and all device events in general !)

>> > One possible (simpler) interface:
>> > 
>> > 	eventid = schedule(time,event)
>> > 	status  = remove(eventid)
>> > 	eventid = schedulerelative(time_delta, event)
>> > 	time    = gettime()
>> > 
>> > In order to simulate timers have a process that does a gettime when it receives
>> > a message.
>> > 
>> > In order to simulate periodic events have the the receiver of the message 
>> > reschedule itself.
>> > 
>> > I'm not certain whether we need facilities to determine how much time a process
>> > has consumed.
>> > If we do it will have to be in the kernel since it involves the process 
>> > scheduler.
How complicated !
Again, let's program it by layer. The lowest (kernel) layer does a Andreas
says. Then, you can have a filter monopolize the lower-level resource to emit
events on a queue, then if you want, mix that queue into a general event queue
for stubborn processes to un-multiplex the global queue, as stupid current
systems do. YES, you CAN do it ! But once you see there are simpler, easier
means to handle data, by piping data just where you want, you WON'T use the
centralizing algorithm. Everything is easier, neater, quicker, better, when
objects just fit one into the other.

>> > > B. Display Output Devices
>> > > 
>> > >     A proper definition of the state of the display output devices
>> > > would be an object-oriented GUI similar to X11, only much easier
>> > > to use. :-)
>> > 
>> > NO!!!!
>> > The user interface is a USER program for flexibility.
>> > The display should offer graphics primitives.
>> > (Eg. line, text, blit ...)
Of course again there are several layers ! Every program uses just the
one it pleases. Every layer has a standard interface; every interface can
be filtered for programs not to interfere each with the other.
(why must I repeat always the same motto ?)
(why am I so aggressive today ? because of Unix !)

>> > User input:
>> > 	It is useful to be able to insert input filters -- processes through
>> > 	which input events pass before being sent to their destination.
>> > (Uses: Screen savers, macro recorders, shortcuts ...)
the BASIC PRINCIPLE of using an OO system is linking object one to the other.
Call it piping, method calling, whatever, its just the inherent idea that
object interact; objects live ! You can't just isolate one: an isolated object
does not live; it cannot even exist !

>> > File systems:
>> > 	One issue that hasn't been raised is crash recovery.
>> > 	I suggest people have a look at Amoeba's file system -- they store
>> > 	files contiguously sacrificing disk space for speed.

>> > Libraries:
>> > 	I'm sorry. I didn't understand this too well.
>> > 	Can you please explain them. 
>> > 	IN particular I'm uncertain as to the difference between objects and 
>> > 		libraries -- libraries seem to be just typed objects which
>> > 		sounds like what you were trying to avoid in ...
 Well libraries, as you see, ar paarticular objects. Of course every object
should be properly typed (that's a definition, something untyped doesn't
"exist" to the system)

>> > >      Strictly speaking, the operating system will define nothing
>> > > more than a standard format for storing a class and a methodology
>> > > for accessing its attributes and methods in a meaningful way.  No
>> > > enforcement of these policies will actually be done to allow for
>> > > maximum flexibility and efficiency.  If objects are not implemented
>> > > correctly by an application or device driver, the loss will be only
 Why "nothing more" ? That's THAT that is important, that's what make the
system OO'ed. That's why you MUST enforce OO compliancy, else you have
nothing but Unix. That's also why OO specs should be well conceived (they're
the key to success or failure), and fit expectation not of the worst
HLL possible (as Dennis seems to have suggested by forbidding variable
length parameters in procedure to fit Pascal stubborness), but of the best
with features not all reunited yet in a unique language (which I will never
fully say how I wish it be), but all more or less present somewhere:
generic types; unifying schemes, including types themselves and functions,
along with any executable code; logical constraint programming; implicit
parameters with a "the computer does it for you the best with the least
data" philosophy,...
 If object are not correctly  implemented, they just won't be able to
communicate ! And we don't want a system where every little thing you do
requires a different application, and you can't communicate the result of
one to the other, but under a postscript file or something like that, do
we ? That's why every object that a user one day may want to link with his
own objects you didn't thought about must be well defined in the OO system;
and these object are seldom what you believed, so the more OO compliant
objects, the better. Now, some object may have very little likeliness to
be interfaced with others, so that you can (meta-)build interfaces that do
exist if you really insist, but that are complicated and slow under
usual circomstances - give just the info in a remote place of an info file,
and that will do: the OO compliancy should be flexible when needed !
Also remember that for HL tasks, you don't gain much from systematically
use optimized code (notwithstanding compile time), and may especially lose
a great deal of memory for code that make you gain less time than it takes
to load it from disk !

>> > [...]
>> > Gary Duzan
>> > ~~~~~~~~~~
>> > 
>> > I think we SHOULD provide a CLI (Command Line Interface) -- their very useful
>> > when porting Unix based software.
>> > 
>> > >   So what language do we write the high-level stuff in? Should it
>> > > matter? Can we make it not matter?
To me, the only way to have an all-user-understandable system is for the HLL
and the CLI to be just the same ! That means that usual (unoptimized) HLL
objects are real-time semi-compiled to LLL; LLL could also be seen as a
subset of HLL, and their syntax may be devised to fit HLL's; the HLL may
thus have many a layer, more or less HL/LL. It's no more a HLL or a LLL, it
becomes THE Programming Language. That's why it's (sub)syntax(es) should fit
all very different needs of people for different tasks, from device I/O to
mathematical abstraction. If we do not implement everything now (let's have
the lowest layers first, and build each with the former ones, as we'll do
with the system more generally)

>> > We MUST make it not matter. An OS that only supports one language isn't going
>> > to be useful.
Well, there's a difference between supporting a language and have it as a
primary language. ANY system can run ANY language as long as it's powerful
enough. You CAN run AppleSoft BASIC on a Unix WorkStation; but you just WON'T,
because it's without any interest but historical. That should be the same for
MOOSE and C/C++: of course you can still use C, but you won't be able to
-directly- use all its power with such a LL dirty language, and you will have
to include many a library to interface both. Moreover, standard LLLing allows
easy implementation of ANY language you want, by providing a fore part of a
compiler from the new language to any (combination of) existing standard layer
of THE PL.


>> > Fare'
>> > ~~~~~
>> > 
>> > Agree. The system should be written in a HLL. C has had an influence on Unix etc
>> > 
>> > > To conclude, I think we mustn't rush doing what would be the kernel of a
>> > > system whose features aren't defined yet. Let's define the high-level object
>> > > orientation of the system before we write the kernel (more precisely, let's
>> > > not write something in the kernel we should have to change completely because
>> > > it will not fit high-level system requirements).
>> > 
>> > I disagree - I feel that the kernel should be designed first with the
>> > applications in mind.
 I disagree: we do agree ! Both must be done at the same time because THAT is
not the fundamental criteria for software development: you must first define
WHAT you want it to do, then see HOW to do it, and feed back the problems
encountered to eventually modify the HL specs, and entering the cycle again.

>> > Lets face it -- this is a chicken and egg problem: The kernel and the
>> > applications (including device drivers) depend on each other's design.
>> > The solution is to start with the kernel (which doesn't actually use the device
>> > drivers and so can be designed without knowing the precise interface) and then
>> > designing the device drivers. This process is then iterated to a fixpoint.


>> > Regards the Mac OS being in ROM - we can simply let it boot and THEN take over.
Why take over, and not run inside it ? after all, a Mac user will still want
to use its existing standard programs, and the MacOS is clean enough to allow
defining new interchange standards; it's up to the Kernel and the I/O device
to adapt the external MacOS layer. Everyone will enjoy interchange betweene
Mac and MOOSE software. That's not possible with DOS where no program can
communicate with no other; and no one sensible will want to communicate with
Unix clumsy ASCII, but to support standard network services.

>> > Some ideas and suggestions -- PLEASE READ THIS BIT
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please read every one else's whole stuff, until work was well divided - see (3)
below !

>> > (1) What audience are we aiming this OS at?
>> > 	My original understanding was standalone PCs but then you mentioned
>> > 	various network drivers.
>> > 	Do we plan to support (Eg.) diskless workstations?
MOOSE should be Pee O aRe Tee A Bee eL Ee. However, we all come to have 386
PC's, because cloning has made these stupid computers CHEAP and STANDARD.
But, we'd love  to be able to run our new standard OS on an even CHEAPER,
NON-STANDARD, BETTER computer (like, say, the Amiga or RISC machines).

>> > (2) We need to have a configuration facility to make installation of new
>> > 	software/devices/hardware totally painless.
>> > 	This of course, will not be in the kernel however I thought it
>> > 	worth mentioning.
>> > 	We should set things up so that either
>> > 	(1) An application doesn't need to know what it's running on
>> > 	(2) An application can easily find out what services the system provides
With my "link the objects" philosophy, there's no more need of a constant
global configuration file; the system is a dynamical link system; it just
boots an object (presumably an all-powerful interface that'll ultimately do
what you want, but propose you standard objects to begin with) and there you
are. You can link/unlink device drivers at anytime, for any group of objects
(you're responsible for it); the Kernel being reentrant, the system will be
able to run inside himslef, so that multiple task managing should be a trifle,
"only" imposing restrictions on atomicity of code/data (THAT is an important
issue !).

>> > 	This is particularly important since an application may find that
>> > 	certain device drivers have not been mounted.

>> > (3) (I've mentioned this b4) We need a facility for returning error codes
>> > 	when a system call fails.
see CAML light exceptions (better than C++ ones, but without the same name
polymorphing): you "virtually" (implementation is up to the Kernel)
define exceptions, with handlers pushing and poping with the code, (the
Kernel/compilers may group or ungroup execptions to optimize), and when
an exception occurs, it is fed to the nearest handler available (with
catch facilities; ultimately a system error handling device will get it);
simple isn't it ? So we may define parametrized exceptions (as code and
data are equivalent, a parametrized value may as well be a function or an
array element or whatever) ...

>> > (4) Objects, Files, address spaces and all that jazz ...
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>> > Persistent objects subsume both processes and files.
>> > Getting rid of the concept of the files is (IMHO) a strong forward step.
see what I said above about Unix, files, and objects.

>> > One idea which may simplify swapping is to use a single address space across
>> > all objects -- possibly even the one corresponding to where they are stored
>> > on disk.
>> > Of course most of the address space will be inaccessible ...
>> > 
>> > The main advantage of this scheme is that it makes shared memory simpler to 
>> > program with -- otherwise pointers have to be avoided since the addresses
>> > will differ from process to process.
>> > 
>> > [But see arenas later]
Again, that's for implementation eyes only. See (1b)

>> > (5) Objects must be first class -- we MUST be able to store objects in variables	, pass 'em to functions etc.
>> > 	The implementation will of course use pointers. This might be a good
>> > 	place to start thinking about capabilities.
wasn't that obvious ? (didn't I say the same thing b4 ? )

>> > (6) Security: It hasn't been mentioned yet.
>> > 	Do we want it?
>> > 	To what degree?
See (1)

>> > (7) I/O redirection:
>> > 	Idea: Have the following convention: when an object is started it 
>> > 	is given by it's creator the objects representing stdin stdout etc.
>> > 	(It may be more appropriate to think of screen, kbd etc.)
>> > 	This lets us easily do I/O redirection -- simply have the shell
>> > 	substitute say, a file for the keyboard or a printer for the screen etc.
>> > 
>> > 	[Note: The list of initial objects could perhaps include ALL objects 
>> > 	used (Eg. file system) for maximum flexibility -- this would then also
>> > 	let us run a program in an isolated environment ... good defence against
>> > 	trojan horses]
Call it I/O, whatever. There will be a generic pipe type to connect anything
that produces something
(in ML: a pipe is a (('a->'b)->('b->'c))->('a->'c) (I know I over-
parenthesised it)) Then your can have all kinds of I and/or O buffered pipes;
pipes that allow you to interrupt and/or see the traffic; automatic
transtyping pipes, etc.

>> > (8) Microkernel:
>> > 	Seems to be the way we're heading. Good.
't'should be able to run even on my HP28 ! Of course, you won't have any
tools, then, hardly a few devices for the simplest I/O.

>> > 	* Efficient IPC is important
>> > 	* Possible interface:
>> > 		send	-- sends a message to an object
>> > 		receive	-- returns the next object. Pauses caller if none
>> > 				available.
>> > 		call	-- Like a send but does a context switch to the receiver
>> > 			for extra speed 
>> > 		spawn (or create_object) 
>> > 		kill	-- destroys an object, freeing it's resources
>> > 		self	-- returns the id of the caller. One use is "kill(self)"
>> > 				instead of a special exit call.
>> > 		alloc	-- AllocateMemory
>> > 		free	-- FreeMemory

Yes, but keep it virtual (i.e. HLL before interpret/compile) level: I hate
unnecessary physical (so-called "virtual") virtual-methods table. Well, after
all, we should agree on inter-objects communication; but then, I think those
methods don't suffise.

>> > The main missing calls in the interface are process communication and 
>> > synchronisation.
(among others). Let's define the OBJECT -virtual- type before implementating
anything (but let's try to define everything to see what we need at base
level); we should need, for example to have its type and possibly other infos,
etc.


>> > (9) Process communication and synchronisation -- a proposal
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > 		
>> > Process communication requires an efficient means of passing large 
>> > amounts of information between processes.
>> > 
>> > The one commonly used is shared memory -- the problem is that pointers don't
>> > work.
Zap,Zap: that's implementation problem. Let's have standard pointer types
defined in the LLL, and a virtual pointer type in the HLL: anything that cast
be used to "point" at an object among others can be called a virtual "pointer"!

>> > I would like to suggest a variation which I'd like to call "arenas"e
>> > The idea is that the arena is like shared memory except that when created 
>> > it is specified to which virtual memory addresses the arena should be bound.
>>
>> > Any process that attaches to the arena has it mapped to the same virtual memory
>> > addresses so pointers can be safely used as long as they remain pointing within
>> > the arena.
>>
Hey, this has few to do with an OS specs: Very Unportable ! Let's leave this to
LLL implementation(s): sure it can be used, but we don't use assembler hacks
-only- for the fun of it, but also to find HL requirements. What do 680x0
programmers would say if they heard you with these 386 tricks ?
There's only one thing at HL: you may want to allocate an object, and you may
want to publish it, so that others can see it where you put signs.

>> > Regards synchronisation -- semaphores are a fairly common primitive.
>> > Rather then having objects we can simply have operations "up" and "down" that
>> > take a pointer to an integer.
Yes, but semaphore need not be needed -explicitly- all HL: they should be a
very low-level built-in Kernel construct (the same as error handling, etc)

>> > By convention the first 4 bytes of an arena can be used as a semaphore for
>> > mutual exclusive access to the arena. This is only a convention and is not 
>> > enforced anywhere.
always more and more hacks ! If there should be semaphores, they should be
standard, and of course the system should enforce its mutual respect policy,
else anyone can have a "safe" task destroying data by not respecting simple
restriction.
>> > 
>> > Comments?
Isn't that enough ?

>> > (10) Do we support distributed applications? How?
I'd like to. That means a lot of sheculing is neaded to know how to distribute
the stuff.

>> > (11) Where is non-deterministic behavior expressed and how?
>> > 
>> > (12) Do we support some notion of "signal" -- ie. pre-empting messages?
>> > 	Should we? (I don't know)
There may simply be external (parallel) exceptions taking over when such signal
appears. The same as Andreas' trick. Remember that you give code as parameter
to other executable code. And then ?
   
>> > 
>> > (13) Should we be providing threads? (I don't think so but am open to debate)
what are threads/tasks but little/large objects ? Why build such a distinction
between both ? We saw well that any definite limit between two was artificial,
as is U*x's: when they don't share memory, unix processes share files; indeed,
there are but large clumsy file under unix; following that philosophy, numbers
should be stocked as directory entry, etc. That's more than stupid !
 Well, any executable object is a thread (or task) somehow. Some tasks need
more context than other (for example, a DOS emulating task may need many
complicated variables to achieve running, while a LLL interpreted task only
needs its (LLL) program counter & exception/running stack pointers &
environment pointer (= 4 system pointers only !).

>> >[ ...]
(I boycott the naming discussion )

---------------------------------------------
Here are other answers:
* Duzan:
>> 
>> =>Is this OS only for programmers.
>> 
>>    The OS should always be for the programmers; the user interface
>> should be for the users.
 YES, but appl. prog. is so much eased or hardened (or even made impossible)
by the OS that you can't totally separate each from the other.


* Dennis : (approximatively quoted)
 (HLL choice) 
> ... (for example) no function calls with arg. lists because not supported
> in Pascal !
 
  Then nothing but ints & chars, because else not supported in assembly (or
SNOBOL, if you want an HLL).
  This is a counter argument because Pascal & C (and other) calling conventions
are different, so that whatever, you can't have your system direct calls
compatible with every HLL !
  Does this mean we must restrict HL programming to the most limited existing
HLL capabilities because of compatibility reasons ? THAT's DOS !
  More seriously, ... OO ... polymorphism ... exceptions ... constraints ? ...


* Dr. Hayden 15 Feb 93
>> So, here's my best and most current "definition" of Moose:
>>
>> "Moose will be a fully interrupt driven, preemptive, priority-based
>> multithreaded system."
  Then Moose would be just another kind of OS/2 and Unix, which would have
the additional disadvantage not being able to execute any existing code
(not to talk about compatibility with old code).
  Moose should be more than that; it should be multithreaded because it is
the only simple means to represent interacting living objects as people
imagine system components, and also because multitasking is the only way to
have the computer work and still be in interaction with the user; it is the
only way for the computer to meet the completely different things the user
(or users !) want it to do at the same time. A computer is a tool that can
and must react to man's mind, and satisfy all his simultaneous and
successive needs.
  MOOSE should be the first and ONLY Intelligent System for Intelligent
User, (ISIU) conceived for easiest mutual machine-human understanding.
  That's not having human learn the machine or do nothing, like Unix; that's
not either saying the human mustn't learn anything, and have him do nothing
as in the Mac. That's really enabling understanding of the human by the
machine; this can be done only through communication between both man ande
computer, where BOTH must make an effort; the effort shouldn't be put in only
one side. The machine must learn how to interpret the man's will so that
to execute it; that for, the human must not consider the machine as stupid
itself and give it unmotivated orders (that's LLL programming - see C).
In the same way, he won't have been thought too stupid to formulate calmly
his wishes: that means communication between both, and each making his best
make him understood.
 That's the basic philosophy of my OO'edness: the machine learns schemes and
general ideas about what it can do for the user. The user can define anything
he wants, it will be understood in its fuller conception; but the machine
won't be neglected, for with each object is defined machine-level info on how
to implement it, what method is the best. Finally, user and machine exchange
only the fewest needed data for both to be sure the other agrees. When one
is not sure, he may be able to "talk" with the other so that to make clear
some obscure points, or decide by himself which solution to choose if it
doesn't matter for the other - that is, machine choose between implementations,
user chooses between names and how to represent logically his objectss - and
that does not mean one has no access to the other, as they can begin a talk
session when needed.
 Now multi* capabilities are only one of the things 

* about DOS FAT systems:
Some talk about reading/writing it. Of course, this is obvious on 386 based
computers. But DOS FAT is so @#$^#$%^& that no sensible people would willingly
use an OS with it as a main FS. Whatever FS is choosen to work on, this should
be included as a device driver, not in the Kernel.


* Could one explain a poor ignorant frenchman the joke about Moose ?
('heard you talk about a Mr Moose; who was it ? )


*** To Andreas:
* UI: why not allowing text windows (a la Turbo-Vision), with
text-fullscreening window capability ? It may be useful for people who don't
have graphical capability (i.e. VT220 users; people who only have CGA, etc) ?
The TUI may be very similar to the GUI and may share most of its programmer
methods with the GUI. I'd like both to include object stack windows (a` la
HP) to use with FORTH directives (with possible switching between RPN and
infix notation).
* no for SVGA only: we'd like the GUI to be portable to any card, as well
lower resolution cards as higher resolution ones. It'd be good also that a DOS
emulator be able to use lower modes. (don't let andreas svgaize the MUSIC)
Last but at least software standards (as opposed to hardware standards) are
more easily portable, makable as a subsystem (for example, why not use the
Mac OS and windowing system in a possible Mac version ? I see no reason why
MOOSE should always be at the lowest layer of the system to run properly.
If we can skip writing I/O, that's all the better for us.

* Andreas : function tables for device drivers.
(Michael David disagrees: says it's too slow)
That's not slow; that should be far faster than stupid polling (on PC's, we
can and must use interrupts to interface with hardware, whereas on many 8 bit
machines we just couldn't and had to synchronize manually). In fact, I think
that's the good method (which I myself thought about when I dreamt about my own
system, a long time ago).
 As for Andreas concerns about list maintenance, there are better ways to
implement a list than use an array; array maintenance is of linear cost,
whereas tree maintenance may be logarithmic if properly managed; so what I
propose is a combined tree/array structure (you give arrays of functions to
the device driver which manages a tree)
 Michael shouldn't worry about queues, for a function given to a device driver
can use queues: each window will have its queues, if it wants; there also are
standard public queues to use explicitly (with standard queue managing
routines provided) (among them, there should be the timer queue, ordened by
increasing date, so that for example the mouse handler enters
wait-for-double-click state at the first click, and tells the timer to end it
some time later; if it happens before the timer signal that the click wasn't
a double click, the mouse driver will just tell the timer to forget the
request)
 Good question: can we really manage a logarithmic algorithm for moving a
pointer into a set of 2D windows, and finding which window it is in...


* Realloc necessary ?
well, what if a task needs 4 Meg stack space at initialization for
recursive calls, and then runs well with 4K ? Will the full 4 Meg stay
in (even swapped) memory while the process is running, whereas it is not
used ? What if only one instance of the process needed the 4 Megs, but
the other instances, not having resizing capability, ask for a 4 Meg stack
as a precaution ?
 Yes, I think ReAlloc may prove useful, and may be included in some
standard extension of the system, if not the minimal one. A simple version
of it is (in an imaginary enhanced Pascal language)

Procedure ReAlloc (x:Allocated_Object;NewSize:Object_size);
 Var
   Y:Physical_Allocated_Objecte ;
 Begin
   With X being physical_object(x) and OldSize being X.size do
    if OldSize <> NewSize
    then
      begin
         Alloc_Physical_Object (y,NewSize) ;
         CopyRawData (X,Y,Min(OldSize,NewSize)) ;
         Tell_New_Size (Y.Contained_Object,NewSize) ;
         Free_Physical_Object (X) ;
         X := Y ;
      end ;
 End ;

* dmarer:
 Keep the Kernel as pure as possible: OK.
 Allow non-OO programming: ??
 - if it means device drivers are not bound to be OO clean, and heavy
 computation need not look multiple method tables at each iteration, ok;
 but if it means there is not a standard compulsory class hierarchy
 from low level raw data classes to high level virtual classes for system
 calls, I don't agree anymore !
  It would mean no more standard means to connect objects one to the other.
 There will be a proliferation of dirty apps which won't recognize each
 other's objects and methods, so that we are back to old DOS incompatibility
 (or to Unix low-level text compatibility). (a)
  The system Kernel interface MUST be OO based; but there are accessible
 low-level objects for low-level programming by low-level programmers (or
 compilers). Of course, only the INTERFACE of the Kernel will be OO based.
 By definition, the Kernel is the minimal set of routine needed to run
 system objects, so that all the remaining can and must be OO compliant
 (including low-level OO, as I please you don't forget before flaming)

 (a) you may notice that compatibility is  decided by what the user can create
 and modify directly from the shell; for as all machines are equivalent each
 to the other, up to power (every one being equivalent to a Turing Machine),
 any app can be rewritten for any machine and OS; what counts is what the user
 actually has when he buys the machine, given with the system, or with the
 main common apps: on 8 bit machines, he had antique line number BASIC's (and
 an assembler and disassembler, on the Apple ][); under DOS he cannot do
 anything; under MS-Losedows, he cannot do anything either, but he's got nice
 windows not to do it; move icons, redraw them, but he cannot really do
 anythingomething elseither; under MacOS, the only standard user language,
 HyperTalk, is good for object manipulation, but incapable of any efficient
 calculus; under Unix he can only manipulate text strings, in fact he MUST use
 them or stick to the remaining, i.e. a COMMAND.COM equivalent. Let alone
 power, I prefer the 8 bit machines.
  Then for the GUI being an "extension": yes, but it may be standard and
 complete, so that you can think programming graphics without it (both
 because it is so standard as to be demanded by the user and because it is so
 complete as to make the programmer feel happy and eased). But it would be nice
 for simple programs not to care about the actual UI to be text or graphics
 based.
 
 - as for a task being an object, I don't see at all how it would slow down
 the system, except if you want MOOSE systematically to implement objects by
 virtual method tables, which effectively is slow and stupid.



-(1)-------------------------------------------------------------------------
As promised, here is my opinion about OO, multi* and protection

--a--
 It sounds clear to me that safety and OO compliance are equivalent topics in
a OO system. If there's no enforcement of OO method use, objects won't bee
secure, and thus will be unusable between processes; the system won't be an OO.
Conversely, in a secure system, only Kernel enforced means are secure, so that
you can't add inter object communication through other means than those given
by the Kernel. If it only handles big files and not tiny objects, you won't
be able to use your tiny objects, unless you voluntarily restrict your use of
the system; but then, as for security, you'll never be able to ensure your
tiny objects behaviour, as any uncomliant (unaware/hostile) internal source can
jeopardize the whole subsystem's integrity.
 That's how MS-Losedoze is, for example !

 To me, the system units and files and processes; they are objects and methods,
the method space and object space being the each other's dual space. Then, what
you called IPC is IOC: Inter-OBJECTS-Communication, or dually IMC, Inter-
METHODS-Communication. As methods are themselves objects, we have a 
monomorphism from one space in the other (which not being one-to-one, proves
the (virtually) infinite dimensionness of the system's logical Object
universe).
 And I make no fundamental distinction between small or huge object/methods,
the big one being tasks and the lesser ones procedures. Objects are all
fundamentally free one from others; but they each interact with a very few
number of neighbours. The system is connected as each object is indirectedly
linked to every other. But, We manage to find significance on objects because
of their linking particularities and structures: the see how to group them,
or differentiate them. We know that two objects are free WITH RESPECT TO a set
of neglected objects if they are independant when you actually cut the
neglected objects. Now, if we ultimately trust the user to tell us all we
must and can about his objects, security is when objects that are free with
respect to user/external manipulation stay free when you don't trust the
user and external world as much as you could if they were perfect.

  Sharing objects: iff you know of an object (have its ID), you can
use it (i.e. use its methods). More or less public/private objects/methods are
achieved by declaring different "views" of the same physical object. Less
privileged actors (with respect to the given object) will only see restricted
"views" of it (my english is poor -- help me find the proper word; I'm suree
that's not "view"). If you want to protect your objects, just don't publish
their ID, or publish ID's for limited "views" of them only.

  That's a general method for protection, which is after all only a "view" of
sharing objects. To enhance this, you may add a key to names so an aggressive
program not be able to pirat you because you use common names.

  Now, what are the IDs, and where are they ?
IDs should be a pointer to an object. For security purpose, you can add a key
to it, so that one who picks unmatching random IDs are detected and isolated.
Now, each object must have infos including its class, ID, and environment,
that is the context in the which the object is defined, its neighbours.
Usual objects have very few neighbours. "Task" object have a large
environment; to some, it may seem that this reproduces Unix environment; but
definitely, this is a very limited comparison: a MOOSE environment variable
can contain any kind of type object. Objects are organized hierarchically, as
are objects in the intermediate code produced by a compiler. And there we are:
we will work on the compiler's intermediate code; interfaced variables will
be published by that means; Uninterfaced variables are forgotten, and may not
fear any exterior jeopardy, thus aer safe, and may have been compiled as such
(the compiler can look for more optimization on uninterfaced variables, while
interfaced variables take more place because when the variable is simplified,
the interface is often complicated, so that you can't optimize much code on
interfaced objects).
  About File system, you will say that an evil object need only look the
main directory, and then have the ID of whatever object he wants - Yes,
that's why a given object/task WON'T have complete rights upon the file
system, and will be forced to use a File server which will automatically
ask object ID from a standard UI call.
  As for copying huge symbol tables for each object, we need not copy the
entire "table" (should be lists of tables of lists of ...), but only point
to table modifications. If modifications exceeds a certain rate, larger parts
of the table may be copied, etc. Pascal-like hierarchy should cause no
problem, with the last defined object checked first: that's what we obtained,
didn't we ? (See later, I call it the dictionnary)

 
 In fact, I think the Kernel Set should be exactly the C/ASM coded methods for
handling low-level objects: tasks/thread/procedures (executable code in
general, including stack management, and exception handling), memory
allocation, object typing, virtual pointers and naming (including subnaming
and polymorphism, linking and unlinking object to the running system (imagine
the coding/decoding needed to load/save an object from the running session
from/to mass memory). Nothing more.
 A basic extension should be a little Forth-like semi-interpreted language
(very quick for high-level stuff, very portable, very light). This language
should be equivalent (with a null or linear time computation) to the famous
standard intermediate code language I vouch for, and may be a VERY usefule
extensible tool for both booting the system, and using it daily (pushing and
poping from/to multiple stacks is great ! Better than mere cut/paste with a
unique one-level stack as in Losedoze and Max).
 Other extensions needed for a minimal lightweight system will be a
simple file system, say, inside a single DOS file; and a simple interface
system, say, a raw terminal to begin with. All that should fit in a very few
K's; less than 64K !
 A basic extension should allow scanning through the hierarchical "dictionnary"
(list of all accessible objects) with several criteria, including comments one
given objects (for example, find the fastest available version of a realee
number handler including numbers ranging from -10e4 to 10e4, with precision
1e-4 (that is 9 decimals, and no need of floating point); on this example, a
32 bit fixed point manager may be sufficient and faster than a co-processor
emulator. I think the dictionnary is very similar to concepts as file system
(files are the only objects supported in Unix and like systems), environnment
(which under Unix and DOS contain only litterate text strings), and of course
compiler symbol table and FORTH dictionnary; the main difference with respect
to DOS/Unix is dictionnary may contain any kind of typed objects, not only
ASCII. Objects in the dictionnary need not be copied for each instance of the
dictionnary, or the dictionnary be duplicated for each object. Each object may
just tell what difference its dictionnary have from parent version.
 The dict. is everything an object know from the exterior. Most simple objects
have a very restricted vocabulary; but an object may allow dictionnary
expansion: local methods name are hierarchically given "inside" the definition
of the local object's classe

 

--b--
386 Kernel Implementation

Here are my assumptions
- You very seldom manage huge unsecable object; if you really do and want
optimal speed, do compile a device driver to assembly; it's worth it; then,
your huge object while be interfaced with the system.
- There only remains to manage small and tiny objects to the Kernel and its
low-level devices. There shall be a huge number of suches.

 You'll tell me having a FORTH-like interpreter is slow ?
No, it may be as quick as Turbo-Pascal Code, more if there the
libraries' features are complete.
 Let me explain
DOS-like dynamical link is unadapted to managing those tiny objects; you can
link one big stable program, but how can you link, unlink, relink tiny
objects ? the linkage table would always be present with the object; or
objects would be forced to fit page alignement ! In both cases, it isn't
stable !
Following 386PM rules as defined by intel works fine with tasks and libraries,
but completely fails if each procedure instance is associated to its particular
"thread"; OO, particularly with Turbo like so-called virtual tables,  would be
SO slow I understand Dennis would hate it. But here comes an interpreter.
The interpreter is in Flat mode, that's why it is FAST (as compared to multi-
segment mode): function call is 2 to 3 times faster, 2 times even faster with
my hack (I too can propose hacks, but I don't mix them with specifs :-).
The security is guaranteed because WE system engineers wrote the interpreter.

PM RET+CALL
>70 clock ticks
Flat RET+CALL
35 ticks
Flat RET only  -> that means if you compile assembly to interpreted code
10 ticks only   you have the worst bound of 20 times slowest. But you never
		do that, so that standard time should be 8 times slowest than
                assembly for integer calculus, and faster than usual assembly
		for virtual table call.

If SS:(E)SP is our LLL PC, that's fine !
interrupts use another stack (because of hardware priviledge) -> ok
we can write-protect SS !



an JMP[BP++] equivalent or LODSW AX, JMP AX should be as fine as well, if you
still want clean intel-compliant kernel.

In the MOOSE standard format (used on disks, for example), function numbers
are used for the FORTH interpreter. When read to memory, function numberse
are mapped to function address. The mapper recognizes operands and do not
map them.

Even the interpreter can have more than one privilege level, so that some
instructions numbers are or not available at compile and/or run time...


BTW, let's ask intel guys: can you have a 16-bit long CS with 32 bit
default instructions ? Or the same for SS ? It should be VERY useful for
Kernel compression.


-(2)--------------------------------------------------------------------------
and here my views upon OO'edness & genericity
(well, that'll be next time !)
--a--
see C++ templates ; CAML generic types


--b--
here's how to implement it
-> we have compile time virtual tables. Only the fewest possible
needed of them are (partly) represented in object code. Directly
interfaced object of course must include full virtual tables,;



-(3)-------------------------------------------------------------------------
 To finish with, here is what I propose for mailing organization:

 We should name our message subject following the actual MOOSE sub-ject of 
the letter, and divide a communication in as many letters as there are
subjects. We will number letters with a personal ID and counter to easily
archive and quote each other's work.

example:
main subjects available would be
ORG - moose ORGanization, nothing to do with actual programming, but
    compulsory.
KER - system KERnel, the minimal set of instruction to bootstrap the OS.
TUI - User Interface; useful for boot strap; also interfaces the language.
GUI - you know what that is.
HLL - High Level Language; its specs, its compiler.
LLL - Low Level language; its specs, its interpreter (compiler for moose 1.0)
DEV - Device level; we define the algorithm for implementing our virtual
     data.
386 - interface with hardware
MAC - interface with MacOS
UX  - interface with Unix systems
NET - remote NET link.

 Most message will be messages at the interface between two or more subject;
let's just list the subjects. For example: the GUI should be intersecting
both HLL and LLL in its specs, HLL so write GUI,HLL and GUI,LLL; Text UI
should be have the same; common GUI and TUI parts should be present in
GUI,TUI; graphics impl' may be talken about in GUI.386 or suches.
compiler specs would be HLL,LLL; the LLL interpreter would be LLL,KER; 
Memory Management would be respectively at KER,DEV LLL,DEV HLL,DEV following
programming level, etc (I'm sure I did not make the right choices; but the
one to manage the mailing list should make the definitive choice after having
heard expressed opinions; he'll have to manage further modifications).

 I thought to add + for OO definition (how it looks from outside), or - for
implementation (how it looks from the inside), so that people interested in
interface only don't HAVE TO know how it is inside (but still CAN). Again, I
don't want to impose my choice to the other, and I'll correct my numbering
following final moose ORG decisions (and I certainly wouldn't take the
responsibility to take this decision alone).
  Next, when those are settled and work well divided, there will be subfields
to  subjects.
HLL.GEN for HLL syntax about GENericity)
LLL.GEN for LLL representation for the same
DEV.FAT for DOS FAT objects devices
DEV.OFS for a possible custom disk Object Filing System
386.DOS for a DOS EMUlator under MOOSE (that's for version 2 at least; for
        now, we'd better make a MOOSE EMUlator under DOS !)
  We'll know better what to add when there we are.

 Personal ID might be 3 letters indicators also, so that I am far, Dennis
is den, Andreas is arf, JJ Lay is jjl, etc (well veryone chooses his ID).
Let's also initialize personal counters to 10, so that we see what to do of
previous messages. Thus, for example:
the first part of my message should be KER,ORG+ far10 then perhaps 
KER,*- far 11
part (1) would be KER,HLL+ far12
part (2a) would be HLL+ far13
part (2b) would be LLL- far14
part  (3) would be ORG- far15


                            --------------


Mailing is too slow a means of communication when there are more than two
people, because each message takes a long time to be read/written.
We should try also a forum, talking, phoning (but this may be difficult).
Why not publish everyone's disponibility for such means of communication ?
Personally I can't receive talks, but I can send one with my brother's account.
I spent more than 24 hours an this mail, and it isn't even a good input
for precise specs.
We should also define a standard format for asking and answering, proposing
and counter proposing to be more efficient. Does anyone in the group mastere
Unix text managing tools, so that we manage directly specs with simple
commands (=add a "message", link it to keywords/other messages as answer,
counter-answer, acknowledge, particularization/generalization, etc...;
for each field, you can keep a list of up-to-date messages, with
the three particular fields Open problems, choices to make do, decisions taken
as everyone can't do this by himself, each part of the specs is let to
someone to manage it for everyone, keeping it as up-to-date as possible.
 The list of keywords must also include where the keyword first appears, is
the best defined; is used in another definition ...

			   ,
			Fare



From uunet.UU.NET!davgar!davgar Mon Mar  1 12:41:15 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24456; Mon, 1 Mar 93 12:41:14 +0100
Return-Path: <uunet.UU.NET!davgar!davgar>
Received-Date: Mon, 1 Mar 93 12:41:14 +0100
Received: from chenas.inria.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by chenas.inria.fr (5.65c8d/92.02.29)
	via Fnet-EUnet id AA29473; Mon, 1 Mar 1993 08:38:28 +0100 (MET)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12323; Sun, 28 Feb 93 23:32:25 -0800
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA01509; Mon, 1 Mar 93 02:32:22 -0500
Received: from davgar.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 023106.19802; Mon, 1 Mar 1993 02:31:06 EST
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR1);
           Mon, 01 Mar 1993 01:22:20 EST
Date:      Mon, 01 Mar 1993 01:22:17 EST
From: (David Garfield) david@davgar@uunet.uu.net
Sender: David Garfield <david@davgar@uunet.uu.net>
Message-Id: <2b91ab9d.davgar@davgar.UUCP>
To: moose-programmers@sfu.ca
Subject:   memory, video, and a few thoughts
Status: OR

I would like to apologize for not contributing much to date, but I
have been busy trying to set up my new USENET site, and have
fallen a bit behind....

I am now at     david%davgar@uunet.uu.net
instead of      garfield@snoopy.sra.com
I do not yet have a domain name, but I am looking in to it.

---------------

 From: "Gary D. Duzan" <duzan@udel.edu>
> =>> >      The starting address of the memory block will be returned by
> =>> > this function.  If the allocation fails a null address is returned,
> =>> > indicated by an address of zero.
> =>>
> =>> Firstly there is scope for a bug here -- consider what
> =>> happens if the system allocates a task memory beginning at
> =>> (virtual) memory location 0 ...
>    Simple enough to fix: just don't do that. :-)

I will again say: You can't allocate memory (address space)
because it already exists!  It is just invalid.  Memory
allocation is the process of changing invalid memory into valid
memory.  All that should be returned is the error code.
Additionally, address zero (and the nearby low addresses) should
be reserved as invalid addresses, so chasing NULL causes an
immeadiate error.  (One of VMS's best desicisions, pity we can't
also make hex 00 an invalid instruction...)

> =>> (2) We need to have a configuration facility to make
> installation of new
> =>>     software/devices/hardware totally painless.
>
>    This is an impossible goal on the ISA architecture. :-(

This is not impossible, and is in fact a VERY good idea.  MOOSE
should have a facility to install any and all additional software
components.  Then any new software being installed can use this
to install itself.  This will avoid the major MSDOS problem that
every piece of software (except the newest Windoze stuff) has a
different installation procedure.

---------------

 From: dmarer@td2cad.intel.com (Dennis Marer)
>         byte:           always 8 bits.
>         char:           always 16 bits (remember Unicode?)
>         short word:     at least 16 bits.
>         word:           at least 32 bits.
>         long word:      at least 64 bits.

The problem with this kind of definition is that terms like word
and long word have been used before, and have meant other things.
For instance, on an IBM 360 and so on, a WORD is 32 bits and a
HALF WORD is 16 bits.  On an IBM PC a WORD is 16 bits and a
DOUBLE WORD is 32 bits.  And this is just within IBM's products.

A (probably) better usage is something which specifies the number
of bits, the signed/unsigned/floating point nature, and whether
the size must (should) be exact.  Perhaps:
        u16             at least 16 bits, unsigned integer
        s32             at least 32 bits, signed integer
        f32             at least 32 bits, floating point
        u8e             exactly 8 bits, unsigned integer
About the only thing that should require an exact size is
something networked.
        u18             at least 18 bits, unsigned integer
We should support EVERY non-exact size up to the maximum
supportable by the achitecture.  This particular type is useful
to represent the time of day.

---------------

 From: ANDREASA@dhhalden.no
> I must fire my last shot at the moosers who want a textbased system :-(, but
> I have to.
..
> The land that uses omlaut a, aa and o,
> and for the countries of europe, japan the mozlem countries and african
> countries. It would be nice if all apps could support Unicode, instead of
> having to remap the character table twice a day. Beeing able to write a letter
> in arabic, then in kanji, or any other alphabet, how are you going to support
> this in textmodus? Remap the character table all the time, stealing valuable
> resources?
> Ok, I know some of you will flame me for this one, but please don't. This is
> a serious problem in many countries, beeing a slave of the ANSI comitte.
> I know it is possible to remap the character table etc., and I have done it
> before, but the world would be much more easy if we had a two byte character.
> Give me another reason than speed, and I might listen more careful.

 From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
> What about a user who doesn't need
> virtual memory, because his/her applications are small? Must he/she
> live with a performance lack, because the system runs all through
> the virtual memory manager's code?

Both these complaints can be answered in the same way.  The
feature (character set remapping and virtual memory) does not get
invoked (save for one-time uses) until needed.

While I am on the subject, I will say again that if Moose is a GUI
only system I will disassociate myself from Moose.  I admit that
Moose needs GUI support, but it needs text support as well.  I am
not going to give up on Moose and text-based capabilities until
forced.

---------------

With reference to all the acronyms etc... being used by everyone,
Unicode and several file systems have been referenced.  Where does
one find information on these?  It would be really nice to know
just what they are.  When mentioning new technical information of
this source, it would be nice to provide the references.
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From mueller@sc.ZIB-Berlin.DE Mon Mar  1 13:04:43 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25072; Mon, 1 Mar 93 13:04:42 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 1 Mar 93 13:04:42 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15749; Mon, 1 Mar 93 04:01:02 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA17607; Mon, 1 Mar 93 13:00:49 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA09422; Mon, 1 Mar 93 13:00:48 +0100
Date: Mon, 1 Mar 93 13:00:48 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303011200.AA09422@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: MOOSE KER,*+ far10
Status: OR

(hey! Where's my code book?)


just kidding. Very good idea to structure mails by subject lines! So I would like
to "reserve" 'pem' for my personal id ...

The mail is to large to be answered now. I've to work ;-)

Bye

Peter

P.S.: arf: Do you want to start a bibliography of Tao? Here's another book:

	The Tao Of Objects
	by Gary Entsminger

From cis.udel.edu!udel.edu!duzan Thu Mar  4 16:01:49 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24249; Thu, 4 Mar 93 16:01:47 +0100
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Thu, 4 Mar 93 16:01:47 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03673; Thu, 4 Mar 93 06:58:50 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id bb26432; 4 Mar 93 9:44 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa03336; 4 Mar 93 3:44 GMT
Received: from sol.cis.udel.edu by daffy.cis.udel.edu id aa26878;
          4 Mar 93 3:40 GMT
To: moose-programmers@sfu.ca
Subject: Processes and Communication
Date: Wed, 03 Mar 93 22:40:31 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303040340.aa26878@daffy.cis.udel.edu>
Status: OR


   This is an overview of my vision for processes and interprocess
communication in the MOOSE system. It is far from being a complete
specification, and I encourage discussion of the various features. I
have intentionally left out any implementation details or actual
example interface code so that we can decide on the abstract model
first and move on to the implementation once the model is ironed out.

   Entities in the MOOSE system are referred to as 'objects'. The
interface to an object is composed entirely of 'methods'. One object
communicates with another by 'invocing' a method on another object.
Invocation is accomplished through Remote Procedure Calls, or 'RPC'.
An invoced method is called a 'thread'.

   Objects represent protected units of functionality in MOOSE. With
the exception of inheirited (non-virtual) base class code (libraries),
each object has a completely private, non-shared address space. The
kernel is reponsible for scheduling objects and providing resources as
needed. Each object has a specific protection level which determines
how the object's threads may directly modify the system hardware.

   An RPC call will contain information such as a remote object name,
the remote object's method name, permission information, and a set of
arguments to the method. The invocing thread is blocked, the message is
delivered to the destination object, the object executes the method
with the given arguments, and passes the return value (or error code)
in a message as a reply to the calling thread. Note that passing
pointers isn't useful, since objects have disjoint data spaces. There
are, however, techniques to improve performance when passing large data
items.

   The thread is the basic unit of execution within an object. A thread
can invoce a method of another object via an RPC. The calling thread is
blocked until the call is completed, but the other threads are allowed
to continue. The call is received by a thread in the target object that
waits for calls to that particular method. Threads can create other
threads to execute while others are blocked. This allows the object to
continue processing while waiting on the result, while maintaining
procedure call semantics.

   An object is created by an RPC call to an object with access to the
scheduler and resource allocator. An object with such access may also
destroy an object by descheduling it an deallocating its resources.
Less drastic object control is implemented though normal method calls.
Each object will have an initial set of object names. This will
generally include the name of an object that holds the names of other
objects. Each object should include a method to determine the names of
its other methods.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Sun Mar  7 14:58:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06077; Sun, 7 Mar 93 14:58:25 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Sun, 7 Mar 93 14:58:25 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08132; Sun, 7 Mar 93 05:55:42 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA02380; Sun, 7 Mar 93 14:55:39 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA03427; Sun, 7 Mar 93 14:55:38 +0100
Date: Sun, 7 Mar 93 14:55:38 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303071355.AA03427@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: ORG,ROI,pem
Cc: mueller@ave.ZIB-Berlin.DE
Status: OR

Hi,

(hope, I've used the right code in my subject line. To Fare': Correct
me if I'm wrong :-)

> >> >    An RPC call will contain information such as a remote object name,
> >> > the remote object's method name, permission information, and a set of
> >> > arguments to the method. The invocing thread is blocked, the message is
> >> > delivered to the destination object, the object executes the method
> >> > with the given arguments, and passes the return value (or error code)
> >> > in a message as a reply to the calling thread. Note that passing
> >> > pointers isn't useful, since objects have disjoint data spaces. There
> >> > are, however, techniques to improve performance when passing large data
> >> > items.
> Again, I suggest to implement a standard second way for errors and exceptions,
> with an exception handler routine stack.

If I'm on the right track you want to establish a second communication link in
addition to the main link for error and exception messages? If so, it's just 
uneccessary. If in a communication a faster link is needed let the objects decide
to establish such a connection. If I'm on the wrong track, ignore this paragraph.

> 
> >> That's again too deep. Naming should be done by another object, eg. a 
> >> NAME_SERVICE. This must exist, because objects must be able to publish 
> >> themselves or their methods to the outer world. Thus, an object X which
> >> want to be published invoke a methods of the NAME_SERVICE, which makes X
> >> known within the NAME_SERVICE's scope:
> >> 
> >> +---+              +--------------+
> >> | X |---publish--->| NAME_SERVICE |
> >> +---+              +--------------+
> >> 
> >> If an object Y wants to use X it first must determine X's location. Therefore
> >> it asks its NAME_SERVICE, which returns X location:
> >> 
> >> +---+                           +--------------+
> >> |   |---ask for X's location--->|              |
> >> | Y |                           | NAME_SERVICE |
> >> |   |<---return X's location----|              |
> >> +---+                           +--------------+
> >> 
> >> Now Y can simply invoke a method from X:
> >> 
> >> +---+             +---+
> >> | Y |---invoke--->| X |
> >> +---+             +---+
> >> 
> >> With this design it is possible only to contact published objects. More: You
> >> have to contact the right NAME_SERVICE to get a desired object's location. 
> >> Think of several applications (which are O B J E C T S), which all have their 
> >> own NAME_SERVICE available. Several objects with the same name may coexist
> >> even with different functionality but the application's local NAME_SERVICE
> >> secures, that the application is only able to invoke methods of well known
> >> objects. 
> >> 
> >> Of course it is possible to "link" NAME_SERVICE objects. So it is possible to
> >> create hierachical or other name scopes. If an object's location cannot be
> >> resolved within the first (ie. smallest) scope the next higher NAME_SERVICE
> >> is automatically invoked.
> >> 
> >> What I currently left out is, how an object received knowledge of "its"
> >> NAME_SERVICE. (Or to be precise: Which NAME_SERVICE provides the knowledge
> >> of the desired object.) If you want, I can try to present you a design
> >> idea.
> again, I do agree with Peter's remark, but else support Gary's views (perhaps
> are we going to agree upon that 'dictionnary' stuff as I call it - call it as
> you may).
> 
> >> >    The thread is the basic unit of execution within an object. A thread
> >> > can invoce a method of another object via an RPC. The calling thread is
> >> > blocked until the call is completed, but the other threads are allowed
> >> > to continue. The call is received by a thread in the target object that
> >> > waits for calls to that particular method. Threads can create other
> >> > threads to execute while others are blocked. This allows the object to
> >> > continue processing while waiting on the result, while maintaining
> >> > procedure call semantics.
> >> 
> >> That's again too deep for the first ROI specification.
> Well Gary's just anticipating on implementation.
> 


> >> >    An object is created by an RPC call to an object with access to the
> >> > scheduler and resource allocator. An object with such access may also
> >> > destroy an object by descheduling it an deallocating its resources.
> >> > Each object will have an initial set of object names. This will
> >> > generally include the name of an object that holds the names of other
> >> > objects. 
> >> 
> >> Hmm, what does object creation have to do with ROI? (BTW: In my opinion
> >> an application which cannot receive access to an object, simply create an
> >> instance of a new one. Then the object can make itself available via the 
> >> application's NAME_SERVICE or a predefined one. Of course the application
> >> object already know the object's location and can invoke methods immediately.)
> >> 
> >> > Each object should include a method to determine the names of
> >> > its other methods.
> >> 
> >> NO! Publish all methods which should be accessable by other objects to the
> >> NAME_SERVICE! Seperate the services (provided by objects) and it's management
> >> (provided by NAME_SERVICEs). Without such separation each time you include
> >> a new service you must also change the determination method. Don't mix up
> >> services and their availability.
> Uh, well, both ! It may be useful to ask the method's name directly to the
> object without having to look through the whole table (but both methods are
> equivalent; you can build the name list from the objects with a method list
> method; or you can build a method list method from a name list; so to me,
> that's up to implementation)

No, it's not the same. If you have to provide a method, which holds all information
about the object's functionality you are forced to mix implementation and 
access within one object. If we use oo, we should separate both. (BTW: How do
you ask for an object method's name if there's no NAME_SERVICE, giving you 
information of the object's location?)

Next, oo means to design from base with minimal extensions. As Fare' said, a
functionality method can simply be provided by asking name facilities for known
objects and building up a method list (which must hold object's location [its NAME]
and the name of the method). This seems to me to be a minimal extension.

Last, if an object have once asked for a remote object's location it can address it
(ie. invoke its methods) directly. There's no need to ask the nameing facility more 
than once.

Again, "directly" means, that there are IPC (and know I mean IPC) mechanisms, which
make such method calls possible. This includes, address resolution, routing, 
sending, and receiveing (which both should be synchronous). IPC should be included
in the kernel. There's a must that IPC must be as fast as possible. 

If there's interest, I will set up a design specification during the next week. 
(I know you will all be happy with that ;-) But first I want to wait a few days and 
give you time to throw in your ideas. PLEASE: I know you are all sitting in front of
your keyboards, willing to answer to all those ideas as fast as possible. I want you
to think it over. Don't think about implementation, how it can be done, or what 
problems may occur in real programmer's life. I want you to think in a higher 
level, abstract, and object-orientated. Think in terms like: services, invocation,
functionalities, methods, and - of course - objects. Imagine a system, where no
communication costs exist (uuh, you will flame me for that), where you have no 
memory restrictions, or stuff like that. Think of an ideal system. (Again: Let's
first say what we want and then see, how we can get it.) Start up a drawing program
and draw pictures with boxes as objects and arrows as communication lines. (Think
about a possibility to send it via e-mail :-)

Now, read again my vision of a NAME_SERVICE mentioned above, get yourself a cup of
coffee, and ... FLAME ME!

Cheers,

Peter					

From cis.udel.edu!udel.edu!duzan Sun Mar  7 20:40:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12276; Sun, 7 Mar 93 20:40:28 +0100
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Sun, 7 Mar 93 20:40:28 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA13301; Sun, 7 Mar 93 11:37:41 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa18610; 7 Mar 93 14:35 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa22534; 7 Mar 93 19:35 GMT
Received: from sol.cis.udel.edu by bugs.cis.udel.edu id aa28609;
          7 Mar 93 19:30 GMT
To: moose-programmers@sfu.ca
Subject: Capabilities
Date: Sun, 07 Mar 93 14:29:51 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303071930.aa28609@bugs.cis.udel.edu>
Status: OR


   There seems to be some interest in using capabilities in MOOSE, and
probably an equal amount of confusion about them. Therefore, I'll take
the opportunity to put on my professor's cap and talk about them for a
bit.

   A Capability is just that: the ability to do something. An entity
that holds a capability has the right and ability to perform a
particular operation on another entity. To do something to something
else, you need to what you are doing it to, so capabilities incorporate
addressing as well. Therefore, capabilities include both naming and
security in a single concept. Capabilities may be passed to other
entities to allow them access to the capability-protected entity.

   A typical implementation will have an object id, method id, a set of
rights bits, and possibly a sub-object id (for large objects that
manage a set of smaller objects.) In a distributed system, it may also
contain hints about which system the object resides upon. The calling
entity would make a system call containing the capability and any data
to pass to the method. When the destination object receives the
message, it examines the capability for validity, and if valid,
performs the desired operation.

   Now, if capabilities were only normal structures, a malicious entity
could simply flip rights bits and do whatever it pleased. There are
basically two ways to deal with this problem: system capabilities and
encrypted rights.
   A system with system capabilities keeps all capabilities in a
protected space which normal entities cannot access. This system space
contains a table of the capabilities held by each entity in the system.
Instead of including the capability itself in the system call, the
entity passes an offset into its capability table. The system then
extracts the capability from the table and passes it to the destination
object. For the Unix people out there, this is something like the idea
of a file descriptor. Though I have no experience with it, I understand
that this is the method used in OS/400.
   A system with encrypted capabilities treats capabilities like any
other program data structure. To maintain the security of the
capability, the rights field, along with a random number generated by
the object, is encrypted, with the object holding the decryption key
(or keeping a table of encrypted rights -> rights mappings.) To forge a
capability, an entity would have to know the encryption method, the
encryption key, and the random number. This is the method used in the
Amoeba distributed operating system.

   Note that nowhere in this discussion is the concept of a user or
superuser mentioned. An object accepting a capability doesn't care who
holds it, as long as it is valid. In such systems, a user is just
another entity that holds certain capabilities. Capability systems will
also generally support a naming object to distribute capabilities. Such
an object would contain sub-objects which hold other capabilities.
These capabilities may refer to other sub-objects of the naming object
or to other objects in the system. In this manner, a single capability,
possibly representing a user, can expand to a full set of rights to
objects in the system.

   Capabilities have been around for a long time, but have never been
very popular. However, with the rediscovery of the powerful simplicity
of capabilities, and their implementation in the Amoeba and OS/400
systems, I believe we are facing the dawn of a capability renaissance
in operating systems.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From uunet.UU.NET!davgar!david Mon Mar  8 08:12:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29363; Mon, 8 Mar 93 08:12:00 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Mon, 8 Mar 93 08:12:00 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA01107; Sun, 7 Mar 93 23:09:12 -0800
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA11076; Mon, 8 Mar 93 02:09:09 -0500
Received: from davgar.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020835.806; Mon, 8 Mar 1993 02:08:35 EST
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR5);
           Mon, 08 Mar 1993 01:53:25 EST
Date:      Mon, 08 Mar 1993 01:53:21 EST
From: (David Garfield) uunet.UU.NET!davgar!david
Message-Id: <2b9aed66.davgar@davgar.UUCP>
To: moose-programmers@sfu.ca
Subject:   memory allocation (djg4)
Status: OR

I firmly believe that at the kernel level, a malloc() style memory
allocation interface should not exist.  Using malloc() does not allow
any chance for the application to control where the memory blocks are
placed.

An alternative is for the memory allocation requests to be done by
specifying the memory block and whether it is to be virtual memory,
invalid memory, or any of a variety of other choices.  Along with
this, there needs to be a request to inquire what the status of an
area of memory is.  Another useful request is to locate an area of
invalid memory (kernel support only needed for speed).  This sort of
scheme does allow a malloc() style interface on top of it (in a
library?), and also allows exact placement of memory.

I will point out that the call to determine the status of a memory
area is ABSOLUTELY NECESSARY no matter what allocation scheme is used.

I will admit to one advantage to the malloc() style interface, and
that is the (memory manager only) ability to relocate the virtual
memory provided by realloc().  I will admit I would like to see this
ability kept, even if it does mean another kernel call.
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From uunet.UU.NET!davgar!david Mon Mar  8 08:12:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29364; Mon, 8 Mar 93 08:12:00 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Mon, 8 Mar 93 08:12:00 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA01102; Sun, 7 Mar 93 23:09:08 -0800
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA09864; Mon, 8 Mar 93 02:09:10 -0500
Received: from davgar.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020834.801; Mon, 8 Mar 1993 02:08:34 EST
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR5);
           Mon, 08 Mar 1993 00:58:16 EST
Date:      Mon, 08 Mar 1993 00:58:09 EST
From: (David Garfield) uunet.UU.NET!davgar!david
Message-Id: <2b9ae07a.davgar@davgar.UUCP>
To: moose-programmers@sfu.ca
Subject:   Object Sharing via File System (djg3)
Status: OR

A possible means of making data objects available to other processes:

It is possible for

   1) All processes to be objects.

   2) Objects to be in the logical file system.

   3) Objects themselves be asked what objects are below them in the
      file system.

With this setup, each process object is placed in the logical file
system.  Each process object may then be queried as to what public
objects it contains.  If a process is a 'dumb' program, this would
probably mean either nothing is public or a fixed list is public.  A
'smart' program could either published all its objects or a portion of
its object list it selects.

As an additional capability, a 'smart' program could have objects
placed into the directory that it provides by other programs.  This
could be used as a means of specifically requesting communications
with a process.

Additionally, if an object can be placed in one place in the file
system, it can be placed in other 'known' places, allowing for the
publication of objects.

One other capability allowed by mapping between directories and
objects is that something like a ZIP file (produced by PKZIP or the
like) could allow its contents to be directly accessed as a file.
Mapping between different styles of file systems could happen the same
way (assuming you want to nest filesystems).


Note on terms:  I am using the term 'logical file system' to refer to
the effective file system that exists when the system is running.  In
Unix this is composed of the the root file system and any file systems
and network file systems mounted on it.  In the case of Moose, the
logical file system will (I hope) also include objects and other
things.

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From winikoff@cs.mu.OZ.AU Tue Mar  9 06:44:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06655; Tue, 9 Mar 93 06:44:26 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 9 Mar 93 06:44:26 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07515; Mon, 8 Mar 93 21:35:12 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA11355
	Tue, 9 Mar 1993 15:34:51 +1000 (from winikoff)
Date: Tue, 9 Mar 1993 15:34:51 +1000
From: Michael David WINIKOFF <winikoff@cs.mu.OZ.AU>
Message-Id: <9303090534.11355@mulga.cs.mu.OZ.AU>
To: moose-programmers@sfu.ca
Subject: You might be interested in this ...
Status: OR

Picked this up of news ...

Michael
--------------------------------------------

In article <FS_FUCHS.93Mar2173339@rcsw66.rcvie.at> fs_fuchs@rcsw66.rcvie.at (Kurt Fuchs) writes:
>In article <1993Feb16.093823.7497@worak.kaist.ac.kr> hanmaum@kaist.ac.kr (Oh Sung-kyu) writes:
>> Hi all,
>> I am an MS majoring Computer Science.
>> Recently, I am much interested in Object-Orientedness and want to know
>> more things about it, especially what is called as Object-Oriented OS.
>> If you know any definitions, ideas or examples of it, mail me please.
>> Thanks.
>
>Chorus Systemes is developing, besides their micro-kernel Chorus, a
>Chorus Object Oriented Layer (COOL, resp. COOL-2) to give support for
>the development of object oriented operating systems.
>-- 
>Kurt Fuchs				  voice:    +43 (1) 39 16 21 / 177

Also see Choices from Univ Chicago at Urbana-Chamgane (choies.uiuc.edu).

I've wondered what one would do with an object-oriented OS?
Would some application inherit from iostream to produce, say, an indexed
file illusion?  Or inherit from fork() to provide some tracking with
the applicaiton of which programs where run... and if you did this,
would it affect system() libary call?

	Does UNIX limit my thoughts?

I'm curious because I want to create such an OS (like Choices), but where
you just override/inherit any function call.  Then any *application*
that comes around later, would use the local definition.  Hydra took
this direction (from CMU).  Just how to make this practical...
How to maintain security...  What if your method has an fatal error...
Is it really worth it?

Also..
Can an object-oriented OS be designed using conventional programming
inside of it while presenting an object-oriented interface?  Many
windowing systems go this route.  Are server (aka Mach) designed to 
give an object-BASED interface (can't inherit an object-based i/f; Ada).

Pointers to articles/papers/FTP sites appriciated...  I attending the
USENIX microkernel conference.  Don't ask me how small is a microkernel.

--- brian

-- 
============================================================================= !
   Brian Witt   Sac State Computer Science]   "Waldo, the pariot, is dead"
   Internet:  wittb@cube01.ccs.csus.edu               -- Agent Cooper
                #define  POSIX_ME_HARDER     1       <-- GNU

From dmarer@td2cad.intel.com Wed Mar 10 01:41:23 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07351; Wed, 10 Mar 93 01:41:21 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 10 Mar 93 01:41:21 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02954; Tue, 9 Mar 93 16:38:14 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Tue, 9 Mar 93 16:38:10 -0800
Received: by td2cad (5.57/10.0i); Tue, 9 Mar 93 16:41:41 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00400; Tue, 9 Mar 93 16:48:58 PDT
Date: Tue, 9 Mar 93 16:48:58 PDT
Message-Id: <9303100048.AA00400@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re: Processes and Communication (2)
Status: OR

Hi!

>    Imagine a system that automatically changes the protection level
> when the code enters a particular code area. Each protected block of
> code would provide a special block of memory containing jump
> operations. This block would allow other code to execute it, and
> executing it causes a protection switch, so when the CPU hits the jump
> target, the processor will be executing with a new set of rights.

For anyone who has familiarity with the 386, you know how incredibly
easy this is to accomplish!  There exists two tables, the Global
Descriptor Table and the Local Descriptor Table, in which entries can
be made to reference segments, tasks, and *procedures*.  Calling one
of these "gates" automatically transfers the task to a higher priviledge
level, allowing it to access parts of memory it couldn't before, or
possibly directly access I/O ports, etc.

One disadvantage: there are only 8192 global entries and 8192 local
(to the task) entries available.  I could see a large task running
short real quick...of course, not *every* method of every object would 
need to go in these tables, just those which operate at a different
priviledge level.

> Hence, communication would be via normal function calls. Even if this
> communication mechanism isn't used, any secure communication method
> between entities with different protection levels would suffice for a
> complete system. One entity could have memory allocation rights, while
> another might have access to a particular device, while others may
> provide high-level services. Accessing these resources is simply a
> matter of communicating with the entities that provide them.

It wouldn't be too difficult to implement a secure method on any
processor, granted its not too antiquated.  Even the 680x0 has its
notion of a supervisor/user mode, which suits our purposes.

>    Please keep the flames down to simmer; this is all hypothetical/
> theoretical stuff, and won't necessarily apply to MOOSE. However,
> there may be some ideas we can use in there somewhere.

I can't think of any other way to accomplish what we need to do without
some sort of mechanism like this.  It's completely transparent to the
programmer and even to the compiler.  I like it!

Just had to put by $0.02 in on the implementation side of this scheme...

		Dennis

From mueller@sc.ZIB-Berlin.DE Wed Mar 10 16:56:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06403; Wed, 10 Mar 93 16:55:59 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 10 Mar 93 16:55:59 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28880; Wed, 10 Mar 93 07:51:57 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA09041; Wed, 10 Mar 93 16:51:54 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA07579; Wed, 10 Mar 93 16:51:54 +0100
Date: Wed, 10 Mar 93 16:51:54 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303101551.AA07579@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: ORG, ROI, pem - question
Status: OR

I've sent out an answer to the first presentation of 
Gary's IPC specification, where I was asking you to
give me feed back if you want to see a design 
specification for ROI. As I've seen NO response, I get
a little confused if you all have received this.

So, I would ask you to give me an ACK if you have 
received a message with 'ORG,ROI,pem' as subject line.

Thanks,

Peter (or, to be precise: 'pem')

From winikoff@cs.mu.OZ.AU Thu Mar 11 02:35:22 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24344; Thu, 11 Mar 93 02:35:21 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 11 Mar 93 02:35:21 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA13677; Wed, 10 Mar 93 17:29:04 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA21452
	Thu, 11 Mar 1993 11:28:53 +1000 (from winikoff)
Message-Id: <9303110128.21452@mulga.cs.mu.OZ.AU>
Subject: Re: Processes and Communication (2)
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 11 Mar 93 11:28:50 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To:  <9303101224.aa17241@buster.cis.udel.edu>; from "Gary D. Duzan" at Mar 10, 93 7:24 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> =>What is the advantage of having no kernel as opposed to a micro-kernel?
> =>Sounds as if someone said "micro-kernels are better then typical bloated
> =>kernels hence having no kernel must be better still" :-)
> 
>    Well, you'd have to agree that it is a radical idea, and there will
> always be young upstarts like myself that will jump at anything that
> goes against the establishment. :-) I think the basic idea it that if
> you can build a system that is quick and efficient without a kernel,
> then you'll end up with a more flexible system if you get rid of it.
> It also logically separates the different parts of the kernel
> (scheduler, memory manager, communications, etc.) into manageble and
> easily replaceable chunks, just like microkernels do for higher-level
> services.  However, keep in mind that it isn't even unanimously agreed
> upon that microkernels are the way to go, much less non-kernels.

I've read the paper.
The main argument seems to be that there is benefit in having a system wide
address space as opposed to a separate address space for each program.

This has nothing to do with the size/existance of the kernel (IMHO)

> 
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 
> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Thu Mar 11 13:25:31 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16156; Thu, 11 Mar 93 13:25:29 +0100
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Thu, 11 Mar 93 13:25:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02337; Thu, 11 Mar 93 04:22:46 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa11510; 11 Mar 93 7:14 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa21392;
          11 Mar 93 12:13 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa12705;
          11 Mar 93 12:11 GMT
To: Moose Project <moose-programmers@sfu.ca>
Subject: Re: Processes and Communication (2) 
In-Reply-To: Your message of "Thu, 11 Mar 93 11:28:50 EST."
             <9303110128.21452@mulga.cs.mu.OZ.AU> 
Date: Thu, 11 Mar 93 07:11:00 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303111211.aa12705@bifur.cis.udel.edu>
Status: OR

=>I've read the paper.
=>The main argument seems to be that there is benefit in having a system wide
=>address space as opposed to a separate address space for each program.
=>
=>This has nothing to do with the size/existance of the kernel (IMHO)

   True, but the second paper I referenced (from Communications of the
ACM) does discuss the possibility of a communication mechanism (or
coordination language, as he calls it) eliminating the need for a kernel.
The first paper just struck me as a possible way of implementing it.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From rideau@clipper Thu Mar 11 23:13:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03555; Thu, 11 Mar 93 23:13:00 +0100
Return-Path: <rideau@clipper>
Received-Date: Thu, 11 Mar 93 23:13:00 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06178; Thu, 11 Mar 93 14:03:23 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from galion.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03307; Thu, 11 Mar 93 23:03:13 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303112203.AA03307@clipper.ens.fr>
Subject: Re: KER arf1 What should the kernel contain
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Thu, 11 Mar 93 23:03:15 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <MAILQUEUE-101.930308213821.448@sofus.dhhalden.no>; from "Andreas Arff" at Mar 8, 93 9:38 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR


>> To divide all the postings to get a more clear view of what we are talking
>> about I write this message.

>> Ok, how far have we come.
>> 
>> The kernel should contain:
>> - Task manangement
>> - LL Memory management (physical/virtual)
>> - A _small_ messaging system for events that araise in the kernel and that
>>   affects the running tasks.

>> Of course I know that there are others that have different meanings about
>> this, but lets agree on the most minimum kernel that is possible.
>> Ok, add your wishes and I'll sort them out in about a week, and hopefully
>> by then we shall have the next rev. from Dennis handy (or what do you say
>> Dennis. Got a shock from my last mail? Were only kidding).

I see it more like that:
- The "kernel" is only a ASM/calling convention which allows using another
objects' methods.
- Then, we have basic modules; but these modules are modules the same as
high-level modules; only what they do is more basic; they do not have
different means to communicate than the other modules. You often cannot
decide exactly where the kernel ends and where the devices begin, or where
the devices end and where the application begins, or where the application
ends and where the end-user program begins.
- For example, see memory management: we first have physical memory allocated
into blocks; inside these blocks work one or more instances of a virtual
memory manager. It's very low-level, isn't it ? Then, we may have instances
of (32 bit long) word aligned memory blocks manager; several may have
garbage collecting, etc.  Well, that's no more the kernel. But where did it
end ? We only have several layers of memory managers, each directly accessing
its memory, which is allocated from a lower manager.
- For the task manager, we'll first have a low-level object for each hardware
interrupt; a timing manager will plug into the timer interrupt; a threading
manager will each time choose a thread to run then tell the timer when to
next preempt running thread. Each thread class will have thread launcher,
thread interrupter, thread rerunner, signal takers (etc) methods. Among these
"thread" classes may be hardware tasks (if hardware implemented as with the
intel 386) and subtasks, tiny interpreter threads (for interpreters with
breakpoints such that only few registers are necessary to know the thread's
state), etc. Where did the kernel begin, where did it end ?

>> 
>> Arff
>> sig.'s in for 1000 miles service
>>         --Andreas Arff          andreasa@dhhalden.no--
>> 
>>

   ,
Fare

From rideau@clipper Fri Mar 12 00:39:41 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06355; Fri, 12 Mar 93 00:39:40 +0100
Return-Path: <rideau@clipper>
Received-Date: Fri, 12 Mar 93 00:39:40 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA13423; Thu, 11 Mar 93 15:33:53 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from galion.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06150; Fri, 12 Mar 93 00:33:45 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303112333.AA06150@clipper.ens.fr>
Subject: Re: KER,THREAD arf 1 - Thread definition
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Fri, 12 Mar 93 0:33:47 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <MAILQUEUE-101.930308220243.320@sofus.dhhalden.no>; from "Andreas Arff" at Mar 8, 93 10:02 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR


>> A thread is a part of a task that can _act_ as a separate task in the meaning
>> of program execution, but is a method in a program and shares the program
>> data and code-space.

 There's no fundamental difference (from the system's point) between tasks and
threads; there are larger or smaller threads; threads sharing more or less
(real, virtual, virtual virtual, virtual^n) memory (=objects) with other
threads, where the other thread can be part of a device manager, or a server
(for example, if we are to build a GUI "server" as X-Window for Unix, we'd
like not TO HAVE to pipe all data thru a PHYSICAL file; rather share virtual
window objects, for the system to maintain if the server is remote, or to
be actual shared memory if the server is at hand. Whatever, I don't like
the X server structure at all: you have low-level access to high-level
structure, etc).

 So we have a thread/task/running-code class; a program/procedure is a
function returning running code, (parameters being global data zone, for
example). The code actually runs if it is linked to the running list in the
task manager; else it is interrupted.

>> Meaning of program execution means that it has got its own entry in the task-
>> list.
(That's it)

The task specific concept is available only if hardware support special
task managing as with the i386 cpu. But this has to do with implementation,
and not with moose specifications.

>> The thread must contain abilities to lock and unlock data, and the code that
>> initializes the thread should be able to do so before the thread start its own
>> execution.
As a function returning running code, a program class method can itself include
computations, that is running code ! So loader/ender routines are no problem.

   ,
Fare

From dmarer@td2cad.intel.com Fri Mar 12 01:02:40 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06957; Fri, 12 Mar 93 01:02:39 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 12 Mar 93 01:02:39 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15210; Thu, 11 Mar 93 15:57:12 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Thu, 11 Mar 93 15:56:59 -0800
Received: by td2cad (5.57/10.0i); Thu, 11 Mar 93 16:00:23 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00769; Thu, 11 Mar 93 16:07:48 PDT
Date: Thu, 11 Mar 93 16:07:48 PDT
Message-Id: <9303120007.AA00769@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re: KER,THREAD arf 1 - Thread definition (GREAT!)
Status: OR

Howdy!

	I like Fare's definition of a thread.  It seems like a complete
definition and the ideal path to pursue in our system.  I also like how tasks
and threads are one and the same, except a thread shares the memory space
of its (task) parent.  Looks good!

> The task specific concept is available only if hardware support special
> task managing as with the i386 cpu. But this has to do with implementation,
> and not with moose specifications.

I think it would be possible to implement tasks on devices which do not
have these functions built in as well.  The 386 swaps tasks automatically
using a jmp or call instruction which just saves the state of the machine
and loads another task's state as well.  This would be easy to do with most
machines.  For example, the 68k: Push all registers (one instruction) then
save the stack pointer in the process table.  To restore a task, load its
stack register, pop all registers, and return.

The point I'm trying to make is that the concept of a task is easy to
implement even on a system which doesn't explicitly have it in hardware.
>From the programmer's point of view, nothing is different.  It may be a little
slower, but is still identical.

One question I have is this: what kind of information is associated with a
task?  Memory space, of course, but what else?  Accounting (time, etc) info?
This will need to be specified eventually, but is not vital yet.

**

I've decided that I tend to look at the implementation aspect of things where
a lot of you tend to look at the theory aspect.  Just an observation...
I think its good to get both points of view!

Do you realize I've received over 1.2 megabytes of mail from you in the past
two months?  I think that's great!

			Dennis

From winikoff@cs.mu.OZ.AU Fri Mar 12 13:03:02 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01781; Fri, 12 Mar 93 13:03:01 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 12 Mar 93 13:03:01 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02624; Fri, 12 Mar 93 03:51:27 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA02995
	Fri, 12 Mar 1993 15:52:32 +1000 (from winikoff)
Message-Id: <9303120552.2995@mulga.cs.mu.OZ.AU>
Subject: KER, win
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 12 Mar 93 15:52:31 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

Hi! 
I've knocked up a sketch for a simple kernel.
I've currently left out virtual memory and object support simply 
because virtual memory seems to be dependant on how we do objects and
we haven't reached a consensus (or even an understanding yet!) on objects.

I'll hopefuly find the time to write it up over the next day or two.

Michael

--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Fri Mar 12 13:06:16 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01870; Fri, 12 Mar 93 13:06:15 +0100
Received-Date: Fri, 12 Mar 93 13:06:15 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03527; Fri, 12 Mar 93 04:01:59 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA28248
	Fri, 12 Mar 1993 13:54:54 +1000 (from winikoff)
Received: from hermes.intel.com by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50); id AA15149
	Fri, 12 Mar 1993 06:03:17 +1000 (from dmarer@td2cad.intel.com)
Return-Path: <dmarer@td2cad.intel.com>
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Thu, 11 Mar 93 12:02:54 -0800
Received: by td2cad (5.57/10.0i); Thu, 11 Mar 93 09:06:31 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00580; Thu, 11 Mar 93 09:13:39 PDT
Date: Thu, 11 Mar 93 09:13:39 PDT
Message-Id: <9303111713.AA00580@tdge15.intel.com>
To: winikoff@mulga.cs.mu.OZ.AU
Subject: Re: Processes and Communication (2)
Status: OR

> > =>What is the advantage of having no kernel as opposed to a micro-kernel?
> > ...I think the basic idea it that if

> > you can build a system that is quick and efficient without a kernel,
> > then you'll end up with a more flexible system if you get rid of it.

> I've read the paper.
> The main argument seems to be that there is benefit in having a system wide
> address space as opposed to a separate address space for each program.

That does keep things simple enough, but what about security?  If each program
shares the same address space and one of them goes awry (due to a pointer error
or something) other programs could get trashed.  One of the nice things about
separating each task is that they can't interfere with each other and no one
task can bring down the whole system.  If it begins to overstep its bounds,
the kernel can kick it out.

I'm not convinced on the "no-kernel" idea.  It seems there needs to be some
entity responsible for the lowest level management of the system resources.
(These resources would be: memory, I/O, and tasks <- nothing else!)  This
keeps the kernel teensy (read: micro) and everything would be an extension of
the kernel.  Without some central control of these basic resources the machine
is very vulnerable.  One of my biggest *likes* about Windows 3.1 is that a
buggy program no longer brings down the whole system (like Windows 3.0), and
when I'm writing a chunk of software which uses doubly linked lists of records
containing splay trees of objects, I'm bound to make a mistake somewhere... :-)

IMHO, I think the kernel should define the interface to the system: memory is
used in a certain way, device drivers are set up in a certain way, tasks act
a certain way.  What lies on top of this is the "operating system", and from
there the possibilities are endless.

Question: someone (michael?) mentioned that the kernel should contain *fast*
IPC - anybody have any insight to why it should be in the kernel vs. on top of
the kernel?  Just curious - I can't see any speed advantage, but maybe I just
don't see...it might fall under the "task" category of the kernel, but I'm not
sure yet.  Any input?

I guess I'm a fan of micro-kernels.  Could you tell?  :-)

Dennis


From mueller@sc.ZIB-Berlin.DE Fri Mar 12 13:11:40 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01960; Fri, 12 Mar 93 13:11:38 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Fri, 12 Mar 93 13:11:38 +0100
Received: from sc.ZIB-Berlin.DE by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA13208; Fri, 12 Mar 93 13:11:09 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA10531; Fri, 12 Mar 93 13:11:08 +0100
Date: Fri, 12 Mar 93 13:11:08 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303121211.AA10531@sc.zib-berlin.dbp.de>
To: ANDREASA@dhhalden.no, danodom@matt.ksu.ksu.edu, dmarer@sc9.intel.com,
        duzan@cis.udel.edu, uunet.uu.net!davgar!david, haydedr@wkuvx1.bitnet,
        mckeeveb@sfu.ca, mueller@sc.ZIB-Berlin.DE, newlin@ecn.purdue.edu,
        rideau@clipper, winikoff@cs.mu.oz.au
Subject: ORG, ROI, pem 03/12
Status: OR

Hi,

I've sent an ACK request for a mail with similar
subject line, but received only one (1). I now re-send
the mail more or less directly by a name list. Sorry,
if you received it twice.

----- Begin "ORG, ROI, pem" -----

Hi,

(hope, I've used the right code in my subject line. To Fare': Correct
me if I'm wrong :-)

> >> >    An RPC call will contain information such as a remote object name,
> >> > the remote object's method name, permission information, and a set of
> >> > arguments to the method. The invocing thread is blocked, the message is
> >> > delivered to the destination object, the object executes the method
> >> > with the given arguments, and passes the return value (or error code)
> >> > in a message as a reply to the calling thread. Note that passing
> >> > pointers isn't useful, since objects have disjoint data spaces. There
> >> > are, however, techniques to improve performance when passing large data
> >> > items.
> Again, I suggest to implement a standard second way for errors and exceptions,
> with an exception handler routine stack.

If I'm on the right track you want to establish a second communication link in
addition to the main link for error and exception messages? If so, it's just 
uneccessary. If in a communication a faster link is needed let the objects decide
to establish such a connection. If I'm on the wrong track, ignore this paragraph.

> 
> >> That's again too deep. Naming should be done by another object, eg. a 
> >> NAME_SERVICE. This must exist, because objects must be able to publish 
> >> themselves or their methods to the outer world. Thus, an object X which
> >> want to be published invoke a methods of the NAME_SERVICE, which makes X
> >> known within the NAME_SERVICE's scope:
> >> 
> >> +---+              +--------------+
> >> | X |---publish--->| NAME_SERVICE |
> >> +---+              +--------------+
> >> 
> >> If an object Y wants to use X it first must determine X's location. Therefore
> >> it asks its NAME_SERVICE, which returns X location:
> >> 
> >> +---+                           +--------------+
> >> |   |---ask for X's location--->|              |
> >> | Y |                           | NAME_SERVICE |
> >> |   |<---return X's location----|              |
> >> +---+                           +--------------+
> >> 
> >> Now Y can simply invoke a method from X:
> >> 
> >> +---+             +---+
> >> | Y |---invoke--->| X |
> >> +---+             +---+
> >> 
> >> With this design it is possible only to contact published objects. More: You
> >> have to contact the right NAME_SERVICE to get a desired object's location. 
> >> Think of several applications (which are O B J E C T S), which all have their 
> >> own NAME_SERVICE available. Several objects with the same name may coexist
> >> even with different functionality but the application's local NAME_SERVICE
> >> secures, that the application is only able to invoke methods of well known
> >> objects. 
> >> 
> >> Of course it is possible to "link" NAME_SERVICE objects. So it is possible to
> >> create hierachical or other name scopes. If an object's location cannot be
> >> resolved within the first (ie. smallest) scope the next higher NAME_SERVICE
> >> is automatically invoked.
> >> 
> >> What I currently left out is, how an object received knowledge of "its"
> >> NAME_SERVICE. (Or to be precise: Which NAME_SERVICE provides the knowledge
> >> of the desired object.) If you want, I can try to present you a design
> >> idea.
> again, I do agree with Peter's remark, but else support Gary's views (perhaps
> are we going to agree upon that 'dictionnary' stuff as I call it - call it as
> you may).
> 
> >> >    The thread is the basic unit of execution within an object. A thread
> >> > can invoce a method of another object via an RPC. The calling thread is
> >> > blocked until the call is completed, but the other threads are allowed
> >> > to continue. The call is received by a thread in the target object that
> >> > waits for calls to that particular method. Threads can create other
> >> > threads to execute while others are blocked. This allows the object to
> >> > continue processing while waiting on the result, while maintaining
> >> > procedure call semantics.
> >> 
> >> That's again too deep for the first ROI specification.
> Well Gary's just anticipating on implementation.
> 


> >> >    An object is created by an RPC call to an object with access to the
> >> > scheduler and resource allocator. An object with such access may also
> >> > destroy an object by descheduling it an deallocating its resources.
> >> > Each object will have an initial set of object names. This will
> >> > generally include the name of an object that holds the names of other
> >> > objects. 
> >> 
> >> Hmm, what does object creation have to do with ROI? (BTW: In my opinion
> >> an application which cannot receive access to an object, simply create an
> >> instance of a new one. Then the object can make itself available via the 
> >> application's NAME_SERVICE or a predefined one. Of course the application
> >> object already know the object's location and can invoke methods immediately.)
> >> 
> >> > Each object should include a method to determine the names of
> >> > its other methods.
> >> 
> >> NO! Publish all methods which should be accessable by other objects to the
> >> NAME_SERVICE! Seperate the services (provided by objects) and it's management
> >> (provided by NAME_SERVICEs). Without such separation each time you include
> >> a new service you must also change the determination method. Don't mix up
> >> services and their availability.
> Uh, well, both ! It may be useful to ask the method's name directly to the
> object without having to look through the whole table (but both methods are
> equivalent; you can build the name list from the objects with a method list
> method; or you can build a method list method from a name list; so to me,
> that's up to implementation)

No, it's not the same. If you have to provide a method, which holds all information
about the object's functionality you are forced to mix implementation and 
access within one object. If we use oo, we should separate both. (BTW: How do
you ask for an object method's name if there's no NAME_SERVICE, giving you 
information of the object's location?)

Next, oo means to design from base with minimal extensions. As Fare' said, a
functionality method can simply be provided by asking name facilities for known
objects and building up a method list (which must hold object's location [its NAME]
and the name of the method). This seems to me to be a minimal extension.

Last, if an object have once asked for a remote object's location it can address it
(ie. invoke its methods) directly. There's no need to ask the nameing facility more 
than once.

Again, "directly" means, that there are IPC (and know I mean IPC) mechanisms, which
make such method calls possible. This includes, address resolution, routing, 
sending, and receiveing (which both should be synchronous). IPC should be included
in the kernel. There's a must that IPC must be as fast as possible. 

If there's interest, I will set up a design specification during the next week. 
(I know you will all be happy with that ;-) But first I want to wait a few days and 
give you time to throw in your ideas. PLEASE: I know you are all sitting in front of
your keyboards, willing to answer to all those ideas as fast as possible. I want you
to think it over. Don't think about implementation, how it can be done, or what 
problems may occur in real programmer's life. I want you to think in a higher 
level, abstract, and object-orientated. Think in terms like: services, invocation,
functionalities, methods, and - of course - objects. Imagine a system, where no
communication costs exist (uuh, you will flame me for that), where you have no 
memory restrictions, or stuff like that. Think of an ideal system. (Again: Let's
first say what we want and then see, how we can get it.) Start up a drawing program
and draw pictures with boxes as objects and arrows as communication lines. (Think
about a possibility to send it via e-mail :-)

Now, read again my vision of a NAME_SERVICE mentioned above, get yourself a cup of
coffee, and ... FLAME ME!

Cheers,

Peter					


From dmarer@td2cad.intel.com Fri Mar 12 19:24:22 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16574; Fri, 12 Mar 93 19:24:21 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 12 Mar 93 19:24:21 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21452; Fri, 12 Mar 93 10:14:50 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Fri, 12 Mar 93 10:13:57 -0800
Received: by td2cad (5.57/10.0i); Fri, 12 Mar 93 10:17:35 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00860; Fri, 12 Mar 93 10:24:48 PDT
Date: Fri, 12 Mar 93 10:24:48 PDT
Message-Id: <9303121824.AA00860@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: KER, obj (was Re:  KER, win)
Status: OR

> Hi! 
> I've knocked up a sketch for a simple kernel.
> I've currently left out virtual memory and object support simply 
> because virtual memory seems to be dependant on how we do objects and
> we haven't reached a consensus (or even an understanding yet!) on objects.

Great - we'll be looking forward to seeing that!

Q: Why is virtual memory considered dependant on how we do objects?  Maybe I
   missed that discussion...

-------------------------------------------------------------------------------

I have some thoughts on objects:

I would like to see the kernel *support* objects.  (Now I have to define what
this means.)  The kernel does not consist of objects - all of the kernel 
functions will be standard function calls.  However, some of these calls take
objects as parameters, and some portions of the kernel use objects when they
are called.

For example, I was working up a method for handling hardware interrupts in an
OO evironment.  It's been driving me crazy trying to find a way to have an
interrupt pass control to a method within an object.  (Consider if a device
driver is an object, this is *exactly* what needs to be done.)  I've devised
such a way (implementation details are unnecessary right now) and the
interface to it is like so:


	These deal with regular interrupt handlers, cases where a function
	is called when the interrupt is generated.  No data is passed to the
	function.  The 'number' is the hardware interrupt number, the
	'handlerFunction' is the address of the function to call, and the
	'flags' parameter can be use to indicate that an interrupt can be
	shared by one or more handlers.  This is useful (for example) with
	the IBM PC's serial ports.

		status = IntrAddHandler(number,handlerFunction,flags);
		status = IntrRemoveHandler(number,handlerFunction,flags)

	Now for the fun stuff!  An interrupt handler can be added to generate
	an interrupt and call an object's method using the following functions.

		status = IntrAddObjectHandler(number,object,method,flags);
		status = IntrRemoveObjectHandler(number,object,method,flags);

Ok - this is just an example I've been tinkering with.  I think its something
that does need to go into the kernel (most CPUs implement interrupts in some
state and somebody needs to control access) but for now its just an example.

In this case, the kernel needs to know enough about objects to (1) determine
if the method passed is physical or virtual, as well as the structure of
objects in general to see if it's got multiple inheritance in its lineage, etc.
and (2) be able to call this method when the interrupt is generated.  Also,
interrupt handlers can't have any parameters.

Remember how I mentioned modules have detailed information about all functions
and objects, including full parameter info about methods?  The kernel can use
this information to satisfy requirement (1) and to perform parameter checking.
I guess the kernel will also need to know about the structure of an object,
how to call a virtual function, and so on.

The structure of an object needs to be clearly defined by the kernel: how it
stores the attributes (data) associated with an object, how polymorphism
affects the virtual method tables (VMT) of an object, especially in the case
of multiple inheritance, and so on.  Also, this definition of an object needs
to be useful to all languages...this is a tall order to fill!

I'm familiar with objects in terms of Ada and C++, which could both use pretty
much the same object structure with no problem.  (As far as I can tell, method
scoping is the only real difference.)  How about other OOP languages anyone
is familar with?  How are these different?

I'll do some probing around in the newsgroups too - someone should have some
ideas on this... :-)


		Dennis

From bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Mar 12 23:53:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24598; Fri, 12 Mar 93 23:53:54 +0100
Return-Path: <bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 12 Mar 93 23:53:54 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14379; Fri, 12 Mar 93 14:49:16 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa09194;
          12 Mar 93 17:44 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa16904;
          12 Mar 93 22:42 GMT
Received: from sol.cis.udel.edu by bofur.cis.udel.edu id aa26827;
          12 Mar 93 22:40 GMT
To: moose-programmers@sfu.ca
Subject: Re: Processes and Communication (2) 
In-Reply-To: Your message of "Thu, 11 Mar 93 09:13:39 PDT."
             <9303111713.AA00580@tdge15.intel.com> 
Date: Fri, 12 Mar 93 17:40:14 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303122240.aa26827@bofur.cis.udel.edu>
Status: OR

=>That does keep things simple enough, but what about security?  If each progra
m
=>shares the same address space and one of them goes awry (due to a pointer err
or
=>or something) other programs could get trashed.  One of the nice things about
=>separating each task is that they can't interfere with each other and no one
=>task can bring down the whole system.  If it begins to overstep its bounds,
=>the kernel can kick it out.

   I'm afraid you've got segments-on-the-brain. :-)  As I understand
it, other types of MMU specify access rights for ranges of addresses,
so the system can maintain a single 0 - (2^n - 1) address space with
different protected address sub-spaces.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From rideau@clipper Sat Mar 13 12:09:08 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15438; Sat, 13 Mar 93 12:09:07 +0100
Return-Path: <rideau@clipper>
Received-Date: Sat, 13 Mar 93 12:09:07 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07350; Sat, 13 Mar 93 03:05:38 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15389; Sat, 13 Mar 93 12:05:34 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303131105.AA15389@clipper.ens.fr>
Subject: Re:  PLEASE READ THIS ONE far18
To: dmarer@td2cad.intel.com (Dennis Marer)
Date: Sat, 13 Mar 93 12:05:32 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <9303091758.AA00221@tdge15.intel.com>; from "Dennis Marer" at Mar 9, 93 9:58 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>> Hi Moosers,
(bis)
">>" is Dennis, quoting ">> >" Michael.

>> > The reason, I think, is that we don't have a common conceptual image of
>> > what the system should end up being.
>> > 
>> > Different people's proposals suggest different systems -- everything from 
>> > an OO based application sharing layer sitting above a conventional hardware
>> > abstractor through a small single user Unix to a distributed multi user 
>> > system.
>> > Can we drop detailed issues and talk about conceptual models for the moment?
>> 
>> But its much more fun to talk details... :-)
>> 
>> > I'd like everyone to stop and think about what type of system they'd invisage
>> > MOOSE as -- how would you summarise it's ESSENCE?
>> > 
>> > Then try to explain your view to everyone else.
>> >
>> > I'd particularly like Dennis (who has been rather quiet lately) to try
>> > and get across his conceptual model.

I think Michael hit the spot again: we grouped because each of us sought
something new that lacked in existing systems; something that is deeper than
just how systems are implemented; something that touches system philosophy.
If not, the solution would just be "buy a new, more powerful, computer", and/or
switch to unix (there's linux and BSD available on cheap 386 PCs).

>> :-)  Yep, this is true.  Forgive the silence, I've got some rather stressful
>> situations upon me at the moment.  Still working, thinking, eating, and
>> breathing Moose, just not being very vocal.
>> 
>> Here's my ideas: (from the ground up)
>> 
>> I envision Moose as a flexible operating system.  The heart of it is the
>> kernel which takes care of all that stuff kernels are good at: memory and
>> device handling, task handling, and nothing more.  This is a pure interface
>> to the machine and it must support the concept of an object.  It will not
>> be all that much different than other kernels except in the way it handles
>> the objects...
(That may be a valid definition of the kernel; then our micro-kernel/no kernel
discussion may be about the kernel's kernel :-)

>> The kernel needs to understand what I call modules and libraries.  These are
>> identical in definition to Unix modules and libraries: a module contains a
>> collection of related functions, data, and objects.  What is different about
>> Moose modules is the interface.  All "external" functions, data, and objects
>> are included in the interface in exact detail - this includes data types and
>> sizes of all function parameters, heirarchy of objects, and so on.  The
>> private objects not included in the interface are not directly accessible,
>> but everything in the interface is described in enough detail such that
>> load-time or run-time linking to a module is possible.
>>
>> A library is just a collection of modules...nothing special there. :-)
 Hey ! libraries are collections of modules, modules are collection of objects.
Why have this cumbersome terminology ? Let's have only objects as system
basic idea. Modules will naturally arise, and the simplest is the system base
concept, the better, and the more beautiful and intellectually satisfying
(again, remember to follow the Tao of Progamming).
 But for that, I agree objects can't come alone, and heavily linked objects
will be grouped in modules, then libraries and so on; be even libraries are
linked to external programs, etc; for unlinked objects are of no use (even
unix terminology use the link/unlink scheme).

>> Maybe an entire library is loaded into memory at once with all references
>> between modules predetermined, or maybe modules are loaded one at a time
>> and dependencies cause other modules to be loaded.  I don't know - maybe
>> this is something which should fall under the next category...
>> 
>> The most important library in our system will be the system library.  This
>> will include functions and objects to make the system useful.  For example,
>> a semaphore object might be included here.  Objects to perform IPC would
>> also be found here, not in the kernel.  Disk drive object prototypes,
>> file system object prototypes, keyboard object implementation, mouse
>> object prototypes, memory management objects, and on and on and on.  Not
>> all of this has to be done using objects, but why not?  ;-)  This library
>> defines the operating system, the kernel is there only to support it.
 Why create this arbitrary library ? Let's group objects as they are programmed:
when strong links appear, group the objects. Grouping should again arise
naturally.

>> (Some of the above were listed as prototypes, where we would define only
>>  "pure" objects with no implementation.  I don't want XXX video device
>>   driver in the operating system library even if there's a good chance
>>   I'd use it.  Each video device could be implemented as an object in
>>   its own library as a descendant of the pure video object.)
>>
>> On top of the operating system, most definitely, absolutely, positively
>> *not* within the operating system, exists things such as the user
>> interface.  Be default, the operating system includes *no* interface!
>> Most of us will want one though :-] and I'd prefer to see both text and
>> graphics.
I totally agree; however, standardization in UI's would be very nice, and
a system without application is unusable.

>> >> Ideally, I'd like to see a well enough designed interface such that
>>    a program written for a GUI using buttons, scroll bars, windows, and
>>    other GUI concepts could be run without modification and without
>>    recompiling under a windowing Text User Interface (TUI).  As long
>>    as the GUI version does not use the primitive graphics functions
>>    this is entirely possible.
>> 
>> Overall, I envision a system which is logical and uncomplicated to use.
>> The interface to every layer of software is *simple* and *flexible*,
>> not requiring (in the case of, for example, X Windows) seven or eight
>> books open on my desk at all times to write software with.  Seriously!
>> (I do write X software, and I do have this many books to reference...)
No book at all would be great. For example I love Borland programs' internal
help, and I learned Pascal without a book, only with help and examples; I
had to look only once in a book to learn C (for function pointer declaration),
and sometimes for C++ (but this was before Borland C++).

>> I believe this should be the software designer's operating system not
>> the end-user's operating system.  Windows is *great* as far as the
>> end-user is concerned, and O/2 2.1 is *even better*.  Really!  But,
I wouldn't say that: you can't do anything. It's an interface to nothingness !

>> have you ever tried to write a Windows Application?  From my point of
>> view, it's not a good programmers interface.  The user interface is
>> simple to duplicate and well defined enough that we ought to be
>> more concerned with the software interface, which affects issues in
>> software development such as development time and frustration.
It's so complicated no one even at Microsoft can understand it all, and
why it was implemented that way. It's only bad stuff added on bad stuff, etc,
each time to go round bugs and misses in previous versions.
To avoid such things, the system should be naturally extensible; it should
provide high-level as well as low-level standards, but not horribly mixed
together; there should be a standard extensible description for generic objects
so that we won't need a hack to add a feature to the system.
If it is well done, the basic system will never have to be written again, but
to optimize it on a new hardware implementation.

>> Have I said enough?  I could go on for a while yet...
>> 
>> Hope this has gotten my ideas across - I'll try to be more active
>> in discussion now, but I think Michael has gotten an important point
>> across which I think we were missing.  The concept is important,
>> the details are the easy part...
>> 
>> Dennis
   ,
Fare

From rideau@clipper Sat Mar 13 12:37:21 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16213; Sat, 13 Mar 93 12:37:20 +0100
Return-Path: <rideau@clipper>
Received-Date: Sat, 13 Mar 93 12:37:20 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07711; Sat, 13 Mar 93 03:34:24 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16078; Sat, 13 Mar 93 12:34:22 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303131134.AA16078@clipper.ens.fr>
Subject: Re: pointer implementation far19
To: dmarer@td2cad.intel.com (Dennis Marer)
Date: Sat, 13 Mar 93 12:34:21 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <9303100048.AA00400@tdge15.intel.com>; from "Dennis Marer" at Mar 9, 93 4:48 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>> Hi!
(>> is Dennis, >> > is Gary)

>> >    Imagine a system that automatically changes the protection level
>> > when the code enters a particular code area. Each protected block of
>> > code would provide a special block of memory containing jump
>> > operations. This block would allow other code to execute it, and
>> > executing it causes a protection switch, so when the CPU hits the jump
>> > target, the processor will be executing with a new set of rights.
>> 
>> For anyone who has familiarity with the 386, you know how incredibly
>> easy this is to accomplish!  There exists two tables, the Global
>> Descriptor Table and the Local Descriptor Table, in which entries can
>> be made to reference segments, tasks, and *procedures*.  Calling one
>> of these "gates" automatically transfers the task to a higher priviledge
>> level, allowing it to access parts of memory it couldn't before, or
>> possibly directly access I/O ports, etc.
>>
>> One disadvantage: there are only 8192 global entries and 8192 local
>> (to the task) entries available.  I could see a large task running
>> short real quick...of course, not *every* method of every object would 
>> need to go in these tables, just those which operate at a different
>> priviledge level.
 I already thought about using segment as direct pointers to objects (a long
time before MOOSE); but as for obvious security reasons an application can't
modify its descriptor tables, the system should do it; then, each time you
assign a new value to a segment, you must use a system call. It's pretty
slow ! The only solution that arose was again the system low-level
interpreter: if you trust it, you can allow it to modify segments directly,
and it can be quick if algorithms involving lists and pointers are
implemented in the interpreter.
 Whatever, segments can't be the only way to point: offsets are far quicker,
and suffice for internal calculation. Segments should be used only for
inter-object communication; then, descriptor tables can be used as pointer
tables (could you remind me if DT addresses point to real or virtual
memory ?).
 Finally, that's a purely 386 specific hack. You can't expect it to work
on any other system. What I mean is we mustn't build MOOSE specification
around an unportable hack, which does not mean this hack isn't interesting
for implementation.

>> > Hence, communication would be via normal function calls. Even if this
>> > communication mechanism isn't used, any secure communication method
>> > between entities with different protection levels would suffice for a
>> > complete system. One entity could have memory allocation rights, while
>> > another might have access to a particular device, while others may
>> > provide high-level services. Accessing these resources is simply a
>> > matter of communicating with the entities that provide them.
>> 
>> It wouldn't be too difficult to implement a secure method on any
>> processor, granted its not too antiquated.  Even the 680x0 has its
>> notion of a supervisor/user mode, which suits our purposes.

On other processors, an interpreter is compulsory to ensure security,
but for very sure assembler (device) routines.

>> >    Please keep the flames down to simmer; this is all hypothetical/
>> > theoretical stuff, and won't necessarily apply to MOOSE. However,
>> > there may be some ideas we can use in there somewhere.
>> 
>> I can't think of any other way to accomplish what we need to do without
>> some sort of mechanism like this.  It's completely transparent to the
>> programmer and even to the compiler.  I like it!
>> 
>> Just had to put by $0.02 in on the implementation side of this scheme...
>> 
>> 		Dennis
>> 


From rideau@clipper Sat Mar 13 12:54:52 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16576; Sat, 13 Mar 93 12:54:52 +0100
Return-Path: <rideau@clipper>
Received-Date: Sat, 13 Mar 93 12:54:52 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07956; Sat, 13 Mar 93 03:52:07 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16533; Sat, 13 Mar 93 12:52:04 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303131152.AA16533@clipper.ens.fr>
Subject: Re:  PLEASE READ THIS ONE far18 (addendum)
To: dmarer@td2cad.intel.com (Dennis Marer)
Date: Sat, 13 Mar 93 12:52:03 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <9303091758.AA00221@tdge15.intel.com>; from "Dennis Marer" at Mar 9, 93 9:58 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(Addendum to message far18)

Here is what I  first wrote about modules:

 I don't think the module/library terminology, how is called such
 library, etc, is an important issue; of course objects will come in
 logically linked groups. The best way to see which objects to go in which
 groups is just to program them. When we do code, we'll well see what's the
 best place for everything, provided we well did define the proper system
 philosophy (remember the Tao of Programming).
  Also, there's no point at naming a group of objects and then force them to
 be grouped. Objects are just here, linked to others the way that fits best.
 If some routines naturally group (for example, real number routines for a
 same non-hardware implemented format), let them group; if they don't
 (for example object sharing and memory allocation), let them don't.
 Let's not put arbitrary borders between modules, and then see conflict
 emerge between them, but mostly inside them (as europeans, mostly french ;-(
 and english men, did when leaving Africa)


 And as for MOOSE being a programmer's system, not a user's system, I'd say
that there's no fundamental difference between a programmer and a user:
there  are only  higher or lower level, more or less specialized users.

	   ,
	Fare

From gumby.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sat Mar 13 14:47:48 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19070; Sat, 13 Mar 93 14:47:46 +0100
Return-Path: <gumby.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sat, 13 Mar 93 14:47:46 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09468; Sat, 13 Mar 93 05:45:29 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa15836; 13 Mar 93 8:42 EST
Received: from gumby.cis.udel.edu by sol.cis.udel.edu id aa25353;
          13 Mar 93 13:37 GMT
Received: from sol.cis.udel.edu by gumby.cis.udel.edu id aa29115;
          13 Mar 93 13:36 GMT
To: Moose Project <moose-programmers@sfu.ca>
Subject: Re: Co-ordination languages ... 
In-Reply-To: Your message of "Sat, 13 Mar 93 23:09:58 EST."
             <9303131309.430@mulga.cs.mu.OZ.AU> 
Date: Sat, 13 Mar 93 08:36:22 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303131336.aa29115@gumby.cis.udel.edu>
Status: OR

=>What I would like to propose based on this is NOT that we adopt linda but rat
her
=>that we use it's simplicity as a guide in seeking a single unifying 
=>concept encompassing files, inter application communication and inter machine
=>communication.
=>
=>Since an OS defines a coordination language we can implement this concept as
=>a conventional OS -- the problem with current OSes is that they use many 
=>seperate concepts for these things (eg., files., shared memory, RPC etc.)

   Yes!!!!!!!!!!!!!!!!!!!

=>Michael Winikoff
=>winikoff@cs.mu.oz.au
=>Computer science honours. University of Melbourne, Australia.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Sat Mar 13 15:31:57 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20155; Sat, 13 Mar 93 15:31:56 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 13 Mar 93 15:31:56 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA10055; Sat, 13 Mar 93 06:28:33 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA01391
	Sun, 14 Mar 1993 00:28:27 +1000 (from winikoff)
Date: Sun, 14 Mar 1993 00:28:27 +1000
From: Michael David WINIKOFF <winikoff@cs.mu.OZ.AU>
Message-Id: <9303131428.1391@mulga.cs.mu.OZ.AU>
To: moose-programmers@sfu.ca
Subject: OO OS?
Status: OR

Yo guys!
Found this in comp.os.research ...

---------- CUT HERE -----------
In article <C3sH08.H6x@cs.mcgill.ca>, sunny@cs.mcgill.ca (Roxanne CHARLEBOIS) writes:
%% What makes an OS Object Oriented?
%% 
%% Romulus.
%% sunny@binkley.cs.mcgill.ca
%% 
%% P.S. I do understand OO, but I want to know how an OS is OO. 


This is an answer both to this question and the various comments
and questions about Chorus and COOL.


Firstly, Chorus:

The CHORUS micro-kernel is written in C++. The multi server MiX (ie UNIX)
system is a mix of Chorus code and USL code. There are 5 main servers,
a process manager that takes traps, deals with process related calls
and farms out other requests to the other servers. The PM is pure
Chorus code and written in C++. There is an object manager, which is
actually a file system server - it is mainly USL code and written in C.
A SVRV streams manger deals with the streams stuff, there is a key manager
and an IPC manager which are mainly USL code and so C.

COOL, the Chorus object oriented layer is a system designed to support
distributed object oriented languages. It works by extending the micro-kernel
abstractions with abstractions better suited to distributed OO systems.
These abstractions provide support for objects as simple encapsulations
of code and data, dynamic link/load of objects, invocation among objects
in a distributed environment, persistence of objects and migration of
objects between address spaces and machines.

The system is layered, and provide an upcall interface that allows language
level run-times to interface to the underlying support. We have concentrated
C++, so that we offer a C++ environment that supports all of the features
mentioned above.

COOL v2 runs alongside MiX as a 'seperate' OS personality, however it is not
a full OS, but uses MiX services, eg the file store (this is for resource
reasons - building a complete OS from scratch is a big task :-)

We are currently looking at how we can use the COOL services to build OS
functionality, and your going to hate this, how we can use COOL to help
build a better UniX. We are doing this work with USL.

Details on CHORUS, MiX and COOL are available via anonymous ftp from

	opera.chorus.fr
	cse.ogi.edu

As far as Object oriented operating systems are concerned most of the answers
to your questions can be found in the proceedings of "the international
workshop on object orientation in operating systems (IWOOOS)" There are
2 (maybe 3) procedings. IEEE press order number 2265 for '91 and 3015 for '92.

Basically an OO OS can:

	o be built in an OO way, eg OO languages etc, but offer a traditional
	OS interface (Unix perhaps) and no support for OO apps. This is 
	basically only of interest to the system builder as it makes
	development/maintainence and update eaisier. The work we do with USL
	is looking to see if this is worthwhile.

	o be built in a traditional way eg non OO language, but have an
	OO like interface. This is mainly of interest to app developers
	and makes their world look a little cleaner. I think Cairo hopes
	to do this for windows. The semantic gap between the language model
	and the system abstractions still remains the same.

	o Is built in one of the two ways above, but is designed to
	support objects, ie the supported paradigm for application
	development is object oriented. There are many people doing
	this, the COOL project is just one. Our overriding interest
	is that the OO paradigm is a good one for building distributed
	systems. We hope to reduce the semantic gap, so that the mapping
	of programming model to system abstractions is easier, more
	efficient, and integrated.

I refer you to the IWOOOS proceedings for more info.

rodger lea

chorus 
-- 
Software Engineering: Quality through Deforestation.
Michael Winikoff	| "If you know what you're doing    |	Musician
winikoff@cs.mu.oz.au	| 	-- it ain't research"       |	Amiga 500 Owner
Computer science honours. University of Melbourne, Australia. 	Role Player

From uunet.UU.NET!davgar!david Sat Mar 13 22:06:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28041; Sat, 13 Mar 93 22:06:25 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Sat, 13 Mar 93 22:06:25 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA02399; Sat, 13 Mar 93 16:06:27 -0500
Received: from davgar.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 160457.615; Sat, 13 Mar 1993 16:04:57 EST
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR5);
           Sat, 13 Mar 1993 13:46:18 EST
Date:      Sat, 13 Mar 1993 13:46:12 EST
From: (David Garfield) uunet.UU.NET!davgar!david
Message-Id: <2ba22bfc.davgar@davgar.UUCP>
Organization: Third Star on the Left
To: "Francois-Rene Rideau" <rideau@clipper>
Subject:   Re: memory allocation (djg4)
Status: OR

On Sat, 13 Mar 93 11:29:03 MET, "Francois-Rene Rideau"
<rideau@clipper.ens.fr> wrote:
>
> >> I firmly believe that at the kernel level, a malloc() style memory
> >> allocation interface should not exist.  Using malloc() does not allow
> >> any chance for the application to control where the memory blocks are
> >> placed.
>  There should be different memory managers for all devices/apps/user
> programs to match their need. For example very high-level programs
> often need a garbage collecting feature, whereas low-level programs
> would be only slowed by it. If you don't implement a GC memory manager,
> each app will have to do its own, and inter-app object communication
> will be made impossible or very, very difficult and slow. If you always
> require GC compliancy, that will slow everything, and affect the system
> security.
>  To me, there should not be only ONE memory manager. Memory management is
> not a Kernel feature; there are higher or lower level devices to manage
> memory; but they have a standard interface, so that you don't need know
> what's its memory manager to access an object.
>  We can even build generic memory managers, to transform a low-level
> one into a higher-level one by adding each time some features.
>  So we start with physical memory, add virtual memory, add word aligned
> blocks, add GC, etc. Each time, you can add it in part of the previous
> manager; you can add it several times in different parts of the manager;
> etc.

I couldn't agree more.  My argument is that the lowest level memory
manager should not be a malloc() style interface.  The malloc() style
interface is the second or third level.  Dennis in his initial design
had proposed a malloc style interface in the kernel, and I felt a need
to oppose this.

> 		   ,
> 		Fare

I also oppose the use of tab characters in anything seen by more than
one system/user.  Too many PC based software packages change the tab
stops.  Oh for the days of the VT100 when nobody changed tab stops.

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From uunet.UU.NET!davgar!david Sat Mar 13 23:16:04 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29329; Sat, 13 Mar 93 23:16:03 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Sat, 13 Mar 93 23:16:03 +0100
Received: from relay1.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA01323; Sat, 13 Mar 93 16:05:10 -0500
Received: from davgar.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 160458.620; Sat, 13 Mar 1993 16:04:58 EST
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR5);
           Sat, 13 Mar 1993 14:10:21 EST
Date:      Sat, 13 Mar 1993 14:10:17 EST
From: (David Garfield) uunet.UU.NET!davgar!david
Message-Id: <2ba2319f.davgar@davgar.UUCP>
Organization: Third Star on the Left
To: "Francois-Rene Rideau" <rideau@clipper>
Subject:   Re: Obj. Sharing (djg3) far17
Status: OR

On Sat, 13 Mar 93 11:14:57 MET, "Francois-Rene Rideau"
<rideau@clipper.ens.fr> wrote:
> >> A possible means of making data objects available to other processes:
> >>
> >> It is possible for
> >>
> >>    1) All processes to be objects.
> >>    2) Objects to be in the logical file system.
> >>    3) Objects themselves be asked what objects are below them in the
> >>       file system.
>
> I think we agree, but I'd like to modify what you said:
> 1) EVERYTHING is an object; processes in particular.

agreed.

> 2) I'd rather say the file system is included in the object system
> (objects are files is the unix philosophy: you have only files,
> and even to send/receive one integer number, you are bound to
> use a (preferably ASCII) file).

Either the file system is the object system or the object system is
the file system.  Either way they are the same thing.  Which one
doesn't really matter.

> >> With this setup, each process object is placed in the logical file
> >> system.  Each process object may then be queried as to what public
> >> objects it contains.  If a process is a 'dumb' program, this would
> >> probably mean either nothing is public or a fixed list is public.  A
> >> 'smart' program could either published all its objects or a portion of
> >> its object list it selects.
> The FS directory equivalent becomes what I previously called the dictionary.
> You can even publish part of an object, that is, only part of its methods
> are available. As each object has its dictionary, you can publish different
> things to each of them.
>
> >> As an additional capability, a 'smart' program could have objects
> >> placed into the directory that it provides by other programs.  This
> >> could be used as a means of specifically requesting communications
> >> with a process.
> I'm not sure of understanding what you said, but modifying an object
> in a dictionary is a sure means of communication to all those who
> read this dictionary. Also see my discussion with Peter Mueller about
> naming.

This point is that program A can place object B into the directory
provided by program C.  Thus dictionaries may be written to by things
other than their provider.  Of course, the directory provider will
have to manage (and allow in the first place) the placement of an
object into it by a foreign process.

>
> >> Additionally, if an object can be placed in one place in the file
> >> system, it can be placed in other 'known' places, allowing for the
> >> publication of objects.
> That's the multiple dictionaries I ask for.

ok.  Directories/Dictionaries must also be hierarchical.

>
> >> One other capability allowed by mapping between directories and
> >> objects is that something like a ZIP file (produced by PKZIP or the
> >> like) could allow its contents to be directly accessed as a file.
> >> Mapping between different styles of file systems could happen the same
> >> way (assuming you want to nest filesystems).
> Dictionaries should be a virtual object class, with standard methods, then
> anyone could implement a new way of accessing objects. They also should
> have a recursive definition, so that dictionaries can be part of another,
> and there's no problem in mixing dictionary methods.

Actually, I almost think that the abstract directory class is the base
of the object hierarchy.

>
> >> Note on terms:  I am using the term 'logical file system' to refer to
> >> the effective file system that exists when the system is running.  In
> >> Unix this is composed of the the root file system and any file systems
> >> and network file systems mounted on it.  In the case of Moose, the
> >> logical file system will (I hope) also include objects and other
> >> things.
> Each of us has his own terminology, inherited from his past experiences
> and thinkings about computing. Let's not fight for names.
> But if I prefer the object terminology to the file terminology, it's because
> under existing systems, files are a closed inextensible system, with a
> unique implementation oriented toward big file managing. Objects are
> a generic extensible concept, which includes huge structures as well as
> basic data.

I defined my terms so that everyone else would know what I was talking
about.  I expect everyone to know what I mean when I say 'file
system', but will they know just what I mean when I say 'logical file
system'?  I have no objection to using the object terminology, but
will argue that they should be equivalent in implementation.  I would
argue that we should support files as objects, and that files/objects
should have all kinds of varied capabilities.

>
> >> --
> >> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> >> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com
>
>    ,
> Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
> 45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
> rideau@clipper.ens.fr
>

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From winikoff@cs.mu.OZ.AU Sat Mar 13 14:12:33 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18399; Sat, 13 Mar 93 14:12:32 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 13 Mar 93 14:12:32 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09058; Sat, 13 Mar 93 05:10:05 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA00430
	Sat, 13 Mar 1993 23:09:58 +1000 (from winikoff)
Message-Id: <9303131309.430@mulga.cs.mu.OZ.AU>
Subject: Co-ordination languages ...
To: moose-programmers@sfu.ca (Moose Project)
Date: Sat, 13 Mar 93 23:09:58 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

Hi people!
I've just read the co-ordination paper (CACM, Feb 1992) and have followed the
debate backwards (April and OCtober 1989 CACMs)

The coordination language proposed in the paper is Linda.

Linda has the following primitives:

out(tuple) in(tuple) rd(tuple) inp(tuple) rdp(tuple) eval(tuple)

out places a tuple into "tuple space"
in gets a tuple from tuple space.
Note that in uses a form of pattern matching:

eg.

out("V",1,sqrt(4))
in("V",? i, ? f)

f is assigned to 2 and i to 1.

in removes the tuple whereas rd doesn;t.
The "p" versions of in and rd (read) return imediately if there is no such tuple
available whereas "in" and "rd" suspend.

eval creates a process to evaluate the tuple b4 outing it.

eg.
out(some_fun(3)) will evaluate some_fun then do the out.
eval(some_fun(3)) will return immediately, some_fun will be evaluated in a new
process and when completed the tuple will be available.

THe debate was centered about parallelism -- mostly irrelevant for our purposes.

The points that concern us are:
(1) Linda enables cross language work.
(2) An OS defines a co-ordination language.
(3) A coordination language is a uniform framework for inter application, 
inter time (ie. communicating with future programs -- normally done through
files) and I/O
(4) there is a problem with having a single tuple space -- The people working
on Linda have defined multiple tuple spaces and ways of treating them as first 
class.

What I would like to propose based on this is NOT that we adopt linda but rather
that we use it's simplicity as a guide in seeking a single unifying 
concept encompassing files, inter application communication and inter machine
communication.

Since an OS defines a coordination language we can implement this concept as
a conventional OS -- the problem with current OSes is that they use many 
seperate concepts for these things (eg., files., shared memory, RPC etc.)

Michael


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Sat Mar 13 14:32:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18725; Sat, 13 Mar 93 14:32:32 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 13 Mar 93 14:32:32 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09309; Sat, 13 Mar 93 05:30:10 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA00699
	Sat, 13 Mar 1993 23:30:06 +1000 (from winikoff)
Message-Id: <9303131330.699@mulga.cs.mu.OZ.AU>
Subject: Re: KER, obj (was Re:  KER, win)
To: moose-programmers@sfu.ca (Moose Project)
Date: Sat, 13 Mar 93 23:30:05 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303121824.AA00860@tdge15.intel.com>; from "Dennis Marer" at Mar 12, 93 10:24 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> > Hi! 
> > I've knocked up a sketch for a simple kernel.
> > I've currently left out virtual memory and object support simply 
> > because virtual memory seems to be dependant on how we do objects and
> > we haven't reached a consensus (or even an understanding yet!) on objects.
> 
> Great - we'll be looking forward to seeing that!
> 
> Q: Why is virtual memory considered dependant on how we do objects?  Maybe I
>    missed that discussion...

Something Fare' said about objects being small and this conflicting with 
the page as the smallest unit of VM/protection.

I'm not quite certain so I'm playing it safe.

> 
> The structure of an object needs to be clearly defined by the kernel: how it
> stores the attributes (data) associated with an object, how polymorphism
> affects the virtual method tables (VMT) of an object, especially in the case
> of multiple inheritance, and so on.  Also, this definition of an object needs
> to be useful to all languages...this is a tall order to fill!
> 

I still feel uncomfortable about defining such features as polymorphism 
at a level where they will be so hard to change -- surely there is no one
universally used model of objects/polymorphism etc. ...



--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Sat Mar 13 14:37:36 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18832; Sat, 13 Mar 93 14:37:35 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 13 Mar 93 14:37:35 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09355; Sat, 13 Mar 93 05:35:08 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA00738
	Sat, 13 Mar 1993 23:35:04 +1000 (from winikoff)
Message-Id: <9303131335.738@mulga.cs.mu.OZ.AU>
Subject: Libraries
To: moose-programmers@sfu.ca (Moose Project)
Date: Sat, 13 Mar 93 23:35:03 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

Hi!

I think that having the seperate concepts of module, library and object 
is overkill. Can't we merge these into a single concept and simplify life?

Michael


From winikoff@cs.mu.OZ.AU Sat Mar 13 15:17:41 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19887; Sat, 13 Mar 93 15:17:40 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 13 Mar 93 15:17:40 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09839; Sat, 13 Mar 93 06:15:17 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA01197
	Sun, 14 Mar 1993 00:15:11 +1000 (from winikoff)
Message-Id: <9303131415.1197@mulga.cs.mu.OZ.AU>
Subject: Ker, win 
To: moose-programmers@sfu.ca (Moose Project)
Date: Sun, 14 Mar 93 0:15:11 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

Hi everyone -- as promised my sketch for a simple kernel.
feel free to flame, comment, criticise, compliment (:-) or suggest additions
or changes.


The kernel has the following system calls:

contextswitch()
pid = self()
pid = spawn(ptr to code, ptr to stack, initial pc)
kill(pid)

send(pid, message)
mesg = receive()
bool = poll()

ptr = alloc(size)
free(ptr, size)

reqid = service(devid, service_number, ptr to result/arg buffer, flags)
bool = ready(reqid)

getdev(devid, service_number, var pid, var code)
setdev(devid, service_number, pid, code)


-----
contextswitch: Calls the scheduler. This is not likely to be used from within
user code.

self: Returns the current process/task's id, useful for exit() = kill(self())
[And also for sending messages to self. ??]

spawn -- this creates another task/process.
The details here are very hazy. The current call is meant to be very light
weight -- all it does is add an entry in the scheduler, allocating the memory,
loading the code (and setting up virtual memory) is done somewhere else.

send and receive work as expected (rec. blocks if no message is available.
It is an open question whether we have a buffer and if so how large is it
-- or possibly unbounded?)

A comment on messages: Sending large message raises issues.
We can either just copy them or fiddle with address spaces so they're accessible.
(possibly using copy on write??)

Currently think of mesg as being a single atomic value. 
This can be a pointer -- setting up he VM / copying data can be done elsewhere.

poll returns TRUE if there is a waiting message.

allocate and free dish out (physical) memory. 

The kernel has a device table. This is simply a mapping from
(devid, service_number) to (pid, code)

The system call "service" looks up the appropriate location and calls the
result process passing on the code.

Note that service is asynchronous -- it returns a reqid.
This can be used for determining when the operation has been carried out.
I feel that asynchronous IO is better in that you can simulate sunchonous 
IO using it but not the other way around (at least not without creating extra
processes ...)

One of the flags to the device could be whether the process wishes a message
to be sent to it when the operation has been carried out.

The caller could do:

reqid = service(....)
a:
mesg = receive(...)
IF not(ready(reqid)) THEN
	remember mesg
	GOTO a
ENDIF
getdev and setdev are used for querying the table and for changing it.
Obviously some notion of priviliege is needed -- we don't want all processes
to be able to read and modify the dev-table.

I'd envisage devicees as being reasonably high levelinterfaces to hard ware.

Eg the disk would provide seek, block read and block write but not a file system

Some devices include:
	disk (floppy and hard), ports (serial and parallel)
	clock, screen, sound, mouse, joystick, keyboard.


-------
An initial "shell" could be a program that lets you make system calls ...
This would be more like a system debugger/monitor ...

-------

A sample implementation
~~~~~~~~~~~~~~~~~~~~~~~~~

Note: This is (very!) simplistic. 
It illustrates one possible implementation.

There is a ticker that generates an intterupt every n milliseconds.
(how else can you do preemption? :-)

THis forces a call to contextswitch()

The scheduler can use simple round robin 

Process table:

next_free
running-process

for each process:
	state: waiting / ready / running / invalid
	pid: int
	pc
	registers
	current message
	message valid : bool

----------
IMPORTANT: Except when a system call has a call to contextswitch it will
be assumed to run atomically.
(eg. on a single procesor implementation system calls disable interupts)

contextswitch: changes state of running-process to ready
	finds next ready process, sets it to running, sets running-process
	to it.
	load registers and pc.

kill: removes an entry from the table (set state to invalid)

self: return running-process

spawn: Find an invalid entry. Change it to ready and initialise it

send: 
	a:
	if target of send is invalid return error
	if the message_valid is false then
		message_valid = true
		current_message = mesg (passed as argument to call)
		return
	else
		contextswitch()
		goto a
	endif
	
	/* note that we don't have a facility for waiting. 
	** due to the context switch this should be reasonable efficient.
	** if message sending is a bottleneck we should have a queue of 
	** messages rather then a single entry
	*/

receive:
	if message_valid then
		message_valid = false
		return current_message
	else
		state = waiting
		contextswitch()
	endif

poll: return message_valid

-----
Memory allocation:

A simple way of managing memory is with a bitmap.
If we have 1 bit = 1K byte then the amount of memory taken by the bitmap is
0.1% -- this is fine if we are managing physical memory.

alloc(size) 
	round size upto next kilobyte
	search bitmap for next free chunk of that size
	set the region to taken
	return pointer

free(ptr,size)
	reset bits in bitmap

Note: We can't compact physical memory without using virtual memory ...

-----

We also have a device table.
The "ready" call could be implemented either in the kernel or  in the device
drivers.



--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From rideau@clipper Mon Mar 15 06:04:04 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19338; Mon, 15 Mar 93 06:04:02 +0100
Return-Path: <rideau@clipper>
Received-Date: Mon, 15 Mar 93 06:04:02 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24663; Sun, 14 Mar 93 21:01:10 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19279; Mon, 15 Mar 93 06:01:01 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303150501.AA19279@clipper.ens.fr>
Subject: Re: Ker, win far20
To: winikoff@mulga.cs.mu.OZ.AU (Michael David WINIKOFF)
Date: Mon, 15 Mar 93 6:00:59 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <9303131415.1197@mulga.cs.mu.OZ.AU>; from "Michael David WINIKOFF" at Mar 14, 93 12:15 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR


>> Hi everyone -- as promised my sketch for a simple kernel.
>> feel free to flame, comment, criticise, compliment (:-) or suggest additions
>> or changes.

I fear it's only going to be flames from me ;-( !

>> The kernel has the following system calls:
>> 
>> contextswitch()
>> pid = self()
>> pid = spawn(ptr to code, ptr to stack, initial pc)
>> kill(pid)

>> send(pid, message)
>> mesg = receive()
>> bool = poll()

>> ptr = alloc(size)
>> free(ptr, size)
>> 
>> reqid = service(devid, service_number, ptr to result/arg buffer, flags)
>> bool = ready(reqid)
>> 
>> getdev(devid, service_number, var pid, var code)
>> setdev(devid, service_number, pid, code)

 AAARRRRGGGGHHHHH !!!!!!
 This is *-disoriented unix-like stuff ! That should have nothing to do in
a structured object-oriented OS !
 If that had to be like that, we wouldn't need anymore Moose Kerneling:
we'd only have to use existing unix kernel (well, why not after all ?) !!!
(if standard unix isn't satisfying, there are plenty of unix enhanced clones
existing !)

- contextswitch():
 it's up to the system, not objects (processes) to decide whether to switch
context. In a massively parallel architecture, there may be no switch at all.
Processes can have a "Wait" primitive, but contextswitching is a kernel
problem.

- self()
 generically, objects may know of themselves; the self() call for processes
should only be a particular instance of self() for any object.

- spawn()
 cough cough cough !!! Warf !!!
 Sorry, I just couldn't digest it !
 "spawn" was a C add-up to make allow parallelism in an unstructured language
(where thread-private data couldn't exist, everything being global !). It
only allows auto-calling (very stupid). Such a horror shouldn't exist in
the kernel.

- send(),receive(),poll()
 ok for sending and receiving mechanisms; but again, why only for processes;
any object may receive messages; or else, every object would have to be a
process (why not then ?).
But what would the mesg type be ? I hope that won't be only strings or
(worse !) numbers ! Let's send/receive objects. Pattern matching will be
done to separate objects.
Polling can also be done by receiving in a sub-thread. (but having it standard
is good). We may even make poll and receive atomic in some cases.

- alloc(), free().
 No ! see what I said about memory management (also see farther)

- service(), ready()
 Why particularize system services and have many varying syntaxes ?
Let's have only objects. System objects which are the lowest-level objects
will have the same access as other.

-  getdev(),setdev()
 Why have devices ?
 Devices are a new kind of object you bring about when you see your
traditional OS concepts couldn't manage something (unix, thus dos: files
can't manage anything, they're just data; devices are just read/write
code).
 In a OO OS, objects are what the system manages, and they are both
data and code (I'd even like that we end differentiating each from the
other), so we don't need to have a special concept as devices. What was
called "devices" in previous messages was only low-level objects that
would most probably be written in assembler or compiled from a low-level
language (like C, for ex.). We'll have low-level objects as we'll have
higher-level objects, in the object dictionaries.


>> -------
>> An initial "shell" could be a program that lets you make system calls ...
>> This would be more like a system debugger/monitor ...
Any interactive object is a "shell"; If we provide standard LLL, a LLL
interpreter could be the first bootstrap shell.
e
>> -------
[I won't talk about the implementation, as I can't agree with the kernel]

>> Memory allocation:
>> 
>> A simple way of managing memory is with a bitmap.
>> If we have 1 bit = 1K byte then the amount of memory taken by the bitmap is
>> 0.1% -- this is fine if we are managing physical memory.
>> 
>> alloc(size) 
>> 	round size upto next kilobyte
>> 	search bitmap for next free chunk of that size
>> 	set the region to taken
>> 	return pointer
>> 
>> free(ptr,size)
>> 	reset bits in bitmape
>> 
>> Note: We can't compact physical memory without using virtual memory ...

 I don't agree at all with this either. See my previous messages about a
multi-layer memory management, and a kernel that is/does but inter-object
communication.
 Also, optimal base memory block size depends mostly on the hardware (must
be 4KB on the intel, 8KB on the SPARC, 256B on some 8 bit machines, etc).
So let's have it implementation dependant.

>> ----------------------------------------------------------------------
>> Michael Winikoff
>> winikoff@cs.mu.oz.au
>> Computer science honours. University of Melbourne, Australia.
>> 

As I destroyed all that, I must show I can also construct. So I will
soon post something (quick, then certainly full of errors) about how I
envision things in an OO OS.


	   ,
	Fare
Student (?) at the Ecole Normale Superieure, Paris

P.S.
- my tabs can't hurt, as there's the same number of tabs at the
two lines, and they begin the line; so I whatever size tabs are,
it's ok. (but next time, I promise I won't put tabs)
- beware of 80 columns non scrolling displays and multi-quoting !
if you use more than, say, 70 columns in your texts, your quoted
message won't display correctly/cleanly !


From rideau@clipper Mon Mar 15 06:25:05 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20650; Mon, 15 Mar 93 06:25:04 +0100
Return-Path: <rideau@clipper>
Received-Date: Mon, 15 Mar 93 06:25:04 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25068; Sun, 14 Mar 93 21:22:13 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20596; Mon, 15 Mar 93 06:22:12 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303150522.AA20596@clipper.ens.fr>
Subject: Did you receive far18,19,20 ?
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Mon, 15 Mar 93 6:22:09 MET
X-Mailer: ELM [version 2.3 PL11]
Status: OR

 Hello happy moosers !
 I have problems with my mailing to you:
my mails are returned, so I don't know if you received my previous
moose contributions.
 Perhaps you did receive them more than once because I tried several times !
So excuse me if I encumbered your mailboxes, and please ACKnowledge if you
received it. (Just replying, and add your name/plan ?)



Here are three sample error headers, separated by a line.
If someone can help explain my mistakes and how to neext mail properly,
I thank him for his explaining !

-----------------------------------------------------------------------------
Message 3/18  From Mail Delivery Subsystem            Mar 13 '93 at 5:15 am -300

Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Date: Sat, 13 Mar 93 05:15:07 -0500
Subject: Returned mail: Host unknown
To: <rideau@clipper>
Sender: rideau@clipper

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
        (5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
        id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]




------------------------------------------------------------------------------

From rideau@clipper Mon Mar 15 02:07:24 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09064; Mon, 15 Mar 93 02:07:23 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19427; Sun, 14 Mar 93 17:04:10 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08997; Mon, 15 Mar 93 02:04:02 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08634; Mon, 15 Mar 93 01:45:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18839; Sun, 14 Mar 93 16:41:03 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08559; Mon, 15 Mar 93 01:40:50 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07210; Mon, 15 Mar 93 00:35:59 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17084; Sun, 14 Mar 93 15:32:23 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07132; Mon, 15 Mar 93 00:32:16 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14520; Sat, 13 Mar 93 11:15:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20271; Sat, 13 Mar 93 05:15:07 -0500
Date: Sat, 13 Mar 93 05:15:07 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131015.AA20271@relay2.UU.NET>
To: <rideau@clipper>
Sender: rideau@clipper
Status: OR

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]


>> A possible means of making data objects available to other processes:
>> 
>> It is possible for
>> 
>>    1) All processes to be objects.
>>    2) Objects to be in the logical file system.
>>    3) Objects themselves be asked what objects are below them in the
>>       file system.

I think we agree, but I'd like to modify what you said:
1) EVERYTHING is an object; processes in particular.
2) I'd rather say the file system is included in the object system
(objects are files is the unix philosophy: you have only files,
and even to send/receive one integer number, you are bound to
use a (preferably ASCII) file).

>> With this setup, each process object is placed in the logical file
>> system.  Each process object may then be queried as to what public
>> objects it contains.  If a process is a 'dumb' program, this would
>> probably mean either nothing is public or a fixed list is public.  A
>> 'smart' program could either published all its objects or a portion of
>> its object list it selects.
The FS directory equivalent becomes what I previously called the dictionary.
You can even publish part of an object, that is, only part of its methods
are available. As each object has its dictionary, you can publish different
things to each of them.

>> As an additional capability, a 'smart' program could have objects
>> placed into the directory that it provides by other programs.  This
>> could be used as a means of specifically requesting communications
>> with a process.
I'm not sure of understanding what you said, but modifying an object
in a dictionary is a sure means of communication to all those who
read this dictionary. Also see my discussion with Peter Mueller about
naming.

>> Additionally, if an object can be placed in one place in the file
>> system, it can be placed in other 'known' places, allowing for the
>> publication of objects.
That's the multiple dictionaries I ask for.

>> One other capability allowed by mapping between directories and
>> objects is that something like a ZIP file (produced by PKZIP or the
>> like) could allow its contents to be directly accessed as a file.
>> Mapping between different styles of file systems could happen the same
>> way (assuming you want to nest filesystems).
Dictionaries should be a virtual object class, with standard methods, then
anyone could implement a new way of accessing objects. They also should
have a recursive definition, so that dictionaries can be part of another,
and there's no problem in mixing dictionary methods.

>> Note on terms:  I am using the term 'logical file system' to refer to
>> the effective file system that exists when the system is running.  In
>> Unix this is composed of the the root file system and any file systems
>> and network file systems mounted on it.  In the case of Moose, the
>> logical file system will (I hope) also include objects and other
>> things.
Each of us has his own terminology, inherited from his past experiences
and thinkings about computing. Let's not fight for names.
But if I prefer the object terminology to the file terminology, it's because
under existing systems, files are a closed inextensible system, with a
unique implementation oriented toward big file managing. Objects are
a generic extensible concept, which includes huge structures as well as
basic data.

>> -- 
>> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
>> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

   ,
Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
rideau@clipper.ens.fr





From rideau@clipper Mon Mar 15 02:07:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09068; Mon, 15 Mar 93 02:07:25 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19441; Sun, 14 Mar 93 17:04:34 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09000; Mon, 15 Mar 93 02:04:28 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08659; Mon, 15 Mar 93 01:45:55 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18842; Sun, 14 Mar 93 16:41:13 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08562; Mon, 15 Mar 93 01:41:06 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14774; Sat, 13 Mar 93 11:29:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:29:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA21241; Sat, 13 Mar 93 05:29:08 -0500
Date: Sat, 13 Mar 93 05:29:08 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131029.AA21241@relay2.UU.NET>
To: <rideau@clipper>
Sender: rideau@clipper
Status: OR

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA21226; Sat, 13 Mar 93 05:29:08 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14771; Sat, 13 Mar 93 11:29:04 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131029.AA14771@clipper.ens.fr>
Subject: Re: memory allocation (djg4)
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:29:03 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9aed66.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 1:53 am
X-Mailer: ELM [version 2.3 PL11]


>> I firmly believe that at the kernel level, a malloc() style memory
>> allocation interface should not exist.  Using malloc() does not allow
>> any chance for the application to control where the memory blocks are
>> placed.
 There should be different memory managers for all devices/apps/user
programs to match their need. For example very high-level programs
often need a garbage collecting feature, whereas low-level programs
would be only slowed by it. If you don't implement a GC memory manager,
each app will have to do its own, and inter-app object communication
will be made impossible or very, very difficult and slow. If you always
require GC compliancy, that will slow everything, and affect the system
security.
 To me, there should not be only ONE memory manager. Memory management is
not a Kernel feature; there are higher or lower level devices to manage
memory; but they have a standard interface, so that you don't need know
what's its memory manager to access an object.
 We can even build generic memory managers, to transform a low-level
one into a higher-level one by adding each time some features.
 So we start with physical memory, add virtual memory, add word aligned
blocks, add GC, etc. Each time, you can add it in part of the previous
manager; you can add it several times in different parts of the manager;
etc.
		   ,
		Fare





From MAILER-DAEMON@eos03a.eos.ncsu.edu Mon Mar 15 02:08:22 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09079; Mon, 15 Mar 93 02:08:20 +0100
Return-Path: <MAILER-DAEMON@eos03a.eos.ncsu.edu>
Received-Date: Mon, 15 Mar 93 02:08:20 +0100
Received: from eos03a.eos.ncsu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by eos03a.eos.ncsu.edu (5.65b/eos-server.920426)
	id AA21761; Sun, 14 Mar 93 20:07:53 -0500
Date: Sun, 14 Mar 93 20:07:53 -0500
Subject: Returned mail: Service unavailable
From: MAILER-DAEMON@eos03a.eos.ncsu.edu (Mail Delivery Subsystem)
Posted-Date: Sun, 14 Mar 93 20:07:53 -0500
Message-Id: <9303150107.AA21761@eos03a.eos.ncsu.edu>
To: rideau@clipper
Status: OR

   ----- Transcript of session follows -----
While talking to eos06a.eos.ncsu.edu:
>>> DATA
<<< 554 sendall: too many hops 18 (17 max): from <rideau@clipper.ens.fr>, to rideau@clipper.ens.fr
554 <dspascha@eos.ncsu.edu>... Service unavailable

   ----- Unsent message follows -----
Received: from whistler.sfu.ca by eos03a.eos.ncsu.edu (5.65b/eos-server.920426)
	id AA21749; Sun, 14 Mar 93 20:07:53 -0500
Posted-Date: Sat, 13 Mar 93 05:15:07 -0500
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19427; Sun, 14 Mar 93 17:04:10 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08997; Mon, 15 Mar 93 02:04:02 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08634; Mon, 15 Mar 93 01:45:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18839; Sun, 14 Mar 93 16:41:03 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08559; Mon, 15 Mar 93 01:40:50 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07210; Mon, 15 Mar 93 00:35:59 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17084; Sun, 14 Mar 93 15:32:23 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07132; Mon, 15 Mar 93 00:32:16 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14520; Sat, 13 Mar 93 11:15:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20271; Sat, 13 Mar 93 05:15:07 -0500
Date: Sat, 13 Mar 93 05:15:07 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131015.AA20271@relay2.UU.NET>
To: <rideau@clipper.ens.fr>
Sender: rideau@clipper.ens.fr

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]


>> A possible means of making data objects available to other processes:
>> 
>> It is possible for
>> 
>>    1) All processes to be objects.
>>    2) Objects to be in the logical file system.
>>    3) Objects themselves be asked what objects are below them in the
>>       file system.

I think we agree, but I'd like to modify what you said:
1) EVERYTHING is an object; processes in particular.
2) I'd rather say the file system is included in the object system
(objects are files is the unix philosophy: you have only files,
and even to send/receive one integer number, you are bound to
use a (preferably ASCII) file).

>> With this setup, each process object is placed in the logical file
>> system.  Each process object may then be queried as to what public
>> objects it contains.  If a process is a 'dumb' program, this would
>> probably mean either nothing is public or a fixed list is public.  A
>> 'smart' program could either published all its objects or a portion of
>> its object list it selects.
The FS directory equivalent becomes what I previously called the dictionary.
You can even publish part of an object, that is, only part of its methods
are available. As each object has its dictionary, you can publish different
things to each of them.

>> As an additional capability, a 'smart' program could have objects
>> placed into the directory that it provides by other programs.  This
>> could be used as a means of specifically requesting communications
>> with a process.
I'm not sure of understanding what you said, but modifying an object
in a dictionary is a sure means of communication to all those who
read this dictionary. Also see my discussion with Peter Mueller about
naming.

>> Additionally, if an object can be placed in one place in the file
>> system, it can be placed in other 'known' places, allowing for the
>> publication of objects.
That's the multiple dictionaries I ask for.

>> One other capability allowed by mapping between directories and
>> objects is that something like a ZIP file (produced by PKZIP or the
>> like) could allow its contents to be directly accessed as a file.
>> Mapping between different styles of file systems could happen the same
>> way (assuming you want to nest filesystems).
Dictionaries should be a virtual object class, with standard methods, then
anyone could implement a new way of accessing objects. They also should
have a recursive definition, so that dictionaries can be part of another,
and there's no problem in mixing dictionary methods.

>> Note on terms:  I am using the term 'logical file system' to refer to
>> the effective file system that exists when the system is running.  In
>> Unix this is composed of the the root file system and any file systems
>> and network file systems mounted on it.  In the case of Moose, the
>> logical file system will (I hope) also include objects and other
>> things.
Each of us has his own terminology, inherited from his past experiences
and thinkings about computing. Let's not fight for names.
But if I prefer the object terminology to the file terminology, it's because
under existing systems, files are a closed inextensible system, with a
unique implementation oriented toward big file managing. Objects are
a generic extensible concept, which includes huge structures as well as
basic data.

>> -- 
>> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
>> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

   ,
Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
rideau@clipper.ens.fr





From rideau@clipper Mon Mar 15 07:49:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22313; Mon, 15 Mar 93 07:49:24 +0100
Return-Path: <rideau@clipper>
Received-Date: Mon, 15 Mar 93 07:49:24 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26849; Sun, 14 Mar 93 22:46:13 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22257; Mon, 15 Mar 93 07:46:10 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303150646.AA22257@clipper.ens.fr>
Subject: Ker,OOOOOOOOO far21
To: winikoff@mulga.cs.mu.OZ.AU (Michael David WINIKOFF)
Date: Mon, 15 Mar 93 7:46:08 MET
Cc: moose-programmers@sfu.ca (All the happy Moosers !)
In-Reply-To: <9303131330.699@mulga.cs.mu.OZ.AU>; from "Michael David WINIKOFF" at Mar 13, 93 11:30 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR


-- (a) -----------------------------------------------------------
Let me first begin with a reply to Michael, quoting Dennis' reply to him.
The end of the reply will be an introduction to MOOSE's fundamental problem.

>>> Hi!
>>> I've knocked up a sketch for a simple kernel.
>>> I've currently left out virtual memory and object support simply 
>>> because virtual memory seems to be dependant on how we do objects and
>>>  we haven't reached a consensus (or even an understanding yet!) on objects.
>> 
>> Great - we'll be looking forward to seeing that!
>> 
>> Q: Why is virtual memory considered dependant on how we do objects?  Maybe I
>>    missed that discussion...
> 
> Something Fare' said about objects being small and this conflicting with 
> the page as the smallest unit of VM/protection.
> 
> I'm not quite certain so I'm playing it safe.
> 

 Let me confirm. if EVERYTHING is gonna be objects, then we'll have huge
objects (for example, the whole system) as well as tiny objects (for example,
a boolean); so we can't allow object memory allocation done exclusively with
page alignment (which does not mean large object won't be page aligned).
 If only Large and Huge things are really going to be objects, then we're
back to UNIX and its spawns DOS and Windows; and we've gained very little
for a hard work.

>> The structure of an object needs to be clearly defined by the kernel: how it
>> stores the attributes (data) associated with an object, how polymorphism
>> affects the virtual method tables (VMT) of an object, especially in the case
>> of multiple inheritance, and so on.  Also, this definition of an object needs
>> to be useful to all languages...this is a tall order to fill!
>> 
I agree with all that, BUT with VMT: VMT are a way slow both to use objects
and to create them. I'd rather have external descriptors on objects (access
is much slower but much much more generic than with a VMT). Then, the same as
for Peter's name service, you can ask a direct link to an object's method for
frequent use, rather than call it everytime through the long method.


> I still feel uncomfortable about defining such features as polymorphism 
> at a level where they will be so hard to change -- surely there is no one
> universally used model of objects/polymorphism etc. ...

Well, again, you rise the right, deep question.
You also said in your Mar 10 "Re: PLEASE READ THIS ONE" message
(if everybody numbered messages, quoting would be quicker)

>  The part that I find is still unclear is the role of "objects" in the
> system. The rest is a fairly conventional OS -- I'm not saying this is
> bad, if it designed properly (ie. to be simple) it can (and will) be
> exactly what we want -- something that's a pleasure to write applics
> under.
>
> Most of the problems we've had have been with the role of objects.

 Yes, Michael; I'd say that's THE problem we've had. Let's say what we
think should be the role of objects in the system (and I fear that's
where we may disagree), for its the ESSENTIAL question you asked we
answered in a previous message.
 We all talked about objects, everyone having his idea about it. Now
it appears that we must clarify our mutual ideas, for if we're not
talking about the same thing, we can never agree (or even disagree !),
just talk each for himself.

------------------------------------------------------------------------

 In older manuals, objects were define as an embedding of code and data.
Now, I will rather say that code and data are different aspects of objects.
 Objects are a unifying scheme in computer science. Some call it schemes,
others call it functions, some may call it God, etc. The fact is we can
seek unity in computer programming (code and data or yin and yang aspects
of the Tao; one feeds from the other).
 This unity was broken when (micro)processors were built so complicated,
that code to handle data was as foreign to data as data to represent code
was from machine code.
 But unity was rediscovered, and may be achieved again.

 Object are everything; everything is an object. Unix tried to say that files
are everything, that everything could be done with a file; but Unix files
were thus implemented that only big objects could be efficiently represented
that way; and Unix didn't provide any code embedding with this data; and Unix
forced people to access data through strings. So that the system wasn't a
unified system.

 There came MOOSE, which raised hope among young programmers. It at last
was a unified system. But it wasn't a closed unenhanceable, unextensible
system. It provided generic polymorphic object managing: objects were
implemented through descriptors who themselves were objects. Objects had
a recursive definition, so that the only basic code/data was a convention
on how to code objects so that others are aware of it and its methods.

 Objects had basic methods:
- get object's descriptor : (if you have the object's descriptor, you have it)
- copy the object
- send a message to the object. For example a dictionary entry to add to the
object's dictionary.

 Objects descriptors came in tiny, small, medium. large, huge groups named
dictionaries.
(to be continued ...)
 



From uunet.UU.NET!davgar!david Mon Mar 15 08:01:18 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22539; Mon, 15 Mar 93 08:01:17 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Mon, 15 Mar 93 08:01:17 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA05655; Mon, 15 Mar 93 02:01:11 -0500
Received: from davgar.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020033.15269; Mon, 15 Mar 1993 02:00:33 EST
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR5);
           Mon, 15 Mar 1993 01:52:38 EST
Date:      Mon, 15 Mar 1993 01:52:34 EST
From: (David Garfield) uunet.UU.NET!davgar!david
Message-Id: <2ba427b7.davgar@davgar.UUCP>
Organization: Third Star on the Left
To: uunet.UU.NET!davgar!Francois-Rene.Rideau, <rideau@clipper>
Subject:   I think you should know your mailer has bugs.
Status: OR

When you replied to:

: From: (David Garfield) davgar!david@uunet.uu.net
: To: moose-programmers@sfu.ca

You wound up with:

: From: rideau@clipper.ens.fr (Francois-Rene Rideau)
: To: david%davgar@uunet.uu.net
: Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net

That CC: line should have been somewhat different.  You may
want to notify your system manager that your mailer isn't
correctly processing replies.
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From uunet.UU.NET!davgar!david Mon Mar 15 08:50:18 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23555; Mon, 15 Mar 93 08:50:16 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Mon, 15 Mar 93 08:50:16 +0100
Received: from relay1.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA24684; Mon, 15 Mar 93 02:50:11 -0500
Received: from davgar.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 024912.18186; Mon, 15 Mar 1993 02:49:12 EST
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR5);
           Mon, 15 Mar 1993 02:36:01 EST
Date:      Mon, 15 Mar 1993 02:35:58 EST
From: (David Garfield) uunet.uu.net!davgar!david
Message-Id: <2ba431e3.davgar@davgar.UUCP>
Organization: Third Star on the Left
To: rideau@clipper
Subject:   Received far 18, 19, 20
Status: OR

I actually received 4 copies of # 18, and your other reply 
to my message.  I have also received your messages # 19 and 
20.  As I stated in my previous message, your problem with 
rejections is that your reply is not correctly formatting.  
On my previous message you will have observed that mine 
didn't work quite right either.  Ah well.  Live and learn.
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From ANDREASA@sofus.dhhalden.no Mon Mar 15 12:19:02 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29624; Mon, 15 Mar 93 12:19:00 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 15 Mar 93 12:19:00 +0100
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <04968-0@fenris.dhhalden.no>; Mon, 15 Mar 1993 12:18:43 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930315121828.448; 15 Mar 93 12:18:43 -100
Message-Id: <MAILQUEUE-101.930315121818.416@sofus.dhhalden.no>
To: rideau@clipper (Francois-Rene Rideau)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 15 Mar 93 12:18:18 +0100
Subject: Re: Did you receive far18,19,20 ?
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> From:          rideau@clipper.ens.fr (Francois-Rene Rideau)
> Subject:       Did you receive far18,19,20 ?
> To:            moose-programmers@sfu.ca (All the happy Moosers !)
> Date:          Mon, 15 Mar 93 6:22:09 MET

>  Hello happy moosers !
>  I have problems with my mailing to you:
> my mails are returned, so I don't know if you received my previous
> moose contributions.
>  Perhaps you did receive them more than once because I tried several times !
> So excuse me if I encumbered your mailboxes, and please ACKnowledge if you
> received it. (Just replying, and add your name/plan ?)
>
>
>
> Here are three sample error headers, separated by a line.
> If someone can help explain my mistakes and how to neext mail properly,
> I thank him for his explaining !
>
> -----------------------------------------------------------------------------
> Message 3/18  From Mail Delivery Subsystem            Mar 13 '93 at 5:15 am -300
>
> Return-Path: <MAILER-DAEMON@uunet.uu.net>
> Received-Date: Sat, 13 Mar 93 11:15:14 +0100
> Date: Sat, 13 Mar 93 05:15:07 -0500
> Subject: Returned mail: Host unknown
> To: <rideau@clipper>
> Sender: rideau@clipper
>
>    ----- Transcript of session follows -----
> 550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown
>
>    ----- Recipients of this delivery -----
>    <david%davgar@uunet.UU.NET>
>    <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>
>
>    ----- Unsent message follows -----
> Received: from dmi.ens.fr by relay2.UU.NET with SMTP
>         (5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
> Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
>         id AA14495; Sat, 13 Mar 93 11:14:59 +0100
> From: rideau@clipper.ens.fr (Francois-Rene Rideau)
> Message-Id: <9303131014.AA14495@clipper.ens.fr>
> Subject: Re: Obj. Sharing (djg3) far17
> To: david%davgar@uunet.uu.net
> Date: Sat, 13 Mar 93 11:14:57 MET
> Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
> In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
> X-Mailer: ELM [version 2.3 PL11]
>
>
>
>
> ------------------------------------------------------------------------------

Got three editions of all you letters  :-)
Don't know why you get all those terrible errors, but why are all of them
sent to davgar?

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon Mar 15 13:30:13 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01523; Mon, 15 Mar 93 13:30:12 +0100
Return-Path: <bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 15 Mar 93 13:30:12 +0100
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa16420; 15 Mar 93 7:21 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa18288;
          15 Mar 93 12:16 GMT
Received: from sol.cis.udel.edu by bofur.cis.udel.edu id aa15313;
          15 Mar 93 12:13 GMT
To: Francois-Rene Rideau <rideau@clipper>
Subject: Re: Did you receive far18,19,20 ? 
Date: Mon, 15 Mar 93 07:13:20 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303151213.aa15313@bofur.cis.udel.edu>
Status: OR


   I received several messaged like that (and several copies of some
of them.)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dmarer@td2cad.intel.com Mon Mar 15 16:47:28 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08231; Mon, 15 Mar 93 16:47:26 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Mon, 15 Mar 93 16:47:26 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05264; Mon, 15 Mar 93 07:22:35 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Mon, 15 Mar 93 07:22:22 -0800
Received: by td2cad (5.57/10.0i); Mon, 15 Mar 93 07:26:04 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01054; Mon, 15 Mar 93 07:33:16 PDT
Date: Mon, 15 Mar 93 07:33:16 PDT
Message-Id: <9303151533.AA01054@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re:  Libraries
Status: OR

> Hi!
> 
> I think that having the seperate concepts of module, library and object 
> is overkill. Can't we merge these into a single concept and simplify life?
> 
> Michael

I think the reason I came up with these concepts in the first place had to
deal with what was being loaded into memory at one time.  Objects tend to be
small, and if they were each loaded seperately, linking would be hell and
take up lots of overhead.  The concept of a module is to put into a single
unit a group of related objects *and* functions *and* data (not just objects).
It is a *tightly* related collection of things.  A library is a more loosely
related collection of modules, and doesn't really concern the kernel at all.
It was thought of originally as a convention for storing stuff on disk.

Windows and OS/2 have DLLs, which would be equivalent to what I call a module.
A "library" in my mind is a much larger entity than a module, but a module is
the smallest chunk of code which will occupy a portion of memory allocated
by the kernel.  All code in a module sits at a particular priviledge level.

I can't see doing away with the concept of a library - our system stuff itself
may need 20 to 30 modules, the GUI may need 10 or 20, and so on.  Combining
these into a library simplifies life on disk, so this is a concept important
to the filesystem only.  (A group of files within a file?)  If the *entire*
system library were loaded at run-time, we'd have the same problem as OS/2
and Windows - it would take tons of memory to run.  To load only those parts
necessary, libraries are broken into modules which can be loaded and linked
to at run-time of an application.  If an app runs and the module exists in
memory already, no load is necessary.  (Just like DLLs, just different names.)
Only those portions used by a program are loaded, at run-time.

In this scheme, a program *is* a module with (in C terminology) a "main"
function to be called once the program is loaded.

Again, if objects are loaded individually the overhead would be tremendous -
if the entire OS or GUI is put in a single module, memory usage would be
outrageous.

I think some of you were asking why not make modules and programs objects?
This would be nice, except who would benefit?  The only entity responsible
for (and allowed to) manipulate modules is the kernel.  Nobody else needs
really any interface at all to modules except information gathering for
linking purposes. It's really a toss up - it's a nice convention to make
everything an object, but it may not be useful.  We'll see!

			Dennis

From dmarer@td2cad.intel.com Mon Mar 15 16:27:10 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07489; Mon, 15 Mar 93 16:27:04 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Mon, 15 Mar 93 16:27:04 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Mon, 15 Mar 93 07:25:59 -0800
Received: by td2cad (5.57/10.0i); Mon, 15 Mar 93 07:29:41 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01058; Mon, 15 Mar 93 07:36:54 PDT
Date: Mon, 15 Mar 93 07:36:54 PDT
Message-Id: <9303151536.AA01058@tdge15.intel.com>
To: rideau@clipper
Subject: Re:  Did you receive far18,19,20 ?
Status: OR

>  Hello happy moosers !
>  I have problems with my mailing to you:
> my mails are returned, so I don't know if you received my previous
> moose contributions.
>  Perhaps you did receive them more than once because I tried several times !
> So excuse me if I encumbered your mailboxes, and please ACKnowledge if you
> received it. (Just replying, and add your name/plan ?)

Hi fare-

	I think I received all of them - actually, two copies of each. :-)

				Dennis

From dmarer@td2cad.intel.com Mon Mar 15 16:52:49 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08430; Mon, 15 Mar 93 16:52:48 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Mon, 15 Mar 93 16:52:48 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06050; Mon, 15 Mar 93 07:48:45 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Mon, 15 Mar 93 07:48:43 -0800
Received: by td2cad (5.57/10.0i); Mon, 15 Mar 93 07:52:28 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01062; Mon, 15 Mar 93 07:59:41 PDT
Date: Mon, 15 Mar 93 07:59:41 PDT
Message-Id: <9303151559.AA01062@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Frustration 1
Status: OR

Hi Moosers,

	Well, I'm frustrated.  Half of me wants to throw in the towel.  It
seems like that we've accomplished very little so far!  Frankly, I've got no
idea what the next steps or decisions we should make are, so I'm going to
collect *all* of the information we've generated so far, go home, and start
writing.  Over the next several weeks, I'm going to be working on what things
I envision for this operating system of ours.  This will be a lot of my
opinions, influenced by things we've discussed here - don't get me wrong,
there have been a lot of great ideas but almost no organization.  This will
be revision 2 of the specs and it will seek to organize our thoughts.  It's
going to take a while to finish to my satisfaction - I'm not going to promise
any dates.

	It takes too much for me to try to explain all of my ideas in this
system in small pieces (I.E., a little bit each mail message).  I'm going to
try and put *all* of my ideas into a single document, from which we can work.
I rushed the first revision of the specs just to get some discussion going and
now its time for me to go back and start from scratch again.

	Keep discussion going, definitely!  I'm still reading all the mails,
and as new ideas come up I'll use them in the document where appropriate.
I'm not quitting yet, just will be less active in discussion until I have
defined on paper what I believe is what I want in an operating system.

				Dennis

From ANDREASA@sofus.dhhalden.no Mon Mar 15 17:26:22 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09783; Mon, 15 Mar 93 17:26:20 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 15 Mar 93 17:26:20 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08378; Mon, 15 Mar 93 08:22:20 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <13139-0@fenris.dhhalden.no>; Mon, 15 Mar 1993 17:22:02 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0-VROOM 
          with IPX id 100.930315172146.256; 15 Mar 93 17:22:01 -100
Message-Id: <MAILQUEUE-101.930315172144.736@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 15 Mar 93 17:21:44 +0100
Subject: Re: PLEASE READ THIS ONE
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> From:          Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
>
> Can we drop detailed issues and talk about conceptual models for the moment?
>
> Then try to explain your view to everyone else.

I'll do as good as I can :-)

> To start the ball rolling here's mine ... I would like to emphasize that
> mine is a kinda vague defaulty thing -- I'm quite open to suggestions
> and other viewpoints ...
>
> What I had in mind was a system where executable code is the standard
> however you'd have kernel calls to send messages to other processes/objects

I have a completly different way of looking at it (I belive).
The kernel can't send _any_ type of message!!!, what it can do is to raise
events in devices in the layer above the kernel.

> Internally an object is a piece of code with no constraints.
> It (the object) gets called from other objects.

I envision the OS beeing a set of devices (or objects, but I use devices for
both devices and objects because I think it is easier to understand my model
if we regards devices as objects, but not necessary objects as devices)
that can raise events in all tasks that are linked to that device.

> We have more flexibility then (EG) MS-DOS since an object has multiple entry
> points as opposed to a single "run -- exit" sequence.
>
> We provide inter-application communication by having standard object
> sementics -- much like device independant I/O allows us to write programs
> that will work on both files, terminals, pipes etc.
> Call this polymorphism if you will.

I would want to have a device that take care of inter-process communication.
You output data/code (in any object type, files, handels etc) to a device and
then the device will transmitt it to the proper task, alternativily the device
could transmitt a direct contact to another task.

> The fundumentals are
>     * Multitasking (otherwise you can't have inter-application
>             communication)
>     * mountable devices
>     * Remote Object Invocation (or whatever you want to call it)

Agree.

Dennis has a lot of remarks about GUIs in his follow up.
I mostly agree with what he says there.
There is also a lot of talk about making it an OS for the programmer.
This can be difficult to acomplish, but I'll do my best to show how this could
be done with my model.

Imagine an object. You attach to/inherit this object. Whenever an event
arises the object will raise the attached object/overloaded method.

Take Windows as an example. It is event driven. Whenever something happens
in the world (of IO devices) that windows knows of it posts/sends a message
to a function that is known by windows. Then that function must classify
the message and take any appropirate action, or just let it pass to a standard
function.
This is not very programmer friendly. Windows programming is so cumbersome
that nobody has time to do anything useful other than just make the UI work.
The system is unstable and it is difficult to scope up the basic ideas.
(And remember the recommendations that every program should support the
minimum of DDE, how many apps. does/did this?)

Now, envision a system where the programmer just writes a member function
of an object that he has inherited. Say the base class he has inherited is
a keyboard device. Now, when the keyboarddevice is activated it will pass its
data up to the function he has written. As opposed to windows where the
"device" just passes a message to a function.
The base object will resort the correct action, not the programmer, and thus
we will lessen the chance of a faulty program.
The programmer can concentrate on making his program, not on when to do what,
or vice versa.

Overloading of (base member) functions gets important beacuse this is one way
to solve it with, and possible the most simple.
This will be some type of DDVT (Dynamic Dispatch Virtual Table), where each
device will have his own ddvt.
If the function is not overloaded it will just use the standard way of
resolving the situation.

Well that was a small begining, flame on or ask me if there is anything
unclear. Tell me if this could be a possible way of doing this. Does
anybody agree with me?

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From winikoff@cs.mu.OZ.AU Mon Mar 15 06:29:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20728; Mon, 15 Mar 93 06:29:26 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 15 Mar 93 06:29:26 +0100
Received: from mulga.cs.mu.OZ.AU by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA05885
	Mon, 15 Mar 1993 15:29:14 +1000 (from winikoff)
Message-Id: <9303150529.5885@mulga.cs.mu.OZ.AU>
Subject: Re: Did you receive far18,19,20 ?
To: rideau@clipper (Francois-Rene Rideau)
Date: Mon, 15 Mar 93 15:29:13 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303150522.AA20596@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 15, 93 6:22 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
>  Hello happy moosers !
>  I have problems with my mailing to you:
> my mails are returned, so I don't know if you received my previous
> moose contributions.
>  Perhaps you did receive them more than once because I tried several times !
> So excuse me if I encumbered your mailboxes, and please ACKnowledge if you
> received it. (Just replying, and add your name/plan ?)

I did recieve it (multiple times) -- I think the problem is with Dave's address

> 
> 
> 
> Here are three sample error headers, separated by a line.
> If someone can help explain my mistakes and how to neext mail properly,
> I thank him for his explaining !
> 
> -----------------------------------------------------------------------------
> Message 3/18  From Mail Delivery Subsystem            Mar 13 '93 at 5:15 am -300
> 
> Return-Path: <MAILER-DAEMON@uunet.uu.net>
> Received-Date: Sat, 13 Mar 93 11:15:14 +0100
> Date: Sat, 13 Mar 93 05:15:07 -0500
> Subject: Returned mail: Host unknown
> To: <rideau@clipper>
> Sender: rideau@clipper
> 
>    ----- Transcript of session follows -----
> 550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown
> 
>    ----- Recipients of this delivery -----
>    <david%davgar@uunet.UU.NET>
>    <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>
> 
>    ----- Unsent message follows -----
> Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
>         (5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
> Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
>         id AA14495; Sat, 13 Mar 93 11:14:59 +0100
> From: rideau@clipper.ens.fr (Francois-Rene Rideau)
> Message-Id: <9303131014.AA14495@clipper.ens.fr>
> Subject: Re: Obj. Sharing (djg3) far17
> To: david%davgar@uunet.uu.net
> Date: Sat, 13 Mar 93 11:14:57 MET
> Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
> In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
> X-Mailer: ELM [version 2.3 PL11]
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Mon Mar 15 06:43:24 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20969; Mon, 15 Mar 93 06:43:23 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 15 Mar 93 06:43:23 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25431; Sun, 14 Mar 93 21:39:41 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA06183
	Mon, 15 Mar 1993 15:39:29 +1000 (from winikoff)
Message-Id: <9303150539.6183@mulga.cs.mu.OZ.AU>
Subject: Re: Ker, win far20
To: moose-programmers@sfu.ca (Moose Project)
Date: Mon, 15 Mar 93 15:39:28 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303150501.AA19279@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 15, 93 6:00 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> 
> >> Hi everyone -- as promised my sketch for a simple kernel.
> >> feel free to flame, comment, criticise, compliment (:-) or suggest additions
> >> or changes.
> 
> I fear it's only going to be flames from me ;-( !

Fine. 

> 
>  AAARRRRGGGGHHHHH !!!!!!
>  This is *-disoriented unix-like stuff ! That should have nothing to do in
> a structured object-oriented OS !

Yes and no.
(1) I admit to to being influenced by Unix.
(2) I deliberately left out objects because
	(a) We haven't reached a consensus on objects
	(b) The kernel to me should be as simple as possible.

>  If that had to be like that, we wouldn't need anymore Moose Kerneling:
> we'd only have to use existing unix kernel (well, why not after all ?) !!!

Because most existing kernels are more complex and we can't extend them easily.

Actually this raises an interesting point -- what if we started with an existing
kernel (Eg. Linux, 386BSD) and added object support to the kernel?


> (if standard unix isn't satisfying, there are plenty of unix enhanced clones
> existing !)
> 
> - contextswitch():
>  it's up to the system, not objects (processes) to decide whether to switch
> context. In a massively parallel architecture, there may be no switch at all.
> Processes can have a "Wait" primitive, but contextswitching is a kernel
> problem.

As i mentioned this isn't really used by user processes.
You're right though -- it probly shoudln't be a system call then.

> 
> - self()
>  generically, objects may know of themselves; the self() call for processes
> should only be a particular instance of self() for any object.
> 
> - spawn()
>  cough cough cough !!! Warf !!!
>  Sorry, I just couldn't digest it !
>  "spawn" was a C add-up to make allow parallelism in an unstructured language
> (where thread-private data couldn't exist, everything being global !). It
> only allows auto-calling (very stupid). Such a horror shouldn't exist in
> the kernel.

Read the description -- the function takes an argument which is a pointer to 
code -- it is intended to essentially just add a task to the task table.

The code previous should 
(1) Allocate memory for the task
(2) Load the task's code into the memory

This is not at all like UNix'es "fork()" which I don't like.

> 
> - send(),receive(),poll()
>  ok for sending and receiving mechanisms; but again, why only for processes;
> any object may receive messages; or else, every object would have to be a
> process (why not then ?).
> But what would the mesg type be ? I hope that won't be only strings or
> (worse !) numbers ! Let's send/receive objects. Pattern matching will be
> done to separate objects.
> Polling can also be done by receiving in a sub-thread. (but having it standard
> is good). We may even make poll and receive atomic in some cases.

> 
> - alloc(), free().
>  No ! see what I said about memory management (also see farther)
> 
> - service(), ready()
>  Why particularize system services and have many varying syntaxes ?
> Let's have only objects. System objects which are the lowest-level objects
> will have the same access as other.
> 
> -  getdev(),setdev()

Ok then -- 
set_low_level_object_handler()

>  Why have devices ?
>  Devices are a new kind of object you bring about when you see your
> traditional OS concepts couldn't manage something (unix, thus dos: files
> can't manage anything, they're just data; devices are just read/write
> code).
>  In a OO OS, objects are what the system manages, and they are both
> data and code (I'd even like that we end differentiating each from the
> other), so we don't need to have a special concept as devices. What was
> called "devices" in previous messages was only low-level objects that
> would most probably be written in assembler or compiled from a low-level
> language (like C, for ex.). We'll have low-level objects as we'll have
> higher-level objects, in the object dictionaries.
> 
> 
> >> -------
> >> An initial "shell" could be a program that lets you make system calls ...
> >> This would be more like a system debugger/monitor ...
> Any interactive object is a "shell"; If we provide standard LLL, a LLL
> interpreter could be the first bootstrap shell.
> e
> >> -------
> [I won't talk about the implementation, as I can't agree with the kernel]
> 
> >> Memory allocation:
> >> 
> >> A simple way of managing memory is with a bitmap.
> >> If we have 1 bit = 1K byte then the amount of memory taken by the bitmap is
> >> 0.1% -- this is fine if we are managing physical memory.
> >> 
> >> alloc(size) 
> >> 	round size upto next kilobyte
> >> 	search bitmap for next free chunk of that size
> >> 	set the region to taken
> >> 	return pointer
> >> 
> >> free(ptr,size)
> >> 	reset bits in bitmape
> >> 
> >> Note: We can't compact physical memory without using virtual memory ...
> 
>  I don't agree at all with this either. See my previous messages about a
> multi-layer memory management, and a kernel that is/does but inter-object
> communication.
>  Also, optimal base memory block size depends mostly on the hardware (must
> be 4KB on the intel, 8KB on the SPARC, 256B on some 8 bit machines, etc).
> So let's have it implementation dependant.
> 
> >> ----------------------------------------------------------------------
> >> Michael Winikoff
> >> winikoff@cs.mu.oz.au
> >> Computer science honours. University of Melbourne, Australia.
> >> 
> 
> As I destroyed all that, I must show I can also construct. So I will
> soon post something (quick, then certainly full of errors) about how I
> envision things in an OO OS.
> 
> 
> 	   ,
> 	Fare
> Student (?) at the Ecole Normale Superieure, Paris
> 
> P.S.
> - my tabs can't hurt, as there's the same number of tabs at the
> two lines, and they begin the line; so I whatever size tabs are,
> it's ok. (but next time, I promise I won't put tabs)
> - beware of 80 columns non scrolling displays and multi-quoting !
> if you use more than, say, 70 columns in your texts, your quoted
> message won't display correctly/cleanly !
> 
> 

Quickly  (I have to go to a lecture now ...) we still have the problem of 
how to handle objects in an OS.

I deliberately left this out of this design which seems to have made it fatally
flawed and perhaps useless.

More later.
Bye for now.


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Tue Mar 16 01:18:23 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA26546; Tue, 16 Mar 93 01:18:22 +0100
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Tue, 16 Mar 93 01:18:22 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17588; Mon, 15 Mar 93 16:12:44 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa14338;
          15 Mar 93 19:03 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa26858; 16 Mar 93 0:02 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa09235;
          16 Mar 93 0:01 GMT
To: moose-programmers@sfu.ca
Subject: Code Space Generation, Protection, and Communication
Date: Mon, 15 Mar 93 19:00:42 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303160001.aa09235@bifur.cis.udel.edu>
Status: OR


   How about a brief look at the basics? Here are some basic things
we will need:

1) A code space. Private code and code included from elsewhere. This
implies a binding mechanism (dynamic or static) and a method of
locating the external code. (Constant data can be considered part of
the code, for all practical purposes.)

2) An execution space. A code space, a data space, and execution state.
For multitasking (or whatever your favorite term happens to be) more
than one of these is required. So we need a way to create and control
the execution space.

3) Communication. A standard way for execution spaces to pass data
between them. To communicate, execution spaces require some sort of
naming mechanism to direct the data to be communicated.

4) Protection. Keep execution spaces from disturbing other execution
spaces or the hardware. So we have to define which execution spaces
can perform particular sets of operations on particular code spaces,
data spaces, execution states, and hardware.

   Now, if we plan to globally implement object inheritance via code
inclusion, protection becomes a serious issue. For example, one idea
proposed was to inheirit a keyboard object to handle the object's
keyboard input. However, if the keyboard code needs access to the
keyboard, there needs to be some way to keep the upper-level code
from disturbing the keyboard hardware. In other words, the system
needs to enforce the object interface.
   Now, the 386 can probably handle this pretty well by using the
protection attributes of 386 segments. However, other architectures
may require a separate execution space to properly enforce this
protection. This implies that the inheritance in this case must
be translated into communication. Therefore, we should define a
standard communication method for invocing "base class methods"
on other objects.
   Anyone see any major logic flaws here?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Tue Mar 16 04:10:58 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01770; Tue, 16 Mar 93 04:10:56 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 16 Mar 93 04:10:56 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26447; Mon, 15 Mar 93 18:59:52 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA03147
	Tue, 16 Mar 1993 12:50:45 +1000 (from winikoff)
Message-Id: <9303160250.3147@mulga.cs.mu.OZ.AU>
Subject: Re: Ker,OOOOOOOOO far21
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 16 Mar 93 12:50:43 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303150646.AA22257@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 15, 93 7:46 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
>  In older manuals, objects were define as an embedding of code and data.
> Now, I will rather say that code and data are different aspects of objects.
>  Objects are a unifying scheme in computer science. Some call it schemes,
> others call it functions, some may call it God, etc. The fact is we can
> seek unity in computer programming (code and data or yin and yang aspects
> of the Tao; one feeds from the other).
>  This unity was broken when (micro)processors were built so complicated,
> that code to handle data was as foreign to data as data to represent code
> was from machine code.
>  But unity was rediscovered, and may be achieved again.

This is exactly the metaphysical crap we don't need -- objects should NOT
be a religion.

> 
>  Object are everything; everything is an object. Unix tried to say that files
> are everything, that everything could be done with a file; but Unix files
> were thus implemented that only big objects could be efficiently represented
> that way; and Unix didn't provide any code embedding with this data; and Unix
> forced people to access data through strings. So that the system wasn't a
> unified system.
> 
>  There came MOOSE, which raised hope among young programmers. It at last
> was a unified system. But it wasn't a closed unenhanceable, unextensible
> system. It provided generic polymorphic object managing: objects were
> implemented through descriptors who themselves were objects. Objects had
> a recursive definition, so that the only basic code/data was a convention
> on how to code objects so that others are aware of it and its methods.
> 
>  Objects had basic methods:
> - get object's descriptor : (if you have the object's descriptor, you have it)
> - copy the object
> - send a message to the object. For example a dictionary entry to add to the
> object's dictionary.
> 
>  Objects descriptors came in tiny, small, medium. large, huge groups named
> dictionaries.
> (to be continued ...)
>  
> 
> 
> 

As far I'm concerned (IMHO, feel free to arguye/flame) objects are usually
very wishy washily defined.

The main reason (IMHO) is that the concept of OO contains a number of separate
distinct concepts that have been lumped together.

(1) Data abstraction -- accessing data only through the interface
(2) Inheritance -- this is a code reuse issue
(3) POlymorphism and overloading -- these are typing issues

This is usually associated with a layer above an imperative langauge. 
However ...
(1) Polymorphism can be done (and has been) in declereative languages
(2) Haskell's type classes implement overloading (and a form of inheritance)
(3) Data abst5action is not at all related to imperative languages.

 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Tue Mar 16 06:06:24 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10634; Tue, 16 Mar 93 06:06:19 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 16 Mar 93 06:06:19 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA00854; Mon, 15 Mar 93 20:57:52 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA08172
	Tue, 16 Mar 1993 14:57:35 +1000 (from winikoff)
Message-Id: <9303160457.8172@mulga.cs.mu.OZ.AU>
Subject: Re: Ker, win
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 16 Mar 93 14:57:33 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <MAILQUEUE-101.930315131517.416@sofus.dhhalden.no>; from "Andreas Arff" at Mar 15, 93 1:15 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> > Hi everyone -- as promised my sketch for a simple kernel.
> > feel free to flame, comment, criticise, compliment (:-) or suggest additions
> > or changes.
> >
> 
> I feel that this way of doing things locks out the object from the kernel, and
> as Fare' said, becomes a "standard unix kernel" type of kernel.
> As mentioned hundereds of times i previous mails, we need to define what we
> want to achive, but because of me getting very exhited (the adrenalin is
> pumping up the veins :-) I'll give you my suggestion later.

In retrospect I shouldn't have posted -- I should have waited till we had
a consensus on objects or proposed an object based design.

I think it is fair to say that objects (whatever that means) will play a role
in the design of the kernel.

> 
> > The kernel has the following system calls:
> >
> > contextswitch()
> > pid = self()
> > pid = spawn(ptr to code, ptr to stack, initial pc)
> > kill(pid)
> 
> This contradicts my way of looking upon the problem.
> As I see it:
> There are two type of contextsswitches that we must have.
> Both the preemptive and the event-based.
> These are contradictionary (?) in them self in a way.
> But the important things.
> An application must be able to act on an event imidiatly when it is raised.
> The kernel should make it's contextswitches whenever the "heart beats" (clock
> ticks).
> This prevents us from makeing a simple round robin implementation!
> We must have tasks that have more prioriaty than others, eg. the tasks used
> by the user should have, say, twice as much processing time as opposed to the
> others, that are latent from the users actions.
> I.e. no input, no need to give the task his full share of time.
> Much user input - more time given to that task than given to the others.

Note: I suggested round robin and the other implementation as the simplest
possible. 
Not neccessarily as a good or practicle way of doing things.

If you're machine is sufficiently fast then round robin should be workable.

> 
> Now back to my fundamental idea (don't know if you like it or not because of
> lacking response (well, not you Fare')) where the device has its own list
> of tasks/threads that might want to have input from it. Whenever the device
> gets an event (key pressed on keyboard) the running task is interupted.
> The interupt routine passes the message further to the thread that wants it.
> The thread processes the message until no more time left, and the kernel

I don't like this -- I prefer to simply have the interrupt handler create 
a message that is placed in the appropriate place but do not context switch.

Under MULTICS (?) this was done --- a user could get more CPU time by hitting
a key every now and again ...

> contextswitch to the task that was running before the event.
> I realize that this could make a large overhead and that tasks could nest them
> self to infinity (interrupt on interrupt on interrupt...).
> The way to go round this is to have each task maintain a que that will be
> handeled when it gets its timeslice.
> This will turn my previous idea on its head in a way, but the basic concept
> will still work.
> Of course most of this should be put into the task-device.
> 
> > send(pid, message)
> > mesg = receive()
> > bool = poll()
> 
> No one will never poll or ask for a message, or send one if everyting is
> developed as devices.
> We can have a send device that will act the same way as a keyboard device.

These kernel calls will be used in the writting of the devices.

> 
> > ptr = alloc(size)
> > free(ptr, size)
> 
> I support these things for the kernel. A very simple basic memory allocation
> scheme with MemoryAllocate, MemoryReAllocate and MemoryFree as proposed by
> Dennis in rev. 0.
> All GC, word alignment etc. will be handeled by a device.
> Keep the kernel clean and simple.

Good! (Of course I agree - I suggested it :-)
> 
> > reqid = service(devid, service_number, ptr to result/arg buffer, flags)
> > bool = ready(reqid)
> 
> Preferr the Amiga way with sniff/tiff/gif/etc. devices/objects that are
> published through a dictionary.
> 
> > getdev(devid, service_number, var pid, var code)
> > setdev(devid, service_number, pid, code)
> 
> You should be able to insert a device into the dictionary as long as there
> are no device already occupying its postition.
> 
> Have to run
> to be continued...
> 
> Arff
> sig.'s in for 1000 miles service
>         --Andreas Arff          andreasa@dhhalden.no--
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From mueller@sc.ZIB-Berlin.DE Wed Mar 17 10:12:23 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18079; Wed, 17 Mar 93 10:12:21 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 17 Mar 93 10:12:21 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24530; Wed, 17 Mar 93 01:06:59 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA20315; Wed, 17 Mar 93 10:06:46 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA15128; Wed, 17 Mar 93 10:06:45 +0100
Date: Wed, 17 Mar 93 10:06:45 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303170906.AA15128@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: ORG, ROI, pem - Specification 03/16/93
Status: OR

Howdy! 
 
In this mail I will give you a first specification of remote object 
invocation. There were no (zero!) responses to my previous mail. I get 
a little confused, have I said something wrong? Don't you have enough 
time to think it over? Well, I actually assume, that some of you have 
not received my mail and I've sent out an acknowledgement request. 
 
This specification presents only my point of view. It is written in 
present time so it's possible to use it as documentation when things 
work. I will try to keep it up-to-date and to `broadcast' it in a 
periodical manner (if there are no other opinions). I hope, you will 
send me many suggestions, ideas, wishes, and negative or positive criticism 
(which always should be constructive, of course :-). 
 
As I pointed out in previous mails, I'm an advocate of a strict separation 
between design/specification and implementation. So, the specification only 
says what happens and not how it is actually done. Nevertheless, as most of 
you are more interested in implementation details, I will give an example on 
how ROI is involved in an application at the end of the specification. 
 
And now happy reading, 
 
Peter 
 
----- Cut here ----- 
 
R e m o t e   O b j e c t   I n v o c a t i o n 
 
Specification Release 0.00 (03/16/93) 
 
1 Overview 
========== 
 
   This specification will give an abstract view on how remote object 
invocation is done in MOOSE. Remote object invocation (ROI) means to invoke 
a method from an object, which is not sharing the invoker's address space. 
Thus, `remote' in this context means still both invoker and invokee be 
running on the same machine. (This restriction will disappear, when MOOSE 
becomes a distributed OS. Then `remote' means not the same address space or 
even on a remote machine.) 
 
   Usually ROI is used, when an object needs access to services provided 
by other objects. Therefore the terms `client' and `server' are used to 
distinguish between the invoking and invoked object. Clients use services 
from servers. This allows a strict separation between these two 
functionalities, although it is still possible to have objects, which are 
both, client and server, at the same time. 
 
2 Design goals 
============== 
 
   The following points give an overview of desired characteristics for ROI. 
Thus, ROI should be: 
 
     1. general 
     2. object location transparent 
     3. very efficient regarding communication costs 
     4. user-friendly 
 
2.1 Generality 
-------------- 
 
   ROI must be provided for a variety of objects, which can be wide spreaded 
among different applications as well as different contexts or privilege 
levels. 
 
2.2 Object Location Transparency 
-------------------------------- 
 
   Most objects within MOOSE are location independent; it is not definitely 
clear where the object exist at a given time. Additionally, objects are 
created dynamically in a non-deterministic fashion. 
 
   Mechanisms are needed which provide a mapping function from an object's 
description to its actual location. These mechanisms are provided by a 
special kind of server object, the NAME SERVER. Name servers know the 
absolute locations of their objects and make them transparently available 
to other objects. 
 
2.3 Efficiency 
-------------- 
 
   As one design goal of MOOSE is to provide a highly dynamic system, where 
components are added on the fly, ROI will be a highly used communication 
mechanism. Almost all traditional operating system services are provided by 
independent objects. Therefore ROI must be very efficient to minimize the 
remote invocation overhead. This can only be reached if very efficient IPC 
mechanisms exist. Thus the kernel must provide very fast IPC (which is to be 
specified in another release). 
 
2.4 User-friendliness 
--------------------- 
 
   Users and their applications should not be aware of ROI. If an application 
needs to invoke methods of a remote server it should simply instance an 
appropriate client object. All necessary ROI stuff should be done by creation 
of the client, which then provides a transparent view to the servers' 
methods. 
 
   Surely there must exist mechanisms, which allow to interfere in the ROI 
process as much as the user want. Eg, it must be possible to ask a specific 
name server for a server object's location. 
 
3. Object Identification 
======================== 
 
   To give access to a server's method the server must be known to all 
possible clients. Thus the client must have the functionality to identify 
the right server. Identifying can be done in several ways, eg.: 
 
     1. by name 
     2. by description 
     3. by value 
 
This specification will only handle the first one, nameing. 
 
3.1 Nameing 
----------- 
 
   A server can be unambiguously identified by its name. A `name' is a unique 
identifier within a given context, its `scope'. Note that several scopes may 
coexist at the same time, eg. each application may have its own name scope. 
This facilitates that multiple objects with the same name may coexist, but 
each one must reside in its own scope. 
 
   A server is now an object, which can be seen as a tuple, combining a name 
with provided services. To make these services available, the server 
publishes its name within the desired scope by contacting the appropriate 
name server. This is illustrated in Fig. 1: 
 
 
      +----------+  Make `MyServer' public   +--------------+ 
      | MyServer |-------------------------->| MyNameServer | 
      +----------+                           +--------------+ 
 
Fig. 1 
 
 
   Here the server `MyServer' makes its services available within the scope 
of the name server `MyNameServer'. Each time a client asks `MyNameServer' 
for `MyServer' it will return the server's location (Fig. 2). 
 
 
      +----------+       Ask for `MyServer'      +--------------+ 
      |          |------------------------------>|              | 
      | MyClient |                               | MyNameServer | 
      |          |   Return `MyServer' location  |              | 
      |          |<------------------------------|              | 
      +----------+                               +--------------+ 
 
Fig. 2 
 
 
   Now `MyClient' is able to invoke all provided methods from `MyServer' as 
if `MyServer' is a local object. All necessary message passing is done by 
ROI and hidden from the user of `MyClient'. 
 
3.2 Name scopes 
--------------- 
 
   A scope is created whenever a name server is started. Thus all known names 
to a name server form the name server's scope. An application, which creates 
a name server have the ability to build up its own scope, allowing it to 
redefine names as needed. Eg, it's possible to `overwrite' an existing file 
server to an application specific one, which always encrypt data on writing 
and decrypt it when reading. The application's file server can then be an 
inherited file server, which is specialized for encryption. Of course it can 
use methods from the `traditional' file server. 
 
   One question arises: What is the first scope OR where is the location of 
the first name server? 
 
   As almost all traditional operating system services are done by objects, 
there's the need for an default name server (DNS). DNS is installed at system 
startup, providing the first name scope, which holds information about, for 
example, the file server, printer server or disk servers. DNS is the only 
object which must be installed at a well known location (or: the kernel must 
provide a service to get its location). 
 
 
        +-------------+  client request or server registration 
        | Application |----------+ 
        +-------------+          v 
                 |   ^        +-----+ 
         ask for |   |        | DNS | 
          DNS by |   |        +-----+ 
         request |   |           | 
                 |   | return    | bounded 
                 |   | DNS       | location                User level 
      ...........|...|...........|................................... 
                 v   |           |                       Kernel level 
                +-------------+  | 
                |   Kernel    |--+ 
                | +---------+ | 
                | | Nucleus | | 
                +-+---------+-+ 
 
Fig. 3 
 
 
   A DNS location request solved by a kernel service is shown in Fig. 3. For 
simplicity only two privilege levels are shown, user and kernel level. An 
application, wishing to use services of a remote server object or to install 
a new server in the default name scope, must first find out the DNS location. 
It initiates a request to the kernel, which returns the current DNS location. 
Then the application can contact the DNS as usual. 
 
   Providing a kernel service have the advantage, that access to the DNS 
is location transparent. The system is free to place the DNS as it wishes. 
It has the disadvantage, that a kernel request must be additionally done to 
find out its location. But for flexibility the advantage outweights the 
disadvantage. 
 
   All necessary communication stuff for finding the DNS location should be 
encapsulated in clients or servers, respectively. If no other attributes are 
specified the DNS should be used automatically. Of course, an application, 
which creates its own name server can declare this server as its DNS. Then 
this name server is used, if no further attributes are given. 
 
3.3 Addressing 
-------------- 
 
   The name server is responsible to map a received name into an useful 
object location. This can be done either direct or indirect. A direct mapping 
function can calculate the location from the name, as shown in Fig. 4: 
 
 
      +------+  Mapping function   +-------------------+ 
      | Name |-------------------->| Object's Location | 
      +------+                     +-------------------+ 
 
Fig. 4 
 
 
   This is usually done by makeing the object's location part of the name. 
This has one great disadvantage. Consider the case, where several clients 
exist, which all want to use services of one server. Then all these clients 
will use the same name. For some reason the server must be migrated to 
another location. Then all names are invalid. 
 
   A second approach is to map a name to an `address' which then can be 
mapped to the object's location (Fig. 5). If the destination object migrates 
only the address must be changed. All names will still be valid. 
 
 
      +------+         +-------------------+ 
      | Name |         | Object's location | 
      +------+         +-------------------+ 
         |                ^ 
         |                | 
         |   +---------+  | 
         +-->| Address |--+ 
             +---------+ 
 
Fig. 5 
 
 
   With this approach a name can be very small. They only have to provide 
all necessary information to indicate an address. 
 
----- Cut here ----- 
 
To all of you, who want to see a more `implementation' oriented version 
I will now present examples, how an user should be able to use ROI 
in his/her application. All definitions are specified in a syntax similiar 
to those of C++. Note: This is still a conceptual model! At the end I will 
present problems which arise at this layer. 
 
Examples 
======== 
 
   Think of a server providing two services: 
 
    o doSomething() 
      Invoke a very funny procedure within the server. The service must 
      be called with no arguments. 
 
    o doSomethingElse(first, second) 
      Invoke another procedure within the server. This service must be 
      called with two arguments. 
 
The designer of the server have to do two things: He first have to create 
a server object and he secondly have to provide a client interface to use 
his server object. (This should be done automatically, either from a 
compiler or preprocessor.) 
   The server might look like this: 
 
      01: class MYSERVER : SERVER { 
      02:     // private and/or protected stuff (not visible) 
      03: public: 
      04:     MYSERVER(NAMETYPE name = "myserver") : SERVER(name) {} 
      05:     ~MYSERVER() {} 
      06:     doSomething(); 
      07:     doSomethingElse(FIRSTTYPE first, SECONDTYPE second); 
      08: }; 
      09: 
      10: MYSERVER::doSomething() { 
      11:     // do something 
      12: } // MYSERVER::doSomething 
      13: 
      14: MYSERVER::doSomethingElse(FIRSTTYPE first, SECONDTYPE second) { 
      15:     // do something with first and second. 
      16: } // MYSERVER::doSomethingElse 
      17: 
      18: main() { 
      19:     MYSERVER server; 
      20: } // main 
 
What happens? 
 
Lines 01-08: This is the definition of the server object's interface. There 
             should be an abstract SERVER object from which all servers are 
             inherited. The constructor should be responsible to publish the 
             server to an appropriate name server with a useful, hence, user 
             readable name ("myserver"). When no other arguments are given, 
             the default name server is used. (The case when a server with 
             the name already exist is not discussed any further. Yet.) 
 
             The destructor will be responsible to unpublish the server. This 
             means the name server will be informed that there is no more 
             server with this name. 
 
Lines 10-16: Usual method definitions. These methods should be invoked by 
             ROI. 
 
Line 19:     This actually establishes a new server. As there are no 
             arguments given, the server uses the default name (in this case 
             "myserver") and the default name server. Now a new server is 
             available in the scope of the default name server. 
 
The provided client interface should look like this: 
 
      01: class MYSERVER_CLIENT : CLIENT { 
      02:     // private and/or protected stuff 
      03: public: 
      04:     MYSERVER_CLIENT(NAMETYPE name = "myserver") : CLIENT(name) {} 
      05:     ~MYSERVER_CLIENT() {} 
      06:     doSomething(); 
      07:     doSomethingElse(FIRSTTYPE first, SECONDTYPE second); 
      08: }; 
      09: 
      10: main() { 
      11:     MYSERVER_CLIENT myclient; 
      12:     FIRSTTYPE first; 
      13:     SECONDTYPE second; 
      14: 
      15:     // Initialisation of first and second. 
      16:     myclient.doSomething(); 
      17:     myclient.doSomethingElse(first, second); 
      18: } // main 
 
What happens? 
 
Lines 01-08: Definition of the client's interface. The public part should 
             always look like the one from the corresponding server object. 
             The constructor will contact the name server trying to locate 
             a useful server. When no other arguments are specified the 
             default name server is contacted. 
 
Line 11:     In this line a new client is created. As there are no arguments 
             specified, the default server (in this case the server with the 
             name "myserver") is used. Its location was received by asking 
             the default name server. 
 
Lines 16,17: In both lines methods from the server are called. These calls 
             are performed by ROI, invoking the methods in the server 
             object. 
 
Note: There are no definitions of doSomething() and doSomethingElse(), 
      because both are executed remotely. 
 
Inheritance should be possible: 
 
       01: class NEWCLIENT : MYSERVER_CLIENT { 
       02:     // private and/or protected stuff 
       03: public: 
       04:     doSomething(); 
       05: }; 
       06: 
       07: NEWCLIENT::doSomething() { 
       08:     // do NEWCLIENT'S specialization 
       09:     MYSERVER_CLIENT::doSomething(); 
       10: } // NEWCLIENT::doSomething 
       11: 
       12: main() { 
       13:     NEWCLIENT myclient; 
       14: 
       15:     myclient.doSomething(); 
       16: } // main 
 
Line 09:     This line invoke doSomething() by ROI. All other stuff is 
             performed locally. 
Line 15:     Call of specialized doSomething() method locally. 
 
Note: doSomethingElse() cannot be called, because NEWCLIENT uses 
      MYSERVER_CLIENT as a private base class. 

   Inheritance should even be possible with servers. This can lead to a 
hierarchy of servers or to a call chain from descendants to ancestors with
ROI.
 
Problems 
======== 
 
What, when public methods of a server call private methods? 
----------------------------------------------------------- 
 
   Private methods are able to change the server's state. There must be 
mechanisms which avoid an influence from one client to another client's 
point of view to this state. Thus, each client must see it's own server 
state. 
 
What, when a server chooses a name which is already occupied by another 
server? 
----------------------------------------------------------------------- 
 
   This leads to a name conflict, which must be solved. The name server will 
deny the request and the server is not published. Thus, the provided services 
are not available. 
 
What, when a client cannot locate an appropriate server? 
-------------------------------------------------------- 
 
   There are two reasons for this problem: First, there's no server 
available. Then the client can simply create a new server instance. This 
instance will then publish itself to the name server, which was asked by the 
client. In this case the client knows the server's location. There's no need 
to ask the name server again. 
 
   Second, there's a server using the name, but which is not appropriate 
because it have the wrong type. There must be a mechanism which ensures that 
the returned server is useful for the asking client. 

From ANDREASA@sofus.dhhalden.no Wed Mar 17 11:02:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20139; Wed, 17 Mar 93 11:02:28 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 17 Mar 93 11:02:28 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25521; Wed, 17 Mar 93 01:58:28 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <20818-5@fenris.dhhalden.no>; Wed, 17 Mar 1993 10:58:14 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930317102534.2112; 17 Mar 93 10:58:11 -0100
Message-Id: <MAILQUEUE-101.930317102504.800@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 17 Mar 93 10:25:04 +0100
Subject: Re: Libraries
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Hi to everybody.

(> is Michael and > > is Dennis and > > > is Michael again)

Even though Dennis is taking a "pause" to collect our ideas into a working
doc. we don't have to stop the discussion. My mailbox was almost empty this
morning :-).
> >
> > > Hi!
> > >
> > > I think that having the seperate concepts of module, library and object
> > > is overkill. Can't we merge these into a single concept and simplify life?
> > >
> > > Michael
> >
> > I think the reason I came up with these concepts in the first place had to
> > deal with what was being loaded into memory at one time.  Objects tend to be
> > small, and if they were each loaded seperately, linking would be hell and
> > take up lots of overhead.  The concept of a module is to put into a single
> > unit a group of related objects *and* functions *and* data (not just objects).
>
> You mean we're having data that is NOT encapsulated in objects? My god,
> what will he come up with next? Blasphemy! :-) :-)

Not only data, functions too!!! :-)

> Seriously though, if the only reason for separarting objects into libraries
> and modules is efficiency then we'd be better off (IMHO) to keep them as one
> concept and just take care to make the implementation efficient.

Yes, but I think it would be easier if we made it hierarchical. It is easier
to handle the concept then, but whether or not the implementation will
contain this hierachical system is something that has to be considered at
implementation time. Even though our code may be dirty (havn't we all reached
Tao:-), it doesn't mean that our documents have to be dirty :-)

> > I can't see doing away with the concept of a library - our system stuff itself
> > may need 20 to 30 modules, the GUI may need 10 or 20, and so on.  Combining
> > these into a library simplifies life on disk, so this is a concept important
>
> You're more or less assuming a comventional file-system that doesn't like
> small files -- this is not a good thing to assume automatically.

After all a disk is a disk. Even though your system equally "likes" large and
small files, it doesn't automatically mean that it will be equally efficient.
It is faster to load one large file (if it is contigous) with subfiles in it,
than 50 small files (spread over the disk).

> > to the filesystem only.  (A group of files within a file?)  If the *entire*
> > system library were loaded at run-time, we'd have the same problem as OS/2
> > and Windows - it would take tons of memory to run.  To load only those parts
> > necessary, libraries are broken into modules which can be loaded and linked
> > to at run-time of an application.  If an app runs and the module exists in
> > memory already, no load is necessary.  (Just like DLLs, just different names.)
> > Only those portions used by a program are loaded, at run-time.
>
> i think it's simpler just to have objects and to let the virtual memory system
> handle loading.

Well, are there any practical difference? I agree with Michaels way of doing
it though.

> Do you think this is unworkable from an efficiency view?

It depends on how much of the OS that is needed in the Memory at a time.
It should be possible to mark (at least) the kernel as a MEM_PHYSICAL block.


> > In this scheme, a program *is* a module with (in C terminology) a "main"
> > function to be called once the program is loaded.
> >
> > Again, if objects are loaded individually the overhead would be tremendous -
> > if the entire OS or GUI is put in a single module, memory usage would be
> > outrageous.
>
> Not with virtual memory.
Virtual memory won't simplifie the change of objects when we have made
improvements to parts of the OS, and want to exchange maybe two out of 50
objects.
Just another aspect of it.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From ANDREASA@sofus.dhhalden.no Wed Mar 17 11:57:12 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22237; Wed, 17 Mar 93 11:57:10 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 17 Mar 93 11:57:10 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26155; Wed, 17 Mar 93 02:45:45 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <20818-28@fenris.dhhalden.no>; Wed, 17 Mar 1993 11:45:01 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930317112625.1824; 17 Mar 93 11:44:58 -0100
Message-Id: <MAILQUEUE-101.930317112545.1216@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 17 Mar 93 11:25:45 +0100
Subject: Re: ORG, ROI, pem - Specification 03/16/93
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> Howdy!
>
> And now happy reading,

Thank you Peter, you have given MOOSE a huge kick forward, I want more of this
stuff.
Just some few comments on your proposal, which are mostly very good.
A question though, with nucleus do you mean the innermost kernel?

> Peter
>
> ----- Cut here -----
>
> R e m o t e   O b j e c t   I n v o c a t i o n
>
> Specification Release 0.00 (03/16/93)
>
> 1 Overview
> ==========
>
> 2 Design goals
> ==============
>
>    The following points give an overview of desired characteristics for ROI.
> Thus, ROI should be:
>
>      1. general
>      2. object location transparent
>      3. very efficient regarding communication costs
>      4. user-friendly
>
> 2.3 Efficiency
> --------------
>
>    As one design goal of MOOSE is to provide a highly dynamic system, where
> components are added on the fly, ROI will be a highly used communication
> mechanism. Almost all traditional operating system services are provided by
> independent objects. Therefore ROI must be very efficient to minimize the
> remote invocation overhead. This can only be reached if very efficient IPC
> mechanisms exist. Thus the kernel must provide very fast IPC (which is to be
> specified in another release).

I'm not sure I agree with that the kernel should provide the IPC. Remember
to keep it small and clean. I would rather put the ROI into its own ROI-device.
(oooh no, don't start to talk about devices again Andreas :-)

> 3. Object Identification
> ========================
>
>    To give access to a server's method the server must be known to all
> possible clients. Thus the client must have the functionality to identify
> the right server. Identifying can be done in several ways, eg.:
>
>      1. by name
>      2. by description
>      3. by value
>
> This specification will only handle the first one, nameing.

I many ways the other two are more important. I'm sure you have thought alot
about them.
For 2. must we make a ROI description language? I'm not sure of how you ment
this to be done.
For 3. Should we provide the developer with a list of numbers, each equal to
one object-type/object, if this is what you mean.

Please elaborate point 2 and 3 a little bit more.

One thing that I think should be possible; make an object private. You have
to know a "password" to use it or something like that.

> ----- Cut here -----
>
> To all of you, who want to see a more `implementation' oriented version
> I will now present examples, how an user should be able to use ROI
> in his/her application. All definitions are specified in a syntax similiar
> to those of C++. Note: This is still a conceptual model! At the end I will
> present problems which arise at this layer.

Actually Peter, I liked the draft more than the example:-).


Maybe I have misunderstood some of the ROI concept so here follows a brief
discussion of my thoughts vs. your.

Following your concept each object seems to be very "private".
A task knows what he wants (by name?/!) and uses it.
Now another task need the same service, but he doesn't know the objects name.
How can he know how to use it then?

It looks like we have to define several types of base objects with a set of
minimum defined functions to let it become an object that can be used by the
name server as a public object.
I don't think a task should know everything about the object he want to use.

I'll give you an example:

  Take a picture viewer. It doesn't contain any code itself to show
  any picture, he relies on objects that he can reach through the name
  server.
  How can it know what objects to ask for without a uniform description
  language. How can it know how to use the object without knowing something
  about it's capabilities.

Maybe I have missed something fundamental (trying desperate to reach the Tao).
Correct me if so.

Arff

PS. Peter, I must say once more that the only thing that has brought MOOSE a
similar step forward was rev. -72 :-) from Dennis, keep up your good work,
both of you!.
DS.
  Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From dmarer@td2cad.intel.com Wed Mar 17 19:08:38 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17455; Wed, 17 Mar 93 19:08:36 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 17 Mar 93 19:08:36 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11272; Wed, 17 Mar 93 10:02:58 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Wed, 17 Mar 93 10:02:52 -0800
Received: by td2cad (5.57/10.0i); Wed, 17 Mar 93 10:06:38 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01512; Wed, 17 Mar 93 10:13:54 PDT
Date: Wed, 17 Mar 93 10:13:54 PDT
Message-Id: <9303171813.AA01512@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re:  Libraries
Status: OR

> You're more or less assuming a comventional file-system that doesn't like
> small files -- this is not a good thing to assume automatically.

Are you saying that every object exists in its own file?  Is there no grouping?
No, I'm not assuming any file size problems, just that in, for example, a GUI
I can already envision several hundred objects. (thousand?)  You'd be stupid
to place each in its own file, so some grouping is necessary.

> i think it's simpler just to have objects and to let the virtual memory system
> handle loading.
> 
> Do you think this is unworkable from an efficiency view?

Are you saying every object is loaded into memory individually?

What about linking?  Loading one object could in turn cause several *hundred*
to subsequently be loaded into memory because it references them.  This is
several *hundred* accesses to disk, links, and possibilities of failure.

If related objects, functions, and data are grouped together (in a module,
for example) all internal references are linked at the time the module is
created, not at the time the module is loaded.  External links (to other
modules) are resolved at load time, which is done en masse for every object
in the whole module rather than one at a time.

*Yes*, I think its unefficient.  Let's look at the implementation: the system
would need to keep track of the standard information for memory allocation,
a pointer and the size of the memory area used.  Also, linking information for
every method (public and private - remember inheritance) and data item for
the object would need to be stored.  I can envision cases where the info
stored by the system would be larger than the object itself!  (I make "pure"
objects all the time, with no code and no data.)

There needs to be some cohesive unit...if this were a 100% object oriented
environment where everything were an object, your idea would have merit.
It's not, and functions and data outside objects still exist.  Some way needs
to exist to collect these concepts into a cohesive unit.

> > Again, if objects are loaded individually the overhead would be tremendous -
> > if the entire OS or GUI is put in a single module, memory usage would be
> > outrageous.
> 
> Not with virtual memory.

*flame on*  This is the one assumption I completely disagree with!  IBM and
Microsoft have made this assumption, and now you're *reccomended* to have 16MB
of memory just to run OS/2 or Windows NT.  Sure, you can run with 4/8MB, but
you'll be swapping from here to timbuktu. *flame off*

Break the system down into useable chunks, only load those you need.

What if I'm running an application which only utilizes the local screen.  Does
it mean I have to load the code to support a screen at a networked system also?

I can't tell if you want everything in one single file or everything in its
own file...please explain your ideas more.  I just see the need for a logical
way of dividing things: lots of relatively small objects (and functions and
data items) go into a module to simplify management by the kernel.  Lots of
modules can be placed into libraries to simplify management by the *user*.

I'm just trying to develop a system which encourages grouping of related
concepts into logical chunks.  Today, you *can* use your C++ compiler to
generate a single file for every object, but you don't, do you?  Also, you
can generate hundreds of modules and link to them explicitly instead of
placing them all in a library, but you don't, do you?  These are not new
concepts I'm introducing here - they're tried and true, and apply just as
well to the world of OOP.

-------------------------------------------------------------------------------

Ok, so I'm not out to redesign every aspect of the concept of an operating
system - I'm frustrated because it seems that's what we're trying to do.  I'm
more interested in applying the concepts already in existence and developing
something useful quickly instead of doing intensive research and testing of
brand new ideas.  I'm not trying to re-write UNIX, but I'm also not trying to
develop Amoeba (which has taken over 5 years so far).  What I want out of this
project is something that is more *useful* to me than DOS or Windows, not
something which takes the scientific world by storm.

				Dennis


From winikoff@cs.mu.OZ.AU Wed Mar 17 06:38:36 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA11255; Wed, 17 Mar 93 06:38:35 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Wed, 17 Mar 93 06:38:35 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18584; Tue, 16 Mar 93 21:33:10 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA16761
	Wed, 17 Mar 1993 15:32:56 +1000 (from winikoff)
Message-Id: <9303170532.16761@mulga.cs.mu.OZ.AU>
Subject: Re:  Libraries
To: moose-programmers@sfu.ca (Moose Project)
Date: Wed, 17 Mar 93 15:32:55 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303151533.AA01054@tdge15.intel.com>; from "Dennis Marer" at Mar 15, 93 7:33 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> > Hi!
> > 
> > I think that having the seperate concepts of module, library and object 
> > is overkill. Can't we merge these into a single concept and simplify life?
> > 
> > Michael
> 
> I think the reason I came up with these concepts in the first place had to
> deal with what was being loaded into memory at one time.  Objects tend to be
> small, and if they were each loaded seperately, linking would be hell and
> take up lots of overhead.  The concept of a module is to put into a single
> unit a group of related objects *and* functions *and* data (not just objects).

You mean we're having data that is NOT encapsulated in objects? My god,
what will he come up with next? Blasphemy! :-) :-)

Seriously though, if the only reason for separarting objects into libraries
and modules is efficiency then we'd be better off (IMHO) to keep them as one
concept and just take care to make the implementation efficient.

> I can't see doing away with the concept of a library - our system stuff itself
> may need 20 to 30 modules, the GUI may need 10 or 20, and so on.  Combining
> these into a library simplifies life on disk, so this is a concept important

You're more or less assuming a comventional file-system that doesn't like
small files -- this is not a good thing to assume automatically.

> to the filesystem only.  (A group of files within a file?)  If the *entire*
> system library were loaded at run-time, we'd have the same problem as OS/2
> and Windows - it would take tons of memory to run.  To load only those parts
> necessary, libraries are broken into modules which can be loaded and linked
> to at run-time of an application.  If an app runs and the module exists in
> memory already, no load is necessary.  (Just like DLLs, just different names.)
> Only those portions used by a program are loaded, at run-time.

i think it's simpler just to have objects and to let the virtual memory system
handle loading.

Do you think this is unworkable from an efficiency view?

> 
> In this scheme, a program *is* a module with (in C terminology) a "main"
> function to be called once the program is loaded.
> 
> Again, if objects are loaded individually the overhead would be tremendous -
> if the entire OS or GUI is put in a single module, memory usage would be
> outrageous.

Not with virtual memory.

> 
> I think some of you were asking why not make modules and programs objects?
> This would be nice, except who would benefit?  The only entity responsible
> for (and allowed to) manipulate modules is the kernel.  Nobody else needs
> really any interface at all to modules except information gathering for
> linking purposes. It's really a toss up - it's a nice convention to make
> everything an object, but it may not be useful.  We'll see!
> 
> 			Dennis
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Wed Mar 17 06:39:50 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA11296; Wed, 17 Mar 93 06:39:49 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Wed, 17 Mar 93 06:39:49 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18646; Tue, 16 Mar 93 21:35:18 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA16844
	Wed, 17 Mar 1993 15:34:59 +1000 (from winikoff)
Message-Id: <9303170534.16844@mulga.cs.mu.OZ.AU>
Subject: Re: PLEASE READ THIS ONE
To: moose-programmers@sfu.ca (Moose Project)
Date: Wed, 17 Mar 93 15:34:59 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <MAILQUEUE-101.930315172144.736@sofus.dhhalden.no>; from "Andreas Arff" at Mar 15, 93 5:21 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> > From:          Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
> >
> > Can we drop detailed issues and talk about conceptual models for the moment?
> >
> > Then try to explain your view to everyone else.
> 
> I'll do as good as I can :-)
> 
> > To start the ball rolling here's mine ... I would like to emphasize that
> > mine is a kinda vague defaulty thing -- I'm quite open to suggestions
> > and other viewpoints ...
> >
> > What I had in mind was a system where executable code is the standard
> > however you'd have kernel calls to send messages to other processes/objects
> 
> I have a completly different way of looking at it (I belive).
> The kernel can't send _any_ type of message!!!, what it can do is to raise
> events in devices in the layer above the kernel.
> 
> > Internally an object is a piece of code with no constraints.
> > It (the object) gets called from other objects.
> 
> I envision the OS beeing a set of devices (or objects, but I use devices for
> both devices and objects because I think it is easier to understand my model
> if we regards devices as objects, but not necessary objects as devices)
> that can raise events in all tasks that are linked to that device.
> 
> > We have more flexibility then (EG) MS-DOS since an object has multiple entry
> > points as opposed to a single "run -- exit" sequence.
> >
> > We provide inter-application communication by having standard object
> > sementics -- much like device independant I/O allows us to write programs
> > that will work on both files, terminals, pipes etc.
> > Call this polymorphism if you will.
> 
> I would want to have a device that take care of inter-process communication.
> You output data/code (in any object type, files, handels etc) to a device and
> then the device will transmitt it to the proper task, alternativily the device
> could transmitt a direct contact to another task.
> 
> > The fundumentals are
> >     * Multitasking (otherwise you can't have inter-application
> >             communication)
> >     * mountable devices
> >     * Remote Object Invocation (or whatever you want to call it)
> 
> Agree.
> 
> Dennis has a lot of remarks about GUIs in his follow up.
> I mostly agree with what he says there.
> There is also a lot of talk about making it an OS for the programmer.
> This can be difficult to acomplish, but I'll do my best to show how this could
> be done with my model.
> 
> Imagine an object. You attach to/inherit this object. Whenever an event
> arises the object will raise the attached object/overloaded method.
> 
> Take Windows as an example. It is event driven. Whenever something happens
> in the world (of IO devices) that windows knows of it posts/sends a message
> to a function that is known by windows. Then that function must classify
> the message and take any appropirate action, or just let it pass to a standard
> function.
> This is not very programmer friendly. Windows programming is so cumbersome
> that nobody has time to do anything useful other than just make the UI work.
> The system is unstable and it is difficult to scope up the basic ideas.
> (And remember the recommendations that every program should support the
> minimum of DDE, how many apps. does/did this?)
> 
> Now, envision a system where the programmer just writes a member function
> of an object that he has inherited. Say the base class he has inherited is
> a keyboard device. Now, when the keyboarddevice is activated it will pass its
> data up to the function he has written. As opposed to windows where the
> "device" just passes a message to a function.
> The base object will resort the correct action, not the programmer, and thus
> we will lessen the chance of a faulty program.
> The programmer can concentrate on making his program, not on when to do what,
> or vice versa.
> 
> Overloading of (base member) functions gets important beacuse this is one way
> to solve it with, and possible the most simple.
> This will be some type of DDVT (Dynamic Dispatch Virtual Table), where each
> device will have his own ddvt.
> If the function is not overloaded it will just use the standard way of
> resolving the situation.
> 
> Well that was a small begining, flame on or ask me if there is anything
> unclear. Tell me if this could be a possible way of doing this. Does
> anybody agree with me?
> 
> Arff
> sig.'s in for 1000 miles service
>         --Andreas Arff          andreasa@dhhalden.no--
> 
> 

Sounds complex.

Does anyone think it might be a good idea to knock up a prototype of the 
interface to get an idea of what it's like to write applics under the system?


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From rideau@clipper Thu Mar 18 03:16:00 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04322; Thu, 18 Mar 93 03:15:57 +0100
Return-Path: <rideau@clipper>
Received-Date: Thu, 18 Mar 93 03:15:57 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19912; Wed, 17 Mar 93 18:08:40 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fregate.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04105; Thu, 18 Mar 93 03:08:30 +0100
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303180208.AA04105@clipper.ens.fr>
Subject: Re: ORG, ROI, pem - Specification 03/16/93
To: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Date: Thu, 18 Mar 93 3:08:31 MET
Cc: moose-programmers@sfu.ca
In-Reply-To: <9303170906.AA15128@sc.zib-berlin.dbp.de>; from "Peter Mueller" at Mar 17, 93 10:06 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(reply to Peter)
> Howdy! 
>  
> In this mail I will give you a first specification of remote object 
> invocation. There were no (zero!) responses to my previous mail. I get 
> a little confused, have I said something wrong? Don't you have enough 
> time to think it over? Well, I actually assume, that some of you have 
> not received my mail and I've sent out an acknowledgement request. 
(Hey ! I did answer your message; didn't you receive my reply ?)

> As I pointed out in previous mails, I'm an advocate of a strict separation 
> between design/specification and implementation. So, the specification only
 I guess we all are; if someone disagrees, let him tell it loud. This does
not mean we can't propose an efficient implementation together with some
specs.


> R e m o t e   O b j e c t   I n v o c a t i o n 

> Specification Release 0.00 (03/16/93) 

I'd call it only Meta-ROI; for you don't say anything about direct ROI, but
only about how to get to be able to do ROI.

> 1 Overview 
> ========== 

>    This specification will give an abstract view on how remote object 
> invocation is done in MOOSE. Remote object invocation (ROI) means to invoke 
> a method from an object, which is not sharing the invoker's address space. 
> Thus, `remote' in this context means still both invoker and invokee be 
> running on the same machine. (This restriction will disappear, when MOOSE 
> becomes a distributed OS. Then `remote' means not the same address space or 
> even on a remote machine.) 
 I totally agree; MOOSE should be able to adaptate to distributed systems
(won't even the Pentium have two CPU's ?).

> [...]

> 2 Design goals 
> ============== 
>  
>   The following points give an overview of desired characteristics for ROI.
> Thus, ROI should be: 
>  
>      1. general
>      2. object location transparent
>      3. very efficient regarding communication costs
>      4. user-friendly
ok.

> 2.1 Generality
> --------------

>    ROI must be provided for a variety of objects, which can be wide spreaded
> among different applications as well as different contexts or privilege
> levels.
 Yes, that's why some type checking must be available for objects to properly
connect. This checking may also allow type casting and/or conversion. Of
course, types won't have to be checked at each transmission; only at
connection time (upon call to the name server).


> 2.2 Object Location Transparency
> --------------------------------

>    Most objects within MOOSE are location independent; it is not definitely
> clear where the object exist at a given time. Additionally, objects are
> created dynamically in a non-deterministic fashion.
>
>    Mechanisms are needed which provide a mapping function from an object's
> description to its actual location. These mechanisms are provided by a
> special kind of server object, the NAME SERVER. Name servers know the
> absolute locations of their objects and make them transparently available
> to other objects. 
 The "name server" name takes into account only part of the various aspects
of this object. This object is also a client to memory, to any library/module/
object publishing to it, etc. And it's a very technical term. I prefer the
"dictionary" name, or something like that (well, after all, let's have this
name fight a minor issue; Dennis will ultimately decide).


> 2.3 Efficiency
> --------------

>   As one design goal of MOOSE is to provide a highly dynamic system, where 
> components are added on the fly, ROI will be a highly used communication 
> mechanism. Almost all traditional operating system services are provided by 
> independent objects.
 I couldn't agree more.

>   Therefore ROI must be very efficient to minimize the
> remote invocation overhead. This can only be reached if very efficient IPC
> mechanisms exist. Thus the kernel must provide very fast IPC (which is to be
> specified in another release).
 Well, to me, ROI & IPC ARE JUST THE SAME.


> 2.4 User-friendliness 
> --------------------- 

>   Users and their applications should not be aware of ROI. If an
> application needs to invoke methods of a remote server it should simply
> instance an appropriate client object. All necessary ROI stuff should be
> done by creation of the client, which then provides a transparent view to
> the servers' methods.
>   Surely there must exist mechanisms, which allow to interfere in the ROI
> process as much as the user want. Eg, it must be possible to ask a specific
> name server for a server object's location.


> 3. Object Identification
> ======================== 

>    To give access to a server's method the server must be known to all
> possible clients. Thus the client must have the functionality to identify
> the right server. Identifying can be done in several ways, eg.:

>      1. by name
>      2. by description
>      3. by value
absolutely agreed; you can ask the dictionary to find an object considering
restrictions on its name, its type, and/or its value. So that's not only a
NAME server, but it's an OBJECT server.

> This specification will only handle the first one, nameing.
Yes; to begin with, let's have only the name. We'll add other features in
next versions.

> 3.1 Nameing
> -----------

>  A server can be unambiguously identified by its name. A `name' is a unique
> identifier within a given context, its `scope'. Note that several scopes may
> coexist at the same time, eg. each application may have its own name scope.
> This facilitates that multiple objects with the same name may coexist, but
> each one must reside in its own scope.
 Well, I'd see it more like an structured object language symbol table:
the server returns (if it exists) the latest (with respect to structure
hierarchy) object fitting the name and typing restrictions.


>    A server is now an object, which can be seen as a tuple, combining a name
> with provided services. To make these services available, the server
> publishes its name within the desired scope by contacting the appropriate
> name server. This is illustrated in Fig. 1:
 I know you like figures; but you already explained that, and I already
agreed, so I won't quote you again, so you won't enjoy being quoted :-)

> 3.2 Name scopes 
> --------------- 

>   A scope is created whenever a name server is started. Thus all known names
> to a name server form the name server's scope. An application, which create
> a name server have the ability to build up its own scope, allowing it to
> redefine names as needed. Eg, it's possible to `overwrite' an existing file
> server to an application specific one, which always encrypt data on writing
> and decrypt it when reading. The application's file server can then be an
> inherited file server, which is specialized for encryption. Of course it can
> use methods from the `traditional' file server.
More generally, and as I previously posted, dictionaries are a virtual
recursive type, so that anyone can create a new kind of dictionary (example:
DOS partition dictionary; ZIP file dictionary; encrypted dictionary, etc),
and any object can use any dictionary as part of it's own dictionary.

>    One question arises: What is the first scope OR where is the location of
> the first name server?
No need for that; each object is provided a dictionary upon its creation.
The bootstrap's object dictionary recursively contains everything; it may
give part of it only to sub-objects.

>    As almost all traditional operating system services are done by objects,
> there's the need for an default name server (DNS). DNS is installed at
> system startup, providing the first name scope, which holds information
> about, for example, the file server, printer server or disk servers. DNS
> is the only object which must be installed at a well known location (or:
> the kernel must provide a service to get its location).
I always agree (whereas always not with the name. main/home/root library/
dictionary/directory would be as fine.)


>         +-------------+  client request or server registration 
>         | Application |----------+ 
>         +-------------+          v 
>                  |   ^        +-----+ 
>          ask for |   |        | DNS | 
>           DNS by |   |        +-----+ 
>          request |   |           | 
>                  |   | return    | bounded 
>                  |   | DNS       | location                User level 
>       ...........|...|...........|................................... 
>                  v   |           |                       Kernel level 
>                 +-------------+  | 
>                 |   Kernel    |--+ 
>                 | +---------+ | 
>                 | | Nucleus | | 
>                 +-+---------+-+ 
>  
> Fig. 3 

I don't agree ; here is my proposition:

>         +-------------+    Kernel   +----------------+
>         | An Object   |<----------->| its dictionary |
>         +-------------+    = ROI    +----------------+
> Fig. 3 b

>    A DNS location request solved by a kernel service is shown in Fig. 3. For
> simplicity only two privilege levels are shown, user and kernel level. 
My figure has no privilege levels. No such thing is needed. Kernel is ROI.

> application, wishing to use services of a remote server object or to install
> a new server in the default name scope, must first find out the DNS
> location. It initiates a request to the kernel, which returns the current
> DNS location. Then the application can contact the DNS as usual.
It will publish to its know dictionaries: its own, and those present inside
its own. Dictionaries are free to accept or refuse publication and possibly
to spread it.

>    Providing a kernel service have the advantage, that access to the DNS
> is location transparent. The system is free to place the DNS as it wishes.
> It has the disadvantage, that a kernel request must be additionally done to
> find out its location. But for flexibility the advantage outweights the
> disadvantage.

>    All necessary communication stuff for finding the DNS location should be 
> encapsulated in clients or servers, respectively. If no other attributes are
> specified the DNS should be used automatically. Of course, an application, 
> which creates its own name server can declare this server as its DNS. Then 
> this name server is used, if no further attributes are given. 
ok

> 3.3 Addressing 
> -------------- 

>    The name server is responsible to map a received name into an useful 
> object location. This can be done either direct or indirect. A direct mapping 
> function can calculate the location from the name, as shown in Fig. 4: 
>  
>  
>       +------+  Mapping function   +-------------------+ 
>       | Name |-------------------->| Object's Location | 
>       +------+                     +-------------------+ 
>  
> Fig. 4 
>  
>  
>    This is usually done by makeing the object's location part of the name. 
> This has one great disadvantage. Consider the case, where several clients 
> exist, which all want to use services of one server. Then all these clients 
> will use the same name. For some reason the server must be migrated to 
> another location. Then all names are invalid. 

>    A second approach is to map a name to an `address' which then can be 
> mapped to the object's location (Fig. 5). If the destination object migrates 
> only the address must be changed. All names will still be valid. 
>  
>  
>       +------+         +-------------------+ 
>       | Name |         | Object's location | 
>       +------+         +-------------------+ 
>          |                ^ 
>          |                | 
>          |   +---------+  | 
>          +-->| Address |--+ 
>              +---------+ 
>  
> Fig. 5 
>  
>  
>    With this approach a name can be very small. They only have to provide 
> all necessary information to indicate an address. 
>  
> ----- Cut here ----- 
>  
> To all of you, who want to see a more `implementation' oriented version 
> I will now present examples, how an user should be able to use ROI 
> in his/her application. All definitions are specified in a syntax similiar 
> to those of C++. Note: This is still a conceptual model! At the end I will 
> present problems which arise at this layer. 
 C++ is good, but it is unstructured (all data global or local), and allows
object handling only at compile time; no execute time handling is provided.

> Examples
> ========

> Problems 
> ======== 
>  
> What, when public methods of a server call private methods? 
> ----------------------------------------------------------- 
>  
>    Private methods are able to change the server's state. There must be 
> mechanisms which avoid an influence from one client to another client's 
> point of view to this state. Thus, each client must see it's own server 
> state. 
?
Each client manages its dictionary itself; but the dictionary is given
objects at the beginning.

> What, when a server chooses a name which is already occupied by another 
> server?
The older one is hidden by the newer; See Pascal and such structured
languages.

> ----------------------------------------------------------------------- 
  
>  This leads to a name conflict, which must be solved. The name server will
> deny the request and the server is not published. Thus, the provided
> services are not available. 
I prefer the previous solution; or you may choose between those two.
  
> What, when a client cannot locate an appropriate server? 
> -------------------------------------------------------- 
Then it cannot use it !

>    There are two reasons for this problem: First, there's no server 
> available. Then the client can simply create a new server instance. This
> instance will then publish itself to the name server, which was asked by the
> client. In this case the client knows the server's location. There's no need
> to ask the name server again. 
>  
>    Second, there's a server using the name, but which is not appropriate
> because it have the wrong type. There must be a mechanism which ensures
> that the returned server is useful for the asking client.
Well, you see there's a need for typing !

 To sum up my comments: I totally agree with what you wrote (whereas I stick
to the dictionary name for NAME SERVER; name server is too technical;
dictionary is just fine). HOWEVER, this just isn't enough, for names don't
suffice, and we have to define what a direct link is, and include typing into
it; for if we have no typing, there is no objects.
 So let's define objects, which are our main problem.
 I will next; but now I'm going to bed.

 Goodbye !

    ,
 Fare, 200% time MOOSE programmer.

From mueller@sc.ZIB-Berlin.DE Thu Mar 18 12:46:11 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01329; Thu, 18 Mar 93 12:46:09 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Thu, 18 Mar 93 12:46:09 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07723; Thu, 18 Mar 93 03:40:09 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA22845; Thu, 18 Mar 93 12:40:02 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA16840; Thu, 18 Mar 93 12:40:01 +0100
Date: Thu, 18 Mar 93 12:40:01 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303181140.AA16840@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: ORG, ROI, pem - Spec. 03/16/93, defence (long)
Status: OR

Hi, 

I've read comments about my specification on ROI. Let me comment things, which can be 
done on the fly. Though there are some suggestions, which require a deeper look.
I will think about them this weekend.

comments to arff:
> [...] with nucleus do you mean the innermost kernel?

In previous mails there was a kind of call to provide a kernel-within-the-kernel which 
should handle the most elemental stuff. I suggest the name `nucleus' for this `little' 
kernel. (But that's not my creation. It's used in several other OSs ... :-)

> I'm not sure, that the kernel should provide IPC.

IPC requires copy of data from one into another address space. Thus the entity providing 
IPC must have enough privileges to write into foreign data space. The question, where 
the entity actually resides must be answered with the requirements in mind. IPC must be 
fast. Very fast. Maybe it is possible to provide the fastest IPC within a device (though 
there maybe is an overhead: the device is `scheduled' by the kernel. Thus kernel
calls are made which contradicts the requirements of IPC.) Nevertheless, the idea to put 
IPC in an IPC-device sounds good. Note: IPC in current systems is the main factor for 
performance lost.

> Identifying objects by description ...

With `description' I mean a possibility to request some kind of service with a given 
quality. If you know of transport protocols as they are specified in - I think - OSI, 
you will know what I mean. You can distinguish between at least 4 classes of transport
protocols, each providing the same service, to transport data from one to another
entity. They differ in the handling of, eg., error conditions. Where the first class 
assume that the underlying communication medium requires no error handling at all, the 
last class assume just the opposite. The medium isn't safe, thus, it provides error 
checking and correction. The first one is fast, because there's no error handling 
overhead, whereas the second is slower but safe.
   An object can request a transport protocol with a desired quality. If you declare the 
description of the desired quality as an own language, then you may call it `description 
language'. But there's only a change in the request to the directory (dedicted to Fare').
To the name (for example `transport') a description of the desired quality is added. The
directory can then choose the right object, fulfilling the requestor's needs.

> Identifying objects by value.

Maybe I should have said 'identifying by state'. With this you can ask for a server which 
is in a desired state. (Sorry, I currently have no example by hand.)

> Password stuff

Simply rename what I've called 'name' into 'ticket'. If an object
sends a request it must have the right ticket, so it is allowed to
ask for the requested service. (This leads to capabilities. Please
give me the weekend to think it over in more detail.)

> Actually, I liked the draft more than the example.

Sorry. I bet your pardon ... ;-) And thank you: You gave me the
word I've been searching for: It's more a draft than a spec.
 
> Following your concept each object seems to be very "private".
> A task knows what he wants (by name?/!) and uses it.
> Now another task need the same service, but he doesn't know the objects name.
> How can he know how to use it then?
> 
> It looks like we have to define several types of base objects with a set of
> minimum defined functions to let it become an object that can be used by the
> name server as a public object.
> I don't think a task should know everything about the object he want to use.
> 
> I'll give you an example:
> 
>   Take a picture viewer. It doesn't contain any code itself to show
>   any picture, he relies on objects that he can reach through the name
>   server.
>   How can it know what objects to ask for without a uniform description
>   language. How can it know how to use the object without knowing something
>   about it's capabilities.
>
> Maybe I have missed something fundamental (trying desperate to reach the Tao).

Ok. I will do what I can to let you reach the Tao. Here is, how I would include
your example in my 'system'. Let's first make two assumptions:

1. The picture viewer knows the format of the picture.
2. There are no other objects, which want to display pictures (I come back to
   this point later).

The first points enables the viewer to choose the right display server. With the
second point there's no need to make all possible display servers available via
a name server. You can manage the viewing of the picture with less overhead:

a. The viewer receives a request to display a picture, eg. via ROI.
b. Depending on the picture's format it creates a new instance of an appropriate
   display server. (It actually knows the server's location, hence, it must NOT
   ask any name servers.)
c. After displaying the picture, the server terminates (or, after the picture must
   no longer be present).

Now let's change assumption 2 to the following:

2. There are other objects, which want to display pictures.

As displaying a picture can be a very application dependent task, you can simply
let all objects create their own display server instance. (Well, then you might have
several copies of the same server, each running in its own name scope.)
As each application knows the name of its server, there are no identifying problems.

If you don't want to have multiple copies of the same display server running the 
following scenario is what I would expect.

Some nice human have made a display server available. He/She will then provide two 
objects: First, a server and second a client object. (The latter must be made available
for all those other humans, designing applications which want to display a picture.) 
In the applications this client object is used to request services from the newly 
available server, which must be present in the appropriate name scope. 

The next step is to make several displaying servers available within an application. You
mentioned it already: There's a base object, describing services which must be provided
by a display server. The application creates an instance of this base object, and identify
the right server by its name.

I don't think that providing base objects is such a great problem. It's the key issue in
object-orientated design. So each one, developping servers or devices (here they are again!)
should first develop a useful abstract base class.

> Correct me if so.

Dito. :-)
> 
> Arff
> 
> PS. Peter, I must say once more that the only thing that has brought MOOSE a
> similar step forward was rev. -72 :-) from Dennis, keep up your good work,
> both of you!.

Thank you.

comments to Fare':
==================

> (Hey ! I did answer your message; didn't you receive my reply ?)

No, I don't.

 
> I'd call it only Meta-ROI; for you don't say anything about direct ROI, but
> only about how to get to be able to do ROI.

I will refer to this terms later, when you mention, that "ROI and IPC are just
the same". Sorry, they are not.

> 
> 
> > 2.2 Object Location Transparency
> > --------------------------------
> 
> >    Most objects within MOOSE are location independent; it is not definitely
> > clear where the object exist at a given time. Additionally, objects are
> > created dynamically in a non-deterministic fashion.
> >
> >    Mechanisms are needed which provide a mapping function from an object's
> > description to its actual location. These mechanisms are provided by a
> > special kind of server object, the NAME SERVER. Name servers know the
> > absolute locations of their objects and make them transparently available
> > to other objects. 
>  The "name server" name takes into account only part of the various aspects
> of this object. This object is also a client to memory, to any library/module/
> object publishing to it, etc. And it's a very technical term. I prefer the
> "dictionary" name, or something like that (well, after all, let's have this
> name fight a minor issue; Dennis will ultimately decide).
> 

I don't think, that "name server" is a very technical term. But you're right: 
There's no need for a name fight. We can use dictionary. (But how would you
call an entry within this one? A key? Index? ... :-)

> 
> > 2.3 Efficiency
> > --------------
> >
> >   Therefore ROI must be very efficient to minimize the
> > remote invocation overhead. This can only be reached if very efficient IPC
> > mechanisms exist. Thus the kernel must provide very fast IPC (which is to be
> > specified in another release).
>  Well, to me, ROI & IPC ARE JUST THE SAME.

Now it's time to separate the terms ROI and IPC. ROI is very similiar to the well
known RPC. It's only a concept, defining how one object can invoke another object's
methods. There is no specification on how this is actually done. There are no send
or receive primitives. To provide ROI there must exist these mechanisms. As RPC is
packed upon transport protocols, ROI must also be packed upon protocols, etc. (And to
Gary: After thinking some days, I agree: RPC is NO implementation detail. I think,
I've mixed up real RPC implementations with the RPC idea.) Well, actually ROI is
a special kind of RPC, used in object-orientated environments. Because RPC isn't
enough anymore (and to avoid mixing up invocation with procedure call) the term ROI was
minted (my dictionary told me that's the word I would use in German ...).

Again, ROI is only a concept. The actual definition is done via IPC, where an
invocation is mapped into send and receive primitives. Thus, IPC is nearer to
implementation than ROI. In an IPC specification you will see definitions of
communication primitives, protocols, and communication units.

> 
> > 3. Object Identification
> > ======================== 
> 
> >    To give access to a server's method the server must be known to all
> > possible clients. Thus the client must have the functionality to identify
> > the right server. Identifying can be done in several ways, eg.:
> 
> >      1. by name
> >      2. by description
> >      3. by value
> absolutely agreed; you can ask the dictionary to find an object considering
> restrictions on its name, its type, and/or its value. So that's not only a
> NAME server, but it's an OBJECT server.

Oh, let's simply say dictionary. There's no need for the term OBJECT SERVER.

> 
> > 3.1 Nameing
> > -----------
> 
> >  A server can be unambiguously identified by its name. A `name' is a unique
> > identifier within a given context, its `scope'. Note that several scopes may
> > coexist at the same time, eg. each application may have its own name scope.
> > This facilitates that multiple objects with the same name may coexist, but
> > each one must reside in its own scope.
>  Well, I'd see it more like an structured object language symbol table:
> the server returns (if it exists) the latest (with respect to structure
> hierarchy) object fitting the name and typing restrictions.
> >
> > 3.2 Name scopes 
> > --------------- 
> 
> >   A scope is created whenever a name server is started. Thus all known names
> > to a name server form the name server's scope. An application, which create
> > a name server have the ability to build up its own scope, allowing it to
> > redefine names as needed. Eg, it's possible to `overwrite' an existing file
> > server to an application specific one, which always encrypt data on writing
> > and decrypt it when reading. The application's file server can then be an
> > inherited file server, which is specialized for encryption. Of course it can
> > use methods from the `traditional' file server.
> More generally, and as I previously posted, dictionaries are a virtual
> recursive type, so that anyone can create a new kind of dictionary (example:
> DOS partition dictionary; ZIP file dictionary; encrypted dictionary, etc),
> and any object can use any dictionary as part of it's own dictionary.
> 
> >    One question arises: What is the first scope OR where is the location of
> > the first name server?
> No need for that; each object is provided a dictionary upon its creation.
> The bootstrap's object dictionary recursively contains everything; it may
> give part of it only to sub-objects.
> 

Actually, I don't see any difference to my approach, besides the fact, that you want
each object to have its own dictionary, whereas I want to have each object decide
if it needs one. If there's the need then the object can create a new dictionary
instance, simultaneously creating a new scope, which may overlay the previous one. 
 
 
> I don't agree ; here is my proposition:
> 
> >         +-------------+    Kernel   +----------------+
> >         | An Object   |<----------->| its dictionary |
> >         +-------------+    = ROI    +----------------+
> > Fig. 3 b
> 
> >    A DNS location request solved by a kernel service is shown in Fig. 3. For
> > simplicity only two privilege levels are shown, user and kernel level. 
> My figure has no privilege levels. No such thing is needed. Kernel is ROI.

See my comments on ROI and IPC.

   
> > To all of you, who want to see a more `implementation' oriented version 
> > I will now present examples, how an user should be able to use ROI 
> > in his/her application. All definitions are specified in a syntax similiar 
> > to those of C++. Note: This is still a conceptual model! At the end I will 
> > present problems which arise at this layer. 
>  C++ is good, but it is unstructured (all data global or local), and allows
> object handling only at compile time; no execute time handling is provided.

Again, this is still conceptual! I used C++ syntax, because I'm knowing it. I 
only want to show, how I would use ROI in an implementation layer ...

 
> > Problems 
> > ======== 
> >  
> > What, when public methods of a server call private methods? 
> > ----------------------------------------------------------- 
> >  
> >    Private methods are able to change the server's state. There must be 
> > mechanisms which avoid an influence from one client to another client's 
> > point of view to this state. Thus, each client must see it's own server 
> > state. 
> ?
> Each client manages its dictionary itself; but the dictionary is given
> objects at the beginning.

You still have the problem, what to do, when a remote object is called and the
called method changes the private state of the object. Another object, invoking
methods from the same remote object will see the changed state. That is not
desired. The private part must be separated for each calling object.

> 
> > What, when a server chooses a name which is already occupied by another 
> > server?
> The older one is hidden by the newer; See Pascal and such structured
> languages.

I don't think, this is a useful mechanism. Simply use creation of new name
scopes to hide equal names. If you hide a previous publication a client
cannot reach this "older" server.

> 
> > ----------------------------------------------------------------------- 
>   
> >  This leads to a name conflict, which must be solved. The name server will
> > deny the request and the server is not published. Thus, the provided
> > services are not available. 
> I prefer the previous solution; or you may choose between those two.
>   
> > What, when a client cannot locate an appropriate server? 
> > -------------------------------------------------------- 
> Then it cannot use it !
A little bit too fast ... ;-)

> 
> >    There are two reasons for this problem: First, there's no server 
> > available. Then the client can simply create a new server instance. This
> > instance will then publish itself to the name server, which was asked by the
> > client. In this case the client knows the server's location. There's no need
> > to ask the name server again. 

One solution.

> >  
> >    Second, there's a server using the name, but which is not appropriate
> > because it have the wrong type. There must be a mechanism which ensures
> > that the returned server is useful for the asking client.
> Well, you see there's a need for typing!

Yup. I totally agree. But that's fundamental to OO ;-)

> 
>  To sum up my comments: I totally agree with what you wrote (whereas I stick
> to the dictionary name for NAME SERVER; name server is too technical;
> dictionary is just fine). HOWEVER, this just isn't enough, for names don't
> suffice, and we have to define what a direct link is, and include typing into
> it; for if we have no typing, there is no objects.

Ok. But in ROI the typing mechanism is an assumption. ROI uses the OO paradigm 
to invoke remote methods. Typing is implicit. So, a ROI specification must not
necessarily include how typing is done.

>  So let's define objects, which are our main problem.

That's a part of another specification. Need not to be done here.

Bye,

Peter

From mueller@sc.ZIB-Berlin.DE Thu Mar 18 13:56:52 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03868; Thu, 18 Mar 93 13:56:51 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Thu, 18 Mar 93 13:56:51 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08899; Thu, 18 Mar 93 04:52:52 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA22997; Thu, 18 Mar 93 13:52:19 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA16952; Thu, 18 Mar 93 13:52:18 +0100
Date: Thu, 18 Mar 93 13:52:18 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303181252.AA16952@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: ORG, ROI, pem - Specification 03/16/93
Status: OR

> From winikoff@cs.mu.OZ.AU Thu Mar 18 13:32:37 1993
> Subject: Re: ORG, ROI, pem - Specification 03/16/93
> To: moose-programmers@sfu.ca (Moose Project)
> Date: Thu, 18 Mar 93 22:29:01 EST
> From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
> X-Mailer: ELM [version 2.3 PL0]
> Content-Length: 1255
> 
> >  
> >      1. general 
> >      2. object location transparent 
> >      3. very efficient regarding communication costs 
> >      4. user-friendly 
> 
> Huh? My definition of user-friendly says that this is irrelevant to a system
> call ... 
> 
> >    Mechanisms are needed which provide a mapping function from an object's 
> > description to its actual location. These mechanisms are provided by a 
> 
> We need to specify the description format.
> Strings are the obvious simple choice.
> 
> > 2.4 User-friendliness 
> > --------------------- 
> >  
> >    Users and their applications should not be aware of ROI. If an application 
> > needs to invoke methods of a remote server it should simply instance an 
> > appropriate client object. All necessary ROI stuff should be done by creation 
> > of the client, which then provides a transparent view to the servers' 
> > methods. 
> 
> Please keep client-server and ROI seperate.
> ROI is a system call (service?) we are desigining which can be used to 
> implement a client server relationship.

I've mentioned that I use the terms client and server, because their functionality
is well known. When an object wants to invoke a remote object's methods, the first one
requests a service from the latter. Maybe I should have used the terms invoker and
invokee ...

AND: ROI is *no* system call. It's a conceptual model, which allows an invocation between
two remote objects as if they were local. 

> 
> We shouldn't constrain the user of ROI to a client server setup.

Ok, I suppose you get stuck, because I've used the terms within my examples, too. If you want
to provide mechanisms like callbacks in RPC you can do it in such a way:

	LOCALOBJECT.doSomethingRemote(myself);

myself is then the reference to the invoking object. Now the invokee can invoke objects from
the invoker (in the remote object):

	REMOTEOBJECT::doSomethingRemote(LOCALOBJECT &caller) {
		caller.doSomethingElse();    // This can be seen as a call back ...
	}

So, there is the possibility to communicate in both directions. ROI will give no constraints
about the communication style!	

Sorry, that I've used these two terms which leads to misunderstanding. I will keep the next 
specification cleaner.

Cheers,

Peter

P.S.: Can someone please explain what `IMHO' stands for? 

From winikoff@cs.mu.OZ.AU Thu Mar 18 13:33:37 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02996; Thu, 18 Mar 93 13:33:36 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 18 Mar 93 13:33:36 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08539; Thu, 18 Mar 93 04:29:06 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA01651
	Thu, 18 Mar 1993 22:29:01 +1000 (from winikoff)
Message-Id: <9303181229.1651@mulga.cs.mu.OZ.AU>
Subject: Re: ORG, ROI, pem - Specification 03/16/93
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 18 Mar 93 22:29:01 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303170906.AA15128@sc.zib-berlin.dbp.de>; from "Peter Mueller" at Mar 17, 93 10:06 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

>  
>      1. general 
>      2. object location transparent 
>      3. very efficient regarding communication costs 
>      4. user-friendly 

Huh? My definition of user-friendly says that this is irrelevant to a system
call ... 

>    Mechanisms are needed which provide a mapping function from an object's 
> description to its actual location. These mechanisms are provided by a 

We need to specify the description format.
Strings are the obvious simple choice.

> 2.4 User-friendliness 
> --------------------- 
>  
>    Users and their applications should not be aware of ROI. If an application 
> needs to invoke methods of a remote server it should simply instance an 
> appropriate client object. All necessary ROI stuff should be done by creation 
> of the client, which then provides a transparent view to the servers' 
> methods. 

Please keep client-server and ROI seperate.
ROI is a system call (service?) we are desigining which can be used to 
implement a client server relationship.

We shouldn't constrain the user of ROI to a client server setup.

I agree with your stuff about nameservers with the reservation that a nameserver
shouldn't have a special role -- it should just be an object that implements
a dictionary of some sort.



From winikoff@cs.mu.OZ.AU Thu Mar 18 13:38:37 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03140; Thu, 18 Mar 93 13:38:36 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 18 Mar 93 13:38:36 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08567; Thu, 18 Mar 93 04:31:31 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA01728
	Thu, 18 Mar 1993 22:31:25 +1000 (from winikoff)
Message-Id: <9303181231.1728@mulga.cs.mu.OZ.AU>
Subject: Re: Libraries
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 18 Mar 93 22:31:24 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <MAILQUEUE-101.930317102504.800@sofus.dhhalden.no>; from "Andreas Arff" at Mar 17, 93 10:25 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> > > I can't see doing away with the concept of a library - our system stuff itself
> > > may need 20 to 30 modules, the GUI may need 10 or 20, and so on.  Combining
> > > these into a library simplifies life on disk, so this is a concept important
> >
> > You're more or less assuming a comventional file-system that doesn't like
> > small files -- this is not a good thing to assume automatically.
> 
> After all a disk is a disk. Even though your system equally "likes" large and
> small files, it doesn't automatically mean that it will be equally efficient.
> It is faster to load one large file (if it is contigous) with subfiles in it,
> than 50 small files (spread over the disk).

The point I was trying to make was that if we are going to support small objects
we're going to have to do it eficiently -- there's little point (IMHO) in 
saying we have an OO system that supports small objects where in practice
small objects are too inefficient to be used.

If we intend to use smal objects then the system should support them efficiently.


From winikoff@cs.mu.OZ.AU Thu Mar 18 13:40:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03207; Thu, 18 Mar 93 13:40:26 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 18 Mar 93 13:40:26 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08633; Thu, 18 Mar 93 04:35:11 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA01986
	Thu, 18 Mar 1993 22:35:06 +1000 (from winikoff)
Message-Id: <9303181235.1986@mulga.cs.mu.OZ.AU>
Subject: Re: ORG, ROI, pem - Specification 03/16/93
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 18 Mar 93 22:35:05 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <MAILQUEUE-101.930317112545.1216@sofus.dhhalden.no>; from "Andreas Arff" at Mar 17, 93 11:25 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> I'm not sure I agree with that the kernel should provide the IPC. Remember
> to keep it small and clean. I would rather put the ROI into its own ROI-device.
> (oooh no, don't start to talk about devices again Andreas :-)

How do we ask the ROI device to do ROI? 
Answer: Through Inter Process Communication (IPC)

IPC simply means a facility for comminucating between processes.
Some form of it HAS to be provided in the kernel (IMHO)

> 
> One thing that I think should be possible; make an object private. You have
> to know a "password" to use it or something like that.

The object can take an extra argument (the password) and return an error
without doing anything if the password is wrong.

> 
> Maybe I have missed something fundamental (trying desperate to reach the Tao).
> Correct me if so.

A NAMESERVER (Aka Dictionary) is the solution.
One has a dictionary (either becuase the shell gave you one when you were 
created or because you asked the kernel for the default name server) which
one can ask about objects and use it to find interesting objects.

In some sense the dictionary is just like a directory (only it points to 
objects rather then files)

> 
> Arff
> 
> PS. Peter, I must say once more that the only thing that has brought MOOSE a
> similar step forward was rev. -72 :-) from Dennis, keep up your good work,
> both of you!.
> DS.
>   Arff
> sig.'s in for 1000 miles service
>         --Andreas Arff          andreasa@dhhalden.no--
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Thu Mar 18 13:46:15 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03364; Thu, 18 Mar 93 13:46:14 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 18 Mar 93 13:46:14 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08702; Thu, 18 Mar 93 04:40:23 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA02129
	Thu, 18 Mar 1993 22:40:10 +1000 (from winikoff)
Message-Id: <9303181240.2129@mulga.cs.mu.OZ.AU>
Subject: Re:  Libraries
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 18 Mar 93 22:40:09 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303171813.AA01512@tdge15.intel.com>; from "Dennis Marer" at Mar 17, 93 10:13 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> *flame on*  This is the one assumption I completely disagree with!  IBM and
> Microsoft have made this assumption, and now you're *reccomended* to have 16MB
> of memory just to run OS/2 or Windows NT.  Sure, you can run with 4/8MB, but
> you'll be swapping from here to timbuktu. *flame off*

A pile of ashes.
Twin eyes blink in the pile.
<Cough, splutter> (clears dust from throat)
Ahh, you're  right ...

[I'd like to think that OS/2 and WNT failed because they didn't place the system
size as an important goal but this is a little naive ...]


Anyhow, I've more or less come to the conclusion that very small objects
(Eg. on the level of an array of primitive values) are unworkable.

Comments?

> 
> I can't tell if you want everything in one single file or everything in its
> own file...please explain your ideas more.  I just see the need for a logical
> way of dividing things: lots of relatively small objects (and functions and
> data items) go into a module to simplify management by the kernel.  Lots of
> modules can be placed into libraries to simplify management by the *user*.

I'd like to DEFINE a "file" as a (persistant) object that happens to 
support the 'usual' operations on files as methods.

> -------------------------------------------------------------------------------
> 
> Ok, so I'm not out to redesign every aspect of the concept of an operating
> system - I'm frustrated because it seems that's what we're trying to do.  I'm
> more interested in applying the concepts already in existence and developing
> something useful quickly instead of doing intensive research and testing of
> brand new ideas.  I'm not trying to re-write UNIX, but I'm also not trying to
> develop Amoeba (which has taken over 5 years so far).  What I want out of this
> project is something that is more *useful* to me than DOS or Windows, not
> something which takes the scientific world by storm.

Uhh, Dennis could you please repost this last paragraph in a separate mail
with anb URGENT tag and a "READ THIS" subject?

It's a much needed reminder, some of us ARE drifting of the track and trying
to be too ambitious (the technical term for this is reinventing the wheel :-)

> 
> 				Dennis
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Thu Mar 18 13:46:49 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03389; Thu, 18 Mar 93 13:46:48 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 18 Mar 93 13:46:48 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08738; Thu, 18 Mar 93 04:42:26 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA02196
	Thu, 18 Mar 1993 22:42:20 +1000 (from winikoff)
Message-Id: <9303181242.2196@mulga.cs.mu.OZ.AU>
Subject: Re: ORG, ROI, pem - Specification 03/16/93
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 18 Mar 93 22:42:20 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303180208.AA04105@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 18, 93 3:08 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> I don't agree ; here is my proposition:
> 
> >         +-------------+    Kernel   +----------------+
> >         | An Object   |<----------->| its dictionary |
> >         +-------------+    = ROI    +----------------+
> > Fig. 3 b
> 
> >    A DNS location request solved by a kernel service is shown in Fig. 3. For
> > simplicity only two privilege levels are shown, user and kernel level. 
> My figure has no privilege levels. No such thing is needed. Kernel is ROI.
> 
The DNS is ONLY used when boting the system.
It's role is to give the object it's dictionary.

If as you suggest an object gets given a dictionary when it is created then 
the DSN is only used for the initial object.

[Aside: I think dictionary's shouldn't be a special thing associated with an 
object -- any object that you know about that supports the right methods should
be a dictionary]




From danodom@matt.ksu.ksu.edu Sat Feb 13 00:46:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22239; Sat, 13 Feb 93 00:46:26 +0100
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sat, 13 Feb 93 00:46:26 +0100
Received: from matt.ksu.ksu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA02651; Fri, 12 Feb 93 17:46:32 CST
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9302122346.AA02651@matt.ksu.ksu.edu>
Subject: Moose (You guys...)
To: winikoff@cs.mu.oz.au (Winikoff), rideau@clipper (Rideau),
        newlin@ecn.purdue.edu (Newlin), mueller@sc.zib-berlin.de (Mueller),
        mckeeveb@sfu.ca (Mckeeveb), garfield@sra.com (Garfield),
        duzan@cis.udel.edu (Duzan), dmarer@td2cad.intel.com (Dmarer),
        danodom@matt.ksu.ksu.edu (Dan Odom), ANDREASA@dhhalden.no (Andreasa)
Date: Fri, 12 Feb 93 17:46:31 CST
X-Mailer: ELM [version 2.3 PL11]
Status: OR


Geez, I go out of town for one lousy week and you guys start
(semi-) interesting conversations without me!  Oh, well.

Revision -72 looked pretty fair, but I have a few minor things that
I would like to add/change/point out:

1)  Device Drivers:  We need to have user-installable device drivers.
      I personally prefer the Unix style of device driver, but the MS-DOS
      style isn't bad (it's just not as good, IMHO).  This way, we don't
      have to include ANY I/O in the kernel; we can have a device
      named 'STDOUT' or 'TTY' or 'CON', and that device will
      represent the screen.  Our C RTL can then send output from
      printf (), etc. to that device.

2)  Rather than saying 'This OS is a GUI!', I think that we should allow
      the user to write his/her own shell.  I personally would like
      a csh-ish interface; I could add my own.  One of my friends likes
      the X interface; he could add his own X-like interface.

3)  Making the kernel object-oriented would be a real pain in the rear,
      and also increase the amount of required memory.  I say that
      we do a traditional kernel, and then write OO shells for it in
      C++ and ObjectPascal.  That way, we'd still be able to code like:

         class MyInputDevice : public GenericInputDevice
           {
              ...
           }

      but the kernel could be kept simple.

4)  We need to spend quite a bit of time on the high-level specifications
      before we move on to the low-level stuff.  Let's not worry about
      implementation stuff until we've got the abstract stuff down.

*****

---> Dan

From MAILER-DAEMON@uunet.uu.net Sat Mar 13 11:15:16 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14520; Sat, 13 Mar 93 11:15:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20271; Sat, 13 Mar 93 05:15:07 -0500
Date: Sat, 13 Mar 93 05:15:07 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131015.AA20271@relay2.UU.NET>
To: <rideau@clipper>
Status: OR

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]


>> A possible means of making data objects available to other processes:
>> 
>> It is possible for
>> 
>>    1) All processes to be objects.
>>    2) Objects to be in the logical file system.
>>    3) Objects themselves be asked what objects are below them in the
>>       file system.

I think we agree, but I'd like to modify what you said:
1) EVERYTHING is an object; processes in particular.
2) I'd rather say the file system is included in the object system
(objects are files is the unix philosophy: you have only files,
and even to send/receive one integer number, you are bound to
use a (preferably ASCII) file).

>> With this setup, each process object is placed in the logical file
>> system.  Each process object may then be queried as to what public
>> objects it contains.  If a process is a 'dumb' program, this would
>> probably mean either nothing is public or a fixed list is public.  A
>> 'smart' program could either published all its objects or a portion of
>> its object list it selects.
The FS directory equivalent becomes what I previously called the dictionary.
You can even publish part of an object, that is, only part of its methods
are available. As each object has its dictionary, you can publish different
things to each of them.

>> As an additional capability, a 'smart' program could have objects
>> placed into the directory that it provides by other programs.  This
>> could be used as a means of specifically requesting communications
>> with a process.
I'm not sure of understanding what you said, but modifying an object
in a dictionary is a sure means of communication to all those who
read this dictionary. Also see my discussion with Peter Mueller about
naming.

>> Additionally, if an object can be placed in one place in the file
>> system, it can be placed in other 'known' places, allowing for the
>> publication of objects.
That's the multiple dictionaries I ask for.

>> One other capability allowed by mapping between directories and
>> objects is that something like a ZIP file (produced by PKZIP or the
>> like) could allow its contents to be directly accessed as a file.
>> Mapping between different styles of file systems could happen the same
>> way (assuming you want to nest filesystems).
Dictionaries should be a virtual object class, with standard methods, then
anyone could implement a new way of accessing objects. They also should
have a recursive definition, so that dictionaries can be part of another,
and there's no problem in mixing dictionary methods.

>> Note on terms:  I am using the term 'logical file system' to refer to
>> the effective file system that exists when the system is running.  In
>> Unix this is composed of the the root file system and any file systems
>> and network file systems mounted on it.  In the case of Moose, the
>> logical file system will (I hope) also include objects and other
>> things.
Each of us has his own terminology, inherited from his past experiences
and thinkings about computing. Let's not fight for names.
But if I prefer the object terminology to the file terminology, it's because
under existing systems, files are a closed inextensible system, with a
unique implementation oriented toward big file managing. Objects are
a generic extensible concept, which includes huge structures as well as
basic data.

>> -- 
>> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
>> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

   ,
Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
rideau@clipper.ens.fr


From MAILER-DAEMON@uunet.uu.net Sat Mar 13 11:29:15 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14774; Sat, 13 Mar 93 11:29:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:29:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA21241; Sat, 13 Mar 93 05:29:08 -0500
Date: Sat, 13 Mar 93 05:29:08 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131029.AA21241@relay2.UU.NET>
To: <rideau@clipper>
Status: OR

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA21226; Sat, 13 Mar 93 05:29:08 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14771; Sat, 13 Mar 93 11:29:04 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131029.AA14771@clipper.ens.fr>
Subject: Re: memory allocation (djg4)
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:29:03 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9aed66.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 1:53 am
X-Mailer: ELM [version 2.3 PL11]


>> I firmly believe that at the kernel level, a malloc() style memory
>> allocation interface should not exist.  Using malloc() does not allow
>> any chance for the application to control where the memory blocks are
>> placed.
 There should be different memory managers for all devices/apps/user
programs to match their need. For example very high-level programs
often need a garbage collecting feature, whereas low-level programs
would be only slowed by it. If you don't implement a GC memory manager,
each app will have to do its own, and inter-app object communication
will be made impossible or very, very difficult and slow. If you always
require GC compliancy, that will slow everything, and affect the system
security.
 To me, there should not be only ONE memory manager. Memory management is
not a Kernel feature; there are higher or lower level devices to manage
memory; but they have a standard interface, so that you don't need know
what's its memory manager to access an object.
 We can even build generic memory managers, to transform a low-level
one into a higher-level one by adding each time some features.
 So we start with physical memory, add virtual memory, add word aligned
blocks, add GC, etc. Each time, you can add it in part of the previous
manager; you can add it several times in different parts of the manager;
etc.
		   ,
		Fare



From rideau@clipper Mon Mar 15 00:36:00 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07210; Mon, 15 Mar 93 00:35:59 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17084; Sun, 14 Mar 93 15:32:23 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07132; Mon, 15 Mar 93 00:32:16 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14520; Sat, 13 Mar 93 11:15:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20271; Sat, 13 Mar 93 05:15:07 -0500
Date: Sat, 13 Mar 93 05:15:07 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131015.AA20271@relay2.UU.NET>
To: <rideau@clipper>
Sender: rideau@clipper
Status: OR

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]


>> A possible means of making data objects available to other processes:
>> 
>> It is possible for
>> 
>>    1) All processes to be objects.
>>    2) Objects to be in the logical file system.
>>    3) Objects themselves be asked what objects are below them in the
>>       file system.

I think we agree, but I'd like to modify what you said:
1) EVERYTHING is an object; processes in particular.
2) I'd rather say the file system is included in the object system
(objects are files is the unix philosophy: you have only files,
and even to send/receive one integer number, you are bound to
use a (preferably ASCII) file).

>> With this setup, each process object is placed in the logical file
>> system.  Each process object may then be queried as to what public
>> objects it contains.  If a process is a 'dumb' program, this would
>> probably mean either nothing is public or a fixed list is public.  A
>> 'smart' program could either published all its objects or a portion of
>> its object list it selects.
The FS directory equivalent becomes what I previously called the dictionary.
You can even publish part of an object, that is, only part of its methods
are available. As each object has its dictionary, you can publish different
things to each of them.

>> As an additional capability, a 'smart' program could have objects
>> placed into the directory that it provides by other programs.  This
>> could be used as a means of specifically requesting communications
>> with a process.
I'm not sure of understanding what you said, but modifying an object
in a dictionary is a sure means of communication to all those who
read this dictionary. Also see my discussion with Peter Mueller about
naming.

>> Additionally, if an object can be placed in one place in the file
>> system, it can be placed in other 'known' places, allowing for the
>> publication of objects.
That's the multiple dictionaries I ask for.

>> One other capability allowed by mapping between directories and
>> objects is that something like a ZIP file (produced by PKZIP or the
>> like) could allow its contents to be directly accessed as a file.
>> Mapping between different styles of file systems could happen the same
>> way (assuming you want to nest filesystems).
Dictionaries should be a virtual object class, with standard methods, then
anyone could implement a new way of accessing objects. They also should
have a recursive definition, so that dictionaries can be part of another,
and there's no problem in mixing dictionary methods.

>> Note on terms:  I am using the term 'logical file system' to refer to
>> the effective file system that exists when the system is running.  In
>> Unix this is composed of the the root file system and any file systems
>> and network file systems mounted on it.  In the case of Moose, the
>> logical file system will (I hope) also include objects and other
>> things.
Each of us has his own terminology, inherited from his past experiences
and thinkings about computing. Let's not fight for names.
But if I prefer the object terminology to the file terminology, it's because
under existing systems, files are a closed inextensible system, with a
unique implementation oriented toward big file managing. Objects are
a generic extensible concept, which includes huge structures as well as
basic data.

>> -- 
>> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
>> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

   ,
Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
rideau@clipper.ens.fr



From rideau@clipper Mon Mar 15 00:36:12 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07215; Mon, 15 Mar 93 00:36:11 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17098; Sun, 14 Mar 93 15:32:53 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07155; Mon, 15 Mar 93 00:32:47 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14774; Sat, 13 Mar 93 11:29:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:29:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA21241; Sat, 13 Mar 93 05:29:08 -0500
Date: Sat, 13 Mar 93 05:29:08 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131029.AA21241@relay2.UU.NET>
To: <rideau@clipper>
Sender: rideau@clipper
Status: OR

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA21226; Sat, 13 Mar 93 05:29:08 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14771; Sat, 13 Mar 93 11:29:04 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131029.AA14771@clipper.ens.fr>
Subject: Re: memory allocation (djg4)
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:29:03 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9aed66.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 1:53 am
X-Mailer: ELM [version 2.3 PL11]


>> I firmly believe that at the kernel level, a malloc() style memory
>> allocation interface should not exist.  Using malloc() does not allow
>> any chance for the application to control where the memory blocks are
>> placed.
 There should be different memory managers for all devices/apps/user
programs to match their need. For example very high-level programs
often need a garbage collecting feature, whereas low-level programs
would be only slowed by it. If you don't implement a GC memory manager,
each app will have to do its own, and inter-app object communication
will be made impossible or very, very difficult and slow. If you always
require GC compliancy, that will slow everything, and affect the system
security.
 To me, there should not be only ONE memory manager. Memory management is
not a Kernel feature; there are higher or lower level devices to manage
memory; but they have a standard interface, so that you don't need know
what's its memory manager to access an object.
 We can even build generic memory managers, to transform a low-level
one into a higher-level one by adding each time some features.
 So we start with physical memory, add virtual memory, add word aligned
blocks, add GC, etc. Each time, you can add it in part of the previous
manager; you can add it several times in different parts of the manager;
etc.
		   ,
		Fare




From rideau@clipper Mon Mar 15 01:45:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08634; Mon, 15 Mar 93 01:45:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18839; Sun, 14 Mar 93 16:41:03 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08559; Mon, 15 Mar 93 01:40:50 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07210; Mon, 15 Mar 93 00:35:59 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17084; Sun, 14 Mar 93 15:32:23 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07132; Mon, 15 Mar 93 00:32:16 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14520; Sat, 13 Mar 93 11:15:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20271; Sat, 13 Mar 93 05:15:07 -0500
Date: Sat, 13 Mar 93 05:15:07 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131015.AA20271@relay2.UU.NET>
To: <rideau@clipper>
Sender: rideau@clipper
Status: OR

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]


>> A possible means of making data objects available to other processes:
>> 
>> It is possible for
>> 
>>    1) All processes to be objects.
>>    2) Objects to be in the logical file system.
>>    3) Objects themselves be asked what objects are below them in the
>>       file system.

I think we agree, but I'd like to modify what you said:
1) EVERYTHING is an object; processes in particular.
2) I'd rather say the file system is included in the object system
(objects are files is the unix philosophy: you have only files,
and even to send/receive one integer number, you are bound to
use a (preferably ASCII) file).

>> With this setup, each process object is placed in the logical file
>> system.  Each process object may then be queried as to what public
>> objects it contains.  If a process is a 'dumb' program, this would
>> probably mean either nothing is public or a fixed list is public.  A
>> 'smart' program could either published all its objects or a portion of
>> its object list it selects.
The FS directory equivalent becomes what I previously called the dictionary.
You can even publish part of an object, that is, only part of its methods
are available. As each object has its dictionary, you can publish different
things to each of them.

>> As an additional capability, a 'smart' program could have objects
>> placed into the directory that it provides by other programs.  This
>> could be used as a means of specifically requesting communications
>> with a process.
I'm not sure of understanding what you said, but modifying an object
in a dictionary is a sure means of communication to all those who
read this dictionary. Also see my discussion with Peter Mueller about
naming.

>> Additionally, if an object can be placed in one place in the file
>> system, it can be placed in other 'known' places, allowing for the
>> publication of objects.
That's the multiple dictionaries I ask for.

>> One other capability allowed by mapping between directories and
>> objects is that something like a ZIP file (produced by PKZIP or the
>> like) could allow its contents to be directly accessed as a file.
>> Mapping between different styles of file systems could happen the same
>> way (assuming you want to nest filesystems).
Dictionaries should be a virtual object class, with standard methods, then
anyone could implement a new way of accessing objects. They also should
have a recursive definition, so that dictionaries can be part of another,
and there's no problem in mixing dictionary methods.

>> Note on terms:  I am using the term 'logical file system' to refer to
>> the effective file system that exists when the system is running.  In
>> Unix this is composed of the the root file system and any file systems
>> and network file systems mounted on it.  In the case of Moose, the
>> logical file system will (I hope) also include objects and other
>> things.
Each of us has his own terminology, inherited from his past experiences
and thinkings about computing. Let's not fight for names.
But if I prefer the object terminology to the file terminology, it's because
under existing systems, files are a closed inextensible system, with a
unique implementation oriented toward big file managing. Objects are
a generic extensible concept, which includes huge structures as well as
basic data.

>> -- 
>> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
>> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

   ,
Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
rideau@clipper.ens.fr




From rideau@clipper Mon Mar 15 01:45:55 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08659; Mon, 15 Mar 93 01:45:55 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18842; Sun, 14 Mar 93 16:41:13 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08562; Mon, 15 Mar 93 01:41:06 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14774; Sat, 13 Mar 93 11:29:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:29:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA21241; Sat, 13 Mar 93 05:29:08 -0500
Date: Sat, 13 Mar 93 05:29:08 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131029.AA21241@relay2.UU.NET>
To: <rideau@clipper>
Sender: rideau@clipper
Status: OR

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA21226; Sat, 13 Mar 93 05:29:08 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14771; Sat, 13 Mar 93 11:29:04 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131029.AA14771@clipper.ens.fr>
Subject: Re: memory allocation (djg4)
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:29:03 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9aed66.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 1:53 am
X-Mailer: ELM [version 2.3 PL11]


>> I firmly believe that at the kernel level, a malloc() style memory
>> allocation interface should not exist.  Using malloc() does not allow
>> any chance for the application to control where the memory blocks are
>> placed.
 There should be different memory managers for all devices/apps/user
programs to match their need. For example very high-level programs
often need a garbage collecting feature, whereas low-level programs
would be only slowed by it. If you don't implement a GC memory manager,
each app will have to do its own, and inter-app object communication
will be made impossible or very, very difficult and slow. If you always
require GC compliancy, that will slow everything, and affect the system
security.
 To me, there should not be only ONE memory manager. Memory management is
not a Kernel feature; there are higher or lower level devices to manage
memory; but they have a standard interface, so that you don't need know
what's its memory manager to access an object.
 We can even build generic memory managers, to transform a low-level
one into a higher-level one by adding each time some features.
 So we start with physical memory, add virtual memory, add word aligned
blocks, add GC, etc. Each time, you can add it in part of the previous
manager; you can add it several times in different parts of the manager;
etc.
		   ,
		Fare




From MAILER-DAEMON@hermes.intel.com Mon Mar 15 02:06:56 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09051; Mon, 15 Mar 93 02:06:55 +0100
Return-Path: <MAILER-DAEMON@hermes.intel.com>
Received-Date: Mon, 15 Mar 93 02:06:55 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by hermes.intel.com (5.65/10.0i); Sun, 14 Mar 93 17:06:07 -0800
Date: Sun, 14 Mar 93 17:06:07 -0800
From: MAILER-DAEMON@hermes.intel.com (Mail Delivery Subsystem)
Message-Id: <9303150106.AA22343@hermes.intel.com>
Subject: Returned mail: Service unavailable
To: postmaster@dmi.ens.fr
To: <rideau@clipper>
Status: OR

   ----- Transcript of session follows -----
>>> DATA
<<< 554 sendall: too many hops (17 max)
554 <dmarer@td2cad.intel.com>... Service unavailable

   ----- Unsent message follows -----
Received: from whistler.sfu.ca by hermes.intel.com (5.65/10.0i); Sun, 14 Mar 93 17:06:07 -0800
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19427; Sun, 14 Mar 93 17:04:10 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08997; Mon, 15 Mar 93 02:04:02 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08634; Mon, 15 Mar 93 01:45:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18839; Sun, 14 Mar 93 16:41:03 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08559; Mon, 15 Mar 93 01:40:50 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07210; Mon, 15 Mar 93 00:35:59 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17084; Sun, 14 Mar 93 15:32:23 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07132; Mon, 15 Mar 93 00:32:16 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14520; Sat, 13 Mar 93 11:15:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20271; Sat, 13 Mar 93 05:15:07 -0500
Date: Sat, 13 Mar 93 05:15:07 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131015.AA20271@relay2.UU.NET>
To: <rideau@clipper.ens.fr>
Sender: rideau@clipper.ens.fr

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]


>> A possible means of making data objects available to other processes:
>> 
>> It is possible for
>> 
>>    1) All processes to be objects.
>>    2) Objects to be in the logical file system.
>>    3) Objects themselves be asked what objects are below them in the
>>       file system.

I think we agree, but I'd like to modify what you said:
1) EVERYTHING is an object; processes in particular.
2) I'd rather say the file system is included in the object system
(objects are files is the unix philosophy: you have only files,
and even to send/receive one integer number, you are bound to
use a (preferably ASCII) file).

>> With this setup, each process object is placed in the logical file
>> system.  Each process object may then be queried as to what public
>> objects it contains.  If a process is a 'dumb' program, this would
>> probably mean either nothing is public or a fixed list is public.  A
>> 'smart' program could either published all its objects or a portion of
>> its object list it selects.
The FS directory equivalent becomes what I previously called the dictionary.
You can even publish part of an object, that is, only part of its methods
are available. As each object has its dictionary, you can publish different
things to each of them.

>> As an additional capability, a 'smart' program could have objects
>> placed into the directory that it provides by other programs.  This
>> could be used as a means of specifically requesting communications
>> with a process.
I'm not sure of understanding what you said, but modifying an object
in a dictionary is a sure means of communication to all those who
read this dictionary. Also see my discussion with Peter Mueller about
naming.

>> Additionally, if an object can be placed in one place in the file
>> system, it can be placed in other 'known' places, allowing for the
>> publication of objects.
That's the multiple dictionaries I ask for.

>> One other capability allowed by mapping between directories and
>> objects is that something like a ZIP file (produced by PKZIP or the
>> like) could allow its contents to be directly accessed as a file.
>> Mapping between different styles of file systems could happen the same
>> way (assuming you want to nest filesystems).
Dictionaries should be a virtual object class, with standard methods, then
anyone could implement a new way of accessing objects. They also should
have a recursive definition, so that dictionaries can be part of another,
and there's no problem in mixing dictionary methods.

>> Note on terms:  I am using the term 'logical file system' to refer to
>> the effective file system that exists when the system is running.  In
>> Unix this is composed of the the root file system and any file systems
>> and network file systems mounted on it.  In the case of Moose, the
>> logical file system will (I hope) also include objects and other
>> things.
Each of us has his own terminology, inherited from his past experiences
and thinkings about computing. Let's not fight for names.
But if I prefer the object terminology to the file terminology, it's because
under existing systems, files are a closed inextensible system, with a
unique implementation oriented toward big file managing. Objects are
a generic extensible concept, which includes huge structures as well as
basic data.

>> -- 
>> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
>> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

   ,
Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
rideau@clipper.ens.fr





From MAILER-DAEMON@td2cad.intel.com Mon Mar 15 02:07:00 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09056; Mon, 15 Mar 93 02:06:59 +0100
Return-Path: <MAILER-DAEMON@td2cad.intel.com>
Received-Date: Mon, 15 Mar 93 02:06:59 +0100
Received: from hermes.intel.com by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Sun, 14 Mar 93 17:06:53 -0800
Received: by td2cad (5.57/10.0i); Sun, 14 Mar 93 17:10:30 -0800
Date: Sun, 14 Mar 93 17:10:30 -0800
From: MAILER-DAEMON@td2cad.intel.com (Mail Delivery Subsystem)
Message-Id: <9303150110.AB13740@td2cad>
Subject: Returned mail: Unable to deliver mail
To: postmaster@dmi.ens.fr
To: <rideau@clipper>
Status: OR

   ----- Transcript of session follows -----
<<< RCPT To:<dmarer@td2cad.intel.com>
<<< DATA
554 sendall: too many hops (17 max)

   ----- Unsent message follows -----
Received: by td2cad (5.57/10.0i); Sun, 14 Mar 93 17:10:30 -0800
Received: from whistler.sfu.ca by hermes.intel.com (5.65/10.0i); Sun, 14 Mar 93 17:06:07 -0800
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19427; Sun, 14 Mar 93 17:04:10 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08997; Mon, 15 Mar 93 02:04:02 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08634; Mon, 15 Mar 93 01:45:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18839; Sun, 14 Mar 93 16:41:03 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08559; Mon, 15 Mar 93 01:40:50 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07210; Mon, 15 Mar 93 00:35:59 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17084; Sun, 14 Mar 93 15:32:23 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07132; Mon, 15 Mar 93 00:32:16 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14520; Sat, 13 Mar 93 11:15:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20271; Sat, 13 Mar 93 05:15:07 -0500
Date: Sat, 13 Mar 93 05:15:07 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131015.AA20271@relay2.UU.NET>
To: <rideau@clipper.ens.fr>
Sender: rideau@clipper.ens.fr

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]


>> A possible means of making data objects available to other processes:
>> 
>> It is possible for
>> 
>>    1) All processes to be objects.
>>    2) Objects to be in the logical file system.
>>    3) Objects themselves be asked what objects are below them in the
>>       file system.

I think we agree, but I'd like to modify what you said:
1) EVERYTHING is an object; processes in particular.
2) I'd rather say the file system is included in the object system
(objects are files is the unix philosophy: you have only files,
and even to send/receive one integer number, you are bound to
use a (preferably ASCII) file).

>> With this setup, each process object is placed in the logical file
>> system.  Each process object may then be queried as to what public
>> objects it contains.  If a process is a 'dumb' program, this would
>> probably mean either nothing is public or a fixed list is public.  A
>> 'smart' program could either published all its objects or a portion of
>> its object list it selects.
The FS directory equivalent becomes what I previously called the dictionary.
You can even publish part of an object, that is, only part of its methods
are available. As each object has its dictionary, you can publish different
things to each of them.

>> As an additional capability, a 'smart' program could have objects
>> placed into the directory that it provides by other programs.  This
>> could be used as a means of specifically requesting communications
>> with a process.
I'm not sure of understanding what you said, but modifying an object
in a dictionary is a sure means of communication to all those who
read this dictionary. Also see my discussion with Peter Mueller about
naming.

>> Additionally, if an object can be placed in one place in the file
>> system, it can be placed in other 'known' places, allowing for the
>> publication of objects.
That's the multiple dictionaries I ask for.

>> One other capability allowed by mapping between directories and
>> objects is that something like a ZIP file (produced by PKZIP or the
>> like) could allow its contents to be directly accessed as a file.
>> Mapping between different styles of file systems could happen the same
>> way (assuming you want to nest filesystems).
Dictionaries should be a virtual object class, with standard methods, then
anyone could implement a new way of accessing objects. They also should
have a recursive definition, so that dictionaries can be part of another,
and there's no problem in mixing dictionary methods.

>> Note on terms:  I am using the term 'logical file system' to refer to
>> the effective file system that exists when the system is running.  In
>> Unix this is composed of the the root file system and any file systems
>> and network file systems mounted on it.  In the case of Moose, the
>> logical file system will (I hope) also include objects and other
>> things.
Each of us has his own terminology, inherited from his past experiences
and thinkings about computing. Let's not fight for names.
But if I prefer the object terminology to the file terminology, it's because
under existing systems, files are a closed inextensible system, with a
unique implementation oriented toward big file managing. Objects are
a generic extensible concept, which includes huge structures as well as
basic data.

>> -- 
>> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
>> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

   ,
Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
rideau@clipper.ens.fr





From MAILER-DAEMON@ecn.purdue.edu Mon Mar 15 02:07:03 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09060; Mon, 15 Mar 93 02:07:02 +0100
Return-Path: <MAILER-DAEMON@ecn.purdue.edu>
Received-Date: Mon, 15 Mar 93 02:07:02 +0100
Received: from bank.ecn.purdue.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by bank.ecn.purdue.edu (5.65/1.32jrs)
	id AA24616; Sun, 14 Mar 93 20:06:48 -0500
Date: Sun, 14 Mar 93 20:06:48 -0500
From: MAILER-DAEMON@ecn.purdue.edu (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <9303150106.AA24616@bank.ecn.purdue.edu>
To: <rideau@clipper>
Status: OR

   ----- Transcript of session follows -----
>>> DATA
<<< 554 sendall: too many hops 18 (17 max): from , to (null)
554 newlin@purcell... Service unavailable

   ----- Unsent message follows -----
Received: from whistler.sfu.ca by bank.ecn.purdue.edu (5.65/1.32jrs)
	id AA24612; Sun, 14 Mar 93 20:06:48 -0500
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19427; Sun, 14 Mar 93 17:04:10 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08997; Mon, 15 Mar 93 02:04:02 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08634; Mon, 15 Mar 93 01:45:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18839; Sun, 14 Mar 93 16:41:03 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08559; Mon, 15 Mar 93 01:40:50 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07210; Mon, 15 Mar 93 00:35:59 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17084; Sun, 14 Mar 93 15:32:23 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07132; Mon, 15 Mar 93 00:32:16 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14520; Sat, 13 Mar 93 11:15:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20271; Sat, 13 Mar 93 05:15:07 -0500
Date: Sat, 13 Mar 93 05:15:07 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131015.AA20271@relay2.UU.NET>
To: <rideau@clipper.ens.fr>
Sender: rideau@clipper.ens.fr

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]


>> A possible means of making data objects available to other processes:
>> 
>> It is possible for
>> 
>>    1) All processes to be objects.
>>    2) Objects to be in the logical file system.
>>    3) Objects themselves be asked what objects are below them in the
>>       file system.

I think we agree, but I'd like to modify what you said:
1) EVERYTHING is an object; processes in particular.
2) I'd rather say the file system is included in the object system
(objects are files is the unix philosophy: you have only files,
and even to send/receive one integer number, you are bound to
use a (preferably ASCII) file).

>> With this setup, each process object is placed in the logical file
>> system.  Each process object may then be queried as to what public
>> objects it contains.  If a process is a 'dumb' program, this would
>> probably mean either nothing is public or a fixed list is public.  A
>> 'smart' program could either published all its objects or a portion of
>> its object list it selects.
The FS directory equivalent becomes what I previously called the dictionary.
You can even publish part of an object, that is, only part of its methods
are available. As each object has its dictionary, you can publish different
things to each of them.

>> As an additional capability, a 'smart' program could have objects
>> placed into the directory that it provides by other programs.  This
>> could be used as a means of specifically requesting communications
>> with a process.
I'm not sure of understanding what you said, but modifying an object
in a dictionary is a sure means of communication to all those who
read this dictionary. Also see my discussion with Peter Mueller about
naming.

>> Additionally, if an object can be placed in one place in the file
>> system, it can be placed in other 'known' places, allowing for the
>> publication of objects.
That's the multiple dictionaries I ask for.

>> One other capability allowed by mapping between directories and
>> objects is that something like a ZIP file (produced by PKZIP or the
>> like) could allow its contents to be directly accessed as a file.
>> Mapping between different styles of file systems could happen the same
>> way (assuming you want to nest filesystems).
Dictionaries should be a virtual object class, with standard methods, then
anyone could implement a new way of accessing objects. They also should
have a recursive definition, so that dictionaries can be part of another,
and there's no problem in mixing dictionary methods.

>> Note on terms:  I am using the term 'logical file system' to refer to
>> the effective file system that exists when the system is running.  In
>> Unix this is composed of the the root file system and any file systems
>> and network file systems mounted on it.  In the case of Moose, the
>> logical file system will (I hope) also include objects and other
>> things.
Each of us has his own terminology, inherited from his past experiences
and thinkings about computing. Let's not fight for names.
But if I prefer the object terminology to the file terminology, it's because
under existing systems, files are a closed inextensible system, with a
unique implementation oriented toward big file managing. Objects are
a generic extensible concept, which includes huge structures as well as
basic data.

>> -- 
>> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
>> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

   ,
Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
rideau@clipper.ens.fr





From dmarer@td2cad.intel.com Fri Mar 19 18:19:20 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10284; Fri, 19 Mar 93 18:19:18 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 19 Mar 93 18:19:18 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28255; Fri, 19 Mar 93 09:11:09 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Fri, 19 Mar 93 09:11:06 -0800
Received: by td2cad (5.57/10.0i); Fri, 19 Mar 93 09:14:55 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01900; Fri, 19 Mar 93 09:22:10 PDT
Date: Fri, 19 Mar 93 09:22:10 PDT
Message-Id: <9303191722.AA01900@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Mach 3.0
Status: OR

Howdy Moosers!

	I've been hearing things lately about a kernel called Mach 3.0, so I
thought I'd do some research and see what it's about.  I've just FTPed some of
the docs, but haven't had a chance to read them.  Thought y'all might want to
take a look as well!  Just trying to get some more info on kernels.

				Dennis

-------------------------------------------------------------------------------

Thank you for your interest in Mach.

Before you can receive the i386/i486 release of Mach 3, we suggest
you first obtain Mach 2.5.  There are tools in 2.5 needed to build
3.0.

Please read over the following information.  PLEASE NOTE: It is 
important to FTP and read the installation notes as advised.  After
reading over the information, please contact me if you would like
to obtain the release.

Lori Iannamico
Mach Distribution Coordinator
lli+@cs.cmu.edu

   ANNOUNCING THE DISTRIBUTION OF MACH 2.5/3.0 FOR THE INTEL 80386/80486

  We  have a 80386/80486 version of Mach 2.5/3.0 that runs on a number of AT 
clones; Mach is being used at CMU on the following machines:  Olivetti M380, 
Toshiba  T5200, IBM-LP40SX, Dell 316,320 (i386SX chip), HP Vectra RS 25C, 
Intel 301, Intel 302, and Intel 401.

  To  get the Mach 2.5/3.0 for the Intel 80386 you need sign an agreement
stating that you will be bound by the terms of the Mach 2.5 license which in
turn requires source licenses for 4.3BSD and AT&T V3.2. CMU's licenses are
such that we can only distribute code only to holders of compatible source
licenses. 

  We have limited resources for making the  system  more  widely  available  at
present, but are willing to take on more sites.  To simplify our lives, we
are only making this distribution to sites that can access  the  internet  with
tcp/ip.  Mt Xinu has source or binary-only tape distributions available. They
can be reached at mtxinu-mach@mtxinu.com or (415) 644-0146.

We only support machines with:
   - Either an i386 or i486 processor
   - at least 5 Meg of memory.  We typically use 8Meg - 16Meg.
   - an AT/ISA compatible bus.
   - an approved disk controller: (You should get at least 100Meg of disk.
     We typically use 300Meg drives.)
        * WD 1007 compatible disk controllers.
        * IDE disks (these are WD 1007 compatible).
        * Adaptec 1542B compatible SCSI controller.
        * ST506 controller [Note: they are awfully slow.]
   - a displays:
        * simple displays in 25 x 80 character mode.
        * B&W X11R5 for VGA at 640x480 resolution from Thomas Roell.
        * Color X11R5 for SVGA from Thomas Roell.
   - high density 3 1/2" and/or 5 1/4" floppies  at  1.44Meg  and  1.2Meg,
     respectively.

  We support but do not require:
   - Intel 80387 hardware floating point. (recommended)
   - The built-in serial line: COMi
   - The built-in parallel port: LPTi
   - ethernet controller boards:
        * 3COM's  EtherLink  I  and EtherLink II (sometimes known as 3c501
          and 3c503),
        * Western Digital's WD8003E and WD8013E ethernet boards.
        * SMC's WD8003E Elite and WD8013E  Elite  ethernet  boards(Western
          Digital  sold  its  WD8003 ethernet product to SMC shortly after
          reengineering the board.  This board is called the WD8003 Elite.
          A recently sampled board seems to work fine, but there have been
          problems with some early units.  (They would  stop  transmitting
          after a while.))
        * Intel's iMX586 or PC586/ENET586 ethernet board (Now obsolete)
   - Wangtek 1/4" standard 3M streamer.

  WE DO NOT SUPPORT:
   - The microchannel bus: IBM PS 2/70 and PS 2/80 and some NCR machines
   - NFS (Is available only to holders of NFS Educational Institution License)

  NOTE: While Mach does not require an ethernet board for normal operation, our
method of installation assumes that you can get  the  files  from  CMU  to  the
target machine over the internet.


  If your site meets our licensing and hardware requirements,  you  should  ftp
the  Mach  2.5/3.0  I386  installation  manual.  You  may  acquire the manual
via anonymous ftp at mach.cs.cmu.edu; it is stored as:
   - /usr/mach/public/doc/unpublished/i386_install.{ps,doc}
   - /usr/mach/public/doc/unpublished/i386_manpages.{ps,doc}

To ftp from CMU:  Ftp to mach.cs.cmu.edu (128.2.209.192),
as "anonymous", at the password prompt send your Username@site 
Then "cd /usr/mach/public/doc".  
You can then use the standard ftp commands, e.g. get, ls with relative 
path names for the files. The articles are available in postscript(.ps) 
and ascii(.doc).  There is an INDEX file available in that directory.

  After reading the manual, if you would like to install Mach 2.5 I386,  please
contact us for more information either at:
mach@cs.cmu.edu
mach is read by the Project Manager and the Distribution Coordinator.  or at:
Mach Project
c/o Brian Bershad
School of Computer Science
Carnegie Mellon University
Pittsburgh, PA 15213-3890


----- End Included Message -----


From bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Mar 19 20:48:58 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15409; Fri, 19 Mar 93 20:48:57 +0100
Return-Path: <bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 19 Mar 93 20:48:57 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA10340; Fri, 19 Mar 93 11:38:03 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa05659;
          19 Mar 93 14:33 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa02270;
          19 Mar 93 19:29 GMT
Received: from sol.cis.udel.edu by bofur.cis.udel.edu id aa00479;
          19 Mar 93 19:26 GMT
To: moose-programmers@sfu.ca
Subject: Re: Mach 3.0 
Date: Fri, 19 Mar 93 14:26:18 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303191926.aa00479@bofur.cis.udel.edu>
Status: OR

In Message <9303191722.AA01900@tdge15.intel.com> ,
   Dennis Marer <dmarer@td2cad.intel.com> wrote:
=>Howdy Moosers!
=>
=>	I've been hearing things lately about a kernel called Mach 3.0, so I
=>thought I'd do some research and see what it's about.  I've just FTPed some o
f
=>the docs, but haven't had a chance to read them.  Thought y'all might want to
=>take a look as well!  Just trying to get some more info on kernels.
=>
=>				Dennis

   From what I've heard of Mach 3.0, it is probably larger than what
we want. They put a lot of emphasis on virtual memory, and provide an
extensive set of memory management functions. I understood that our
kernel was going to be lighter than that. They do, however, put the
higher level functionality in user-level tasks.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dmarer@td2cad.intel.com Fri Mar 19 21:14:18 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16235; Fri, 19 Mar 93 21:14:17 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 19 Mar 93 21:14:17 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12648; Fri, 19 Mar 93 12:04:52 -0800
Received: from [143.183.64.3] by hermes.intel.com (5.65/10.0i); Fri, 19 Mar 93 12:04:48 -0800
Received: by td2cad (5.57/10.0i); Fri, 19 Mar 93 12:08:34 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01949; Fri, 19 Mar 93 12:15:54 PDT
Date: Fri, 19 Mar 93 12:15:54 PDT
Message-Id: <9303192015.AA01949@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re: Mach 3.0
Status: OR

>    From what I've heard of Mach 3.0, it is probably larger than what
> we want. They put a lot of emphasis on virtual memory, and provide an
> extensive set of memory management functions. I understood that our
> kernel was going to be lighter than that. They do, however, put the
> higher level functionality in user-level tasks.

No doubt - they claim 5MB required, but actually need 8-16MB to be useful.
Actually, I was just suggesting it as another source of ideas, with no real
intention of using it as a base for our system.  I think we've got a totally
different design concept, and Mach wouldn't fit in too well.

Dennis

From ANDREASA@sofus.dhhalden.no Sat Mar 20 18:26:36 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01853; Sat, 20 Mar 93 18:26:34 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Sat, 20 Mar 93 18:26:34 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22627; Sat, 20 Mar 93 09:23:17 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <00320-25@fenris.dhhalden.no>; Sat, 20 Mar 1993 18:20:47 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930320174357.11840; 20 Mar 93 18:20:39 -0100
Message-Id: <MAILQUEUE-101.930320174355.288@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 20 Mar 93 17:43:55 +0100
Subject: Re: ORG, ROI, pem - Specification 03/16/93
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> R e m o t e   O b j e c t   I n v o c a t i o n
>
> Specification Release 0.00 (03/16/93)
>
Hello dear Elger (elg = moose in norwegian)

I have been thinking about Peters draft a lot lately, and also about "my"
device idea. Actually they are relatives, as brothers and sisters. Close as
man and wife. So I have thought, if we get an effective ROI we only have to
do two things to get them work as I suggest, give them a callback function
and a que pointer, and there it is - a fully functional IO device interface.

This can give very interresting features when it comes to networking, you
could actually read another harddisk on the net, use it as your own.
You could let ten users write in the same document at the time by connecting
your keyboard-device to their keyboards, and their screen-device to yours.
Of course, if this is possible there are no longer any security at all, a
total resource anarchism, and it could also be turn into a totalistic system
ala' George Orwells "1984"! But - this can be overcome.

Now about the use of the words invokee/invoker vs. client/server, actually
the use of client server suits my purpose _much_ better, because there
are no clear difference between invokee and invoker if you attach yourself
to a ROI with a callback function, or maybe still better servent instead of
server:-).

Please enjoy.
#pragma +Flame

Now I'll give you my suggestion for the "event/callback-function" system I
have suggested, with the use of ROI.

It will have the normal abilities as the ROI have;
 - Ability to change the hardware interface at runtime.
 - A dictionary (?) so you can select the IO device you'd preferr (eg. ms-dos
   file-system/unix/os/2(/vifs?))

ROI "extensions" to IO ROIs
 - Have a callback function that is called whenever there is IO the user is
   connected to. See example/idea 1.
 - Have a pointer to the task-ques last element pointer (very unabstract
   written). See example/idea 2.
 - The ability to either just post a message or to stop the multitasking if
   it must do so (ie. if a task does something critical which has to be delt
   with imidiatly!)
 - Whatever you can think of...


Now my two examples, in C and C++.
Example 1)

client.c
  #include "keyboarddev.h"

  .
  .
  .
  /* myKeybFunc = my keyboard function
     szUniqueName = a string that is unique to this application, suppsedly
                    given as argv[1] to prevent that others have the same
                    name
     dwInputIDxxx = if you have several input fields you might want to
                    have different (strings for them) input functions to them
     ptrMyQue = so the server knows where to put the callbackfunction and its
                parameters.
     last define = How much work should the device do for you, do you want
                   the scan-code or the character.
  */
  AttachToKeyboard (myKeybFunc, szMyUniqueName, dwInputIDxxx, ptrMyQue,
                    KEYB_ALL_INPUT);
  .
  .
  .
  /* Later you might use a ready-defined function. */
  ch = getchar ():

keyb-server.c++
class Keyboard : private BaseIODeviceClass
  {
    public:
      getchar ()
        { // Yes - I ident the parantheses too, and I don't use K&R style!:-)
        AttachToKeyboard (...); // Look in client.c
        }
      AttachToKeyboard (?);
      AttachToKeyBoard (?,?);
      AttachToKeyboard (?,?,?);

      KeyBoard (?);
      KeyBoard (?,?);
  }

Keyboard::AttachToKeyboard   ((void *) itsFunc, long ID, void *ptrQue);
  {
  InsertFunctionInTaskXsFunctionListWithItsInputID (itsFunc, ID);
  InsertPointerToLastElementInQuePtr (ptrQue);
  }

Keyboard::AnyKeyboardEvent (struct stdParameters wackiwacki)
  {
  long i,
       j;

  j = Semaphore->On(TaskXsQue);
  /* Or better DontMultiTaskYet (); */

  i = FindOutWhichInputFieldHasFocus ();
  i = GetFunctionNoDependingOnWhatHasFocus (i);
  PutFunctionInTasksEventQue (TasksFunctionXAppliedQuePtr[i], wackiwacki);

  Semaphore->Off(j);
  /* still better OkToMultiTask ();
     this prevents another item to wait for the que to become unlocked and
     to spend all its time doing nothing!
  */
  }


Now to example two.

    +---------+
    | Obj X   |           +------->[PtrToLastElementInTaskXsQue]---+
    |_________|           |                                        |
    |[QuePtrY]| ----------+                                        |
    +---------+                                                    |
                                   +-------------------------------+
                                   |   +----------------+Que
                                   +-->|[LastQueEntrie] |
                                       |[...]           |
                      +--------------->|[FirstQueEntrie]|
                      |                +----------------+
                      +-<KickFunctionInFirstQueEntrie (...);

Now how the que should/could be served.
 I suggest a (circular?) list/que.
 If you need to get your message through before any other you can just
 insert an item before the first entry in the que and update the pointer
 to the first item.
 Then you kick(launch is probably a better word but kick sounds much better
 :-)each item in the list as you traverse it.
 Whenever you insert an item last in the list you update a pointer to the
 last item. The address of this pointer is made "public" to all devices so
 they can update it.


Before I turn of flame; I don't say that ROI and this is the same thing, only
that I could give us a lot less work if it were, so don't take my scalp if
you don't like it.

#pragma -Flame

Ok guys, have a nice (Satur) day..., while I'll have to do some work:-)


Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From winikoff@cs.mu.OZ.AU Sun Mar 21 06:32:32 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29479; Sun, 21 Mar 93 06:32:31 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sun, 21 Mar 93 06:32:31 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03444; Sat, 20 Mar 93 21:27:30 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA28963
	Sun, 21 Mar 1993 15:27:19 +1000 (from winikoff)
Message-Id: <9303210527.28963@mulga.cs.mu.OZ.AU>
Subject: Kernel 0.1, Win
To: moose-programmers@sfu.ca (Moose Project)
Date: Sun, 21 Mar 93 15:27:18 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
Priority: Urgent
X-Mailer: ELM [version 2.3 PL0]
Status: OR

Kernel -- The Second Attempt 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[NOTE: I'm starting from a conventional OS and moving away rather then starting
 from objects and moving towards OS -- I feel that this is more likely to
 yield a running system in a short amount of time. As Dennis has pointed out
 we don't have the resources to re-invent the wheel]

Rather then just present details here I'd like to throw some ideas and
justifications.

Idea 1
~~~~~~
We base the kernel on persistent processes.

[Terminology: In a moment I'll modify this to persistent objects and explain
the differences. By persistent I mean that it can be swapped out to storage,
the machine turned off and on and then continued. In practice we would like
to be able to have a large number of suspended processes on disk]

This subsumes directories and files -- a directory is just a process that 
accepts queries and returns some identifier for the processes representing files

Consider now the form of such a server (which incidently bears a striking 
resemblence to the nameservers (or dictionaries)):

	while (accept(request)) 
		case request of
			type1 : ... handle 1 ...
			type2 : ... handle 2 ...

This type of code will be very common in the system.
It allready is in event based systems.

Why then not have a process declare to the kernel that
"I handle the following request:
	req1 taking 4 parameters
	req2 taking 3 parameters
etc."

This is just an object.
It has the concept of methods. 

[Note: It is open to discussion how much the kernel should know about the form
of the parameters (Eg. number, type ...)]

[note 2: Inheritance has been left out for the moment.
 as have overloading and polymorphism]

Definition 1
~~~~~~~~~~~~
An object is a process with method declerations.

Definition 2
~~~~~~~~~~~~~
A Device or "LOw Level Object" (lolo) is an object which 
either i
(1) has been granted the privilege of being able to refer to certain hardware 
resources. (Eg. disk control registers, ethernet card)
AND/OR
(2) Has methods which are invoked upon the reciept of a particular interrupt.
(Eg. data ready)

[Note: Most lolo's will have (1) -- I think that few will have ONLY (2)]


Definition 3
~~~~~~~~~~~~~
An OID (Object IDentifier) is an atomic data item that is valid across processes
(Note: In a distributed system it would be valid across machines too) and 
can be used to address an object.

Definition 4
~~~~~~~~~~~~~
A Dictionary (Or Name Server) is an object which supports certain lookup 
operations and returns an OID.

[Note: We see the concept of object classes by the type of the supported methods
falling out. Whether  this should be enforced by the kernel or elsewhere
or not at all is open to debate]


Discussion: As can be seen, so far we need system calls to
	* Create new objects
		This must take in parameters describing
			(1) The code
			(2) The method declerations
		These two could (should?) be together in an executable
			(3) OIDs for the objects which the new object has 
				access to
		This is important -- it replaces the concept of a default
		name server. The only object that is not given an object by
		it's spawner is the initial object. Giving it a nameserver
		is part of the bootstrap process.
	* Destroy objects -- clearly this takes an OID as a parameter
	* Invoking a method
		This takes
			(1) An OID
			(2) The method "name"
			(3) The arguments
		Issues:
			What is the type of the name?
			An integer is the obvious. 
			When would the allocation of these be done?

			The permissible type of the arguments?
			in a purely OO system we could just have OIDs and be
			done. In our system it is doubtful that representing
			(eg.) an array by an object would be practicle so we 
			need to be able to pass large granularity data between
			objects. 

			This is where IPC comes in.
			(I'm using the definition that IPC involves data 
			 copying between address space]



A comment on (very) small objects
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In a pure OO environment one could use an object to represent say an array
(not to mention an integer)

This is impracticle if we treat objects as processes since then a method
invocation involves a context switch.

This does not prohibit using small objects WITHIN a single larger object it's
just that these small objects can't be exported to the rest of the system.

I don't think that we can develop a system supporting small objects with 
reasonable efficiency in reasonable time. It involves too much research.

Some Other Issues
~~~~~~~~~~~~~~~~~~~~

These are areas which bear further thought.
I'll indicate my initial reactions to these issues.
Rather then spend time filling out the details now (and spark a debate on them)
I'd like to come to agreement on the basics first.

(1) Memory Allocation
(2) lolos -- how are they created, managed etc.
(3) Virtual Memory  and Address Spaces
(4) What are the semantics of persistance -- eg. what efficiency do we guarantee
[Note: Efficiency is important in design in that a gross efficiency difference
will influence the way a feature will be used.]
(5) Semantics of invocation (Eg. do we have a single threaded or multi threaded
semantics)
(6) Inheritance 
(7) Polymorphism and Overloading

---------
(1) Memory allocation:
	What kernel calls, how and should we support higher level functionality.
	(Eg. GC etc.) 
(2) lolos:
	How do we set an object up as a lolo, how do we give it access to a
	certain region of memory.
	(Implementation: we might need to have the access traped and then redone
	 by the kernel after checking -- MMUs don't neccessarily support fine
	 grain protection.
	 (Eg. this object can read bytes 100-102 and write bytes 103-110 but 
	 can't touch bytes 0-99 and 111-500)
	)
(3) Virtual Memory and Address Space
	I think we can more or less agree that seperate objects should not
	be able to read/write each others address space for robustness 
	reasons.
	Should we have an address space that is global or local to each object.
	(Note: This IS an independant issue)

	How should VM be done? I think paging is the simplest way.
	DEtails:
		User input to the process if any
		Existance of PHYS_MEM and it's management
(4) Semantics of persistance:
	One way to do persistance is to simply rely on paging -- assume all
	objects are in a very large memory and let paging load them in as
	needed.
	As Dennis has pointed out this is inefficient.
	Another way is swapping -- a process can only be either completely
	swapped out or completely in memory. 
	Disadvantage: Lose the ability to save memory by having part of a 
		process in memory
	Advantages: (1) Can be done without an MMU
		(2) By letting the user do this manually we allow coarse grain
		manual resource allocation.
		(Sort of like doing a "copy foo TO ramdisk" b4 starting
		 and having an automatic save files to hard disk from ramdisk
		 when about to shutdown)

(5) Semantics of invocation
	MOOSE is multitasking.
	What happens in the following situation:

	Object X	Object Y	Object Z
	Invoke(Z,1)
					Starts executing method 1
			Invoke(Z,2)
The three obvious possibilities are
(a) Z starts another method in parallel
(b) Y is blocked until Z finishes 
(c) Y continues and the invocation is queued.

(a) Gives us multithreading and requires us to have semaphores to co-ordinate
access to shared data.
(b) Is the simplest to implement but is less versatile
(c) Makes invocation asynchronous -- this adds paralellism to the system.

Notice that under (b) one could have the invoke call return a result.
Under (c) though the invoke would not return anything (other then
"this was succesfuly queued" OR "this failed") and the reciever would use
it's own invoke to return an answer.

Of course we could (and probly will end up doing) provide more then one.

(6) Inheritance 
	I've left this out for now.
	One question I would like to raise is WHICH INHERITANCE?
	There are multiple models -- C++, Smalltalk.
	Oh,  and this is without considering multiple inheritance.

(7) Polymorphism and Overloading
	So far I've only come across these as language design issues.
	 You have a "natural" polymorphism in some commands
	 (Eg. mv,rm,cp) when the contents of a file don't matter.

	 Could someone expound on their ideas -- how do YOU view the role
	 and function of polymorphism in an OS.

--------------------------
And of course, feel free to comment, correct, suggest, debate and/or flame.

Michael
Aka. Merlin son of Corwin and Dara, sorcerer and creator of Ghostwheel. :-)


From uunet.UU.NET!davgar!david Sun Mar 21 22:04:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27155; Sun, 21 Mar 93 22:04:28 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Sun, 21 Mar 93 22:04:28 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA00851; Sun, 21 Mar 93 12:59:13 -0800
Received: from uunet.uu.net (via spool.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA18661; Sun, 21 Mar 93 15:59:11 -0500
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR6);
           Sun, 21 Mar 1993 15:47:57 EST
Date:      Sun, 21 Mar 1993 15:47:43 EST
From: (David Garfield) uunet.uu.net!davgar!david
Message-Id: <2bacd483.davgar@davgar.UUCP>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: Kernel 0.1 by win.   djg5
Status: OR

"> " is from Michael David WINIKOFF

> Idea 1
> ~~~~~~
> We base the kernel on persistent processes.
>
> [Terminology: In a moment I'll modify this to persistent objects and explain
> the differences. By persistent I mean that it can be swapped out to storage,
> the machine turned off and on and then continued. In practice we would like
> to be able to have a large number of suspended processes on disk]

I would like to disagree at this stage.  Objects are not processes.
Object classes are processes.  I hate to say it, but I do think the
difference should exist.  This has the distinct advantage that you
don't have to store the code with the data, only a reference to it.
Ideally, for most classes, I would rather see one instance of the code
in virtual memory as well.

> This subsumes directories and files -- a directory is just a process that
> accepts queries and returns some identifier for the processes representing files

Change process to object due to the above objection and I agree
completely.

> Consider now the form of such a server (which incidently bears a striking
> resemblence to the nameservers (or dictionaries)):

Actually, I would argue that ALL objects should should be
nameservers/dictionaries/directories.  Some are just empty.


..

> Definition 1
> ~~~~~~~~~~~~
> An object is a process with method declerations.
An object is an area of data with a reference to a process or, in the
case of a suspended object, to a program.

> Definition 2
> ~~~~~~~~~~~~~
> A Device or "LOw Level Object" (lolo) is an object which
> either i
> (1) has been granted the privilege of being able to refer to certain hardware
> resources. (Eg. disk control registers, ethernet card)
> AND/OR
> (2) Has methods which are invoked upon the reciept of a particular interrupt.
> (Eg. data ready)
>
> [Note: Most lolo's will have (1) -- I think that few will have ONLY (2)]

Excellent definition.

> Definition 3
> ~~~~~~~~~~~~~
> An OID (Object IDentifier) is an atomic data item that is valid across processes
>
> (Note: In a distributed system it would be valid across machines too) and
> can be used to address an object.

I would have to counter that 1) an OID is only valid for non-suspended
objects and 2) In a network environment, aliases will exist for
objects on remote machines.  Any given OID is only valid on one
machine.

> Definition 4
> ~~~~~~~~~~~~~
> A Dictionary (Or Name Server) is an object which supports certain lookup
> operations and returns an OID.

As stated above, I argue that ALL objects are dictionaries/name
servers/directories.

> [Note: We see the concept of object classes by the type of the supported methods
> falling out. Whether  this should be enforced by the kernel or elsewhere
> or not at all is open to debate]

Actually, I think thats the class hierarchy.


> Discussion: As can be seen, so far we need system calls to
>         * Create new objects
>                 This must take in parameters describing
>                         (1) The code
>                         (2) The method declerations
>                 These two could (should?) be together in an executable
I think the correct phrase is MUST.

>                         (3) OIDs for the objects which the new object has
>                                 access to
>                 This is important -- it replaces the concept of a default
>                 name server. The only object that is not given an object by
>                 it's spawner is the initial object. Giving it a nameserver
>                 is part of the bootstrap process.
The new object has access to 1) itself, 2) any objects it (or its
class) creates, 3) any object whose OID is EVER passed to it, 4) any
object access from other dictionaries/name servers/directories.  I do
not believe that you can do away with a default name server/root
directory concept.  On the other hand, many objects have reasonable
cause to want to know the identity of there creater/parent directory.

>         * Destroy objects -- clearly this takes an OID as a parameter
My only argument here is that we may want it to be "Delete Myself",
with no parameters

>         * Invoking a method
>                 This takes
>                         (1) An OID
>                         (2) The method "name"
>                         (3) The arguments
>                 Issues:
>                         What is the type of the name?
>                         An integer is the obvious.
>                         When would the allocation of these be done?
I too would like to see method "name"s be integers.  I would also like
to see a large number of standard methods predefined, so we can use
switch statements as needed.

>                         The permissible type of the arguments?
>                         in a purely OO system we could just have OIDs and be
>                         done. In our system it is doubtful that representing
>                         (eg.) an array by an object would be practicle so we
>                         need to be able to pass large granularity data between
>                         objects.
>
>                         This is where IPC comes in.
>                         (I'm using the definition that IPC involves data
>                          copying between address space]

I would agree that we should not restrict ourselves to objects as
parameters.  After all, how does one read a block from disk into local
memory if an object can only write it into another object?  And how
could one even write it into said object?

..

> (2) lolos:
>         How do we set an object up as a lolo, how do we give it access to a
>         certain region of memory.
>         (Implementation: we might need to have the access traped and then redone
>          by the kernel after checking -- MMUs don't neccessarily support fine
>          grain protection.
>          (Eg. this object can read bytes 100-102 and write bytes 103-110 but
>          can't touch bytes 0-99 and 111-500)
>         )
We should not need to limit the granularity of memory access by LOLOs
(at least on the 386).  Most (if not all) hardware devices that
provide memory mapped I/O provide large blocks.  We do also have to
provide access to I/O ports on a restricted basis, and allow interrupt
callbacks.

I would say that the header of all executables will include what
hardware facilities it will require.  If an executable is
appropriately listed as 'trusted', the process resulting from this
executable will have access to the facilities listed.

> (3) Virtual Memory and Address Space
>         I think we can more or less agree that seperate objects should not
>         be able to read/write each others address space for robustness
>         reasons.
I would allow objects of the same class to co-exist in one allocation
unit if the class is well-developed, simply to conserve memory.

>         Should we have an address space that is global or local to each object.
>         (Note: This IS an independant issue)

IMHO each process should have it's own address space, and each object
should have a block of memory that is mapped into its class's address
space when a message is being processed.  The address of the objects
memory would then be passed to the code for processing.  For derived
class objects, the address of the classes data would (also) be passed.

>
>         How should VM be done? I think paging is the simplest way.
>         DEtails:
>                 User input to the process if any
>                 Existance of PHYS_MEM and it's management

Physical memory would be handled in the same way as I/O (see above).


..

> (5) Semantics of invocation
>         MOOSE is multitasking.
>         What happens in the following situation:
>
>         Object X        Object Y        Object Z
>         Invoke(Z,1)
>                                         Starts executing method 1
>                         Invoke(Z,2)
> The three obvious possibilities are
> (a) Z starts another method in parallel
> (b) Y is blocked until Z finishes
> (c) Y continues and the invocation is queued.
>
> (a) Gives us multithreading and requires us to have semaphores to co-ordinate
> access to shared data.
> (b) Is the simplest to implement but is less versatile
> (c) Makes invocation asynchronous -- this adds paralellism to the system.
>
> Notice that under (b) one could have the invoke call return a result.
> Under (c) though the invoke would not return anything (other then
> "this was succesfuly queued" OR "this failed") and the reciever would use
> it's own invoke to return an answer.
>
> Of course we could (and probly will end up doing) provide more then one.

IMHO we should have all three.  The difference between (a) and (b)
will be at the discression of the receiving process (=1 or more
classes).  The difference between (b) and (c) is that (b) is a send
and wait for reply, and (c) is send it now, tell me later.  Case (c)
is actually how new threads are started.

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From winikoff@cs.mu.OZ.AU Mon Mar 22 00:35:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01768; Mon, 22 Mar 93 00:35:24 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 22 Mar 93 00:35:24 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05252; Sun, 21 Mar 93 15:31:32 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA09646
	Mon, 22 Mar 1993 09:31:25 +1000 (from winikoff)
Message-Id: <9303212331.9646@mulga.cs.mu.OZ.AU>
Subject: Re: Kernel 0.1, Win
To: moose-programmers@sfu.ca (Moose Project)
Date: Mon, 22 Mar 93 9:31:24 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To:  <9303211812.aa14116@bifur.cis.udel.edu>; from "Gary D. Duzan" at Mar 21, 93 1:12 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> In Message <9303210527.28963@mulga.cs.mu.OZ.AU> ,
>    Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:
> 
> =>Kernel -- The Second Attempt 
> 
>    For the most part, I tend to agree with this view of the system.
> 
> =>[Note: We see the concept of object classes by the type of the supported meth
> ods
> =>falling out. Whether  this should be enforced by the kernel or elsewhere
> =>or not at all is open to debate]
> 
>    Types are a sticky issue. They are basically language-specific, and
> we are building a system that needs to work across languages. I don't
> think we can expect to teach the kernel about every data type that
> comes along, so I think that any type checking would have to be done
> at one or both ends of the communication rather than in the kernel.

Yes.
Do you have any suggestions on the mechanism for doing this?

> =>This does not prohibit using small objects WITHIN a single larger object it's
> =>just that these small objects can't be exported to the rest of the system.
> 
>    Unless, of course, the larger object decides to allow access via a
> method of its own.

The point is that we still have this one large object with an extra method
rather then an extra object -- for instance the "small" object doesn't have an
OID.

> 
> =>(3) Virtual Memory and Address Space
> =>	Should we have an address space that is global or local to each object.
> =>	(Note: This IS an independant issue)
> 
>    Local address spaces have the advantages of simplifying, if not
> eliminating, kernel memory allocation and reducing problems with
> growing/shrinking allocated memory regions. If we all had 48/64-bit
> virtual addresses, this would be less of an advantage, but I assume we
> want something to run on existing machines. Global address spaces have
> the advantages of facilitating code sharing and simplifying object
> addressing/communication.
> 
> =>(4) Semantics of persistance:
> =>	One way to do persistance is to simply rely on paging -- assume all
> =>	objects are in a very large memory and let paging load them in as
> =>	needed.
> =>	As Dennis has pointed out this is inefficient.
> 
>    If the objects are large and we do some intelligent things like
> prefetching, it shouldn't be too inefficient. Global vs. Local address
> space would impact this as well.
>    Of course, if you really don't want to reinvent the wheel, then we
> should have a plain, old-fashioned file system. Regardless, I don't

The point is that objects are used to implement files so a file system is not
a good term.
[Since objects would implement such thing as file indexing we don't need the 
disk front end to provide sequential byte streams -- a simple page writing
interface could be sufficient.]

> think that a persistent object system on an MMU-less system would be
> much fun to work with. I would assume that such a system would need to
> stop and checkpoint objects fairly regularly, which would be rather
> ugly from the user's point of view.

THis is all hypothetical BTW, but, I'd imagine that checkpointing objects would
be done manually.
The user would be aware that any objects not saved before a system crash would
be lost.

> 
> =>(5) Semantics of invocation
> =>	MOOSE is multitasking.
> =>	What happens in the following situation:
> =>
> =>	Object X	Object Y	Object Z
> =>	Invoke(Z,1)
> =>					Starts executing method 1
> =>			Invoke(Z,2)
> =>The three obvious possibilities are
> =>(a) Z starts another method in parallel
> =>(b) Y is blocked until Z finishes 
> =>(c) Y continues and the invocation is queued.
> 
>    I bet you knew I couldn't resist commenting on this one. :-)  As I
> have commented in the past, I prefer the semantics of (a). However, I
> understand that the system level would be better served by the
> semantics of (c). So I would suggest implementing (c) at the system
> level and building an interface to provide the semantics of (a) on top
> of (c) at the user level (i.e. a threads package.) Objects should use
> this level to formalize communication rather than the lower level
> primitives. The (a) interface may be tailored to each language, as
> necessary.

I think providing all three  at the user level is what we should do.
WHich get done at the kernel and which get done by libraries I'll leave
o experts in the area (like yourself) to decide.

>    Of course, if a language will support Futures, I would love to see
> them implemented.  For those who don't know what a Future (or Future
> Object) is, it is an object which may not have state assigned yet. The
> language can pass around references to the Future just like any other
> object, but if it tries to access its state, the process blocks until
> some concurrent entity sets the state. I'm aware of Futures from what I
> have read on a parallel language called Ellie. It may not be
> particularly relevent to MOOSE, but it is an interesting concept.
> 
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 
> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From ANDREASA@sofus.dhhalden.no Mon Mar 22 16:25:04 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10088; Mon, 22 Mar 93 16:25:03 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 22 Mar 93 16:25:03 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24002; Mon, 22 Mar 93 07:19:35 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <06430-2@fenris.dhhalden.no>; Mon, 22 Mar 1993 16:19:01 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930322161851.992; 22 Mar 93 16:18:58 -0100
Message-Id: <MAILQUEUE-101.930322161849.672@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 22 Mar 93 16:18:49 +0100
Subject: arf, GW problems
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Hello dear moosers

My site has had some GateWay problems during this weekend, I have got about
three mail today.
If there has been more, or if you havn't got my last posting (saying ROI =
Device) please tell me so you, and eventually you/I could repost the
message(s).sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Tue Mar 23 01:12:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29995; Tue, 23 Mar 93 01:12:29 +0100
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Tue, 23 Mar 93 01:12:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07162; Mon, 22 Mar 93 16:09:28 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa12582;
          22 Mar 93 19:02 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa05984; 23 Mar 93 0:02 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa24193;
          22 Mar 93 23:59 GMT
To: moose-programmers@sfu.ca
Subject: Re: Kernel 0.1, Win 
Date: Mon, 22 Mar 93 18:59:07 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303222359.aa24193@thorin.cis.udel.edu>
Status: OR

In Message <9303212331.9646@mulga.cs.mu.OZ.AU> ,
   Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:

=>>    Types are a sticky issue. They are basically language-specific, and
=>> we are building a system that needs to work across languages. I don't
=>> think we can expect to teach the kernel about every data type that
=>> comes along, so I think that any type checking would have to be done
=>> at one or both ends of the communication rather than in the kernel.
=>
=>Yes.
=>Do you have any suggestions on the mechanism for doing this?

   Well, the most efficient would be to ignore types altogether and
assume that both ends know what they are doing. We could also define
some standard types (8/16/32/64-bit signed/unsigned integer, floating
point, fixed length string, variable length string, etc.) and require
that all IPC use these types. We could also provide libraries for
each language to convert language types into system types. Expanding
the libraries would allow for more system types. I don't know if
this is a good idea, but it is an idea.

=>> think that a persistent object system on an MMU-less system would be
=>> much fun to work with. I would assume that such a system would need to
=>> stop and checkpoint objects fairly regularly, which would be rather
=>> ugly from the user's point of view.
=>
=>THis is all hypothetical BTW, but, I'd imagine that checkpointing objects wou
ld
=>be done manually.
=>The user would be aware that any objects not saved before a system crash woul
d
=>be lost.

   I would have thought that persistent objects were meant to hide
the persistence from the user. I suppose we could do a transactional
system (logs & checkpoints) to deal with crashes, but that would be
quite a chore.

=>> [ stuff about communication semantics ]
=>>
=>I think providing all three  at the user level is what we should do.
=>WHich get done at the kernel and which get done by libraries I'll leave
=>o experts in the area (like yourself) to decide.

   However, the system will be more coherent if we encourage a
particular communication mechanism.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Tue Mar 23 04:52:35 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04753; Tue, 23 Mar 93 04:52:32 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 23 Mar 93 04:52:32 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19057; Mon, 22 Mar 93 19:49:01 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA26543
	Tue, 23 Mar 1993 13:48:26 +1000 (from winikoff)
Message-Id: <9303230348.26543@mulga.cs.mu.OZ.AU>
Subject: Re: Kernel 0.1, Win
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 23 Mar 93 13:48:25 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To:  <9303222359.aa24193@thorin.cis.udel.edu>; from "Gary D. Duzan" at Mar 22, 93 6:59 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> In Message <9303212331.9646@mulga.cs.mu.OZ.AU> ,
>    Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:
> 
> =>>    Types are a sticky issue. They are basically language-specific, and
> =>> we are building a system that needs to work across languages. I don't
> =>> think we can expect to teach the kernel about every data type that
> =>> comes along, so I think that any type checking would have to be done
> =>> at one or both ends of the communication rather than in the kernel.
> =>
> =>Yes.
> =>Do you have any suggestions on the mechanism for doing this?
> 
>    Well, the most efficient would be to ignore types altogether and
> assume that both ends know what they are doing. We could also define
> some standard types (8/16/32/64-bit signed/unsigned integer, floating
> point, fixed length string, variable length string, etc.) and require
> that all IPC use these types. We could also provide libraries for
> each language to convert language types into system types. Expanding
> the libraries would allow for more system types. I don't know if
> this is a good idea, but it is an idea.

It's the simplest for us but it causes problems with robustness.

> 
> =>> think that a persistent object system on an MMU-less system would be
> =>> much fun to work with. I would assume that such a system would need to
> =>> stop and checkpoint objects fairly regularly, which would be rather
> =>> ugly from the user's point of view.
> =>
> =>THis is all hypothetical BTW, but, I'd imagine that checkpointing objects wou
> ld
> =>be done manually.
> =>The user would be aware that any objects not saved before a system crash woul
> d
> =>be lost.
> 
>    I would have thought that persistent objects were meant to hide
> the persistence from the user. I suppose we could do a transactional

They are. I was talking about a hypothetical MMU-less implementation ...

> system (logs & checkpoints) to deal with crashes, but that would be
> quite a chore.
> 
> =>> [ stuff about communication semantics ]
> =>>
> =>I think providing all three  at the user level is what we should do.
> =>WHich get done at the kernel and which get done by libraries I'll leave
> =>o experts in the area (like yourself) to decide.
> 
>    However, the system will be more coherent if we encourage a
> particular communication mechanism.

Yes -- which? :-)

> 
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 
> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From uunet.UU.NET!davgar!david Tue Mar 23 07:35:53 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13994; Tue, 23 Mar 93 07:35:52 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Tue, 23 Mar 93 07:35:52 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26718; Mon, 22 Mar 93 22:33:28 -0800
Received: from uunet.uu.net (via spool.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA08009; Tue, 23 Mar 93 01:33:25 -0500
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR6);
           Tue, 23 Mar 1993 01:26:36 EST
Date:      Tue, 23 Mar 1993 01:26:23 EST
From: (David Garfield) uunet.uu.net!davgar!david
Message-Id: <2baead9e.davgar@davgar.UUCP>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: Kernel 0.1, Win [djg6]
Status: OR

On Tue, 23 Mar 93 13:48:25 EST, "Michael David WINIKOFF" 
   <winikoff@mulga.cs.mu.OZ.AU> wrote:
> In-Reply-To:  <9303222359.aa24193@thorin.cis.udel.edu>; 
>    from "Gary D. Duzan" at Mar 22, 93 6:59 pm
> > 
> > In Message <9303212331.9646@mulga.cs.mu.OZ.AU> ,
> >    Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:
> > 
> > =>>    Types are a sticky issue. They are basically language-specific, and
> > =>> we are building a system that needs to work across languages. I don't
> > =>> think we can expect to teach the kernel about every data type that
> > =>> comes along, so I think that any type checking would have to be done
> > =>> at one or both ends of the communication rather than in the kernel.
> > =>
> > =>Yes.
> > =>Do you have any suggestions on the mechanism for doing this?
> > 
> >    Well, the most efficient would be to ignore types altogether and
> > assume that both ends know what they are doing. We could also define
> > some standard types (8/16/32/64-bit signed/unsigned integer, floating
> > point, fixed length string, variable length string, etc.) and require
> > that all IPC use these types. We could also provide libraries for
> > each language to convert language types into system types. Expanding
> > the libraries would allow for more system types. I don't know if
> > this is a good idea, but it is an idea.
> 
> It's the simplest for us but it causes problems with robustness.

One possible way to have a reasonable change of getting the parameters 
right is to encode the parameter types in the method name, like C++ 
name mangling.

[stuff about persistence deleted]
> > system (logs & checkpoints) to deal with crashes, but that would be
> > quite a chore.
> > 
> > =>> [ stuff about communication semantics ]
> > =>>
> > =>I think providing all three  at the user level is what we should do.
> > =>WHich get done at the kernel and which get done by libraries I'll leave
> > =>o experts in the area (like yourself) to decide.
> > 
> >    However, the system will be more coherent if we encourage a
> > particular communication mechanism.
> 
> Yes -- which? :-)

The point IMHO is to allow the object class to support single threads 
with queuing or multiple threads, and to allow the invoker to use 
synchronous or asynchronous invokations, and to encourage applications 
and classes to use the techniques that are appropriate for what is 
being done.  By preference, class should support multiple threads and 
applications should to synchronous calls, but for some uses, other 
techniques should be used.

> >                                         Gary Duzan
> >                                         Time  Lord
> >                                     Third Regeneration
> >                          Humble Practitioner of the Computer Arts
> --------------------------------------------------------------------------------
> 
> Michael Winikoff
> winikoff@cs.mu.oz.au
> Computer science honours. University of Melbourne, Australia.

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From ANDREASA@sofus.dhhalden.no Tue Mar 23 10:54:41 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18600; Tue, 23 Mar 93 10:54:39 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Tue, 23 Mar 93 10:54:39 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02344; Tue, 23 Mar 93 01:49:45 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <26255-0@fenris.dhhalden.no>; Tue, 23 Mar 1993 10:37:16 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930323103657.448; 23 Mar 93 10:37:11 -0100
Message-Id: <MAILQUEUE-101.930323103645.416@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 23 Mar 93 10:36:45 +0100
Subject: Re: Kernel 0.1, Win
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

 > Kernel -- The Second Attempt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Idea 1
> ~~~~~~
> Consider now the form of such a server (which incidently bears a striking
> resemblence to the nameservers (or dictionaries)):
>
>     while (accept(request))
>         case request of
>             type1 : ... handle 1 ...
>             type2 : ... handle 2 ...
>
> This type of code will be very common in the system.
> It allready is in event based systems.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Those two sentences gives me the creeps. If I'll have to continue code that
way I'll stick to windows until moose 2.0!
Then we wouldn't have achieved the most important goal, simpleness!
It must be simple to program, or else noone ever will, except us!
Yes I see that we will need that type of structures in our code, but it can
be minimized using ROI-like devices as I suggested in my last mail.
Then that type of code will be neccesary only in the kernel and devices.

> Why then not have a process declare to the kernel that
> "I handle the following request:
>     req1 taking 4 parameters
>     req2 taking 3 parameters
> etc."

I must say I belive that is to give the kernel to much work.
I see 1 important goal for the kernel, to it keep efficient.
It must be small enough to be kept in physical memory all the time. Think of
a kernel, the most important (?) part in a system, that swaps itself out
because of its size!
I think this is to give the kernel to much work.
Why must a task go all the way down to the kernel to become familiar with
other objects floating around in the address space. I belive this could be
done in a higher level. Correct me if I'm wrong, I can take some flames!

> This is just an object.
> It has the concept of methods.
>
> [Note: It is open to discussion how much the kernel should know about the form
> of the parameters (Eg. number, type ...)]
>
> [note 2: Inheritance has been left out for the moment.
>  as have overloading and polymorphism]
>
> Definition 1
> ~~~~~~~~~~~~
> An object is a process with method declerations.
>
> Definition 2
> ~~~~~~~~~~~~~
> A Device or "LOw Level Object" (lolo) is an object which
> either i
> (1) has been granted the privilege of being able to refer to certain hardware
> resources. (Eg. disk control registers, ethernet card)
> AND/OR
> (2) Has methods which are invoked upon the reciept of a particular interrupt.
> (Eg. data ready)
>
> [Note: Most lolo's will have (1) -- I think that few will have ONLY (2)]

  (3) It has also been granted the privilege to launch certain processes in
  tasks that has asked for it.

>
> Definition 3
> ~~~~~~~~~~~~~
> An OID (Object IDentifier) is an atomic data item that is valid across processes
> (Note: In a distributed system it would be valid across machines too) and
> can be used to address an object.
>
> Definition 4
> ~~~~~~~~~~~~~
> A Dictionary (Or Name Server) is an object which supports certain lookup
> operations and returns an OID.
>
> [Note: We see the concept of object classes by the type of the supported methods
> falling out. Whether  this should be enforced by the kernel or elsewhere
> or not at all is open to debate]
>
>
> Discussion: As can be seen, so far we need system calls to
>     * Create new objects
>         This must take in parameters describing
>             (1) The code
>             (2) The method declerations
>         These two could (should?) be together in an executable
I agree with the must.
>             (3) OIDs for the objects which the new object has
>                 access to
                  In addition it is presented to its own OID.

>         This is important -- it replaces the concept of a default
>         name server. The only object that is not given an object by
>         it's spawner is the initial object. Giving it a nameserver
>         is part of the bootstrap process.
>     * Invoking a method
>         This takes
>             (1) An OID
>             (2) The method "name"
>             (3) The arguments
I referr to my last mail where I have drawn a event-que with pointers to
functions. Maybe this way is somewhat better, that you supply the
OID, method name and arguments into the task-que.
>         Issues:
>             What is the type of the name?
>             An integer is the obvious.
>             When would the allocation of these be done?
The integers? At compile time. When you create an object, the object will
already contain numbers for its methods.
If the OID is distributed at runtime there wont be any OID.method crashes.
>             The permissible type of the arguments?
>             in a purely OO system we could just have OIDs and be
>             done. In our system it is doubtful that representing
>             (eg.) an array by an object would be practicle so we
>             need to be able to pass large granularity data between
>             objects.
>
>             This is where IPC comes in.
>             (I'm using the definition that IPC involves data
>              copying between address space]
>
>
>
> A comment on (very) small objects
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In a pure OO environment one could use an object to represent say an array
> (not to mention an integer)
>
> This is impracticle if we treat objects as processes since then a method
> invocation involves a context switch.
>
> This does not prohibit using small objects WITHIN a single larger object it's
> just that these small objects can't be exported to the rest of the system.
>
> I don't think that we can develop a system supporting small objects with
> reasonable efficiency in reasonable time. It involves too much research.

Sounds very wise.

> Some Other Issues
> ~~~~~~~~~~~~~~~~~~~~
>
> These are areas which bear further thought.
> I'll indicate my initial reactions to these issues.
> Rather then spend time filling out the details now (and spark a debate on them)
> I'd like to come to agreement on the basics first.
>
> (1) Memory Allocation
> (2) lolos -- how are they created, managed etc.
> (3) Virtual Memory  and Address Spaces
> (4) What are the semantics of persistance -- eg. what efficiency do we guarantee
> [Note: Efficiency is important in design in that a gross efficiency difference
> will influence the way a feature will be used.]
> (5) Semantics of invocation (Eg. do we have a single threaded or multi threaded
> semantics)
> (6) Inheritance
> (7) Polymorphism and Overloading
>
> ---------
> (1) Memory allocation:
>     What kernel calls, how and should we support higher level functionality.
>     (Eg. GC etc.)
> (2) lolos:
>     How do we set an object up as a lolo, how do we give it access to a
>     certain region of memory.
>     (Implementation: we might need to have the access traped and then redone
>      by the kernel after checking -- MMUs don't neccessarily support fine
>      grain protection.
>      (Eg. this object can read bytes 100-102 and write bytes 103-110 but
>      can't touch bytes 0-99 and 111-500)

       We look in the object dictionary at boot-time and just launch those
       objects that are listed under the device-index. Not that simple but
       almost. There must be information telling us what it needs.
       Maybe the standard devices should have their own dictionary (as I
       belive Dennis talked about in Januar) "hardcoded" in the kernels
       bootstrap code together with cpu ports lists for each device, and
       eventually other requirements.

> (3) Virtual Memory and Address Space
>     I think we can more or less agree that seperate objects should not
>     be able to read/write each others address space for robustness
>     reasons.
Yes.
>     Should we have an address space that is global or local to each object.
>     (Note: This IS an independant issue)
If you mean that the object can reach outside its own address space, I
belive the answer must be global. What if an object allocates memory and
it's pointer can't reach outside the object itself? Or did I missunderstand
something.

>     How should VM be done? I think paging is the simplest way.
Don't know if it's the simplest way, but probably the smartest. I belive
we are dumb if we only use segments.

> (5) Semantics of invocation
>     MOOSE is multitasking.
>     What happens in the following situation:
>
>     Object X    Object Y    Object Z
>     Invoke(Z,1)
>                     Starts executing method 1
>             Invoke(Z,2)
> The three obvious possibilities are
> (a) Z starts another method in parallel
> (b) Y is blocked until Z finishes
> (c) Y continues and the invocation is queued.
>
> (a) Gives us multithreading and requires us to have semaphores to co-ordinate
> access to shared data.
> (b) Is the simplest to implement but is less versatile
> (c) Makes invocation asynchronous -- this adds paralellism to the system.
>
> Notice that under (b) one could have the invoke call return a result.
> Under (c) though the invoke would not return anything (other then
> "this was succesfuly queued" OR "this failed") and the reciever would use
> it's own invoke to return an answer.

I would preferr alternative c, but there are some moments when you don't
want things to get qued.
Lets take a parallell to windows. Either you post a message, then it is
put into the que. Or you can send the message. Then windows just jumps
to the appropirate windows function (where the programmer has a 1000 lines
long switch-case to respond to all possible 70 messages; which is dirty
cumbersome and which I hate; and most important don't want to see in moose!)
and when that function returns it gives control back to the calling procedure.

> Of course we could (and probly will end up doing) provide more then one.
Probably yes.

> (7) Polymorphism and Overloading
>     So far I've only come across these as language design issues.
>      You have a "natural" polymorphism in some commands
>      (Eg. mv,rm,cp) when the contents of a file don't matter.
>
>      Could someone expound on their ideas -- how do YOU view the role
>      and function of polymorphism in an OS.
I don't think the OS should know anything about the data, if it isn't ment
for its own use.

> And of course, feel free to comment, correct, suggest, debate and/or flame.
The same to me.
> Michael
> Aka. Merlin son of Corwin and Dara, sorcerer and creator of Ghostwheel. :-)

Ha, Time Lord and Merlin son of Corwin and Dara, sorecerer and creator of
Ghostwheel, hah.
Me I laugh at your pettyness. Me, I am THE DUNGEON MASTER. Tremble you
weenie mortals, quiecheaters and lamers.
Me laugh at your pettyness. Your pride is only bullshit, me say as imortal.
You only live because of the GMs goodwill. So don't push your limits, then
you might get killed.

Arff :-)

sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From mueller@sc.ZIB-Berlin.DE Tue Mar 23 12:59:37 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA21426; Tue, 23 Mar 93 12:59:36 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Tue, 23 Mar 93 12:59:36 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA04727; Tue, 23 Mar 93 03:55:08 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA00695; Tue, 23 Mar 93 12:54:56 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA02634; Tue, 23 Mar 93 12:54:56 +0100
Date: Tue, 23 Mar 93 12:54:56 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303231154.AA02634@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Article: about QNX
Status: OR

Hi,

sorry, I can't give you a new ROI spec. But I want to
mention the following article (maybe you've already 
know it):

	"An Architectural Overview of QNX"
	by: Dan Hildebrand

available via anon-ftp from

	ftp.cse.ucsc.edu:/pub/qnx-paper.ps.Z

in there you will find a description of a real micro-
kernel based OS, though not object-orientated.

Enjoy!

Peter

	

From uunet.UU.NET!davgar!david Wed Mar 24 07:57:14 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24045; Wed, 24 Mar 93 07:57:13 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Wed, 24 Mar 93 07:57:13 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12401; Tue, 23 Mar 93 22:54:15 -0800
Received: from uunet.uu.net (via spool.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA28368; Wed, 24 Mar 93 01:54:13 -0500
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR7);
           Wed, 24 Mar 1993 01:36:39 EST
Date:      Wed, 24 Mar 1993 01:36:33 EST
From: (David Garfield) uunet.uu.net!davgar!david
Message-Id: <2bb00178.davgar@davgar.UUCP>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: Kernel 0.1, Win  [djg7]
Status: OR

"> " is Andreas Arff On 23 Mar 93 10:36:45 +0100
"> > " is Michael WINIKOFF

> > Kernel -- The Second Attempt
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Idea 1
> > ~~~~~~
> > Consider now the form of such a server (which incidently bears a striking
> > resemblence to the nameservers (or dictionaries)):
> >
> >     while (accept(request))
> >         case request of
> >             type1 : ... handle 1 ...
> >             type2 : ... handle 2 ...
> >
> > This type of code will be very common in the system.
> > It allready is in event based systems.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Those two sentences gives me the creeps. If I'll have to continue code that
> way I'll stick to windows until moose 2.0!
> Then we wouldn't have achieved the most important goal, simpleness!
> It must be simple to program, or else noone ever will, except us!
> Yes I see that we will need that type of structures in our code, but it can
> be minimized using ROI-like devices as I suggested in my last mail.
> Then that type of code will be neccesary only in the kernel and devices.

This type of code should almost never be necessary.  The correct way
to do this is something like a C++ Virtual Dispatch Table.  In other
words, just go straight to the right function.

> > Why then not have a process declare to the kernel that
> > "I handle the following request:
> >     req1 taking 4 parameters
> >     req2 taking 3 parameters
> > etc."
>
> I must say I belive that is to give the kernel to much work.
> I see 1 important goal for the kernel, to it keep efficient.
> It must be small enough to be kept in physical memory all the time. Think of
> a kernel, the most important (?) part in a system, that swaps itself out
> because of its size!

The kernel should NEVER be swapped.  Nor should any code/data the
kernel is using to do swapping.

> I think this is to give the kernel to much work.
> Why must a task go all the way down to the kernel to become familiar with
> other objects floating around in the address space. I belive this could be
> done in a higher level. Correct me if I'm wrong, I can take some flames!

The only other obvious choices are to ask the object itself or to have
a centralized server(?) that every object (class?) introduces itself
to.  But since the objects (classes) need to introduce themselves to
the kernel for the purpose of inheritence anyway, why not allow
outside processes to ask it as well?

> > This is just an object.
> > It has the concept of methods.
> >
> > [Note: It is open to discussion how much the kernel should know about the form
> > of the parameters (Eg. number, type ...)]
> >
> > [note 2: Inheritance has been left out for the moment.
> >  as have overloading and polymorphism]
> >
> > Definition 1
> > ~~~~~~~~~~~~
> > An object is a process with method declerations.
> >
> > Definition 2
> > ~~~~~~~~~~~~~
> > A Device or "LOw Level Object" (lolo) is an object which
> > either i
> > (1) has been granted the privilege of being able to refer to certain hardware
> > resources. (Eg. disk control registers, ethernet card)
> > AND/OR
> > (2) Has methods which are invoked upon the reciept of a particular interrupt.
> > (Eg. data ready)
> >
> > [Note: Most lolo's will have (1) -- I think that few will have ONLY (2)]
>
>   (3) It has also been granted the privilege to launch certain processes in
>   tasks that has asked for it.

Making callbacks to an invoker should not require any privilege.  Any
object that is given something to call back to can do this.

> >
> > Definition 3
> > ~~~~~~~~~~~~~
> > An OID (Object IDentifier) is an atomic data item that is valid across processes
> > (Note: In a distributed system it would be valid across machines too) and
> > can be used to address an object.
> >
> > Definition 4
> > ~~~~~~~~~~~~~
> > A Dictionary (Or Name Server) is an object which supports certain lookup
> > operations and returns an OID.
> >
> > [Note: We see the concept of object classes by the type of the supported methods
> > falling out. Whether  this should be enforced by the kernel or elsewhere
> > or not at all is open to debate]
> >
> >
> > Discussion: As can be seen, so far we need system calls to
[create skipped]
> >     * Invoking a method
> >         This takes
> >             (1) An OID
> >             (2) The method "name"
> >             (3) The arguments
> I referr to my last mail where I have drawn a event-que with pointers to
> functions. Maybe this way is somewhat better, that you supply the
> OID, method name and arguments into the task-que.

Since we want the object involved, adding the OID is obvious.  
Ideally, you might also be able to add entries without objects, but 
then you need to know a process and a location in the address space.  
Do-able.

> >         Issues:
> >             What is the type of the name?
> >             An integer is the obvious.
> >             When would the allocation of these be done?
> The integers? At compile time. When you create an object, the object will
> already contain numbers for its methods.
> If the OID is distributed at runtime there wont be any OID.method crashes.

I think I would rather see a set of numbers predefined for all objects
(though objects need not respond to them), and other numbers be
allocated at run-time, on a system-wide basis.  I will admit that this
will require remapping some numbers in a networking environment, but I
think we can live with this.  The name to number translation can also
be reversible, which can simplify writing debuggers and similar
functions.

[other issues skipped]
["A comment on (very) small objects" skipped]
["Some Other Issues" list skipped]
> > (1) Memory allocation:
> >     What kernel calls, how and should we support higher level functionality.
> >     (Eg. GC etc.)
> > (2) lolos:
> >     How do we set an object up as a lolo, how do we give it access to a
> >     certain region of memory.
> >     (Implementation: we might need to have the access traped and then redone
> >      by the kernel after checking -- MMUs don't neccessarily support fine
> >      grain protection.
> >      (Eg. this object can read bytes 100-102 and write bytes 103-110 but
> >      can't touch bytes 0-99 and 111-500)
>
>        We look in the object dictionary at boot-time and just launch those
>        objects that are listed under the device-index. Not that simple but
>        almost. There must be information telling us what it needs.
>        Maybe the standard devices should have their own dictionary (as I
>        belive Dennis talked about in Januar) "hardcoded" in the kernels
>        bootstrap code together with cpu ports lists for each device, and
>        eventually other requirements.

This is startup, which is liable to be a very painful process.  We
almost need to have the system come into being with lots of objects
already built.  This is actually possible by loading a checkpoint, but
we should have another way to do it.  Loading a checkpoint might be
allowed as a quick boot technique.

> > (3) Virtual Memory and Address Space
> >     I think we can more or less agree that seperate objects should not
> >     be able to read/write each others address space for robustness
> >     reasons.
> Yes.
> >     Should we have an address space that is global or local to each object.
> >     (Note: This IS an independant issue)
> If you mean that the object can reach outside its own address space, I
> belive the answer must be global. What if an object allocates memory and
> it's pointer can't reach outside the object itself? Or did I missunderstand
> something.

IMHO, if an object allocates memory, nothing other than the object (or
it's class depending on the allocation) should get access to the
memory.  To give someone else access, either the data must be
transfered through a method call, or a method call could initiate a
shared memory access.

> >     How should VM be done? I think paging is the simplest way.
> Don't know if it's the simplest way, but probably the smartest. I belive
> we are dumb if we only use segments.

If we are going to make this portable to something other than a
386/486/pentium, we can't use segments except for some very simple
stuff.

["(5) Semantics of invocation" skipped]
["(7) Polymorphism and Overloading" skipped]

> > And of course, feel free to comment, correct, suggest, debate and/or flame.
> The same to me.
And me.

> > Michael
> > Aka. Merlin son of Corwin and Dara, sorcerer and creator of Ghostwheel. :-)
>
> Ha, Time Lord and Merlin son of Corwin and Dara, sorecerer and creator of
> Ghostwheel, hah.
> Me I laugh at your pettyness. Me, I am THE DUNGEON MASTER. Tremble you
> weenie mortals, quiecheaters and lamers.
> Me laugh at your pettyness. Your pride is only bullshit, me say as imortal.
> You only live because of the GMs goodwill. So don't push your limits, then
> you might get killed.
>
> Arff :-)
>
> sig.'s in for 1000 miles service
>         --Andreas Arff          andreasa@dhhalden.no--

Campaign switch!  Now I'm THE DUNGEON MASTER.  I look, see some chaos,
set everyone on the Moose development team up as a deity, but with
power only as long as we all agree, and step down.  Chaos rules
supreme.  Oh well, maybe we can build some law.  Maybe we can also
achieve a certain amount of good, so the campaign will grow.
Thoughts?

David :-)

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From ANDREASA@sofus.dhhalden.no Wed Mar 24 09:36:04 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25473; Wed, 24 Mar 93 09:36:03 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 24 Mar 93 09:36:03 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14825; Wed, 24 Mar 93 00:30:53 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <24935-0@fenris.dhhalden.no>; Wed, 24 Mar 1993 09:30:36 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930324093016.352; 24 Mar 93 09:30:30 -0100
Message-Id: <MAILQUEUE-101.930324093011.320@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 24 Mar 93 09:30:11 +0100
Subject: Re: Kernel 0.1, Win [arf2]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

"> " is David
"> > " is Andreas Arff On 23 Mar 93 10:36:45 +0100
"> > > " is Michael WINIKOFF
>
> > > Kernel -- The Second Attempt
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > Idea 1
> > > ~~~~~~
> > > Consider now the form of such a server (which incidently bears a striking
> > > resemblence to the nameservers (or dictionaries)):
> > >
> > >     while (accept(request))
> > >         case request of
> > >             type1 : ... handle 1 ...
> > >             type2 : ... handle 2 ...
> > >
> > > This type of code will be very common in the system.
> > > It allready is in event based systems.
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Those two sentences gives me the creeps. If I'll have to continue code that
> > way I'll stick to windows until moose 2.0!
> > Then we wouldn't have achieved the most important goal, simpleness!
> > It must be simple to program, or else noone ever will, except us!
> > Yes I see that we will need that type of structures in our code, but it can
> > be minimized using ROI-like devices as I suggested in my last mail.
> > Then that type of code will be neccesary only in the kernel and devices.
>
> This type of code should almost never be necessary.  The correct way
> to do this is something like a C++ Virtual Dispatch Table.  In other
> words, just go straight to the right function.

Cannot agree more, but just a couple of remarks, or what I should call it.
1) I have heard that VDTs are slow (ok - somewhat implementation dependant.)
2) VDTs could (should) be done with ROI
3) Each device object could (should) have its own VDT

> > I must say I belive that is to give the kernel to much work.
> > I see 1 important goal for the kernel, to it keep efficient.
> > It must be small enough to be kept in physical memory all the time. Think of
> > a kernel, the most important (?) part in a system, that swaps itself out
> > because of its size!
>
> The kernel should NEVER be swapped.  Nor should any code/data the
> kernel is using to do swapping.

Good. But we can't have a kernel of the size of an elephant.

> > I think this is to give the kernel to much work.
> > Why must a task go all the way down to the kernel to become familiar with
> > other objects floating around in the address space. I belive this could be
> > done in a higher level. Correct me if I'm wrong, I can take some flames!
>
> The only other obvious choices are to ask the object itself or to have
> a centralized server(?) that every object (class?) introduces itself
> to.  But since the objects (classes) need to introduce themselves to
> the kernel for the purpose of inheritence anyway, why not allow
> outside processes to ask it as well?

Ok, if you can't beat them join them. Truly your argumentation, even though
it is very small, but clear as fresh mountain water, has convinced me.
You proposal will minimize the amount of communication done, because the
communication that is done, is necessary anyway.
IMHO an honorable idea!

> > > Definition 2
> > > ~~~~~~~~~~~~~
> > > A Device or "LOw Level Object" (lolo) is an object which
> > > either i
> > > (1) has been granted the privilege of being able to refer to certain hardware
> > > resources. (Eg. disk control registers, ethernet card)
> > > AND/OR
> > > (2) Has methods which are invoked upon the reciept of a particular interrupt.
> > > (Eg. data ready)
> > >
> > > [Note: Most lolo's will have (1) -- I think that few will have ONLY (2)]
> >
> >   (3) It has also been granted the privilege to launch certain processes in
> >   tasks that has asked for it.
>
> Making callbacks to an invoker should not require any privilege.  Any
> object that is given something to call back to can do this.

Yes, but if you give it something to call back to, you _have_ given it
some sort of privilige. So by announcing your OID and a method number is
the same as saying, "please do something to me".
Lets take a parallell to real life. Say you are at a disco (don't know how old
you are, but if you don't like the idea, let's call it a pub) and there is a
girl that seems quite alright. Before the end of the night you have given her
you telephone number. Now does this mean you have given her the privilege to
call you later, or did you just do it for the fun of it?
Me not know you, but I know what I think it would mean.

> > >         Issues:
> > >             What is the type of the name?
> > >             An integer is the obvious.
> > >             When would the allocation of these be done?
> > The integers? At compile time. When you create an object, the object will
> > already contain numbers for its methods.
> > If the OID is distributed at runtime there wont be any OID.method crashes.
>
> I think I would rather see a set of numbers predefined for all objects
> (though objects need not respond to them), and other numbers be
> allocated at run-time, on a system-wide basis.  I will admit that this
> will require remapping some numbers in a networking environment, but I
> think we can live with this.  The name to number translation can also
> be reversible, which can simplify writing debuggers and similar
> functions.

How are these #predefine NUMBERS going to be distributed. By a central bureua?
Each task has its own number, within the task there are objects, within the
objects there are methods.
This gives use: TASKNUMBER, OBJECTNUMBER, METHODNUMBER.
In a networking system we will also have MACHINENUMBER.
With these four numbers you can identify everything down to a simple
method.
Machine number will be fixed (for long periods), the task number will be its
launching number and each object will get a sub-number. The method number
and the object number could now be distributed at compile-time. I could
address an object in your machine with this scheme via internet.

> This is startup, which is liable to be a very painful process.  We
> almost need to have the system come into being with lots of objects
> already built.  This is actually possible by loading a checkpoint, but
> we should have another way to do it.  Loading a checkpoint might be
> allowed as a quick boot technique.

Know what checkpoint means, but I don't understand what you mean with it.

> > > (3) Virtual Memory and Address Space
> > >     I think we can more or less agree that seperate objects should not
> > >     be able to read/write each others address space for robustness
> > >     reasons.
> > Yes.
> > >     Should we have an address space that is global or local to each object.
> > >     (Note: This IS an independant issue)
> > If you mean that the object can reach outside its own address space, I
> > belive the answer must be global. What if an object allocates memory and
> > it's pointer can't reach outside the object itself? Or did I missunderstand
> > something.
>
> IMHO, if an object allocates memory, nothing other than the object (or
> it's class depending on the allocation) should get access to the
> memory.  To give someone else access, either the data must be
> transfered through a method call, or a method call could initiate a
> shared memory access.

I agree with you about that.

> > Ha, Time Lord and Merlin son of Corwin and Dara, sorecerer and creator of
> > Ghostwheel, hah.
> > Me I laugh at your pettyness. Me, I am THE DUNGEON MASTER. Tremble you
> > weenie mortals, quiecheaters and lamers.
> > Me laugh at your pettyness. Your pride is only bullshit, me say as imortal.
> > You only live because of the GMs goodwill. So don't push your limits, then
> > you might get killed.
> >
> > Arff :-)
> >
> Campaign switch!  Now I'm THE DUNGEON MASTER.  I look, see some chaos,
> set everyone on the Moose development team up as a deity, but with
> power only as long as we all agree, and step down.  Chaos rules
> supreme.  Oh well, maybe we can build some law.  Maybe we can also
> achieve a certain amount of good, so the campaign will grow.
> Thoughts?
Is this a PBM?
With power as long as we agree. Gooood. The kernel spec's will be our law,
and we are eagerly awaiting Dennis new spec's -0.71.

> David :-)

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From ANDREASA@sofus.dhhalden.no Wed Mar 24 10:21:03 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA26178; Wed, 24 Mar 93 10:21:01 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 24 Mar 93 10:21:01 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15994; Wed, 24 Mar 93 01:15:39 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <25643-0@fenris.dhhalden.no>; Wed, 24 Mar 1993 10:15:13 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930324101452.256; 24 Mar 93 10:15:07 -0100
Message-Id: <MAILQUEUE-101.930324101449.480@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 24 Mar 93 10:14:49 +0100
Subject: Kernel 0.11, [arf1]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

This is originaly Michaels mail, but I'll try to sumarize what we agree on.
Now notice this, if we are going get something done in a resonable amount of
time we must start to agree on things, as David mentioned as a postlude in
his last mail.
Now there are very few differences to Winikoffs mail but I suggest we use
Michaels mail as a working draft that will propagate around the world til
we have a draft. We will probably take Peter's ROI and Dennis next spec. and
add them to this list, or maybe add this and Peter's ROI to Dennis list
instead. Anyway we got to agree on the basics.
There are several "fields" which havn't been discussed yet, so I suggest we
look at these first.
Remeber one thing: We can always begin in the simple and step up when we need.
It is easier to see what works bad if there are only simple schems around.


 Kernel -- The Third Attempt
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 [NOTE: I'm starting from a conventional OS and moving away rather then starting
  from objects and moving towards OS -- I feel that this is more likely to
  yield a running system in a short amount of time. As Dennis has pointed out
  we don't have the resources to re-invent the wheel]

 Rather then just present details here I'd like to throw some ideas and
 justifications.

 Idea 1
 ~~~~~~
 We base the kernel on persistent processes.

 [Terminology: In a moment I'll modify this to persistent objects and explain
 the differences. By persistent I mean that it can be swapped out to storage,
 the machine turned off and on and then continued. In practice we would like
 to be able to have a large number of suspended processes on disk]

 This subsumes directories and files -- a directory is just a process that
 accepts queries and returns some identifier for the processes representing files

 Consider now the form of such a server (which incidently bears a striking
 resemblence to the nameservers (or dictionaries)):

     while (accept(request))
         case request of
             type1 : ... handle 1 ...
             type2 : ... handle 2 ...

 This type of code will be very common in the system.
 It allready is in event based systems.

 Why then not have a process declare to the kernel that
 "I handle the following request:
     req1 taking 4 parameters
     req2 taking 3 parameters
 etc."

 This is just an object.
 It has the concept of methods.

This type of code will only be necessary in the lolo's and kernel. Elsewhere
we will implement Virtual Dispatch Tables.

Discussion: How should we implement VDT. Is suggest my approach I have drawn
earlier with ROI. It's difficult to be objective, but of course there are
other ways of doing it.

 [Note: It is open to discussion how much the kernel should know about the form
 of the parameters (Eg. number, type ...)]
We havn't come to an agreement here as I have understod it.

 [note 2: Inheritance has been left out for the moment.
  as have overloading and polymorphism]
Not here either.

 Definition 1
 ~~~~~~~~~~~~
 An object is a process with method declerations.

 Definition 2
 ~~~~~~~~~~~~~
 A Device or "LOw Level Object" (lolo) is an object which
 either i
 (1) has been granted the privilege of being able to refer to certain hardware
 resources. (Eg. disk control registers, ethernet card)
 AND/OR
 (2) Has methods which are invoked upon the reciept of a particular interrupt.
 (Eg. data ready)

 [Note: Most lolo's will have (1) -- I think that few will have ONLY (2)]

We agree upon this.

 Definition 3
 ~~~~~~~~~~~~~
 An OID (Object IDentifier) is an atomic data item that is valid across processes
 (Note: In a distributed system it would be valid across machines too) and
 can be used to address an object.
 The id is an integer.

Also agreed upon.

 Definition 4
 ~~~~~~~~~~~~~
 A Dictionary (Or Name Server) is an object which supports certain lookup
 operations and returns an OID.

Agreed upon.

 [Note: We see the concept of object classes by the type of the supported methods
 falling out. Whether  this should be enforced by the kernel or elsewhere
 or not at all is open to debate]


 Discussion: As can be seen, so far we need system calls to
     * Create new objects
         This must take in parameters describing
             (1) The code
             (2) The method declerations
         These two should/must be together in an executable
             (3) OIDs for the objects which the new object has
                 access to
         This is important -- it replaces the concept of a default
         name server. The only object that is not given an object by
         it's spawner is the initial object. Giving it a nameserver
         is part of the bootstrap process.
     * Destroy objects -- clearly this takes an OID as a parameter
     * Invoking a method
         This takes
             (1) An OID
             (2) The method "name"
             (3) The arguments
         Issues:
             What is the type of the name?
             An integer is the obvious.
An atomic integer as suggested by all of us. See def. 3.
             When would the allocation of these be done?
There are two suggestions; mine and Davids. Any more?
             The permissible type of the arguments?
             in a purely OO system we could just have OIDs and be
             done. In our system it is doubtful that representing
             (eg.) an array by an object would be practicle so we
             need to be able to pass large granularity data between
             objects.

             This is where IPC comes in.
             (I'm using the definition that IPC involves data
              copying between address space]



 A comment on (very) small objects
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 In a pure OO environment one could use an object to represent say an array
 (not to mention an integer)

 This is impracticle if we treat objects as processes since then a method
 invocation involves a context switch.

 This does not prohibit using small objects WITHIN a single larger object it's
 just that these small objects can't be exported to the rest of the system.

 I don't think that we can develop a system supporting small objects with
 reasonable efficiency in reasonable time. It involves too much research.

As I see it, we agree with Dennis here.


 Some Other Issues
 ~~~~~~~~~~~~~~~~~~~~

 These are areas which bear further thought.
 I'll indicate my initial reactions to these issues.
 Rather then spend time filling out the details now (and spark a debate on them)
 I'd like to come to agreement on the basics first.


 ---------
 (1) Memory allocation:
     What kernel calls, how and should we support higher level functionality.
     (Eg. GC etc.)
We have two suggestions here. Either a C-like way of doing it or Fare's way.
(Don't remeber it exactly). I think it was more support for Dennis way of
doing it. (Hope I didn't jump upon anyones toes now:-)

 (2) lolos:
     How do we set an object up as a lolo, how do we give it access to a
     certain region of memory.
     (Implementation: we might need to have the access traped and then redone
      by the kernel after checking -- MMUs don't neccessarily support fine
      grain protection.
      (Eg. this object can read bytes 100-102 and write bytes 103-110 but
      can't touch bytes 0-99 and 111-500)

Still an open question if I remember right.

 (3) Virtual Memory and Address Space
     I think we can more or less agree that seperate objects should not
     be able to read/write each others address space for robustness
     reasons.
     Should we have an address space that is global or local to each object.
     (Note: This IS an independant issue)

We agreed upon local (well - noone else said anything else :-)

     How should VM be done? I think paging is the simplest way.
     DEtails:
         User input to the process if any
         Existance of PHYS_MEM and it's management

Agreed upon paging.
Details havn't been discussed yet, but as far as we have come with the
implementation I belive we could use the MEM_PHYS until we feel we need
swaping.

 (4) Semantics of persistance:
     One way to do persistance is to simply rely on paging -- assume all
     objects are in a very large memory and let paging load them in as
     needed.
     As Dennis has pointed out this is inefficient.
     Another way is swapping -- a process can only be either completely
     swapped out or completely in memory.
     Disadvantage: Lose the ability to save memory by having part of a
         process in memory
     Advantages: (1) Can be done without an MMU
         (2) By letting the user do this manually we allow coarse grain
         manual resource allocation.
         (Sort of like doing a "copy foo TO ramdisk" b4 starting
          and having an automatic save files to hard disk from ramdisk
          when about to shutdown)

We havn't come to an agreement here, since there hasn't been any discussion.
So let me suggest this. This is not a priority issue. We just use the
simplest available scheme, and then we can step up to use a more advanced
scheme when needed.

 (5) Semantics of invocation
     MOOSE is multitasking.
     What happens in the following situation:

     Object X    Object Y    Object Z
     Invoke(Z,1)
                     Starts executing method 1
             Invoke(Z,2)
 The three obvious possibilities are
 (a) Z starts another method in parallel
 (b) Y is blocked until Z finishes
 (c) Y continues and the invocation is queued.

 (a) Gives us multithreading and requires us to have semaphores to co-ordinate
 access to shared data.
 (b) Is the simplest to implement but is less versatile
 (c) Makes invocation asynchronous -- this adds paralellism to the system.

 Notice that under (b) one could have the invoke call return a result.
 Under (c) though the invoke would not return anything (other then
 "this was succesfuly queued" OR "this failed") and the reciever would use
 it's own invoke to return an answer.

 Of course we could (and probly will end up doing) provide more then one.

We have agreed on alternative c, but we implement the simplest scheme first.

 (6) Inheritance
     I've left this out for now.
     One question I would like to raise is WHICH INHERITANCE?
     There are multiple models -- C++, Smalltalk.
     Oh,  and this is without considering multiple inheritance.

Could someone outline the smalltalk way, ada way and the simula way. I'm not
familiar with other then C++, and I havn't studied ADA for a couple of years.

 (7) Polymorphism and Overloading
     So far I've only come across these as language design issues.
      You have a "natural" polymorphism in some commands
      (Eg. mv,rm,cp) when the contents of a file don't matter.

      Could someone expound on their ideas -- how do YOU view the role
      and function of polymorphism in an OS.
Still an open question.

 --------------------------
 And of course, feel free to comment, correct, suggest, debate and/or flame.

 Michael
 Aka. Merlin son of Corwin and Dara, sorcerer and creator of Ghostwheel. :-)

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed Mar 24 13:44:03 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00457; Wed, 24 Mar 93 13:44:02 +0100
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 24 Mar 93 13:44:02 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19839; Wed, 24 Mar 93 04:40:22 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa02177; 24 Mar 93 7:36 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa05645;
          24 Mar 93 12:35 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa19514;
          24 Mar 93 12:34 GMT
To: moose-programmers@sfu.ca
Subject: Re: Kernel 0.1, Win [djg7] 
Date: Wed, 24 Mar 93 07:34:33 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303241234.aa19514@gloin.cis.udel.edu>
Status: OR

In Message <2bb00178.davgar@davgar.UUCP> ,
   david%davgar@uunet.uu.net wrote:

=>This type of code should almost never be necessary.  The correct way
=>to do this is something like a C++ Virtual Dispatch Table.  In other
=>words, just go straight to the right function.

   Right, so we have one of those wonderful arrays of pointers to
functions that are so cute in C. :-)  void (*foo[])(va_alist);
Of course, there should probably be an entry-point function to
process incoming calls.

=>I think I would rather see a set of numbers predefined for all objects
=>(though objects need not respond to them), and other numbers be
=>allocated at run-time, on a system-wide basis.  I will admit that this
=>will require remapping some numbers in a networking environment, but I
=>think we can live with this.  The name to number translation can also
=>be reversible, which can simplify writing debuggers and similar
=>functions.

   I'd prefer to have a global string space than an integer space and
map the strings to integers at runtime.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dmarer@td2cad.intel.com Wed Mar 24 19:37:44 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07920; Wed, 24 Mar 93 19:37:43 +0100
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 24 Mar 93 19:37:43 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06627; Wed, 24 Mar 93 10:23:37 -0800
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Wed, 24 Mar 93 10:23:32 -0800
Received: by td2cad (5.57/10.0i); Wed, 24 Mar 93 10:27:20 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00667; Wed, 24 Mar 93 10:34:46 PDT
Date: Wed, 24 Mar 93 10:34:46 PDT
Message-Id: <9303241834.AA00667@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re: Kernel 0.11, [arf1]
Status: OR

Howdy all!

Some comments on the kernel so far - looks pretty good!

One statement concerns me: "every object is a process..."  I'm assuming you
mean every *instance* of an object is a process, which would require a lot of
overhead.  (As an estimate, a system might use between 256 bytes and 8k to
represent a single process and its registers, state of the machine, etc.)

*Note* Andreas mentioned using 'objects' to represent an integer, etc.  This
is commonly done using a 'concrete object', or one with no virtual methods
and no capability of inheritance -> only concrete methods.  The data overhead
to accomplish this is *zero* and most of the functions are inline anyway.
This should be left up to the compiler - creating a regular object to do this
is probably silly anyway because the overhead for an object is usually larger
than the size of an integer anyway.  SEP (Somebody Else's Problem).

So most of our objects will be larger than an integer anyway.  I think from
the implementation perspective, a task switch is a very expensive operation.
(Again, an estimate on the 386 is about 100 clock cycles!)

Some objects will *need* to be processes: device drivers, applications, etc.
I don't believe every object does though - for example, a spreadsheet might
represent every cell as an object, and no other application would need to
access these objects.  Therefore, they are private to the spreadsheet and
dependent entirely on the spreadsheet process, or the instances of the cell
objects are contained within the spreadsheet process.  (They occupy this
process' data space.)

Now take a look at a database application: multiple processes would need
access to the same instance of an object (a record in the database) at once.
Each process can change the object, and (possibly) one process changing a
database record notifies all other processes with interests in that record
that a change has been made so they may update themselves accordingly.  This
type of object is a 'public' object, stored (most likely) in some shared memory
space, and has some special characteristics allowing it to be shared between
processes and (in a distributed system) between systems.  Methods for sharing
these objects between processes and systems are implemented in the next type
of object, which is....

The process object.  Descendants of this type of object would be applications,
device drivers, and *possibly* the kernel itself.  Processes have some way of
making themselves available to other processes, and if one process knows the
interface to another, they can communicate directly.  As mentioned before,
shared object stored in this manner would probably be distributed through this
interface.

So far, this is our object heirarchy:

			object
		   |		  |
	     shared object  process object

An 'object' is the definition of how an object in this system is structured,
how it behaves, how its attributes (data) are stored, and how its methods
(functions) are accessed.  Most languages (C++) do not define an 'object'
object, but in this system *all* objects have a common ancestor.  If, for
example, an object were defined in C++ with no ancestors, it would (by the
compiler) be given the 'object' ancestor by default.  This ties all objects
together with a single ancestor, closing a major gap in to OOP paradigm.
Maybe it defines some methods...I don't know yet.  This kind of object is
created in a private memory area, which must be owned by some process.
Maybe this object defines some virtual methods for loading itself and storing
itself to and from a 'file' object?  This way, all objects are given the
interface to load/store, and whether or not this is implemented is up to the
object designer.  Also, the 'object' object would be given some method to
identify itself in a system dependent manner, defining which module the object
is found in an what the object is called. (module:object)  This I don't know
how to define yet...

A 'shared object' is the next step in this heirarchy, and represents an object
which can be shared between mutlitple processes, or (eventually) between
systems in a distributed system.  This object must be able to handle itself
contention of multiple processes through the use of semaphores or other similar
devices.  This kind of object is created in a shared memory area, which must
be owned by some process.  Some process must manage these - they are not
independent in and of themselves. 

A 'process object' is the type of object associated with a task or application.
When a process object is instanciated, it can be made public to other proceses
(or not) through which other processes have access to its methods.  These are
managed by the kernel, and access to processes (finding a process object
pointer?) is done via the kernel.

----------------------

An example using this scheme, implementing a database application:

The database process is started for a particular database, placing it in the
system wide table of processes, or giving only a limited subset of processes
access to it.  (This access and protection still needs to be ironed out...)

Another process begins, and needs to access the database.  It requests the
kernel for a pointer to the database process object.  Next, it needs to find
all records in the database with a certain search criteria, and uses the
database process object's methods to perform this search, returning a list of
objects.  Each of these objects are instances of shared objects stored in
memory managed by the database process; for all the requesting process knows,
it instanciated these objects itself and should treat them as such.  *Note*:
directly modifying the contents of these objects is not allowed...  Next,
another process accesses the database and also requests similar records, so
now two processes have pointers to identical objects (the same data, *not*
two instances!).  The first process *destroys* its version of the shared
objects (the database records) when it is through, just as it would with any
other object, except instead of freeing memory it only dereferences the object,
and when the reference count reaches zero the object is actually destroyed.

Did I mention the second process existed on another system? :-)

Basically, when processes are created some access protection is set to allow
use by a single user, multiple users, multiple systems, etc.  This example
database application would probably allow multiple user access, but only a
limited subset of "installed" users.  I.E., the database has complete control
over which users are allowed to access its process (via the kernel) to begin
with.

--------------------------

I envision shared memory being read-only by all processes except the owner.
(The owner can write as well.)  Across distributed systems, process should not
even be allowed to read shared memory.  This way, all information can be
gathered from an object without a task switch; to modify an object requires a
task switch to the owner's task, so each method in a shared object must be
classified in some way to allow this to happen.

Ok...these thoughts are a little sketchy, but coming together nicely.  Let me
know what you think!  This is absolutely implementable - I've done my research
there.  I think this is our best bet of an object oriented system...

			Dennis

From winikoff@cs.mu.OZ.AU Thu Mar 25 02:24:14 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14961; Thu, 25 Mar 93 02:24:13 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 25 Mar 93 02:24:13 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11575; Wed, 24 Mar 93 17:20:31 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA23078
	Thu, 25 Mar 1993 11:01:00 +1000 (from winikoff)
Message-Id: <9303250101.23078@mulga.cs.mu.OZ.AU>
Subject: Dungeon Masters
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 25 Mar 93 11:00:59 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <2bb00178.davgar@davgar.UUCP>; from "david@uunet.UU.NET" at Mar 24, 93 1:36 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> > > Michael
> > > Aka. Merlin son of Corwin and Dara, sorcerer and creator of Ghostwheel. :-)
> >
> > Ha, Time Lord and Merlin son of Corwin and Dara, sorecerer and creator of
> > Ghostwheel, hah.
> > Me I laugh at your pettyness. Me, I am THE DUNGEON MASTER. Tremble you
> > weenie mortals, quiecheaters and lamers.
> > Me laugh at your pettyness. Your pride is only bullshit, me say as imortal.
> > You only live because of the GMs goodwill. So don't push your limits, then
> > you might get killed.
> >
> > Arff :-)
> >
> > sig.'s in for 1000 miles service
> >         --Andreas Arff          andreasa@dhhalden.no--
> 
> Campaign switch!  Now I'm THE DUNGEON MASTER.  I look, see some chaos,
> set everyone on the Moose development team up as a deity, but with
> power only as long as we all agree, and step down.  Chaos rules
> supreme.  Oh well, maybe we can build some law.  Maybe we can also
> achieve a certain amount of good, so the campaign will grow.
> Thoughts?

If we start a role playing campaign we won't get enough work done on moose ...
:-)

> 
> David :-)
> 
> -- 
> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Thu Mar 25 02:24:57 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14972; Thu, 25 Mar 93 02:24:56 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 25 Mar 93 02:24:56 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11665; Wed, 24 Mar 93 17:21:45 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA23458
	Thu, 25 Mar 1993 11:12:34 +1000 (from winikoff)
Message-Id: <9303250112.23458@mulga.cs.mu.OZ.AU>
Subject: Re: Kernel 0.1, Win [djg7]
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 25 Mar 93 11:12:33 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To:  <9303241234.aa19514@gloin.cis.udel.edu>; from "Gary D. Duzan" at Mar 24, 93 7:34 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> =>think we can live with this.  The name to number translation can also
> =>be reversible, which can simplify writing debuggers and similar
> =>functions.
> 
>    I'd prefer to have a global string space than an integer space and
> map the strings to integers at runtime.

I think this is a bad idea -- method calls will be quite common in the system.
We will lose heavily in performance if each method involves a string -> int
translation.

> 
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 
> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Thu Mar 25 04:24:11 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16748; Thu, 25 Mar 93 04:24:10 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 25 Mar 93 04:24:10 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17295; Wed, 24 Mar 93 19:20:52 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA29219
	Thu, 25 Mar 1993 13:20:31 +1000 (from winikoff)
Message-Id: <9303250320.29219@mulga.cs.mu.OZ.AU>
Subject: Everything You ever Wanted To know about Virtual Memory
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 25 Mar 93 13:20:29 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

We've had a number of problems with terminology over virtual memory and address
spaces.

The aim of this mail is to clearly (hopefuly) define and clarify this area.

(1) What is an address space?
What gets refered to when a process has an instruction that referes to memory.
Ie. a processes view of memory.

(2) What is virtual memory?
The mechanism that swaps regions of physical memory to disk when they're not
often used.

(3) What is memory protection?
The mechanism whereby despite a memory region being in my address space I cannot
do certain things to it (EG. run code in it. write it etc.)

These three are independant.
In practice all three are performed with the aid of an MMU.

Hypothetically one can envisage systems where ...
(i) All processes have the same addres space, there is no virtual memory and
there is no memory protection (Eg, an MMU-less machine, MS-DOS)

(ii) All processes have separate address spaces, there is virtual memory and
there is memory protection that stops a program from writing on code or 
executing data (Various Unixen)

(iii) All processes have the same adress space but cannot write on sections of
memory that belong to other processes. (One of the proposed designs for MOOSE,
some research OSes for 64 bit machines)
[Ie. process X might "own" addresses 1000-2000 and process Y owns 4000-5000.
Process X can still REFER to address 4500 -- if memory protection allows it
to. This reference will be to the memory used by process Y]


Is this clear?
Please comment if something here seems unclear or ambiguous -- if we can't 
agree on terminology it's hard having a sensible discussion which makes sense
to both sides ...

Michael

--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From uunet.UU.NET!davgar!david Thu Mar 25 05:56:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23829; Thu, 25 Mar 93 05:56:32 +0100
Return-Path: <uunet.UU.NET!davgar!david>
Received-Date: Thu, 25 Mar 93 05:56:32 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21087; Wed, 24 Mar 93 20:53:34 -0800
Received: from uunet.uu.net (via spool.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA24399; Wed, 24 Mar 93 23:53:45 -0500
Received:  by davgar.UUCP (UUPC/extended 1.11xDAVGAR7);
           Wed, 24 Mar 1993 23:48:40 EST
Date:      Wed, 24 Mar 1993 23:48:37 EST
From: (David Garfield) uunet.uu.net!davgar!david
Message-Id: <2bb139aa.davgar@davgar.UUCP>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   On method numbers [djg8]
Status: OR

"> " is Andreas Arff On 24 Mar 93 09:30:11 +0100
"> > " is David
"> > > " is Andreas Arff On 23 Mar 93 10:36:45 +0100
"> > > > " is Michael WINIKOFF writing "Kernel -- The Second Attempt"

[discussions of objects dropped]
> > > >         Issues:
> > > >             What is the type of the name?
> > > >             An integer is the obvious.
> > > >             When would the allocation of these be done?
> > > The integers? At compile time. When you create an object, the object will
> > > already contain numbers for its methods.
> > > If the OID is distributed at runtime there wont be any OID.method crashes.
> >
> > I think I would rather see a set of numbers predefined for all objects
> > (though objects need not respond to them), and other numbers be
> > allocated at run-time, on a system-wide basis.  I will admit that this
> > will require remapping some numbers in a networking environment, but I
> > think we can live with this.  The name to number translation can also
> > be reversible, which can simplify writing debuggers and similar
> > functions.
>
> How are these #predefine NUMBERS going to be distributed. By a central bureua?
> Each task has its own number, within the task there are objects, within the
> objects there are methods.
> This gives use: TASKNUMBER, OBJECTNUMBER, METHODNUMBER.

OIDs have already been described as unique system-wide.  I am arguing
that method numbers should also be SYSTEM-WIDE.  This gives us:
OBJECTNUMBER, METHODNUMBER.

This gives us two categories of method numbers.

The first is a set of predefined numbers.  These numbers are defined
by the gods of moose (us), once set will never (after first public
release) be changed, and will be usable by all objects.  Amongst these
predefined numbers will be things like
        Inquire_Subobjects(?),
        write(void *buffer, int length)
        read(void *buffer, int length)
        DisplayOn(?)
Simply, anything very common or basic could wind up here.  In fact,
EVERY (predefined) method of the root class would be a predefined
method number, as well as most methods from common abstract classes
(like a video object).

The second category of method numbers is numbers allocated while the
system is running.  My thought is that, when a program is loaded, the
list of methods in the header is passed to a kernel routine that
manages name to number translation.  Any name that isn't found is
added as a new number.  The numbers thus obtained could then be used
to modify the loaded image so that, once the program is running, it
does know it wasn't a constant.  If a program needs to, for one reason
or another, it could invoke kernel routines for name to number or
number to name.

The truth of the matter is that the first category could be eliminated
completely, but, I think that by having it and by putting the right
methods into it, we can eliminate at least 95% of the translations.
This would be a good thing if just for the sake of efficiency.


> In a networking system we will also have MACHINENUMBER.
> With these four numbers you can identify everything down to a simple
> method.
> Machine number will be fixed (for long periods), the task number will be its
> launching number and each object will get a sub-number. The method number
> and the object number could now be distributed at compile-time. I could
> address an object in your machine with this scheme via internet.

In a network forwarder, I would prefer that the forwarder handle
translation of OIDs and Method numbers from one machine to the other.
In this case, the local alias of the object can include the remote
machine identification and object identification.

You can't address an object on my machine via internet.  I'm not on
internet, just usenet.  It will interesting to see you address objects
on my machine via MAIL.  :-)  Actually, I want to try it!

> > > Arff :-)
> > David :-)
> Arff
David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From fate@ccwf.cc.utexas.edu Thu Mar 25 15:33:24 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03954; Thu, 25 Mar 93 15:33:23 +0100
Return-Path: <fate@ccwf.cc.utexas.edu>
Received-Date: Thu, 25 Mar 93 15:33:23 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from happy.cc.utexas.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA04334; Thu, 25 Mar 93 06:30:32 -0800
Received: by happy.cc.utexas.edu (5.61/1.34/CCWF 1.21)
	id AA28124; Thu, 25 Mar 93 08:30:29 -0600
Date: Thu, 25 Mar 93 08:30:29 -0600
From: fate@ccwf.cc.utexas.edu (Murphy's Law)
Message-Id: <9303251430.AA28124@happy.cc.utexas.edu>
To: winikoff@mulga.cs.mu.OZ.AU
Subject: Re:  Everything You ever Wanted To know about Virtual Memory
Cc: moose-programmers@sfu.ca
Status: OR

>(iii) All processes have the same adress space but cannot write on sections
>of memory that belong to other processes. (One of the proposed designs for
>MOOSE, some research OSes for 64 bit machines)
>[Ie. process X might "own" addresses 1000-2000 and process Y owns 4000-5000.
>Process X can still REFER to address 4500 -- if memory protection allows it
>to. This reference will be to the memory used by process Y]

I don't like the idea of processes being able to read all the data from
other processes..  


That would entail a few things that could cause problems -- 
	A)  A tendency to rely on fixed addresses
	B)  insecurity on a possible multiuser implementation *shrug*
	C)  programs having to keep track of their own addresses.
 
I think it might be a lot simpler to have the process that needs to access 
data from another task make a call to the object, passing it a way of writing (or some way of communicating between the processes) and passing a copy of the
data.  There are fast instructions, eg, MOVSW / MOVSD on the 386, and there are
comparable on the 680x0, so it wouldn't be that hard..  and objects can control what they want to share!
 
Just my fraction of a penny.

From winikoff@cs.mu.OZ.AU Fri Mar 26 08:16:13 1993
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["7022" "Fri" "26" "March" "93" "16:42:05" "EST" "Michael David WINIKOFF" "winikoff@mulga.cs.mu.OZ.AU" nil "135" "Re: Kernel 0.11, [arf1]" "^From:" nil nil "3"])
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24564; Fri, 26 Mar 93 08:16:12 +0100
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 26 Mar 93 08:16:12 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03498; Thu, 25 Mar 93 23:10:43 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA08047
	Fri, 26 Mar 1993 16:42:06 +1000 (from winikoff)
Message-Id: <9303260642.8047@mulga.cs.mu.OZ.AU>
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 26 Mar 93 16:42:05 EST
In-Reply-To: <9303241834.AA00667@tdge15.intel.com>; from "Dennis Marer" at Mar 24, 93 10:34 am
X-Mailer: ELM [version 2.3 PL0]
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
Subject: Re: Kernel 0.11, [arf1]
Status: OR

> 
> Howdy all!
> 
> Some comments on the kernel so far - looks pretty good!
> 
> One statement concerns me: "every object is a process..."  I'm assuming you
> mean every *instance* of an object is a process, which would require a lot of
> overhead.  (As an estimate, a system might use between 256 bytes and 8k to
> represent a single process and its registers, state of the machine, etc.)
> 

Let me explain. 
What I meant was that a MOOSE object is defined to be a process.
A small object that isn't a process (Eg. is internal to a process/large-object)
isn't viewed as an object by the system.


Ie. objects REPLACE processes -- there is only the single (merged) concept.

[Private objects deleted]
Private objects are not viewed as MOOSE objects.

> 
> Now take a look at a database application: multiple processes would need
> access to the same instance of an object (a record in the database) at once.
> Each process can change the object, and (possibly) one process changing a
> database record notifies all other processes with interests in that record
> that a change has been made so they may update themselves accordingly.  This
> type of object is a 'public' object, stored (most likely) in some shared memory
> space, and has some special characteristics allowing it to be shared between
> processes and (in a distributed system) between systems.  Methods for sharing
> these objects between processes and systems are implemented in the next type
> of object, which is....
> 
> The process object.  Descendants of this type of object would be applications,
> device drivers, and *possibly* the kernel itself.  Processes have some way of
> making themselves available to other processes, and if one process knows the
> interface to another, they can communicate directly.  As mentioned before,
> shared object stored in this manner would probably be distributed through this
> interface.
> 
> So far, this is our object heirarchy:
> 
> 			object
> 		   |		  |
> 	     shared object  process object
> 
> An 'object' is the definition of how an object in this system is structured,
> how it behaves, how its attributes (data) are stored, and how its methods

I don't think we should dictate how the data is stored -- we shoudl instead
limit ourselves to accessing said data through methods. Comments?

> (functions) are accessed.  Most languages (C++) do not define an 'object'
> object, but in this system *all* objects have a common ancestor.  If, for
> example, an object were defined in C++ with no ancestors, it would (by the
> compiler) be given the 'object' ancestor by default.  This ties all objects
> together with a single ancestor, closing a major gap in to OOP paradigm.
> Maybe it defines some methods...I don't know yet.  This kind of object is
> created in a private memory area, which must be owned by some process.
> Maybe this object defines some virtual methods for loading itself and storing
> itself to and from a 'file' object?  This way, all objects are given the
> interface to load/store, and whether or not this is implemented is up to the
> object designer.  Also, the 'object' object would be given some method to
> identify itself in a system dependent manner, defining which module the object
> is found in an what the object is called. (module:object)  This I don't know
> how to define yet...
> 
> A 'shared object' is the next step in this heirarchy, and represents an object
> which can be shared between mutlitple processes, or (eventually) between
> systems in a distributed system.  This object must be able to handle itself
> contention of multiple processes through the use of semaphores or other similar
> devices.  This kind of object is created in a shared memory area, which must
> be owned by some process.  Some process must manage these - they are not
> independent in and of themselves. 
> 
> A 'process object' is the type of object associated with a task or application.
> When a process object is instanciated, it can be made public to other proceses
> (or not) through which other processes have access to its methods.  These are
> managed by the kernel, and access to processes (finding a process object
> pointer?) is done via the kernel.
> 
> ----------------------
> 
> An example using this scheme, implementing a database application:
> 
> The database process is started for a particular database, placing it in the
> system wide table of processes, or giving only a limited subset of processes
> access to it.  (This access and protection still needs to be ironed out...)
> 
> Another process begins, and needs to access the database.  It requests the
> kernel for a pointer to the database process object.  Next, it needs to find
> all records in the database with a certain search criteria, and uses the
> database process object's methods to perform this search, returning a list of
> objects.  Each of these objects are instances of shared objects stored in
> memory managed by the database process; for all the requesting process knows,
> it instanciated these objects itself and should treat them as such.  *Note*:
> directly modifying the contents of these objects is not allowed...  Next,
> another process accesses the database and also requests similar records, so
> now two processes have pointers to identical objects (the same data, *not*
> two instances!).  The first process *destroys* its version of the shared
> objects (the database records) when it is through, just as it would with any
> other object, except instead of freeing memory it only dereferences the object,
> and when the reference count reaches zero the object is actually destroyed.
> 
> Did I mention the second process existed on another system? :-)
> 
> Basically, when processes are created some access protection is set to allow
> use by a single user, multiple users, multiple systems, etc.  This example
> database application would probably allow multiple user access, but only a
> limited subset of "installed" users.  I.E., the database has complete control
> over which users are allowed to access its process (via the kernel) to begin
> with.
> 
> --------------------------
> 
> I envision shared memory being read-only by all processes except the owner.
> (The owner can write as well.)  Across distributed systems, process should not
> even be allowed to read shared memory.  This way, all information can be
> gathered from an object without a task switch; to modify an object requires a
> task switch to the owner's task, so each method in a shared object must be
> classified in some way to allow this to happen.
> 
> Ok...these thoughts are a little sketchy, but coming together nicely.  Let me
> know what you think!  This is absolutely implementable - I've done my research
> there.  I think this is our best bet of an object oriented system...
> 
> 			Dennis
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From ANDREASA@sofus.dhhalden.no Fri Mar 26 09:46:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA26462; Fri, 26 Mar 93 09:46:53 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Fri, 26 Mar 93 09:46:53 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07524; Fri, 26 Mar 93 00:41:37 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <04305-0@fenris.dhhalden.no>; Fri, 26 Mar 1993 09:41:11 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930326094047.448; 26 Mar 93 09:41:01 -0100
Message-Id: <MAILQUEUE-101.930326094037.416@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 26 Mar 93 09:40:37 +0100
Subject: ORG, GEN arf1
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

Howdy all elgers

I have some things to say about the organization. It stinks.
Yes, this is another of those "nowwemustputourselftogether" mails.

First:
Let's divide into smaller groups.

Second:
Let's get something done.

I suggest these groups:
1) Kernel
   Nucleus(?) - Dennis is boss, he has already done some work with this.
   ROI - Peter?

2) Common IO devices - pretty large area but the most important first.
  All reporting is done to the Leader in this group.
   - Keyboard
   - Disks (Harddisk/floppy disk)
   - com-port/Mice
   - parallell ports
   - SCSI interface - Someone has already mentioned his interest for this
   - UI - I'll take that part if no one objects, anyway this is why I'm here.

3) Language support - Fare'

Now we have a working OS?
I suppose most of you have an "area" they want to work with.

Now what are you going to do now. Write a flameing letter telling me to go to
hell, or complain over putting you together with that nut-head, or telling me
that no norwegian is going to decide what to do when?
I say NO!

Now what you are going to do!
Send me a PRIVATE mail together with your wish. What would you like to work
with? If there are things you think I have forgot (as the group deciding what
the object should look like?:-) don't hesistate to mention it.
Now, this don't mean we must stop these discussions about eg. memory
allocation schemes, only that we must more than discuss!
Also tell me whether you would like to become a group chief.
There are two already, if they don't change their minds, Dennis and Fare'.

Now if there is interrest we can split group two into smaller parts.
You might protest I have put myself up on the (G)UI group, but if you
don't like it you should have told us so the second week of Januar:-).

Ok, send me a mail and I'll work out a working list as fast as I can, and if
you don't respond within a small time I'll put you up in the group that I
think needs you.


Ok,ok,ok here from you?

Arff

PS. Now DM has given you rules. Obey these and your work will be fruitful,
remeber we are powerful as long there are unity and we obey the rules.
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From mueller@sc.ZIB-Berlin.DE Fri Mar 26 11:04:57 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28389; Fri, 26 Mar 93 11:04:56 +0100
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Fri, 26 Mar 93 11:04:56 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09185; Fri, 26 Mar 93 01:56:39 -0800
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA08619; Fri, 26 Mar 93 10:56:13 +0100
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA08676; Fri, 26 Mar 93 10:56:12 +0100
Date: Fri, 26 Mar 93 10:56:12 +0100
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9303260956.AA08676@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: ORG, GEN arf1
Cc: ANDREASA@dhhalden.no
Status: OR

nice text ... really :-)


> Howdy all elgers
> 
> I have some things to say about the organization. It stinks.
> Yes, this is another of those "nowwemustputourselftogether" mails.
> 
> First:
> Let's divide into smaller groups.
> 
> Second:
> Let's get something done.
> 
> I suggest these groups:
> 1) Kernel
>    Nucleus(?) - Dennis is boss, he has already done some work with this.
>    ROI - Peter?

For me that's ok. But here are my restrictions:

I'm going to England in April, thus, I'm not able to answer until April 30th.
(This is my first holiday since several years, so I will go, whether you like
it or not :-)

Next: There should be first a group which thinks about IPC mechanisms. If noone
is interested I will do it, though my time constraints are very restrictive. If
there's someone else ... I'm the first one who supports him!

Besides the time constraints another important restriction arise: I'm only able
to work here at this organisation until Sep. 30th, because I will finish my
diploma thesis this July. The contract is restricted until I'm ready. So, that's
the very bad news (not for me! I'm happy to start working on my PhD :-)

Therefore: I'm currently running around, searching for a place where I can
make the PhD in the next years. I hope to find an engagement before I'm leaving
and to let you know, where I'm reachable then.

> 
> 2) Common IO devices - pretty large area but the most important first.
>   All reporting is done to the Leader in this group.
>    - Keyboard
>    - Disks (Harddisk/floppy disk)
>    - com-port/Mice
>    - parallell ports
>    - SCSI interface - Someone has already mentioned his interest for this
>    - UI - I'll take that part if no one objects, anyway this is why I'm here.
> 
> 3) Language support - Fare'
> 
> Now we have a working OS?
> I suppose most of you have an "area" they want to work with.
> 
> Now what are you going to do now. Write a flameing letter telling me to go to
> hell, or complain over putting you together with that nut-head, or telling me
> that no norwegian is going to decide what to do when?
> I say NO!
> 
> Now what you are going to do!
> Send me a PRIVATE mail together with your wish. What would you like to work
> with? If there are things you think I have forgot (as the group deciding what
> the object should look like?:-) don't hesistate to mention it.
> Now, this don't mean we must stop these discussions about eg. memory
> allocation schemes, only that we must more than discuss!
> Also tell me whether you would like to become a group chief.
> There are two already, if they don't change their minds, Dennis and Fare'.
> 
> Now if there is interrest we can split group two into smaller parts.
> You might protest I have put myself up on the (G)UI group, but if you
> don't like it you should have told us so the second week of Januar:-).
> 
> Ok, send me a mail and I'll work out a working list as fast as I can, and if
> you don't respond within a small time I'll put you up in the group that I
> think needs you.
> 
> 
> Ok,ok,ok here from you?
> 
> Arff
> 
> PS. Now DM has given you rules. Obey these and your work will be fruitful,
> remeber we are powerful as long there are unity and we obey the rules.
> sig.'s in for 1000 miles service
>         --Andreas Arff          andreasa@dhhalden.no--
> 
> 


From uunet.UU.NET!davgar!davgar.arlington.va.us!david Sat Mar 27 00:23:35 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10739; Sat, 27 Mar 93 00:23:34 +0100
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Sat, 27 Mar 93 00:23:34 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19308; Fri, 26 Mar 93 15:16:13 -0800
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA09160; Fri, 26 Mar 93 18:15:43 -0500
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 181241.13816; Fri, 26 Mar 1993 18:12:41 EST
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 26 Mar 1993 18:06:36 EST
Date:      Fri, 26 Mar 1993 18:06:32 EST
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bb38c7d.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: ORG, GEN arf1 [djg9]
Status: OR

On 26 Mar 93 09:40:37 +0100, "Andreas Arff" <ANDREASA@dhhalden.no> wrote:
> Howdy all elgers
> 
> I have some things to say about the organization. It stinks.
> Yes, this is another of those "nowwemustputourselftogether" mails.
> 
> First:
> Let's divide into smaller groups.

Much as I would like to divide into smaller groups, I don't think we 
can do this viably until we have designed the Kernel.  Without 
knowledge of the Kernel, how can we go elsewhere?

> Second:
> Let's get something done.

I too would like to see something done.

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Sat Mar 27 03:42:05 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12093; Sat, 27 Mar 93 03:42:04 +0100
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Sat, 27 Mar 93 03:42:04 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA01449; Fri, 26 Mar 93 18:34:41 -0800
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA29090; Fri, 26 Mar 93 21:34:35 -0500
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 213302.3220; Fri, 26 Mar 1993 21:33:02 EST
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 26 Mar 1993 21:28:41 EST
Date:      Fri, 26 Mar 1993 21:28:36 EST
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bb3bbda.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: On method numbers [djg10]
Status: OR

On Fri, 26 Mar 93 16:48:17 EST, "Michael David WINIKOFF"
<winikoff@mulga.cs.mu.OZ.AU> wrote:
> I'm mailing this to you rather then the mailing list 'cause all I want to say
> is that I agree with what you've said.

He says he agrees, but I'm not sure Michael even understood, so I will
try to explain further.

> > OIDs have already been described as unique system-wide.  I am arguing
> > that method numbers should also be SYSTEM-WIDE.  This gives us:
> > OBJECTNUMBER, METHODNUMBER.
>
> Agree.
> >
> > This gives us two categories of method numbers.
> >
> > The first is a set of predefined numbers.  These numbers are defined
> > by the gods of moose (us), once set will never (after first public
> > release) be changed, and will be usable by all objects.  Amongst these
> > predefined numbers will be things like
> >         Inquire_Subobjects(?),
> >         write(void *buffer, int length)
> >         read(void *buffer, int length)
> >         DisplayOn(?)
> > Simply, anything very common or basic could wind up here.  In fact,
>
> Yup. Part of our job in providing a good system is defining a lot of
> services and implementing as many of 'em as possible.

A lot of COMMON services.

> NOTE: I think though that we should reserve a range of IDs for future expansion
>
> Another thing that could be done is having a central co-ordinator (ie a person)
> that assigns numbers.
>
> Eg. I'm a programmer out there. I've written an application that introduces
> some new calls which I think should be added to the list.
> I send off mail and get assigned numbers for my use.

NO APPLICATION GETS PREDEFINED NUMBERS.  For an application to use new
numbers, it uses the second category of numbers.  The first category
is very small (I hope <300 at initial release, <1000 ever!), and, as I
said below, is at least partly for efficiency.

In fact, if we implement what I'm proposing correctly, someone wanting
to change things could define a new list of assigned numbers, or even
empty it, and only require relinking of anything he plans to run!  We
don't need (shouldn't need) a central co-ordinator.

As for needing a reserved range, that too is unneeded, because the
second category dynamic allocation doesn't happen until after boot
time.

I would say number 0 is reserved as invalid,
numbers 1 to N are the predefined ones,
numbers N+1 to MAXINT are for dynamic allocation.

> > The second category of method numbers is numbers allocated while the
> > system is running.  My thought is that, when a program is loaded, the
> > list of methods in the header is passed to a kernel routine that
> > manages name to number translation.  Any name that isn't found is
> > added as a new number.  The numbers thus obtained could then be used
> > to modify the loaded image so that, once the program is running, it
>
> I'm not too sure about modifying code ...

This modifying of code I am proposing is of the same sort as load-time
relocation of an execuable.  It is well understood and easy.

> > does know it wasn't a constant.  If a program needs to, for one reason
> > or another, it could invoke kernel routines for name to number or
> > number to name.
> >
> > The truth of the matter is that the first category could be eliminated
> > completely, but, I think that by having it and by putting the right
> > methods into it, we can eliminate at least 95% of the translations.
> > This would be a good thing if just for the sake of efficiency.
> >
> >
> > > In a networking system we will also have MACHINENUMBER.
> > > With these four numbers you can identify everything down to a simple
> > > method.
> > > Machine number will be fixed (for long periods), the task number will be its
> > > launching number and each object will get a sub-number. The method number
> > > and the object number could now be distributed at compile-time. I could
> > > address an object in your machine with this scheme via internet.
> >
> > In a network forwarder, I would prefer that the forwarder handle
> > translation of OIDs and Method numbers from one machine to the other.
> > In this case, the local alias of the object can include the remote
> > machine identification and object identification.
> >
> > You can't address an object on my machine via internet.  I'm not on
> > internet, just usenet.  It will interesting to see you address objects
> > on my machine via MAIL.  :-)  Actually, I want to try it!
> >
> > > Arff
> > David
> Michael Winikoff
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Sat Mar 27 04:16:56 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12525; Sat, 27 Mar 93 04:16:55 +0100
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Sat, 27 Mar 93 04:16:55 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02424; Fri, 26 Mar 93 19:11:12 -0800
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA07451; Fri, 26 Mar 93 22:11:09 -0500
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 221002.12714; Fri, 26 Mar 1993 22:10:02 EST
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 26 Mar 1993 22:06:16 EST
Date:      Fri, 26 Mar 1993 22:06:10 EST
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bb3c4aa.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Are Processes Objects? [djg11]
Status: OR

In the beginning there was the question "Are Objects Processes".

At first, I thought yes.

Now, I'm not sure.

I will admit that process management is done through objects that are 
associated one-to-one with the processes, however I have come to 
belief that they should be seperate.  

I feel that each process should provide drivers for 0 or more classes, 
provide 0 or more public functions, and optionally include a startup 
and shutdown functions.  

The startup function will be invoked when the process is started.  For 
a purely procedural program, this will be the program.  

The shutdown function will be invoked by the system (kernel or some 
manager) when the system believes it is ok to terminate the process 
and thinks it would be good to do so.  The shutdown function will then 
have three choices, say no, say yes, or terminate its process.  Saying 
no will normally be because the process feels it is still needed.  A 
TCP/IP handling process might be like this, as to terminate because 
the system is low on memory would stop all future remote access 
attempts.  Saying yes would mean that the process is willing to 
terminate, and would normally be given only if the request was "are 
you willing to terminate".  Terminating itself would be done if the 
process feels it has nothing more to do at this time and that it can 
be restarted if needed.  Most graphics interface processes would 
probably do this if there are not running graphics applications.

The classes information would define what classes this process can 
respond to methods of, what methods of these classes are handled by 
this processes, and define the base classes of the classes.

The public function table would provide similar information (under the 
constraints of not being object oriented).



Among other things, I am not sure what a process object would do with 
methods to itself besides what I just said, and I don't see any of 
what I already said requiring the process itself to receive messages 
to its management object.

Arguments?  Flames?
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From ANDREASA@sofus.dhhalden.no Sat Mar 27 13:02:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23346; Sat, 27 Mar 93 13:02:53 +0100
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Sat, 27 Mar 93 13:02:53 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14072; Sat, 27 Mar 93 03:58:31 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <27507-0@fenris.dhhalden.no>; Sat, 27 Mar 1993 12:58:20 +0100
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930327125758.448; 27 Mar 93 12:58:08 -0100
Message-Id: <MAILQUEUE-101.930327125750.416@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 27 Mar 93 12:57:50 +0100
Subject: ORG, GEN [arf2]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

More news about the organization.

So far I have received three postive mail and one "negative" mail, that's
4 to 1(half?), which I regard as a decision that we should continue this NOW.
Discussions can continue but we got to get something done!

'Nough moral talk.

There has been some (very) small changes to the cathegorizing(?).

Now the updated lists with people:

Group Name: Group Leader: Participants:
     Sub Group:
MOOSE:      Dennis (I have currently taken his place to get some structure)
                       Participants: All who gets this mail!
-----------------------------------------------------------------
Kernel:      Dennis       Dennis, John Newlin, Peter Mueller(?).
        ROI: Peter M.(?)
-----------------------------------------------------------------
IO devices:   None so far but don't worry

        Keyboards:
        Disks (hard and floppy):
        Com/Parallel(/mice) ports: Dennis (he has already done some of it)
        SCSI-interface: Who where you who showed interrest in this?
        (G)UI: Andreas Arff (JJ?)
------------------------------------------------------------------
Language support: Fare'    Fare' and JJ Lay
------------------------------------------------------------------

Now there are one more thing I want you elgere to notice when you respond
to my last mail, tell me what langauge you want the language group to work
with.
Sorry Fare' and Lay, we are not buying a pig without having a look at it
first:-(.

Dennis have said he'll take command of the kernel group immediately, so listen
up kernelers'.

I miss response from the following: (Don't know the name of you all:-()
Gary D. Duzan
David Garfield
Dr. Hayden
McKeeve
Dan Odom
Michael Winikoff
Francois Rene Rideau
Dspascha (?)
Erik "Fate" ...

Those who have responded positively:
Dennis
John Newlin
JJ Lay
Me (that was hard to guess...)


Current status:
Dennis has done some work (I mean coding) regarding
1) the Kernel
2) Idea testing the kernel with a muckettymuck C++program
3) Written drivers for com and parallel ports (don't know how finished they
    are, or if it is just old stuff)



Now respond!
BTW, if you have lost interrest please notice me! I'm trying to get this
coordinated and it would be a lot more easy if you could respond soon.

Arff

PS. To you who does respond before Wednesday, you get a free watch that
shows the correct time for 86400 different cities all around the world.
To those of you who don't, you'll get mentioned as quislings in the
manual:-)

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From uunet.UU.NET!davgar!davgar.arlington.va.us!david Sat Mar 27 23:35:03 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29837; Sat, 27 Mar 93 23:35:03 +0100
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Sat, 27 Mar 93 23:35:03 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from spool.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25429; Sat, 27 Mar 93 14:32:15 -0800
Received: from davgar.UUCP by spool.UU.NET with UUCP 
	(5.61/UUNET-uucp-primary) id AA20184; Sat, 27 Mar 93 17:32:12 -0500
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Sat, 27 Mar 1993 17:27:45 EST
Date:      Sat, 27 Mar 1993 17:27:40 EST
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bb4d4e3.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   ORG, GEN Re:arf2  [djg12]
Status: OR

On 27 Mar 93 12:57:50 +0100, "Andreas Arff" <ANDREASA@dhhalden.no> wrote:
> More news about the organization.
...
> Current status:
> Dennis has done some work (I mean coding) regarding
> 1) the Kernel
> 2) Idea testing the kernel with a muckettymuck C++program
> 3) Written drivers for com and parallel ports (don't know how finished they
>     are, or if it is just old stuff)
...
> Arff

It really sounds to me like you are saying that now that discussion of
the general design is diminishing that it is time to begin coding.

Please,

        NNN      NNN      OOOOOOOO      !!!
        NNNN     NNN     OOOOOOOOOO     !!!
        NNNNN    NNN    OOO      OOO    !!!
        NNNNNN   NNN    OOO      OOO    !!!
        NNN NNN  NNN    OOO      OOO    !!!
        NNN  NNN NNN    OOO      OOO    !!!
        NNN   NNNNNN    OOO      OOO    !!!
        NNN    NNNNN    OOO      OOO       
        NNN     NNNN     OOOOOOOOOO     !!!
        NNN      NNN      OOOOOOOO      !!!

The design phases are:

        1) requirements
        2) general design
        3) detailed design
        4) coding
        5) testing

Now I will admit, phase 1 is done.  Our requirement is for a "Multi-
tasking Object oriented Operating SystEm" (thus MOOSE).  But we
haven't yet managed to finish the general design, so we should at most  
be doing some preliminary work on the detailed design and coding
experiments that are considered, in the long term, junk; but WE AREN'T
READY TO CODE.

If I seem a bit intense about this, it is because I have seen what
happens to a large project if there is appropriate design before
coding begins.  In this case, I would expect that if we start coding
now, we will in not less than two years have something that can be
compared unfavorably with Windows 3.0, and that isn't good.

I will admit that I, and probably most good programmers, have skipped
both the general and detailed designs on numerous occasions, but that
is for small projects of not more than two people and relatively short
duration.  Lets not make the mistake of thinking it works for large
projects!  IT DOESN'T!  At least not unless you plan to do it over.

======

I would say that what we need to do now is determine:
   1) What the kernel will do and what the rest will do.
   2) How messages will be sent to objects.  (This has been called
      ROI.  PLEASE don't think that means it is seperate from the
      kernel.)
This more or less defines the kernel.

Then we get then detailed design:
   1) What are the classes?  Most of the class hierarchy?
   2) What are the common methods?
   and about 10 times more stuff, most of which probably won't be
      obvious until we get there.... (or even into coding....)

AFTER that we code.

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From rideau@clipper Sun Mar 28 04:49:02 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02848; Sun, 28 Mar 93 04:49:01 +0200
Return-Path: <rideau@clipper>
Received-Date: Sun, 28 Mar 93 04:49:01 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02261; Sat, 27 Mar 93 18:44:39 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from trimaran.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02799; Sun, 28 Mar 93 04:44:29 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303280244.AA02799@clipper.ens.fr>
Subject: Re: ORG,GEN [far22]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Sun, 28 Mar 93 4:44:30 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

In [Arf1] (I'm happy everybody begins numbering his messages), Andreas says:

> First:
> Let's divide into smaller groups.
> Second:
> Let's get something done.

Hey, Andreas, you awoke me from my sleep ! Thanks for that, but ...
Here's my reply to Andreas.

 That's true, discussion don't advance quickly enough, and we must organize.
I've proposed something in my early [far10] message (Monday, March, 1st)
but nobody ever replied (did you read it? I know I should have posted
multiple messages rather than a big boring one).
 My point is: YES, we must each concentrate on a subject, and YES, each
subject should have a manager that keeps track of discussion, what are
pros and cons of each solution to each problem. But NO we can't split:
we haven't agreed on anything precise yet.

 What we know and are sure of is:
- the system will manage objects.
- objects are manipulated through Object IDs, that are valid through the
whole system, but are somehow protected.
- objects are more or less the same as processes; multitasking IS having
multiple objects living at the same time.
- objects are not isolated; they live in society and can create new links
between each other through dictionaries.
- dictionaries are called once then short-circuited.

 All the remaining is still discussed. So how can you talk about I/O !
I'd love we be able to, but unhappily not at the moment.
 Let's organize first and agree on more detailed features, as well as
on the essential point everybody flees (excepted Michael, who knows it,
but tries to reject it): what are objects to be precisely, and what
will the Kernel/base system implement ?


> Discussions can continue but we got to get something done!
They must, and only through them can we advance.

> 'Nough moral talk.




> Now the updated lists with people:

> Group Name: Group Leader: Participants:
>      Sub Group:
> MOOSE:      Dennis (I have currently taken his place to get some structure)
>                        Participants: All who gets this mail!
> -----------------------------------------------------------------
> Kernel:      Dennis       Dennis, John Newlin, Peter Mueller(?).
>         ROI: Peter M.(?)
Add me to the Kernel list: language and Kernel are linked.

> -----------------------------------------------------------------
> IO devices:   None so far but don't worry
> 
>         Keyboards:
>         Disks (hard and floppy):
>         Com/Parallel(/mice) ports: Dennis (he has already done some of it)
>         SCSI-interface: Who where you who showed interrest in this?
>         (G)UI: Andreas Arff (JJ?)
Add me to the GUI list too. GUI is not only IO, 'cause it interfaces the
user himself, not only the machine; interfacing is having a discussion,
even (all the more) in a non ASCII language !

> ------------------------------------------------------------------
> Language support: Fare'    Fare' and JJ Lay
> ------------------------------------------------------------------
Well, you remind me to talk you about languages ... soon !



I agree with groups, but again we can't split for the time being, without
having agreed anything in common to the groups (not even the ROI
implementation principles).


> Now there are one more thing I want you elgere to notice when you respond
> to my last mail, tell me what langauge you want the language group to work
> with.
 A NEW language; it should be OOed, include functional notation, and
constraint programming and/or inter-object relation managing. It should
also be meta-self (i.e. be its own preprocessor), be modular (auto-
expandable), handle genericity, accept polymorphism and inheritance through
implicitness.
 Why not C++ : it inherits low-level features and unsecureness from C; bad
low-level feature: implementation is determined by syntax, not optimization;
type casting is unsafe, so you can't trust compiled code; only special
paging hardware can enable safety.


> Sorry Fare' and Lay, we are not buying a pig without having a look at it
> first:-(.
 You're right; that's why I'm talking about it in next message.



> Dennis have said he'll take command of the kernel group immediately, so listen
> up kernelers'.
I do.

> I miss response from the following: (Don't know the name of you all:-()
> Gary D. Duzan
> David Garfield
> Dr. Hayden
> McKeeve
> Dan Odom
> Michael Winikoff
> Francois Rene Rideau
now that's done for me. (sorry: that wasn't private mail, but I think I had
things to say to everybody).
> Dspascha (?)
> Erik "Fate" ...


> Those who have responded positively:
> Dennis
> John Newlin
> JJ Lay
> Me (that was hard to guess...)


> Current status:
> Dennis has done some work (I mean coding) regarding
> 1) the Kernel
> 2) Idea testing the kernel with a muckettymuck C++program
> 3) Written drivers for com and parallel ports (don't know how finished they
>     are, or if it is just old stuff)
What kernel are you going to test ?


> Now respond!
> BTW, if you have lost interrest please notice me! I'm trying to get this
> coordinated and it would be a lot more easy if you could respond soon.

> Arff
> 
> PS. To you who does respond before Wednesday, you get a free watch that
> shows the correct time for 86400 different cities all around the world.
> To those of you who don't, you'll get mentioned as quislings in the
> manual:-)
The greatest threat was not this one; it was that of seeing MOOSE end up into
nothing if nothing is done soon (...or if something stupid is done).

   ,
Fare


From ANDREASA@sofus.dhhalden.no Sun Mar 28 13:40:38 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12387; Sun, 28 Mar 93 13:40:37 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Sun, 28 Mar 93 13:40:37 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA10506; Sun, 28 Mar 93 03:37:21 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <15323-0@fenris.dhhalden.no>; Sun, 28 Mar 1993 13:37:16 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930328123651.352; 28 Mar 93 12:37:02 -0100
Message-Id: <MAILQUEUE-101.930328123648.320@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 28 Mar 93 12:36:48 +0100
Subject: Re: ORG, GEN [arf3]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

"> " is David Garfield and me am "> > "

> > Current status:
> > Dennis has done some work (I mean coding) regarding
> > 1) the Kernel
> > 2) Idea testing the kernel with a muckettymuck C++program
> > 3) Written drivers for com and parallel ports (don't know how finished they
> >     are, or if it is just old stuff)
> ...
> > Arff
>
> It really sounds to me like you are saying that now that discussion of
> the general design is diminishing that it is time to begin coding.
>
> Please,
>
>         NNN      NNN      OOOOOOOO      !!!
>         NNNN     NNN     OOOOOOOOOO     !!!
>         NNNNN    NNN    OOO      OOO    !!!
>         NNNNNN   NNN    OOO      OOO    !!!
>         NNN NNN  NNN    OOO      OOO    !!!
>         NNN  NNN NNN    OOO      OOO    !!!
>         NNN   NNNNNN    OOO      OOO    !!!
>         NNN    NNNNN    OOO      OOO
>         NNN     NNNN     OOOOOOOOOO     !!!
>         NNN      NNN      OOOOOOOO      !!!

My yes is much more smaller than yours but I belive I have the support from
80% percent of moose, if not more, so I don't feel I have to shout.

> The design phases are:
>
>         1) requirements
>         2) general design
>         3) detailed design
>         4) coding
>         5) testing
>
> Now I will admit, phase 1 is done.  Our requirement is for a "Multi-
> tasking Object oriented Operating SystEm" (thus MOOSE).  But we
> haven't yet managed to finish the general design, so we should at most
> be doing some preliminary work on the detailed design and coding
> experiments that are considered, in the long term, junk; but WE AREN'T
> READY TO CODE.

Ok phase one is done. Good. Now let's turn the (moose) steak. General
Design is the next phase, and after that, detailed design. Ok, so far so good.
Dennis is working very hard to put down all his thoughts on paper. It's
going forward I can say. I hope we can see what he has done at the end of this
week. That would be the "general design" wouldn't it? He has taken into account
what has been discussed here lately, so no objection please. There can't be
two captains on a ship, remember.
It is more appropirate that Dennis takes the command now than ever, when it
comes to the general design issue.

Now we have the detailed design. This should be carved out by each sub-group.
The subgroup-coordinators will put the design into a document and from there
to the group-coordinators and from there to Dennis. (Of course he has given us
some orders for what each thing should contain.) If he likes what he sees we
continue working with it til we feel we are finished.

What we needs from Dennis to get things work together is specs. regarding
IPC and events. When he has given us the general design we will continue from
there to make a specification on how things should work together.
There is nothing that stops us start coding now. Take my GUI group as an
example. I'll have to rewrite parts of BIOS (as some others will have to).
But I'm not going to put my first bios code into Moose, I'll have to do some
testing first. These things could be done at the same time as the detailed
spec's. is written.

> If I seem a bit intense about this, it is because I have seen what
> happens to a large project if there is appropriate design before
> coding begins.  In this case, I would expect that if we start coding
> now, we will in not less than two years have something that can be
> compared unfavorably with Windows 3.0, and that isn't good.

Havn't we all? No it won't become a windows 3.0, do you know why. We wont
have ms-dos, we won't have a virtual 8086 running inside our OS. We will have
mem. protection etc. We won't have a world of programmers hateing us because
of beeing ruthless against others!

> I will admit that I, and probably most good programmers, have skipped
> both the general and detailed designs on numerous occasions, but that
> is for small projects of not more than two people and relatively short
> duration.  Lets not make the mistake of thinking it works for large
> projects!  IT DOESN'T!  At least not unless you plan to do it over.
>
This is ment to be a small project. Flexibel and modular, so we can add things
when we need!
>
> I would say that what we need to do now is determine:
>    1) What the kernel will do and what the rest will do.
Dennis is working on it.
>    2) How messages will be sent to objects.  (This has been called
>       ROI.  PLEASE don't think that means it is seperate from the
>       kernel.)
> This more or less defines the kernel.
Let Peter and Dennis talk together and we'll have something there too.

> Then we get then detailed design:
>    1) What are the classes?  Most of the class hierarchy?
The classes will be every sub-group, inheriting from every main group,
inheriting from moose. Don't flame me for this. But it will end up something
like this anyway.

>    2) What are the common methods?
The common methods will be methods for looking into dictionaries, rasing
events etc. Don't flame me for this either!

>    and about 10 times more stuff, most of which probably won't be
>       obvious until we get there.... (or even into coding....)
>
> AFTER that we code.

Still most of us don't read a hardware book and then code a perfectly running
program, mostly because books are bad?:-)

Where shall I put you David? Main-group trashcanemptier? Sorry for beeing so
hard but we need getting organized. There isn't time for chitchating!


I assume I'll get answers from all of you before the end of mars!

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From ANDREASA@sofus.dhhalden.no Sun Mar 28 13:51:58 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12443; Sun, 28 Mar 93 13:51:57 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Sun, 28 Mar 93 13:51:57 +0200
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <15351-0@fenris.dhhalden.no>; Sun, 28 Mar 1993 13:51:45 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930328125119.288; 28 Mar 93 12:51:31 -0100
Message-Id: <MAILQUEUE-101.930328125118.256@sofus.dhhalden.no>
To: rideau@clipper (Francois-Rene Rideau)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 28 Mar 93 12:51:18 +0100
Subject: Re: ORG,GEN [arf4]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR


> In [Arf1] (I'm happy everybody begins numbering his messages), Andreas says:
>
Good, but have you noticed I number my messages from 0 when I start a new
thread. Is this wrong according to your scheme?

> > First:
> > Let's divide into smaller groups.
> > Second:
> > Let's get something done.
>
> Hey, Andreas, you awoke me from my sleep ! Thanks for that, but ...
> Here's my reply to Andreas.
>
>  That's true, discussion don't advance quickly enough, and we must organize.
> I've proposed something in my early [far10] message (Monday, March, 1st)
> but nobody ever replied (did you read it? I know I should have posted
> multiple messages rather than a big boring one).

I have read all messages from everyone!

>  My point is: YES, we must each concentrate on a subject, and YES, each
> subject should have a manager that keeps track of discussion, what are
> pros and cons of each solution to each problem. But NO we can't split:
> we haven't agreed on anything precise yet.

We are not going to "split" exactly in that meaning. We are just building
workgroups to get things a little bit more hierarchical, or maybe I should
say inherited:-).

>  What we know and are sure of is:
[Stuff deleted]

We are all(?) eagerly awaiting Dennis new spec's.

>  All the remaining is still discussed. So how can you talk about I/O !
> I'd love we be able to, but unhappily not at the moment.
>  Let's organize first and agree on more detailed features, as well as
> on the essential point everybody flees (excepted Michael, who knows it,
> but tries to reject it): what are objects to be precisely, and what
> will the Kernel/base system implement ?

I belive Dennis will make this clear in the next spec.

> > Discussions can continue but we got to get something done!
> They must, and only through them can we advance.

They will continue, but not the way we are doing it now.
>From when we receive next spec. we will start discuss implementation problems.
No objections? Good!

> I agree with groups, but again we can't split for the time being, without
> having agreed anything in common to the groups (not even the ROI
> implementation principles).

You are all just like kids on christmas day. Wait for Santa Dennis.

> > Now there are one more thing I want you elgere to notice when you respond
> > to my last mail, tell me what langauge you want the language group to work
> > with.
>  A NEW language; it should be OOed, include functional notation, and
> constraint programming and/or inter-object relation managing. It should
> also be meta-self (i.e. be its own preprocessor), be modular (auto-
> expandable), handle genericity, accept polymorphism and inheritance through
> implicitness.
>  Why not C++ : it inherits low-level features and unsecureness from C; bad
> low-level feature: implementation is determined by syntax, not optimization;
> type casting is unsafe, so you can't trust compiled code; only special
> paging hardware can enable safety.

Why don't you implement ADA then?

> > Sorry Fare' and Lay, we are not buying a pig without having a look at it
> > first:-(.
>  You're right; that's why I'm talking about it in next message.

Do so.

I miss response from the following: (Don't know the name of you all:-()
 Gary D. Duzan
 David Garfield
 Dr. Hayden
 McKeeve
 Dan Odom
 Michael Winikoff
 Dspascha (?)
 Erik "Fate" ...


Those who have responded positively:
 Dennis
 John Newlin
 JJ Lay
 Me (that was hard to guess...)
 Francois-Rene' Rideau


> > Current status:
[No change]

> What kernel are you going to test ?
Ask him, not me.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From cis.udel.edu!udel.edu!duzan Sun Mar 28 18:42:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15437; Sun, 28 Mar 93 18:42:53 +0200
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Sun, 28 Mar 93 18:42:53 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12915; Sun, 28 Mar 93 08:39:50 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa02493;
          28 Mar 93 11:35 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa22154;
          28 Mar 93 16:34 GMT
Received: from sol.cis.udel.edu by daffy.cis.udel.edu id aa12936;
          28 Mar 93 16:32 GMT
To: moose-programmers@sfu.ca
Subject: Re: ORG, GEN [arf3] 
Date: Sun, 28 Mar 93 11:32:03 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303281632.aa12936@daffy.cis.udel.edu>
Status: OR

In Message <MAILQUEUE-101.930328123648.320@sofus.dhhalden.no> ,
   Andreas Arff <ANDREASA@dhhalden.no> wrote:

=>> It really sounds to me like you are saying that now that discussion of
=>> the general design is diminishing that it is time to begin coding.
=>>
=>> Please,
=>>
=>> [ large NO! removed for brevity ]
=>
=>My yes is much more smaller than yours but I belive I have the support from
=>80% percent of moose, if not more, so I don't feel I have to shout.

   Well, I'll have to agree on David with this one. I've heard
precious little agreement on some basic issues, and I believe it
would be foolish to proceed without some clear idea of where we
are going.

=>Ok phase one is done. Good. Now let's turn the (moose) steak. General
=>Design is the next phase, and after that, detailed design. Ok, so far so good
.
=>Dennis is working very hard to put down all his thoughts on paper. It's
=>going forward I can say. I hope we can see what he has done at the end of thi
s
=>week. That would be the "general design" wouldn't it? He has taken into accou
nt
=>what has been discussed here lately, so no objection please. There can't be
=>two captains on a ship, remember.
=>It is more appropirate that Dennis takes the command now than ever, when it
=>comes to the general design issue.

   I understood that this was going to be a group design, or were
we all recruited as free programming labor? At this stage, I think
a design imposed from above may meet resistance, and may lose group
support. Of course, if we can agree on the revised design as posted
by Dennis, all the better. It is at least a good step in the design
process.

=>> If I seem a bit intense about this, it is because I have seen what
=>> happens to a large project if there is appropriate design before
=>> coding begins.  In this case, I would expect that if we start coding
=>> now, we will in not less than two years have something that can be
=>> compared unfavorably with Windows 3.0, and that isn't good.
=>
=>Havn't we all? No it won't become a windows 3.0, do you know why. We wont
=>have ms-dos, we won't have a virtual 8086 running inside our OS. We will have
=>mem. protection etc. We won't have a world of programmers hateing us because
=>of beeing ruthless against others!

   That doesn't mean we won't end up with a useless, bloated, ugly
mess that takes three times as long to complete as it should. It
doesn't mean we will, either, but we shouldn't proceed until we have
a solid, agreeable, workable design.

=>> I will admit that I, and probably most good programmers, have skipped
=>> both the general and detailed designs on numerous occasions, but that
=>> is for small projects of not more than two people and relatively short
=>> duration.  Lets not make the mistake of thinking it works for large
=>> projects!  IT DOESN'T!  At least not unless you plan to do it over.
=>>
=>This is ment to be a small project. Flexibel and modular, so we can add thing
s
=>when we need!

   Resulting in an ad hoc, ugly system. A microkernel by itself is
completely, utterly useless. The real system is what goes on top of
it, and until we decide how to structure the system on top, we won't
have a good idea of how to support it from below.

=>Where shall I put you David? Main-group trashcanemptier? Sorry for beeing so
=>hard but we need getting organized. There isn't time for chitchating!

   This is uncalled for. If this group can't tolerate differences
of opinion, then we are doomed from the start. And what is your
rush? Patience is a virtue, or so I have been told, and we aren't
working against any deadlines. A complete system is a large thing,
and I believe that we are well justified in wanting to take the
time to design it properly.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From cis.udel.edu!udel.edu!duzan Sun Mar 28 18:59:00 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15556; Sun, 28 Mar 93 18:58:59 +0200
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Sun, 28 Mar 93 18:58:59 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA13318; Sun, 28 Mar 93 08:55:43 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa02817;
          28 Mar 93 11:50 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa22202;
          28 Mar 93 16:49 GMT
Received: from sol.cis.udel.edu by daffy.cis.udel.edu id aa13036;
          28 Mar 93 16:48 GMT
To: moose-programmers@sfu.ca
Subject: Re: ORG,GEN [far22] 
Date: Sun, 28 Mar 93 11:48:05 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9303281648.aa13036@daffy.cis.udel.edu>
Status: OR

In Message <9303280244.AA02799@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=>In [Arf1] (I'm happy everybody begins numbering his messages), Andreas says:
=>
=>> Now there are one more thing I want you elgere to notice when you respond
=>> to my last mail, tell me what langauge you want the language group to work
=>> with.
=> A NEW language; it should be OOed, include functional notation, and
=>constraint programming and/or inter-object relation managing. It should
=>also be meta-self (i.e. be its own preprocessor), be modular (auto-
=>expandable), handle genericity, accept polymorphism and inheritance through
=>implicitness.
=> Why not C++ : it inherits low-level features and unsecureness from C; bad
=>low-level feature: implementation is determined by syntax, not optimization;
=>type casting is unsafe, so you can't trust compiled code; only special
=>paging hardware can enable safety.

   Being the idealist that I am, I'd agree that this would be the
ideal situation. Unfortunately, the reality is that it would be
beyond the scope of this project. We would have to get into language
design, compiler design, and programmer training to pull it off. If,
on the other hand, you can find an existing OO language with freely
available compilers for a variety of platforms that meets your
criteria, it may well be worth the time and effort to learn it and
use it. Otherwise, I'm afraid we are stuck with C++ (or G++) and all
its faults.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From uunet.UU.NET!davgar!davgar.arlington.va.us!david Mon Mar 29 05:38:57 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA26398; Mon, 29 Mar 93 05:38:56 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Mon, 29 Mar 93 05:38:56 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA29548; Sun, 28 Mar 93 19:36:10 -0800
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA00380; Sun, 28 Mar 93 22:36:08 -0500
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 223526.4066; Sun, 28 Mar 1993 22:35:26 EST
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Sun, 28 Mar 1993 22:30:27 EST
Date:      Sun, 28 Mar 1993 22:30:24 EST
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bb66d55.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: ORG, GEN Re:arg2  [djg12]  [djg13]
Status: OR

"> " is Michael David WINIKOFF
"> > " is me

[...]
> > be doing some preliminary work on the detailed design and coding
> > experiments that are considered, in the long term, junk; but WE AREN'T
[...]
> I would like however to point out exploratory programming -- this is where you
> can't decide exactloy what you want so you build prototypes of the sywtem which
> wil later be rewritten.
[...]
> Yes. Coding the system now is WRONG.
> Knocking up bits of code to test ideas is good.
[...]
> Michael Winikoff

Like I said, "coding experiments that are considered, in the long
term, junk".  "Junk" doesn't mean the experiment doesn't yield
information.  Thus do exploratory programming and test code, just
don't get attached to it.  And remember to get information from it.

Myself, I've decided to start writing test keyboard (& 8042 control)
code.  Anybody have odd keyboards? (non-English? >101/102 key?)
Anybody think we need to support pre-AT keyboards?

David Garfield
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From ANDREASA@sofus.dhhalden.no Mon Mar 29 13:19:59 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02471; Mon, 29 Mar 93 13:19:58 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 29 Mar 93 13:19:58 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07635; Mon, 29 Mar 93 01:14:18 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <02197-0@fenris.dhhalden.no>; Mon, 29 Mar 1993 11:14:11 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930329101349.384; 29 Mar 93 10:14:11 -0100
Message-Id: <MAILQUEUE-101.930329101341.320@sofus.dhhalden.no>
To: moose-programmers@sfu.ca (Moose Project)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 29 Mar 93 10:13:41 +0100
Subject: Re: To ANDREAS ...
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> [BTW -- this is being posted rather then mailed directory to ANDREAS since I
> seem to have difficulties reaching him directly ...]

Just a test whether I can reach you.

> Sure, I'd like to keep contributing to the kernel/nucleus.

> I'd be interested in keeping up to date with language related issues
> (If only to ensure that the needs of non OO languages aren't neglected :-)

I'd put you up on kernel and language design Michael.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From winikoff@cs.mu.OZ.AU Mon Mar 29 02:27:03 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19398; Mon, 29 Mar 93 02:27:02 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 29 Mar 93 02:27:02 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24357; Sun, 28 Mar 93 16:22:27 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA00221
	Mon, 29 Mar 1993 10:22:11 +1000 (from winikoff)
Message-Id: <9303290022.221@mulga.cs.mu.OZ.AU>
Subject: Re: ORG, GEN Re:arf2  [djg12]
To: moose-programmers@sfu.ca (Moose Project)
Date: Mon, 29 Mar 93 10:22:09 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <2bb4d4e3.davgar@davgar.arlington.va.us>; from "David Garfield" at Mar 27, 93 5:27 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> The design phases are:
> 
>         1) requirements
>         2) general design
>         3) detailed design
>         4) coding
>         5) testing
> 
> Now I will admit, phase 1 is done.  Our requirement is for a "Multi-
> tasking Object oriented Operating SystEm" (thus MOOSE).  But we
> haven't yet managed to finish the general design, so we should at most  
> be doing some preliminary work on the detailed design and coding
> experiments that are considered, in the long term, junk; but WE AREN'T
> READY TO CODE.
> 
> If I seem a bit intense about this, it is because I have seen what
> happens to a large project if there is appropriate design before
> coding begins.  In this case, I would expect that if we start coding
> now, we will in not less than two years have something that can be
> compared unfavorably with Windows 3.0, and that isn't good.

The only large (relatively) scale project I was involved with spent ages on 
the design -- the coding want very smoothly (especially considering it involved
shared memory, semaphores, spin locks etc.)

I would like however to point out exploratory programming -- this is where you
can't decide exactloy what you want so you build prototypes of the sywtem which
wil later be rewritten.

> 
> ======
> 
> I would say that what we need to do now is determine:
>    1) What the kernel will do and what the rest will do.
>    2) How messages will be sent to objects.  (This has been called
>       ROI.  PLEASE don't think that means it is seperate from the
>       kernel.)
> This more or less defines the kernel.
> 
> Then we get then detailed design:
>    1) What are the classes?  Most of the class hierarchy?
>    2) What are the common methods?
>    and about 10 times more stuff, most of which probably won't be
>       obvious until we get there.... (or even into coding....)
> 
> AFTER that we code.

Yes. Coding the system now is WRONG.
Knocking up bits of code to test ideas is good.

> 
> -- 
> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Mon Mar 29 09:29:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28852; Mon, 29 Mar 93 09:29:28 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 29 Mar 93 09:29:28 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05389; Sun, 28 Mar 93 23:25:54 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA17129
	Mon, 29 Mar 1993 17:24:31 +1000 (from winikoff)
Message-Id: <9303290724.17129@mulga.cs.mu.OZ.AU>
Subject: To ANDREAS ...
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Mon, 29 Mar 93 17:24:29 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
Cc: moose-programmers@sfu.ca (Moose Project)
In-Reply-To: <MAILQUEUE-101.930329074255.448@sofus.dhhalden.no>; from "Andreas Arff" at Mar 29, 93 7:42 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

[BTW -- this is being posted rather then mailed directory to ANDREAS since I 
seem to have difficulties reaching him directly ...]

> 
> > > AFTER that we code.
> >
> > Yes. Coding the system now is WRONG.
> > Knocking up bits of code to test ideas is good.

On the proviso that you realise that the code will be thrown away ... :-)

> 
> Good you agree! Now, please annonce what group you'd be interested to join.

Sure, I'd like to keep contributing to the kernel/nucleus.

I'd be interested in keeping up to date with language related issues 
(If only to ensure that the needs of non OO languages aren't neglected :-)

> 
> > Michael Winikoff
> 
> Arff
> 
> sig.'s in for 1000 miles service
>         --Andreas Arff          andreasa@dhhalden.no--
> 
> 

Michael -- hoping he'll be able to find time to keep up with moose ...


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From dmarer@td2cad.intel.com Mon Mar 29 19:36:51 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10272; Mon, 29 Mar 93 19:36:50 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Mon, 29 Mar 93 19:36:50 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20850; Mon, 29 Mar 93 09:30:27 -0800
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Mon, 29 Mar 93 09:30:24 -0800
Received: by td2cad (5.57/10.0i); Mon, 29 Mar 93 09:34:08 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01828; Mon, 29 Mar 93 09:41:46 PDT
Date: Mon, 29 Mar 93 09:41:46 PDT
Message-Id: <9303291741.AA01828@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re:  Are Processes Objects? [djg11]
Status: OR

Howdy Moosers!

A few comments on David's mail...

> I feel that each process should provide drivers for 0 or more classes, 
> provide 0 or more public functions, and optionally include a startup 
> and shutdown functions.  

Good - a constructor and destructor possibly, plus some "main" function for
the process to begin execution.  Then, if you wrote a C program, the main()
function would map directly to this function...can anyone think of a better
name than "main" though?

> Among other things, I am not sure what a process object would do with 
> methods to itself besides what I just said, and I don't see any of 
> what I already said requiring the process itself to receive messages 
> to its management object.

In some cases, it would be nice for a process to let other processes access
it.  I've been thinking device drivers almost need to be processes, and if
they were objects their methods would be their interface.  Beyond this, only
a few real applications would need a process interface, like database servers
and so on.  In most cases, a process would need its "main" function and not
much else in its external interface though.

		Dennis

From dmarer@td2cad.intel.com Mon Mar 29 20:01:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10571; Mon, 29 Mar 93 20:01:26 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Mon, 29 Mar 93 20:01:26 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22680; Mon, 29 Mar 93 09:52:29 -0800
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Mon, 29 Mar 93 09:52:25 -0800
Received: by td2cad (5.57/10.0i); Mon, 29 Mar 93 09:56:10 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01840; Mon, 29 Mar 93 10:03:48 PDT
Date: Mon, 29 Mar 93 10:03:48 PDT
Message-Id: <9303291803.AA01840@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Re:  ORG, GEN Re:arf2  [djg12]
Status: OR

> It really sounds to me like you are saying that now that discussion of
> the general design is diminishing that it is time to begin coding.
> 
> Please,
> 
>         NNN      NNN      OOOOOOOO      !!!
>         NNNN     NNN     OOOOOOOOOO     !!!
>         NNNNN    NNN    OOO      OOO    !!!
>         NNNNNN   NNN    OOO      OOO    !!!
>         NNN NNN  NNN    OOO      OOO    !!!
>         NNN  NNN NNN    OOO      OOO    !!!
>         NNN   NNNNNN    OOO      OOO    !!!
>         NNN    NNNNN    OOO      OOO       
>         NNN     NNNN     OOOOOOOOOO     !!!
>         NNN      NNN      OOOOOOOO      !!!

No is correct!  The design has only just begun.

I think what Andreas is suggesting is to streamline things a bit!  As much as
I'd like to jump in and start actually writing the kernel or the OS, I don't
have the slightest idea where to start yet.

> The design phases are:
> 
>         1) requirements
>         2) general design
>         3) detailed design
>         4) coding
>         5) testing
> 
> Now I will admit, phase 1 is done.  Our requirement is for a "Multi-
> tasking Object oriented Operating SystEm" (thus MOOSE).  But we
> haven't yet managed to finish the general design, so we should at most  
> be doing some preliminary work on the detailed design and coding
> experiments that are considered, in the long term, junk; but WE AREN'T
> READY TO CODE.

I agree.  Phase 2 needs a lot more work still.

> I will admit that I, and probably most good programmers, have skipped
> both the general and detailed designs on numerous occasions, but that
> is for small projects of not more than two people and relatively short
> duration.  Lets not make the mistake of thinking it works for large
> projects!  IT DOESN'T!  At least not unless you plan to do it over.

I know that from experience too!

Let me let you know what I've been working on:

I've been developing little code 'snippets', or just little bits of code which
do useful things.  For example, I've written a program which initializes
protected mode on the 386.  Also, I've written some basic serial port device
drivers.  Also, boot from the hard drive and modifying the boot sectors.  In
the end, experience from doing this will go directly to this project - none of
the code will probably be used verbatim, but it will be used as a reference.

About the "mucketymockup" (I like that!) of the kernel in C++.  As I've been
writing the specs for the kernel, I've been testing what I've written.  I've
found from experience that lots of things look good on paper, but once built
don't fly and need to be redesigned.  To combat this, I've developed a *very*
simple "kernel" from which we can build and test ideas as they come up to see
if they are at all useful.  It does not use protected mode or virtual memory,
but it incorporates some of the ideas we've been talking about, including
*multitasking*!!!  This is only an idea testbed.

This by no means is the finished product - it's a device I've been using to 
test out what we've been discussing.  So far I've found 3 or 4 errors in logic
when defining the kernel on paper, and gone back and fixed them.  I feel its
better to find these *now* before we actually try to implement the real thing.

I agree with David - we're still only on Phase 2 (general details).  If we try
to start coding now, we'll be cutting our own throats.

> ======
> 
> I would say that what we need to do now is determine:
>    1) What the kernel will do and what the rest will do.
>    2) How messages will be sent to objects.  (This has been called
>       ROI.  PLEASE don't think that means it is seperate from the
>       kernel.)
> This more or less defines the kernel.
> 
> Then we get then detailed design:
>    1) What are the classes?  Most of the class hierarchy?
>    2) What are the common methods?
>    and about 10 times more stuff, most of which probably won't be
>       obvious until we get there.... (or even into coding....)

I've defined a lot of this in the next revision of the specs.  Actually, so far
I have only been working on the kernel specs, leaving the rest of the system
out of discussion for the moment.  I'm sorry these specs are taking so long,
but its been kindof a stressful time for me, both in work (real job) and my
personal life.  My time is more flexible from now on, and I'll be able to
commit a lot more effort towards our goals.

> AFTER that we code.

But I strongly recommend getting familiar with some of the hardware we'll be
working with.  Everything takes a couple of tries (IMHO) to get right, so if
you sat down and started writing a SCSI driver with no previous experience,
it probably wouldn't work very well.

I do have an excellent recommendation in this area - "Linux" already has many
common PC devices implemented, and would be a good reference for any disk drive
or even SCSI drive details.  Last I heard it supported many common devices -
there is no reason to ignore this source of information.  Just don't copy code
or we'll be bound by the Gnu copyleft.

I'm putting together ideas on how to further organize the kernel development.
We'll get together later this week to speed things up and get those ideas out
there and on paper.  Keep in touch!

			Dennis

From csjjlay@knuth.mtsu.edu Mon Mar 29 22:06:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12679; Mon, 29 Mar 93 22:06:33 +0200
Return-Path: <csjjlay@knuth.mtsu.edu>
Received-Date: Mon, 29 Mar 93 22:06:33 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from watson.mtsu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA01764; Mon, 29 Mar 93 11:32:15 -0800
Received: by knuth.mtsu.edu (Smail3.1.28.1 #8)
	id m0ndPWv-0005ASC; Mon, 29 Mar 93 13:29 CST
Message-Id: <m0ndPWv-0005ASC@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: OO Language
To: moose-programmers@sfu.ca
Date: Mon, 29 Mar 1993 13:29:56 -0600 (CST)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1370      
Status: OR

Having been silent for quite a while do to the somewhat disorganized
nature of the project, I think it might be of some interest for those
who would like to be involved with the Language development, take a 
look at an OO language called Sather.  It has a lot of interesting
features that may be pertinent to the MOOSE cause.

There is talk of actually beginning coding.  How can that be?  We aren't
sure what we want!  What if we were to adopt an actual software
development life-cycle?  Using Object-Oriented Analysis and design, we
could develop a series of prototypes to get a "feel" for the system.
Once that was finished, move on to the tried and true Waterfall
methodology.  Does anyone feel like me?  Flame on.  I have my asbestos
underwear on!  8-)
							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"Marriage is a noble institution...  If you want to be institutionalized
the rest of your life!" -Dr. Paul Hutcheson, MTSU Computer Science Dept

From UKCC.UKY.EDU!WKUVX1.BITNET!haydedr Tue Mar 30 02:50:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15978; Tue, 30 Mar 93 02:50:24 +0200
Return-Path: <UKCC.UKY.EDU!WKUVX1.BITNET!haydedr>
Received-Date: Tue, 30 Mar 93 02:50:24 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ukcc.uky.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28905; Mon, 29 Mar 93 16:41:33 -0800
Received: from UKCC.UKY.EDU by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 3768; Mon, 29 Mar 93 19:40:38 EST
Received: from WKUVX1.BITNET (NJE origin MXMAILER@WKUVX1) by UKCC.UKY.EDU
 (LMail V1.1d/1.7f) with BSMTP id 7745; Mon, 29 Mar 1993 19:40:38 -0500
Received: by WKUVX1.BITNET (MX V3.3 VAX) id 12346; Mon, 29 Mar 1993 18:40:07 CST
Date: Mon, 29 Mar 1993 18:40:04 CST
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: moose-programmers@sfu.ca
Message-Id: <0096A3EA.077E7080.12346@WKUVX1.BITNET>
Subject: Re:  ORG, GEN Re:arf2  [djg12]
Status: OR

Dennis Marer <dmarer@td2cad.intel.com> writes:
>
>> It really sounds to me like you are saying that now that discussion of
>> the general design is diminishing that it is time to begin coding.

[Large NO deleted]

>
>No is correct!  The design has only just begun.
>

I agree; however, I would like to see some of the important issues
that have been already discussed decided on and put on paper.

>I think what Andreas is suggesting is to streamline things a bit!  As much as
>I'd like to jump in and start actually writing the kernel or the OS, I don't
>have the slightest idea where to start yet.
>
>> The design phases are:
>>
>>         1) requirements
>>         2) general design
>>         3) detailed design
>>         4) coding
>>         5) testing
>>
>> Now I will admit, phase 1 is done.  Our requirement is for a "Multi-
>> tasking Object oriented Operating SystEm" (thus MOOSE).  But we
>> haven't yet managed to finish the general design, so we should at most
>> be doing some preliminary work on the detailed design and coding
>> experiments that are considered, in the long term, junk; but WE AREN'T
>> READY TO CODE.
>
>I agree.  Phase 2 needs a lot more work still.

I think we're on track so far as well.

<snip...>

>Let me let you know what I've been working on:
>
>I've been developing little code 'snippets', or just little bits of code which
>do useful things.  For example, I've written a program which initializes
>protected mode on the 386.  Also, I've written some basic serial port device
>drivers.  Also, boot from the hard drive and modifying the boot sectors.  In
>the end, experience from doing this will go directly to this project - none of
>the code will probably be used verbatim, but it will be used as a reference.

I have quite a bit of code that does about the same things (it's all
asm though).  E.G. Put 386 into protected mode, and I can enable paging as
well, although my page fault handler is quite weak right now :-)  If
it makes any sense to say it now, I'd very much like to work with the
areas of Moose that deal with hardware specific areas (in all
platforms we develop for).

I also have some ideas about scheduling, dispatching, and other areas
of the kernel that I've put on paper.  I've posted some of them early
on, but I'll repost them when we come to discuss these areas.

>
>About the "mucketymockup" (I like that!) of the kernel in C++.  As I've been
>writing the specs for the kernel, I've been testing what I've written.  I've
>found from experience that lots of things look good on paper, but once built
>don't fly and need to be redesigned.  To combat this, I've developed a *very*
>simple "kernel" from which we can build and test ideas as they come up to see
>if they are at all useful.  It does not use protected mode or virtual memory,
>but it incorporates some of the ideas we've been talking about, including
>*multitasking*!!!  This is only an idea testbed.
>
>This by no means is the finished product - it's a device I've been using to
>test out what we've been discussing.  So far I've found 3 or 4 errors in logic
>when defining the kernel on paper, and gone back and fixed them.  I feel its
>better to find these *now* before we actually try to implement the real thing.

I'd like to see this sometime :-)

>
>I agree with David - we're still only on Phase 2 (general details).  If we try
>to start coding now, we'll be cutting our own throats.

Ouch!  I like my throat uncut, so lets get some more concrete design
done.

<snip...>

>
>I'm putting together ideas on how to further organize the kernel development.
>We'll get together later this week to speed things up and get those ideas out
>there and on paper.  Keep in touch!
>
>                       Dennis

Sounds great!

Later,
Ross Hayden

From rideau@clipper Wed Mar 31 04:34:51 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15004; Wed, 31 Mar 93 04:34:24 +0200
Return-Path: <rideau@clipper>
Received-Date: Wed, 31 Mar 93 04:34:24 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05151; Tue, 30 Mar 93 18:27:37 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13368; Wed, 31 Mar 93 04:26:59 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303310226.AA13368@clipper.ens.fr>
Subject: KER,GEN+ [far24]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Wed, 31 Mar 93 4:26:58 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

I thought I could explain directly my language ideas, but I see I must
explain first my global vision of the system. The language's features arise
naturally from how the whole system is conceived: that's the coordination
language, that reflects exactly how the system is conceived, and what it
offers to you.
 I quote Dennis (mar 17 message) (hey, Dennis, please number your messages
too !):
>  What I want out of this project is something that is more *useful* to me
> than DOS or Windows, not something which takes the scientific world by storm.
 So for the system to be useful, you must be able to use its full
functionalities simply from a language (the so-called coordination language
as appeared in all OS project that arose in the discussion). I do not
consider calling libraries with grotesque structures (pointed ,referenced,
or copied) a simple system call. A system call must be simple, easy, and
don't change its syntax when you change implementation ! (that's also why a
Low-Level language as C++ cannot do).


 This is originaly Michaels mail, and Andreas tried to sumarize what we agree
on; I added my own stuff as a reply; disagreements are marked ***; additions
are marked +++. Now notice this, if we are going get something done in a
resonable amounte of time we must start to agree on things, as David
mentioned as a postlude in his mail.
 There are several "fields" which hadn't been discussed yet, so I took them.
Remember one thing: We can always begin in the simple and step up when we
need, AS LONG AS WE KEEP THE SYSTEM EXTENSIBLE BY HAVING ONLY HIGH-LEVEL
REQUIREMENTS; that's why here are only HL specs. Implementation is left out
(I have some ideas about them, but I won't explain it there; if you're not
convinced something can be efficiently implemented, then I'll show you
possible implementations).

------------------------------------------------------------------------------

 System -- The Fourth Attempt
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  [NOTE: I'm starting from a conventional OS and moving away rather then starting
>  from objects and moving towards OS -- I feel that this is more likely to
>  yield a running system in a short amount of time. As Dennis has pointed out
>  we don't have the resources to re-invent the wheel]

I'm rather starting from the other end: the user/programmer; how he
(actually, that's more like I) conceptualizes the system; what he expects it
to do, how he'd like to modify its behavior.

 THE Basic principle
 ~~~~~~~~~~~~~~~~~~~
 We base the system (and THUS the Kernel) on persistent object/processes.

 [Terminology: by persistent I mean that it can be swapped out to storage,
 the machine turned off and on and then continued. In practice we would like
 to be able to have a large number of suspended processes on disk]

 [This subsumes directories and files -- a directory is a particular kind of
 dictionary (see below), describing persistent objects (then if you call
 "files" persistent objects, a directory is a "file", and not even a
 particular one, as any object can contain sub-objects). Then the
 file/directory terminology in  other system is made obsolete, and remains
 the more general object/dictionary paradigm.]

+++
 The underlying idea, is that there's a Yin-Yang duality between processes and
objects (one always come with the other, and even different, they can't be
separated as each generates the other): object evaluation is done through
processing; processing management is done through object. This is true for
virtual as well as physical objects/processes, and at any abstraction level:
at lowest level, CPU instructions are binary coded / binary data is modified
through CPU instructions ; at highest level virtual object data may be
accessed through functions (a "zap" field can be accessed through virtual
read/write functions, so that zap := f(zap,...) will invoke zap.read and
zap.write), and virtual functions can be implemented as just data (i.e. a
function on a very limited number of elements can be coded as just an array
containing its values). 
 By virtual, I mean the system includes a high abstraction level where objects
are accessible through their abstract inter-object properties, not depending
on how they are implemented, implementation being the system's problem
(through a standard object evaluator, including compiling) ; this is not
only while programming, but at anytime when just using the system --
"programming" must be just using more deeply, without any clear boundary
between programmation and common use -- if you ever used a HP28/48, you know
what I mean. this implies there is no boundary either between compiling and
interpreting ; you just evaluate or simplify objects.

***
 In Mar 26 message Re: Kernel 0.11 [arf1], Michael says (hey, Michael, do
number your message !):
> What I meant was that a MOOSE object is defined to be a process.
> A small object that isn't a process (Eg. is internal to a
> process/large-object) isn't viewed as an object by the system.
 If by process, you mean a system object (assuming that by duality, objects
ever end up into processing), of course only processes are system objects !
 BUT, if you mean that the system's base object will have to save the CPU/FPU
state, plus system data, as unix tasks, then of course not ! If that's what
you want, just write a server under unix to relaunch tasks with checkpointed
data, and add it in the superuser's profile (I'm sure that's not what you
want).


 Objects
 ~~~~~~~
> An object is a process with method declerations.
+++
 Anything is an object.
 Integers are objects; the whole system is an object; even code is an object
class; classes are objects; anything is an object.
 NOW, every object doesn't have to be accessible from every other. That's
why, for example, every single temporary integer won't have to be directly
interfaced to the user. However, if you possess debug info, you can access
any single integer in the system (apart possibly from some temporary variables
in parts of the nucleus which need forbid interrupts).

 How to access an object - (O)ID's
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The system implements a basic type of data which is (object) IDentifiers.
The "object" word is unnecessary, as ANYTHING is an object, so of course,
what you IDentify IS an object. So I'll later refer to it as ID's (or OID's
when it's not obvious a general object is identified).
 ID's may include ID identification data, so that you can't just invent an
OID, use it, then crash the system. ID's are are valid through the whole
system; possibly automatically translated when transferred from one part
of the system to another (see remote adress space in a distributed system).
 Objects possess subobjects, accessible if you get their ID. There are
objects at any level; each level can be thought as an "implementation"
of higher level requirements. 
+++
What you can do is evaluate an object (giving him arguments), get a
sub-object/another aspect of the object, use it as an readable and/or
writeable argument to another function, or destroy it.
 An object's method is only one of its sub-objects (or of it's class'
sub-objects). As it is itself an object, no ID fields is required to
access an object's method: the method's ID is just a common OID;
after all, every object is another object's sub-object, except perhaps
the whole system !
 So let the inmost kernel manage but OIDs: that's all we need; then,
basic devices (see further lolos) can manage everything else. All
we need is OIDs (BTW can someone find how we can make "LOVE" an acronym
for OIDs ? :-)

 [implementation: IDs will organize naturally following modular
 grouping: if for example on the i386, we can use a 64 bit ID representing
 the  DT/segment/offset of a physical object, objects from the same module
 being very likely to be in the same segment or at least the same DT. Let
 the  implementer do it the best he can to fit requirements. We can also
 have but DT and segment, or but offset, or but segment and offset, and/or
 add a key/check field, to ensure that a bugged/pirat can't use an object
 that doesn't exist/didn't really give you the rights to use it. (that's
 been called capabilities, says Gary)]

 [if you're sure to use local objects, you're not forced to use global OIDs;
 external, unlinked objects must use OID's to communicatein (that's late OO
 binding); if you want to speed up execution, then link statically instead
 of dynamically linking (that's early binding); as you CAN compile only
 parts of your program and/or interpret part of it, and/or compile parts of
 it later]

 [Thus, in the same system implementation, there may be several different
 types of OID's managed; the only thing is any identifiable object's access
 may be allowed to another object through an OID; i.e. different tasks may
 have different OID mapping as long as they can communicate whatever OID
 to any other task through possible OID conversion.]

 Virtual Classes
 ~~~~~~~~~~~~~~~
 +++
 What differentiates objects one from the other, what unifies the concept of
objects, is the inter-object relationship.
 Raw data doesn't mean anything, as it can mean anything. What gives it
sense, what makes interesting or important, is not just its absolute, raw
value; its how this value interferes with other objects. In Maths, it's the
same: raw sets aren't interesting at all; what it interesting is the
structure you have on it; a set without a structure is so meaningless, than
when you name a set, you always intend an underlying, IMPLICIT structure on
it (for example, you talk about "group G" and "ring R", rather than "group
(G,+)" and "ring (R,+,x)", but certainly mean the operators without
explicitly naming them). Sometimes, you must explicit your structure, as
none or more than one is implicitly available for your given set.
 So in Computer Science, what describes the structure is classes. A class
is the data of a set of elements, and operators on this set; class may
(must) be interlinked by operators through both set, as there must be
(indirect, seldom direct) interaction between any class and the whole
system object (if not, by definition of existence in the system, the said
class would not even exist).
 Classes must not only state that operators do exist, for raw operators
(as operators are dual to set elements, and operator sets to set on which
they operate) are not more interesting than raw elements. Thus, the data
of element/operator classes (which is necessary) just does not suffice
(they're enough for just running, and may be enough for the kernel; but
they aren't enough to efficiently link dynamically and staying
meaningful at the same time) We need know more general restrictions:
-what object is being accessed, written, read, or referenced,
-what algebraic/functional equations are verified by the system objects,
-etc, etc.
 That may allow checking more strict but also more free for the programmer,
than just type
 The Kernel need only know about the implementation of a base class class,
say a DVT-driven-class-class class, then it will be able to use virtually
any class, then any object, provided any object has a class that indirectly
can finally be expressed by evaluating a basic class instance.
 What you may want to ask the class is:
- get the list of available members (methods/data).
- get an object's dictionary (isn't it more or less the same ?).
- get the info about restrictions applying on previous objects.
- creating a new instance/a list of new instance of the class.

 Functions
 ~~~~~~~~~
 +++
 Any object can also be considered as a virtual computation (call it a
function, a procedure) (polymorphic or not), which takes arguments as input,
and modifies consequently its output. A computation is deterministic, i.e.
given identical input, it will output the same thing to their output.
 NOW, 1) input and output may be the same object.
2) runing twice on the same object is not runing twice on the same data if
the input object has been modified
3) in particular, when you read from a pipe, the pipe is part of the input,
but also of the output, as you tell it to "advance".
4) some of the input may be declared non-deterministic/dependent on
uncontrollable external parameters (example: peripherals; shared objects)
5) some of the parameters may be implicit: some functions use global
(actually, more global) parameters. A common example is CPU registers are
implicitly given as both input and output to all binary functions (but
some functions can be trusted not to modify them, at the system's risk,
if their info tell they do).
6) a complete function descriptor include all this. Of course, it is not
needed to load it all if you already are sure of the function's features.
Only the function's ID is required; if you have it, you're supposed to
know how it works; if someone wants type checking, register saving and
all that, he'll just pipe a filter between the function and it's caller.

 Exceptions
 ~~~~~~~~~~
 +++
 Computations may well end up in a non-trivial way; a function may behave
exceptionally because of exceptional input: input not matching (common)
function's requirements, etc. Exceptions are the same as the events saw
in any "event-driven" environment:  someone produces it, others (and/or
the same) catch it, and treat it. However, we are not bound to the client/
server way of implementing exceptions: we can have local exceptions as
well as (more) global ones; in fact, each exception may be implemented
individually, although modules are present to help each one implement.
 Exceptions may also occur in/by special data coding:  a function that
the returns the next element of a set can actually return an element from
the set, or emit a "set is empty" (local) exception that's to be caught by
only one process in each chain of process.
 You can also have "positive" exceptions: a procedure that computes a
set's cardinal using previous function may emit a local "set not empty"
exception, but catch it itself if nobody else does; thus, if someone
knows only of a set counting function, he may more directly determine if
the set is empty or not without having to count each element (of course,
this is useful only is the first function is unaccessible, or slower than
the counting function that mustn't use it, then).
 Thus, exceptions can be unrecoverable/recoverable and may be caught by
the emitter if no one else catches it (this may be implemented by
a boolean indicating if someone else catches the exception, and another/
the same for the function to return if thee exception occured; but then
a catcher won't be able to recover after catching... but all this is
implementation problem).

 Multitasking
 ~~~~~~~~~~~~
 +++
 Several objects maybe evaluated at the same time, or wait for others to
evaluate; any single object computation may be done by switching between
objects only when an evaluation waits for another one to finish. However,
this is not good when you want independent/very lightly dependent objects
to live together, as we want in a multi-tasking system, where every user/
sub-user may want something different done, independently from the
other objects. Then, we have to (justly) share execution time between
each user/sub-user.
 The time-sharing system I propose is both simple and fairly fair:
at base system, there is only one "system" ("root") user. Then, at
each level, a user can split into "sub-users". To each user
corresponds a process; but processes can be asleep (waiting for another
process to finish/to emit an event) or awaken. Each sub-user may have
more weight than another to demand time. A prehensive system switch
changes user according weight proportion, and continues running the
process if awaken; if the user possesses sub-users, it will
recursively do the same algorithm. When you accept to leave the
hand to another, brother processes may prioritarily profit from it.
A process can be shared by multiple user, then, each user will
launch the process (if he had a non zero weight).
 [On multiprocessor systems, two cases arise: if multiple processors
 use common data, we can keep the same scheme (with a little
 optimization in distributing users preferably to a processor which
 still has it in its cache); if different processors have different]
Thus, we have a tree defined by recursive circular lists of processes;
There are also chained processes that organize in stack rather than
a circular list: each such process launches another one, then waits
for it to succeed.

 Dictionaries
 ~~~~~~~~~~~~
 A dictionary is a kind of object server: you tell him what object you
want, and if it has it, it gives you its ID. Basic dictionaries use names.
More generic object servers can use any criteria. Basically, an object
server is a function returning an OID, or an "Object not found" exception.
But another aspect of the object may be a sub-functione that searches the
object in an unexplored part of the dictionary only, together with a
function that initializes the unexplored part to the whole dictionary, so
that you can get ALL fitting objects, and decide yourself which to choose.
Thus, you can build complex dictionaries from simple one, by just adding
functionality to the dictionary functions, via virtual function members.
 +++
 Now, some dictionaries (not all: a function, for example, may know only
of its parameters and/or variables) may accept dynamically adding new
objects to them; this is done by a function having as explicit parameters
an OID, its type, and its "name" (be it ascii and/or number).
 +++
 A complete dictionary actually is a compiler symbol table !

 Security
 ~~~~~~~~
 Protection is done by restricting object servers: as you can only get
OIDs through name servers (that's the def. of a name server :-), you
can't access an object if no server which you could access possessed the
object's ID & key.
 Limited rights or also done by limited publishing of member functions/data
to public dictionaries.
 Each object may also be more or less trusted. For an object to be trusted,
you will have to recompile it or interpret it (with the same rights as you
gave the object; i.e. a non lolo accepted software cannot compile forbidden
hardware access instructions). Trust can organized at the user/subuser
multitasking level: each user is more or less trusted according to its
subuser behavior and to the trust given to the modules it uses. Modules
themselves are trusted according to their successive use. In a distributed
OS, each host may more or less trust other hosts and/or interhost link.
This may be done simply by assigning a user and/or module to each connected
host.


 Inheritance & Polymorphism
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 +++
 To me, inheritance is only saying "one aspect of that object is that it
fits another object's requirement, thus particularizing it"; so it's more
easy to name inheritance as a subobject of main object. So for example, an
aspect of a circle is it being an ellipsis; this is purely virtual, and
does not mean the physical implementation of a circle will effectively
include say, the length of both axes.
 Polymorphism is also done by using the same name for different objects.
Then, you can differentiate equally named objects by looking at their
different classes. This means a dictionary (although perhaps not base
dictionaries) can manipulate objects not only according to theirname, but
also acccording to their class/level.

 Information on an object
 ~~~~~~~~~~~~~~~~~~~~~~~~
 +++
 - To manage an object, you often need additional info about it, but just
its raw class and value; for example, you may need info on how to display/
print it, how to link it, if the object was chekcpointed to the
disk, if it supports compatibility with other similar modules,
if the object is in a valid state, or if you must waitfor it to initialize
properly.
 - the system scheduling may require the system to evalutate which is the
"best" of a set of operatons (more generallly of two objects), knowing of
a cost function upon.
 - those are IMPLICIT informations, which don't appear during computation,
but nevertheless are essential to the environment.
 - all this may be implemented by EXPLICITly having an info list and a
 pointer on the object. Again, implementation isn't to be discussed here.

 High Level Programming
 ~~~~~~~~~~~~~~~~~~~~~~
 If you followed my reasoning, the essential point that is important for
a HL programming language is allowing you to implicitly do any thing that
is "obvious"; of course, to be sure you and the computer have the same
opinion about the obviousness of such IMPLICIT statement, you must know
how he manages implicitness and/or ask him what is his opinion. This may
be done interactively in a user-interactive object editor/compiler
(editing and compiling may or may not be grouped; the GUI can also be
used to graphically view/edit objects).

----------------------------------------------------------------------------
 Some examples
 ~~~~~~~~~~~~~

- Dictionaries
Let us consider a C++-like function
struct zap zep (int zip, struct zop zup, struct zop & zyp)
{
 static a ;
 int b ;
   if (c) /* c: global variable */
    {
      ...
    }
}
It will have a dictionary containing zap,zip,zop,zup,zyp,a,b,c,
where each previous object will contain info about how the object may
be accessed from the function. Of course,
- the dictionary is virtual: it doesn't need contain all this info in
memory, if only it can answer questions from object clients;
- internal local variables need not be published (but the existence of a
static variable is important), neither need parameter names; types are more
important. And if you no object has access to those objects' name or to
internal local variables; then these don't exist, so why talk about them ?
- if you don't provide dictionary contents, you may have a pointer to it
as an Internet ftp-able address, for example, and/or emit an exception
explaining that you couldn't find the dictionary contents.
- this dictionary won't be extensible, as you should recompile the function
to enlarge it; however, the zup & zyp structures may contain themselves
subobjects that enlarge zep's scope.

----------------------------------------------------------------------------

Notes on second/third attempt on the Kernel:

 
>    * Invoking a method
>         This takes
>             (1) An OID
>             (2) The method "name"
>             (3) The arguments
 NO ! just use the method's OID and arguments ! The method is an object !
Let's address it directly !

>         Issues:
>             What is the type of the name?
>             An integer is the obvious.
> An atomic integer as suggested by all of us. See def. 3.
 This should be implementation and/or coding dependent.
 Maintaining a global integer scope for the whole system would be
VERY difficult, so names being pointers to a structure or anything
is just fine. Again, names should be accessed only through standard
name class methods, and thus be implementation independent.

>             When would the allocation of these be done?
Allocation is done as soon as possible, i.e.

> There are two suggestions; mine and Davids. Any more?
>             The permissible type of the arguments?
>             in a purely OO system we could just have OIDs and be
>             done. In our system it is doubtful that representing
>             (eg.) an array by an object would be practicle so we
>             need to be able to pass large granularity data between
>             objects.

>             This is where IPC comes in.
>             [I'm using the definition that IPC involves data
>             copying between address space]
 No ! IPC is meant to allow different processes using the same
objects, or writing objects that another one will read, etc.
If memory must be copied, well, it must. But the implementator
should be free to use the full hardware support to make IPC as
fast as possible (and in this case, we don't need copy big
chunks of memory; an the i386, segment descriptors may be used
to point more easily on any array of memory). I also suggest
dynamically compiling programs that do heavy IPC (the scheduler
should be aware that on a particular case, it is better to
perform a local compile, or to let the system use slower but
immediate late binding).



> A comment on (very) small objects
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In a pure OO environment one could use an object to represent say an array
> (not to mention an integer)

> This is impracticle if we treat objects as processes since then a method
> invocation involves a context switch.

> This does not prohibit using small objects WITHIN a single larger object it's
> just that these small objects can't be exported to the rest of the system.

> I don't think that we can develop a system supporting small objects with
> reasonable efficiency in reasonable time. It involves too much research.

 Of course we can, what is the problem here ? I really see no problem at
using arbitrarily big/small objects. All we need is keeping the whole
compiling info for the object we want to use. (unused debug info will be
compressed and/or deleted/not generated, according to user's demand and/or
use). Of course, interfacing objects that weren't designed for interfacing
will be slower than interfacing objects designed for it; you may locally
recompile a program to change only a variable's access.

> Some Other Issues
> ~~~~~~~~~~~~~~~~~
>
> These are areas which bear further thought.
> I'll indicate my initial reactions to these issues.
> Rather then spend time filling out the details now (and spark a debate on them)
> I'd like to come to agreement on the basics first.


> ----------------
> (1) Memory allocation:
>     What kernel calls, how and should we support higher level functionality.
>     (Eg. GC etc.)
> We have two suggestions here. Either a C-like way of doing it or Fare's way.
> (Don't remeber it exactly). I think it was more support for Dennis way of
> doing it. (Hope I didn't jump upon anyones toes now:-)

 That's the n-th time I repeat my opinion about memory allocation:
We'll have a layered organization of devices, providing graduated
functionality to user program; It's up to the compiler (as always,
with programmer's help) to use the proper device.
 memory alllocation zone features may be:
- word/block granularity
- realloc possible or not
- garbage collecting/ volunteer alloc,free
Of course, a memory zone may be included in another one. For example,e
independent programs may want to use independant memory zones, so that
a crash in one won't crash the other, so they will open each its own
sub-space of a memory allocation zone (or more likely, the system will
automatically do when a program ask for a memory zone).


> (2) LOLOs:
  ~~~~~~~~~~
> A Device or "LOw Level Object" (lolo) is an object which
> either
> (1) has been granted the privilege of being able to refer to certain hardware
> resources. (Eg. disk control registers, ethernet card)
> AND/OR
> (2) Has methods which are invoked upon the reciept of a particular interrupt.
> (Eg. data ready)
> [Note: Most lolo's will have (1) -- I think that few will have ONLY (2)]

I like it; but we must see that lolo's are only the lowest layers of a
multilayered system:
+++
 more generally, a lolo is an object that has be trusted by the system to
access hardware/software directly without any further system control (but
volontarily passed test). Then the most basic task and memory managers will
be lolo's also. 
 From the system scheduling view, hardware will be a (rather protected)
object, so that allowing someone to access hardware should only be a
particularization of letting some object access another.


>     How do we set an object up as a lolo, how do we give it access to a
>     certain region of memory.
>     (Implementation: we might need to have the access traped and then redone
>      by the kernel after checking -- MMUs don't neccessarily support fine
>      grain protection.
>      (Eg. this object can read bytes 100-102 and write bytes 103-110 but
>      can't touch bytes 0-99 and 111-500)
- first thing: if something is a lolo, it is powerful enough to crash the
whole system, so we can trust it not to crash it; of course, it may still
use any system protection scheme.
- now, an host dependent key must identify objects that have lolo rights
on a particular machine, so that you can't just write a virus and tell
another one's system it's a lolo (but you can still destroy your own
machine, if you really like it 8-).
- as for allowing limited rights on an object, that's for the compiler
to implement it (with help of libraries). On the i386, you can use
segment/page faults then manually verify rights. On any implementation,
you can use standard read/write functions, etc.



> (3) Virtual Memory and Address Space
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     I think we can more or less agree that seperate objects should not
>     be able to read/write each others address space for robustness
>     reasons.
>     Should we have an address space that is global or local to each object.
>     (Note: This IS an independant issue)

> agreed upon local (well - noone else said anything else :-)

>     How should VM be done? I think paging is the simplest way.
>     DEtails:
>         User input to the process if any
>         Existance of PHYS_MEM and it's management
 That's implementation dependent, and should not be part of OS specs
(but we can still talk about it in implementation discussion)
(I suggest again the use of +- modifiers to subject, depending on
whether the message talks about specs or implementation)

> Agreed upon paging.
 That's only for the i386, and that won't suffice. A protection scheme
should be included at OID level.

 [protection suggestion: OIDs are either completely sure (as segment
 descriptors in the i386), or not directly usable (you must ask the
 system to link you with a local ID -> OID correspondance). Whatever,
 if you can modify an OID variable, then some right checking must be
 done]

> Details havn't been discussed yet, but as far as we have come with the
> implementation I belive we could use the MEM_PHYS until we feel we need
> swaping.
Swapping may be at the same time a caching device, so it's not
that uninteresting (of course, it's not the first thing to implement
either).


> (4) Semantics of persistance:
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     One way to do persistance is to simply rely on paging -- assume all
>     objects are in a very large memory and let paging load them in as
>     needed.
Yes; we can even assume that for small system implementation  (like the
PC386 version), there will be a unique virtual addressable space of at most
4GB. To use more than 4GB disks, there should be a distributed system and/or
special device controllers.
>     As Dennis has pointed out this is inefficient.
No. What he pointed out is that we couldn't page-align every object
(all the more if everything is an object). We may still have this kind
of paging, but we may adapt it so that at any moment when the disk
isn't being written, the disk system file contains some valid data, so
that persistent objects are preserved if the computer is powered down.

>    Another way is swapping -- a process can only be either completely
>    swapped out or completely in memory.
 That's stupid when you can do paging, except if each process is small.
But we want BOTH tiny and huge objects. Moreover, as there is always a
bigger object to contain a given object, there will always be processes
too big to fit entirely in memory.

>     Disadvantage: Lose the ability to save memory by having part of a
>         process in memory
          - VERY slow for big processes.
>     Advantages: (1) Can be done without an MMU
          if we don't have MMU, we'll have to use an interpreter to
          enforce security, but for lolos, so there's no problem here; only
          interpreter design.
>         (2) By letting the user do this manually we allow coarse grain
>         manual resource allocation.
>         (Sort of like doing a "copy foo TO ramdisk" b4 starting
>         and having an automatic save files to hard disk from ramdisk
>         when about to shutdown)
          That's called caching. What we can have is a temp. object
    
 We can also parametrize the system to accept partial/global automatic/
manual chekpoints. However a good persistent system may have extra power
for saving critical data before shutdown.

> We havn't come to an agreement here, since there hasn't been any discussion.
> So let me suggest this. This is not a priority issue. We just use the
> simplest available scheme, and then we can step up to use a more advanced
> scheme when needed.
agreed.

> (5) Semantics of invocation
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     MOOSE is multitasking.
>     What happens in the following situation:
>
>     Object X    Object Y    Object Z
>     Invoke(Z,1)
>                     Starts executing method 1
>             Invoke(Z,2)
> The three obvious possibilities are
> (a) Z starts another method in parallel
> (b) Y is blocked until Z finishes
> (c) Y continues and the invocation is queued.
>
> (a) Gives us multithreading and requires us to have semaphores to co-ordinate
> access to shared data.
> (b) Is the simplest to implement but is less versatile
> (c) Makes invocation asynchronous -- this adds paralellism to the system.

 Notice that under (b) one could have the invoke call return a result.
 Under (c) though the invoke would not return anything (other then
 "this was succesfuly queued" OR "this failed") and the reciever would use
 it's own invoke to return an answer.

> Of course we could (and probly will end up doing) provide more than one.
  And we will provide the three of them; the only thing is the system may
 generate an task switch time interrupt and/or see that the launching
 process is running outside its normal time (example: an event driven
 process that interrupted normal execution) and thus decide to first
 execute next process (the launching thread will be given back execution
 when its normal turn comes back).
  A more generic invocation is telling the system: here is a list of
 computation to execute in parallel; do them all (with this priority
 order/time weight distribution), then give me back execution (or then
 end).
  See "multitasking" paragraph above.


> (6) Inheritance
  ~~~~~~~~~~~~~~~
>     I've left this out for now.
>     One question I would like to raise is WHICH INHERITANCE?
>     There are multiple models -- C++, Smalltalk.
>     Oh,  and this is without considering multiple inheritance.
 Inheritance as an implicitely opened (pascal "with"ed) member
is no problem. The inherited aspect of an object will only be a
sub-object among others. Only its high-level syntax is different,
with possibly a low-level naming convention (but I think putting
suitable info in the class descriptor may be enough).


> Could someone outline the smalltalk way, ada way and the simula way. I'm not
> familiar with other then C++, and I havn't studied ADA for a couple of years.

> (7) Polymorphism and Overloading
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     So far I've only come across these as language design issues.
>      You have a "natural" polymorphism in some commands
>      (Eg. mv,rm,cp) when the contents of a file don't matter.

>      Could someone expound on their ideas -- how do YOU view the role
>      and function of polymorphism in an OS.
 In an OS as everywhere, what we want is ease of use, and the least
redundancy in code&data; this leads to genericity (that is, you produce
code that is valid for the most generic data types/values possible, and
once it's written, you never have to rewrite it for a particular data;
the system/compiler will specialize code; somehow, it "undertands" what
you told him the most it could), and polymorphism which is context
dependent reuse of the same name (sometimes to stress the similarity
between two functions than couldn't be descended from a generic
function, and/or sometimes to use implicit parameters)



Note on servers
~~~~~~~~~~~~~~~

> Consider now the form of such a server (which incidently bears a striking
> resemblence to the nameservers (or dictionaries)):
>
>     while (accept(request))
>         case request of
>             type1 : ... handle 1 ...
>             type2 : ... handle 2 ...
>
> This type of code will be very common in the system.
> It allready is in event based systems.

Well, yes and no. If some code really appears often, it will be included in
modules which implement it efficiently and parametrizably. In particular, I
think the way a C compiler would implement it is bad; the while(accept())
function should be implemented by adding a request managing function to a
request catching handler list, or by putting the object to sleep (if
requesters already know of the object).

> Why then not have a process declare to the kernel that
> "I handle the following request:
>     req1 taking 4 parameters
>     req2 taking 3 parameters
> etc."

 That's more like it, but it certainly won't be the kernel (rather a
standard module in the base system). The compiler will do that; which
means it will implement it using a library (module) of more or less
compiled routines, and will choose the 'best' implementation himself
(or you can tell it your preferences/orders if you would; but a good
compiler/profiler couple should do it better than you).
 The system compiler should be accessible through standard means, and be
able to compile pre-compiled LLL code as well as HLL code, or any standard
intermediate representation of code between direct user-interfaced code
and direct CPU executed code. A LLL standard will be very efficient for
both quick compiling & quick code communication. If you keep it rich,
you have a good input for back-end compiling; if you compress it, you
may have efficient code for interpreting.
 Actually, the compiler does not compile code; it compiles objects,
simplifies them for optimal speed and/or memory occupation, or any
positive cost function. A common application is simplifying a chain of
functions: if you just run it, much time may be lost each function
calling next one. And checking functions may have been piped for security,
which are redundant and/or unuseful once you consider class info/
input restrictions/inter-object relations).
 To help the compiling structure, dictionaries will actually be compiler
symbol tables, so that you can co-compile with an object from its full
dictionary, and/or you can extract the everyday info of a dictionary from
the full symbol table.

------------------------------------------------------------------------------

 Summary of OO managing organisation in the system
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- we first have the Kernel's inmost part (I think Peter called it
Nucleus) which only manages low-level ROI and OIDs; it should be optimized
for speed.
- Then, we have a low-level security device, which only checks access
rights, through segmentation/pagination/whatever the hardware offers.
If the hardware offers no protection facility, non-lolo programs will
have to systematically use:
- a LLL interpreter.
- a typing/classing convention will be provided as a ML system.
- a type manager which will provide security through default type checking.
- a HL type manager understanding genericity, polymorphism, overloading.
- a scheduling type manager which chooses best object sequences from
an object sequence generator, and a cost function.
- an implicit type casting manager, using the scheduler to determine
the fastest path to transform a given type into another.

 Summary of base system objects
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- one basic physical class implementation (with DDVMT or such), that is,
a standard basic common ROI.
Basic Classes (low-level standards, implemented through direct ROI)
- dictionary class.
- class class.
- generic ROI class.
- computation class.
- event/exception class.
- an impliciteness/expliciteness protocol.
Modules (medium-level standards, implemented through basic classes)
- common UI functions.
- extensible object compiler
- other ROI implementation.
- other classes
HL Modules (high-level standards; given as source files; may be already
partly/fully compiled)
- anything.


-----------------------------------------------------------------------------
   ,         ,
Fare, aka Fare, son of his mother and father, master of himself (sometimes),
who haven't roleplayed for a long time ;-(, and never could play as regularly
as I'd have liked ;-(.


P.S.: I'm very slow at redacting such a paper (not talking about
writing it in english !): I've been typing it for hours ! (whereas a
quick draft on paper was done in some minutes). That's why
1) I didn't have time to talk about the language itself
2) I'll ask you to allow me writing in telegraphic style, next time,
and as long as we're doing a discussion and not a definitive paper.




From rideau@clipper Wed Mar 31 05:30:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29346; Wed, 31 Mar 93 05:30:25 +0200
Return-Path: <rideau@clipper>
Received-Date: Wed, 31 Mar 93 05:30:25 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07593; Tue, 30 Mar 93 19:27:39 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28319; Wed, 31 Mar 93 05:27:22 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9303310327.AA28319@clipper.ens.fr>
Subject: GEN,HLL+ [far25]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Wed, 31 Mar 93 5:27:21 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

 I'd like to regularly post a list of pros and cons about a new language,
and its features. Here I compare to C++.



C/C++
~~~~~
Advantages:
1- We already know this language, and don't have to readapt to another
language syntax (see New Language Disadvantage 1)
2- We can test language functions immediately, without having to wait
for the kernel to be done (see Disadvantages 4)

Disadvantages:
1- does not include code as a standard object, thus creating a boundary
between using and programming. You can't both program and use at the
same time. That's the opposite of user programmer/user friendliness
(see HP calculators, which despite their lack of power, are much more
usable than my unix workstation, because code IS an object as anything
on the HP).
2- is not a structured language: procedures are all global; that's why
C/C++ will NEVER allow having independent light threads, and why it's
impossible to have a lightweight multitasking system under C/C++.
You may notice that this point is related to the preceding remark:
if procedure were objects, you could include them individually inside
thread objects, then each thread would have its own independent code.
3- C++ know only early binding (i.e., it only compiles directly executable
code), hardly knows about dynamic library linking (that's not a language
transparent feature; only a linker feature); C/C++ considers a program
to be complete, finished, and run in the absolute without interaction
with other programs, but through the system; that's why all ROI in C
must be explicitly done through system calls !!!
4- The "we won't have to rewrite a compiler" argument doesn't stand: if
the system is to be OOed, we'll have to adapt the compiler so as it produce
system requirements complying OO code. Thus, we can easily use code
language code that don't use the kernel, but adapting the compiler output
code to fit kernel requirements will be such that it's difficult to
test programs with the Kernel !
5- As it's a low-level language, either we'll have to have low-level specs
for the OS (as with Unix), so that we can't adapt to an architecture
different from that for the which the OS was designed; or we'll have to
rewrite a great amount of the C/C++ code on each system adaptation.
So we lose either system functionality, or language portability.


New Language
~~~~~~~~~~~~
Disadvantages:
1- we have to relearn a new language syntax (see New language advantage 1).
2- we have to debug the language specifications as we use it.
3- we have to write a full compiler for it.

Requirements
1- may be quickly (semi-)compiled at the same time as written, and
intermediate LLL code can be efficiently interpreted.
2- everything is an object, including code, including classes.
3 - parallelism is included in simple language constructs (not
so hard to build from executable code being object).
4- Meta programming easy in the language: the compiler is its own
preprocessor; the language is its own macro-command language.

Advantages:
1- We can design the syntax to fit our needs and ideas, so that it's
much easier to use. Moerover, even C isn't our natural language, and
whatever language we use, there will have been adaptating time to use
it.
2- We can correct the lacks of any existing language we would have used.
3- Portability: both the system and the language will be as easy to
port. All you need do is writing a LLL back-end compiler and
hardware specific lolos.
4- The language is perfectly is adapted to the system. No need of bizarre
and slow language -> system call translation.
5- being able to be interpreted, it serves as a shell language as
well as a programming language; being powerful, and easy to specialize
via standard libraries, it also replaces small utility languages
(sed, awk, perl, etc); finally, being high-level and knowing of
relations between objects, it is easily adaptated to an AI language.
So there is no more need to learn a different language for every
application; the same language is used for (almost) everything; no
more need to learn new syntaxes each time.


This isn't finished, but I post it as well. Feel free to add your
comments.

   ,
Fare


PS: BTW, did anyone receive my [far23] message ? I didn't, so perhaps
I posted it only to one person (is it you, Andreas ?), and not to the
whole mailing-list. It wasn't a fundamental article, but I'd like not
to write it again nevertheless.

From ANDREASA@sofus.dhhalden.no Wed Mar 31 10:12:24 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06323; Wed, 31 Mar 93 10:12:22 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 31 Mar 93 10:12:22 +0200
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <10906-0@fenris.dhhalden.no>; Wed, 31 Mar 1993 10:12:07 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930331101154.384; 31 Mar 93 10:12:07 -0200
Message-Id: <MAILQUEUE-101.930331101151.352@sofus.dhhalden.no>
To: rideau@clipper (Francois-Rene Rideau)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 31 Mar 93 10:11:51 +0100
Subject: Re: GEN,HLL+ [far25]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

>  I'd like to regularly post a list of pros and cons about a new language,
> and its features. Here I compare to C++.
>

I havn't looked at Objective-C myself but could this do the job for us?

I'll check if I have far23.

Arff

sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From ANDREASA@sofus.dhhalden.no Wed Mar 31 11:09:20 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16875; Wed, 31 Mar 93 11:09:19 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 31 Mar 93 11:09:19 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18301; Wed, 31 Mar 93 00:47:26 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <11618-0@fenris.dhhalden.no>; Wed, 31 Mar 1993 10:45:29 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930331104516.448; 31 Mar 93 10:45:30 -0200
Message-Id: <MAILQUEUE-101.930331104506.416@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 31 Mar 93 10:45:06 +0100
Subject: Last updated contributor list.
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR


Group Name: Group Leader: Participants:
     Sub Group:
-----------------------------------------------------------------
MOOSE:      Dennis
     Organization:  Andreas#1 (temporarily)
                          Participants: All who gets this mail!
-----------------------------------------------------------------
Kernel:      Dennis       Dennis, John Newlin, Peter Mueller(?), Michael W.#1
                          Francois#2, David Garfield#3
        ROI: Peter M.(?) David Garfield#2
-----------------------------------------------------------------
IO devices:   None so far but don't worry

        Keyboards: David Garfield#1
        Disks (hard and floppy):
        Com/Parallel(/mice) ports: Dennis (he has already done some of it)
        SCSI-interface: Who where you who showed interrest in this?
        (G)UI: Andreas#2, JJ#2
------------------------------------------------------------------
Language support: Francois    Francois#1, JJ Lay#1 and Michael W.#2
                              Dan Odom
------------------------------------------------------------------

A #x behind a name just tells the participants priority if he has joined
several groups.


I miss response from the following:
Gary D. Duzan
Dr. Ross Hayden (expressed interrest in everything with hardware, suppose
                 group 2 somewhere for you?)
Rob McKeever
Peter Mueller (but I suppose you'll join the kernel group.)
Dspascha (?) ...
Erik "Fate@cc???" ...

Those who have responded:
Dennis
John Newlin
JJ Lay
Francois-Rene Rideau
Michael Winikoff
David Garfield
Dan Odom
Me



Arff

PS. We have had some gateway problems lately. I don't know if they are
fixed now or if it is temporarily. That is why some of you may have had
difficulties to reach me. DS

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From uunet.UU.NET!davgar!davgar.arlington.va.us!david Thu Apr  1 06:46:42 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22713; Thu, 1 Apr 93 06:46:41 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Thu, 1 Apr 93 06:46:41 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from spool.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26320; Wed, 31 Mar 93 20:35:24 -0800
Received: from davgar.UUCP by spool.UU.NET with UUCP 
	(5.61/UUNET-uucp-primary) id AA06452; Wed, 31 Mar 93 23:35:14 -0500
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Wed, 31 Mar 1993 23:30:35 EST
Date:      Wed, 31 Mar 1993 23:30:31 EST
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bba6fec.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re:  Are Processes Objects?   [djg14]
Status: OR

"> " is Dennis
"> > " is me

> > I feel that each process should provide drivers for 0 or more classes,
> > provide 0 or more public functions, and optionally include a startup
> > and shutdown functions.
>
> Good - a constructor and destructor possibly, plus some "main" function for
> the process to begin execution.  Then, if you wrote a C program, the main()
> function would map directly to this function...can anyone think of a better
> name than "main" though?

Well, actually I was thinking that main would be invoked from the
startup function in a C program.  The startup and shutdown functions
where not a constructor and destructor, becuase the process isn't an
object.  Object constructors and destructors would be part of the
class definitions.

> > Among other things, I am not sure what a process object would do with
> > methods to itself besides what I just said, and I don't see any of
> > what I already said requiring the process itself to receive messages
> > to its management object.
>
> In some cases, it would be nice for a process to let other processes access
> it.  I've been thinking device drivers almost need to be processes, and if
> they were objects their methods would be their interface.  Beyond this, only
> a few real applications would need a process interface, like database servers
> and so on.  In most cases, a process would need its "main" function and not
> much else in its external interface though.

But what you saying is that the only way to link one process to
another is by one of them BEING an object.  My point was that IMHO a
process is not an object but a collection of zero or more classes.
Thus, the process is the drivers.  So, for the serial port objects,
one process defines the serial port class, for which two objects are
created (assuming you have two serial ports).  Most processes will
probably define some classes and create objects of these classes, if
nothing else just to defines their user interface stuff.

> 		Dennis

David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From dmarer@td2cad.intel.com Thu Apr  1 00:56:11 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06385; Thu, 1 Apr 93 00:56:10 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Thu, 1 Apr 93 00:56:10 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05805; Wed, 31 Mar 93 14:49:24 -0800
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Wed, 31 Mar 93 14:49:21 -0800
Received: by td2cad (5.57/10.0i); Wed, 31 Mar 93 14:53:08 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00799; Wed, 31 Mar 93 15:00:45 PDT
Date: Wed, 31 Mar 93 15:00:45 PDT
Message-Id: <9303312300.AA00799@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Organization [dpm1]
Status: OR

Greetings Moosers!

The intent of this message is to expand on the organization efforts started by
Andreas - the focus of our efforts will shift a bit in the next few weeks,
which will give our brains a chance to think about something different.

-------------------------------------------------------------------------------

First, a suggestion.  We've been tossing around naming ideas for a while now,
and eventually decided to not try and name the operating system until it has
been better defined.  I agree, but do have one suggestion:

Why don't we call the kernel "Moose"?

I really like this name, and it captures the spirit of this project I've seen
so far.  (One big ugly beast?)  Anyway, none of the end users will care what
the kernel is called (or even if there is a kernel there) so I think its a
perfectly acceptable name.  Or, for the international faction, "Elger"?

Howzat sound?  (Look, a Moose smiley!---->   C:{  )

-------------------------------------------------------------------------------

Here's our plan of action for the next few weeks: we've generated a lot of
great ideas for the kernel, and its time to put all those ideas into a single
document.  That's what I've been working on for a while, and will continue to
work on until it's been finished, which could take another week or two.  I've
got over 1 megabyte of mail to sift through, so this is a long process.  I
feel after we've got something definite on paper, we'll be able to discuss it
in a more organized manner.

For example, when you feel changes need to be made, refer to the document:
"Chapter X, Section Y, Paragraph Z: I suggest..."  Without a document, there
is no record of the decisions made, or how they affect the rest of the system.

Some of you might have questions about why one person (me) is in charge of
the kernel at this stage.  This is because most of the details concerning the
kernel have already been discussed and they need to be written down, and
it won't be possible for us to collaborate on this task.  Obviously, this
might produce a document which looks like the kernel in Dennis' eyes, but I'm
trying to be objective and adding your needs and concerns as well.

If you're worried about me just having you as free coding help, don't.  I'll
probably want to do all that myself too.  :-)  Actually, no...I think coding
the kernel will be something much easier to collaborate on, and we'll be able
to split up tasks into logical, predefined sections, as described in the
specs we're working on now.

-------------------------------------------------------------------------------

My plan is set for the next couple of weeks, and I'd like to shift gears a bit
and set you all into a different line of thinking for a while.  At this point,
I'd like to ask you to trust me and assume the kernel is defined enough to the
point that we may start design of the rest of the system.  I'd like to turn
your brains away from the kernel for a short while and start thinking about
what resides on top of it.  Namely, as Andreas suggested, the devices.  I've
grouped things together more into related areas, as shown below:


User Input Devices
------------------

    Text input (keyboards, speech recognition)
    Position input (mice, touch screens, etc)

User Output Devices
-------------------
    Video output	
    Hard copy (Printers, plotters, faxes)

Mass Storage Devices
--------------------
    All types of disk drives (low level block access, floppy, hard, networked)
    Filesystems (HPFS, DOS, etc, etc, ???)

Communication Devices
---------------------
    Serial
    Parallel

Networking Devices
------------------
    Networks

Maybe I'm missing a few, or the groupings aren't quite right, but that's not
too important.  What is important is the concept of a device as an object, and
how it is similar to objects in its group.  For example, why could both the
serial and parallel devices utilize the same interface?  Each would be a
descendant of some 'communication device' object but implement its methods in
a way pertinent to itself.  Similarly, both hard copy and video devices might
share the same interface to simplify WYSIWYG output when the GUI is developed.
(Oh...I didn't put the GUI on here because its not a device.)

Here are some of the steps I see in defining device objects:

    1. Classification (Single vs. Multiple user)

	Can this device be used by more than one user at a time?  A serial
	port, for example, could only support a single user which greatly
	simplifies its interface and internal workings.  Disk drives need to
	be accessed by multiple users, so their interface needs to accomodate
	these needs and their internals become much more complicated.

    2. Relation to other devices

	How would this device work in conjunction with other devices?  Would
	it use other devices?  Would other devices use it?  How similar is it
	in functionality to other devices?  For example, a network device might
	be able to use either a standard serial port or FDDI hardware without
	changes to its internal structure.  This would be both of these types
	of communication devices should be designed with identical interfaces.

    3.	What special needs does the device have?  Can these be accomodated by
	the generic kernel or do special extensions need to be built in?

    4.	How will device contention occur (transparently to the user) in multi
	user devices? 

    5.	What will the interface to the device be?  For data transfer devices
	will this be block or stream oriented data?

    6.	How can devices with similar interfaces be better grouped together to
	minimize our work?  For example, could all data transfer devices (like
	disk drives, and network devices) use a common ancestor to handle some
	of the more common functionality?

Just thinking about it, here's a sample heirarchical structure of devices. I
just spent a few minutes on this, so its nothing concrete, just an example of
how things might be structured:

	device
	    dataTransfer
		blockData
		    massStorage
			floppyDrive
			fixedDrive
			    Winchester
			    SCSI
			    networkDrive
			    etc.
			CD-ROM
			floptical
		streamData
		    communication
			serialPort
			parallelPort
			modem
	    userInput
		characterBased
		    keyboard
		    voiceRecognition
		positionBased
		    mouse
		    touchScreen
	    userOutput
		hardCopy
		    printer
		    fax
		video
		    VGA
		    superVGA
	    audioOutput
		sampled
		    soundBlaster
		note
		    MIDI
		    etc...

Does anybody want to officially document this structure and keep it current?
Or restructure it?  Like I said, I only spent a few minutes on it...

-------------------------------------------------------------------------------

What I need you to do is to pick one of these areas and begin to design its
interface.  To do this you'll need to coordinate your efforts with those
devices in similar areas or with similar functionality to insure your
interfaces are compatible.  Andreas has already started taking volunteers for
each section, (and we're missing a lot of people) so sign up now or the rest
of us will have to take on multiple interfaces.

>From these designs, I also expect you to write a "chapter" in what will
eventually be our user documentation.  Don't worry right now about proper
English or organization, content is the most important for the time being.
Write down your definition of a particular class of objects, as well as how
it interacts with the rest of the system, and (finally) its interface.  Be as
complete as you can be!

If you're absolutely not interested in device drivers, say that too but come up 
with some suggestion of what else needs to be done.  Here's a partial list I 
can think of:

	GUI/TUI (Graphics/Text User Interface)
	User and session management, access rights
	Filesystems
	Languages

Any questions so far?  Just trying to divert your brains from the kernel long
enough for me to put it all down on paper.  Hopefully by the time I've finished
the kernel docs and mucketymockup, you'll have made enough progress on your
respective device so that you can implement a mockup of it as well and test
how it functions under the mockup.  This section will be individual work
mostly, but need lots of discussion among the group to coordinate how each
of our devices are used.

My dream is that we've defined and tested every aspect of the system before
we even attempt to implement it.  You don't think Intel developed and built
the Pentium processor without simulating it first, do you? :-)

		Dennis

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Thu Apr  1 07:48:20 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22815; Thu, 1 Apr 93 07:48:18 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Thu, 1 Apr 93 07:48:18 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28575; Wed, 31 Mar 93 21:37:28 -0800
Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA02695; Thu, 1 Apr 93 00:37:20 -0500
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 003305.26162; Thu, 1 Apr 1993 00:33:05 EST
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Thu, 01 Apr 1993 00:28:28 EST
Date:      Thu, 01 Apr 1993 00:28:24 EST
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bba7d7e.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: Organization [dpm1] [djg15]
Status: OR

On Wed, 31 Mar 93 15:00:45 PDT, "Dennis Marer" <dmarer@td2cad.intel.com> wrote:

[...]
> My plan is set for the next couple of weeks, and I'd like to shift gears a bit
> and set you all into a different line of thinking for a while.  At this point,
> I'd like to ask you to trust me and assume the kernel is defined enough to the
> point that we may start design of the rest of the system.  I'd like to turn
> your brains away from the kernel for a short while and start thinking about
> what resides on top of it.  Namely, as Andreas suggested, the devices.  I've
> grouped things together more into related areas, as shown below:
> 
> 
> User Input Devices
> ------------------
> 
>     Text input (keyboards, speech recognition)
>     Position input (mice, touch screens, etc)
> 
> User Output Devices
> -------------------
>     Video output
>     Hard copy (Printers, plotters, faxes)
> 
> Mass Storage Devices
> --------------------
>     All types of disk drives (low level block access, floppy, hard, networked)
>     Filesystems (HPFS, DOS, etc, etc, ???)
> 
> Communication Devices
> ---------------------
>     Serial
>     Parallel
> 
> Networking Devices
> ------------------
>     Networks
> 
> Maybe I'm missing a few, or the groupings aren't quite right, but that's not
> too important.  What is important is the concept of a device as an object, and
> how it is similar to objects in its group.  For example, why could both the
> serial and parallel devices utilize the same interface?  Each would be a
> descendant of some 'communication device' object but implement its methods in
> a way pertinent to itself.  Similarly, both hard copy and video devices might
> share the same interface to simplify WYSIWYG output when the GUI is developed.
> (Oh...I didn't put the GUI on here because its not a device.)

Just because it isn't a device doesn't mean it doesn't deserve equal 
consideration....  In fact, most of the system should be non-device 
classes.

> Here are some of the steps I see in defining device objects:
> 
>     1. Classification (Single vs. Multiple user)
> 
>         Can this device be used by more than one user at a time?  A serial
>         port, for example, could only support a single user which greatly
>         simplifies its interface and internal workings.  Disk drives need to
>         be accessed by multiple users, so their interface needs to accomodate
>         these needs and their internals become much more complicated.

I must disagree.  EVERYTHING should support multiple users.  In the 
case of a serial port, there is no reason why several dozen different 
programs cannot all be writing strings of data to a log printer on a 
serial device.  Offhand I can think of only 1 device (piece) that 
cannot have multiple users is the PC/AT keyboard drivers ResetCPU 
function, which, if a call gets past security checks, NEVER RETURNS 
AND TAKES OUT (terminates with extreme prejudice) MOOSE.

>     2. Relation to other devices
> 
>         How would this device work in conjunction with other devices?  Would
>         it use other devices?  Would other devices use it?  How similar is it
>         in functionality to other devices?  For example, a network device might
>         be able to use either a standard serial port or FDDI hardware without
>         changes to its internal structure.  This would be both of these types
>         of communication devices should be designed with identical interfaces.

Classes implementing an objects functionality have the ability to 
reference other objects.  Thus the IP class references a FDDI hardware 
object or a SLIP or PPP object which in turn references serial port 
object.  Of course, someone could go a bit crazy and put a SLIP object 
on top of a TCP object, but...  

>     3.  What special needs does the device have?  Can these be accomodated by
>         the generic kernel or do special extensions need to be built in?

Nothing should require extensions to the kernel.

>     4.  How will device contention occur (transparently to the user) in multi
>         user devices? 

It needs to occur inside 

>     5.  What will the interface to the device be?  For data transfer devices
>         will this be block or stream oriented data?
> 
>     6.  How can devices with similar interfaces be better grouped together to
>         minimize our work?  For example, could all data transfer devices (like
>         disk drives, and network devices) use a common ancestor to handle some
>         of the more common functionality?

If we don't do this, we aren't much better that Unix.

> Just thinking about it, here's a sample heirarchical structure of devices. I
> just spent a few minutes on this, so its nothing concrete, just an example of
> how things might be structured:
> 
>         device
modify:   object
>             dataTransfer
>                 blockData
add:                  communication
add:                      Ethernet
add:                          various ethernet cards
add:                      FDDI
add:                      IP            (non-device object)
add:                      UDP           (non-device object)
add:                      SLIP          (non-device object)
add:                      CSLIP         (non-device object)
>                     massStorage
>                         floppyDrive
>                         fixedDrive
>                             Winchester
>                             SCSI
>                             networkDrive
>                             etc.
>                         CD-ROM
>                         floptical
add:                      ramDisk
add:                      file          (non-device object)
        A file has basically the same capabilities of a mass storage 
        device with the addition that it is variable length.  Anything 
        you can put on a device you can also put in a file.  
add:                      partition     (non-device object)
>                 streamData
>                     communication
>                         serialPort
>                         parallelPort
>                         modem
(another non-device object)
add:                      terminal      (non-device object talking to 
                                        a userInput/characterBased and 
                                        a userOutput/video) 
add:                      TCP           (non-device object)
>             userInput
>                 characterBased
>                     keyboard
>                     voiceRecognition
>                 positionBased
>                     mouse
add:                      busMouse
add:                      serialMouse   (non-device object)
add:                      ps2Mouse      (keyboard user?)
>                     touchScreen
>             userOutput
>                 hardCopy
>                     printer
>                     fax
>                 video
>                     VGA
>                     superVGA
>             audioOutput
>                 sampled
>                     soundBlaster
>                 note
>                     MIDI
>                     etc...
> 
> Does anybody want to officially document this structure and keep it current?
> Or restructure it?  Like I said, I only spent a few minutes on it...

By the time get the system built there should be several hundred 
entries here.  It would be good to start considering how this stuff is 
given to the kernel.  In the hierarchical form.


David

P.S.  Dennis, try to avoid tabs...

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From danodom@matt.ksu.ksu.edu Fri Apr  2 00:04:12 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10703; Fri, 2 Apr 93 00:04:11 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Fri, 2 Apr 93 00:04:11 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15069; Thu, 1 Apr 93 13:56:58 -0800
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA04614; Thu, 1 Apr 93 15:57:50 CST
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304012157.AA04614@matt.ksu.ksu.edu>
Subject: Re: Organization [djo0]
To: moose-programmers@sfu.ca
Date: Thu, 1 Apr 93 15:57:49 CST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

I am afraid that my first message in over a month must be a critical one.
Oh, well; such are the ways of CompuGeeks :-)

>From the mind of David Garfield came:
> 
[Much of David's quote of Dennis deleted]
> > (Oh...I didn't put the GUI on here because its not a device.)
> 
> Just because it isn't a device doesn't mean it doesn't deserve equal 
> consideration....  In fact, most of the system should be non-device 
> classes.

I am opposed to the idea of developing the interface right now.
Personally, I can't stand a GUI.  Hate them with a passion (any
interface that spends more time entertaining the user than getting
actual work done has problems).  If we hold off on the development
of the UI until the end, each Mooser will be free to develop
his own interface.  Then we can offer several choices to the end
user.

[More deleted]

> I must disagree.  EVERYTHING should support multiple users.  In the 
> case of a serial port, there is no reason why several dozen different 
> programs cannot all be writing strings of data to a log printer on a 
> serial device.  Offhand I can think of only 1 device (piece) that 
> cannot have multiple users is the PC/AT keyboard drivers ResetCPU 
> function, which, if a call gets past security checks, NEVER RETURNS 
> AND TAKES OUT (terminates with extreme prejudice) MOOSE.

I agree with this, but we'll have to put some serious work in to the
various spoolers involved.

[Still more deleted]

> Nothing should require extensions to the kernel.

On the contrary, EVERYTHING should require extensions to the kernel.
A loaded device driver should be treated as a part of the kernel,
even if we use a Unix-style interface.

> 
> P.S.  Dennis, try to avoid tabs...

Please!  And, if we're going to quote like this, everyone should
try to stop typing by the 72nd column or so.

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

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

From winikoff@cs.mu.OZ.AU Fri Apr  2 02:15:59 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12113; Fri, 2 Apr 93 02:15:57 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 2 Apr 93 02:15:57 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26306; Thu, 1 Apr 93 16:10:46 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA22307
	Fri, 2 Apr 1993 10:02:03 +1000 (from winikoff)
Message-Id: <9304020002.22307@mulga.cs.mu.OZ.AU>
Subject: Re: KER,GEN+ [far24]
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 2 Apr 93 10:02:02 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303310226.AA13368@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 31, 93 4:26 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> functionalities simply from a language (the so-called coordination language
> as appeared in all OS project that arose in the discussion). I do not
> consider calling libraries with grotesque structures (pointed ,referenced,
> or copied) a simple system call. A system call must be simple, easy, and

Agreed.

> don't change its syntax when you change implementation ! (that's also why a
> Low-Level language as C++ cannot do).
> 
> 
>  This is originaly Michaels mail, and Andreas tried to sumarize what we agree
> on; I added my own stuff as a reply; disagreements are marked ***; additions
> are marked +++. Now notice this, if we are going get something done in a
> resonable amounte of time we must start to agree on things, as David
> mentioned as a postlude in his mail.

Unfortunately it is no longer clear from the document who said what ...

> I'm rather starting from the other end: the user/programmer; how he
> (actually, that's more like I) conceptualizes the system; what he expects it
> to do, how he'd like to modify its behavior.

I feel this is less practical -- there are things that users want that are
still research issues as regards eficient implementation while maintaining
security and robustness.

> 
> +++
>  The underlying idea, is that there's a Yin-Yang duality between processes and
> objects (one always come with the other, and even different, they can't be

Nope -- I'm DEFINING one in terms of the other.
Actualy objects as used in OO languages such as smaltalk are distrinct
from processes in that
(1) They don't have an independant thread of control
(2) Theyare of much smaller granularity.

> separated as each generates the other): object evaluation is done through
> processing; processing management is done through object. This is true for
> virtual as well as physical objects/processes, and at any abstraction level:
> at lowest level, CPU instructions are binary coded / binary data is modified
> through CPU instructions ; at highest level virtual object data may be
> accessed through functions (a "zap" field can be accessed through virtual
> read/write functions, so that zap := f(zap,...) will invoke zap.read and
> zap.write), and virtual functions can be implemented as just data (i.e. a
> function on a very limited number of elements can be coded as just an array
> containing its values)
. 

I get the feeling that you'r defoining an obkject interms of itself without
giving a base case to break out of the recursion.


> between programmation and common use -- if you ever used a HP28/48, you know
> what I mean. this implies there is no boundary either between compiling and
> interpreting ; you just evaluate or simplify objects.

Now you're confusing the conceptual language model and it's implementatuion.
For the point of view of givoing semantics to the language OF COURSE it doesn't 
mater whether the language is interpreteted opr compiled.

> 
> ***
>  In Mar 26 message Re: Kernel 0.11 [arf1], Michael says (hey, Michael, do
> number your message !):
> > What I meant was that a MOOSE object is defined to be a process.
> > A small object that isn't a process (Eg. is internal to a
> > process/large-object) isn't viewed as an object by the system.
>  If by process, you mean a system object (assuming that by duality, objects
> ever end up into processing), of course only processes are system objects !
>  BUT, if you mean that the system's base object will have to save the CPU/FPU
> state, plus system data, as unix tasks, then of course not ! If that's what
> you want, just write a server under unix to relaunch tasks with checkpointed
> data, and add it in the superuser's profile (I'm sure that's not what you
> want).

I *DO* mean a conventional process.
IMPORTANT POINT ABOUT TERMIN0OLOGY -- IF I USE A STANDARD TERM ASSUME I MEAN`
THE STANDARD THING -- IF I WANT A NOSTANDARD THING I'LL USE A NON STANDARD TERM

Regareds writing a server -- what do you implement the server on top of?


>  Integers are objects; the whole system is an object; even code is an object
> class; classes are objects; anything is an object.
>  NOW, every object doesn't have to be accessible from every other. That's
> why, for example, every single temporary integer won't have to be directly
> interfaced to the user. However, if you possess debug info, you can access
> any single integer in the system (apart possibly from some temporary variables
> in parts of the nucleus which need forbid interrupts).

NO NO No !!!!!!

As I was arguing, tiny granularity objects are not practical while maintaini ng 
protection. Mostly because there is an overhead of method cal as compared
to a direct access.

Things like integeres or arrays can be objects ihn the language you're using but
The OS doesn';t know or care about them - they are internal to the application.


>  So let the inmost kernel manage but OIDs: that's all we need; then,
> basic devices (see further lolos) can manage everything else. All
> we need is OIDs (BTW can someone find how we can make "LOVE" an acronym
> for OIDs ? :-)

You'd have problems finding a relevant word containing "V" ... :-)

> meaningful at the same time) We need know more general restrictions:
> -what object is being accessed, written, read, or referenced,
> -what algebraic/functional equations are verified by the system objects,
> -etc, etc.
>  That may allow checking more strict but also more free for the programmer,
> than just type
>  The Kernel need only know about the implementation of a base class class,
> say a DVT-driven-class-class class, then it will be able to use virtually
> any class, then any object, provided any object has a class that indirectly
> can finally be expressed by evaluating a basic class instance.
>  What you may want to ask the class is:
> - get the list of available members (methods/data).
> - get an object's dictionary (isn't it more or less the same ?).
> - get the info about restrictions applying on previous objects.
> - creating a new instance/a list of new instance of the class.

Can you convince me that this can be efficiently implemented?
Curently I don't see that it can.


> 
>  Inheritance & Polymorphism
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~
>  +++
>  To me, inheritance is only saying "one aspect of that object is that it
> fits another object's requirement, thus particularizing it"; so it's more
> easy to name inheritance as a subobject of main object. So for example, an
> aspect of a circle is it being an ellipsis; this is purely virtual, and
> does not mean the physical implementation of a circle will effectively
> include say, the length of both axes.
>  Polymorphism is also done by using the same name for different objects.
> Then, you can differentiate equally named objects by looking at their
> different classes. This means a dictionary (although perhaps not base
> dictionaries) can manipulate objects not only according to theirname, but
> also acccording to their class/level.
> 

I'm more interested in the mechanism you're using to express polymorphism
at the OS level then in what it is.

> 
> Notes on second/third attempt on the Kernel:
> 
>  
> >             What is the type of the name?
> >             An integer is the obvious.
> > An atomic integer as suggested by all of us. See def. 3.
>  This should be implementation and/or coding dependent.
>  Maintaining a global integer scope for the whole system would be
> VERY difficult, so names being pointers to a structure or anything
> is just fine. Again, names should be accessed only through standard
> name class methods, and thus be implementation independent.

Yes.

> >             This is where IPC comes in.
> >             [I'm using the definition that IPC involves data
> >             copying between address space]
>  No ! IPC is meant to allow different processes using the same
> objects, or writing objects that another one will read, etc.
> If memory must be copied, well, it must. But the implementator
> should be free to use the full hardware support to make IPC as
> fast as possible (and in this case, we don't need copy big
> chunks of memory; an the i386, segment descriptors may be used
> to point more easily on any array of memory). I also suggest
> dynamically compiling programs that do heavy IPC (the scheduler
> should be aware that on a particular case, it is better to
> perform a local compile, or to let the system use slower but
> immediate late binding).

I take it you disagre with my definition of IPC rather then with what I'm 
saying.

> 
> 
>  Of course we can, what is the problem here ? I really see no problem at
> using arbitrarily big/small objects. All we need is keeping the whole
> compiling info for the object we want to use. (unused debug info will be
> compressed and/or deleted/not generated, according to user's demand and/or
> use). Of course, interfacing objects that weren't designed for interfacing
> will be slower than interfacing objects designed for it; you may locally
> recompile a program to change only a variable's access.

There is a significant overhead.
Apart from the extra information that the system has to keep around to 
manage an object we have the problem that acessing an object is done
by method call whereas accessing a variable can be done by direct acess.
Direct access is much faster then a method call.
It realy bolis down tohow much work uis done by a method call.
I'd guess thatif we limited the functionality of method cals (EG. no virtual
functions or inheruitance - which implies a method search) then we could
bring the overhead down to afactor of 4 or so using hand tuned code.

> - first thing: if something is a lolo, it is powerful enough to crash the
> whole system, so we can trust it not to crash it; of course, it may still
> use any system protection scheme.

Yes. 

> >     As Dennis has pointed out this is inefficient.
> No. What he pointed out is that we couldn't page-align every object
> (all the more if everything is an object). We may still have this kind
> of paging, but we may adapt it so that at any moment when the disk
> isn't being written, the disk system file contains some valid data, so
> that persistent objects are preserved if the computer is powered down.

NO. it IS ineficnet due to the overhead of method invocations.

I would just like to point out that this discussion about doing without an 
MMU was a hypothetical aside.

> 
> >     Disadvantage: Lose the ability to save memory by having part of a
> >         process in memory
>           - VERY slow for big processes.
> >     Advantages: (1) Can be done without an MMU
>           if we don't have MMU, we'll have to use an interpreter to
>           enforce security, but for lolos, so there's no problem here; only
>           interpreter design.

Nope - to slow.
Machines woithout MMUs tend to be old and slow anyhow ...

> 
> Note on servers
> ~~~~~~~~~~~~~~~
> 
> > Consider now the form of such a server (which incidently bears a striking
> > resemblence to the nameservers (or dictionaries)):
> >
> >     while (accept(request))
> >         case request of
> >             type1 : ... handle 1 ...
> >             type2 : ... handle 2 ...
> >
> > This type of code will be very common in the system.
> > It allready is in event based systems.
> 
> Well, yes and no. If some code really appears often, it will be included in
> modules which implement it efficiently and parametrizably. In particular, I
> think the way a C compiler would implement it is bad; the while(accept())
> function should be implemented by adding a request managing function to a
> request catching handler list, or by putting the object to sleep (if
> requesters already know of the object).
> 

PLEASE READ -- I WAS USING THIS AS *MOTIVATION* FOR HAVING OBJECTS RATHER THENN PROCESSES.
THIS WIL NOT, REPEAT NOT, OCCUR IN THE CODE.

> 
> ------------------------------------------------------------------------------
> 
>  Summary of OO managing organisation in the system
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> - we first have the Kernel's inmost part (I think Peter called it
> Nucleus) which only manages low-level ROI and OIDs; it should be optimized
> for speed.
> - Then, we have a low-level security device, which only checks access
> rights, through segmentation/pagination/whatever the hardware offers.
> If the hardware offers no protection facility, non-lolo programs will
> have to systematically use:
> - a LLL interpreter.
> - a typing/classing convention will be provided as a ML system.
> - a type manager which will provide security through default type checking.
> - a HL type manager understanding genericity, polymorphism, overloading.
> - a scheduling type manager which chooses best object sequences from
> an object sequence generator, and a cost function.
> - an implicit type casting manager, using the scheduler to determine
> the fastest path to transform a given type into another.

Too complex.

> 
>  Summary of base system objects
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> - one basic physical class implementation (with DDVMT or such), that is,
> a standard basic common ROI.
> Basic Classes (low-level standards, implemented through direct ROI)
> - dictionary class.
> - class class.
> - generic ROI class.
> - computation class.
> - event/exception class.
> - an impliciteness/expliciteness protocol.
> Modules (medium-level standards, implemented through basic classes)
> - common UI functions.
> - extensible object compiler
> - other ROI implementation.
> - other classes
> HL Modules (high-level standards; given as source files; may be already
> partly/fully compiled)
> - anything.
> 
> 
> -----------------------------------------------------------------------------
>    ,         ,
> Fare, aka Fare, son of his mother and father, master of himself (sometimes),
> who haven't roleplayed for a long time ;-(, and never could play as regularly
> as I'd have liked ;-(.
> 
> 
> P.S.: I'm very slow at redacting such a paper (not talking about
> writing it in english !): I've been typing it for hours ! (whereas a
> quick draft on paper was done in some minutes). That's why
> 1) I didn't have time to talk about the language itself
> 2) I'll ask you to allow me writing in telegraphic style, next time,
> and as long as we're doing a discussion and not a definitive paper.
> 
> 
> 
> 

Sory, if I seem rushed - I am.
Gotta run.
Be replying to other mail later today.



--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Apr  2 05:04:32 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13746; Fri, 2 Apr 93 05:04:31 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 2 Apr 93 05:04:31 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from spool.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05192; Thu, 1 Apr 93 18:56:41 -0800
Received: from davgar.UUCP by spool.UU.NET with UUCP 
	(5.61/UUNET-uucp-primary) id AA27072; Thu, 1 Apr 93 21:56:11 -0500
Message-Id: <9304020256.AA27072@spool.UU.NET>
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Thu, 01 Apr 1993 21:49:04 EST
Resent-Date: Thu, 01 Apr 1993 21:48:24 EST
Resent-From: "David Garfield" <david@davgar.arlington.va.us>
Resent-Message-Id: <2bbba9a1.davgar@davgar.arlington.va.us>
Resent-Organization: Third Star on the Left
Resent-To: moose-programmers@sfu.ca
From: dmarer@td2cad.intel.com (Dennis Marer)
Date: Thu, 1 Apr 93 09:32:44 PDT
To: david@davgar.arlington.va.us
Subject: Re: Organization [dpm1] [djg15]
Status: OR


> > Is Dennis
> Is David

> > (much stuff deleted)

>     1. Classification (Single vs. Multiple user)
> 
>         Can this device be used by more than one user at a time?  A serial
>         port, for example, could only support a single user which greatly
>         simplifies its interface and internal workings.  Disk drives need to
>         be accessed by multiple users, so their interface needs to accomodate
>         these needs and their internals become much more complicated.
>
> I must disagree.  EVERYTHING should support multiple users.  In the 
> case of a serial port, there is no reason why several dozen different 
> programs cannot all be writing strings of data to a log printer on a 
> serial device.  Offhand I can think of only 1 device (piece) that 
> cannot have multiple users is the PC/AT keyboard drivers ResetCPU 
> function, which, if a call gets past security checks, NEVER RETURNS 
> AND TAKES OUT (terminates with extreme prejudice) MOOSE.

If several dozen different programs try to access the serial port at once,
what appears at the other end would be garbage.  Without knowing what's
connected to the other end of the serial port, there would be no way to
logically manage access by multiple processes.

If, for instance, you wished to connect the printer to a serial port, there
would need to be some process (like Print Manager in Windows) to manage the
serial port.  When it started, it would acquire the serial port, thereby
making it unavailable to all other processes.  It could then logically know
how to manage the hardware.  A device like the serial port is a very general
purpose device, and the low level access to it should involve only minor
management.  And buffering or contention access is usally dependent on what's
connected to the other end.



Those are good suggestions for new entries to our device heirarchy!  There
surely will be hundreds when we're through.

I tinkered more with our mucketmockup, trying to write a simple device
driver for a text screen.  I discovered there were absolutely no advantages
to this device driver being a process, i.e. it does not need any periodic
use of the CPU time except to service interrupts and so on.  Can anyone think
of any reason a device driver should be a process?

I'm guessing possibly we could make a device driver a shared object owned by
the kernel.  (Their data would reside in the kernel's memory space...?)  I
don't know...maybe y'all have some better suggestions!


			Tschuess,

			    Dennis
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Apr  2 05:04:36 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13750; Fri, 2 Apr 93 05:04:36 +0200
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 2 Apr 93 05:04:36 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05210; Thu, 1 Apr 93 18:56:56 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa19646; 1 Apr 93 21:44 EST
Received: from louie.udel.edu by sol.cis.udel.edu id aa21019; 2 Apr 93 2:39 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa29770;
          2 Apr 93 2:34 GMT
To: moose-programmers@sfu.ca
Subject: Class -> Object -> Thread
Date: Thu, 01 Apr 93 21:34:40 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304020234.aa29770@bifur.cis.udel.edu>
Status: OR


   How's this sound for a small idea? A chunk of code is a class,
with no external interface except an initialization entry point.
When an external entity initializes the class, it acquires passive
state and sets up its interface, but is not (necessarily) active
afterwards. When a method call is made, either internal or external
to the object, the active method becomes a thread, including active
state (registers, stack, etc).
   Note that this has no mention of how the class code is generated,
how method calls are implemented, or concurrency semantics. Can we at
least agree on something like this as a base concept to work from?
We are never going to agree on anything if we start from 40K of
description, mostly because I keep falling asleep/getting lost while
trying to digest it all. Let's build a small core of agreement; a
microdesign, if you will; and build up from there.

   On another point, I see no reason to make tiny to small objects
addressable throughout the system. I believe that there have to be
atoms in a language/system. What would be the good of defining a
system-level interface for every integer variable in every program?
Just because I am special and can access another object's state
doesn't mean that I am accessing objects within it, the reason being
that I am not following the interface rules set by the object.
   As for a special language, a LLL, and security for MMU-less
machines, I don't believe we need them. Defining the system entirely
within a new language would hamper the use of other languages in the
system. The coordination language concept I referred to earlier has
nothing to do with general purpose programming languages. Rather it
is a conceptual base for adding a standard communication mechanism to
an existing language. Maintaining consistent syntax across langauges
would be a goal to aim for, though not, I imagine, always
possible/practical. As in most cases, consistent semantics are more
important than the syntax. I see no reason to use a LLL when we have
all this wonderful compiler technology lying about. And I would say
that securing MMU-less hardware would be more trouble than it would
be worth. MMU-less machines are going to be single-user anyhow, for
the most part, so there shouldn't be as much to lose. By the time
we get this thing finished, you will be able to get an MMU out of
a vending machine for 50 cents, anyway. :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Fri Apr  2 05:34:33 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17375; Fri, 2 Apr 93 05:34:31 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 2 Apr 93 05:34:31 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06460; Thu, 1 Apr 93 19:29:56 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA29630
	Fri, 2 Apr 1993 13:11:25 +1000 (from winikoff)
Message-Id: <9304020311.29630@mulga.cs.mu.OZ.AU>
Subject: Re: GEN,HLL+ [far25]]
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 2 Apr 93 13:11:24 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9303310327.AA28319@clipper.ens.fr>; from "Francois-Rene Rideau" at Mar 31, 93 5:27 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
>  I'd like to regularly post a list of pros and cons about a new language,
> and its features. Here I compare to C++.
> 

You're missing a third very important option -- use an existing language
other then C/C++

Eg. Modula-3, Ada, Eiffel, Sather.
Sather in particular could be a good candidate.
It has a compiler freely available. 
I'm currently FTPing it to see how much source code is included and what
are the license conditions.
	
> 5- being able to be interpreted, it serves as a shell language as
> well as a programming language; being powerful, and easy to specialize
> via standard libraries, it also replaces small utility languages
> (sed, awk, perl, etc); finally, being high-level and knowing of
> relations between objects, it is easily adaptated to an AI language.
> So there is no more need to learn a different language for every
> application; the same language is used for (almost) everything; no
> more need to learn new syntaxes each time.

Ummm, are we discussing the language for the system implermentation or
the user language?
I feel that the requirements for the two are sufficiently different that we
can't easily use the same language for both.

> 
> 
> This isn't finished, but I post it as well. Feel free to add your
> comments.
> 
>    ,
> Fare
> 
> 
> PS: BTW, did anyone receive my [far23] message ? I didn't, so perhaps
> I posted it only to one person (is it you, Andreas ?), and not to the
> whole mailing-list. It wasn't a fundamental article, but I'd like not
> to write it again nevertheless.
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Fri Apr  2 05:45:52 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19171; Fri, 2 Apr 93 05:45:50 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 2 Apr 93 05:45:50 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06858; Thu, 1 Apr 93 19:41:03 -0800
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA00970
	Fri, 2 Apr 1993 13:40:47 +1000 (from winikoff)
Message-Id: <9304020340.970@mulga.cs.mu.OZ.AU>
Subject: Re: Class -> Object -> Thread
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 2 Apr 93 13:40:46 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To:  <9304020234.aa29770@bifur.cis.udel.edu>; from "Gary D. Duzan" at Apr 1, 93 9:34 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> 
>    How's this sound for a small idea? A chunk of code is a class,
> with no external interface except an initialization entry point.
> When an external entity initializes the class, it acquires passive
> state and sets up its interface, but is not (necessarily) active
> afterwards. When a method call is made, either internal or external
> to the object, the active method becomes a thread, including active
> state (registers, stack, etc).

I don't understand what you're suggesting.

> 
>    On another point, I see no reason to make tiny to small objects
> addressable throughout the system. I believe that there have to be
> atoms in a language/system. What would be the good of defining a
> system-level interface for every integer variable in every program?
> Just because I am special and can access another object's state
> doesn't mean that I am accessing objects within it, the reason being
> that I am not following the interface rules set by the object.

Agree!

>    As for a special language, a LLL, and security for MMU-less
> machines, I don't believe we need them. Defining the system entirely

Yes!

> within a new language would hamper the use of other languages in the

Yes!

> system. The coordination language concept I referred to earlier has
> nothing to do with general purpose programming languages. Rather it
> is a conceptual base for adding a standard communication mechanism to
> an existing language. Maintaining consistent syntax across langauges
> would be a goal to aim for, though not, I imagine, always

Yes!

> possible/practical. As in most cases, consistent semantics are more
> important than the syntax. I see no reason to use a LLL when we have

Yes!

> all this wonderful compiler technology lying about. And I would say
> that securing MMU-less hardware would be more trouble than it would
> be worth. MMU-less machines are going to be single-user anyhow, for
> the most part, so there shouldn't be as much to lose. By the time
> we get this thing finished, you will be able to get an MMU out of
> a vending machine for 50 cents, anyway. :-)
> 
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 
> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Apr  2 07:45:11 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20832; Fri, 2 Apr 93 07:45:10 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 2 Apr 93 07:45:10 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from spool.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11221; Thu, 1 Apr 93 21:41:46 -0800
Received: from davgar.UUCP by spool.UU.NET with UUCP 
	(5.61/UUNET-uucp-primary) id AA08093; Fri, 2 Apr 93 00:41:38 -0500
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 02 Apr 1993 00:37:05 EST
Date:      Fri, 02 Apr 1993 00:36:56 EST
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bbbd102.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: Organization [dpm1] [djg15] [djg16]
Status: OR

"> > > " Is Dennis
"> > " Is David
"> " Is Dennis

> > > (much stuff deleted)
>
> > >    1. Classification (Single vs. Multiple user)
> > >
> > >       Can this device be used by more than one user at a time?  A serial
> > >       port, for example, could only support a single user which greatly
> > >       simplifies its interface and internal workings.  Disk drives need to
> > >       be accessed by multiple users, so their interface needs to accomodate
> > >       these needs and their internals become much more complicated.
> >
> > I must disagree.  EVERYTHING should support multiple users.  In the
> > case of a serial port, there is no reason why several dozen different
> > programs cannot all be writing strings of data to a log printer on a
> > serial device.  Offhand I can think of only 1 device (piece) that
> > cannot have multiple users is the PC/AT keyboard drivers ResetCPU
> > function, which, if a call gets past security checks, NEVER RETURNS
> > AND TAKES OUT (terminates with extreme prejudice) MOOSE.
>
> If several dozen different programs try to access the serial port at once,
> what appears at the other end would be garbage.  Without knowing what's
> connected to the other end of the serial port, there would be no way to
> logically manage access by multiple processes.

I didn't say it would always make sense, but if you write line buffers
to a serial port attached to a printer, it can make sense.

> If, for instance, you wished to connect the printer to a serial port, there
> would need to be some process (like Print Manager in Windows) to manage the
> serial port.  When it started, it would acquire the serial port, thereby
> making it unavailable to all other processes.  It could then logically know
> how to manage the hardware.  A device like the serial port is a very general
> purpose device, and the low level access to it should involve only minor
> management.  And buffering or contention access is usally dependent on what's
> connected to the other end.

Actually, I think it should be a print manager CLASS which buffers
activity until a print manager object is closed, and then sends
everything at once to the real printer interface object.  One more
class for the hierarchy.  Remember, lots of stuff, not just the
devices, are classes.

> Those are good suggestions for new entries to our device heirarchy!  There
> surely will be hundreds when we're through.
>
> I tinkered more with our mucketmockup, trying to write a simple device
> driver for a text screen.  I discovered there were absolutely no advantages
> to this device driver being a process, i.e. it does not need any periodic
> use of the CPU time except to service interrupts and so on.  Can anyone think
> of any reason a device driver should be a process?

I changed the root from device to object with good reason.  This is
the class hierarchy.  An entry here means a class, not an object, not
a device.  I agree that the class that looks like a stream interface
and maps to a keyboard and video object does deserve a process of its
own, but this is why I am arguing that objects are not processes /
processes are not objects.

As for "our mucketmockup", ok if this is "our"s, how do I see it?  Or
should that have been "my mucketmockup"?

> I'm guessing possibly we could make a device driver a shared object owned by
> the kernel.  (Their data would reside in the kernel's memory space...?)  I
> don't know...maybe y'all have some better suggestions!


-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From ANDREASA@sofus.dhhalden.no Fri Apr  2 11:15:15 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23376; Fri, 2 Apr 93 11:15:14 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Fri, 2 Apr 93 11:15:14 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA16514; Fri, 2 Apr 93 01:07:13 -0800
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <00316-0@fenris.dhhalden.no>; Fri, 2 Apr 1993 11:07:05 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930402110652.384; 02 Apr 93 11:07:05 -0100
Message-Id: <MAILQUEUE-101.930402110650.352@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 2 Apr 93 11:06:50 +0100
Subject: Re: Organization [djo0] [arf1]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

I am afraid that my first answer to you in over a month must be a critical
one C:}.

> I am afraid that my first message in over a month must be a critical one.
> Oh, well; such are the ways of CompuGeeks :-)
>
> From the mind of David Garfield came:
> >
> [Much of David's quote of Dennis deleted]
> > > (Oh...I didn't put the GUI on here because its not a device.)
> >
> > Just because it isn't a device doesn't mean it doesn't deserve equal
> > consideration....  In fact, most of the system should be non-device
> > classes.
>
> I am opposed to the idea of developing the interface right now.
> Personally, I can't stand a GUI.  Hate them with a passion (any
> interface that spends more time entertaining the user than getting
> actual work done has problems).  If we hold off on the development
> of the UI until the end, each Mooser will be free to develop
> his own interface.  Then we can offer several choices to the end
> user.

Very good idea. I had thought of making moose available to the lower layers
of the people (ie. non programmers C:} ). That would mean a standard
interface, or at least standard functions for each interface item.
As I have understod the UI filosofy there will be a GUI and a TUI. Of
course you could build a GUI in a TUI if we made the graphics
initialization commands public (as I suppose we'll do). But I don't think
there should be 13 different GUIs, each with a different object structure.
What we could do; Make some sort of dynamic gadget library, so you could
add (or even change some of the existing) gadgets.

What I think is important is to have a single GUI with a common UI, to
simplifie the users life. Another question; is everybody prepared to put
down the work needed to get a good UI? I think if we make 13 GUIs we'd
have 13 bad GUIs, but if we made 1 (base) GUI we'd have 1 good gui!

I also hate GUIs with some passion, because I think they aren't good enough.
Take the mac, an old black and white GUI. It will never (?) become a true
color GUI. Take windows (os2). Fancy and bright colors; make you tired in
5 minutes. Take NeXT; very good, but it is better suited in a workstation
environment than as a PC beacuse of all its advanced features. Still I don't
like the NeXT gui very much, even though it is the best ever made IMHO.
Both mac and next makes you very dependant of the mouse.

The point of developing a GUI is not to make it entertaining; but to make it
easy to work with. I'd rather prefer a GUI with quite a high learning
threshold that has hundreds of shortcuts everywhere, than a true point and
click GUI as mac and next.

If we wait with it til moose is finished it won't become an integrated part
of the OS and that is pretty dumb I belive. Then we will have another windows
(but with a lot more easy memory management from the programmers point of
view).

Users don't want to have different GUIs (unless they are programmers)!
If they would like to help the chap at the terminal beside him he don't want
to learn a new GUI first.

PS. Dennis, singularis of moose in norwegian is Elg (as english elk).
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Apr  2 14:43:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25579; Fri, 2 Apr 93 14:43:25 +0200
Return-Path: <nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 2 Apr 93 14:43:25 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20507; Fri, 2 Apr 93 04:39:28 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id ab23982; 2 Apr 93 7:31 EST
Received: from louie.udel.edu by sol.cis.udel.edu id ab29880; 2 Apr 93 12:30 GMT
Received: from sol.cis.udel.edu by nori.cis.udel.edu id aa10518;
          2 Apr 93 12:30 GMT
To: moose-programmers@sfu.ca
Subject: Re: Class -> Object -> Thread 
Date: Fri, 02 Apr 93 07:29:52 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304021230.aa10518@nori.cis.udel.edu>
Status: OR

In Message <9304020340.970@mulga.cs.mu.OZ.AU> ,
   Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:

=>> [ Thus spake Gary D. Duzan ]
=>> 
=>>    How's this sound for a small idea? A chunk of code is a class,
=>> with no external interface except an initialization entry point.
=>> When an external entity initializes the class, it acquires passive
=>> state and sets up its interface, but is not (necessarily) active
=>> afterwards. When a method call is made, either internal or external
=>> to the object, the active method becomes a thread, including active
=>> state (registers, stack, etc).
=>
=>I don't understand what you're suggesting.

   That's ok, I'm not certain I do either. :-) I was just trying to
come up with a basic idea of how code, state, and execution can be
modeled in the system. In this model, for example, compiling and
linking would be seen as class generation, starting a server or other
process (where the initialization code may start a concurrent method
call to allow the object to remain active) would be seen as object
creation/initialization, and IPC/method calls (same thing) would be
seen as starting a thread in the object. If the calling thread is
blocked, then you can view this as the thread continuing in the other
object.
   My mention of IPC brings to mind the question of what to consider
a process. Historically, a process includes both active and passive
state, in a one-to-one relationship. My object model has no active
state itself, while several active states (threads) may operate
concurrently on the passive state. Thus, I would suggest that my
model would be better off if we don't try to force the notion of a
process onto it.

=>Agree!
=>Yes!
=>Yes!
=>Yes!
=>Yes!

   So do you agree with me, or what? :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dmarer@td2cad.intel.com Fri Apr  2 17:25:46 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28324; Fri, 2 Apr 93 17:25:44 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 2 Apr 93 17:25:44 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24252; Fri, 2 Apr 93 07:22:35 -0800
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Fri, 2 Apr 93 07:22:32 -0800
Received: by td2cad (5.57/10.0i); Fri, 2 Apr 93 07:26:30 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00223; Fri, 2 Apr 93 07:34:00 PDT
Date: Fri, 2 Apr 93 07:34:00 PDT
Message-Id: <9304021534.AA00223@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Definitions [dpm2]
Status: OR

Ok, let's define some terms:

    class      - Some conceptual notion of an object, describing its
                 interface, its attributes, its ancestors.

    instance   - An instance of a class, located at a particular address in
                 memory, containing a state which can be modified or has been
                 modified through its interface.

    object     - Used interchangeably to mean both of the above.  Generally,
                 when talking about an "object" the object's class is implied.

I feel just calling something an object is sufficient unless we really need
to differentiate between an object class and an instance of that class.  Is
this acceptable to everyone else?

Note: I've been working heavily on the chapter of the kernel involving
objects and the OOP nature of Moose.  As soon as this is finished I'll send
it around so we have the concept of an object ironed down.


> Is David

> As for "our mucketmockup", ok if this is "our"s, how do I see it?  Or
> should that have been "my mucketmockup"?

Oh, jeez.  Let's get technical now, shall we?

I'm trying to develop these things for the group as a whole -> "ours".  The
kernel specs and *the* mucketymockup will be ready for the rest of you to
peruse about the same time, as they're being developed concurrently.  One
represents the sum of our ideas in written form, the other represents a
sample implementation of these ideas.

(growl)

		Dennis

From dmarer@td2cad.intel.com Fri Apr  2 19:01:57 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29852; Fri, 2 Apr 93 19:01:56 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 2 Apr 93 19:01:56 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28568; Fri, 2 Apr 93 08:55:31 -0800
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Fri, 2 Apr 93 08:55:27 -0800
Received: by td2cad (5.57/10.0i); Fri, 2 Apr 93 08:59:24 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA00266; Fri, 2 Apr 93 09:06:56 PDT
Date: Fri, 2 Apr 93 09:06:56 PDT
Message-Id: <9304021706.AA00266@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: Pentium Info
Status: OR

Howdy all!

Just a quick note - I just shelled out $85 to buy the "Pentium Processor
3 Volume Set" from Intel (yes, I have to buy it too).  Maybe if we get
cracking we'll be the first out with a Pentium based operating system.
Now, does anyone want to shell out $10K for a system to test it on? C:{

I'll get it in about a week, so just holler if you want a full report.

				Dennis


From danodom@matt.ksu.ksu.edu Sat Apr  3 00:33:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04191; Sat, 3 Apr 93 00:33:28 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sat, 3 Apr 93 00:33:28 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25153; Fri, 2 Apr 93 14:29:31 -0800
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA06828; Fri, 2 Apr 93 16:31:07 CST
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304022231.AA06828@matt.ksu.ksu.edu>
Subject: Devices as processes (was Re: Organization) [dmp1] [djo1]
To: 
Date: Fri, 2 Apr 93 16:31:05 CST
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <2bbbd102.davgar@davgar.arlington.va.us>; from "David Garfield" at Apr 2, 93 12:36 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR


[Much stuff deleted]

> Can anyone think
> of any reason a device driver should be a process?

Yep: Maintenance.  If device breaks down :

1) Kill driver process
2) Physically disconnect device
3) Fix device
4) Physically reconnect device
5) Restart driver process

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

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

From danodom@matt.ksu.ksu.edu Sat Apr  3 00:56:16 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04271; Sat, 3 Apr 93 00:56:15 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sat, 3 Apr 93 00:56:15 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26966; Fri, 2 Apr 93 14:52:20 -0800
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA08746; Fri, 2 Apr 93 16:53:57 CST
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304022253.AA08746@matt.ksu.ksu.edu>
Subject: Re: Organization [djo0] [arf1]
To: moose-programmers@sfu.ca (Moose List)
Date: Fri, 2 Apr 93 16:53:56 CST
In-Reply-To: <MAILQUEUE-101.930402110650.352@sofus.dhhalden.no>; from "Andreas Arff" at Apr 2, 93 11:06 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of Andreas Arff came:
> 
> I am afraid that my first answer to you in over a month must be a critical
> one C:}.

That's fine; most people are critical of me :-)

[Stuff deleted]
> 
> Very good idea. I had thought of making moose available to the lower layers
> of the people (ie. non programmers C:} ). That would mean a standard
> interface, or at least standard functions for each interface item.
> As I have understod the UI filosofy there will be a GUI and a TUI. Of
> course you could build a GUI in a TUI if we made the graphics
> initialization commands public (as I suppose we'll do). But I don't think
> there should be 13 different GUIs, each with a different object structure.
> What we could do; Make some sort of dynamic gadget library, so you could
> add (or even change some of the existing) gadgets.

(TUI: Terrible user interface?  Torrid user interface?  Tumbling
underclothes from Ireland?)  Ich habe keine Ahnung was ein 'TUI' ist.
(I hope I got that right; anybody want to correct my German?)

I like the idea of a dynamic gadget library.  (I'll call them 'widgets'
in the future since that's the term I'm used to)

> What I think is important is to have a single GUI with a common UI, to
> simplifie the users life. Another question; is everybody prepared to put
> down the work needed to get a good UI? I think if we make 13 GUIs we'd
> have 13 bad GUIs, but if we made 1 (base) GUI we'd have 1 good gui!

I see what you're saying, but I don't want to make the UI part of the
system.  The Unix concept of a seperate shell is a good one, even
if it does make the user's life a little more difficult.  Transition
from sh to tcsh only took me about two weeks, so it's not too bad.

> The point of developing a GUI is not to make it entertaining; but to make it
> easy to work with. I'd rather prefer a GUI with quite a high learning
> threshold that has hundreds of shortcuts everywhere, than a true point and
> click GUI as mac and next.

Agreed!  I don't like having to take my hands off the keyboard all the time.

> If we wait with it til moose is finished it won't become an integrated part
> of the OS and that is pretty dumb I belive. Then we will have another windows
> (but with a lot more easy memory management from the programmers point of
> view).

Hmmm...  I don't want to force a UI on the user.  Keeping the shell
seperate from the kernel is good; that way, if you hate the supplied
one you can write your own.

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

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

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Sat Apr  3 02:50:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04718; Sat, 3 Apr 93 02:50:29 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Sat, 3 Apr 93 02:50:29 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05105; Fri, 2 Apr 93 16:47:25 -0800
Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA13829; Fri, 2 Apr 93 19:47:21 -0500
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 194627.4056; Fri, 2 Apr 1993 19:46:27 EST
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 02 Apr 1993 19:26:24 EST
Date:      Fri, 02 Apr 1993 19:26:19 EST
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bbcd9b1.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: Definitions [dpm2] [djg17]
Status: OR

Dennis wrote:
> Ok, let's define some terms:
>
>     class      - Some conceptual notion of an object, describing its
>                  interface, its attributes, its ancestors.
>
>     instance   - An instance of a class, located at a particular address in
>                  memory, containing a state which can be modified or has been
>                  modified through its interface.
>
>     object     - Used interchangeably to mean both of the above.  Generally,
>                  when talking about an "object" the object's class is implied.
>
> I feel just calling something an object is sufficient unless we really need
> to differentiate between an object class and an instance of that class.  Is
> this acceptable to everyone else?

I have always thought object was synonymous with instance, at least
when refering to something concrete.  I suppose others use of object
as a synonum for class may have confused me somewhat.  Maybe we should
stick with "class" and "instance", because these terms don't have
multiple possible meanings.
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From gumby.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sat Apr  3 20:02:38 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16075; Sat, 3 Apr 93 20:02:36 +0200
Return-Path: <gumby.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sat, 3 Apr 93 20:02:36 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26483; Sat, 3 Apr 93 09:58:49 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id aa03871; 3 Apr 93 12:55 EST
Received: from gumby.cis.udel.edu by sol.cis.udel.edu id aa15581;
          3 Apr 93 17:55 GMT
Received: from sol.cis.udel.edu by gumby.cis.udel.edu id aa14616;
          3 Apr 93 17:50 GMT
To: moose-programmers@sfu.ca
Subject: Re: Definitions [dpm2] [djg17] 
Date: Sat, 03 Apr 93 12:50:37 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304031750.aa14616@gumby.cis.udel.edu>
Status: OR

In Message <2bbcd9b1.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>> [ Dennis ]
=>>
=>> I feel just calling something an object is sufficient unless we really need
=>> to differentiate between an object class and an instance of that class.  Is
=>> this acceptable to everyone else?
=>
=>I have always thought object was synonymous with instance, at least
=>when refering to something concrete.  I suppose others use of object
=>as a synonum for class may have confused me somewhat.  Maybe we should
=>stick with "class" and "instance", because these terms don't have
=>multiple possible meanings.

   A Class is basically a data type with methods defining the
semantics of its interface. An object is an instance of a class, with
code and address space. I believe these are fairly basic, standard
concepts, and I don't think it would do much good to redefine them.
For reference, I looked up an article in the September, 1990 issue
of Communications of the ACM, entitled "Understanding Object-Oriented:
A Unifying Paradigm". The whole issue is dedicated to Object-Oriented
design, and I would encourage everyone here to look it over, as I plan
to do. At least then we will have some solid definitions to start
with instead of the marketing drivel that the software industry has
been spewing out lately. On the other side, the November, 1992 issue
of CACM has in interesting article entitled "What Orientation should
Ada Objects Take?", which might help explain some of the realities of
the Object-Oriented Paradigm.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sun Apr  4 16:43:10 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28232; Sun, 4 Apr 93 16:43:08 +0200
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sun, 4 Apr 93 16:43:08 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19129; Sun, 4 Apr 93 07:41:12 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa12526; 4 Apr 93 10:34 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa26550; 4 Apr 93 14:31 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa10377;
          4 Apr 93 14:29 GMT
To: Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au>
Cc: moose-programmers@sfu.ca
Subject: Re: Class -> Object -> Thread 
Date: Sun, 04 Apr 93 10:29:18 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304041429.aa10377@bifur.cis.udel.edu>
Status: OR

In Message <9304041128.27854@mulga.cs.mu.OZ.AU> ,
   Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:

=>Is it important that compilin g/linking have nice semantics?
=>I feel it ios more important to have a nice clean semantics for the OS
=>interface that a program sees rather then working compiling into
=>the object framework.

   Quite true. I wasn't actually thinking of compiling semantics
at the time; I just wanted to clarify what I meant a class to be.
The compiler can just be an object which takes the source code as
an input, and returns a new class. Semantically, this isn't too
different than compilers in other systems, and shouldn't take too
much modification to implement.

=>-- I see simplicity as more important then objects -- a complex
=>OO system willIMHO be a failure.

   But if we can make a simple, efficient object based system, we
will probably be better off than making an ad hoc design. Building
a special inheritance mechanism for MOOSE objects may not be
necessary or desirable, but we should have separate objects
accessing each other concurrently via a method call mechanism as
the central concept behind the system. We can always emulate
inheritance at the language level (though it may be a good idea to
maintain an object library object to assist the linker with binding
(early binding directly, or late binding, via stubs.)) A base
object is little different than any other object, after all.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Sun Apr  4 13:16:20 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27412; Sun, 4 Apr 93 13:16:19 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sun, 4 Apr 93 13:16:19 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18204; Sun, 4 Apr 93 04:13:59 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA27584
	Sun, 4 Apr 1993 21:13:48 +1000 (from winikoff)
Message-Id: <9304041113.27584@mulga.cs.mu.OZ.AU>
Subject: User Interfaces
To: moose-programmers@sfu.ca (Moose Project)
Date: Sun, 4 Apr 93 21:13:47 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <MAILQUEUE-101.930402110650.352@sofus.dhhalden.no>; from "Andreas Arff" at Apr 2, 93 11:06 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

There's a paper I once read talking about how a GUI should be usable 
rather then fancy.

It was by Rob Pike and is available for ftp from research.att.com (I think)(
in the plan9 doc directory.
I think it was number 12 or so.

-- You should get hold of a copy. If you don't have access to ftp
give a yell and I'll ftp and mail you a copy.

Michael


From winikoff@cs.mu.OZ.AU Mon Apr  5 06:07:04 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08085; Mon, 5 Apr 93 06:07:03 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 5 Apr 93 06:07:03 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06210; Sun, 4 Apr 93 21:04:31 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA19711
	Mon, 5 Apr 1993 14:04:23 +1000 (from winikoff)
Message-Id: <9304050404.19711@mulga.cs.mu.OZ.AU>
Subject: Re: Definitions [dpm2]
To: moose-programmers@sfu.ca (Moose Project)
Date: Mon, 5 Apr 93 14:04:22 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9304021534.AA00223@tdge15.intel.com>; from "Dennis Marer" at Apr 2, 93 7:34 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> Ok, let's define some terms:
> 
>     class      - Some conceptual notion of an object, describing its
>                  interface, its attributes, its ancestors.
> 
>     instance   - An instance of a class, located at a particular address in

An instance is defined to be an instance -- talk about circular definitions ...
:-)

>                  memory, containing a state which can be modified or has been
>                  modified through its interface.
> 
>     object     - Used interchangeably to mean both of the above.  Generally,
>                  when talking about an "object" the object's class is implied.

These definitions are circular -- if I wasn't sure what exactly an object was
(which is the case) these defns don't help -- a class is a conceptual object,
an instance is a class instance, an object is one of the above ... 

Yes, I do get the notions of interface attributes and ancestors coming out but
these aren't clearly defined.

Sorry to be picky but I feel that objects are the ONE concept that we HAVE to 
have a good solid definition of -- BTW many other publications are also
extremely wishy washy on this subject -- one of the main reasons I dislike
OO hype ...

Michael

From dmarer@td2cad.intel.com Thu Apr  8 01:16:14 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09315; Thu, 8 Apr 93 01:16:13 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Thu, 8 Apr 93 01:16:13 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11806; Wed, 7 Apr 93 16:12:37 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Wed, 7 Apr 93 16:09:06 -0700
Received: by td2cad (5.57/10.0i); Wed, 7 Apr 93 13:52:10 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA02352; Wed, 7 Apr 93 13:47:34 PDT
Message-Id: <9304072047.AA02352@iws804.intel.com>
Subject: Hello?
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Wed, 7 Apr 93 13:47:31 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Hello?

Is it just me, or have I received zero replies from my last message?

In fact, I haven't heard anything in a week from anybody...are you there?

Argh...


			Dennis

From danodom@matt.ksu.ksu.edu Thu Apr  8 04:42:58 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA11870; Thu, 8 Apr 93 04:42:55 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Thu, 8 Apr 93 04:42:55 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA00321; Wed, 7 Apr 93 19:39:54 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA18648; Wed, 7 Apr 93 21:33:43 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304080233.AA18648@matt.ksu.ksu.edu>
Subject: Re: Hello?
To: dmarer@iws804.intel.com (Dennis Marer)
Date: Wed, 7 Apr 93 21:33:43 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <9304072047.AA02352@iws804.intel.com>; from "Dennis Marer" at Apr 7, 93 1:47 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of Dennis Marer came:
> 
> Hello?

Hi Dennis!

> Is it just me, or have I received zero replies from my last message?

It's just you; the list has been teeming with activity.  We've almost
got the kernel complete, and a C++ compiler is on the way.  We've
been wondering where you are...

> In fact, I haven't heard anything in a week from anybody...are you there?

If you want to know the honest truth, we were all kidnapped by hostile
Elvis-shaped aliens from the planet Cruton.  They took us to their
Cosmic Experiment Station where we were forced to write a 386 PM
kernel using only a 386, a car battery, 256k of memory, and a bent paperclip.
I _think_ somebody saved a copy of the source...

BTW, if a guy named Zorg asks to join the project, say no.  He's a
lousy programmer; 5 to 1 he winds up at IBM :-)

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

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

From winikoff@cs.mu.OZ.AU Thu Apr  8 03:21:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10871; Thu, 8 Apr 93 03:21:22 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 8 Apr 93 03:21:22 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18697; Wed, 7 Apr 93 18:18:30 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA17446
	Thu, 8 Apr 1993 11:18:15 +1000 (from winikoff)
Message-Id: <9304080118.17446@mulga.cs.mu.OZ.AU>
Subject: Re: Hello?
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 8 Apr 93 11:18:14 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9304072047.AA02352@iws804.intel.com>; from "Dennis Marer" at Apr 7, 93 1:47 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> Hello?
> 
> Is it just me, or have I received zero replies from my last message?
> 
> In fact, I haven't heard anything in a week from anybody...are you there?

Yes. I was actually wondering where everyone had gone ...

> 
> Argh...
> 
> 
> 			Dennis
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Thu Apr  8 13:24:18 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25473; Thu, 8 Apr 93 13:24:17 +0200
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Thu, 8 Apr 93 13:24:17 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14170; Thu, 8 Apr 93 04:21:24 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa20393; 8 Apr 93 7:16 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa27184; 8 Apr 93 11:14 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa19595;
          8 Apr 93 11:14 GMT
To: Dennis Marer <dmarer@td2cad.intel.com>
Cc: Moose Kernel Project <moose-programmers@sfu.ca>
Subject: Re: Hello? 
Date: Thu, 08 Apr 93 07:13:46 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304081114.aa19595@gloin.cis.udel.edu>
Status: OR

In Message <9304072047.AA02352@iws804.intel.com> ,
   Dennis Marer <dmarer@iws804.intel.com> wrote:

=>Hello?
=>
=>Is it just me, or have I received zero replies from my last message?
=>
=>In fact, I haven't heard anything in a week from anybody...are you there?

   I'm rather busy this week, and I want to have a chance to look
over those articles I said I was going to read. Are you referring
to your "Pentium Info" or "Definitions" article? I've seen some
responses to the latter, and I think persuing the former may be a
bit premature. If you've sent out a message since then, I haven't
received it.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dmarer@td2cad.intel.com Thu Apr  8 19:53:08 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04526; Thu, 8 Apr 93 19:53:07 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Thu, 8 Apr 93 19:53:07 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA29998; Thu, 8 Apr 93 10:50:03 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Thu, 8 Apr 93 10:49:24 -0700
Received: by td2cad (5.57/10.0i); Thu, 8 Apr 93 10:53:20 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA03429; Thu, 8 Apr 93 10:48:50 PDT
Message-Id: <9304081748.AA03429@iws804.intel.com>
Subject: Pthhbbbt.
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Thu, 8 Apr 93 10:48:47 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Sorry, the subject should be "Pthbbbt [dpm4]". :-)

Glad to hear you're all still out there - we just got new workstations here at
work (486DX2s) so I wasn't sure if I was receiving outside mail or not.  Whew!


Forgive if I'm in an odd mood today - I've been feeling something is missing
from this project, and I've figured out what it is!

I sat down the other day and tried to figure out why I was working on Moose -
my motivations, and why I want to see it succeed.  I came up with a good long
list for myself...now I'm intersted from you:

1. Why are you working on Moose?  (Be detailed!)

2. What are your intentions?  (Technical knowledge/just for fun/fame/fortune/
	fast women/famous fortunate fast women?)

3. When all is said and done, what do you want to say you have accomplished?


Next, I began thinking about requirements - general things, like "Moose should
be easy to port to other systems".  Or even, "Moose needs to be smaller than
Windows NT".  Of course, some of these will be easy to accomplish... ;-)

What I'm doing is putting together a small document to try and capture the
purpose of our group - the whos, whats, whens, wheres, and whys of our
existence.  I think its something we should have done a long time ago, but
better late than never.  Sure, we've all been working towards a common goal,
but can any of you tell me what that goal is?

-------------------------------------------------------------------------------

On the technical end...

No, I don't think we should be thinking about the Pentium yet - I was just
offering the info if anyone is interested.  One thing we shouldn't ignore when
implementing our system is that there are very few instruction differences
between the 386, 486, and the Pentium processor.  Intstruction *ordering* is
the key in the Pentium, where code can be optimized by rearranging the
order instructions are executed.  Simple instructions can operate in parallel
with each other, complex instructions cannot - in many cases, execution time
can be cut nearly in half!

Just a guess: The P6 will do instruction ordering optimization on the fly. :-)

				Dennis


From dmarer@td2cad.intel.com Fri Apr  2 03:36:48 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12550; Fri, 2 Apr 93 03:36:47 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 2 Apr 93 03:36:47 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA01188; Thu, 1 Apr 93 17:26:44 -0800
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Thu, 1 Apr 93 17:26:03 -0800
Received: by td2cad (5.57/10.0i); Thu, 1 Apr 93 17:29:48 -0800
From: dmarer@td2cad.intel.com (Dennis Marer)
Received: by tdge15.intel.com (5.51/ICES-Networking)
	id AA01074; Thu, 1 Apr 93 17:37:31 PDT
Date: Thu, 1 Apr 93 17:37:31 PDT
Message-Id: <9304020137.AA01074@tdge15.intel.com>
To: moose-programmers@sfu.ca
Subject: New Intel Chip Released
Status: OR


INTEL ANNOUNCES NEW PROCESSOR FOR TRULY PERSONAL COMPUTING
1 April 1993

Intel Corp. today announced a new line of low-power high performance
microprocessors for a entirely new concept in "personal" computing. The
new processors, codenamed "Rectium", are designed to actually fit the
appropriate body cavity for "Computing Anywhere, Anytime", according to
Fred Burfl, Vice President for New Product Locations at Intel. "We
figured that with our 'Intel Inside' advertising campaign, which has
high consumer awareness, we couldn't lose!".

Within six months, a high-performance co-processor will also be made
available.  Implemented in Gallium Arsenide technology, the co-processor
is tentatively code-named "Rectium GaAs".  A new high-speed communications
bus based on a proprietary "Fast Aerodynamic Regional Transport" protocol
will take performance to new heights.

Intel officials suggest that the chips will be ideally suited for
back-end processing applications.


Reaction on Wall Street was mixed.  PepsiCo (owner of the Taco Bell
restaurant chain) gained an eighth, to close at 82 7/8, after announcing
a strong commitment to the new GaAs technology.  Ralston-Purina (maker
of Bean-o) fell an eighth, to 50 5/8.



From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Apr  2 05:04:12 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13741; Fri, 2 Apr 93 05:04:11 +0200
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 2 Apr 93 05:04:11 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05277; Thu, 1 Apr 93 18:58:58 -0800
Received: from sol.cis.udel.edu by louie.udel.edu id ab19646; 1 Apr 93 21:44 EST
Received: from louie.udel.edu by sol.cis.udel.edu id ab21019; 2 Apr 93 2:39 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa29799;
          2 Apr 93 2:39 GMT
To: moose-programmers@sfu.ca
Subject: Re: New Intel Chip Released 
Date: Thu, 01 Apr 93 21:39:17 -0500
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304020239.aa29799@bifur.cis.udel.edu>
Status: OR

In Message <9304020137.AA01074@tdge15.intel.com> ,
   Dennis Marer <dmarer@td2cad.intel.com> wrote:

=> [ article deleted ]

On a related note, from rec.humor.funny...

Date: Mon, 29 Mar 93 4:30:02 EST
Newsgroups: rec.humor.funny
From: rjg@umnstat.stat.umn.edu (Robert J. Granvin)
Subject: Sublimation
Keywords: chuckle, science

Some time  ago, I was taking a ground school class for private pilots.
During the sessions on weather, the instructor wanted to discuss the concept
of sublimation - the act of going from a gas to a solid skipping the
intermediate stage(s).  e.g., frost - water vapor in the air becoming a 
solid on surfaces without first going through the liquid stage.

Wanting to see if the class had understood the concept, the instructor asked
if anyone could provide an example of something that went straight from a
solid to a gas (expecting "dry ice" as the answer), a previously unknown
section of my mind took control of my mouth and immediately emitted the word
"burrito."

It took the instructor about 10 minutes to regain an academic composure.

--
Selected by Maddi Hausmann.  MAIL your joke (jokes ONLY) to funny@clarinet.com.

If you mail to original@clarinet.com, it makes sure that your joke is tagged
as your original work, and thus eligible for the RHF comedy awards.   Always
attribute the source of a joke, whether it's you, or somebody else.



From UKCC.UKY.EDU!WKUVX1.BITNET!haydedr Fri Apr  9 05:08:52 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA02875; Fri, 9 Apr 93 05:08:52 +0200
Return-Path: <UKCC.UKY.EDU!WKUVX1.BITNET!haydedr>
Received-Date: Fri, 9 Apr 93 05:08:52 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from ukcc.uky.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05805; Thu, 8 Apr 93 19:57:04 -0700
Received: from UKCC.UKY.EDU by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 2771; Thu, 08 Apr 93 22:56:45 EDT
Received: from WKUVX1.BITNET (NJE origin MXMAILER@WKUVX1) by UKCC.UKY.EDU
 (LMail V1.1d/1.7f) with BSMTP id 0473; Thu, 8 Apr 1993 22:56:42 -0400
Received: by WKUVX1.BITNET (MX V3.3 VAX) id 16658; Thu, 08 Apr 1993 21:58:31 CDT
Date: Thu, 08 Apr 1993 21:58:29 CDT
From: "Dr. Hayden" <haydedr@WKUVX1.BITNET>
To: moose-programmers@sfu.ca
Message-Id: <0096ABE1.678D4060.16658@WKUVX1.BITNET>
Subject: Re: Pthhbbbt.
Status: OR

Dennis Marer <dmarer@iws804.intel.com> writes:

<snip...>

>1. Why are you working on Moose?  (Be detailed!)
>
>2. What are your intentions?  (Technical knowledge/just for fun/fame/fortune/
>       fast women/famous fortunate fast women?)
>
>3. When all is said and done, what do you want to say you have accomplished?
>

I'm working on this project purely for the fun and for the challenge.
And, it seems I've already learned quite a lot about object oriented
design.  I enjoy the unique experience of participating in a project
of this scale by email.

When all is said and done, all I want is to be able to say, "Yeah, I
wrote an operating system." :-)  But really, no matter the success of
Moose as a product, I'd like to be able to say I had fun learning
(having a working, successful product would be nice too).

>
>Next, I began thinking about requirements - general things, like "Moose should
>be easy to port to other systems".  Or even, "Moose needs to be smaller than
>Windows NT".  Of course, some of these will be easy to accomplish... ;-)

Smaller than NT?  Now I know we said no more than 25% of total system
resources, but COME ON NOW!!  And I also really really really wish we
could make Moose look *JUST LIKE* Windows, too.  d;-)  (I'm sporting
my new baseball cap in this smiley).

<snip...>

>No, I don't think we should be thinking about the Pentium yet - I was just
>offering the info if anyone is interested.  One thing we shouldn't ignore

Yeah, but I sure would love to get my hands on that set of manuals you
bought; unfortunately, though, I currently have a bad case of broke.

<snip...>

>Just a guess: The P6 will do instruction ordering optimization on the fly. :-)
>
>                               Dennis

But of course, when the P6 comes out, Moose will by then do
instruction ordering optimization _much better_ than anyone else :-)

Later,
Ross

From danodom@matt.ksu.ksu.edu Fri Apr  9 05:56:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08616; Fri, 9 Apr 93 05:56:52 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Fri, 9 Apr 93 05:56:52 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07303; Thu, 8 Apr 93 20:51:23 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA11074; Thu, 8 Apr 93 22:53:02 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304090353.AA11074@matt.ksu.ksu.edu>
Subject: Re: Pthhbbbt.
To: ksuvm.ksu.EDU!WKUVX1.BITNET!haydedr (Dr. Hayden)
Date: Thu, 8 Apr 93 22:53:01 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <0096ABE1.678D4060.16658@WKUVX1.BITNET>; from "Dr. Hayden" at Apr 8, 93 9:58 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of Dr. Hayden came:

> Smaller than NT?  Now I know we said no more than 25% of total system
> resources, but COME ON NOW!!  And I also really really really wish we
> could make Moose look *JUST LIKE* Windows, too.  d;-)  (I'm sporting
> my new baseball cap in this smiley).

Geez, you mean we have to try to fit this sucker in to less than 16 megs
(I'm talking about just the kernel, of course.  No sane person could
be expected to fit devices in a mere 16 megs)?  Next you'll be telling
me that it has to fit in less than 3.5 gigabytes of hard disk space.  You
know, my art just can't be restricted by minor issues like system
resources.

And, yes, I agree that we should try to make it look just like Windows.
MS-Win has the __GREATEST__ user interface ever devised, and besides,
if the all-knowing Microsoft uses it, it _has_ to be good.  The
way those buttons go down when you push them just makes me giggle,
and the ability to put nude women up as wallpaper represents
a real innovation!

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

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

From csjjlay@knuth.mtsu.edu Fri Apr  9 05:57:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08640; Fri, 9 Apr 93 05:57:33 +0200
Return-Path: <csjjlay@knuth.mtsu.edu>
Received-Date: Fri, 9 Apr 93 05:57:33 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from knuth.mtsu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07317; Thu, 8 Apr 93 20:52:00 -0700
Received: by knuth.mtsu.edu (Smail3.1.28.1 #8)
	id m0nhA9N-000d3zC; Thu, 8 Apr 93 22:53 CDT
Message-Id: <m0nhA9N-000d3zC@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: MUSIC Specs Notice [jjl0]
To: moose-programmers@sfu.ca
Date: Thu, 8 Apr 1993 22:53:06 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1863      
Status: OR

Greetings!
Having been silent lately on the group, I think it is time to make my
contribution to the effort.  My chief interests are the User Interface
and Programming Languages.  Next Friday I shall release a quite
voluminous recommendation on the User Interface.  What I want right now
is your input: what do you want in the user interface?  My key
assumption and design goal is complete modularity.  Any part of the User
Interface can be replaced by some different but equivalent part thus
resulting in a completely customizable interface.  Please not: my
Interface Spec is not for a GUI or for a Text Only Interface.  It will
incorporate ideas that will easily be coded into the both. 

My second major contribution (I hope) will be a recommendation for a new
programming language.  This language will be Object-Oriented and based
on 4GL principles.  It WILL cut down code size and development time.
Period.  At first it will be a struggle to hammer out details and exact
specifics.

Those who are interested in either or both of the topics please let me
know.  There was a list posted, but I have seem to have forgot which
folder its in :-(  That's the problem with so much traffic!  But it
shows we are really trying to accomplish something...

							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"Marriage is a noble institution...  If you want to be institutionalized
the rest of your life!" -Dr. Paul Hutcheson, MTSU Computer Science Dept

From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Apr  9 15:33:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17412; Fri, 9 Apr 93 15:33:33 +0200
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 9 Apr 93 15:33:33 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17519; Fri, 9 Apr 93 06:22:40 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa12411; 9 Apr 93 9:16 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa17582; 9 Apr 93 13:15 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa26038;
          9 Apr 93 13:11 GMT
To: Dennis Marer <dmarer@iws804.intel.com>
Cc: Moose Kernel Project <moose-programmers@sfu.ca>
Subject: Re: Pthhbbbt. 
Date: Fri, 09 Apr 93 09:10:50 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304091311.aa26038@gloin.cis.udel.edu>
Status: OR

In Message <9304081748.AA03429@iws804.intel.com> ,
   Dennis Marer <dmarer@iws804.intel.com> wrote:

=>1. Why are you working on Moose?  (Be detailed!)
=>
=>2. What are your intentions?  (Technical knowledge/just for fun/fame/fortune/
=>	fast women/famous fortunate fast women?)
=>
=>3. When all is said and done, what do you want to say you have accomplished?

   I am working on MOOSE primarily for the experience of putting
together an advanced, useful, portable system. I keep learning all
this stuff about operating systems, but I haven't really gotten a
chance to put any of it to use. I'll even be taking a 10 day course
in Vancouver, BC this summer on Distributed Systems. I'd like to have
a system I know inside and out to eventually expand into a
distributed operating system. I'd also like to see someone actually
use it, though I don't know how likely that is. For that we need
applications, and that is a whole other project. To help with this
goal, we should try as much as possible to make the programmer's job
fairly easy. There is also the issue of stability. People aren't
going to want to use an unstable system.  Then, once we have a
working system, we can put together an applications group called
SQUIRREL. :-)  Or LYRICS? :-)  I also enjoy being able to contribute
to the free software archives.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From rideau@clipper Sat Apr 10 03:06:56 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27241; Sat, 10 Apr 93 03:06:55 +0200
Return-Path: <rideau@clipper>
Received-Date: Sat, 10 Apr 93 03:06:55 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09125; Fri, 9 Apr 93 18:01:21 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304100100.AA27204@clipper.ens.fr>
Subject: Re: Pthhbbbt.
To: dmarer@iws804.intel.com (Dennis Marer)
Date: Sat, 10 Apr 93 3:00:44 MET DST
Cc: moose-programmers@sfu.ca
In-Reply-To: <9304081748.AA03429@iws804.intel.com>; from "Dennis Marer" at Apr 8, 93 10:48 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR


>> I sat down the other day and tried to figure out why I was working on Moose -
>> my motivations, and why I want to see it succeed.  I came up with a good long
>> list for myself...now I'm intersted from you:
>> 
>> 1. Why are you working on Moose?  (Be detailed!)
'cause 'tis I want to realize my old System project - a system where anybody
could add his own features add have them fit perfectly in any application,
without having to rewrite the whole app to add his module, or wait for big
companies to add a similar module to the app's next version - a system
where anything once done wouldn't have to be ever rewritten/adapted again
(except for real enhancement).

>> 2. What are your intentions?  (Technical knowledge/just for fun/fame/fortune/
>> 	fast women/famous fortunate fast women?)
having a system where I really can work, i.e. not do things I will have to
begin again and again every time. Then I can concentrate on what I like:
music, a system game, artificial intelligence.

>> 3. When all is said and done, what do you want to say you have accomplished?
My sheriff's duty c|:-( *

>> Next, I began thinking about requirements - general things, like "Moose should
>> be easy to port to other systems".  Or even, "Moose needs to be smaller than
>> Windows NT".  Of course, some of these will be easy to accomplish... ;-)
 I've already defined the main requirements: finish with user/programmer
barrier which make computers unusable, and allow systemwise generic modular
programming.
 Being portable to other AND FUTURE platforms will be achieved
by ending the previous/current unportable/stupid/limitating existing
connection between high-level programming and its implementation; by
disconnecting the two (i.e. allowing the user and/or compiler to freely
choose each HLL implementation, and work with HL objects independently of
(possibly simultaneously different) implementations; NOT forbidding one
to communicate with the other: you CAN bind an (lower or higher level) impl'
but you WON'T HAVE TO when its not necessary/harmful).
 Being smaller than NT will be achieved by not writing bullshit, not filling
files with zeros, compressing data rather than expanding it, not having to
maintain compatibility with previous software, eliminating code/data
redundancy through standardness of common modules and allowing genericity in
high-level definitions.

>> What I'm doing is putting together a small document to try and capture the
>> purpose of our group - the whos, whats, whens, wheres, and whys of our
>> existence.  I think its something we should have done a long time ago, but
>> better late than never.  Sure, we've all been working towards a common goal,
>> but can any of you tell me what that goal is?
The goal is what lies at the end of it all. Well, I think no one is ever
sure of what the others mean, all the more if we communicate only by e-mail,
which sure is slowly read. The best would have been physical meetings;
perhaps we can have an Y-Talk one day. For those (like you, Dennis) who
don't have talk capabilities, I can lend you my account, or an unused account
on my computer whom password I know.
 So, when can we (=part or totality of the group) have a talking party
together. I can be free at any hour (provided I am forewarned). So please
mail me your Talk-ative time (please give also GMT).

>> -------------------------------------------------------------------------------
>> 
>> On the technical end...
>> 
>> No, I don't think we should be thinking about the Pentium yet - I was just
>> offering the info if anyone is interested.  One thing we shouldn't ignore when
>> implementing our system is that there are very few instruction differences
>> between the 386, 486, and the Pentium processor.  Intstruction *ordering* is
>> the key in the Pentium, where code can be optimized by rearranging the
>> order instructions are executed.  Simple instructions can operate in parallel
>> with each other, complex instructions cannot - in many cases, execution time
>> can be cut nearly in half!
>> 
>> Just a guess: The P6 will do instruction ordering optimization on the fly. :-)
>> 
>> 				Dennis
I was rather thinking about designing an OO chip, or putting in parallel
cheap FORTH units (as they are just very simple, one could have 4,8,16 of
them on a single chip, and/or give memory and IO on the same chip as the cpu;
this would be far more powerful and/or cheaper than any other equivalent
cpu based system; but the whole system is to be written)

   ,
Fare


From cis.udel.edu!udel.edu!duzan Sat Apr 10 18:47:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09822; Sat, 10 Apr 93 18:47:27 +0200
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Sat, 10 Apr 93 18:47:27 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21324; Sat, 10 Apr 93 09:44:23 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ai06561;
          10 Apr 93 12:40 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa05060;
          10 Apr 93 16:10 GMT
Received: from sol.cis.udel.edu by mercury.cis.udel.edu id aa04374;
          10 Apr 93 16:07 GMT
To: Moose Project <moose-programmers@sfu.ca>
Subject: Re: Pthhbbbt. 
Date: Sat, 10 Apr 93 12:06:54 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304101607.aa04374@mercury.cis.udel.edu>
Status: OR

In Message <9304101305.17321@mulga.cs.mu.OZ.AU> ,
   Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:

=>Actually that's something I don't understand -- why are they no shared memory
 
=>multiple CPU workstations?
=>Sure, programming them may be a hassle if you do it in C.
=>If you use something like Parlog, Concurrent Prolog or a parallel implementat
ion
=>of a functional language then you can get good speed up for say 4 processors.

   I see two issues cost/benefit and parallel programming. There are
additional costs involved in designing a bus, memory, etc. to support
a parallel machine, not not mention the cost of the extra CPUs, and
taking advantage of the benefits generally requires rethinking and
reimplementing programs to use the available parallelism. The natural
decision given these issues would be to look into a faster single CPU
instead. If we ever get an optical computer design, this trend will
likely continue even further into the future. At some point, however,
I imagine that parallel processing will make it into the mainstream.
Also, there seems to be a serious lack of training in parallel
programming, so developing parallel software would likely be more
costly.
   I may be mistaken, but I believe Sun may actually be making a
2-CPU Sparcstation 10 desktop machine. Also, superpipelined and
superscalar CPU designs take advantage of some instruction-level
parallelism.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From danodom@matt.ksu.ksu.edu Sat Apr 10 20:00:28 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10182; Sat, 10 Apr 93 20:00:26 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sat, 10 Apr 93 20:00:26 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22823; Sat, 10 Apr 93 10:56:34 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA29351; Sat, 10 Apr 93 12:58:19 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304101758.AA29351@matt.ksu.ksu.edu>
Subject: Re: Pthhbbbt.
To: moose-programmers@sfu.ca (Moose List)
Date: Sat, 10 Apr 93 12:58:18 CDT
In-Reply-To: <9304101305.17321@mulga.cs.mu.OZ.AU>; from "Michael David WINIKOFF" at Apr 10, 93 11:05 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of Michael David WINIKOFF came:

> >  So, when can we (=part or totality of the group) have a talking party
> > together. I can be free at any hour (provided I am forewarned). So please
> > mail me your Talk-ative time (please give also GMT).

Pretty much any time, but preferably at night or on weekends.  My 'prime
programming time' is from about 18:00 until 03:00, United States C.S.T.
(Is that redundant?).  That is when I am most available.

Maybe we should get together on the net on a Saturday (western hemisphere;
Sunday in Australia, I think) sometme and talk for 2 or 3 hours.  Maybe
an irc channel?

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

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

From winikoff@cs.mu.OZ.AU Sat Apr 10 15:08:38 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08426; Sat, 10 Apr 93 15:08:37 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 10 Apr 93 15:08:37 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18683; Sat, 10 Apr 93 06:05:17 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA17321
	Sat, 10 Apr 1993 23:05:08 +1000 (from winikoff)
Message-Id: <9304101305.17321@mulga.cs.mu.OZ.AU>
Subject: Re: Pthhbbbt.
To: moose-programmers@sfu.ca (Moose Project)
Date: Sat, 10 Apr 93 23:05:08 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9304100100.AA27204@clipper.ens.fr>; from "Francois-Rene Rideau" at Apr 10, 93 3:00 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> The goal is what lies at the end of it all. Well, I think no one is ever
> sure of what the others mean, all the more if we communicate only by e-mail,
> which sure is slowly read. The best would have been physical meetings;
> perhaps we can have an Y-Talk one day. For those (like you, Dennis) who
> don't have talk capabilities, I can lend you my account, or an unused account
> on my computer whom password I know.
>  So, when can we (=part or totality of the group) have a talking party
> together. I can be free at any hour (provided I am forewarned). So please
> mail me your Talk-ative time (please give also GMT).

I don't tend to have a consistent talking time.
If you want to organise something give a yell.

We will have problems with different time zones though ... :-)

> I was rather thinking about designing an OO chip, or putting in parallel
> cheap FORTH units (as they are just very simple, one could have 4,8,16 of
> them on a single chip, and/or give memory and IO on the same chip as the cpu;
> this would be far more powerful and/or cheaper than any other equivalent
> cpu based system; but the whole system is to be written)
> 
>    ,
> Fare

Actually that's something I don't understand -- why are they no shared memory 
multiple CPU workstations?
Sure, programming them may be a hassle if you do it in C.
If you use something like Parlog, Concurrent Prolog or a parallel implementation
of a functional language then you can get good speed up for say 4 processors.


> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Sat Apr 10 15:10:48 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08454; Sat, 10 Apr 93 15:10:47 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 10 Apr 93 15:10:47 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18697; Sat, 10 Apr 93 06:07:37 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA17342
	Sat, 10 Apr 1993 23:07:26 +1000 (from winikoff)
Message-Id: <9304101307.17342@mulga.cs.mu.OZ.AU>
Subject: Why MOOSE?
To: moose-programmers@sfu.ca (Moose Project)
Date: Sat, 10 Apr 93 23:07:25 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

Hi!
Why am I involved in MOOSE?

Firstly to learn -- I am interested in OSes and would like to have the 
experiance of designing one. The implementation will undoubtfully be educational
but to me thats secondary.

I would like to see a SIMPLE MINIMAL OS that people can use without constant
refference to 5 inch manuals.


I feel that if we have a system where it is very easy to develop applications
and which is extendible then it will succeed given a reasonable marketting.
(And given that it is cheap :-)

Michael


From winikoff@cs.mu.OZ.AU Sat Apr 10 16:25:17 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09017; Sat, 10 Apr 93 16:25:16 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 10 Apr 93 16:25:16 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19322; Sat, 10 Apr 93 07:22:09 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA18153
	Sun, 11 Apr 1993 00:22:03 +1000 (from winikoff)
Message-Id: <9304101422.18153@mulga.cs.mu.OZ.AU>
Subject: Some references
To: moose-programmers@sfu.ca (Moose Project)
Date: Sun, 11 Apr 93 0:22:02 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

[Sorry if you go this .. just being certain]

Some references:

operating System Review July 1990
	A regular architecture for operating system
	Vadim G Antonov

	-- Deals with an OO OS

For GUI Have a look at:
[these have some really great ideas]


--------- CUT HERE ------------
Technical reports from the Centre for Mathematics and
Computer Science (CWI) in Amsterdam are now available
by anonymous ftp from ftp.cwi.nl [192.16.184.180].

Directory /pub/CWIreports contains a general index
to all CWI reports. Subdirectories contain the actual reports
(in compressed PostScript) classified under the name of the CWI 
department.

Current contents (2 april) are listed below. More files will be 
added soon.

Please read the README file in /pub/CWIreports for further 
information.


Happy reading,

-- Robert van Liere

CS-R9257
S. Pemberton.
"The Views application environment."

CS-R9258
L.G.L.T. Meertens, and S. Pemberton.
"The ergonomics of computer interfaces. Designing a system 
	for human use."

CS-R9259
S. Pemberton.
"Programming aspects of Views. An open-architecture 
	application environment."

CS-R9260
L.G. Barfield.
"Graphics in the Views system."

CS-R9261
E.D.G. Boeve.
"Modelling interaction tools in the Views architecture."

CS-R9262
J. Ganzevoort.
"Maintaining presentation invariants in the Views system."

CS-R9263
M. Bordegoni.
"Multimedia in Views."


From rideau@clipper Mon Apr 12 00:32:40 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00315; Mon, 12 Apr 93 00:32:39 +0200
Return-Path: <rideau@clipper>
Received-Date: Mon, 12 Apr 93 00:32:39 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA23878; Sun, 11 Apr 93 15:30:15 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304112229.AA00295@clipper.ens.fr>
Subject: Talk
To: danodom@matt.ksu.ksu.edu (Dan Odom)
Date: Mon, 12 Apr 93 0:29:42 MET DST
Cc: moose-programmers@sfu.ca
In-Reply-To: <9304101758.AA29351@matt.ksu.ksu.edu>; from "Dan Odom" at Apr 10, 93 12:58 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>>>>  So, when can we (=part or totality of the group) have a talking party
>>>> together. I can be free at any hour (provided I am forewarned). So please
>>>> mail me your Talk-ative time (please give also GMT).

>> Pretty much any time, but preferably at night or on weekends.  My 'prime
>> programming time' is from about 18:00 until 03:00, United States C.S.T.
>> (Is that redundant?).  That is when I am most available.

Well, the USA is a wide country, so that NY time isn't Seattle time. Could
you please find what offset to GMT you use (for example comparing date and
date -u command results, or looking at a world map). It should be useful.
Tell me also if you use summer time/winter time adjustment (but it may be
a french only stupidity).

>> Maybe we should get together on the net on a Saturday (western hemisphere;
>> Sunday in Australia, I think) sometme and talk for 2 or 3 hours.  Maybe
>> an irc channel?
Why not use irc ? I've never used it as I can connect only through my brother's
account, but if it is easy etc, why not ?

>> -- 
>> Dan Odom
>> danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS
>> 
>> Support the League for Programming Freedom.  Mail lpf@uunet.uu.net
>> 

   ,
Fare

From rideau@clipper Mon Apr 12 00:42:12 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00381; Mon, 12 Apr 93 00:42:11 +0200
Return-Path: <rideau@clipper>
Received-Date: Mon, 12 Apr 93 00:42:11 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24139; Sun, 11 Apr 93 15:39:47 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304112239.AA00364@clipper.ens.fr>
Subject: GEN, HLL+ [far26]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Mon, 12 Apr 93 0:39:14 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR


 I'd like to regularly post a list of pros and cons about a new language,
and its features. This is new version of far25.
 Here I compare to C++. I added C++ cons 6,7,8 and NewHLL req 5.
Please add comments about other languages. I'll summarize.


C/C++
~~~~~
Advantages:
1- We already know this language, and don't have to readapt to another
language syntax (see New Language Disadvantage 1)
2- We can test language functions immediately, without having to wait
for the kernel to be done (see Disadvantages 4)

Disadvantages:
1- does not include code as a standard object, thus creating a boundary
between using and programming. You can't both program and use at the
same time. That's the opposite of user programmer/user friendliness
(see HP calculators, which despite their lack of power, are much more
usable than my unix workstation, because code IS an object as anything
on the HP).
2- is not a structured language: procedures are all global; that's why
C/C++ will NEVER allow having independent light threads, and why it's
impossible to have a lightweight multitasking system under C/C++.
You may notice that this point is related to the preceding remark:
if procedure were objects, you could include them individually inside
thread objects, then each thread would have its own independent code.
3- C++ know only early binding (i.e., it only compiles directly executable
code), hardly knows about dynamic library linking (that's not a language
transparent feature; only a linker feature); C/C++ considers a program
to be complete, finished, and run in the absolute without interaction
with other programs, but through the system; that's why all ROI in C
must be explicitly done through system calls !!!
4- The "we won't have to rewrite a compiler" argument doesn't stand: if
the system is to be OOed, we'll have to adapt the compiler so as it produce
system requirements complying OO code. Thus, we can easily use code
language code that don't use the kernel, but adapting the compiler output
code to fit kernel requirements will be such that it's difficult to
test programs with the Kernel !
5- As it's a low-level language, either we'll have to have low-level specs
for the OS (as with Unix), so that we can't adapt to an architecture
different from that for the which the OS was designed; or we'll have to
rewrite a great amount of the C/C++ code on each system adaptation.
So we lose either system functionality, or language portability.
6- For the same reason (C/C++ being low-level), we can never achieve
object-level security, but by having a C/C++ program for each object,
which either disallows everything -however little- is an object in the
system, or requires many a low-level system (as opposed to language)
declaration in a C source, and/or requires having tiny C/C++ programs,
which contradicts the heavy compilation cost and the class philosophy
of the language.
7- The C++ philosophy contradicts the idea of late user-object binding.
C++ knows only of early compile-time object binding, or at best/worst
binding with compile-time defined virtual class realization through
virtual tables. So to make the slightiest add/change, you must recompile
the whole app.
8- The C++ preprocessor allows simple macro-definitions, but neither
macro instructions, nor recursive macro definitions. If #define DEF #define
was possible, for example, it would be possible to Ziv-Lempel compress
a source program from C to C.

New Language
~~~~~~~~~~~~
Disadvantages:
1- we have to relearn a new language syntax (see New language advantage 1).
Moreover, our system having a brand new conception, even with a traditional
language, we'll have to learn restrictions about our way of programming.
2- we have to debug the language specifications as we use it. But this can
prove useful to refine the language and the system specs.
3- we have to write a full compiler for it (but actually, as we'll have
a new object code format, we're bound to such thing one day indepently of the
chosen language)

Requirements
1- may be quickly (semi-)compiled at the same time as written, and
intermediate LLL code can be efficiently interpreted.
2- everything is an object, including code, including classes.
3 - parallelism is included in simple language constructs (not
so hard to build from executable code being object).
4- Meta programming easy in the language: the compiler is its own
preprocessor; the language is its own macro-command language.
5- Everything is parametrizable; even the compiler might be thought
as the specialization of a more general object compiler.
6- The language should allow a dynamical range of object binding:
HLL must be bounded as soon as possible to gain efficiency, as late
as possible to keep genericity.

Advantages:
1- We can design the syntax to fit our needs and ideas, so that it's
much easier to use. Moreover, even C isn't our natural language, and
whatever language we use, there will have been adaptating time to use
it.
2- We can correct the lacks of any existing language we would have used.
3- Portability: both the system and the language will be as easy to
port. All you need do is writing a LLL back-end compiler and
hardware specific lolos.
4- The language is perfectly is adapted to the system. No need of bizarre
and slow language -> system call translation.
5- being able to be interpreted, it serves as a shell language as
well as a programming language; being powerful, and easy to specialize
via standard libraries, it also replaces small utility languages
(sed, awk, perl, etc); finally, being high-level and knowing of
relations between objects, it is easily adaptated to an AI language.
So there is no more need to learn a different language for every
application; the same language is used for (almost) everything; no
more need to learn new syntaxes each time.


This isn't finished, but I post it as well. Feel free to add your
comments.

   ,
Fare


PS: BTW, what about far23, Andreas ? Even if it wasn't a fundamental
message, I'd like to have it in my collectin of all my mail about MOOSE.

From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon Apr 12 04:43:36 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01411; Mon, 12 Apr 93 04:43:35 +0200
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 12 Apr 93 04:43:35 +0200
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id ac18993;
          11 Apr 93 22:40 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa06233; 12 Apr 93 0:30 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa14711;
          12 Apr 93 0:28 GMT
To: Francois-Rene Rideau <rideau@clipper>
Cc: All the happy Moosers ! <moose-programmers@sfu.ca>
Subject: Re: GEN, HLL+ [far26] 
Date: Sun, 11 Apr 93 20:28:25 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304120028.aa14711@gloin.cis.udel.edu>
Status: OR

In Message <9304112239.AA00364@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=>
=> I'd like to regularly post a list of pros and cons about a new language,
=>and its features. This is new version of far25.
=> Here I compare to C++. I added C++ cons 6,7,8 and NewHLL req 5.
=>Please add comments about other languages. I'll summarize.

   I have only a brief four part reply:

1) You have accurately expressed the ideal case, but like it or
   not, MOOSE is not going to be ideal.

2) Adding language and multi-platform compiler design would
   increase the system design and implementation time by at least a
   factor of two.

3) Such a design would alienate all those who would use other
   languages with the system.

4) Surely there are other languages in existence that would do
   better than C++ and yet avoid the time and energy of creating and
   implementing a new one.

   I wouldn't mind working on a complete language-based system, but I
would think a year or two wouldn't be too high an estimate for the
extra time necessary. How's this sound? We build the initial system
as a standard microkernel-based system, building a language-based
subsystem on top. If the subsystem works well, we can make the next
major release based entirely on the subsystem. In the meantime,
objects could be built either on top of the microkernel or on top of
the subsystem. If the basic interface is similar enough, porting from
one to the other shouldn't be too difficult. In this way we can work
towards a working system and an ideal one at the same time.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon Apr 12 04:47:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01425; Mon, 12 Apr 93 04:47:00 +0200
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 12 Apr 93 04:47:00 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA29027; Sun, 11 Apr 93 19:44:05 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ac18993;
          11 Apr 93 22:40 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa06233; 12 Apr 93 0:30 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa14711;
          12 Apr 93 0:28 GMT
To: Francois-Rene Rideau <rideau@clipper>
Cc: All the happy Moosers ! <moose-programmers@sfu.ca>
Subject: Re: GEN, HLL+ [far26] 
Date: Sun, 11 Apr 93 20:28:25 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304120028.aa14711@gloin.cis.udel.edu>
Status: OR

In Message <9304112239.AA00364@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=>
=> I'd like to regularly post a list of pros and cons about a new language,
=>and its features. This is new version of far25.
=> Here I compare to C++. I added C++ cons 6,7,8 and NewHLL req 5.
=>Please add comments about other languages. I'll summarize.

   I have only a brief four part reply:

1) You have accurately expressed the ideal case, but like it or
   not, MOOSE is not going to be ideal.

2) Adding language and multi-platform compiler design would
   increase the system design and implementation time by at least a
   factor of two.

3) Such a design would alienate all those who would use other
   languages with the system.

4) Surely there are other languages in existence that would do
   better than C++ and yet avoid the time and energy of creating and
   implementing a new one.

   I wouldn't mind working on a complete language-based system, but I
would think a year or two wouldn't be too high an estimate for the
extra time necessary. How's this sound? We build the initial system
as a standard microkernel-based system, building a language-based
subsystem on top. If the subsystem works well, we can make the next
major release based entirely on the subsystem. In the meantime,
objects could be built either on top of the microkernel or on top of
the subsystem. If the basic interface is similar enough, porting from
one to the other shouldn't be too difficult. In this way we can work
towards a working system and an ideal one at the same time.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From danodom@matt.ksu.ksu.edu Mon Apr 12 02:44:56 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00818; Mon, 12 Apr 93 02:44:55 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Mon, 12 Apr 93 02:44:55 +0200
Received: from matt.ksu.ksu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA00907; Sun, 11 Apr 93 19:46:53 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304120046.AA00907@matt.ksu.ksu.edu>
Subject: Re: Talk
To: rideau@clipper (Francois-Rene Rideau)
Date: Sun, 11 Apr 93 19:46:52 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <9304112229.AA00295@clipper.ens.fr>; from "Francois-Rene Rideau" at Apr 12, 93 12:29 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of Francois-Rene Rideau came:

> Well, the USA is a wide country, so that NY time isn't Seattle time. Could
> you please find what offset to GMT you use (for example comparing date and
> date -u command results, or looking at a world map). It should be useful.
> Tell me also if you use summer time/winter time adjustment (but it may be
> a french only stupidity).

Ummm... Like I said, Central Standard Time (C.S.T.).  Houston time.
Right now, 5 hours from GMT, I think.

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

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

From danodom@matt.ksu.ksu.edu Mon Apr 12 02:47:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00833; Mon, 12 Apr 93 02:47:25 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Mon, 12 Apr 93 02:47:25 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26727; Sun, 11 Apr 93 17:45:26 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA00907; Sun, 11 Apr 93 19:46:53 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304120046.AA00907@matt.ksu.ksu.edu>
Subject: Re: Talk
To: rideau@clipper (Francois-Rene Rideau)
Date: Sun, 11 Apr 93 19:46:52 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <9304112229.AA00295@clipper.ens.fr>; from "Francois-Rene Rideau" at Apr 12, 93 12:29 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of Francois-Rene Rideau came:

> Well, the USA is a wide country, so that NY time isn't Seattle time. Could
> you please find what offset to GMT you use (for example comparing date and
> date -u command results, or looking at a world map). It should be useful.
> Tell me also if you use summer time/winter time adjustment (but it may be
> a french only stupidity).

Ummm... Like I said, Central Standard Time (C.S.T.).  Houston time.
Right now, 5 hours from GMT, I think.

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

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

From dmarer@td2cad.intel.com Mon Apr 12 18:32:53 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15152; Mon, 12 Apr 93 18:32:52 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Mon, 12 Apr 93 18:32:52 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA13032; Mon, 12 Apr 93 09:30:01 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Mon, 12 Apr 93 09:29:59 -0700
Received: by td2cad (5.57/10.0i); Mon, 12 Apr 93 09:33:59 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA07897; Mon, 12 Apr 93 09:29:49 PDT
Message-Id: <9304121629.AA07897@iws804.intel.com>
Subject: Pentium Docs Ordering Info
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Mon, 12 Apr 93 9:29:47 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR


> David said....

> You said you have ordered the documentation for the Pentium.  You
> didn't say how to do this.  How do I do this?

Sorry - this can be ordered through Intel Literature:

	Intel Literature
	1(800)548-4725

	Pentium Processor Three Volume Set
	Item #: 241563
	$70+tax+shipping

I received it last week, and it's very interesting!  They've done some neat
things with optimization, and I think it'll fly!

One thing about "Appendix H" - this is the information available by non-
disclosure only.  There are many references to it, but all of them involve
things the average programmer would not be interested in.  Some of the
status bits returned by the CPUID function to identify features are described
only in Appendix H, as well as the "RDTSC" instruction - any guesses what
that stands for?  I have no clue...  There is also some information on how
they sped up the handling of Virtual 8086 mode tasks and the addition info
which (might be) stored in the Task State Segment.

I think if you were an operating systems designed, you'd want to know what
exists in Appendix H - even compiler designers might not find much interesting
there.  I don't really agree on hiding that info, but I guess the point is to
make it that much more difficult for other manufacturers to copy their
chips.  If you don't know all the features, how can you imitate it?  In any
case, it'll only stay secret for a short time before somebody leaks the info
but that gives Intel a competitive edge, I suppose.

Sure love to take a peek at it though...


> > Just a guess: The P6 will do instruction ordering optimization on the fly. :-)
> 
> P6?
> If they follow the new naming, shouldn't it be Hexium?

Hmm...I thought "Sexium" was the next name. :-)

Seriously, I don't think a name has been chosen.  It's even called something
different than the 'P6' around here (but I can't remember what) but until a
name is announced, it's easy to remember.  They'll probably continue using
their new naming strategy, but "Hexium", "Heptium", "Octium", "Neptium", and
"Decium" sound pretty silly.  :-p


Laterz!

	Dennis


From dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Apr 16 13:32:04 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14246; Fri, 16 Apr 93 13:32:03 +0200
Return-Path: <dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 16 Apr 93 13:32:03 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA01519; Fri, 16 Apr 93 04:28:03 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa02725; 16 Apr 93 7:26 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa03729;
          16 Apr 93 11:25 GMT
Received: from sol.cis.udel.edu by dori.cis.udel.edu id aa11171;
          16 Apr 93 11:24 GMT
To: moose-programmers@sfu.ca
Date: Fri, 16 Apr 93 07:23:47 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304161124.aa11171@dori.cis.udel.edu>
Status: OR


   NAK?

From dmarer@td2cad.intel.com Fri Apr 16 18:19:26 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17086; Fri, 16 Apr 93 18:19:25 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 16 Apr 93 18:19:25 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA10702; Fri, 16 Apr 93 09:16:06 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Fri, 16 Apr 93 09:15:57 -0700
Received: by td2cad (5.57/10.0i); Fri, 16 Apr 93 09:20:01 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA17098; Fri, 16 Apr 93 09:16:09 PDT
Message-Id: <9304161616.AA17098@iws804.intel.com>
Subject: Re: your mail
To: duzan@udel.edu (Gary D. Duzan)
Date: Fri, 16 Apr 93 9:16:06 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
Cc: moose-programmers@sfu.ca (Moose Kernel Project)
In-Reply-To:  <9304161124.aa11171@dori.cis.udel.edu>; from "Gary D. Duzan" at Apr 16, 93 7:23 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> Gary sez...
> 
>    NAK?
> 

Ping!

From danodom@matt.ksu.ksu.edu Fri Apr 16 22:25:52 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20418; Fri, 16 Apr 93 22:25:51 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Fri, 16 Apr 93 22:25:51 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA29467; Fri, 16 Apr 93 13:22:23 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA07434; Fri, 16 Apr 93 15:21:51 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304162021.AA07434@matt.ksu.ksu.edu>
Subject: Re: your mail
To: duzan@udel.edu (Gary D. Duzan)
Date: Fri, 16 Apr 93 15:21:50 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To:  <9304161124.aa11171@dori.cis.udel.edu>; from "Gary D. Duzan" at Apr 16, 93 7:23 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of Gary D. Duzan came:
>    NAK?

ACK :-)

Seriously, though.  What's wrong with the list?  Where is everybody.

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

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

From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sat Apr 17 00:00:50 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA21150; Sat, 17 Apr 93 00:00:49 +0200
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sat, 17 Apr 93 00:00:49 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06558; Fri, 16 Apr 93 14:56:19 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa28052;
          16 Apr 93 17:43 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa10868;
          16 Apr 93 21:40 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa11633;
          16 Apr 93 21:36 GMT
To: Moose List <moose-programmers@sfu.ca>
Subject: Re: your mail 
Date: Fri, 16 Apr 93 17:35:55 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304162136.aa11633@bifur.cis.udel.edu>
Status: OR

In Message <9304162021.AA07434@matt.ksu.ksu.edu> ,
   Dan Odom <danodom@matt.ksu.ksu.edu> wrote:

=>From the brain of Gary D. Duzan came:
=>>    NAK?
=>
=>ACK :-)
=>
=>Seriously, though.  What's wrong with the list?  Where is everybody.

   Well, I'm at home in Newark, Delaware, sitting at my HP2621P
terminal, listening to an Andreas Vollenweider CD and drinking a
Pathmark brand cola. :-)
   I think most of us are waiting for Dennis to post a general set of
goals for the project. Personally, I'm waiting for a response from
Fare' on my response to his latest language posting.  Michael has
already responded that he agrees with me, surprise of surprises. :-)
So either I am absolutely correct, and hence there is no point in
debating my points, or I am completely mad, and therefore unworthy
of a response. :-)
   I had better clean out my MOOSE folder; it is about 1.5MB and
274 messages. It will be good to take a look at what we have done
so far, too.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From csjjlay@knuth.mtsu.edu Sun Apr 18 05:48:14 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17898; Sun, 18 Apr 93 05:48:11 +0200
Return-Path: <csjjlay@knuth.mtsu.edu>
Received-Date: Sun, 18 Apr 93 05:48:11 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from knuth.mtsu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19225; Sat, 17 Apr 93 20:44:53 -0700
Received: by knuth.mtsu.edu (Smail3.1.28.1 #8)
	id m0nkQKT-000czgC; Sat, 17 Apr 93 22:46 CDT
Message-Id: <m0nkQKT-000czgC@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: MUSIC Spces 0.0 [jjl1]
To: moose-programmers@sfu.ca
Date: Sat, 17 Apr 1993 22:46:04 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 12048     
Status: OR


Greeting MOOSErs!
I unfortunately could not clean up my specs before Friday as promised.
Who knew planning a wedding was so much work!  In order to get some
feedback, I have mailed you my original specification in hopes to get
some ideas.  this is by no means a rough draft.  that would be
exagerating!  Read over it and let me know how you feel.  This is a week
old...  Enjoy  (I hope)


                                        MUSIC
                              Multimedia USer InterFace

                             Copyright JJ Lay April 1993

                                    REVISION 0.00
                                    10 APRIL 1993
                                    09:00 PM CST


            Permission is given to use the ideas presented in this
            document without prior permission from the author under the
            condition that it is not for profit, monetary or otherwise.

            I.  INTRODUCTION

            A. SCOPE AND PURPOSE
            The following document will cover all aspects of a human-
            computer interface, and is meant to serve as a definitive
            guide for programmers.  There are two reasons for this:  all
            programs using written for this interface will have a common
            "look-and-feel" resulting in a smaller learning curve for
            users.  Secondly, development time for programs should be
            drastically reduced becuase of the underlying assumptions
            built into the interface.

            B. OVERVIEW
            The objective of this MUSIC (as it will be called from here
            on) will be to provide an user interface that is easy to use
            for both user and programmer.  Historically, most interfaces
            have been one or the other.  For example, a text oriented
            interface is easy to program but rather cumbersome for an
            end-user.  An advanced graphical environment such as
            OSF/Motif is somewhat complex to program in, but is easier
            for beginnners to learn based on my experience.  There is
            one exception - Microsoft Windows - which is difficult for
            everyone to use.

            There are two extremely important philosophies on which
            MUSIC is built.
            The first:  The end-user is more concerned with getting a
            job done and producing results.  A computer is a tool.  She
            is not concerned with how the tool works, but with what it
            produces.  An example: a journalist wants to type his news
            article.  He doesn't want to worry about which word
            processor to use or which looks the slickest.  He wants his
            article typed, formatted, and printed.  The interface should
            hide as much about the inner-workings of the program as
            possible and make intelligent assumptions when needed.  This
            type of assumption could be a "document-oriented" approach
            versus a "process-oriented approach."  Contemporary
            operating-systems makes the user worry about which program
            to use, if the files will be compatible, etc.  Who cares?





            The second assumption: Certain end-users have specialized
            needs.  MUSIC will not be able to meet all users' needs.
            Therefore the user should be able to replace those parts of
            the interface with components that better meets his needs.
            It should be "customizable to its atoms."  Equivalent
            components can be exchanged without any side-effects.

            C. SYSTEM REQUIREMENTS AND CONSTRAINTS
            The basic hardware requirements are as follows:
            a 386DX operating at 33MHz with 2Mb of RAM and 80Mb of
            external storage (the term hard disk was avoided because of
            alternative media such as flopticals and network devices).
            The video quality for a graphical interface (GUI) is
            recommended to be a VGA monitor and adapter (640 x 480
            resolution) with 1 Mb of RAM capable of 256 colors.  Text
            quality can be as poor as a text-only dumb terminal.  Input
            can come from a number of various devices.  Currently,
            keyboard and mouse are considered the main input channels.
            MUSIC will have no such prejudice.  It will be built
            assuming anything can give input.  The same will hold for
            output.


            II. INFORMATION DESCRIPTION

            A. OVERVIEW
            The user will have a variety of information which needs to
            be processed.  Therefore MUSIC should handle it all.  Basic
            input can take the form of keyboard commands, mouse motions
            and clicks, and voice commands.  Complex input can be in the
            form of hand motions using a PowerGlove type device, video
            and audio from a camcorder mounted on the monitor, or
            thoughts from some unknown device.  Other inputs not known
            should also be handled.  Similarly for output, standard
            output is text on a screen, icons and graphics, audio in the
            form of beeps, horns, and simulated voice.  Full motion
            video and audio or perhaps 3-D holographics.  Information to
            and from users will be shipped to processes through "ports."

            B. SAMPLE APPLICATIONS
            A simple example but one that can not be ignored is the user
            with a word processor.  A keytboard takes the information
            and the output is produced on the screen or the printer.
            Building on that, the user is stuck, so he clicks on help,
            and window opens with a video complete with audio that
            demonstrates the proper sequence to perform whatever task is
            needed.
            Assume the user is blind.  Input comes via voice.  The
            computer generates responses with audio.  No video or
            keyboard is required.
            The extreme example, virtual reality.  The user uses a
            helmet and suit that gives the user senses of "being there,"
            and input is taken from the motions of his body.  ("Look and
            feel" takes on whole new meanings here.)






            C. EXAMPLE  INFORMATION
            Information can come in all forms:
            Audio
            Video (camcorder)
            Keyboard
            Motion (mouse, joystick, body movement)
            Text
            Graphics
            Physical Analog (temperatures, pressure)
            Processes

            D. REQUIREMENTS
            Information has the nature that it can easily be converted
            from one type to another.  This will be the key to MUSIC.
            Text can be easily converted to audio and vice versa.
            Unfortunately, the same cannot be said for more complex
            information types such as video amd other graphical forms.
            This will be one of the limiting fasctors for now.  Basic
            types must be identified and will be termed "basics."  The
            following basics are proposed:
                 - text
                 - audio
                 - graphics (computer generated mainly)
                 - video
                 - motion
            Keyboard input takes the form of text input.  Mouse would
            fall under motion.  Camcored input could be a combination of
            audio and video.


            III. DEVELOPMENT

            A. OVERVIEW
            Before serious code can be written, the process of
            converting basics to other basics must be developed.  Once
            this is completed, other work can begin.  There is much
            discussion going on as to which is better: a GUI or TUI
            (text user interface).  Both are.  But as shown in previous
            examples, so is an AUI (audio user interface) and so on.
            Certain design criteria should be put down as to what the
            interface will do with input once it is accepted from the
            user and how it will deal with output from processes.  From
            here on out, to avoid the concept that the interface will
            deal only with keyboard input and CRT output, the user will
            be considered to "experience" the interface.

            B. PORTS
            Input and Output will travel through bi-directional PORTS.
            It is a continuous stream of information that has a
            beginning and an ending with no breaks inserted by the
            system.  PORTS can take both input and output, and it is up
            to whatever is on the two ends to decide if they want
            whatever is coming through.  Examples of PORTS include: A





            window on the screen which the user makes active and sends
            her audio input to and receives results from the process on
            the other end.  A PORTS could be a virtual connection to
            between a thermometer that gives a continuous reading of the
            temperature anda process that monitors it.  Or a PORTS could
            be a connection between two or three processes.  This
            implies that some form of interprocess communication will
            need to be developed early on.

            C. PARTITIONING
            At first glance, it appears that the interface will
            extremely complex and bulky.  By using object-oriented
            programming and design and the concepts of modularity, this
            interface could be oparting in very little time.
            1. Concentrate on the text and motion basics.  This will
            give keyboard and mouse capability at the very minimum.
            2. Concntrate on the graphics basic.  This will give both
            text and graphical outputs capability.
            3. Build the basics manager.  It will manage how basics are
            given to the user and received from her.
            3. Go back to 1 and start over until everything works
            perfectly.  Once we have the "simple" basics down, we should
            be able to crank out the others in no time.
            4.  Fgure out how to convert between the various basics
            developed thus far.  This will give some insight into how
            the others should work.

            D. SAMPLE CODE
            class BASIC {
                 private:
                 protected:
                      convert_to (BASIC)
                 public:
                      BASIC(initialization)
                      ~BASIC()
                      INPUT(PORT)
                      OUTPUT(PORT)
            }

            class TEXT is a BASIC {
                 private:
                      BYTE *information
                 protected:
                      convert_to(BASIC) {
                           stuff to handle conversions
                      }
                 public:
                      TEXT(BYTE initial_strings)
                      ~TEXT()
                      INPUT(PORT) {
                           get bytes until eof or whatever
                           and store them in information
                      }
                      OUTPUT(PORT) {





                           write the data to PORT
                      }
							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"Marriage is a noble institution...  If you want to be institutionalized
the rest of your life!" -Dr. Paul Hutcheson, MTSU Computer Science Dept

From csjjlay@knuth.mtsu.edu Sun Apr 18 05:59:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18152; Sun, 18 Apr 93 05:59:29 +0200
Return-Path: <csjjlay@knuth.mtsu.edu>
Received-Date: Sun, 18 Apr 93 05:59:29 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from knuth.mtsu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19424; Sat, 17 Apr 93 20:56:54 -0700
Received: by knuth.mtsu.edu (Smail3.1.28.1 #8)
	id m0nkQW7-000czlC; Sat, 17 Apr 93 22:58 CDT
Message-Id: <m0nkQW7-000czlC@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: Why a filesystem? [jjl2]
To: moose-programmers@sfu.ca
Date: Sat, 17 Apr 1993 22:58:07 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 834       
Status: OR

Why do we need a filesystem?  Shouldn't a hard disk be considered an
extension of memory?  As should any other device?  What do you think of
this idea?

I have 290 email messages totaling 1.3 Mb of disk from Moose!  Wow!

							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"Marriage is a noble institution...  If you want to be institutionalized
the rest of your life!" -Dr. Paul Hutcheson, MTSU Computer Science Dept

From danodom@matt.ksu.ksu.edu Mon Apr 19 00:33:23 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27826; Mon, 19 Apr 93 00:33:22 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Mon, 19 Apr 93 00:33:22 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05150; Sun, 18 Apr 93 15:30:42 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA03104; Sun, 18 Apr 93 17:30:42 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304182230.AA03104@matt.ksu.ksu.edu>
Subject: Re: MUSIC Specs 0.0 [djo4-ish]
To: csjjlay@knuth.mtsu.edu (JJ Lay)
Date: Sun, 18 Apr 93 17:30:41 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <m0nkQKT-000czgC@knuth.mtsu.edu>; from "JJ Lay" at Apr 17, 93 10:46 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of JJ Lay came:

>             B. OVERVIEW
>             The objective of this MUSIC (as it will be called from here
>             on) will be to provide an user interface that is easy to use
>             for both user and programmer.  Historically, most interfaces
>             have been one or the other.  For example, a text oriented
>             interface is easy to program but rather cumbersome for an
>             end-user.  An advanced graphical environment such as
>             OSF/Motif is somewhat complex to program in, but is easier
>             for beginnners to learn based on my experience.  There is
>             one exception - Microsoft Windows - which is difficult for
>             everyone to use.

I would argue this.  GUIs are easy to learn, but once you learn them
CLIs are easier to use.

>             The second assumption: Certain end-users have specialized
>             needs.  MUSIC will not be able to meet all users' needs.
>             Therefore the user should be able to replace those parts of
>             the interface with components that better meets his needs.
>             It should be "customizable to its atoms."  Equivalent
>             components can be exchanged without any side-effects.

Hmmm... This sounds like a programmer's interface, and it's what I'd like to
see.  It's hard to have a customizeable interface that can be learned in
less than a month.  After all, what is the BSD UNIX API but a cutomizeable
interface?  (enough misspellings there for you?)

>             C. SYSTEM REQUIREMENTS AND CONSTRAINTS
>             The basic hardware requirements are as follows:
>             a 386DX operating at 33MHz with 2Mb of RAM and 80Mb of
>             external storage (the term hard disk was avoided because of
>             alternative media such as flopticals and network devices).
>             The video quality for a graphical interface (GUI) is
>             recommended to be a VGA monitor and adapter (640 x 480
>             resolution) with 1 Mb of RAM capable of 256 colors.  Text
>             quality can be as poor as a text-only dumb terminal.  Input
>             can come from a number of various devices.  Currently,
>             keyboard and mouse are considered the main input channels.
>             MUSIC will have no such prejudice.  It will be built
>             assuming anything can give input.  The same will hold for
>             output.

1) VGA is not high enough quality, I don't think.  Anybody who uses a
SPARC knows exactly what I mean.

2) We'll be hard pressed to fit it in 80 meg.  The best 32-bit PC OS
that I have seen is Linux, and the SLS distribution requires 90 meg for
a full installation, plus about 670k of RAM for the kernel.

>             Information has the nature that it can easily be converted
>             from one type to another.  This will be the key to MUSIC.
>             Text can be easily converted to audio and vice versa.
>             Unfortunately, the same cannot be said for more complex
>             information types such as video amd other graphical forms.
>             This will be one of the limiting fasctors for now.  Basic
>             types must be identified and will be termed "basics."  The
>             following basics are proposed:
>                  - text
>                  - audio
>                  - graphics (computer generated mainly)
>                  - video
>                  - motion

OK.  My only comment about this part is that it will take a HELL of a lot
of WORK.

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

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

From danodom@matt.ksu.ksu.edu Mon Apr 19 00:37:16 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27890; Mon, 19 Apr 93 00:37:16 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Mon, 19 Apr 93 00:37:16 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05197; Sun, 18 Apr 93 15:33:07 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA03310; Sun, 18 Apr 93 17:33:09 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304182233.AA03310@matt.ksu.ksu.edu>
Subject: Re: Why a filesystem? [jjl2] [djo5]
To: csjjlay@knuth.mtsu.edu (JJ Lay)
Date: Sun, 18 Apr 93 17:33:08 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <m0nkQW7-000czlC@knuth.mtsu.edu>; from "JJ Lay" at Apr 17, 93 10:58 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of JJ Lay came:

> Why do we need a filesystem?  Shouldn't a hard disk be considered an
> extension of memory?  As should any other device?  What do you think of
> this idea?

ARRRRGH!! NOOOOOOOOOOO!!!!!!!!!!!!!!

Have you ever worked under VM/CMS?  This type of environment is PURE HELL!
Not to mention being very, very slow (disk-based memory is like that, ya
know?).


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

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

From rideau@clipper Sun Apr 18 23:58:48 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27508; Sun, 18 Apr 93 23:58:47 +0200
Return-Path: <rideau@clipper>
Received-Date: Sun, 18 Apr 93 23:58:47 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA04384; Sun, 18 Apr 93 14:55:28 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304182154.AA27486@clipper.ens.fr>
Subject: GEN,LLL+ [far27]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Sun, 18 Apr 93 23:54:53 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR


 I'd like to regularly post a summary of pros, cons, reqs, etc,
about a standard LLL (or what I began to call a LLL, but I'm sure
you'll soon find a better word/acronym).
 This is the first version of the summary.

 
LLL principle
~~~~~~~~~~~~~
 There is a (family of (slightly hardware dependent ?) ?) standard
coding format for objects, INCLUDING EXECUTABLE CODE in such a way
as trivial programs can be instantly interpreted on any machine,
while more complicated programs are compiled without the
parsing/front end step which is known to be the most limitating,
and with intermediate code optimisation done and info ready for
ultimate back end compiling.

Pros
~~~~
1) Greatly shortens compile time
2) allows quick, easy and efficient portable code&data (=object)
exchange inside a heterogeneous distributed system or between 
remote systems.
3) greatly reduces future compiler design: a new language will
only need a new (or adaptated) front end; tools may be provided
for parsing (an OO lex/yacc equivalent). The back-end part of
compilers will be language independent, only hardware/implementation
dependent.
4) may extend current existing HLLs by including features a OO,
genericity, recursive call to HLL from LLL, etc.


Cons
~~~~
1) Is an important human-time investment (but aren't we Moosers
here to work ? :-)
2) Requires our respecting programming rules (but anyway, it's
inevitable)
3) Needs new compilers (but anyway, a new OS always requires new
compilers, to comply new object code format) (so why not profit
to build also a new HLL ? :-) for its features to be available to
programmers/users (again, I make no clear difference).
4) Compiler editing companies might not appreciate competition
(see Microsoft)
5) if it works, ANSI will have to produce again new papers (but
that also is inevitable, with MOOSE, isn't it ?Think about ANSI
MOOSE ! :-)

Reqs
~~~~
1) We must find a "good" preferably extensible format. A quick
linear conversion with a small memory occupancy is to be considered,
to provide at the same time external portability and internal
efficiency (in/external relative to each host). If we forget
something important, we'll have to produce un-upward-compatible
formats and thus forma converter that will occupy system time and 
space.
2) The standard must provide a quick, efficient, unspacy way of
coding external links: an object will almost always need external
objects to run/evaluate, that shouldn't/couldn't/oughtn't be
included in the object itself; however, when loaded/saved, the
object needs the link not to be forgotten, so as to be properly
restored next time. My opinion is have tables/virtual dictionaries
at module level (that'll be my definition for what Dennis called
modules)
3) As the format includes not only LL executable code, but also
data, etc, it's a full language. The main difference from usual
languages then is the fact that it is a binary format as opposed
to text format. But as text is a particular kind of binary, a
point of view would be that HLL is an LLL subset (as well as
machine language) (actually, if my LLL is extended to a full
object description standard, any object will be coded through it,
so why not HLL source fies in particular ?); thus, there is no
more compilation, but only simplification ("optimisation") and
evaluation, from subsets of objects to others.

Language Policy propositions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) (Fare')
First have a LLL interpreter in C/C++; then build C/C++ and/or
NewHLL compiler to LLL (and why not NewHLL <-> C/C++ compilers,
understanding extensions of C/C++ through added info inside
comments ?)
2) (?) What else ?

Feel free (=bound 8-) to contribute and correct my poor english and my
mistypes.
   ,
Fare


PS:
- Gary, we can begin coding in C++, including added info in comments.
C/C++ may be only for kernel code. After that, we MUST have our own
compiler, so why stay with C/C++ which creates a programmer vs. user
barrier ?
- Sorry for the long silence. But being far from my usual Sparcstations,
I am bound to use a costly SLOW 1200/75 baud "minitel" terminal through
phone net, and I HATE wordprocessing with it.
- BTW, what about far23, Andreas ? Even if it wasn't a fundamental
message, I'd like to have it in my collectin of all my mail about MOOSE.

From rideau@clipper Mon Apr 19 00:03:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27640; Mon, 19 Apr 93 00:03:33 +0200
Return-Path: <rideau@clipper>
Received-Date: Mon, 19 Apr 93 00:03:33 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA04484; Sun, 18 Apr 93 15:00:29 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304182159.AA27521@clipper.ens.fr>
Subject: Re: Why a filesystem? [jjl2]
To: csjjlay@knuth.mtsu.edu (JJ Lay)
Date: Sun, 18 Apr 93 23:59:51 MET DST
Cc: moose-programmers@sfu.ca
In-Reply-To: <m0nkQW7-000czlC@knuth.mtsu.edu>; from "JJ Lay" at Apr 17, 93 10:58 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>> 
>> Why do we need a filesystem?  Shouldn't a hard disk be considered an
>> extension of memory?  As should any other device?  What do you think of
>> this idea?
Well, if we base the system on persistent objects, it's more like the
memory being a huge buffer and/or temporary object zone.

>> I have 290 email messages totaling 1.3 Mb of disk from Moose!  Wow!
I have over 305 messages which is over 400 Kb when gziped (1.4 Mb ASCII).

>> 							JJ LAY

   ,
Fare 

From ANDREASA@sofus.dhhalden.no Mon Apr 19 10:09:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09402; Mon, 19 Apr 93 10:09:24 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 19 Apr 93 10:09:24 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA16981; Mon, 19 Apr 93 01:02:52 -0700
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <22648-0@fenris.dhhalden.no>; Mon, 19 Apr 1993 10:02:41 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930419100227.384; 19 Apr 93 10:02:41 -0100
Message-Id: <MAILQUEUE-101.930419100223.352@sofus.dhhalden.no>
To: moose-programmers@sfu.ca (Moose List)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 19 Apr 93 10:02:23 +0100
Subject: Re: MUSIC Specs 0.0 [djo4-ish]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

ACK :-)
> From the brain of Dan Odom
> > From the brain of JJ Lay came:
>
> >             B. OVERVIEW
> >             The objective of this MUSIC (as it will be called from here
> >             on) will be to provide an user interface that is easy to use
> >             for both user and programmer.  Historically, most interfaces
> >             have been one or the other.  For example, a text oriented
> >             interface is easy to program but rather cumbersome for an
> >             end-user.  An advanced graphical environment such as
> >             OSF/Motif is somewhat complex to program in, but is easier
> >             for beginnners to learn based on my experience.  There is
> >             one exception - Microsoft Windows - which is difficult for
> >             everyone to use.
>
> I would argue this.  GUIs are easy to learn, but once you learn them
> CLIs are easier to use.
 No doubt but many people never uses computer more than a couple of hours
 every day, and hence only learns the GUI. Almost only computer literate
 will learn the text version.

> >             C. SYSTEM REQUIREMENTS AND CONSTRAINTS
> >             The basic hardware requirements are as follows:
> >             a 386DX operating at 33MHz with 2Mb of RAM and 80Mb of
> >             external storage (the term hard disk was avoided because of
> >             alternative media such as flopticals and network devices).
> >             The video quality for a graphical interface (GUI) is
> >             recommended to be a VGA monitor and adapter (640 x 480
> >             resolution) with 1 Mb of RAM capable of 256 colors.  Text
> >             quality can be as poor as a text-only dumb terminal.  Input
> >             can come from a number of various devices.  Currently,
> >             keyboard and mouse are considered the main input channels.
> >             MUSIC will have no such prejudice.  It will be built
> >             assuming anything can give input.  The same will hold for
> >             output.
>
> 1) VGA is not high enough quality, I don't think.  Anybody who uses a
> SPARC knows exactly what I mean.

I have been arguing for SVGA only, but it showed up to be a stone-hard
resistance against it. Actually 640x480x8 is SuperVGA, but it is the second
lowest resolution with 256 colors.
I agree, the higher resolution the better!
But to save us from a lot of work, we could start with a lower resolution.
To you who thinks we should support CGA and EGA, noone can use a GUI even if
exists effectively under these resolutions. It simply looks to ugly!

> >             Information has the nature that it can easily be converted
> >             from one type to another.  This will be the key to MUSIC.
> >             Text can be easily converted to audio and vice versa.
> >             Unfortunately, the same cannot be said for more complex
> >             information types such as video amd other graphical forms.
> >             This will be one of the limiting fasctors for now.  Basic
> >             types must be identified and will be termed "basics."  The
> >             following basics are proposed:
> >                  - text
> >                  - audio
> >                  - graphics (computer generated mainly)
> >                  - video
> >                  - motion
>
> OK.  My only comment about this part is that it will take a HELL of a lot
> of WORK.

As I have already told Lay it is almost impossible to convert text to video,
or audio to text.
My suggestion is instead that we make all the proposed BASICs moveable
between each other. You could move a picture into a video etc.

> Dan Odom


Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From ANDREASA@sofus.dhhalden.no Mon Apr 19 10:30:49 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09593; Mon, 19 Apr 93 10:30:48 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 19 Apr 93 10:30:48 +0200
Received: from fenris.dhhalden.no by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <22999-0@fenris.dhhalden.no>; Mon, 19 Apr 1993 10:30:30 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930419103016.256; 19 Apr 93 10:30:30 -0100
Message-Id: <MAILQUEUE-101.930419103005.480@sofus.dhhalden.no>
To: rideau@clipper (Francois-Rene Rideau)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 19 Apr 93 10:30:05 +0100
Subject: Re: GEN,LLL+ [far27] [arf5] (looks like i forgot numbering no 4)
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

>  I'd like to regularly post a summary of pros, cons, reqs, etc,
> about a standard LLL (or what I began to call a LLL, but I'm sure
> you'll soon find a better word/acronym).
>  This is the first version of the summary.

I totaly agree with you Fare'. It looks more and more like a good idea using
an LLL on each platform. You have my support.

> Language Policy propositions
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1) (Fare')
> First have a LLL interpreter in C/C++; then build C/C++ and/or
> NewHLL compiler to LLL (and why not NewHLL <-> C/C++ compilers,
> understanding extensions of C/C++ through added info inside
> comments ?)

Agree.

> 2) (?) What else ?
>
> Feel free (=bound 8-) to contribute and correct my poor english and my
> mistypes.
You are not the only one...:-)
>     ,
> Fare
>
>
> PS:
> - BTW, what about far23, Andreas ? Even if it wasn't a fundamental
> message, I'd like to have it in my collectin of all my mail about MOOSE.
I didn't have it:-(
DS.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon Apr 19 14:01:33 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12199; Mon, 19 Apr 93 14:01:31 +0200
Return-Path: <bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 19 Apr 93 14:01:31 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19598; Mon, 19 Apr 93 04:53:28 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa20403; 19 Apr 93 7:35 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa02640;
          19 Apr 93 11:31 GMT
Received: from sol.cis.udel.edu by bofur.cis.udel.edu id aa04475;
          19 Apr 93 11:31 GMT
To: Moose List <moose-programmers@sfu.ca>
Subject: Re: MUSIC Specs 0.0 [djo4-ish] 
Date: Mon, 19 Apr 93 07:30:59 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304191131.aa04475@bofur.cis.udel.edu>
Status: OR

In Message <MAILQUEUE-101.930419100223.352@sofus.dhhalden.no> ,
   Andreas Arff <ANDREASA@dhhalden.no> wrote:

=>ACK :-)
=>> From the brain of Dan Odom
=>>
=>> 1) VGA is not high enough quality, I don't think.  Anybody who uses a
=>> SPARC knows exactly what I mean.
=>
=>I have been arguing for SVGA only, but it showed up to be a stone-hard
=>resistance against it. Actually 640x480x8 is SuperVGA, but it is the second
=>lowest resolution with 256 colors.
=>I agree, the higher resolution the better!

   Surely, a clean design will scale to whatever resolution is
available. Regardless, if we are going to be portable, we can't
bind ourselves to what is available on one architecture. Of course,
the PC world seems to be the primary target, so we have to keep it
in mind. Unfortunately, there is no real standard for SVGA, so we
should probably support plain VGA first.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From danodom@matt.ksu.ksu.edu Tue Apr 20 00:17:03 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA19992; Tue, 20 Apr 93 00:17:03 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Tue, 20 Apr 93 00:17:03 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03839; Mon, 19 Apr 93 15:11:11 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA08870; Mon, 19 Apr 93 17:11:07 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304192211.AA08870@matt.ksu.ksu.edu>
Subject: Re: MUSIC Specs 0.0 [jjl3] [djo5]
To: csjjlay@knuth.mtsu.edu (JJ Lay)
Date: Mon, 19 Apr 93 17:11:05 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <m0nkk5h-000cyKC@knuth.mtsu.edu>; from "JJ Lay" at Apr 18, 93 7:52 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>From the brain of JJ Lay came:

> : 1) VGA is not high enough quality, I don't think.  Anybody who uses a
> : SPARC knows exactly what I mean.
> 
> But can we expecxt the typical end-user to have anything better right
> now?  You will see more on this in my next release some time soon.  (I
> hope)

1024x768 is becoming more common, but I see your point.  How about this:
VGA support included, but users are encouraged to use a higher mode if
available.

> : 2) We'll be hard pressed to fit it in 80 meg.  The best 32-bit PC OS
> : that I have seen is Linux, and the SLS distribution requires 90 meg for
> : a full installation, plus about 670k of RAM for the kernel.
> 
> Linux is my OS of choice!  I don't see why we can't do what they've
> done, but better! Where's the spirit of a challenge?

Oh, let's do better, certainly.  My point was that OSs take up a lot
of space.

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

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

From winikoff@cs.mu.OZ.AU Tue Apr 20 03:50:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA21729; Tue, 20 Apr 93 03:50:32 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Tue, 20 Apr 93 03:50:32 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA16509; Mon, 19 Apr 93 18:41:54 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA28389
	Tue, 20 Apr 1993 11:23:31 +1000 (from winikoff)
Message-Id: <9304200123.28389@mulga.cs.mu.OZ.AU>
Subject: Why NOT C(++) ...
To: moose-programmers@sfu.ca (Moose Project)
Date: Tue, 20 Apr 93 11:23:30 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
Status: OR

Found this floating around.

Enjoy.

I'll hopefuly have something to say about Sather Real Soon Now.

(BTW -- tared and compressed distribution was about 4 Megs. 
Instalkled it takes up 23 Megs)

Michael 


--------------- CUT HERE --------------

[Note: This is a text-only copy of a technical report which was
originally prepared using Interleaf and distributed in Postscript
form.  In the process of converting this document to textual form
the title pages and some header/footer material, as well as
formatting information, have been lost.  The main content is,
however, preserved unchanged.]


The case against C


P.J. Moylan
Department of Electrical and
Computer Engineering
The University of Newcastle
N.S.W. 2308,
Australia

eepjm@wombat.newcastle.edu.au
Fax: +61 49 60 1712

Abstract

The programming language C has been in widespread use since the
early 1970s, and it is probably the language most widely used by
computer science professionals. The goal of this paper is to argue
that it is time to retire C in favour of a more modern language.
The choice of a programming language is often an emotional issue
which is not subject to rational discussion. Nevertheless it is
hoped to show here that there are good objective reasons why C is
not a good choice for large programming projects. These reasons are
related primarily to the issues of software readability and
programmer productivity.

Keywords: Programming languages, C, C++

Introduction

This note was written after I had found myself saying and writing
the same things over and over again to different people. Rather
than keep repeating myself, I thought I should summarize my
thoughts in a single document.

Although the title may sound frivolous, this is a serious document.
I am deeply concerned about the widespread use of C for serious
computer programming. The language has spread far beyond its
intended application area. Furthermore, the C enthusiasts seem to
be largely in ignorance of the advances which have been made in
language design in the last 20 years. The misplaced loyalty to C
is, in my opinion, just as serious a problem among professionals as
the BASIC problem is among amateurs.

It is not my intention in this note to debate the relative merits
of procedural (e.g. Pascal or C), functional (e.g. Lisp), and
declarative languages (e.g. Prolog). That is a separate issue. My
intention, rather, is to urge people using a procedural language to
give preference to high-level languages.

In what follows, I shall be using Modula-2 as an example of a
modern programming language. This is simply because it is a
language about which I can talk intelligently. I am not suggesting
that Modula-2 is perfect; but it at least serves to illustrate that
there are languages which do not have the failings of C.

I do not consider C++ to be one such language, by the way. The
question of C++ will be considered in a later section. For now, it
is worth pointing out that almost of the criticisms of C which will
be listed in this note apply equally well to C++. The C++ language
is of course an improvement on C, but it does not solve many of the
serious problems which C has.

Some background

The first C compiler, on a PDP-11, appeared in about 1972. At the
time the PDP-11 was a relatively new machine, and few programming
languages were available for it; the choice was essentially limited
to assembly language, BASIC, and Fortran IV. (Compilers and
interpreters for some other languages had been written, but were
not widely distributed.) Given the obvious limitations of these
languages for systems-level programming, there was a clear need for
a new language.

This was also the era in which software designers were coming to
accept that operating systems need not be written in assembly
language. The first version of Unix (1969-70) was written in
assembly language, but subsequently almost all of it was rewritten
in C. To make this feasible, however, it was necessary to have a
language which could bypass some of the safety checks which are
built in to most high-level languages, and allow one to do things
which could otherwise be done only in assembly or machine language.
This led to the concept of intermediate-level machine-oriented
languages.

C was not the only such language, and certainly not the earliest.
In fact, a whole rash of machine-oriented languages appeared at
about that time. (I was the author of one such language, SGL, which
was used for a number of projects within our department in the
1970s. It was retired, as being somewhat old-fashioned, in the
early 1980s.) These languages had a strong family resemblance to
one another; not because the authors were copying from one another
(in my own case, SGL had reached a fairly advanced stage before I
became aware of the existence of C), but because they were all
influenced by the same pool of ideas which were common property at
the time.

Why C became popular

The history of C is inextricably linked with the history of Unix.
The Unix operating system is itself written in C, as are the
majority of utility programs which come with Unix; and to the best
of my knowledge a C compiler comes with every distribution of Unix,
whereas it is harder to get compilers for other languages under
Unix. Thus, we need to look at the reasons for the rapid spread of
Unix.

The obvious reasons are cost and availability. Unix was distributed
at virtually no cost, and sources were available to make it easy to
port it to other systems. A number of useful utilities were
available within Unix - written in C, of course - and it was
usually simpler to leave them in C than to translate them to
another language. For a Unix user who wanted to do any programming,
a competence in C was almost essential.

Since then, C has remained widespread for the same reasons as why
Fortran has remained widespread: once a language has built up a
large user base, it develops an unstoppable momentum. When people
are asked "why do you use C?", the most common answers are (a) easy
availability of inexpensive compilers; (b) extensive subroutine
libraries and tools; (c) everyone else uses it. The ready
availability of compilers, libraries, and support tools is, of
course, a direct consequence of the large number of users. And, of
course, each generation of programming educators teaches students
its favourite language.

Portability is also given as a reason for the popularity of C, but
in my opinion this is a red herring. A subset of C is portable, but
it is almost impossible to convince programmers to stick to that
subset. The C compiler which I use can generate warning messages
concerning portability, but it is no effort at all to write a
non-portable program which generates no compiler warnings.

Why C remains popular

With advances in compiler technology, the original motivation for
designing medium-level languages - namely, object code efficiency -
has largely disappeared. Most other machine-oriented languages
which appeared at about the same time as C are now considered to be
obsolete. Why, then, has C survived?

There is of course a belief that C is more appealing to the "macho"
side of programmers, who enjoy the challenge of struggling with
obscure bugs and of finding obscure and tricky ways of doing things.

The conciseness of C code is also a popular feature. C programmers
seem to feel that being able to write a statement like

**p++^=q++=*r---s

is a major argument in favour of using C, since it saves
keystrokes. A cynic might suggest that the saving will be offset by
the need for additional comments, but a glance at some typical C
programs will show that comments are also considered to be a waste
of keystrokes, even among so-called professional programmers.

Another important factor is that initial program development is
perceived to be faster in C than in a more structured language. (I
don't agree with this belief, and will return later to this point.)
The general perception is that a lot of forward planning is
necessary in a language like Modula-2, whereas with C one can sit
down and start coding immediately, giving more immediate
gratification.

Do these reasons look familiar? Yes, they are almost identical to
the arguments which were being trotted out a few years ago in
favour of BASIC. Could it be that the current crop of C programmers
are the same people who were playing with toy computers as
adolescents? We said at the time that using BASIC as a first
language would create bad habits which would be very difficult to
eradicate. Now we're seeing the evidence of that.

Advances in language design

It would be a gargantuan task to track down and document the origin
of what we know today
about programming language design, and I'm
not going to do that. Many of the good ideas first appeared in
obscure languages, but did not become well-known until they were
adopted into more popular languages. What I want to do in this
section is simply note a few important landmarks, as they appeared
in the better-known languages.

Undoubtedly the most important step forward was the concept of a
high-level language, as exemplified in Fortran and Cobol. What
these languages gave us were at least three important new
principles: portability of programs across a range of machines; the
ability to tackle new problems which were just too big or too
difficult in assembly language; and the expansion of the pool of
potential programmers beyond that small group willing and able to
probe the obscure mysteries of how each individual processor worked.

Needless to say, there were those who felt that "real" programmers
would continue to work in machine language. Those "real"
programmers are still among us, and are still arguing that their
special skills and superior virtue somehow compensate for their
poor productivity.

The main faults of Fortran were a certain lack of regularity, some
awkward restrictions which in hindsight were seen to be
unnecessary, and some features which were imposed more because of
machine dependencies than for programmer convenience. (The only
justification for the three-way IF of Fortran II, for example, was
that it mapped well into the machine language of a machine which is
now obsolete.) Some of these faults were corrected in Algol 60,
which in turn inspired a large number of Algol-like languages. The
main conceptual advance in Algol was probably its introduction of
nesting in control structures, which in turn led to cleaner control
structures.

The structured programming revolution is sometimes considered to
date from Dijkstra's famous "GOTO considered harmful" letter.
Although this is an oversimplification, it is true that the
realisation that the GOTO construct was unnecessary - and even
undesirable - was an important part of the discovery that
programming productivity was very much linked to having
well-structured and readable programs. The effect this had on
language design was a new emphasis on "economy of concept"; that
is, on having languages which were regular in design and which
avoided special cases and baroque, hard to read constructs.

The important contribution of Pascal was to extend these ideas from
control structures to data structures. Although the various data
structuring mechanisms had existed in earlier languages - even C
has a way of declaring record structures - Pascal pulled them all
together in an integrated way.

Pascal can still be considered to be a viable language, with a
large number of users, but it has at least two conspicuous faults.
First, it was standardized too early, which meant that some
niggling shortcomings - the crude input/output arrangements, for
example - were never fixed in the language standard. They are fixed
in many implementations of Pascal, but the repairs go outside the
standard and are therefore nonportable. The second major fault is
that a Pascal program must (if one wants to conform to the
standard) exist as a single file, which makes the language
unsuitable for really large programs.

More recently, there has been a lot of emphasis on issues like
reusable software and efficient management of large programs. The
key idea here is modularity, and this will be discussed in the
following section.

Now, where does C fit into this picture? The answer is that C is
built around lessons which were learnt from Algol 60 and its early
successors, and that it does not incorporate much that has been
learnt since then. We have learnt some new things about language
design in the last 20 years, and we do know that some of the things
that seemed like a good idea at the time are in fact not such good
ideas.  Is it not time to move on to D, or even E?

Modularity

In its very crudest sense, modularity means being able to break a
large program into smaller, separately compiled sections. C allows
this. Even Fortran II allowed it. This, however, is not enough.

What modularity is really about is data encapsulation and
information hiding. The essential idea is that each module should
take care of a particular sort of data, and that there should be no
way of getting at that data except via the procedures provided by
that module. The implementation details of the data structures
should be hidden. There should be no way to call a procedure unless
the module explicitly exports that procedure. Most importantly,
callers of a module should not need to know anything about the
module except for the declarations and comments in its "visible"
section. It should be possible to develop a module without having
any knowledge of the internal structure of any other module.

The advantages should be obvious. At any given time a programmer
need only be concerned with a short section of program - typically
a few pages long - without having to worry about side-effects
elsewhere in the program. It is possible to work with complex data
structures without having to worry about their internal detail. It
is possible to replace a module with a newer version - and this
even includes the possibility of a complete overhaul of the way a
data structure is implemented - without having to alter or re-check
the other modules. In a team programming situation, the
coordination problems become a lot simpler.

If the hardware supports memory segmentation, then the data in each
module are protected from accidental damage by other modules
(except to the extent to which pointers are passed as procedure
parameters). This makes errors easier to detect and to fix. Even
without hardware protection the incidence of programming errors is
reduced, because error rates depend on program complexity, and a
module a few pages long is far less complex than a monolithic
hundred-page program.

Now, modular programming is possible in C, but only if the
programmer sticks to some fairly rigid rules:

-	Exactly one header file per module. The header should contain the
function prototypes and typedef declarations to be exported, and
nothing else (except comments).

-	The comments in a header file should be all that an external
caller needs to know about the module. There should never be any
need for writers to know anything about the module except what is
contained in the header file.

-	Every module must import its own header file, as a consistency
check.

-	Each module should contain #include lines for anything being
imported from another module, together with comments showing what
is being imported. The comments should be kept up-to-date. There
should be no reliance on hidden imports which occur as a
consequence of the nested #include lines which typically occur when
a header file needs to import a type definition or a constant from
elsewhere.

-	Function prototypes should not be used except in header files.
(This rule is needed because C has no mechanism for checking that a
function is implemented in the same module as its prototype; so
that the use of a prototype can mask a "missing function" error.)

-	Every global variable in a module, and every function other than
the functions exported via the header file, should be declared
static.

-	The compiler warning "function call without prototype" should be
enabled, and any warning should be treated as an error.

-	For each prototype given in a header file, the programmer should
check that a non-private (i.e. non-static, in the usual C
terminology) function with precisely the same name has its
implementation in the same module. (Unfortunately, the nature of
the C language makes an automatic check impossible.)

-	Any use of grep should be viewed with suspicion. If a prototype
is not in the obvious place, that's probably an error.

-	Ideally, programmers working in a team should not have access to
one another's source files. They should share only object modules
and header files.

Now, the obvious difficulty with these rules is that few people
will stick to them, because the compiler does not enforce them. A
great many people think of #include as a mechanism for hiding
information, rather than as a mechanism for exporting information.
(This is shown by the distressingly common practice of writing
header files without comments.) The counter-intuitive meaning of
static is a disincentive for using it properly. Function prototypes
tend to be thrown into a program in a haphazard way, rather being
confined to header files. Programmers who think of comments as
things to be added after writing the code will hardly accept the
discipline of keeping the comments on their #include lines
up-to-date. A good many programmers prefer not to enable warning
messages in their compilations, because it produces too many
distracting and "unimportant" messages. Finally, the notion of
having precisely one header file per module runs counter to
traditions which have been built up among the community of C users.

And, what is worse, it takes only one programmer in a team to break
the modularity of a project, and to force the rest of the team to
waste time with grep and with mysterious errors caused by
unexpected side-effects. I believe it is well known that almost
every programming team will include at least one bad programmer. A
modular programming language shields the good programmers from at
least part of the chaos caused by the bad programmers. C doesn't.

To complicate matters, it is easy even for good programmers to
violate, by accident, the rules for proper modularity. There is no
mechanism in C for enforcing the rule that every prototype
mentioned in a header file is matched by an implementation in the
same module, or even for checking that the function names in the
implementation module match those in the header file. It is easy to
forget to make internal functions private, since the default
behaviour is back to front: the default is to make all functions
exportable, whether or not a prototype is used. It is easy, too, to
lose track of what is being imported from where, because the
crucial information is locked away in comments which the compiler
doesn't check. The only way I know of for checking what is being
imported is to comment out the #include lines temporarily, to see
what error messages are produced.

In most modular programs, some or all modules will need an
initialization section. (You can't initialize data structures from
outside the module, since they aren't supposed to be visible from
outside the module.) This means that the main program of a C
program must arrange to call the initialization procedures in the
correct order. The correct order is bottom-up: if module MA depends
on module MB, then module MB must be initialized before module MA.
Any language supporting modular programming will work this out for
you, and perform the initialization in the correct order. (It will
also report circular dependencies, which in most cases reflect an
error in overall program design.) In C, you have to work this out
by hand, which can be a tedious job when there are more than about
a dozen modules. In practice, I have found that it is almost
impossible to avoid circular dependencies in a large C program,
whereas I have rarely struck such dependencies in Modula-2
programs. The reason is that the Modula-2 compiler/linker
combination catches circularities at an early stage, before it has
become too difficult to re-design the program. In C, such errors do
not show up until mysterious errors appear in the final testing.

The hazards of #include

I have often heard it said that the #include directive in C has
essentially the same functionality as the IMPORT of Modula-2 and
similar languages. In fact there is a profound difference, as I
shall now attempt to show.

Consider a header file m2.h which contains the lines

#include <m1.h>
	/* FROM m1 IMPORT stInfo */

void AddToQueue
(stInfo* p);

and suppose that several other modules contain a  #include <m2.h>.
Consider the following sequence of events, which could easily
happen in any programming project:

(a)	some of the modules which import from m2 are compiled;

(b)	as the result of a design change, the typedef defining  stInfo
in  m1.h  is altered;

(c)	the remaining modules which import from m2 are compiled.

At this point, the overall program is in an inconsistent state,
since some of the modules were compiled with an obsolete
definition; but the error will probably not be caught by the
compiler or linker. If you ever wondered why you keep having to do
a "Compile All" in order to eliminate a mysterious bug, this is
part of the reason.

The reason why this problem occurs in C, whereas it does not occur
in languages designed for modular programming, is that a C header
file is a pure text file, with no provision for containing a "last
compiled" time or other mechanism for consistency checking. (This
is also why C compilers appear to be painfully slow when compared
with, for example, a typical Modula-2 compiler. It usually takes
longer to read a header file than it does to read a symbol file.)

Another nasty consequence of reading the header file literally is
that information in the header file is treated as if it were in the
file which contains the #include. There is no "fire wall" around
the header file. Everything declared in one header file is
automatically exported, in effect, to the header files mentioned in
every following #include. This can lead to obscure errors which
depend on the order of the #include lines. It also means that the
effect of a header file is not under the full control of the person
who wrote it, since its behaviour depends on what comes before it
in the importing module.

Similar problems exist with other preprocessor directives, such as
#define. This point is not always fully understood: the effects of
a #define persist through an entire compilation, including any
included files. There is no way in C to declare a local literal
constant.

Have you ever had the experience of having the compiler report an
error in a library function you're not even calling, where the real
error turns out to be a misplaced semicolon in some completely
unrelated file? Such non-local effects make a mockery of modularity.

Another problem with #include is that it is an all-or-nothing
proposition. (This can be resolved by having multiple header files
per module; but that means putting the header files under the
control of the importer, not the exporter, which creates the risk
of undetected discrepancies between a module and its header
file(s). In any case, such a practice creates major headaches in
terms of book-keeping and naming conventions.) How many programmers
read the  whole of a header file before deciding to include it?
Very few, I suspect. The more likely situation is that the #include
imports some names which the importer doesn't know about. This can
be a disaster if, as sometimes happens, two functions happen to
have the same name and the same parameter types. (If you think this
is unlikely, just think of the obsolete versions of software which
are left around when you copy files from place to place.) The
compiler won't complain; it will simply assume you were in an
expansive mood and decided to write a function prototype twice. The
linker might complain, but you can't guarantee it.

As a result, it is possible to import a function which is different
from the function you thought you were importing, and there is not
necessarily any warning message. Part of the problem here is that
the mechanism by which the linker chooses which functions to link
in has no connection with the mechanism by which the compiler
checks function prototypes. There is no way of specifying that a
particular header file belongs to a particular module.

Note, too, that an unused prototype is never picked up as an error.
(This is another reason for insisting that prototypes be used only
in header files, and nowhere else. This does not solve the problem,
but it reduces the amount of manual checking which has to be done.)
While this will not cause a program to run incorrectly, it adds to
the confusion to be faced by future maintainers of the program.

The speed of program development

A claim that is often heard is that initial program development is
fast in C because it is easy to get to the point of the "first
clean compile". (This is also an argument which is popular with the
BASIC enthusiasts.) This property is contrasted with what happens
with languages like Modula-2, where - it is said - a lot of forward
planning is necessary before any progress is made on the coding.
The conclusion is that C programmers get more immediate feedback.

This argument is silly in at least three ways. First, the claim
relies at least partly on the fact that C compilers are more
generous in accepting doubtful code than are compilers for
higher-level languages. Where is the virtue in that? If the
compilation of code containing errors is seen as a significant step
forward, you can get that in any language. All you have to do is
ignore the error messages.

Second, the "first clean compile" is a fairly meaningless measure
of how far you have progressed. It might be a significant milestone
if you follow an approach to programming where the coding is not
started until most of the design work has been completed, but not
otherwise. Under the "code, then debug" philosophy of programming,
you still have most of your work ahead of you after the first
compilation.

Finally, my own experience is that even the original statement is
incorrect. I find that I reach the "first clean compile" stage
within the first few minutes of starting work. This is because I
prefer developing programs through stepwise refinement (also known
as top-down design combined with top-down coding). The very first
thing I compile consists of perhaps half a dozen lines of code,
plus a couple of dozen lines of comments. It is so short that it
will compile without errors either immediately, or after
discovering errors which are obvious and easy to repair.

What about the subdivision of a large program into modules? This
takes a lot less forward planning than is commonly supposed. With
stepwise refinement, and with the philosophy that the function of a
module is to look after a data type, one tends to discover what
modules are needed as the program development proceeds.
Furthermore, true modularity makes it very easy to construct and
test the program in stages, because of the property that changes in
the internal details of a module can be made independently of what
is happening outside that module.

In cases where I have kept a log of the time I have spent on a
project, I have found that I spend about twice the time to get a C
program working as to solve a problem of equivalent complexity
using Modula-2. The difference has nothing to do with typing speed
- since the source files tend to be of about the same length - but
in the time spent in debugging. In Modula-2, the job is essentially
complete once I have typed in the last module, and debuggers are
rarely needed. In C, a good debugger is indispensable.

To a project manager, this is a very important factor. In a big
project, the cost of paying the programmers is typically the
second-biggest budget item (after administrative overheads), and
sometimes even the biggest. A productivity difference of 50% can
make the difference between making a large profit or a large loss
on the project.

Pointers: the GOTO of data structures

Despite all the advances which have been made in the theory and
practice of data structures, pointers remain a thorn in everyone's
side. Some languages (e.g. Fortran, Lisp) manage to get by without
explicit pointers, but at the cost of complicating the
representation of some data structures. (In Fortran, for example,
you have to simulate everything using arrays.) For anyone working
with almost any reasonably advanced application, it is hard to
avoid the use of pointers.

This does not mean that we have to like them. Pointers are
responsible for a significant amount of the time spent on program
debugging, and a large proportion of the complexity which makes
program development difficult. A major challenge for software
designers in languages like Modula-2 is to restrict the pointer
operations to the low-level modules, so that people working with
the software don't have to deal with them. A major, and largely
unsolved, problem for language designers is to find mechanisms
which save programmers the trouble of having to use pointers.

Having said that, one can also say that a distinction can be drawn
between essential and inessential pointers. An essential pointer,
in the present context, is a pointer which is required in order to
create and maintain a data structure. For example, a pointer is
needed to link a queue element to its successor. (The language
might or might not explicitly call it a pointer, but that is a
separate issue. Whatever the language, there must be some way of
implementing the "find successor" operation.) An inessential
pointer is one which is not needed as part of implementing a data
structure.

In a typical C program, the inessential pointers outnumber the
essential pointers by a significant amount. There are two reasons
for this. The first is that C traditions encourage programmers to
create pointers even where equally good access methods already
exist; for example, for stepping through the elements of an array.
(Should we blame the language for the persistence of this bad
habit? I don't know; I simply note that it is more prevalent among
C programmers than among those who prefer other languages.)

The second reason is the C rule that all function parameters must
be passed by value. When you need the equivalent of a Pascal VAR
parameter or an Ada inout parameter, the only solution is to pass a
pointer. This is a major contributor to the unreadability of C
programs. (To be fair, it should be admitted that C++ does at least
provide a solution for this problem.)

The situation worsens when it becomes necessary to pass an
essential pointer as an inout parameter. In this case, a pointer to
a pointer must be passed to the function, which is confusing for
even the most experienced programmers.

Execution-time efficiency

There appears to be a widespread belief among C programmers that -
because the language is close to machine language - a C program
will produce more efficient object code than an equivalent program
written in a high-level language.

I'm not aware of any detailed study of this question, but I have
seen the results of a few informal studies comparing Modula-2 and C
compilers. The results were that the code produced by the Modula-2
compilers was faster and more compact than that produced by the C
compilers. This should not be taken as a definitive answer, since
the studies were not extensive enough, but it does indicate that C
programs might not be as efficient as is generally thought.

I believe I've also seen claims - although I can't recall the
details at this distance in time - that C compilers produced better
code than an assembly language programmer did. I observed a similar
phenomenon when testing my SGL compiler many years ago. The reason
in that case seemed to be that the compiler did a reasonably good
job on things like register allocation, whereas one can suffer from
lapses of concentration when having to concentrate too much on the
fine detail.

The general rule seems to be that a high-level language compiler
will out-perform a lower-level language compiler, mainly because
the high-level language compiler has more scope for making
decisions about how to generate the code. If you do things in C
like setting up a pointer to an array rather than using subscripts,
you are taking that decision away from the compiler. Your approach
might produce more efficient code, but to be sure of that you have
to know quite a lot about the instruction timings on the machine
you are using, and about the code generation strategies of your
compiler. In addition, the decision is a non-portable one,
potentially leading to major inefficiencies if you switch to
another machine or another version of the compiler.

More importantly, the speed of a program tends to depend more on
the global strategies adopted - what sort of data structures to
use, what sorting algorithms to use, and so on - than the
micro-efficiency issues related to precisely how each line of code
is written. When working in a low-level language like C, it becomes
harder to keep track of the global issues.

It is true that C compilers produced better code, in many cases,
than the Fortran compilers of the early 1970s. This was because of
the very close relationship between the C language and PDP-11
assembly language. (Constructs like *p++ in C have the same
justification as the three-way IF of Fortran II: they exploit a
special feature of the instruction set architecture of one
particular processor.) If your processor is not a PDP-11, this
advantage is lost.

What about C++?

The language C++ is supposed to overcome some of the faults of C,
and to a certain extent it does this. It does, however, have two
major drawbacks. It is much more complex than it needs to be, which
can lead programmers either to ignore the extended features or to
use them in an inappropriate way. The second problem is that the
language tries to maintain compatibility with C, and in so doing
retains most of the unsafe features.

This second problem means that most of the faults discussed in
earlier sections are also faults of C++. Type checking is still
minimal, and programmers are still permitted to produce weird and
baroque constructs which are hard to read. Strangest of all, there
is still no support for modularity beyond the crude #include
mechanism. This is a little surprising: modular programming and
object-oriented programming complement each other very nicely, and
given all the effort that the designers of C++ must have had to put
into the object-oriented extensions it is rather disappointing that
they did not put in that slight extra effort which could have
resulted in a major improvement to the language.

Some of the features related to object-oriented programming are
complicated, and open to misuse by programmers who do not fully
understand them. For safety, I would prefer to see programmers
learn object-oriented programming using a cleaner implementation
(e.g. Smalltalk, Modula-3) before being let loose on C++.

The ability to pass function parameters by reference is a definite
bonus, but the mechanism chosen for doing this is unnecessarily
messy. The only motivation I can see for implementing it this way
is to satisfy the Fortran programmers who miss the EQUIVALENCE
construct.

Operator and function overloading is a mixed blessing. In the hands
of a competent programmer it can be a major virtue; but when used
by a sloppy programmer it could cause chaos. I would feel happier
about this feature if C++ compilers had some way to detect sloppy
programmers.

If there is a discrepancy between a function and its prototype, is
this an error, or is it a deliberate overloading? Most commonly it
will be an error, but in some such cases the C++ compiler will make
the optimistic assumption. One has to be a little suspicious of a
language improvement which increases the probability of undetected
errors.

I'm not yet sure how to feel about multiple inheritance. It is
powerful, in the same way that goto is powerful, but is it the sort
of power we want? I have a nagging suspicion that at some time in
the future our guidelines for "clean programming" will include a
rule that object inheritance should always be restricted to single
inheritance. However, I'm prepared to admit that the evidence is
not yet in on this question.

In brief, C++ introduces some new problems without really solving
the original problems. The designers have opted to continue with
the C tradition that "almost everything should be legal". In my
view, this was a mistake.

Libraries vs. language features

One of the popular features of C++ is the large set of library
functions which is usually distributed with it. This is, indeed, a
desirable feature, but it should not be confused with the inherent
properties of the language. Good libraries can be written for any
language; and in any case most reasonable compilers allow one to
call "foreign" procedures written in other languages.

More generally, people sometimes say they like C because they like
things like argc and argv, printf, and so on. (I don't - I've had
so much trouble with printf, sscanf, and the like that I've been
forced into writing alternative I/O formatting functions - but
that's a separate issue.) In many cases, the functions they like,
and point to as examples of "portable C" are peculiar to one
particular compiler, and not even mentioned in whichever C standard
they consider to be the standard standard. The desirability or
otherwise of various library routines is a legitimate subject for
debate, but it is an issue separate from that of language
properties.

There is just one way in which these functions differ as a result
of genuine language differences from the procedures available with
other languages, and that is the C rule which permits functions
with variable numbers and types of parameters. While this feature
does have certain advantages, it necessarily involves a relaxation
of type checking by the compiler. I personally have wasted hours of
valuable debugging time over things like printing out a long int
with a format appropriate to an int, and then not being able to
discover why my computations were producing the wrong value. It
would have been much faster, even if slightly more verbose, to call
type-safe procedures.

Concluding remarks

Nothing in this document should be interpreted as a criticism of
the original designers of C. I happen to believe that the language
was an excellent invention for its time. I am simply suggesting
that there have been some advances in the art and science of
software design since that time, and that we ought to be taking
advantage of them.

I am not so naive as to expect that diatribes such as this will
cause the language to die out. Loyalty to a language is very
largely an emotional issue which is not subject to rational debate.
I would hope, however, that I can convince at least some people to
re-think their positions.

I recognise, too, that factors other than the inherent quality of a
language can be important. Compiler availability is one such
factor. Re-use of existing software is another; it can dictate the
continued use of a language even when it is clearly not the best
choice on other grounds. (Indeed, I continue to use the language
myself for some projects, mainly for this reason.) What we need to
guard against, however, is making inappropriate choices through
simple inertia.



From rideau@clipper Wed Apr 21 02:08:10 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18506; Wed, 21 Apr 93 02:08:09 +0200
Return-Path: <rideau@clipper>
Received-Date: Wed, 21 Apr 93 02:08:09 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07391; Tue, 20 Apr 93 17:03:36 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304210002.AA18438@clipper.ens.fr>
Subject: Re: MUSIC [jjl1] [far29]
To: csjjlay@knuth.mtsu.edu (JJ Lay)
Date: Wed, 21 Apr 93 2:02:41 MET DST
Cc: moose-programmers@sfu.ca
In-Reply-To: <m0nkQKT-000czgC@knuth.mtsu.edu>; from "JJ Lay" at Apr 17, 93 10:46 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(consider my reply to [jjl2] as far28)
(BTW, about languages, if there is an isomorphism from code to
data that maps GOTO into pointers, why not use this isomorphism
to map all known methods that eliminate GOTO (that is, if I wasn't
mistaken, exceptions in loops and other structures) into methods
to elimnate pointers ? Why not map from one to the other (code/data)
everything we know in the first and don't currently have in the
other ? Have anyone got the paper where the isomorphism is exhibited ?)

(To jj: why do you use such format for your messages, moreover with
page feed characters ? It's not easy to quote, etc)

>>                                         MUSIC
>>                               Multimedia USer InterFace
>> 
>>                              Copyright JJ Lay April 1993
>> 
>>                                     REVISION 0.00
>>                                     10 APRIL 1993
>>                                     09:00 PM CST
>> 
>>             I.  INTRODUCTION
>> 
>>             A. SCOPE AND PURPOSE
>>             The following document will cover all aspects of a human-
>>             computer interface, and is meant to serve as a definitive
>>             guide for programmers.  There are two reasons for this:  all
>>             programs using written for this interface will have a common
>>             "look-and-feel" resulting in a smaller learning curve for
>>             users.  Secondly, development time for programs should be
>>             drastically reduced becuase of the underlying assumptions
>>             built into the interface.
 If it's possible, I'd like the interface to be the same for programmers
and users: programmers are only lower level users (again, see the HP28/48
calculators for the beginning of this concept).
 Moreover, we should not conveive independently the interface and what is
to be intefaced: the Mac and/or Windows offer a splendid interface; but
as it was not designed to be an interface to anything in particular, it
is found to be an interface to nothing at all. On the opposite, Unix
was conceived without interface; the most immediate interface (=text) was
thus choosen, then X-Window can do nothing to this and is not adapted to
any Unix utility.
 Finally, the interface should be generic, (as the HLL); that is, you
can build an interface to generic arrays; then, when you have an 'a
array object, the interface is immediately defined from the 'a interface
(which, if no interface is ever given by the programmer/user, will
ultimately be built from atomic types interface). Of course, there is
no reason to be only one type of interface to an object. Then, a given
object may have a default interface separate from its type default. This
leads to object comments: how should comments on an object should be
implemented ? This issue is important, as it links interface to language
and object implementation (=outer kernel).

>>             B. OVERVIEW
>>             The objective of this MUSIC (as it will be called from here
>>             on) will be to provide an user interface that is easy to use
>>             for both user and programmer.  Historically, most interfaces
>>             have been one or the other.  For example, a text oriented
>>             interface is easy to program but rather cumbersome for an
>>             end-user.  An advanced graphical environment such as
>>             OSF/Motif is somewhat complex to program in, but is easier
>>             for beginnners to learn based on my experience.  There is
>>             one exception - Microsoft Windows - which is difficult for
>>             everyone to use.
Text interfaces are also cumbersome for the programmer; however, nobody
managed to build a graphical interface that satisfied programmers: none
had powerful enough expressibility, or else wasn't portable (/ported)
at all.
Text is good (=known symbols, etc);
plain, linear text is bad.
We can now have structured non-linear text.
Of course, for ultimate portability reasons, plain text can be used
as an intermediate coding for data exchange between foreign systems.

>>             There are two extremely important philosophies on which
>>             MUSIC is built.
>>             The first:  The end-user is more concerned with getting a
>>             job done and producing results.  A computer is a tool.  She
>>             is not concerned with how the tool works, but with what it
>>             produces.  An example: a journalist wants to type his news
>>             article.  He doesn't want to worry about which word
>>             processor to use or which looks the slickest.  He wants his
>>             article typed, formatted, and printed.  The interface should
>>             hide as much about the inner-workings of the program as
>>             possible and make intelligent assumptions when needed.  This
>>             type of assumption could be a "document-oriented" approach
>>             versus a "process-oriented approach."  Contemporary
>>             operating-systems makes the user worry about which program
>>             to use, if the files will be compatible, etc.  Who cares?
 Again, programmers ARE users; they use a language environment; and they
seldom are but programmers; for example, they can use mail utilities :-)

>>             The second assumption: Certain end-users have specialized
>>             needs.  MUSIC will not be able to meet all users' needs.
 It may, with genericity combined with modularity and late binding.

>>             Therefore the user should be able to replace those parts of
>>             the interface with components that better meets his needs.
>>             It should be "customizable to its atoms."  Equivalent
>>             components can be exchanged without any side-effects.
(THAT's modularity)(the user being able to do that is late binding)

>>             C. SYSTEM REQUIREMENTS AND CONSTRAINTS
>>             The basic hardware requirements are as follows:
>>             a 386DX operating at 33MHz with 2Mb of RAM and 80Mb of
>>             external storage (the term hard disk was avoided because of
>>             alternative media such as flopticals and network devices).
>>             The video quality for a graphical interface (GUI) is
>>             recommended to be a VGA monitor and adapter (640 x 480
>>             resolution) with 1 Mb of RAM capable of 256 colors.  Text
>>             quality can be as poor as a text-only dumb terminal.  Input
>>             can come from a number of various devices.  Currently,
>>             keyboard and mouse are considered the main input channels.
>>             MUSIC will have no such prejudice.  It will be built
>>             assuming anything can give input.  The same will hold for
>>             output.
 That may be requirements for the first implementation of it. But remember
we want to be PORTABLE.


>>             II. INFORMATION DESCRIPTION
>> 
>>             A. OVERVIEW
>>             The user will have a variety of information which needs to
>>             be processed.  Therefore MUSIC should handle it all.  Basic
>>             input can take the form of keyboard commands, mouse motions
>>             and clicks, and voice commands.  Complex input can be in the
>>             form of hand motions using a PowerGlove type device, video
>>             and audio from a camcorder mounted on the monitor, or
>>             thoughts from some unknown device.  Other inputs not known
>>             should also be handled.  Similarly for output, standard
>>             output is text on a screen, icons and graphics, audio in the
>>             form of beeps, horns, and simulated voice.  Full motion
>>             video and audio or perhaps 3-D holographics.  Information to
>>             and from users will be shipped to processes through "ports."
 As other input devices that don't exist will appear, we have to be as
IO device independent as we can get. Let's not assume even the screen/keyboard
assumption until really necessary (however, this can be the DEFAULT assumption
for now)

[examples skipped with full agreements]
(I'd also like to thank Mr. Kahn at Borland for his user interfaces,
which are good examples, too -- however limited to subsystems, not a
full OS)



>> 							JJ LAY


	   ,
	Fare

P.S.: congratulations for your contribution !
P.P.S.: my phone company is happy: more than one hour from Brittany to
Paris answering my mail by minitel !

From ANDREASA@sofus.dhhalden.no Fri Apr 23 20:51:55 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03104; Fri, 23 Apr 93 20:51:54 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Fri, 23 Apr 93 20:51:54 +0200
Received: from whistler.sfu.ca ([142.58.103.1]) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25004; Fri, 23 Apr 93 11:45:56 -0700
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <21008-0@fenris.dhhalden.no>; Fri, 23 Apr 1993 20:36:35 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930423203619.448; 23 Apr 93 20:36:34 -0100
Message-Id: <MAILQUEUE-101.930423203610.416@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 23 Apr 93 20:36:10 +0100
Subject: The LL language. [arf6]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

About the LLL. I have been thinking on it for a while.

As I see it, there are two ways of doing it if we consider the Fare' way.

1) Create a assembly like language, interpreted.
Say with variables and a couple few commands as add, sub, mov etc.

2) Create a machine language like language, of course interpreted.
Say 64bit wide to ease the stepping up to 64bit platforms.

Just my 2 cents, phennig, francs and oeres :-)


Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From rideau@clipper Fri Apr 23 22:47:06 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA05770; Fri, 23 Apr 93 22:47:05 +0200
Return-Path: <rideau@clipper>
Received-Date: Fri, 23 Apr 93 22:47:05 +0200
Received: from whistler.sfu.ca ([142.58.103.1]) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02930; Fri, 23 Apr 93 13:38:22 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304232037.AA05595@clipper.ens.fr>
Subject: Re: The LL language. [arf6]
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Fri, 23 Apr 93 22:37:48 MET DST
Cc: moose-programmers@sfu.ca
In-Reply-To: <MAILQUEUE-101.930423203610.416@sofus.dhhalden.no>; from "Andreas Arff" at Apr 23, 93 8:36 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>> 
>> About the LLL. I have been thinking on it for a while.
>> 
>> As I see it, there are two ways of doing it if we consider the Fare' way.
>> 
>> 1) Create a assembly like language, interpreted.
>> Say with variables and a couple few commands as add, sub, mov etc.
>> 
>> 2) Create a machine language like language, of course interpreted.
>> Say 64bit wide to ease the stepping up to 64bit platforms.
>> 

my proposition is
3) Create a stack language, which is EASY to port and interpret, as well
as to simplify and compile, and which is near from the tree representation
obtained while parsing. Quick and efficient.


>>         --Andreas Arff          andreasa@dhhalden.no--

   ,
Fare


From ANDREASA@sofus.dhhalden.no Fri Apr 23 23:28:06 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06668; Fri, 23 Apr 93 23:28:05 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Fri, 23 Apr 93 23:28:05 +0200
Received: from whistler.sfu.ca ([142.58.103.1]) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06112; Fri, 23 Apr 93 14:21:18 -0700
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <24328-0@fenris.dhhalden.no>; Fri, 23 Apr 1993 23:21:12 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930423232058.352; 23 Apr 93 23:21:11 -0100
Message-Id: <MAILQUEUE-101.930423232054.320@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 23 Apr 93 23:20:54 +0100
Subject: Re: The LL language. [arf6]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> >>
> >> About the LLL. I have been thinking on it for a while.
> >>
> >> As I see it, there are two ways of doing it if we consider the Fare' way.
> >>
> >> 1) Create a assembly like language, interpreted.
> >> Say with variables and a couple few commands as add, sub, mov etc.
> >>
> >> 2) Create a machine language like language, of course interpreted.
> >> Say 64bit wide to ease the stepping up to 64bit platforms.
> >>
>
> my proposition is
> 3) Create a stack language, which is EASY to port and interpret, as well
> as to simplify and compile, and which is near from the tree representation
> obtained while parsing. Quick and efficient.

Yes, but you can do this in both case 1 and 2:-).

> >>         --Andreas Arff          andreasa@dhhalden.no--
>
>    ,
> Fare

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From rideau@clipper Mon Apr 26 14:04:43 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06451; Mon, 26 Apr 93 14:04:41 +0200
Return-Path: <rideau@clipper>
Received-Date: Mon, 26 Apr 93 14:04:41 +0200
Received: from whistler.sfu.ca ([142.58.103.1]) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19845; Mon, 26 Apr 93 04:57:19 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304261156.AA06265@clipper.ens.fr>
Subject: Re: The LL language. [arf6]
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Mon, 26 Apr 93 13:56:47 MET DST
Cc: moose-programmers@sfu.ca
In-Reply-To: <MAILQUEUE-101.930423232054.320@sofus.dhhalden.no>; from "Andreas Arff" at Apr 23, 93 11:20 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>>> About the LLL. I have been thinking on it for a while.
>>>
>>> As I see it, there are two ways of doing it if we consider the Fare' way.
>>>
>>> 1) Create a assembly like language, interpreted.
>>> Say with variables and a couple few commands as add, sub, mov etc.
>>>
>>> 2) Create a machine language like language, of course interpreted.
>>> Say 64bit wide to ease the stepping up to 64bit platforms.
>>>
>>
>> my proposition is
>> 3) Create a stack language, which is EASY to port and interpret, as well
>> as to simplify and compile, and which is near from the tree representation
>> obtained while parsing. Quick and efficient.
> 
> Yes, but you can do this in both case 1 and 2:-).
> 
 Method 2 is much slower and redundant. It should be excluded but for human
readability (using some kind of assembler/disassembler). Let's choose method 1.
 However, remember we define our LL up to a quickly computed isomorphism
(coding/decoding) so that each representation (host memory, disk, etc) may
choose a proper format (using numbers or pointers, etc). 

 BTW, there's an optimization problem: optimizations made for LLL code may be
bad choice for the compiled version, so that LLL code destined to be compiled and not
only interpreted should remember data about the source code that may allow better
optimization.


>>>         --Andreas Arff          andreasa@dhhalden.no--
>>
>>    ,
>> Fare

> Arff

   ,
Fare

From ANDREASA@sofus.dhhalden.no Mon Apr 26 14:08:00 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06492; Mon, 26 Apr 93 14:07:58 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Mon, 26 Apr 93 14:07:58 +0200
Received: from whistler.sfu.ca ([142.58.103.1]) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20039; Mon, 26 Apr 93 05:05:39 -0700
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <15212-0@fenris.dhhalden.no>; Mon, 26 Apr 1993 14:05:34 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930426140518.480; 26 Apr 93 14:05:32 -0100
Message-Id: <MAILQUEUE-101.930426140505.448@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 26 Apr 93 14:05:05 +0100
Subject: Re: The LL language. [arf6]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

> >>> About the LLL. I have been thinking on it for a while.
> >>>
> >>> As I see it, there are two ways of doing it if we consider the Fare' way.
> >>>
> >>> 1) Create a assembly like language, interpreted.
> >>> Say with variables and a couple few commands as add, sub, mov etc.
> >>>
> >>> 2) Create a machine language like language, of course interpreted.
> >>> Say 64bit wide to ease the stepping up to 64bit platforms.
> >>>
> >>
> >> my proposition is
> >> 3) Create a stack language, which is EASY to port and interpret, as well
> >> as to simplify and compile, and which is near from the tree representation
> >> obtained while parsing. Quick and efficient.
> >
> > Yes, but you can do this in both case 1 and 2:-).
> >
>  Method 2 is much slower and redundant. It should be excluded but for human
> readability (using some kind of assembler/disassembler). Let's choose method 1.
>  However, remember we define our LL up to a quickly computed isomorphism
> (coding/decoding) so that each representation (host memory, disk, etc) may
> choose a proper format (using numbers or pointers, etc).

Even though it may be easier to use no. 1, I belive it would be slower.
The tree would have to do lots of "strcpm" to chose the path to the compiled
code, while an integer represenation as in no. 2 would only need a "cmp".

I'm no language guru so I don't actually now myself, but at least it seems
as no. 2. would be faster.


> Fare

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From dmarer@td2cad.intel.com Mon Apr 26 17:59:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA11010; Mon, 26 Apr 93 17:59:23 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Mon, 26 Apr 93 17:59:23 +0200
Received: from whistler.sfu.ca ([142.58.103.1]) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28646; Mon, 26 Apr 93 08:57:06 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Mon, 26 Apr 93 08:57:04 -0700
Received: by td2cad (5.57/10.0i); Mon, 26 Apr 93 09:01:11 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA04564; Mon, 26 Apr 93 08:58:26 PDT
Message-Id: <9304261558.AA04564@iws804.intel.com>
Subject: Re: The LL language. [arf6] [dpm7]
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Mon, 26 Apr 93 8:58:23 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> > >>> About the LLL. I have been thinking on it for a while.
> > >>>
> > >>> As I see it, there are two ways of doing it if we consider the Fare' way.
> > >>>
> > >>> 1) Create a assembly like language, interpreted.
> > >>> Say with variables and a couple few commands as add, sub, mov etc.
> > >>>
> > >>> 2) Create a machine language like language, of course interpreted.
> > >>> Say 64bit wide to ease the stepping up to 64bit platforms.
> > >>>
> > >>
> > >> my proposition is
> > >> 3) Create a stack language, which is EASY to port and interpret, as well
> > >> as to simplify and compile, and which is near from the tree representation
> > >> obtained while parsing. Quick and efficient.
> > >
> > > Yes, but you can do this in both case 1 and 2:-).
> > >
> >  Method 2 is much slower and redundant. It should be excluded but for human
> > readability (using some kind of assembler/disassembler). Let's choose method 1.
> >  However, remember we define our LL up to a quickly computed isomorphism
> > (coding/decoding) so that each representation (host memory, disk, etc) may
> > choose a proper format (using numbers or pointers, etc).
> 
> Even though it may be easier to use no. 1, I belive it would be slower.
> The tree would have to do lots of "strcpm" to chose the path to the compiled
> code, while an integer represenation as in no. 2 would only need a "cmp".
> 
> I'm no language guru so I don't actually now myself, but at least it seems
> as no. 2. would be faster.
> 
> > Fare
> 
> Arff

One important thing to consider is portability - say machine A has a 64-bit
little endian word and machine B has a 32-bit big endian word...they aren't
going to be compatible.  This is assuming, of course, they need to!  You may
have heard that OSes like Conix have object code compatibility *across*
platforms...is this the intention here?

Dennis




From uunet.UU.NET!davgar!davgar.arlington.va.us!david Tue Apr 27 08:14:35 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28946; Tue, 27 Apr 93 08:14:34 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Tue, 27 Apr 93 08:14:34 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17664; Mon, 26 Apr 93 23:11:08 -0700
Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA02915; Tue, 27 Apr 93 02:11:04 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020955.26188; Tue, 27 Apr 1993 02:09:55 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Tue, 27 Apr 1993 00:57:43 EDT
Date:      Tue, 27 Apr 1993 00:57:40 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bdcbd49.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: The LL language. [arf6] [dpm7] [djg18]
Status: OR

> > > >>> About the LLL. I have been thinking on it for a while.
> > > >>>
> > > >>> As I see it, there are two ways of doing it if we consider the Fare' way.
> > > >>>
> > > >>> 1) Create a assembly like language, interpreted.
> > > >>> Say with variables and a couple few commands as add, sub, mov etc.
> > > >>>
> > > >>> 2) Create a machine language like language, of course interpreted.
> > > >>> Say 64bit wide to ease the stepping up to 64bit platforms.
> > > >>>
> > > >>
> > > >> my proposition is
> > > >> 3) Create a stack language, which is EASY to port and interpret, as well
> > > >> as to simplify and compile, and which is near from the tree representation
> > > >> obtained while parsing. Quick and efficient.
> > > >
> > > > Yes, but you can do this in both case 1 and 2:-).
> > > >
> > >  Method 2 is much slower and redundant. It should be excluded but for human
> > > readability (using some kind of assembler/disassembler). Let's choose method 1.
> > >  However, remember we define our LL up to a quickly computed isomorphism
> > > (coding/decoding) so that each representation (host memory, disk, etc) may
> > > choose a proper format (using numbers or pointers, etc).
> >
> > Even though it may be easier to use no. 1, I belive it would be slower.
> > The tree would have to do lots of "strcpm" to chose the path to the compiled
> > code, while an integer represenation as in no. 2 would only need a "cmp".
> >
> > I'm no language guru so I don't actually now myself, but at least it seems
> > as no. 2. would be faster.
> >
> > > Fare
> >
> > Arff
>
> One important thing to consider is portability - say machine A has a 64-bit
> little endian word and machine B has a 32-bit big endian word...they aren't
> going to be compatible.  This is assuming, of course, they need to!  You may
> have heard that OSes like Conix have object code compatibility *across*
> platforms...is this the intention here?
>
> Dennis

I still am wondering why we need a Low Level Language?  I thought the
purpose of this group was to build an advanced operating system for
our 386 PCs to replace DOS, Windows, and so on.  I can see refraining
from using the 386 segmented memory for the sake of making our OS more
portable to other architectures, but this group is begining to look
like an advanced operating system research project.  I don't think
that was the point.

As for a Low Level Language, what's wrong with a compiler to 386 
machine code?  I will admit that this requires writing assembly code 
to the compiler writers interfaces, but it means we don't need to 
write our own compilers and LLL interpreter.  

I will admit one thing, that having "object code compatibility 
*across* platforms" for selected executables would be a good thing, 
but this means, to me, that we have native mode executables and 
portable executables, and that we use native mode for the entire 
kernel, for most class implementations, most utilities, and many 
applications.  Some classes, utilities, and applications get done as 
portable executables.  General network distribution of applications is 
a reasonable use for portable executables.  

David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From rideau@clipper Tue Apr 27 14:22:08 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06505; Tue, 27 Apr 93 14:22:07 +0200
Return-Path: <rideau@clipper>
Received-Date: Tue, 27 Apr 93 14:22:07 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25355; Tue, 27 Apr 93 05:18:49 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304271218.AA06467@clipper.ens.fr>
Subject: Re: The LL language. [arf6]
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Tue, 27 Apr 93 14:18:16 MET DST
Cc: moose-programmers@sfu.ca
In-Reply-To: <MAILQUEUE-101.930426140505.448@sofus.dhhalden.no>; from "Andreas Arff" at Apr 26, 93 2:05 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>> Even though it may be easier to use no. 1, I belive it would be slower.
>> The tree would have to do lots of "strcpm" to chose the path to the compiled
>> code, while an integer represenation as in no. 2 would only need a "cmp".
>> 
>> I'm no language guru so I don't actually now myself, but at least it seems
>> as no. 2. would be faster.

 Of course I meant I preferred the binary solution, for I hate text-coded data.
Please excuse for getting mixed up with numbers.
 Moreover, I'd like host internal representation to use direct rountine
pointers rather than numbers (useful in disk representation and easier to
compress). A LLL loader module will translate module numbers into system
pointers. As usual a text format will be adopted for human interaction.

>> Arff

   ,
Fare


From ANDREASA@sofus.dhhalden.no Wed Apr 28 15:56:55 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA11272; Wed, 28 Apr 93 15:56:54 +0200
Return-Path: <ANDREASA@sofus.dhhalden.no>
Received-Date: Wed, 28 Apr 93 15:56:54 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25850; Wed, 28 Apr 93 06:53:01 -0700
Received: from odin.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <20325-0@fenris.dhhalden.no>; Wed, 28 Apr 1993 15:52:51 +0200
Received: From SOFUS/WORKQUEUE by odin.dhhalden.no via Charon-4.0A-VROOM 
          with IPX id 100.930428155237.288; 28 Apr 93 15:52:50 -0100
Message-Id: <MAILQUEUE-101.930428155231.480@sofus.dhhalden.no>
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 28 Apr 93 15:52:31 +0100
Subject: Re: The LL language. [arf6] [dpm7] [djg18] [arf7]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: OR

ACK!

> > I still am wondering why we need a Low Level Language?  I thought the
> > purpose of this group was to build an advanced operating system for
> > our 386 PCs to replace DOS, Windows, and so on.  I can see refraining
> > from using the 386 segmented memory for the sake of making our OS more
> > portable to other architectures, but this group is begining to look
> > like an advanced operating system research project.  I don't think
> > that was the point.

I have no objection against what you say. It is very true, but...

> We were trying to make it portable.
> I think that we should start kicking out "interesting" ideas that haven't been
> done b4 -- I think it was Hoare that suggested that language designers firmly
> resist the temptation to use any of their new untested ideas.
>
> If we continue debating new (research) ideas we'll never have a system.
>
> >
> > As for a Low Level Language, what's wrong with a compiler to 386
> > machine code?  I will admit that this requires writing assembly code
> > to the compiler writers interfaces, but it means we don't need to
> > write our own compilers and LLL interpreter.

Why must the code be compiled. I remember reading about an old language
that compiled the code whenever a program were started (it was most certainly
the system that did this, but it is only a vague memory:-). The user didn't
even notice it (or at least that is what was said)! You would gain the speed
of a compiled language, and the "object code compability across platforms".

> > I will admit one thing, that having "object code compatibility
> > *across* platforms" for selected executables would be a good thing,
> > but this means, to me, that we have native mode executables and
> > portable executables, and that we use native mode for the entire
> > kernel, for most class implementations, most utilities, and many
> > applications.  Some classes, utilities, and applications get done as
> > portable executables.  General network distribution of applications is
> > a reasonable use for portable executables.

Actually, if this was an intel OS only, I wouldn't care less about this
issue, but since this is not, a translated language becomes interesting.
IMHO I don't think speed would be an improtant issue here, I don't mean
we should sacrifice speed, only that it will be about equally fast.

> > David
>
> Michael

Me

PS. Is it normal to use large Y in You, Your and Yours in letters posted to
a company, to sound polite? It hasn't much with Moose to do, but could
someone please tell me. DS.

Still Me
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From winikoff@cs.mu.OZ.AU Wed Apr 28 14:39:11 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09335; Wed, 28 Apr 93 14:39:10 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Wed, 28 Apr 93 14:39:10 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24486; Wed, 28 Apr 93 05:36:03 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA28609
	Wed, 28 Apr 1993 22:35:25 +1000 (from winikoff)
Message-Id: <9304281235.28609@mulga.cs.mu.OZ.AU>
Subject: Re: The LL language. [arf6] [dpm7] [djg18]
To: moose-programmers@sfu.ca (Moose Project)
Date: Wed, 28 Apr 93 22:35:24 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <2bdcbd49.davgar@davgar.arlington.va.us>; from "David Garfield" at Apr 27, 93 12:57 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

[Long discussion about LLL deleted]
But David -- you can't interrupt now -- they're having so much fun :-)

> 
> I still am wondering why we need a Low Level Language?  I thought the
> purpose of this group was to build an advanced operating system for
> our 386 PCs to replace DOS, Windows, and so on.  I can see refraining
> from using the 386 segmented memory for the sake of making our OS more
> portable to other architectures, but this group is begining to look
> like an advanced operating system research project.  I don't think
> that was the point.

We were trying to make it portable.
I think that we should start kicking out "interesting" ideas that haven't been
done b4 -- I think it was Hoare that suggested that language designers firmly
resist the temptation to use any of their new untested ideas.

If we continue debating new (research) ideas we'll never have a system.

> 
> As for a Low Level Language, what's wrong with a compiler to 386 
> machine code?  I will admit that this requires writing assembly code 
> to the compiler writers interfaces, but it means we don't need to 
> write our own compilers and LLL interpreter.  
> 
> I will admit one thing, that having "object code compatibility 
> *across* platforms" for selected executables would be a good thing, 
> but this means, to me, that we have native mode executables and 
> portable executables, and that we use native mode for the entire 
> kernel, for most class implementations, most utilities, and many 
> applications.  Some classes, utilities, and applications get done as 
> portable executables.  General network distribution of applications is 
> a reasonable use for portable executables.  

> 
> David
> -- 
> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com
> 

Michael


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Thu Apr 29 03:49:50 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24443; Thu, 29 Apr 93 03:49:49 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Thu, 29 Apr 93 03:49:49 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07929; Wed, 28 Apr 93 18:46:57 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA15012
	Thu, 29 Apr 1993 11:46:32 +1000 (from winikoff)
Message-Id: <9304290146.15012@mulga.cs.mu.OZ.AU>
Subject: Re: The LL language. [arf6] [dpm7] [djg18] [arf7]
To: moose-programmers@sfu.ca (Moose Project)
Date: Thu, 29 Apr 93 11:46:29 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <MAILQUEUE-101.930428155231.480@sofus.dhhalden.no>; from "Andreas Arff" at Apr 28, 93 3:52 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> ACK!
> 
> 
> Why must the code be compiled. I remember reading about an old language
> that compiled the code whenever a program were started (it was most certainly
> the system that did this, but it is only a vague memory:-). The user didn't
> even notice it (or at least that is what was said)! You would gain the speed
> of a compiled language, and the "object code compability across platforms".

If it's such a good idea why isn't it common?

I'm not going to argue that if an idea isn't common it's not good.
I'm just arguing that trying new ideas is the role of research.
If we start doing research into new ideas we will never have a system.


Regards the technical details -- you'd have to compile and sgtore the 
executable otherwise you'd be recompiling each time it was run.
The other question is how much optimisation you're doing when you're compiling?
If you're doing simple compilation you're fine, if you're doing optimisation 
then there'll be a noticeable delay.
This becomes worse for larger programs.

Michael

From rideau@clipper Thu Apr 29 22:03:23 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24253; Thu, 29 Apr 93 22:03:22 +0200
Return-Path: <rideau@clipper>
Received-Date: Thu, 29 Apr 93 22:03:22 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18547; Thu, 29 Apr 93 12:58:39 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304291958.AA24031@clipper.ens.fr>
Subject: LLL Re:many [far30]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Thu, 29 Apr 93 21:58:04 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

>>>> Even though it may be easier to use no. 1, I belive it would be slower.
>>> The tree would have to do lots of "strcpm" to chose the path to the compiled
>>> code, while an integer represenation as in no. 2 would only need a "cmp".
>>>
>>> I'm no language guru so I don't actually now myself, but at least it seems
>>> as no. 2. would be faster.
(yes, I was confused and exchanged the numbers; please excuse and see my reply)

>>>
         ,
>>>> Fare
>>>
>>> Arff

>> One important thing to consider is portability - say machine A has a 64-bit
>> little endian word and machine B has a 32-bit big endian word...they aren't
>> going to be compatible.  This is assuming, of course, they need to!  You may
>> have heard that OSes like Conix have object code compatibility *across*
>> platforms...is this the intention here?
>>
>> Dennis
YES it is. But there's no problem possibly converting data endianness when
loading from disk to memory; as I previously said, LLL must be standard up
to a quick standard transformation.


> I still am wondering why we need a Low Level Language?  I thought the
> purpose of this group was to build an advanced operating system for
> our 386 PCs to replace DOS, Windows, and so on.  I can see refraining
> from using the 386 segmented memory for the sake of making our OS more
> portable to other architectures, but this group is begining to look
> like an advanced operating system research project.  I don't think
> that was the point.
We use PC because we own them, and we own them because they are cheap and
standard. Now, if we had a portable system, we could use better cheaper
(but not standard) computers; we could also be sure that the system can be
future architecture so that our work won't be lost.

> As for a Low Level Language, what's wrong with a compiler to 386 
> machine code?  I will admit that this requires writing assembly code 
> to the compiler writers interfaces, but it means we don't need to 
> write our own compilers and LLL interpreter.  
- We MUST write new compilers to fit the system object code format
(unless you want to use DOS or linux compatible executable code !)
- A LLL interpreter is easy to write and maintain, so that we can start
using LLL immediately when we port the system.
- interpreting will be done only when time is not critical, or at the
beginning (before a compiler is available).
- LLL (with comments added) can be used as source code for real-time
compilation. Current compilers spend most of their time parsing; type
checking and inter-procedural optimization also are very slow; all this
can be done machine-independently and thus in the source->LLL compilation.
Thus, LLL->machine code (or assembler) will be much quicker than source->
the same. 
- The main problem is optimization, which even is very machine dependent.
If you need optimize some time critical routines, you may add info about
the routine to mere interpretable code. You may rather choose to forget
about some info, and preoptimize for best use on architectures you intend
to use the program with, and/or include optimized version(s) of critical
parts of the code, etc. However, you can't have something at the same
time portable, immediate, compact and optimized: you must remove at least
one of these features for a _given_ LLL program (but you may keep the
three others).
- LLL signatures can also be used to copyright/number software (didn't you
Dennis talk about copy protection in the news ? well this at least allow
identifying a program.

> I will admit one thing, that having "object code compatibility 
> *across* platforms" for selected executables would be a good thing, 
> but this means, to me, that we have native mode executables and 
> portable executables, and that we use native mode for the entire 
> kernel, for most class implementations, most utilities, and many 
> applications.  Some classes, utilities, and applications get done as 
> portable executables.  General network distribution of applications is 
> a reasonable use for portable executables.  

- LLL can be a means to communicate code across a heterogeneous distributed
version of the system. Each machine compiles or interprets the code portion,
without having to globally recompile a possibly huge HLL program.
- for high level tasks, LLL may be quicker and more compact than assembly,
and/or assembling LLL before executing it may be slower than interpreting it
(especially when there are many late object bindings).
- many programs whose author cannot (for some reason) write an optimized
portable compiler may require (simple) run-time code generation (with
sometimes optimization _wish_). Such programs are horrible/impossible to
write properly with the given constraints in current systems, all the more
if you want it both quick (or compact) and portable. The standard
inter-platform LLL solves this kind of problem: standardness ensure LLL
optimal efficiency (both if interpreted or compiled), and saves the author
from writing (=much development time) and including (=great increase of size
for comparable performance) it in his code, not to speak about allowing
interfacing the code with possible (and/or compulsory) external programs.
Thus LLL is also a relief for the average programmer !

> David

   ,
Fare

P.S.: I thought I had posted this message two days ago. Perhaps you received
it or it was lost. This version of far30 includes some modifications.

P.P.S.: Michael fears that if a LLL had been a good idea, some would have
been adopted; but the problem with LLL adoption is that there is too much
people to have agree for the ANSI to publish something (moreover, the ANSI
is so slow that when they manage to do the least thing, it already has
become obsolete); to finish with, large companies (IBM,Microsoft,Apple,Sun,
etc) for common user never want a portable (not to say quick/compact)
system for they earn their (extremely high) profit by selling unportable
architectures, together with software to exchange data and hardware to
store converters (even microprocessor manufacturers don't want code
portability FROM their products, do they, Dennis ? :-).

From danodom@matt.ksu.ksu.edu Thu Apr 29 23:32:42 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA26221; Thu, 29 Apr 93 23:32:40 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Thu, 29 Apr 93 23:32:40 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25490; Thu, 29 Apr 93 14:30:24 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA06370; Thu, 29 Apr 93 16:24:43 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304292124.AA06370@matt.ksu.ksu.edu>
Subject: Re: MUSIC Specs 0.0 [djo4-ish]
To: winikoff@mulga.cs.mu.oz.au (Michael David WINIKOFF)
Date: Thu, 29 Apr 93 16:24:42 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <9304281222.28365@mulga.cs.mu.OZ.AU>; from "Michael David WINIKOFF" at Apr 28, 93 10:22 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Michael David WINIKOFF Said:

> > 2) We'll be hard pressed to fit it in 80 meg.  The best 32-bit PC OS
> > that I have seen is Linux, and the SLS distribution requires 90 meg for
> > a full installation, plus about 670k of RAM for the kernel.
> 
> Sheesh.
> The Amiga OS comes on 2 floppy disks (800K, none of this 1.2M) -- I'll let
> you add another disk for the 512K ROM and includes
> 
> 	- pre-emptive multitasking
> 	- devices
> 	- libraries
> 	- GUI
> 	- TUI
> 	- utilities
> 
> Need I go on? It CAN be done.
> The reason Linux is so huge is that it includes gcc and X.
> (and source? :-)

I don't use X, and it still needs 70 meg.  GCC is huge, but we're going to
include it, right?  EMACS, too.

Just a note of interest:  the latest release of AmigaDOS (for the AGA)
was written using GCC.

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

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

From danodom@matt.ksu.ksu.edu Fri Apr 30 05:48:14 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06283; Fri, 30 Apr 93 05:48:11 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Fri, 30 Apr 93 05:48:11 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA13481; Thu, 29 Apr 93 20:46:09 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA25831; Thu, 29 Apr 93 22:46:22 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304300346.AA25831@matt.ksu.ksu.edu>
Subject: Re: MUSIC Specs 0.0 [djo4-ish]
To: winikoff@mulga.cs.mu.oz.au (Michael David WINIKOFF)
Date: Thu, 29 Apr 93 22:46:21 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <9304300156.20968@mulga.cs.mu.OZ.AU>; from "Michael David WINIKOFF" at Apr 30, 93 11:56 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Michael David WINIKOFF Said:

> > I don't use X, and it still needs 70 meg.  GCC is huge, but we're going to
> 
> WHat takes up all the room then?

GCC and EMACS, I imagine.  I could check if you really want me to.

> Why? Durely you don't want to encourage people to use C?

Why not?  Its not _that_ bad, and GCC includes support for C++ and Objective-C

> Besides only developers need C. 
> I see no reason for including C and EMACS in the core distribution.
> Perhaps have a developers packet that has EMACS VI GCC etc.

EVERYONE should be a developer.  Let's make the basic tools a part of
our standard distribution.

But these are details that can be worked out later; let's worry about other
things for now.

> > Just a note of interest:  the latest release of AmigaDOS (for the AGA)
> > was written using GCC.
> 
> I'm still using 1.3 ... :-)

I know very little about the Amiga.  When was 1.3?

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

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

From winikoff@cs.mu.OZ.AU Fri Apr 30 03:57:31 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28965; Fri, 30 Apr 93 03:57:30 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 30 Apr 93 03:57:30 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA10013; Thu, 29 Apr 93 18:54:35 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA20919
	Fri, 30 Apr 1993 11:53:48 +1000 (from winikoff)
Message-Id: <9304300153.20919@mulga.cs.mu.OZ.AU>
Subject: Re: LLL Re:many [far30]
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 30 Apr 93 11:53:46 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9304291958.AA24031@clipper.ens.fr>; from "Francois-Rene Rideau" at Apr 29, 93 9:58 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> > As for a Low Level Language, what's wrong with a compiler to 386 
> > machine code?  I will admit that this requires writing assembly code 
> > to the compiler writers interfaces, but it means we don't need to 
> > write our own compilers and LLL interpreter.  
> - We MUST write new compilers to fit the system object code format
> (unless you want to use DOS or linux compatible executable code !)

Yes and no. 
Modifying an existing compiler to generate a slightly different object code
format is arguably less work then designing an LLL.
Bear in mind that we will have to live ith any deficiency in LLL.

> - A LLL interpreter is easy to write and maintain, so that we can start
> using LLL immediately when we port the system.
> - interpreting will be done only when time is not critical, or at the
> beginning (before a compiler is available).
> - LLL (with comments added) can be used as source code for real-time
> compilation. Current compilers spend most of their time parsing; type
> checking and inter-procedural optimization also are very slow; all this
> can be done machine-independently and thus in the source->LLL compilation.
> Thus, LLL->machine code (or assembler) will be much quicker than source->
> the same. 

This varies. Yes, parsing and lexing take time but linking also takes a fair
amount of time.


Besides, most of the compilation you do will be during development when you
HAVE to do the first step source->LLL, sure you save on the LLL->executable
and I think interpreting LLL will help in making a good debugger but you're
not saving on lexing/parsing -- rather on linking.

> - The main problem is optimization, which even is very machine dependent.
> If you need optimize some time critical routines, you may add info about
> the routine to mere interpretable code. You may rather choose to forget
> about some info, and preoptimize for best use on architectures you intend
> to use the program with, and/or include optimized version(s) of critical
> parts of the code, etc. However, you can't have something at the same
> time portable, immediate, compact and optimized: you must remove at least
> one of these features for a _given_ LLL program (but you may keep the
> three others).
> - LLL signatures can also be used to copyright/number software (didn't you
> Dennis talk about copy protection in the news ? well this at least allow
> identifying a program.

You don't need LLL for this. It can be done with the object code.

> 
> - LLL can be a means to communicate code across a heterogeneous distributed
> version of the system. Each machine compiles or interprets the code portion,
> without having to globally recompile a possibly huge HLL program.

This will only be practicle if you have a caching mechanism so code is
not recompiled each time it is executed on a particular node.
THis implies some method of keeping track of when the LLL "source" changes
so we know that we do have to recompile.


> - for high level tasks, LLL may be quicker and more compact than assembly,
> and/or assembling LLL before executing it may be slower than interpreting it
> (especially when there are many late object bindings).

Yes. The point is that once you've assembled (which for a commercial program
gets done once b4 distribution) you have speed at a possible increase in
size.

The main benefit of LLL is during development, slightly faster compilation,
easier to develop debuggers (although you really want source level debugging
anyway :-)

> - many programs whose author cannot (for some reason) write an optimized
> portable compiler may require (simple) run-time code generation (with

Run time code generation? Please NO! We are not going to have self modifying
code. Or if we are going to then you can debug it :-)

> sometimes optimization _wish_). Such programs are horrible/impossible to
> write properly with the given constraints in current systems, all the more
> if you want it both quick (or compact) and portable. The standard
> inter-platform LLL solves this kind of problem: standardness ensure LLL
> optimal efficiency (both if interpreted or compiled), and saves the author
> from writing (=much development time) and including (=great increase of size
> for comparable performance) it in his code, not to speak about allowing
> interfacing the code with possible (and/or compulsory) external programs.
> Thus LLL is also a relief for the average programmer !
> 
> > David
> 
>    ,
> Fare
> 
> P.S.: I thought I had posted this message two days ago. Perhaps you received
> it or it was lost. This version of far30 includes some modifications.
> 
> P.P.S.: Michael fears that if a LLL had been a good idea, some would have
> been adopted; but the problem with LLL adoption is that there is too much
> people to have agree for the ANSI to publish something (moreover, the ANSI
> is so slow that when they manage to do the least thing, it already has
> become obsolete); to finish with, large companies (IBM,Microsoft,Apple,Sun,
> etc) for common user never want a portable (not to say quick/compact)
> system for they earn their (extremely high) profit by selling unportable
> architectures, together with software to exchange data and hardware to
> store converters (even microprocessor manufacturers don't want code
> portability FROM their products, do they, Dennis ? :-).
> 

Yes and no.
I don't think ANSI has anything to do with it.
ANSI tends to come in on the action only ratherlate when the language/OS 
is allready popular.

Regards companies I agree with your point.
However these days there is a lot of talk on open-systems and people are 
actually moving in that direction.

One interesting idea which DEC has been working on in the context of their
Alpha project is the automatic translation between object code for different
OS/Machines.

Shalom,
Michael


--------------------------------------------------------------------------------
Shalom: Hi OR bye OR Peace
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Apr 30 14:08:24 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17175; Fri, 30 Apr 93 14:08:22 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 30 Apr 93 14:08:22 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA23753; Fri, 30 Apr 93 05:06:07 -0700
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA02516; Fri, 30 Apr 93 08:06:04 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 080456.1941; Fri, 30 Apr 1993 08:04:56 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Thu, 29 Apr 1993 00:59:54 EDT
Date: Thu, 29 Apr 1993 00:40:25 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bdf60cb.davgar@davgar.arlington.va.us>
Message-Id: <2bdf5c41.try2.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject: Re: MUSIC Specs 0.0 [djo4-ish] [djg20]
Status: OR

On Thu, 29 Apr 93 22:46:21 CDT, "Dan Odom" wrote:
> EVERYONE should be a developer.  Let's make the basic tools a part of
> our standard distribution.
> --
> Dan Odom

Nice idea, but reality indicates otherwise.  In fact, something like
in excess of 90% of users are NOT developers, especially since the PC.
There should be a distribution that does not include the compiler or
development tools, at least if they aren't required for system
maintenance (and they should not be).

I would like to propose the following goals for system size and
requirements:
    - Run on any 386 family CPU (including 12MHz 386SX or 386SL)
    - REQUIRE not more than 896k of memory (1 Meg - 128 unrecoverable
            shadow bios [if we can't figure out how to get it back in
            some cases])
    - Require not more than one of:
        = ANY video adapter and a keyboard (for text use)
        = A VGA or better and a keyboard (for graphics use)
        = Any bi-directional stream interface (for remote use)
    - Require not more than 5 Meg of disk storage for the operating
            system and normal runtime, not counting development system
            and fancy graphics classes and data (fonts, etc).
    - Require not more that 20 Meg for the NORMAL development system
    - Require not more that 20 Meg for the Full Normal graphics
            classes and data.

I will not say we should require excellent performance on a 12MHz
386SX with 896k, but it should, I think, be able to run.

David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Apr 30 14:08:36 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17193; Fri, 30 Apr 93 14:08:33 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 30 Apr 93 14:08:33 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA23757; Fri, 30 Apr 93 05:06:15 -0700
Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA09561; Fri, 30 Apr 93 08:06:03 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 080455.1936; Fri, 30 Apr 1993 08:04:55 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Thu, 29 Apr 1993 00:59:42 EDT
Date: Thu, 29 Apr 1993 23:42:42 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bdf60c0.davgar@davgar.arlington.va.us>
Message-Id: <2be0a039.try2.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca (Moose Project)
Subject: Re: LLL Re:many [far30] [djg19]
Status: OR

On Thu, 29 Apr 93 21:58:04 MET DST, "Francois-Rene Rideau" wrote:
...
> > I still am wondering why we need a Low Level Language?  I thought the
> > purpose of this group was to build an advanced operating system for
> > our 386 PCs to replace DOS, Windows, and so on.  I can see refraining
> > from using the 386 segmented memory for the sake of making our OS more
> > portable to other architectures, but this group is begining to look
> > like an advanced operating system research project.  I don't think
> > that was the point.
> We use PC because we own them, and we own them because they are cheap and
> standard. Now, if we had a portable system, we could use better cheaper
> (but not standard) computers; we could also be sure that the system can be
> future architecture so that our work won't be lost.

But the only CPU feature particularly non-portable we might be using
on our 386 & up boxes is segmented memory.  I would actually PREFER to
make use of this to its fullest, even to using 48 bit pointers.  I AM
willing to give this up to make the system more portable.  ***And I
thought the original purpose of this group was to make a better OS for
our 386 boxes.***

> > As for a Low Level Language, what's wrong with a compiler to 386
> > machine code?  I will admit that this requires writing assembly code
> > to the compiler writers interfaces, but it means we don't need to
> > write our own compilers and LLL interpreter.
> - We MUST write new compilers to fit the system object code format
> (unless you want to use DOS or linux compatible executable code !)

Or write a new linker that takes an existing object code produced by
existing compilers and produces an executable for our operating
system.  And actually, I believe GCC already has a standard object
module format, if we want to use GCC.

> - A LLL interpreter is easy to write and maintain, so that we can start
> using LLL immediately when we port the system.

Easy to write.  Easy to do wrong too.

> - interpreting will be done only when time is not critical, or at the
> beginning (before a compiler is available).
> - LLL (with comments added) can be used as source code for real-time
> compilation. Current compilers spend most of their time parsing; type
> checking and inter-procedural optimization also are very slow; all this
> can be done machine-independently and thus in the source->LLL compilation.
> Thus, LLL->machine code (or assembler) will be much quicker than source->
> the same.

It sounds like you want to have 4 non-OS products here:  HLL->LLL,
HLL->machine code, LLL->machine code, LLL interpreter.  Is this right?
Is this reasonable?

> - The main problem is optimization, which even is very machine dependent.
> If you need optimize some time critical routines, you may add info about
> the routine to mere interpretable code. You may rather choose to forget
> about some info, and preoptimize for best use on architectures you intend
> to use the program with, and/or include optimized version(s) of critical
> parts of the code, etc. However, you can't have something at the same
> time portable, immediate, compact and optimized: you must remove at least
> one of these features for a _given_ LLL program (but you may keep the
> three others).
> - LLL signatures can also be used to copyright/number software (didn't you
> Dennis talk about copy protection in the news ? well this at least allow
> identifying a program.

> > I will admit one thing, that having "object code compatibility
> > *across* platforms" for selected executables would be a good thing,
> > but this means, to me, that we have native mode executables and
> > portable executables, and that we use native mode for the entire
> > kernel, for most class implementations, most utilities, and many
> > applications.  Some classes, utilities, and applications get done as
> > portable executables.  General network distribution of applications is
> > a reasonable use for portable executables.
>
> - LLL can be a means to communicate code across a heterogeneous distributed
> version of the system. Each machine compiles or interprets the code portion,
> without having to globally recompile a possibly huge HLL program.
> - for high level tasks, LLL may be quicker and more compact than assembly,
> and/or assembling LLL before executing it may be slower than interpreting it
> (especially when there are many late object bindings).
> - many programs whose author cannot (for some reason) write an optimized
> portable compiler may require (simple) run-time code generation (with
??huh??
> sometimes optimization _wish_). Such programs are horrible/impossible to
> write properly with the given constraints in current systems, all the more
> if you want it both quick (or compact) and portable. The standard
Are you talking about a standard compiler back-end?  Like GCC is
[supposed to be]?
> inter-platform LLL solves this kind of problem: standardness ensure LLL
> optimal efficiency (both if interpreted or compiled), and saves the author
> from writing (=much development time) and including (=great increase of size
> for comparable performance) it in his code, not to speak about allowing
> interfacing the code with possible (and/or compulsory) external programs.
> Thus LLL is also a relief for the average programmer !
>
> > David
>
>    ,
> Fare

O.K.  What do you want to use this LLL for (Direct answer please)?  As
I said, I think it is reasonable for distribution of applications....
One thing I will point out is that adding a standard LLL to an OS can
really be done any time before the OS goes into wide distribution and
porting.  It really is a simple task, compared to building the OS.

> P.S.: I thought I had posted this message two days ago. Perhaps you received
> it or it was lost. This version of far30 includes some modifications.

You mailed it to me.  I thought you were just having mailer problems
again.  You want me to mail a copy back to you?

> P.P.S.: Michael fears that if a LLL had been a good idea, some would have
> been adopted; but the problem with LLL adoption is that there is too much
> people to have agree for the ANSI to publish something (moreover, the ANSI
> is so slow that when they manage to do the least thing, it already has
> become obsolete); to finish with, large companies (IBM,Microsoft,Apple,Sun,
> etc) for common user never want a portable (not to say quick/compact)
> system for they earn their (extremely high) profit by selling unportable
> architectures, together with software to exchange data and hardware to
> store converters (even microprocessor manufacturers don't want code
> portability FROM their products, do they, Dennis ? :-).

Actually, it HAS been done before!  They called it p-code.  It was
part of UCSD Pascal.  It ran on both PDP-11s and 8080s, after having
only a boot disk different between them.  Of course, it went
commercial at version 1.5, and didn't last long past the introduction
of the PC, but it was available for the PC.  It also ran on Apple ][s
as well, and I heard that someone built a CPU that ran it as machine 
code.  Who wants to try again?

David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From winikoff@cs.mu.OZ.AU Fri Apr 30 15:08:15 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18511; Fri, 30 Apr 93 15:08:14 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 30 Apr 93 15:08:14 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24815; Fri, 30 Apr 93 06:06:01 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA10480
	Fri, 30 Apr 1993 23:05:45 +1000 (from winikoff)
Message-Id: <9304301305.10480@mulga.cs.mu.OZ.AU>
Subject: Re: LLL Re:many [far30] [djg19]
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 30 Apr 93 23:05:44 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <2be0a039.try2.davgar@davgar.arlington.va.us>; from "David Garfield" at Apr 29, 93 11:42 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> Actually, it HAS been done before!  They called it p-code.  It was
> part of UCSD Pascal.  It ran on both PDP-11s and 8080s, after having
> only a boot disk different between them.  Of course, it went
> commercial at version 1.5, and didn't last long past the introduction
> of the PC, but it was available for the PC.  It also ran on Apple ][s
> as well, and I heard that someone built a CPU that ran it as machine 
> code.  Who wants to try again?

Yes but P-code wasn't succesful in that there was too much of a speed loss.
They weren't compiling on the fly.
(P-Code had other problems)

[This is from an article I read -- I haven't actually seen/used P-code]

> 
> David
> -- 
> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com
> 


--------------------------------------------------------------------------------
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Fri Apr 30 15:11:06 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18559; Fri, 30 Apr 93 15:11:06 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 30 Apr 93 15:11:06 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24869; Fri, 30 Apr 93 06:08:46 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA10521
	Fri, 30 Apr 1993 23:08:30 +1000 (from winikoff)
Message-Id: <9304301308.10521@mulga.cs.mu.OZ.AU>
Subject: Re: MUSIC Specs 0.0 [djo4-ish] [djg20]
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 30 Apr 93 23:08:30 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <2bdf5c41.try2.davgar@davgar.arlington.va.us>; from "David Garfield" at Apr 29, 93 12:40 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> On Thu, 29 Apr 93 22:46:21 CDT, "Dan Odom" wrote:
> 
> I would like to propose the following goals for system size and
> requirements:
>     - Run on any 386 family CPU (including 12MHz 386SX or 386SL)
>     - REQUIRE not more than 896k of memory (1 Meg - 128 unrecoverable
>             shadow bios [if we can't figure out how to get it back in
>             some cases])
>     - Require not more than one of:
>         = ANY video adapter and a keyboard (for text use)
>         = A VGA or better and a keyboard (for graphics use)

Mouse? 
I think you should be able to use it with less then VGA.
I'm not going to bother arguing for this though.

>         = Any bi-directional stream interface (for remote use)

Is this an indirect way of saying a dumb-terminal on a serial line? :-)

>     - Require not more than 5 Meg of disk storage for the operating
>             system and normal runtime, not counting development system
>             and fancy graphics classes and data (fonts, etc).
>     - Require not more that 20 Meg for the NORMAL development system
			 ^^^^ then
>     - Require not more that 20 Meg for the Full Normal graphics
>             classes and data.
> 
> I will not say we should require excellent performance on a 12MHz
> 386SX with 896k, but it should, I think, be able to run.

... be able to run comfortably.

Agree.

> 
> David
> -- 
> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com
> 


--------------------------------------------------------------------------------
Shalom: Hi OR bye OR Peace
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From winikoff@cs.mu.OZ.AU Fri Apr 30 15:25:48 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18780; Fri, 30 Apr 93 15:25:47 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Fri, 30 Apr 93 15:25:47 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25159; Fri, 30 Apr 93 06:22:19 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA10742
	Fri, 30 Apr 1993 23:22:02 +1000 (from winikoff)
Message-Id: <9304301322.10742@mulga.cs.mu.OZ.AU>
Subject: Re: LLL Re:many [far30]
To: moose-programmers@sfu.ca (Moose Project)
Date: Fri, 30 Apr 93 23:22:01 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9304301303.AA18448@clipper.ens.fr>; from "Francois-Rene Rideau" at Apr 30, 93 3:03 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> ">>" is [far30]
> ">" is Michael's Apr 30 reply
> 
> If we have an OO late binding mechanism (=dynamic, run-time, object link),
> which is I think basic for an OO system (what's an OO system if there's no
> such thing ?), it will not be that easy at all including these mechanism
> in the compiler; and there won't be anymore usable code/data portability.
> Thus, from one platform to the other, you'll have to exchange some ASCII
> text, as with unix, and recompile it, but keeping sources for further
> exchange (which explains why unix eats so much disk space).

I don't think this is why Unix is large.

I still think that you can provide late binding by packing object code
into objects with info on methods.

CF. Libraries on the Amiga and devices on (nearly) any OS.

> > 
> > This varies. Yes, parsing and lexing take time but linking also takes a fair
> > amount of time.
> > 
> Yes, but there's no way to escape it. At least, _user_ compile time will have
> been sped up by a two to five factor.

Avoid compiling at run time. Simple.

I think a problem here is that I'm thinking in terms of conventional compilation
whereas you're thining in terms of libraries/late binding.

To me the packaging of objects to enable late binding should be independant of
the compilation technology.


> > 
> > Besides, most of the compilation you do will be during development when you
> > HAVE to do the first step source->LLL, sure you save on the LLL->executable
> > and I think interpreting LLL will help in making a good debugger but you're
> > not saving on lexing/parsing -- rather on linking.
>  Yes, but only the author will have to compile, not the user; moreover,
> including info in LLL keeping track of what code corresponds to what source
> part will allow partial compile; finally, if the parsed format is standard
> (=commented unoptimized LLL), we can build parse-on-the-fly structured
> editors. If you ever used something like GFA Basic on the Atari or the Amiga,
> you'll know that structured editors are far more functional than linear text
> editors; and GFA is limited by its Basic structure, whereas if we build our
> HLL, we we're not, and we can improve the principle.

Yuck! LLL is by definition low level.
Structured editors are not all good -- when editing strucured programs you 
often go through stages where the program isn't valid syntactically.

You're contradicting yourself -- if only the author needs to compile then
why should LLL keep track of what code corresponds to what source? And doesn't
this keeping track involve keeping the source around?

>  I conceive the system as a huge structured relational code&data base. Of
> course, ASCII source IS a possible and sometimes useful representation of it,
> but it certainly isn't the only, and neither the best, nor the quicker, nor
> the easiest to read/understand/modify for the human, nor the only portable
> one. Let's just not be bound by the ASCII limitations of unix(tm).

To the contrary. What I am proposing is that we accept compiled object code
which is essentially machine code with some packaging as a standard.

This is important -- companies don't want to distribute source code ...

> > 
> > You don't need LLL for this. It can be done with the object code.
> Yes, but LLL is portable, whereas object code is not. But signature is not
> an essential point.

POrtabiity at the object code isn't useful. 
You can get the same effect through source code portability which leaves
you with a simpler kernel.

Let me emphasize one VERY important point:

	PUTTING  FUNCTIONALITY INTO THE KERNEL IS NOT FREE

	EACH BIT OF FUNCTIONALITY THAT IS ADDED TO THE KERNEL HAS A DETRIMENTAL
	EFFECT ON THE SPEED AND RELIABILITY OF THE SYSTEM.
> >
> Well, you know, this is only a particularization of the general problem of
> distributed systems, i.e. keeping track of "copies" of different versions
> of objects. If we have a distributed system, this will only be an
> application of our more general solution (what will it be ?) to the one
> big problem.

ANother point -- are we trying to build a distributed system?

It seems to me that these are still an open research area.
We want to avoid anything associated with research if we want to have a running
system.

> >
> If Moose is made portable, assembling won't be done b4 distribution, except
> possibly for time-critical and/or unportable drivers.

I've answered this above -- this is not a good way of achieving portability.
Furthermore assembley b4 distribution is actually desirable.

>  Did you never have to write some application where the user had to/could
> input functions and/or expressions ? (curve drawing programs and/or
> small spreadsheet app, etc ?). Sometimes, you like it to be powerful, even
> if the kernel is simple and you can't afford building something complex.
> Then, a STANDARD LLL and/or semi-HLL (i.e. standard local entries to the
> HLL compiler) can be more than just useful. Saves time, money, increases
> power, allows easy inter-app high-level communication.

Sorry. I don't see the connection.
Please expand.

> 

Michael -- about to log off and get some sleep.
PS. I'm busy this week so I;d like to appologise in advance for not replying.

--------------------------------------------------------------------------------
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From rideau@clipper Fri Apr 30 15:06:51 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18481; Fri, 30 Apr 93 15:06:49 +0200
Return-Path: <rideau@clipper>
Received-Date: Fri, 30 Apr 93 15:06:49 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24786; Fri, 30 Apr 93 06:04:30 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from corvette.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18448; Fri, 30 Apr 93 15:03:58 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9304301303.AA18448@clipper.ens.fr>
Subject: Re: LLL Re:many [far30]
To: winikoff@mulga.cs.mu.OZ.AU (Michael David WINIKOFF)
Date: Fri, 30 Apr 93 15:03:58 MET DST
Cc: moose-programmers@sfu.ca
In-Reply-To: <9304300153.20919@mulga.cs.mu.OZ.AU>; from "Michael David WINIKOFF" at Apr 30, 93 11:53 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

">>" is [far30]
">" is Michael's Apr 30 reply

>> - We MUST write new compilers to fit the system object code format
>> (unless you want to use DOS or linux compatible executable code !)
> 
> Yes and no. 
> Modifying an existing compiler to generate a slightly different object code
> format is arguably less work then designing an LLL.
> Bear in mind that we will have to live ith any deficiency in LLL.
> 
If we have an OO late binding mechanism (=dynamic, run-time, object link),
which is I think basic for an OO system (what's an OO system if there's no
such thing ?), it will not be that easy at all including these mechanism
in the compiler; and there won't be anymore usable code/data portability.
Thus, from one platform to the other, you'll have to exchange some ASCII
text, as with unix, and recompile it, but keeping sources for further
exchange (which explains why unix eats so much disk space).

>> - A LLL interpreter is easy to write and maintain, so that we can start
>> using LLL immediately when we port the system.
>> - interpreting will be done only when time is not critical, or at the
>> beginning (before a compiler is available).
>> - LLL (with comments added) can be used as source code for real-time
>> compilation. Current compilers spend most of their time parsing; type
>> checking and inter-procedural optimization also are very slow; all this
>> can be done machine-independently and thus in the source->LLL compilation.
>> Thus, LLL->machine code (or assembler) will be much quicker than source->
>> the same. 
> 
> This varies. Yes, parsing and lexing take time but linking also takes a fair
> amount of time.
> 
Yes, but there's no way to escape it. At least, _user_ compile time will have
been sped up by a two to five factor.
> 
> Besides, most of the compilation you do will be during development when you
> HAVE to do the first step source->LLL, sure you save on the LLL->executable
> and I think interpreting LLL will help in making a good debugger but you're
> not saving on lexing/parsing -- rather on linking.
 Yes, but only the author will have to compile, not the user; moreover,
including info in LLL keeping track of what code corresponds to what source
part will allow partial compile; finally, if the parsed format is standard
(=commented unoptimized LLL), we can build parse-on-the-fly structured
editors. If you ever used something like GFA Basic on the Atari or the Amiga,
you'll know that structured editors are far more functional than linear text
editors; and GFA is limited by its Basic structure, whereas if we build our
HLL, we we're not, and we can improve the principle.
 I conceive the system as a huge structured relational code&data base. Of
course, ASCII source IS a possible and sometimes useful representation of it,
but it certainly isn't the only, and neither the best, nor the quicker, nor
the easiest to read/understand/modify for the human, nor the only portable
one. Let's just not be bound by the ASCII limitations of unix(tm).

>> - The main problem is optimization, which even is very machine dependent.
>> If you need optimize some time critical routines, you may add info about
>> the routine to mere interpretable code. You may rather choose to forget
>> about some info, and preoptimize for best use on architectures you intend
>> to use the program with, and/or include optimized version(s) of critical
>> parts of the code, etc. However, you can't have something at the same
>> time portable, immediate, compact and optimized: you must remove at least
>> one of these features for a _given_ LLL program (but you may keep the
>> three others).
>> - LLL signatures can also be used to copyright/number software (didn't you
>> Dennis talk about copy protection in the news ? well this at least allow
>> identifying a program.
> 
> You don't need LLL for this. It can be done with the object code.
Yes, but LLL is portable, whereas object code is not. But signature is not
an essential point.

>> - LLL can be a means to communicate code across a heterogeneous
>> distributed version of the system. Each machine compiles or interprets
>> the code portion, without having to globally recompile a possibly huge
>> HLL program.
>
> This will only be practicle if you have a caching mechanism so code is
> not recompiled each time it is executed on a particular node.
> This implies some method of keeping track of when the LLL "source" changes
> so we know that we do have to recompile.
>
Well, you know, this is only a particularization of the general problem of
distributed systems, i.e. keeping track of "copies" of different versions
of objects. If we have a distributed system, this will only be an
application of our more general solution (what will it be ?) to the one
big problem.


>> - for high level tasks, LLL may be quicker and more compact than
>> assembly, and/or assembling LLL before executing it may be slower
>> than interpreting it.
>> (especially when there are many late object bindings).
> 
> Yes. The point is that once you've assembled (which for a commercial
> program gets done once b4 distribution) you have speed at a possible
> increase in size.
>
If Moose is made portable, assembling won't be done b4 distribution, except
possibly for time-critical and/or unportable drivers.
>
> The main benefit of LLL is during development, slightly faster compilation,
> easier to develop debuggers (although you really want source level debugging
> anyway :-)
>
and portability across different (and/or future) architectures.
>
>> - many programs whose author cannot (for some reason) write an optimized
>> portable compiler may require (simple) run-time code generation (with
>
> Run time code generation? Please NO! We are not going to have self modifying
> code. Or if we are going to then you can debug it :-)
 Did you never have to write some application where the user had to/could
input functions and/or expressions ? (curve drawing programs and/or
small spreadsheet app, etc ?). Sometimes, you like it to be powerful, even
if the kernel is simple and you can't afford building something complex.
Then, a STANDARD LLL and/or semi-HLL (i.e. standard local entries to the
HLL compiler) can be more than just useful. Saves time, money, increases
power, allows easy inter-app high-level communication.

>> sometimes optimization _wish_). Such programs are horrible/impossible to
>> write properly with the given constraints in current systems, all the more
>> if you want it both quick (or compact) and portable. The standard
>> inter-platform LLL solves this kind of problem: standardness ensure LLL
>> optimal efficiency (both if interpreted or compiled), and saves the author
>> from writing (=much development time) and including (=great increase of size
>> for comparable performance) it in his code, not to speak about allowing
>> interfacing the code with possible (and/or compulsory) external programs.
>> Thus LLL is also a relief for the average programmer !
>> 
> David
> 
>>    ,
>> Fare

>> > P.S.: ...

P.S.:
unix(tm) is a trademark of AT&T.

   ,
Fare

From danodom@matt.ksu.ksu.edu Fri Apr 30 21:00:52 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28384; Fri, 30 Apr 93 21:00:51 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Fri, 30 Apr 93 21:00:51 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11948; Fri, 30 Apr 93 11:58:50 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA10497; Fri, 30 Apr 93 13:59:20 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9304301859.AA10497@matt.ksu.ksu.edu>
Subject: Re: MUSIC Specs 0.0 [djo4-ish] [djg20] [djo7]
To: david@davgar.arlington.va.us (David Garfield)
Date: Fri, 30 Apr 93 13:59:19 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <2bdf5c41.try2.davgar@davgar.arlington.va.us>; from "David Garfield" at Apr 29, 93 12:40 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

David Garfield Said:

> Nice idea, but reality indicates otherwise.  In fact, something like
> in excess of 90% of users are NOT developers, especially since the PC.
> There should be a distribution that does not include the compiler or
> development tools, at least if they aren't required for system
> maintenance (and they should not be).

I dunno; I like the idea of distributing apps in source form and letting
the user compile them, like UNIX.

> I would like to propose the following goals for system size and
> requirements:
>     - Run on any 386 family CPU (including 12MHz 386SX or 386SL)
>     - REQUIRE not more than 896k of memory (1 Meg - 128 unrecoverable
>             shadow bios [if we can't figure out how to get it back in
>             some cases])
>     - Require not more than one of:
>         = ANY video adapter and a keyboard (for text use)
>         = A VGA or better and a keyboard (for graphics use)
>         = Any bi-directional stream interface (for remote use)

Sounds good.

>     - Require not more than 5 Meg of disk storage for the operating
>             system and normal runtime, not counting development system
>             and fancy graphics classes and data (fonts, etc).

OK.

>     - Require not more that 20 Meg for the NORMAL development system

Would be nice, but I doubt we could pull it off.  Look at how big most
'normal' development systems are -- while there is room for improvement,
20 Meg might be pushing it.

I am willing to try it, though.

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

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

From winikoff@cs.mu.OZ.AU Sat May  1 06:30:46 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22254; Sat, 1 May 93 06:30:45 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 1 May 93 06:30:45 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06991; Fri, 30 Apr 93 21:05:45 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA22478
	Sat, 1 May 1993 14:05:28 +1000 (from winikoff)
Message-Id: <9305010405.22478@mulga.cs.mu.OZ.AU>
Subject: Re: MUSIC Specs 0.0 [djo4-ish] [djg20] [djo7]
To: moose-programmers@sfu.ca (Moose Project)
Date: Sat, 1 May 93 14:05:27 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9304301859.AA10497@matt.ksu.ksu.edu>; from "Dan Odom" at Apr 30, 93 1:59 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> David Garfield Said:
> 
> 
> I dunno; I like the idea of distributing apps in source form and letting
> the user compile them, like UNIX.

This limits applications to being public domain.
I think it's a good idea but to make it possible for any commercial applications
to exist you must provide a facility for distributing binaries.


Besides -- a lot of shareware gets distributed without code.
(Sometimes the author is too embarassed about the code to puiblish it :-)

Michael

From rideau@clipper Sat May  1 22:43:42 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04759; Sat, 1 May 93 22:43:41 +0200
Return-Path: <rideau@clipper>
Received-Date: Sat, 1 May 93 22:43:41 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA24313; Sat, 1 May 93 13:39:21 -0700
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from trimaran.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04633; Sat, 1 May 93 22:38:41 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9305012038.AA04633@clipper.ens.fr>
Subject: LLL weekly [far32]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Sat, 1 May 93 22:38:42 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR


 I'd like to regularly post a summary of pros, cons, reqs, etc,
about a standard LLL (or what I began to call a LLL, but I'm sure
you'll soon find a better word/acronym).
 This is the first version of the summary.
 
LLL principle
~~~~~~~~~~~~~
 There is a (family of (slightly hardware dependent ?) ?) standard
coding format for objects, INCLUDING EXECUTABLE CODE in such a way
as trivial programs can be instantly interpreted on any machine,
while more complicated programs are compiled without the
parsing/front end step which is known to be the most limitating,
and with intermediate code optimisation done and info ready for
ultimate back end compiling.

Pros
~~~~
1) Greatly shortens compile time
2) allows quick, easy and efficient portable code&data (=object)
exchange inside a heterogeneous distributed system or between 
remote systems.
3) greatly reduces future compiler design: a new language will
only need a new (or adaptated) front end; tools may be provided
for parsing (an OO lex/yacc equivalent). The back-end part of
compilers will be language independent, only hardware/implementation
dependent.
4) may extend current existing HLLs by including features a OO,
genericity, recursive call to HLL from LLL, etc.
5) may be compact _efficient_ (_standard_) interpreted code for HL
tasks, sometimes quicker than hand-written assembly, while much more
portable (don't you know most adventure games use their own
interpreter ?)
6) Is simple enough to be used as back-end by anyone willing to
compile his own expressions (see spreadsheets, function graph
drawers, etc)

Cons
~~~~
1) Is an important human-time investment (but aren't we Moosers
here to work ? :-)
2) Requires our respecting programming rules (but anyway, it's
inevitable)
3) Needs new compilers (but anyway, a new OS always requires new
compilers, to comply new object code format) (so why not profit
to build also a new HLL ? :-) for its features to be available to
programmers/users (again, I make no clear difference).
4) Compiler editing companies might not appreciate competition
(see Microsoft)
5) if it works, ANSI will have to produce again new papers (but
that also is inevitable, with MOOSE, isn't it ? Think about ANSI
MOOSE ! :-)

Reqs
~~~~
1) We must find a "good" preferably extensible format. A quick
linear conversion with a small memory occupancy is to be considered,
to provide at the same time external portability and internal
efficiency (in/external relative to each host). If we forget
something important, we'll have to produce un-upward-compatible
formats and thus forma converter that will occupy system time and 
space.
2) The standard must provide a quick, efficient, unspacy way of
coding external links: an object will almost always need external
objects to run/evaluate, that shouldn't/couldn't/oughtn't be
included in the object itself; however, when loaded/saved, the
object needs the link not to be forgotten, so as to be properly
restored next time. My opinion is have tables/virtual dictionaries
at module level (that'll be my definition for what Dennis called
modules)
3) As the format includes not only LL executable code, but also
data, etc, it's a full language. The main difference from usual
languages then is the fact that it is a binary format as opposed
to text format. But as text is a particular kind of binary, a
point of view would be that HLL is an LLL subset (as well as
machine language) (actually, if my LLL is extended to a full
object description standard, any object will be coded through it,
so why not HLL source fies in particular ?); thus, there is no
more compilation, but only simplification ("optimisation") and
evaluation, from subsets of objects to others.

Comments and Compile info
~~~~~~~~~~~~~~~~~~~~~~~~~
 If you want your LLL code to be efficient not only interpreted, but
also as intermediate code for compiling, you must add info (taken
from HLL compile) that will help optimization (optimizing for LLL
interpretation often is in conflict with LLL optimizing for further
xxx CPU assembly). More generally, we must include in our object info
that is not used while computing the object, but while compiling it,
while scheduling its use, while displaying it or interfacing it to
any external reading-only program.


First crude sketch
~~~~~~~~~~~~~~~~~~

** Modules **
A module will include
- a "Magic number" or equivalent, followed by info about coding format:
endianness, integer length, etc.
- a external module identifiers (names, version ?), followed by
id. of included objects.
- a list (only number ?) of public subobjects.
- a list of relations between the module's public object,
including their type and/or content.
- a pointer to info/comments about the objects. Info/comments have
their own format, different from module format. Module & info CAN
be packed in a single object/file, but don't have to. Info includes
optimization info, source file correspondance, showing/printing/
drawing/displaying format info, object equivalent representation
in different environment, etc.
- LLL include no builtin instruction, only calls to imported
instructions; however, standard instruction libraries are provided.

386 memory implementation
~~~~~~~~~~~~~~~~~~~~~~~~~
** Interpreted LLL **
 Objects are translated into a stack of pointers to LLL routines in
a LLL segment (devices can be added to the LLL through virtual memory).
Execution is done in privilege level 3, and the "code" is put into a
read-only stack (whatever, a level 3 stack is recommended not to interfere
with interrupts). LLL interpreter just pops data and near rets to next
instruction. Escape instructions can change mode into far ret and/or direct
assembly execution, etc. Another stack is ready for use in assembly mode,
and a ds:si, es:di LLL stacks are used for data/address push/pop.
 What d'ya think of it ?

** Compiled LLL **
 It's just 32 bit protected mode machine code. Standard programs run in
lowest privilege level, but lower level programs may run in PL2, 1, or 0.
Pointer/data have different stacks. Programs not trusted will run in PL3,
and won't be able to access external modules but through system calls to
modified paging a/o segmentation.


Policy propositions
~~~~~~~~~~~~~~~~~~~
1) (Fare')
First have a LLL interpreter in C/C++; then build C/C++ and/or
NewHLL compiler to LLL (and why not NewHLL <-> C/C++ compilers,
understanding extensions of C/C++ through added info inside
comments ?)
2) (?)
Forget all this, and "just" adapt an existing compiler (GCC ?
but I thought Michael agreed against plain C/C++ ?)





Feel free (bound ?) to reply/contribute and/or to correct my poor
english and my mistypes. Reply for small contributions/corrections,
group reply for large controverse, but please make me know your
opinion.
 If you feel someone is better suited than me to maintain this issue,
just tell him and me; if he agrees, I'm ready to let him this task.

   ,
Fare


P.S.:
I'm preparing some NewHLL examples for next week.

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Sun May  2 06:48:49 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16523; Sun, 2 May 93 06:48:48 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Sun, 2 May 93 06:48:48 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03652; Sat, 1 May 93 21:46:59 -0700
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA22950; Sun, 2 May 93 00:47:08 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 004615.20071; Sun, 2 May 1993 00:46:15 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Sun, 02 May 1993 00:41:33 EDT
Date:      Sun, 02 May 1993 00:41:28 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2be350ff.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca (Moose Project)
Subject:   Moose Requirements & LLL   followup  [djg21]
Status: OR

Quoting two messages from Michael David WINIKOFF

>> On Thu, 29 Apr 93 22:46:21 CDT, "Dan Odom" wrote:
That was me, David Garfield.  Watch the quotes!
>>
>> I would like to propose the following goals for system size and
>> requirements:
>>     - Run on any 386 family CPU (including 12MHz 386SX or 386SL)
>>     - REQUIRE not more than 896k of memory (1 Meg - 128 unrecoverable
>>             shadow bios [if we can't figure out how to get it back in
>>             some cases])
>>     - Require not more than one of:
>>         = ANY video adapter and a keyboard (for text use)
>>         = A VGA or better and a keyboard (for graphics use)

>Mouse?

Mouse is optional and therefore not REQUIRED.

>I think you should be able to use it with less then VGA.
>I'm not going to bother arguing for this though.

I would actually like to support less than a VGA for graphics too, but
I think other will have problems with putting a GUI on a EGA, or
worse, CGA.  I suppose I could have propose supporting CGA low
resolution graphics (160*100, 16 color, yes CGA can do 16 color
graphics, and it is even documented, if you know where to look).

>>         = Any bi-directional stream interface (for remote use)

>Is this an indirect way of saying a dumb-terminal on a serial line? :-)

Actually, this is a way of saying serial line without preventing it
from also allowing network connections, or bi-directional use of a
parellel port.

>>     - Require not more than 5 Meg of disk storage for the operating
>>             system and normal runtime, not counting development system
>>             and fancy graphics classes and data (fonts, etc).
>>     - Require not more than 20 Meg for the NORMAL development system  [fixed]
>>     - Require not more than 20 Meg for the Full Normal graphics
>>             classes and data.

In reference to someone else comments on 20 Meg, ok, I said goal.  We
should try, and admit we might not succeed on some goals, like this.

>> I will not say we should require excellent performance on a 12MHz
>> 386SX with 896k, but it should, I think, be able to run.

>... be able to run comfortably.

Exactly.  Moose should work reasonably on a 12MHz 386SX with 896k, at
least with a basic VGA in text mode, and maybe in a simple VGA
graphics mode.

>Agree.

>> David
>Michael Winikoff

--------------------------------------------------

>>
>> David Garfield Said:
That was not me, that was Dan Odom.  Watch the quotes!
>>
>>
>> I dunno; I like the idea of distributing apps in source form and letting
>> the user compile them, like UNIX.

>This limits applications to being public domain.
>I think it's a good idea but to make it possible for any commercial applications
>to exist you must provide a facility for distributing binaries.

>Besides -- a lot of shareware gets distributed without code.
>(Sometimes the author is too embarassed about the code to puiblish it :-)

>Michael

For the sake of the above mentioned commerial applications and
shareware developers, we need to have a distribution method other than
source.  For the sake of portability we should have some method of
distribution other than system-specific binary.  This leaves us with
an interpreter of some sort, ant thus we get LLL.  But I still feel
that it is not to be used for most/all of the standard distributions.
I will point out (again?) that this can be done any time up till when
there is a general public distribution.  After that it is too late.
You also can't aford to change the LLL once you do have a general
public distribution.  If you do, you get other portability problems.

As for the comment someone had about disadvantages of putting
something like this in the kernel, you have to put it somewhere fairly
common.  Perhaps the interpreter winds up being a second meta-class?
Anybody want to discuss meta-classes?  Should we support meta-classes?
This might solve the upgrade problems, and even allow any developer
that felt the need to design a new interpreter.

David



-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com

From winikoff@cs.mu.OZ.AU Sun May  2 03:59:01 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07911; Sun, 2 May 93 03:59:00 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sun, 2 May 93 03:59:00 +0200
Received: from mulga.cs.mu.OZ.AU by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA10872
	Sun, 2 May 1993 11:59:03 +1000 (from winikoff)
Message-Id: <9305020159.10872@mulga.cs.mu.OZ.AU>
Subject: Re: LLL weekly [far32]
To: rideau@clipper (Francois-Rene Rideau)
Date: Sun, 2 May 93 11:58:59 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9305012038.AA04633@clipper.ens.fr>; from "Francois-Rene Rideau" at May 1, 93 10:38 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> about a standard LLL (or what I began to call a LLL, but I'm sure
> you'll soon find a better word/acronym).

L^3? :-)

> 
> Pros
> ~~~~
> 1) Greatly shortens compile time

Not the compiles that developers do since they are working of the source 
anyway.


> 2) allows quick, easy and efficient portable code&data (=object)
> exchange inside a heterogeneous distributed system or between 
> remote systems.

We're not here to develop a distributed OS.

> 3) greatly reduces future compiler design: a new language will
> only need a new (or adaptated) front end; tools may be provided
> for parsing (an OO lex/yacc equivalent). The back-end part of
> compilers will be language independent, only hardware/implementation
> dependent.

One can have a back end language without having the OS responsible for
compiling LLL.

> 4) may extend current existing HLLs by including features a OO,
> genericity, recursive call to HLL from LLL, etc.
> 5) may be compact _efficient_ (_standard_) interpreted code for HL
> tasks, sometimes quicker than hand-written assembly, while much more
> portable (don't you know most adventure games use their own
> interpreter ?)

That's because adventure games don't have to be fast.

> 6) Is simple enough to be used as back-end by anyone willing to
> compile his own expressions (see spreadsheets, function graph
> drawers, etc)

It's simpler to write an interpreter rather then compiling to LLl.
Even if LLL is simple.

> 
> Cons
> ~~~~
> 1) Is an important human-time investment (but aren't we Moosers
> here to work ? :-)

Not any more then we have to -- besides we've got plenty to do as it is.

> 2) Requires our respecting programming rules (but anyway, it's
> inevitable)

Huh?

> 3) Needs new compilers (but anyway, a new OS always requires new
> compilers, to comply new object code format) (so why not profit
> to build also a new HLL ? :-) for its features to be available to
> programmers/users (again, I make no clear difference).

Nope. 
We can simply have a utility to translate from (EG) MS-DOS object code 
format to our object code format.

> 4) Compiler editing companies might not appreciate competition
> (see Microsoft)
> 5) if it works, ANSI will have to produce again new papers (but
> that also is inevitable, with MOOSE, isn't it ? Think about ANSI
> MOOSE ! :-)

NO!
Standards
(1) Happen after the system has become both popular and many versioned.
(2) Prohibit progress by freazing the system as is.


Michael 
winikoff@cs.mu.oz.au


From winikoff@cs.mu.OZ.AU Sun May  2 07:07:48 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16734; Sun, 2 May 93 07:07:47 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sun, 2 May 93 07:07:47 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03939; Sat, 1 May 93 22:05:29 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA12947
	Sun, 2 May 1993 15:05:07 +1000 (from winikoff)
Message-Id: <9305020505.12947@mulga.cs.mu.OZ.AU>
Subject: Re: Moose Requirements & LLL   followup  [djg21]
To: moose-programmers@sfu.ca (Moose Project)
Date: Sun, 2 May 93 15:05:06 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <2be350ff.davgar@davgar.arlington.va.us>; from "David Garfield" at May 2, 93 12:41 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> Quoting two messages from Michael David WINIKOFF
> 
> >Mouse?
> 
> Mouse is optional and therefore not REQUIRED.

I'd suggest that it's pretty pointless to have people using a GUI without
a mouse.

I know it can be done but I see nothing wrong with insisting that people have
Mice. This isn't the 80's anymore :-)

> 
> Actually, this is a way of saying serial line without preventing it
> from also allowing network connections, or bi-directional use of a
> parellel port.

Fair 'nuff.

> 
> --------------------------------------------------
> 
> >>
> >> David Garfield Said:
> That was not me, that was Dan Odom.  Watch the quotes!

:-)

> 
> For the sake of the above mentioned commerial applications and
> shareware developers, we need to have a distribution method other than
> source.  For the sake of portability we should have some method of
> distribution other than system-specific binary.  This leaves us with

Not neccessarily. 
Firstly I'd argue that portability AT THAT LEVEL is not an important goal.
You can easily achieve portability by recompiling.
What counts is SOURCE CODE PORTABILITY.
The only reason you'd want binary portability is for process migration which
is irrelevant as WE ARE NOT DEVELOPING A DISTRIBUTED OS.

There's nothing stopping us from defining an LLL and writtig an interpreter, and
encouraging people to use it.

What I object to is placing a compiler in the system and having the system 
responsible for run-time compilation and caching of code.

There are simpler ways to achieve portability which remain out of the
system level.

> an interpreter of some sort, ant thus we get LLL.  But I still feel
> that it is not to be used for most/all of the standard distributions.
> I will point out (again?) that this can be done any time up till when
> there is a general public distribution.  After that it is too late.
> You also can't aford to change the LLL once you do have a general
> public distribution.  If you do, you get other portability problems.
> 
> As for the comment someone had about disadvantages of putting
> something like this in the kernel, you have to put it somewhere fairly
> common.  Perhaps the interpreter winds up being a second meta-class?

Fine. /bin/LLL-interpreter (or the equivalent).

> Anybody want to discuss meta-classes?  Should we support meta-classes?
> This might solve the upgrade problems, and even allow any developer
> that felt the need to design a new interpreter.

What's a meta-class? 

> 
> David
> 

Michael

From dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sun May  2 19:59:10 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27585; Sun, 2 May 93 19:59:09 +0200
Return-Path: <dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sun, 2 May 93 19:59:09 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12683; Sun, 2 May 93 10:55:16 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa05569; 2 May 93 13:52 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa02397; 2 May 93 17:51 GMT
Received: from sol.cis.udel.edu by dori.cis.udel.edu id aa15497;
          2 May 93 17:46 GMT
To: Moose Project <moose-programmers@sfu.ca>
Subject: Re: Moose Requirements & LLL followup [djg21] 
Date: Sun, 02 May 93 13:46:19 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305021746.aa15497@dori.cis.udel.edu>
Status: OR

In Message <9305020505.12947@mulga.cs.mu.OZ.AU> ,
   Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:

=>> 
=>> Quoting two messages from Michael David WINIKOFF
=>> 
=>> >Mouse?
=>> 
=>> Mouse is optional and therefore not REQUIRED.
=>
=>I'd suggest that it's pretty pointless to have people using a GUI without
=>a mouse.
=>
   However, the GUI is also optional, as stated.

=>I know it can be done but I see nothing wrong with insisting that people have
=>Mice. This isn't the 80's anymore :-)
=>
   Substitute "pointing device" for "mouse" in the GUI case, and I
will agree. We should also keep touch screens and tablets and such
in mind.

=>> For the sake of the above mentioned commerial applications and
=>> shareware developers, we need to have a distribution method other than
=>> source.  For the sake of portability we should have some method of
=>> distribution other than system-specific binary.  This leaves us with
=>
=>Not neccessarily. 
=>Firstly I'd argue that portability AT THAT LEVEL is not an important goal.
=>You can easily achieve portability by recompiling.
=>What counts is SOURCE CODE PORTABILITY.

   However, there would be a certain advantage of having a manufacturer
produce a single LLL distribution and allow the user to run it on the
hardware platform platform of his choosing. Otherwise, the user is at
the mercy of the manufacturer's whims on supported hardware.
   Personally, I think this is a moot point since I think it very
unlikely that many, if any, software manufacturers will be writing
software for MOOSE.

=>The only reason you'd want binary portability is for process migration which
=>is irrelevant as WE ARE NOT DEVELOPING A DISTRIBUTED OS.

   True, and I've never been fond of the idea of trying to support
process migration in a heterogeneous distributed system, anyway.

=>> Anybody want to discuss meta-classes?  Should we support meta-classes?
=>> This might solve the upgrade problems, and even allow any developer
=>> that felt the need to design a new interpreter.
=>
=>What's a meta-class? 
=>
   A class that generates other classes as output.

   If we want to use our own HLL, how about using Ellie? I've been
poking around with it on and off for a couple years now. It is
designed as a language to support adjustable grained parallel
objects.  In place of classes, Ellie uses a technique called
interface inclusion, where the interface of a local object is added
to the interface of its surrounding object.  Any object can be used
as a prototype to create a new type. The syntax is simple but
powerful, since everything is an object, including types, methods,
and functions.
   I wrote a lexer and started on a parser about a year and a half
ago, and I've decided to dust it off and see if I can get it working
as an interpreter. It is written in G++, so it should be fairly
portable. If anyone is interested in Ellie, you can FTP several
papers on it from ftp.diku.dk:/pub/diku/dists/ellie/papers.
Unfortunately, there is no compiler available that I am aware of.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From cis.udel.edu!udel.edu!duzan Mon May  3 02:33:32 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06392; Mon, 3 May 93 02:33:31 +0200
Return-Path: <cis.udel.edu!udel.edu!duzan>
Received-Date: Mon, 3 May 93 02:33:31 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21952; Sun, 2 May 93 17:31:29 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa15597; 2 May 93 20:30 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa04817; 3 May 93 0:25 GMT
Received: from sol.cis.udel.edu by daffy.cis.udel.edu id aa02329;
          3 May 93 0:21 GMT
To: moose-programmers@sfu.ca
Subject: Moose List Members
Date: Sun, 02 May 93 20:21:23 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305030021.aa02329@daffy.cis.udel.edu>
Status: OR


   I recently got mail send to the list bounced back with the address
of someone I've never heard of, so I took a look at the current list.

Active
------
250-<duzan@udel.edu>
250-<andreasa@dhhalden.no>
250-<dmarer@td2cad.intel.com>
250-<haydedr%wkuvx1.bitnet@udel.edu>
250-They call me "Uki"... <\mckeeveb>
250-<danodom@matt.ksu.ksu.edu>
250-<winikoff@cs.mu.oz.au>
250-<mueller@sc.zib-berlin.de>
250-<rideau@clipper.ens.fr>
250-<csjjlay@mtsu.edu>

Familiar
--------
250-<dspascha@eos.ncsu.edu>
250-<moose-l%davgar@uunet.uu.net>

Who?
----
250-<newlin@ecn.purdue.edu>
250-<fate@ccwf.cc.utexas.edu>
250-<rahul@npac.syr.edu>
250-Stephanie Lai Yi Chong <chongg>
250 <larrie@reg.triumf.ca>                <--- Bounced

   So what do those who read think of those of us who write? Are we
entertaining enough?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Mon May  3 14:19:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24471; Mon, 3 May 93 14:19:29 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 3 May 93 14:19:29 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA05357; Mon, 3 May 93 05:15:54 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92)
	id AA11878; Mon, 3 May 93 14:15:26 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA03485; Mon, 3 May 93 14:15:25 +0200
Date: Mon, 3 May 93 14:15:25 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305031215.AA03485@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca, duzan@udel.edu
Subject: Hmpf.
Status: OR

Hi,

After spending 3 and a half week in England I'm back! Gosh! When do YOU think
I should read all of your mails? This will take me another month ... But then
... what to do with the next incoming mails?

Is there anything summarizing what had happened between Apr. 1st through
Mar 3rd? If not ... uuh, lot's of reading is to be done ...

Bye, keep talking,

Peter

From winikoff@cs.mu.OZ.AU Mon May  3 02:43:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06520; Mon, 3 May 93 02:43:33 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 3 May 93 02:43:33 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22328; Sun, 2 May 93 17:41:02 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA00501
	Mon, 3 May 1993 10:40:48 +1000 (from winikoff)
Message-Id: <9305030040.501@mulga.cs.mu.OZ.AU>
Subject: Re: Moose Requirements & LLL followup [djg21]
To: moose-programmers@sfu.ca (Moose Project)
Date: Mon, 3 May 93 10:40:41 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To:  <9305021746.aa15497@dori.cis.udel.edu>; from "Gary D. Duzan" at May 2, 93 1:46 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> In Message <9305020505.12947@mulga.cs.mu.OZ.AU> ,
>    Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:
> 
>    However, the GUI is also optional, as stated.

Yes but they go together -- a mouse should be optional BUT NOT IF YOU'RE USING
A GUI.

> 
>    Substitute "pointing device" for "mouse" in the GUI case, and I
> will agree. We should also keep touch screens and tablets and such
> in mind.

Sure.

> 
>    However, there would be a certain advantage of having a manufacturer
> produce a single LLL distribution and allow the user to run it on the
> hardware platform platform of his choosing. Otherwise, the user is at
> the mercy of the manufacturer's whims on supported hardware.

Yes. Sure. Having the compiler and a make-like facility built into the OS
is baroque though (IMHO).

>    Personally, I think this is a moot point since I think it very
> unlikely that many, if any, software manufacturers will be writing
> software for MOOSE.

Unfortunately. So much for ANSI MOOSE ... :-)

>    A class that generates other classes as output.
> 
> portable. If anyone is interested in Ellie, you can FTP several
> papers on it from ftp.diku.dk:/pub/diku/dists/ellie/papers.

Will do. I'll get back to you when I've had the time to read this.

Michael

--------------------------------------------------------------------------------
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From dmarer@td2cad.intel.com Wed May  5 02:27:24 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA03043; Wed, 5 May 93 02:27:23 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 5 May 93 02:27:23 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA25587; Tue, 4 May 93 17:24:24 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Tue, 4 May 93 17:24:21 -0700
Received: by td2cad (5.57/10.0i); Tue, 4 May 93 17:28:16 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA21046; Tue, 4 May 93 17:26:38 PDT
Message-Id: <9305050026.AA21046@iws804.intel.com>
Subject: Re: Moose List Members
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Tue, 4 May 93 17:26:34 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Howdy Moosers!

Forgive my quietness lately...my aliases got messed up, and I've been sending
to the wrong address... :-(


> From @cis.udel.edu:duzan@udel.edu Sun May  2 17:37:31 1993
>    I recently got mail send to the list bounced back with the address
> of someone I've never heard of, so I took a look at the current list.
> 
> (You know all the familiar faces...)
> 
> Who?
> ----
> 250-<newlin@ecn.purdue.edu>

	John Newlin - He was interested in helping, but now...?


> 250-<fate@ccwf.cc.utexas.edu>

	Eric Fate - Also interested in helping, very quiet too!


> 250-<rahul@npac.syr.edu>

	Again, I received some mail interested in helping, then nothing...


> 250-Stephanie Lai Yi Chong <chongg>
> 250 <larrie@reg.triumf.ca>                <--- Bounced

	These two I've never heard of...Rob (McKeever)...any thoughts on
	who they are? :-)


>    So what do those who read think of those of us who write? Are we
> entertaining enough?

I sure hope so!

	Dennis



From dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed Apr  7 13:20:34 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20233; Wed, 7 Apr 93 13:20:33 +0200
Return-Path: <dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 7 Apr 93 13:20:33 +0200
Received: from udel.edu (louie.udel.edu) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa04516; 7 Apr 93 7:17 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa09498; 7 Apr 93 11:17 GMT
Received: from sol.cis.udel.edu by dori.cis.udel.edu id aa11911;
          7 Apr 93 11:15 GMT
To: Francois-Rene Rideau <rideau@clipper>
Subject: Re: Definitions 
Date: Wed, 07 Apr 93 07:14:46 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9304071115.aa11911@dori.cis.udel.edu>
Status: OR

In Message <9304061233.AA00265@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=> Excuse my ignorance, but where can I get CACM papers ?
=> Thanx for your help.

   You can find Communications of the ACM (CACM) in most any
technical or University library, or you can order back issues
from ACM, though I imagine that it would take a while to get
to France.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri May 14 13:43:43 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25054; Fri, 14 May 93 13:43:42 +0200
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 14 May 93 13:43:42 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22356; Fri, 14 May 93 04:36:56 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa02927; 14 May 93 7:35 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa21608;
          14 May 93 11:31 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa03052;
          14 May 93 11:30 GMT
To: moose-programmers@sfu.ca
Subject: Well.....
Date: Fri, 14 May 93 07:30:42 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305141130.aa03052@thorin.cis.udel.edu>
Status: OR


   Does anyone have any ideas on some sort of compromise, or is
Dennis working on a design document, or do we call the whole thing
off? Personally, I'm at a loss to come up with a method of agreement
on a basic design philosophy. What do we do now?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From danodom@matt.ksu.ksu.edu Fri May 14 15:28:17 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA26709; Fri, 14 May 93 15:28:16 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Fri, 14 May 93 15:28:16 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA23957; Fri, 14 May 93 06:21:45 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA08199; Fri, 14 May 93 08:22:54 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9305141322.AA08199@matt.ksu.ksu.edu>
Subject: Re: Well.....
To: duzan@udel.edu (Gary D. Duzan)
Date: Fri, 14 May 93 8:22:53 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To:  <9305141130.aa03052@thorin.cis.udel.edu>; from "Gary D. Duzan" at May 14, 93 7:30 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Gary D. Duzan Said:

>    Does anyone have any ideas on some sort of compromise, or is
> Dennis working on a design document, or do we call the whole thing
> off? Personally, I'm at a loss to come up with a method of agreement
> on a basic design philosophy. What do we do now?

Since we seem to be making very little progress using the methods
we are currently using, I propose that everybody obtain a minimum
of 6 2-liter bottles of Pepsi and 2 pizzas, your choice of
topping.  Then we set up an irc channel, and we don't log off
until we've got the basic stuff worked out.

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

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

From dmarer@td2cad.intel.com Fri May 14 18:33:21 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00392; Fri, 14 May 93 18:33:20 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 14 May 93 18:33:20 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02104; Fri, 14 May 93 09:29:39 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Fri, 14 May 93 09:29:22 -0700
Received: by td2cad (5.57/10.0i); Fri, 14 May 93 09:33:37 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA04103; Fri, 14 May 93 09:28:31 PDT
Message-Id: <9305141628.AA04103@iws804.intel.com>
Subject: Re: Well.....
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Fri, 14 May 93 9:28:28 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Forwarded message:
> From danodom@matt.ksu.ksu.edu Fri May 14 06:29:58 1993
> 
> Gary D. Duzan Said:
> 
> >    Does anyone have any ideas on some sort of compromise, or is
> > Dennis working on a design document, or do we call the whole thing
> > off? Personally, I'm at a loss to come up with a method of agreement
> > on a basic design philosophy. What do we do now?
> 
> Since we seem to be making very little progress using the methods
> we are currently using, I propose that everybody obtain a minimum
> of 6 2-liter bottles of Pepsi and 2 pizzas, your choice of
> topping.  Then we set up an irc channel, and we don't log off
> until we've got the basic stuff worked out.

Dennis here...

Yes, its been very quiet lately!

I've been directing my efforts towards "Moose", which (I think you all have
approved of) is the name of just the kernel portion of the operating system.
I'm almost finished with a document which will (hopefully) help give this
project the direction it needs.  To come before the actual specs, its a
proposal stating *why* we're working on this project (that was the easy part),
*what* it will contain (size and speed requirements, functionality overview),
and *when* we plan to do it all.

It's finished except for the *when* aspect and some minor details in the *what*
section.  Expect it the end of next week (5/23 at the latest).


Sorry about the slow pace, but I've got a lot going on in addition to Moose -
work, studying for the GREs, etc...guaranteed I've already spent a few nights
snarfing pizza until 2 in the morning (last night was one) trying to make
everying come together.  I'm still driven by this project, and still very
dedicated to making it work out.

And I'd still like to have a working kernel done by the end of the year. (wink)


So...about those device drivers you're all working on?  Remember?


	Dennis


From dmarer@td2cad.intel.com Fri May 14 18:38:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00646; Fri, 14 May 93 18:38:53 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 14 May 93 18:38:53 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02573; Fri, 14 May 93 09:35:33 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Fri, 14 May 93 09:35:30 -0700
Received: by td2cad (5.57/10.0i); Fri, 14 May 93 09:39:43 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA04133; Fri, 14 May 93 09:34:38 PDT
Message-Id: <9305141634.AA04133@iws804.intel.com>
Subject: Still there?
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Fri, 14 May 93 9:34:35 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Me again!

I wanted to get an idea who is going to be around this summer?  School ends
pretty quick for a lot of you...drop me some mail if you will be.

	Dennis


From dmarer@td2cad.intel.com Fri May 14 18:51:31 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00834; Fri, 14 May 93 18:51:30 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Fri, 14 May 93 18:51:30 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03818; Fri, 14 May 93 09:48:17 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Fri, 14 May 93 09:48:13 -0700
Received: by td2cad (5.57/10.0i); Fri, 14 May 93 09:52:28 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA04157; Fri, 14 May 93 09:47:23 PDT
Message-Id: <9305141647.AA04157@iws804.intel.com>
Subject: Device Drivers
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Fri, 14 May 93 9:47:20 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Forwarded message:
> From danodom@matt.ksu.ksu.edu Fri May 14 09:42:20 1993
> From: danodom@matt.ksu.ksu.edu (Dan Odom)
> Message-Id: <9305141637.AA18414@matt.ksu.ksu.edu>
> Subject: Re: Well.....
> To: dmarer@iws804.intel.com (Dennis Marer)
> Date: Fri, 14 May 93 11:37:56 CDT
> In-Reply-To: <9305141628.AA04103@iws804.intel.com>; from "Dennis Marer" at May 14, 93 9:28 am
> X-Mailer: ELM [version 2.3 PL11]
> 
> Dennis Marer Said:
> 
> > So...about those device drivers you're all working on?  Remember?
> 
> Ummmm... Isn't that a little tough without a compiler?  Or do
> you mean 'dd _specs_'?

Does it matter?  What have you accomplished?  Have you written test code?
Have you written down your ideas?  Anything?

Dennis


From winikoff@cs.mu.OZ.AU Sat May 15 16:26:56 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22663; Sat, 15 May 93 16:26:55 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sat, 15 May 93 16:26:55 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA23407; Sat, 15 May 93 07:23:30 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA22548
	Sun, 16 May 1993 00:23:25 +1000 (from winikoff)
Message-Id: <9305151423.22548@mulga.cs.mu.OZ.AU>
Subject: Re: Still there?
To: moose-programmers@sfu.ca (Moose Project)
Date: Sun, 16 May 93 0:23:25 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9305141634.AA04133@iws804.intel.com>; from "Dennis Marer" at May 14, 93 9:34 am
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> Me again!
> 
> I wanted to get an idea who is going to be around this summer?  School ends
> pretty quick for a lot of you...drop me some mail if you will be.

Summer? It's currenltly vaguelly winter here and I've just finished my first 
semester (of two).
I'l be around for a while.

> 
> 	Dennis
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From danodom@matt.ksu.ksu.edu Sat May 15 19:24:44 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24080; Sat, 15 May 93 19:24:43 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sat, 15 May 93 19:24:43 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26214; Sat, 15 May 93 10:22:52 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA02198; Sat, 15 May 93 12:24:16 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9305151724.AA02198@matt.ksu.ksu.edu>
Subject: Where IS everybody
To: moose-programmers@sfu.ca (Moose List)
Date: Sat, 15 May 93 12:24:16 CDT
X-Mailer: ELM [version 2.3 PL11]
Status: OR


Haven't seen much MOOSE activity lately,  not even many responses to
Dennis's 'Are you still THERE?' message.

If you are all having thoughts of abandoning this project, I want you
to know that if you leave I will hunt down each of you
individually, cut your testes off with a potato peeler, rip your skin
off with a filet knife, dip your internal organs in the Great Salt
Lake, and force you to watch Barney reruns till you puke.

:-) :-) :-)


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

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

From ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sat May 15 22:01:03 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25524; Sat, 15 May 93 22:01:02 +0200
Return-Path: <ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sat, 15 May 93 22:01:02 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA29288; Sat, 15 May 93 12:58:40 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa08779;
          15 May 93 15:54 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa07881;
          15 May 93 19:50 GMT
Received: from sol.cis.udel.edu by ori.cis.udel.edu id aa24171;
          15 May 93 19:48 GMT
To: Dan Odom <danodom@matt.ksu.ksu.edu>
Cc: Moose List <moose-programmers@sfu.ca>
Subject: Re: Where IS everybody 
Date: Sat, 15 May 93 15:48:40 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305151948.aa24171@ori.cis.udel.edu>
Status: OR

In Message <9305151724.AA02198@matt.ksu.ksu.edu> ,
   Dan Odom <danodom@matt.ksu.ksu.edu> wrote:

=>
=>Haven't seen much MOOSE activity lately,  not even many responses to
=>Dennis's 'Are you still THERE?' message.
=>
=>If you are all having thoughts of abandoning this project, I want you
=>to know that if you leave I will hunt down each of you
=>individually, cut your testes off with a potato peeler, rip your skin
=>off with a filet knife, dip your internal organs in the Great Salt
=>Lake, and force you to watch Barney reruns till you puke.
=>
=>:-) :-) :-)
=>
   Just a warning: I'm 6'5", 250 lbs., and keep a loaded broadsword
next to my bed. :-)
   We do, however, have a great opportunity for endless debate here.
I've still not seen any agreement on the basic system structure. What
is an object? How do they relate with respect to high-level
languages, protection, scheduling, invocation? Are devices, memory
management, paging, networking, etc., part of the kernel or just
special objects? How do we fit our design decisions to various
architectures? How much should we use existing utilities and
technology?
   Opinions, anyone?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Sun May 16 14:50:35 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA11151; Sun, 16 May 93 14:50:34 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Sun, 16 May 93 14:50:34 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12851; Sun, 16 May 93 05:48:34 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA02784; Sun, 16 May 93 14:48:27 +0200
Received: from ave11.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA05839; Sun, 16 May 93 14:48:26 +0200
Date: Sun, 16 May 93 14:48:26 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305161248.AA05839@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Where IS everybody
Status: OR

Hi,

sorry for beeing absent quite a long time, but I'm currently full of work to
finish my diploma thesis. I apologize to let you alone ... ;-)

Maybe there's a possibility to get things started. Mmh, I think we all do agree,
that the basic mechanism which must be provided by the kernel (Moose) must
be interprocess communication. (Or: message passing).

Therefore we have to create a module, which provides an interface with three
primitives, namely:

	send(destination, message)
	receive(from, message)
	reply(to)

I suggest synchronous ipc, because it seems to me to be the basis of any other
ipc types.

Where we still have to get to an agreement is:

o How looks a destination address? 
  Should it look like this: (machine address, object id, method id)
  or only like this: (object id, method id)
  or like this: (machine address, process id)
  or: ???

o How is address translation done?
  We have to specify the size of the address's parts.
  Here we have to say definitely where we expect Moose to run. Should it be
  able to run Moose on several machines or only on one? The latter will not
  require a machine address part, but that's clear.

o How is abstraction to hardware provided? 
  This covers the lower area of message passing. We need routines (but only a
  few) which realize the message transfer. There should also be routines for
  signal handling. (They should build a message which is then sent to an
  appropriate signal server.)

Let me know what you think. If you want, I can try to write a draft about
the IPC interface. I will wait for Dennis' next spec's because it will
give a us a basis. Ok?

Next: Forgive my english, I've had a long long night yesterday and it seems
that I'm standing 1 m besides myself ...

Bye,

Peter

P.S: One for the compiler designer. I don't think, that the missing of a
compiler is a thing which disables us to start writing. If you provide the
possibility to use interfaces to other languages (preferably some which are
in common use, like C++), it's possible to start writing. (BTW: As some code
of the kernel must be done in Assembler, there must be at last an interface
to that sort of language ...)

From bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sun May 16 17:08:43 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12464; Sun, 16 May 93 17:08:42 +0200
Return-Path: <bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sun, 16 May 93 17:08:42 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA13742; Sun, 16 May 93 08:06:47 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ac20151;
          16 May 93 10:58 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id ab18706;
          16 May 93 14:55 GMT
Received: from sol.cis.udel.edu by bofur.cis.udel.edu id aa28588;
          16 May 93 14:53 GMT
To: Peter Mueller <mueller@sc.zib-berlin.de>
Cc: moose-programmers@sfu.ca
Subject: Re: Where IS everybody 
Date: Sun, 16 May 93 10:52:49 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305161453.aa28588@bofur.cis.udel.edu>
Status: OR

In Message <9305161248.AA05839@sc.zib-berlin.dbp.de> ,
   Peter Mueller <mueller@sc.zib-berlin.de> wrote:

=>Maybe there's a possibility to get things started. Mmh, I think we all do agr
ee,
=>that the basic mechanism which must be provided by the kernel (Moose) must
=>be interprocess communication. (Or: message passing).
=>
   Absolutely.

=>Therefore we have to create a module, which provides an interface with three
=>primitives, namely:
=>
=>	send(destination, message)
=>	receive(from, message)
=>	reply(to)
=>
=>I suggest synchronous ipc, because it seems to me to be the basis of
=>any other ipc types.
=>
   I used to be of this opinion, but I've changed my mind somewhat. I
still think that the basic *user* level IPC mechanism should be based
on blocking RPC, as you have described. However, there are some
advantages to building synchonous calls out of asynchronous calls.
(i.e. asynch_send(dest, msg) -> reply_id; block(reply_id)) For example,
a user-level thread package would be much easier to implement in this
scenario. On the other hand, advances in technology may allow us
eventually to use normal function calls to implement IPC, which is
basically blocking the caller untill the function returns, so we should
make it possible to use such a technology as it becomes available.
   So I would advise making IPC asynchronous at the system level and
providing standard library (or langauge-imbedded) functions for
synchrounous IPC. When the secure function call technology appears, we
can simply change the library function (compiler) to use the new call.

=>Where we still have to get to an agreement is:
=>
=>o How looks a destination address? 
=>  Should it look like this: (machine address, object id, method id)
=>  or only like this: (object id, method id)
=>  or like this: (machine address, process id)
=>  or: ???
=>
   I don't think including the machine address is necessary, and not
particularly desirable as part of a system that may very well be
stand-alone. Therefore, (object id, method id [, authorization])
would seem to be the logical answer. To support object server
objects, I would suggest a two-level object id (external and
internal), or possibly object id classes (analogous to Internet
network classes and subnets.) This would allow for addressing either
entire system objects or smaller objects managed by the larger system
object with no change in call syntax. Objects on remote machines
could be accessed via a network object server object that does
translation and forwards calls to a network object server object on
the destination machine, which does the actual call.

=>Let me know what you think. If you want, I can try to write a draft about
=>the IPC interface. I will wait for Dennis' next spec's because it will
=>give a us a basis. Ok?
=>
   Sounds good to me.

=>Next: Forgive my english, I've had a long long night yesterday and it seems
=>that I'm standing 1 m besides myself ...
=>
   Your English looks ok to me. Get some rest; I'm sure you've earned
it.

=>Bye,
=>
=>Peter
=>
=>P.S: One for the compiler designer. I don't think, that the missing of a
=>compiler is a thing which disables us to start writing. If you provide the
=>possibility to use interfaces to other languages (preferably some which are
=>in common use, like C++), it's possible to start writing. (BTW: As some code
=>of the kernel must be done in Assembler, there must be at last an interface
=>to that sort of language ...)

   Indeed. I'd rather use something better now, but if it isn't
available, we can't exactly use it now, can we?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Sun May 16 15:16:06 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA11505; Sun, 16 May 93 15:16:05 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Sun, 16 May 93 15:16:05 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12992; Sun, 16 May 93 06:13:32 -0700
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA12570
	Sun, 16 May 1993 22:53:07 +1000 (from winikoff)
Message-Id: <9305161253.12570@mulga.cs.mu.OZ.AU>
Subject: Re: Where IS everybody
To: moose-programmers@sfu.ca (Moose Project)
Date: Sun, 16 May 93 22:53:06 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To:  <9305151948.aa24171@ori.cis.udel.edu>; from "Gary D. Duzan" at May 15, 93 3:48 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> 
> In Message <9305151724.AA02198@matt.ksu.ksu.edu> ,
>    Dan Odom <danodom@matt.ksu.ksu.edu> wrote:
> 
> =>
> =>Haven't seen much MOOSE activity lately,  not even many responses to
> =>Dennis's 'Are you still THERE?' message.
> =>
> =>If you are all having thoughts of abandoning this project, I want you
> =>to know that if you leave I will hunt down each of you
> =>individually, cut your testes off with a potato peeler, rip your skin
> =>off with a filet knife, dip your internal organs in the Great Salt
> =>Lake, and force you to watch Barney reruns till you puke.
> =>
> =>:-) :-) :-)
> =>
>    Just a warning: I'm 6'5", 250 lbs., and keep a loaded broadsword
> next to my bed. :-)
>    We do, however, have a great opportunity for endless debate here.
> I've still not seen any agreement on the basic system structure. What
> is an object? How do they relate with respect to high-level
> languages, protection, scheduling, invocation? Are devices, memory
> management, paging, networking, etc., part of the kernel or just
> special objects? How do we fit our design decisions to various
> architectures? How much should we use existing utilities and
> technology?
>    Opinions, anyone?
> 
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 

Michael -- not 6'5'', doesn't keep a broadsword, BUT far away in australia :-)

> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.

From mueller@sc.ZIB-Berlin.DE Mon May 17 10:10:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA28913; Mon, 17 May 93 10:10:26 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 17 May 93 10:10:26 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02964; Mon, 17 May 93 01:03:43 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA03759; Mon, 17 May 93 10:03:36 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA06369; Mon, 17 May 93 10:03:36 +0200
Date: Mon, 17 May 93 10:03:36 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305170803.AA06369@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Delivery problem to LARRIE...?
Status: OR

Hi, 

I don't know who this user is but I've received a mail from 
Postmaster@erich.triumf.ca that there is a delivery problem to user
"LARRIE". As I don't know the exact mailing procedure I will give you
the header:

----- begin header -----
>From Mailer-Daemon@sc Sun May 16 14:51:47 1993
Date: Sun, 16 May 1993 05:53:26 PDT
From: Local delivery agent <Postmaster@erich.triumf.ca>
To: <mueller@sc.ZIB-Berlin.DE>
Subject: LOCAL delivery error
Content-Length: 3017

Note: this message was generated automatically.

The following error(s) occurred during local delivery of your message.

Error delivering to user "LARRIE": user unknown
Message follows.

Received: from whistler.sfu.ca ([128.189.32.1]) by REG.TRIUMF.CA (MX V3.1C) with SMTP; Sun, 16 May 1993 05:53:23 PDT
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0) id AA12851; Sun, 16 May 93 05:48:34 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93) id AA02784; Sun, 16 May 93 14:48:27 +0200
Received: from ave11.ZIB-Berlin.DE by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 ) id AA05839; Sun, 16 May 93 14:48:26 +0200
Date: Sun, 16 May 93 14:48:26 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-ID: <9305161248.AA05839@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Where IS everybody

----- end header -----

I hope one of you is able to let me see things clearer. Thanks,

Peter

From mueller@sc.ZIB-Berlin.DE Mon May 17 11:33:43 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01358; Mon, 17 May 93 11:33:40 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 17 May 93 11:33:40 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03580; Mon, 17 May 93 01:52:19 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA03957; Mon, 17 May 93 10:52:15 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA06489; Mon, 17 May 93 10:52:14 +0200
Date: Mon, 17 May 93 10:52:14 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305170852.AA06489@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: ORG, IPC, pem 05/17/93
Status: OR

Hi, 

this is actually a reply to a mail with subject "Re: Where IS everybody". I
think that the new subject line will make things much more clearer. And now,
for something completely different ... 

> =>Maybe there's a possibility to get things started. Mmh, I think we all do agr
> ee,
> =>that the basic mechanism which must be provided by the kernel (Moose) must
> =>be interprocess communication. (Or: message passing).
> =>
>    Absolutely.
> 
> =>Therefore we have to create a module, which provides an interface with three
> =>primitives, namely:
> =>
> =>	send(destination, message)
> =>	receive(from, message)
> =>	reply(to)
> =>
> =>I suggest synchronous ipc, because it seems to me to be the basis of
> =>any other ipc types.
> =>
>    I used to be of this opinion, but I've changed my mind somewhat. I
> still think that the basic *user* level IPC mechanism should be based
> on blocking RPC, as you have described. However, there are some
> advantages to building synchonous calls out of asynchronous calls.
> (i.e. asynch_send(dest, msg) -> reply_id; block(reply_id)) For example,
> a user-level thread package would be much easier to implement in this
> scenario. On the other hand, advances in technology may allow us
> eventually to use normal function calls to implement IPC, which is
> basically blocking the caller untill the function returns, so we should
> make it possible to use such a technology as it becomes available.

Let me comment on this: 

1. A user should, of course, use blocking RPC (which meant ROI). This is the usual
   way to communicate in an OO-environment. (Ok, but to be honest: I suppose that
   their will be some low-level user who uses low-lewel languages and who will
   call IPC primitives directly ... but that's for the system people :-)
   Nonetheless their must be provided mechanisms within the kernel with which ROI
   can be provided. ROI is a more conceptual view of communication. As is RPC in
   common procedure oriented environments. RPC also is only a conceptual model, where
   the IPC stuff is hidden by stubs, which are in turn automatically created.
   We have also to create such "stubs", though they will actually be some kind of
   communication objects. They should handle all necessary stuff to invoke a remote
   method.


2. Now for the difficult part. I do not agree to include asynchronous calls within
   the kernel. Here comes my reasoning.
   Asynchronous communication requires additional overhead. Their must be buffer
   allocation, management, reallocation, etc. This will slow down the whole system!
   (This is proved within some existing systems.) Additionally the kernel will be much
   more bigger. Management will be much more complicated, hence, overhead.
   Well, I know the user is always asking for asynchronous IPC, because it is a much
   more "natural" way to see communication. Of course, there is an alternative. It's
   OO! If someone definitely wants asynchronous IPC he/she should get it with the 
   mechanisms of OO. See, that asynchronous IPC is a specialization of synchronous
   IPC: It is actually specialized in buffering.
   A second alternative is to provide a kind of "buffer manager", which is, of course,
   a server object. If you want a buffered communication, simply install a synchronous
   communication channel to the buffer manager. This manager will then setup a 
   synchronous communication channel to the real destination. Now we have a asynchronous
   communication channel from source to destination, where the buffer manager lays
   in between. BTW: This will give you the freedom to provide several different
   buffer management policies. You can choose your own buffer size. And that's all on
   the fly (same is for the above OO solution).
   On the other hand a user who wants to get the whole out of the system is not 
   disturbed in doing so. He simply can avoid a massive communication overhead in
   using the "basic" synchronous primitives (which are very very fast :-).

>    So I would advise making IPC asynchronous at the system level and
> providing standard library (or langauge-imbedded) functions for
> synchrounous IPC. When the secure function call technology appears, we
> can simply change the library function (compiler) to use the new call.

And I say make it vice-versa: Provide synchronous IPC at system level and make a
standard lib. for asynchronous IPC. Yup, and: BEWARE, I'm a tough guy to argue with
in that subject ... grrrrrr >:-|

> 
> =>Where we still have to get to an agreement is:
> =>
> =>o How looks a destination address? 
> =>  Should it look like this: (machine address, object id, method id)
> =>  or only like this: (object id, method id)
> =>  or like this: (machine address, process id)
> =>  or: ???
> =>
>    I don't think including the machine address is necessary, and not
> particularly desirable as part of a system that may very well be
> stand-alone. Therefore, (object id, method id [, authorization])
> would seem to be the logical answer. To support object server
> objects, I would suggest a two-level object id (external and
> internal), or possibly object id classes (analogous to Internet
> network classes and subnets.) This would allow for addressing either
> entire system objects or smaller objects managed by the larger system
> object with no change in call syntax. Objects on remote machines
> could be accessed via a network object server object that does
> translation and forwards calls to a network object server object on
> the destination machine, which does the actual call.
> 

Ok. That's one design decision. Then we should provide an address object. I think
that we can provide a mechanism with which a specialization into several address
layouts can be made. (I mean, that if in the far future one want to extend Moose
to a distributed OS the addressing mechanism can simply be adjusted. Got to think
this over, anyway ...)

Now I've got a question: An address of (Object id, method id [,authorization]).
Why is authorization necessary? Isn't it enough that, IF an object have the address
(object id, method id), THEN it is automatically authorized to call the method? Then
authorization is separated from the objects. As the actual address is grabbed from
a (what's it name DIRECTORY? and: where's the glossary?) Object, why not providing 
authorization tasks within that object?

You are then again free to provide several security policies on the fly by choosing
the appropriate directory object. So you can range from a system with no security at all to
a full secured system. Of course, the request for receiving an object's address must
hold a kind of ticket. This ticket should identify the owner of the request and its
permission rights.

> =>Let me know what you think. If you want, I can try to write a draft about
> =>the IPC interface. I will wait for Dennis' next spec's because it will
> =>give a us a basis. Ok?
> =>
>    Sounds good to me.
> 

Dennis? Your work! :-)

>                                        Gary Duzan
>                                        Time  Lord
>                                    Third Regeneration
>                         Humble Practitioner of the Computer Arts

Peter


From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon May 17 16:33:47 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA06713; Mon, 17 May 93 16:33:45 +0200
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 17 May 93 16:33:45 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08092; Mon, 17 May 93 07:16:52 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ac29607;
          17 May 93 10:13 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa02295;
          17 May 93 14:10 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa10187;
          17 May 93 14:06 GMT
To: Peter Mueller <mueller@sc.zib-berlin.de>
Cc: moose-programmers@sfu.ca
Subject: Re: ORG, IPC, pem 05/17/93 
Date: Mon, 17 May 93 10:06:43 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305171406.aa10187@bifur.cis.udel.edu>
Status: OR

In Message <9305170852.AA06489@sc.zib-berlin.dbp.de> ,
   Peter Mueller <mueller@sc.zib-berlin.de> wrote:

=>Let me comment on this: 

=> 1. A user should, of course, use blocking RPC (which meant
=>    ROI).  This is the usual way to communicate in an
=>    OO-environment.  (Ok, but to be honest: I suppose that their
=>    will be some low-level user who uses low-lewel languages and
=>    who will call IPC primitives directly ...  but that's for the
=>    system people :-) Nonetheless their must be provided
=>    mechanisms within the kernel with which ROI can be provided.
=>    ROI is a more conceptual view of communication. As is RPC in
=>    common procedure oriented environments. RPC also is only a
=>    conceptual model, where the IPC stuff is hidden by stubs,
=>    which are in turn automatically created.  We have also to
=>    create such "stubs", though they will actually be some kind
=>    of communication objects.  They should handle all necessary
=>    stuff to invoke a remote method.

   Fair enough.

=> 2. Now for the difficult part. I do not agree to include
=>    asynchronous calls within the kernel.

=>>    So I would advise making IPC asynchronous at the system level and
=>> providing standard library (or langauge-imbedded) functions for
=>> synchrounous IPC. When the secure function call technology appears, we
=>> can simply change the library function (compiler) to use the new call.
=>
=> And I say make it vice-versa: Provide synchronous IPC at system
=> level and mak e a standard lib. for asynchronous IPC. Yup, and:
=> BEWARE, I'm a tough guy to argue with in that subject ...
=> grrrrrr >:-|

   Ok, ok, calm down. :-) I can live with synchronous IPC as long
as we have good context switch time and kernel-level multiple
thread support.

=> Now I've got a question: An address of (Object id, method id
=> [,authorization] ).  Why is authorization necessary? Isn't it
=> enough that, IF an object have the address (object id, method
=> id), THEN it is automatically authorized to call the method?
=> Then authorization is separated from the objects. As the actual
=> address is grabbed from a (what's it name DIRECTORY? and:
=> where's the glossary?) Object, why not providing authorization
=> tasks within that object?
=> You are then again free to provide several security policies on
=> the fly by choosing the appropriate directory object. So you
=> can range from a system with no security at all to a full
=> secured system. Of course, the request for receiving an object's
=> address must hold a kind of ticket. This ticket should identify
=> the owner of the request and its permission rights.

   The case you mention is using implicit rather than explicit
authorization. Also, unless steps are taken to insure that it
is very difficult (ideally impossible) to forge an address
(capability, protected pointer, whatever), then it will not be
secure. These steps I rolled up and called "authorization",
since there is any number of ways to do it.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From danodom@matt.ksu.ksu.edu Tue May 18 00:29:08 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23014; Tue, 18 May 93 00:29:07 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Tue, 18 May 93 00:29:07 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15346; Mon, 17 May 93 15:16:08 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA29740; Mon, 17 May 93 17:17:10 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9305172217.AA29740@matt.ksu.ksu.edu>
Subject: Beginning Work [djo9]
To: mueller@sc.zib-berlin.de (Peter Mueller)
Date: Mon, 17 May 93 17:17:10 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <9305161248.AA05839@sc.zib-berlin.dbp.de>; from "Peter Mueller" at May 16, 93 2:48 pm
X-Mailer: ELM [version 2.3 PL11]
Content-Length: 2499
X-Lines: 67
Status: OR

Peter Mueller Said:

> Therefore we have to create a module, which provides an interface with three
> primitives, namely:
> 
> 	send(destination, message)
> 	receive(from, message)
> 	reply(to)

Agreed.

> Where we still have to get to an agreement is:
> 
> o How looks a destination address? 
>   Should it look like this: (machine address, object id, method id)
>   or only like this: (object id, method id)
>   or like this: (machine address, process id)
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That one.  Each process should have a 'message-handler' object that
will receive messages and notify the rest of the process.

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

> o How is address translation done?
>   We have to specify the size of the address's parts.
>   Here we have to say definitely where we expect Moose to run. Should it be
>   able to run Moose on several machines or only on one? The latter will not
>   require a machine address part, but that's clear.

Explain what you mean by 'more than one machine'.

> Next: Forgive my english, I've had a long long night yesterday and it seems
> that I'm standing 1 m besides myself ...

That's OK.  Sometimes I forget English... :-)

> 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.

> I don't think, that the missing of a
> compiler is a thing which disables us to start writing. If you provide the
> possibility to use interfaces to other languages (preferably some which are
> in common use, like C++), it's possible to start writing. (BTW: As some code
> of the kernel must be done in Assembler, there must be at last an interface
> to that sort of language ...)

Correct.  BUT, we haven't even decided what language we'll use (or if
we have, no one told me).  Work on the C/C++ libraries can begin as
soon as the kernel API is developed, and some work can be done before it is
complete.  This assumes we're using C(++).

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.


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

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

From danodom@matt.ksu.ksu.edu Tue May 18 00:57:17 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23453; Tue, 18 May 93 00:57:16 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Tue, 18 May 93 00:57:16 +0200
Received: from matt.ksu.ksu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AB02069; Mon, 17 May 93 17:59:06 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9305172259.AB02069@matt.ksu.ksu.edu>
Subject: Re: Bases [far34] [djo10]
To: rideau@clipper (Francois-Rene Rideau)
Date: Mon, 17 May 93 17:59:05 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <9305172238.AA23280@clipper.ens.fr>; from "Francois-Rene Rideau" at May 18, 93 12:38 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Francois-Rene Rideau Said:

> Unknown
> ~~~~~~~
> 
> Questions:
> @) What will we do that will be the same as or different from
> other systems, currently existing or being developped ?

We will create a 32-bit PC OS with preemptive multitasking.  We will
be 'Object-Oriented', and that will set us apart from Linux, etc.

> a) What does OO means for an OS ; i.e. what do we mean by "object" ?

It will be easier to extend MOOSE than it is to extend other OSs.  I
think fare answered this to my satisfaction; I won't explain here.

> c) What kind of typing/checking will the kernel/base system include,
> if any ?

Typed, but can be overridden.

> d) Must we include a standard LLL in the base system

Include an assembler; that should be enough.

> e) Must we prepare for future distributedness (i.e. refuse solutions
> that won't adapt to a distributed OS).

Yes.

> b) Object ID's.

machine:PID

> c) Objects Classes.

Huh?  Explain what you mean by this.



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

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

From rideau@clipper Tue May 18 00:46:06 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23327; Tue, 18 May 93 00:46:04 +0200
Return-Path: <rideau@clipper>
Received-Date: Tue, 18 May 93 00:46:04 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from nef.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17091; Mon, 17 May 93 15:39:19 -0700
Received: from dmi.ens.fr by nef.ens.fr (5.65c8/ULM-1.0)
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fregate.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23280; Tue, 18 May 93 00:38:38 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9305172238.AA23280@clipper.ens.fr>
Subject: Bases [far34]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Tue, 18 May 93 0:38:39 MET DST
X-Mailer: ELM [version 2.3 PL11]
Content-Length: 4936
X-Lines: 121
Status: OR

 Well, here is I think the main points we MUST agree before we can
begin coding what we call MOOSE (but we already can begin coding
IO drivers and suches).

SPECS
~~~~~

agreements
~~~~~~~~~~
a) MOOSE is "OO" (see Unknown, a))
b) we'll develop a generic UI (user interface), that will
specialize/extend into a TUI (Text UI) and a GUI (Graphical).
c)

Unknown
~~~~~~~

Questions:
@) What will we do that will be the same as or different from
other systems, currently existing or being developped ?
a) What does OO means for an OS ; i.e. what do we mean by "object" ?
b) How light will our basic objects/threads/tasks/processes be ?
c) What kind of typing/checking will the kernel/base system include,
if any ?
d) Must we include a standard LLL in the base system
e) Must we prepare for future distributedness (i.e. refuse solutions
that won't adapt to a distributed OS).

Answers:
Fare:
@) Object Orientedness will make us differ from everything else.
See a). Difference with NeXTStep ? I recommend using a tiny object
grain, whereas NeXTStep seems to use big objects and big messages.
a) it means objects are the generic basic system unit. Unix had files,
directories, devices, pipes, sockets, each completely different and
unextensible without kernel change. We'll have only one basic item,
which will be generic enough to contain code and data of any kind
wanted, and standard enough to be a media for code&data exchange
between programs (which is currently what @%^@%! computer users and
programmers most of the time).
b) Very light: objects are any kind, any size. A larger object is
a structure of smaller objects.
c) The whole thing. Typing some generalization of protection. At a
high level, typing IS protection. If you do not enforce typing
somehow, you won't have a secure OO system, so no one wishing
security will use system objects; you won't have an OO system, but
a common system like any other one; if so, let's just be happy with
unix.
Let us have a standard for describing objects. After that, we
can use this standard to describe other ways to describe objects, when
we want more extended classes. Let us have a HLL which will enable
direct access to this standard.
d) Yes, together with typing (will thus include code&data); see a);
at least, we need some way of exchanging code together with data.
Imagine a brand new format for this or that (example: the brand new
format YOU just designed); you'd like not to get/wait for/pay for
a brand huge (the hugest, the slowest/most difficult/most expensive
to get new version of each of your application to understand it; but
if you just get the proper small code for it, that's ok, and all your
apps will understand it). What I ask for is possible exchange of code,
in some compact and directly executable (or quickly compilable)
format.
e) Yes, because future machines WILL be distributed; the laws of
physics limit the power of a single processor. To break this barrier,
systems will HAVE to be distributed. So if we want not to write
Moose for nothing, we must prepare it for further extensions.


FIRST IMPLEMENTATION
~~~~~~~~~~~~~~~~~~~~
agreements
~~~~~~~~~
a) Moose will run on 386 PC compatible machines.

Unknown
~~~~~~~

Questions:


a) Kernel Requirements:
 - That's just a policy question, and there is a priori no rational
 arguments about it, but what machines we work on.
b) Object ID's.
c) Objects Classes.

Solutions proposed:
Fare:
a) a 386 with extended memory (even 384KB suffice for just booting
with a console ?).
b) use DT:Seg identifiers, or DT:Seg:Offset when needed. (when needed,
the offset may be considered as an argument to DT:Seg as a function
represented by the array of its values).
c) Disk representation will use integer codes (0,1,2,3,...) for
objects. When loaded to memory, these codes are eventually converted
to nearer or farer object IDs (and conversely), for fast
evaluation/access. (Note: this can be done at load time, or at use
time, or sometime in between, what is important is that disk
representation is portable, whereas memory representation is
efficient). 
To physically access an object, we need both its local data and its
more global class, and perhaps even more global meta-classes (a/o
classes you inherit from, etc). So what I propose is, at link time
(which can be just after loading, or during use), use two pointers
(or standard IDs of any kind), one to the class as a description of
data/methods, and to the effective data. If someone wants virtual
pointers, he'll have to use virtual memory traps so that a common
pointer using program can access it.


Please state your mind.
Please recall forgotten points.
Please add your comments.
Please correct mistype/broken english, or mistakes.
I'll maintain this bases list until we come to an agreement, or
someone is willing to replace me, so even a quick personal reply
in telegraphic style will be accepted, and I'll summarize it as soon
as received.

   ,
Fare

From rideau@clipper Tue May 18 04:44:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25664; Tue, 18 May 93 04:44:24 +0200
Return-Path: <rideau@clipper>
Received-Date: Tue, 18 May 93 04:44:24 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from nef.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28960; Mon, 17 May 93 19:27:56 -0700
Received: from dmi.ens.fr by nef.ens.fr (5.65c8/ULM-1.0)
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fregate.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25579; Tue, 18 May 93 04:26:46 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9305180226.AA25579@clipper.ens.fr>
Subject: Re: Beginning Work [djo9] [far35]
To: danodom@matt.ksu.ksu.edu (Dan Odom)
Date: Tue, 18 May 93 4:26:47 MET DST
Cc: mueller@sc.zib-berlin.de, moose-programmers@sfu.ca
In-Reply-To: <9305172217.AA29740@matt.ksu.ksu.edu>; from "Dan Odom" at May 17, 93 5:17 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

">" is Dan, quoting ">>" Peter

>> Therefore we have to create a module, which provides an interface with three
>> primitives, namely:
>> 
>> 	send(destination, message)
>> 	receive(from, message)
>> 	reply(to)
> 
> Agreed.
Well, this seems the basis of OOness. What isn't basic, is how we'll
implement it, and what part of it is in the specs/what part is
implementation dependent.

>> Where we still have to get to an agreement is:
>> 
>> o How looks a destination address? 
>>   Should it look like this: (machine address, object id, method id)
>>   or only like this: (object id, method id)
>>   or like this: (machine address, process id)
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That one.  Each process should have a 'message-handler' object that
> will receive messages and notify the rest of the process.

Well, an object's class is its message handler, isn't it ?
But what kind of message will the kernel transmit ?
Raw binary data ?
Ascii (burp) strings ?
Typed objects ?

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

>> o How is address translation done?
>>   We have to specify the size of the address's parts.
>>   Here we have to say definitely where we expect Moose to run. Should it be
>>   able to run Moose on several machines or only on one? The latter will not
>>   require a machine address part, but that's clear.
> 
> Explain what you mean by 'more than one machine'.
Yes, do you mean have Moose portable (we agreed on that)(Oops ! I forgot it
in my bases posting; tomorrow's version will include it), or have it
distributed in a homogenous net, or even distributed in a heterogeneous net ?
Well, for the moment, we're not building a distributed version of Moose, but
perhaps we can build a driver to virtualize objects on a remote machine linked
by, say, a serial or parallel or ethernet port. However, this is not essential
to the original project (which does not mean we won't do it when we have time)
and this will be limited by our one machine based addressing (but we can build
gates -- no, not Bill Gates ;-( -- between different address types).


>> 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)

>> I don't think, that the missing of a
>> compiler is a thing which disables us to start writing. If you provide the
>> possibility to use interfaces to other languages (preferably some which are
>> in common use, like C++), it's possible to start writing. (BTW: As some code
>> of the kernel must be done in Assembler, there must be at last an interface
>> to that sort of language ...)
> 
> Correct.  BUT, we haven't even decided what language we'll use (or if
> we have, no one told me).  Work on the C/C++ libraries can begin as
> soon as the kernel API is developed, and some work can be done before it is
> complete.  This assumes we're using C(++).

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;

> 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 ?
What about some Objective ML ?
What about these languages Gary talked about ?
What about building our own HLL ?
What about having a language more intelligent than C++ (accepts larger
input to produce better code)

   ,
Fare

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Tue May 18 07:21:04 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04400; Tue, 18 May 93 07:21:03 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Tue, 18 May 93 07:21:03 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA04749; Mon, 17 May 93 22:09:09 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA03663; Tue, 18 May 93 01:09:05 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 010744.10133; Tue, 18 May 1993 01:07:44 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Tue, 18 May 1993 00:54:04 EDT
Date:      Tue, 18 May 1993 00:54:00 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bf86bed.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: ORG, IPC, pem 05/17/93  [djg22]
Status: OR


Gary D. Duzan wrote:

> Peter Mueller <mueller@sc.zib-berlin.de> wrote:
>
> =>Let me comment on this:
>
> => 1. A user should, of course, use blocking RPC (which meant
> =>    ROI).  This is the usual way to communicate in an
> =>    OO-environment.  (Ok, but to be honest: I suppose that their
> =>    will be some low-level user who uses low-lewel languages and
> =>    who will call IPC primitives directly ...  but that's for the
> =>    system people :-) Nonetheless their must be provided
> =>    mechanisms within the kernel with which ROI can be provided.
> =>    ROI is a more conceptual view of communication. As is RPC in
> =>    common procedure oriented environments. RPC also is only a
> =>    conceptual model, where the IPC stuff is hidden by stubs,
> =>    which are in turn automatically created.  We have also to
> =>    create such "stubs", though they will actually be some kind
> =>    of communication objects.  They should handle all necessary
> =>    stuff to invoke a remote method.
>
>    Fair enough.
>
> => 2. Now for the difficult part. I do not agree to include
> =>    asynchronous calls within the kernel.
>
> =>>    So I would advise making IPC asynchronous at the system level and
> =>> providing standard library (or langauge-imbedded) functions for
> =>> synchrounous IPC. When the secure function call technology appears, we
> =>> can simply change the library function (compiler) to use the new call.
> =>
> => And I say make it vice-versa: Provide synchronous IPC at system
> => level and mak e a standard lib. for asynchronous IPC. Yup, and:
> => BEWARE, I'm a tough guy to argue with in that subject ...
> => grrrrrr >:-|
>
>    Ok, ok, calm down. :-) I can live with synchronous IPC as long
> as we have good context switch time and kernel-level multiple
> thread support.

Well, the big problem with providing only synchronous IPC is that you
CANNOT make asynchronous I/O out of it without having a second thread.
The standard way in Unix to do I/O reading from two different sources
is to make one process reading each source.  Unix now has a kludge
called select() that allows a program to identify the descriptors with
available I/O, but this relies on the system and process being able to
keep up with the I/O.  On a VMS system (with asynchronous I/O), one
queues a number of asynchronous I/O calls on each channel, and
processes the data after it is transferred to your processes own space
and you are notified.  I feel this is a much more satisfactory
solution.

Until recently, I had felt that we should provide both synchronous and
asynchronous forms, but I now suspect that, by using only the
asynchronous form, we can have all method receptions having basically
the same starting environment.  With carefull design, starting a new
thread should be a very minor chore, probably less than the cost of
transferring data as part of the call.

> => Now I've got a question: An address of (Object id, method id
> => [,authorization] ).  Why is authorization necessary? Isn't it
> => enough that, IF an object have the address (object id, method
> => id), THEN it is automatically authorized to call the method?
> => Then authorization is separated from the objects. As the actual
> => address is grabbed from a (what's it name DIRECTORY? and:
> => where's the glossary?) Object, why not providing authorization
> => tasks within that object?
> => You are then again free to provide several security policies on
> => the fly by choosing the appropriate directory object. So you
> => can range from a system with no security at all to a full
> => secured system. Of course, the request for receiving an object's
> => address must hold a kind of ticket. This ticket should identify
> => the owner of the request and its permission rights.
>
>    The case you mention is using implicit rather than explicit
> authorization. Also, unless steps are taken to insure that it
> is very difficult (ideally impossible) to forge an address
> (capability, protected pointer, whatever), then it will not be
> secure. These steps I rolled up and called "authorization",
> since there is any number of ways to do it.
>
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts

The obvious way to avoid this is to not make the parameter be the
object ID.  If Unix had used their equivalent, you would pass inode
numbers to read() and write() calls.  The obvious solution is exactly
the same that Unix used, you open() the Object and get a process-
specific identifier.  There is then no possibility of forging
anything, and the authorizations are all checked only once.

On the subject of objects on remote machines, I believe that the
correct way to do this is to access an object of a "remote access
class", and tell it a remote machine and object identification to
connect to.  Once it is connected, all method calls get passed to the
remote machine.  [This might be a seperate meta-class, just so we can
grab all method calls at one point, while not increasing the overhead
for normal objects.]  Once you terminate access to the local object,
the network connection is dropped, and the remote machines object is
no longer used.

-- David

P.S. I should be available all the time except for a week in July and 
a week in December.
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From ANDREASA@dhhalden.no Tue May 18 16:31:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15436; Tue, 18 May 93 16:31:52 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Tue, 18 May 93 16:31:52 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15576; Tue, 18 May 93 07:25:20 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <07978-0@fenris.dhhalden.no>; Tue, 18 May 1993 12:01:39 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Tue, 18 May 93 12:01:33 GMT+1
To: moose-programmers@sfu.ca (Moose List)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 18 May 93 12:00:55 +0100
Subject: Re: Beginning Work [djo9][arf8]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <1781C826AF2@sofus.dhhalden.no>
Status: OR

Hello Moosers, hope I get the numbers right:-)

> is Dan Odom
> > Where we still have to get to an agreement is:
> >
> > o How looks a destination address?
> >   Should it look like this: (machine address, object id, method id)
> >   or only like this: (object id, method id)
> >   or like this: (machine address, process id)
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That one.  Each process should have a 'message-handler' object that
> will receive messages and notify the rest of the process.
>
> Kind of like:   if (MsgHandler.ismsg ());  // Check to see if msg. is waiting.
>                 switch (MsgHandler.message)
>                   // etc...

Ooooh, nooo!!! I'm in favour for another way of doing it.
 SupplyMessageSystemCrashFunction (MySystemCrashFunction);
When a system crash comes, the system crash "spy" calls the
"MySystemCrashFunction". Then the system would take care of all message
handling, and the programmer could program, and not think of eartly things
as messages.

Arff



sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From ANDREASA@dhhalden.no Tue May 18 16:29:28 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15372; Tue, 18 May 93 16:29:25 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Tue, 18 May 93 16:29:25 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15517; Tue, 18 May 93 07:24:03 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <09119-0@fenris.dhhalden.no>; Tue, 18 May 1993 13:04:47 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Tue, 18 May 93 13:04:40 GMT+1
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 18 May 93 13:04:15 +0100
Subject: MUSIC [arf9]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <1792AA07694@sofus.dhhalden.no>
Status: OR

Hello Moosers

I'm writing a small draft for the GUI part of MUSIC. This contains
the minimum commandset we need, and some things to think about
when implementating it. I don't know if it is a good thing to publish it
for all of you, since only a few of you are interested in this part. But
on the other hand, you are entitled to know.

--------------------------------------------------------
The standard primitives for MUSIC

We must find some sort of greatest common divisor, and I think we'll find
it in the VGA/MCGA system. I have some overall goals that I'll present here,
which I think we all can agree on.
- Vga compability
- Exchangeable gadgets/widgets
- 24 or 8 bit colors
- 3 standard viewports - Pixelated, Vectorbased, PostScriptbased.

About the colors, this is only theoretical, it will work equally good on
4 or 15 or 16bpp. I think it is important to provide several types of
viewports, a wysiwyg program might want to use a PS window/viewport, while
some would rather prefer to use vectors. Any other suggestions?


Now over to the primitives.
---------------------------
Different HW forces us to build an exchangeable layer with code for different
cards. The VGA is only a small part here.

            +------------------+
            | VGA | SVga cards |  <--- HW
            +------------------+
            |  Primitives      |  <--- SW
            +------------------+
            | Gfx - interface  |  <--- SW
            +------------------+

What I'll deal with is the primitives, and of course there are some
minimum requirements.
During my "research", I have found out that we need the following
functions.
A. 1. Change Active/Current Bank
   2. Wait for electron beam vertical retrace
   3. Mode setting
   4. Palette Set

B. 1. Put a pixel
   2. Get a pixel
   3. Move a pixel
   4. Clear screen

In addition we need a function to determine the resolution for the screen.
For a fast GUI we need block functions. I think we should come to an
agreement on what we mean with the word block. It can mean a square, or a
polygon. Maybe we should implement to kind of block functions, square and
polygon. There is a speed advantage using squares, and speed loss making
polygons out of squares:-).
We also need iterative functions.
C. 1. Draw a line
   2. Draw an arc

D. 1. Put a block
   2. Get a block
   3. Move a block
   4. Fill a block

Many cards also have support for special features as short vectors and HW-
sprite(s). I think we should implement these too in the minimum code, and
if a card doesn't support it, it could be supported using other primitives.
I use the XGA specification here as the base for the extras I think should
be standard.
E. 1. HW-cursor/sprite
   2. Short vectors

Each implementation will probably have other functions, but these should
be mandatory. A1-3 are card dependant, while A4 could be the same for
(almost?) all cards, since all of them has a DAC that works the same way. B3
could be discussed, but I think it is a good choice. (Remember how to make
sprites with a ZX81 spectrum:-).

A fast UI should also beware certain commands, such as Jnn, any math-function,
and IN's and OUT's. The time consuming MUL operation could be reduced with
95%. Of course the GUI primitives should be written in assembler (mostly), and
this part could be ready made in a large extent befor the the kernel.
I'll have done some asm. code for some of these commands already, so
interested people can get it, and finish it for their SVGA card. I currently
have oak, ati and paradise here (writing this mail on a VBE compliant box,
but I don't know enough about VBE, so that'll have to wait).
In the figure there is a part called gfx-interface, this part is the
interface for the application writers.


Have a nice day.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From danodom@matt.ksu.ksu.edu Tue May 18 15:41:35 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14323; Tue, 18 May 93 15:41:34 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Tue, 18 May 93 15:41:34 +0200
Received: from matt.ksu.ksu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA18802; Tue, 18 May 93 08:43:13 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9305181343.AA18802@matt.ksu.ksu.edu>
Subject: Re:  Beginning Work [djo11]
To: rideau@clipper (Francois-Rene Rideau)
Date: Tue, 18 May 93 8:43:12 CDT
In-Reply-To: <9305180226.AA25579@clipper.ens.fr>; from "Francois-Rene Rideau" at May 18, 93 4:26 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

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

From dobie.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Tue May 18 23:36:44 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22228; Tue, 18 May 93 23:36:43 +0200
Return-Path: <dobie.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Tue, 18 May 93 23:36:43 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17091; Tue, 18 May 93 14:31:09 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ac17885;
          18 May 93 17:29 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id ab25877;
          18 May 93 21:26 GMT
Received: from sol.cis.udel.edu by dobie.cis.udel.edu id aa01063;
          18 May 93 21:25 GMT
To: Dan Odom <danodom@matt.ksu.ksu.edu>
Cc: Moose List <moose-programmers@sfu.ca>
Subject: Re: Beginning Work [djo9] 
Date: Tue, 18 May 93 17:25:19 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305182125.aa01063@dobie.cis.udel.edu>
Status: OR

In Message <9305172217.AA29740@matt.ksu.ksu.edu> ,
   Dan Odom <danodom@matt.ksu.ksu.edu> wrote:

=>> 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.
=>
   I can certainly help out with a compiler, but we haven't yet
established the need for a new compiler (as opposed to adapting
and existing one) or a new langauge.

=>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.
=>
   There are other options, like Sather, and I may have a lead
toward an existing Ellie compiler, so we will have to wait and see.
I would leave C++ as a last option.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From danodom@matt.ksu.ksu.edu Tue May 18 23:41:45 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22324; Tue, 18 May 93 23:41:44 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Tue, 18 May 93 23:41:44 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17460; Tue, 18 May 93 14:37:03 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA15577; Tue, 18 May 93 16:37:31 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9305182137.AA15577@matt.ksu.ksu.edu>
Subject: Re: Beginning Work [dho12]
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Tue, 18 May 93 16:37:30 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <1781C826AF2@sofus.dhhalden.no>; from "Andreas Arff" at May 18, 93 12:00 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Andreas Arff Said:

> Ooooh, nooo!!! I'm in favour for another way of doing it.
>  SupplyMessageSystemCrashFunction (MySystemCrashFunction);
> When a system crash comes, the system crash "spy" calls the
> "MySystemCrashFunction". Then the system would take care of all message
> handling, and the programmer could program, and not think of eartly things
> as messages.

I thought about this, but we're screwed if the programmer isn't
careful about what he puts in the function.

As long as we think we can trust the programmer not to be too
dangerous, this would be OK.

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

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

From dobie.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed May 19 00:24:09 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23021; Wed, 19 May 93 00:24:08 +0200
Return-Path: <dobie.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 19 May 93 00:24:08 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20708; Tue, 18 May 93 15:18:11 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa19700;
          18 May 93 18:10 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa26361;
          18 May 93 22:06 GMT
Received: from sol.cis.udel.edu by dobie.cis.udel.edu id aa01253;
          18 May 93 22:02 GMT
To: David Garfield <david@davgar.arlington.va.us>
Cc: moose-programmers@sfu.ca
Subject: Re: ORG, IPC, pem 05/17/93 [djg22] 
Date: Tue, 18 May 93 18:02:00 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305182202.aa01253@dobie.cis.udel.edu>
Status: OR

In Message <2bf86bed.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>>    Ok, ok, calm down. :-) I can live with synchronous IPC as long
=>> as we have good context switch time and kernel-level multiple
=>> thread support.
=>
=>Well, the big problem with providing only synchronous IPC is that you
=>CANNOT make asynchronous I/O out of it without having a second thread.
=>The standard way in Unix to do I/O reading from two different sources
=>is to make one process reading each source.  Unix now has a kludge
=>called select() that allows a program to identify the descriptors with
=>available I/O, but this relies on the system and process being able to
=>keep up with the I/O.  On a VMS system (with asynchronous I/O), one
=>queues a number of asynchronous I/O calls on each channel, and
=>processes the data after it is transferred to your processes own space
=>and you are notified.  I feel this is a much more satisfactory
=>solution.
=>
   Well, presumably you would want to different things with data
from different sources, so threads would make sense, and if they
are lightweight enough, performance should be ok. I think the main
argument is that object-invocation is basically synchronous, so an
object-oriented operating system should be synchronous.

=>The obvious way to avoid this is to not make the parameter be the
=>object ID.  If Unix had used their equivalent, you would pass inode
=>numbers to read() and write() calls.  The obvious solution is exactly
=>the same that Unix used, you open() the Object and get a process-
=>specific identifier.  There is then no possibility of forging
=>anything, and the authorizations are all checked only once.
=>
   This is certainly one way of doing it, but it adds a lot of
state and complexity to the kernel, which is exactly where not
to put complexity in a microkernel-based system.

=>On the subject of objects on remote machines, I believe that the
=>correct way to do this is to access an object of a "remote access
=>class", and tell it a remote machine and object identification to
=>connect to.  Once it is connected, all method calls get passed to the
=>remote machine.  [This might be a seperate meta-class, just so we can
=>grab all method calls at one point, while not increasing the overhead
=>for normal objects.]  Once you terminate access to the local object,
=>the network connection is dropped, and the remote machines object is
=>no longer used.
=>
   A remote access object is a good idea, but we shouldn't use a
connection-oriented protocol to do the job of an RPC. We can also
implement TCP/IP, SNA, and Vines objects if we want.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dmarer@td2cad.intel.com Wed May 19 01:38:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23965; Wed, 19 May 93 01:38:28 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 19 May 93 01:38:28 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26335; Tue, 18 May 93 16:33:55 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Tue, 18 May 93 16:33:53 -0700
Received: by td2cad (5.57/10.0i); Tue, 18 May 93 16:37:59 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA08989; Tue, 18 May 93 16:33:30 PDT
Message-Id: <9305182333.AA08989@iws804.intel.com>
Subject: Re: ORG, IPC, pem 05/17/93 [djg22] [dpm11]
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Tue, 18 May 93 16:33:28 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Forwarded message:
> From: "Gary D. Duzan" <duzan@udel.edu>
> In Message <2bf86bed.davgar@davgar.arlington.va.us> ,
>    David Garfield <david@davgar.arlington.va.us> wrote:
> 
> =>Well, the big problem with providing only synchronous IPC is that you
> =>CANNOT make asynchronous I/O out of it without having a second thread.
> =>The standard way in Unix to do I/O reading from two different sources
> =>is to make one process reading each source.  Unix now has a kludge
> =>called select() that allows a program to identify the descriptors with
> =>available I/O, but this relies on the system and process being able to
> =>keep up with the I/O.  On a VMS system (with asynchronous I/O), one
> =>queues a number of asynchronous I/O calls on each channel, and
> =>processes the data after it is transferred to your processes own space
> =>and you are notified.  I feel this is a much more satisfactory
> =>solution.
> =>
>    Well, presumably you would want to different things with data
> from different sources, so threads would make sense, and if they
> are lightweight enough, performance should be ok. I think the main
> argument is that object-invocation is basically synchronous, so an
> object-oriented operating system should be synchronous.

I also think threads make sense.  As far as being lightweight, this too is
achievable.  Memory consumption (from a programmers perspective) is close
to nothing per thread, and task switching time could also be reduced by
having a more lightweight switch to go between threads in a process.


> =>The obvious way to avoid this is to not make the parameter be the
> =>object ID.  If Unix had used their equivalent, you would pass inode
> =>numbers to read() and write() calls.  The obvious solution is exactly
> =>the same that Unix used, you open() the Object and get a process-
> =>specific identifier.  There is then no possibility of forging
> =>anything, and the authorizations are all checked only once.
> =>
>    This is certainly one way of doing it, but it adds a lot of
> state and complexity to the kernel, which is exactly where not
> to put complexity in a microkernel-based system.

Ah, I still don't believe in the kernel is where IPC should go - support for
IPC, yes (shared memory, etc) but not the IPC itself.  Maybe.  I dunno.


> =>On the subject of objects on remote machines, I believe that the
> =>correct way to do this is to access an object of a "remote access
> =>class", and tell it a remote machine and object identification to
> =>connect to.  Once it is connected, all method calls get passed to the
> =>remote machine.  [This might be a seperate meta-class, just so we can
> =>grab all method calls at one point, while not increasing the overhead
> =>for normal objects.]  Once you terminate access to the local object,
> =>the network connection is dropped, and the remote machines object is
> =>no longer used.
> =>
>    A remote access object is a good idea, but we shouldn't use a
> connection-oriented protocol to do the job of an RPC. We can also
> implement TCP/IP, SNA, and Vines objects if we want.

In OOP terms, creating an instance of a "remote access class" establishes
the connection (by calling its constructor); when it is destroyed, it calls
its destructor to terminate the connection.

I use the term "connection" loosely - I don't mean to imply any protocol here.
Ideally, network connections should be possible independent of the protocol.
That's ideally...


Laterz.

	Dennis


From uunet.UU.NET!davgar!davgar.arlington.va.us!david Wed May 19 07:18:21 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04159; Wed, 19 May 93 07:18:20 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Wed, 19 May 93 07:18:20 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08318; Tue, 18 May 93 22:14:06 -0700
Received: from spool.uu.net (via localhost) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA27874; Wed, 19 May 93 01:14:04 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 011321.24482; Wed, 19 May 1993 01:13:21 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Wed, 19 May 1993 00:52:28 EDT
Date:      Wed, 19 May 1993 00:52:25 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bf9bd0e.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: ORG, IPC, pem 05/17/93 [djg22] [dpm11] [djg23]
Status: OR

"> " is Dennis Marer
">> " is Gary D. Duzan
">>=>" is David Garfield (me)

>>=>Well, the big problem with providing only synchronous IPC is that you
>>=>CANNOT make asynchronous I/O out of it without having a second thread.
>>=>The standard way in Unix to do I/O reading from two different sources
>>=>is to make one process reading each source.  Unix now has a kludge
>>=>called select() that allows a program to identify the descriptors with
>>=>available I/O, but this relies on the system and process being able to
>>=>keep up with the I/O.  On a VMS system (with asynchronous I/O), one
>>=>queues a number of asynchronous I/O calls on each channel, and
>>=>processes the data after it is transferred to your processes own space
>>=>and you are notified.  I feel this is a much more satisfactory
>>=>solution.
>>=>
>>    Well, presumably you would want to different things with data
>> from different sources, so threads would make sense, and if they
>> are lightweight enough, performance should be ok. I think the main
>> argument is that object-invocation is basically synchronous, so an
>> object-oriented operating system should be synchronous.

"basically synchronous", but only when you do simple stuff.  More 
complicated stuff requires more advanced techniques.  

> I also think threads make sense.  As far as being lightweight, this too is
> achievable.  Memory consumption (from a programmers perspective) is close
> to nothing per thread, and task switching time could also be reduced by
> having a more lightweight switch to go between threads in a process.

Agreed.  These threads need only grab a copy of the loaded image's 
process space, add a stack, copy parameters, and run.  

>>=>The obvious way to avoid this is to not make the parameter be the
>>=>object ID.  If Unix had used their equivalent, you would pass inode
>>=>numbers to read() and write() calls.  The obvious solution is exactly
>>=>the same that Unix used, you open() the Object and get a process-
>>=>specific identifier.  There is then no possibility of forging
>>=>anything, and the authorizations are all checked only once.
>>=>
>>    This is certainly one way of doing it, but it adds a lot of
>> state and complexity to the kernel, which is exactly where not
>> to put complexity in a microkernel-based system.

Protection is REQUIRED in an operating system.  If we don't have it, 
we get a system known as DOS.  Protection includes a necessity for the 
OS to protect objects from unauthorized processes.  Any other 
suggestions on this that are proof against forgery?  

> Ah, I still don't believe in the kernel is where IPC should go - support for
> IPC, yes (shared memory, etc) but not the IPC itself.  Maybe.  I dunno.

If IPC is not in the kernel, how do you communicate with the IPC?

>>=>On the subject of objects on remote machines, I believe that the
>>=>correct way to do this is to access an object of a "remote access
>>=>class", and tell it a remote machine and object identification to
>>=>connect to.  Once it is connected, all method calls get passed to the
>>=>remote machine.  [This might be a seperate meta-class, just so we can
>>=>grab all method calls at one point, while not increasing the overhead
>>=>for normal objects.]  Once you terminate access to the local object,
>>=>the network connection is dropped, and the remote machines object is
>>=>no longer used.
>>=>
>>    A remote access object is a good idea, but we shouldn't use a
>> connection-oriented protocol to do the job of an RPC. We can also
>> implement TCP/IP, SNA, and Vines objects if we want.
>
> In OOP terms, creating an instance of a "remote access class" establishes
> the connection (by calling its constructor); when it is destroyed, it calls
> its destructor to terminate the connection.
>
> I use the term "connection" loosely - I don't mean to imply any protocol here.
> Ideally, network connections should be possible independent of the protocol.
> That's ideally...

Well, connection may be used loosely here, but in some ways, a 
connection-oriented protocol (like TCP) is a GOOD thing.  There are 
things that will work out much easier if it is not necessary to 
establish one or more objects, connect them appropriately, use them, 
and disconnect WITH EVERY CALL.  I admit that the RPC style makes 
sense for something as simple as a disk access (NFS), but not for 
everything.  Can you imagine trying to access a remote Vines 
connection-oriented connection over anything other than a connection-
oriented protocol?  

-- David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Wed May 19 07:18:15 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04154; Wed, 19 May 93 07:18:14 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Wed, 19 May 93 07:18:14 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08321; Tue, 18 May 93 22:14:09 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA11929; Wed, 19 May 93 01:14:07 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 011321.24487; Wed, 19 May 1993 01:13:21 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Wed, 19 May 1993 01:06:20 EDT
Date:      Wed, 19 May 1993 01:06:16 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bf9c04d.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: Beginning Work [djo9][arf8] [djg24]
Status: OR

"> " is Andreas Arff
> > is Dan Odom
> > > Where we still have to get to an agreement is:
> > >
> > > o How looks a destination address?
> > >   Should it look like this: (machine address, object id, method id)
> > >   or only like this: (object id, method id)
> > >   or like this: (machine address, process id)
> >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > That one.  Each process should have a 'message-handler' object that
> > will receive messages and notify the rest of the process.
> >
> > Kind of like:   if (MsgHandler.ismsg ());  // Check to see if msg. is waiting.
> >                 switch (MsgHandler.message)
> >                   // etc...
>
> Ooooh, nooo!!! I'm in favour for another way of doing it.
>  SupplyMessageSystemCrashFunction (MySystemCrashFunction);
> When a system crash comes, the system crash "spy" calls the
> "MySystemCrashFunction". Then the system would take care of all message
> handling, and the programmer could program, and not think of eartly things
> as messages.

Agreed.

Well, two problems with this.  The first is that you actually want a
function that you tell what function to call and when to call it.
That way there is one system function instead of one per message.  The
second problem is that this should for the most part be fed to the
IPC/ROI service provider (which I think is the kernel) all at once in
a table (thus a second function), and that image loading should
automatically feed any preconfigured entry points to the IPC service
provider.  This last technique should be used for 99+% of all
messages.

Well, third problem, but only with the example.  If the system is
crashing, you should not be able to notify anyone, because if you are
stable enough to notify people, you are stable enough not to crash.
Notify of System Shutdown maybe, power failure maybe (some machines
have hardware support for power failure), but not crash.

>
> Arff

-- David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From mueller@sc.ZIB-Berlin.DE Wed May 19 13:51:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA11521; Wed, 19 May 93 13:51:28 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 19 May 93 13:51:28 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17068; Wed, 19 May 93 04:46:35 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA11684; Wed, 19 May 93 13:46:26 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA10256; Wed, 19 May 93 13:46:26 +0200
Date: Wed, 19 May 93 13:46:26 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305191146.AA10256@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Word Chat
Status: OR

Hi,

Fare said the following to the terms 'kernel' and 'nucleus':

... kernel if you accept the "nucleus" terminology, but both words have 
exactly the same meaning ...

That's for the one with the glossary. In OS history there was a trend from
monolithical to mikro-kernel based OS. Then the microkernel grew and grew
and there were people, who thought the term 'micro' used for a kernel with more
then 100.000 lines of code (no comments) isn't ok. And they create a new
kernel with 10.000 lines of code and call it 'nano'-kernel, which should
express that this is a real small kernel. And then others came, saying, that
this is still to big. And then there was the NUCLEUS within the kernel and all-
together will fit within 1000 lines of code.
And though the semantic of 'kernel' and 'nucleus' seems to be the same, there's
still a syntactical difference ...

Is there anyone working on a glossary?

Peter

From mueller@sc.ZIB-Berlin.DE Wed May 19 14:18:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12538; Wed, 19 May 93 14:18:24 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 19 May 93 14:18:24 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17450; Wed, 19 May 93 05:13:19 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA11844; Wed, 19 May 93 14:13:15 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA10314; Wed, 19 May 93 14:13:14 +0200
Date: Wed, 19 May 93 14:13:14 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305191213.AA10314@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: ORG, IPC [pem01]
Status: OR

Hi,

I want to comment to the main design decision, whether to use synchronous or
asynchronous communication primitives. As Moose will be an oo-os it should be
possible, to provide a basic communication object (note: the object is
part of the kernel). Within an application one can create an instance of that
object, say, COMMUNICATION, something like this:

main() {
  COMMUNICATION comm;
  MESSAGE msg;
  ADDRESS addr1, addr2;

  addr1 = ...             // Initialize destination address
  comm.send(addr1, msg);  // Send the message

  // do something

  addr1 = ...            // Initialize source address  
  comm.receive(addr1, msg, addr2);
  comm.reply(addr2);

  // do something
} 

(Before you start to flame me for these implementation-details, please read on.
I used it, because it's very heavy to draw in ascii nice figures. And I think
with this flow of control I can illustrate what I mean ... and yes! I used 
C++ because I then know what I'm writing. :-)

The program above demonstrates the lowest level of IPC. A "normal" user will
not see this in this way, he will use ROI, where a method of a remote object
is directly invoked. Nonetheless, ROI must be mapped to such IPC primitives
(which we call "stubs" or communication objects, as above)

Now my idea: I'm definitely convinced that synchronous IPC is the right choice.
(But: there some of you who are not as much convinced as I am. Well, well. :-)
In my opinion, using very lightweight processes (threads) will give us the
possibility to provide *asynchronous* IPC outside the kernel.

I think, both IPC versions can be used with the following interface, namely

	send, receive, reply

If we can build the IPC primitives within an object, it should be possible,
to create two (2!) kernels: one synchronous and one asynchronous. As the 
interface should be the same, there should be no problem to the application
layer and to the lower layers as well. We can then compare these two or
even offer both.

But I still want to defense my position: Asynchronous IPC will lead to an
enormous communication overhead. There's buffer management, and still the
synchronization problem, when all buffers are in use. I don't want to see
this overhead within a new OS-kernel. Note, that this overhead leads to a
performance lost. If we really want to create a fast system, we should
provide synchronous IPC within the kernel and offer asynchronous IPC as
an add-on.

David wrote:

> Well, the big problem with providing only synchronous IPC is that you
> CANNOT make asynchronous I/O out of it without having a second thread.
> The standard way in Unix to do I/O reading from two different sources
> is to make one process reading each source.  Unix now has a kludge
> called select() that allows a program to identify the descriptors with
> available I/O, but this relies on the system and process being able to
> keep up with the I/O.  On a VMS system (with asynchronous I/O), one
> queues a number of asynchronous I/O calls on each channel, and
> processes the data after it is transferred to your processes own space
> and you are notified.  I feel this is a much more satisfactory
> solution.

Actually, I think the VMS IPC is a third form of I/O, though it's
asynchronous. If I understand it right, it is possible, to direct an I/O
to write into a pre-defined data space within my own process. I suppose,
there's a call like

	receive(chan, to_memory)

where 'to_memory' points to (big enough) data space. The OS waits for data
sent on 'chan' and relay the data to the indicated data space. After a 
sender says, "End Of Send" a notification signal is transferred.

In my opinion this differs from my use of the term 'asynchronous' IPC. Here
a sender is not blocked, because data is immediately transferred into a 
system internal buffer space. On the other hand, a receiver might be blocked,
if there's no data available. (In the above case a receiver is not blocked.)
(Or am I mixing things up?)

Nevertheless, if we do agree that we can provide each form of asynchronous
IPC by an additional buffer server this VMS asynchronous method can be simply
provided: Create a buffer server, who takes such an interface, and who 
will be able to write to a process' data space. Then notification is done by
invoking a method. The easiest way would be within this method, to set a 
flag that data is ready to be used. 

Dennis is '>', David is '>>':

> Ah, I still don't believe in the kernel is where IPC should go - support
> for IPC, yes (shared memory, etc) but not the IPC itself. Maybe. I dunno.
>
>> If IPC is not in the kernel, how do you communicate with the IPC?

Nice answer. (I still want to see the chance to distribute Moose over several
machines. Then their must be mechanisms within the kernel to communicate
to the outside of a machine ... BTW: then each machine should use its own
memory, leading to distributed memory. Virtual shared memory with several 
machines isn't useful ... (s. discussion in comp.os.research)).

I have to go now, stay tuned for more PEM News,

Peter
 

From bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed May 19 20:40:00 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20816; Wed, 19 May 93 20:39:59 +0200
Return-Path: <bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 19 May 93 20:39:59 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08156; Wed, 19 May 93 11:36:54 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa24733;
          19 May 93 14:34 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa13626;
          19 May 93 18:30 GMT
Received: from sol.cis.udel.edu by bofur.cis.udel.edu id aa06628;
          19 May 93 18:28 GMT
To: David Garfield <david@davgar.arlington.va.us>
Cc: Moose Project <moose-programmers@sfu.ca>
Subject: Re: ORG, IPC, pem 05/17/93 [djg22] [dpm11] [djg23] 
Date: Wed, 19 May 93 14:27:49 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305191828.aa06628@bofur.cis.udel.edu>
Status: OR

In Message <2bf9bd0e.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>"> " is Dennis Marer
=>">> " is Gary D. Duzan
=>">>=>" is David Garfield
=>
=>>>    Well, presumably you would want to different things with data
=>>> from different sources, so threads would make sense, and if they
=>>> are lightweight enough, performance should be ok. I think the main
=>>> argument is that object-invocation is basically synchronous, so an
=>>> object-oriented operating system should be synchronous.
=>
=>"basically synchronous", but only when you do simple stuff.  More 
=>complicated stuff requires more advanced techniques.  
=>
   Well, if we use Ellie, we can always use future return objects. :-)

=>> I also think threads make sense.  As far as being lightweight, this too is
=>> achievable.  Memory consumption (from a programmers perspective) is close
=>> to nothing per thread, and task switching time could also be reduced by
=>> having a more lightweight switch to go between threads in a process.
=>
=>Agreed.  These threads need only grab a copy of the loaded image's 
=>process space, add a stack, copy parameters, and run.  
=>
   Sounds like we are going to do threads. Now the trick is to do
it portably and efficiently. We may also want to consider what sort
of protection among threads is required/possible.

=>>>    This is certainly one way of doing it, but it adds a lot of
=>>> state and complexity to the kernel, which is exactly where not
=>>> to put complexity in a microkernel-based system.
=>
=>Protection is REQUIRED in an operating system.  If we don't have it, 
=>we get a system known as DOS.  Protection includes a necessity for the 
=>OS to protect objects from unauthorized processes.  Any other 
=>suggestions on this that are proof against forgery?  
=>
   Very sparse address spaces and encryption can be used, as in the
Amoeba system. Sparse addressing (i.e. say, a 128-bit number with
object numbers scattered around in it) may be sufficient for a local
system.

=>If IPC is not in the kernel, how do you communicate with the IPC?
=>
   Quite so. Unless the hardware has some IPC support, it has to
be in the kernel. The 386 seems to be one of the exceptions in that
the gates (if I remember correctly) can be used here. Other machines
aren't so fortunate. Regardless, it needs to be in the kernel API
whether it actually goes to the kernel or not.

=>Well, connection may be used loosely here, but in some ways, a 
=>connection-oriented protocol (like TCP) is a GOOD thing.  There are 
=>things that will work out much easier if it is not necessary to 
=>establish one or more objects, connect them appropriately, use them, 
=>and disconnect WITH EVERY CALL.  I admit that the RPC style makes 
=>sense for something as simple as a disk access (NFS), but not for 
=>everything.  Can you imagine trying to access a remote Vines 
=>connection-oriented connection over anything other than a connection-
=>oriented protocol?  
=>
   Quite so. So are we going to implement StreetTalk for Moose too? :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From uunet.UU.NET!davgar!davgar.arlington.va.us!david Thu May 20 06:55:20 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04472; Thu, 20 May 93 06:55:19 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Thu, 20 May 93 06:55:19 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA16761; Wed, 19 May 93 21:53:07 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA15635; Thu, 20 May 93 00:53:03 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 005133.20808; Thu, 20 May 1993 00:51:33 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Thu, 20 May 1993 00:44:37 EDT
Date:      Thu, 20 May 1993 00:44:32 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bfb0cb6.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca (Moose Project)
Status: OR

Subject: IPC - synchronous/asynchronous etc... [djg25]

"> " is Peter Mueller
> I want to comment to the main design decision, whether to use synchronous or
> asynchronous communication primitives. As Moose will be an oo-os it should be
> possible, to provide a basic communication object (note: the object is
> part of the kernel). Within an application one can create an instance of that
> object, say, COMMUNICATION, something like this:
> 
> main() {
>   COMMUNICATION comm;
>   MESSAGE msg;
>   ADDRESS addr1, addr2;
> 
>   addr1 = ...             // Initialize destination address
>   comm.send(addr1, msg);  // Send the message
> 
>   // do something
> 
>   addr1 = ...            // Initialize source address  
>   comm.receive(addr1, msg, addr2);
>   comm.reply(addr2);
> 
>   // do something
> } 

Assuming you are talking about doing communications with a device 
object, like a serial port COMMUNICATIONS object, then it can look 
like this: 

MESSAGE msg_connect, msg_send, msg_receive; // constant values
main() {
  COMMUNICATION comm;
  ADDRESS addr;
  char output_data[1024];
  char input_data[1024];

  addr1 = ...                         // Initialize destination address
  comm.send(msg_connect, addr);       // establish the connection
  comm.send(msg_send, output_data);   // Send some data

  // do something

  comm.send(msg_receive, input_data); // Send some data

  // do something
}

> The program above demonstrates the lowest level of IPC. A "normal" user will
> not see this in this way, he will use ROI, where a method of a remote object
> is directly invoked. Nonetheless, ROI must be mapped to such IPC primitives
> (which we call "stubs" or communication objects, as above)
> 
> Now my idea: I'm definitely convinced that synchronous IPC is the right choice.
> (But: there some of you who are not as much convinced as I am. Well, well. :-)
> In my opinion, using very lightweight processes (threads) will give us the
> possibility to provide *asynchronous* IPC outside the kernel.
> 
> I think, both IPC versions can be used with the following interface, namely
> 
>         send, receive, reply

There are two basic models of communications.  

In one model one person sends and the other person receives.  In this 
model, communication is basically uni-directional.  You can do it bi-
directional, but the directions are totally independent.  This model 
is basically synchronous, and I am not sure how you make it 
asynchronous, other than having notification that you can receive 
something.  

In the other model, one person says do_X, and the other responds 
I_did_X.  In this model, communications is basically bi-directional, 
in a master-slave mode.  One person can say do_X or do_Y, and the 
other can only answer that it did it or not.  This model is easily 
either synchronous or asynchronous, from the senders point of view.  
In synchronous mode it is equivalent to a function call.  In 
asynchronous mode, the originator at some later time learns that the 
other guy is finished.  The thing that goes weird in this model, is 
that the receiver basically gets started out of the blue to do 
something, and can have multiple threads running all at once, but that 
is why we're building an OS.  

For use in Moose, the second makes more sense to me than the first, as 
it conforms nicely to a message-invokation model.  In the case of 
Moose, do_X could be "write this data out" or "read data and put it 
inn the buffer I gave you".  The send can then either tell how and 
where it is to be notified of completion, or receive back a tag that 
it can wait for the completion of.  

> If we can build the IPC primitives within an object, it should be possible,
> to create two (2!) kernels: one synchronous and one asynchronous. As the 
> interface should be the same, there should be no problem to the application
> layer and to the lower layers as well. We can then compare these two or
> even offer both.

Now you want two(!) kernels!?!?  Do you think we are masocists?  I 
mean, they can't be the same OS.  They would require two completely 
different sets of support software ...

[...]
> David wrote:
> 
[...]
> >                        On a VMS system (with asynchronous I/O), one
> > queues a number of asynchronous I/O calls on each channel, and
> > processes the data after it is transferred to your processes own space
> > and you are notified.  I feel this is a much more satisfactory
> > solution.
> 
> Actually, I think the VMS IPC is a third form of I/O, though it's
> asynchronous. If I understand it right, it is possible, to direct an I/O
> to write into a pre-defined data space within my own process. I suppose,
> there's a call like
> 
> 	receive(chan, to_memory)
> 
> where 'to_memory' points to (big enough) data space. The OS waits for data
> sent on 'chan' and relay the data to the indicated data space. After a 
> sender says, "End Of Send" a notification signal is transferred.

The VMS low level IPC is through an interface name SYS$QIO().  You 
give it an open channel (VMS's equivalent to a Unix file descriptor), 
a message number with modifiers, three different forms of return 
status values, and six arbitrary parameters.  The receiving program, 
known as a device driver, may process the message in any way it 
chooses.  It may use all six arbitrary parameters in any way it 
chooses, either as numbers, pointers to data to be read, or pointers 
to data to be written (though if it wishes to defer the activity 
pending a hardware device's activity, it can only have one pointer, 
and it must tell at compile time if the data is to be copied to/from a 
system buffer [Buffered I/O], or locked in memory for direct access by 
the device driver [Direct I/O]).  Within VMS, devices are categorized 
into classes that all respond to the same basic set of messages in the 
same way, so that you will know that if you have a class 1 (disk) 
device, you can (if you have the privilege to send the message in 
question) send messages to do physical read and physical write 
operations and expect them to work.

> In my opinion this differs from my use of the term 'asynchronous' IPC. Here
> a sender is not blocked, because data is immediately transferred into a 
> system internal buffer space. On the other hand, a receiver might be blocked,
> if there's no data available. (In the above case a receiver is not blocked.)
> (Or am I mixing things up?)
> 
> Nevertheless, if we do agree that we can provide each form of asynchronous
> IPC by an additional buffer server this VMS asynchronous method can be simply
> provided: Create a buffer server, who takes such an interface, and who 
> will be able to write to a process' data space. Then notification is done by
> invoking a method. The easiest way would be within this method, to set a 
> flag that data is ready to be used. 

Run that by me again....

=============================================================================

"> " is Gary D. Duzan
">=>" is David Garfield (me)
">=>> " is Dennis Marer
">=>>> " is Gary D. Duzan

>=>>>    Well, presumably you would want to different things with data
>=>>> from different sources, so threads would make sense, and if they
>=>>> are lightweight enough, performance should be ok. I think the main
>=>>> argument is that object-invocation is basically synchronous, so an
>=>>> object-oriented operating system should be synchronous.
>=>
>=>"basically synchronous", but only when you do simple stuff.  More 
>=>complicated stuff requires more advanced techniques.  
>=>
>   Well, if we use Ellie, we can always use future return objects. :-)

Sounds like its just a language construct for asynchrous messages. :-)

>=>> I also think threads make sense.  As far as being lightweight, this too is
>=>> achievable.  Memory consumption (from a programmers perspective) is close
>=>> to nothing per thread, and task switching time could also be reduced by
>=>> having a more lightweight switch to go between threads in a process.
>=>
>=>Agreed.  These threads need only grab a copy of the loaded image's 
>=>process space, add a stack, copy parameters, and run.  
>=>
>   Sounds like we are going to do threads. Now the trick is to do
>it portably and efficiently. We may also want to consider what sort
>of protection among threads is required/possible.

I think we won't have much choice, but it may be reasonable for a 
image to specify that only one thread may be active at any time, all 
others must wait to get in (subject to rule changes to prevent deadlock).

>=>>>    This is certainly one way of doing it, but it adds a lot of
>=>>> state and complexity to the kernel, which is exactly where not
>=>>> to put complexity in a microkernel-based system.
>=>
>=>Protection is REQUIRED in an operating system.  If we don't have it, 
>=>we get a system known as DOS.  Protection includes a necessity for the 
>=>OS to protect objects from unauthorized processes.  Any other 
>=>suggestions on this that are proof against forgery?  
>=>
>   Very sparse address spaces and encryption can be used, as in the
>Amoeba system. Sparse addressing (i.e. say, a 128-bit number with
>object numbers scattered around in it) may be sufficient for a local
>system.

Even if you do pick them at random in a sparse address, you are only 
getting good chances of preventing forgery, not proof.  Remember, if 
the OS is not protected (i.e. PROOF) against the applications, any 
application can trash the OS.  We call this an unprotected operating 
system.  DOS is unprotected.  

>=>If IPC is not in the kernel, how do you communicate with the IPC?
>=>
>   Quite so. Unless the hardware has some IPC support, it has to
>be in the kernel. The 386 seems to be one of the exceptions in that
>the gates (if I remember correctly) can be used here. Other machines
>aren't so fortunate. Regardless, it needs to be in the kernel API
>whether it actually goes to the kernel or not.

All CPUs with multiple protection levels will have a method for a user 
level program to invoke something at a higher protection level, and 
pass some sort of parameter.  The unusual part of the 386 is that the 
parameter is that any of several calls can be used.  Most hardwares 
just let you pass an n-bit constant.

>=>Well, connection may be used loosely here, but in some ways, a 
>=>connection-oriented protocol (like TCP) is a GOOD thing.  There are 
>=>things that will work out much easier if it is not necessary to 
>=>establish one or more objects, connect them appropriately, use them, 
>=>and disconnect WITH EVERY CALL.  I admit that the RPC style makes 
>=>sense for something as simple as a disk access (NFS), but not for 
>=>everything.  Can you imagine trying to access a remote Vines 
>=>connection-oriented connection over anything other than a connection-
>=>oriented protocol?  
>=>
>   Quite so. So are we going to implement StreetTalk for Moose too? :-)

If you can come up with a useful protocol and if failure to provide an 
implementation for the protocol will result in different people 
writing different implementation for it, then we need to provide an 
implementation as part of the original development.  At this time, 
TCP/IP fits the bill, as do SCSI hard disks, and MFM/ESDI/IDE hard 
disks, and VGA and SVGA displays.  Other protocols and interfaces may 
also qualify.  

=============================================================================

Sorry about the length, but it seemed to make sense to put the 
messages together since they where both based on variants off one 
original message, about the same basic topic, and I it didn't seem 
right to cut much.

David

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Thu May 20 17:01:12 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12018; Thu, 20 May 93 17:01:08 +0200
Return-Path: <nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Thu, 20 May 93 17:01:08 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28711; Thu, 20 May 93 07:56:43 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa08269;
          20 May 93 10:51 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa29460;
          20 May 93 14:47 GMT
Received: from sol.cis.udel.edu by nori.cis.udel.edu id aa17892;
          20 May 93 14:47 GMT
To: David Garfield <david@davgar.arlington.va.us>
Cc: Moose Project <moose-programmers@sfu.ca>
Subject: Re: 
Date: Thu, 20 May 93 10:46:56 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305201447.aa17892@nori.cis.udel.edu>
Status: OR

In Message <2bfb0cb6.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>> If we can build the IPC primitives within an object, it should be possible,
=>> to create two (2!) kernels: one synchronous and one asynchronous. As the 
=>> interface should be the same, there should be no problem to the application
=>> layer and to the lower layers as well. We can then compare these two or
=>> even offer both.
=>
=>Now you want two(!) kernels!?!?  Do you think we are masocists?  I 
=>mean, they can't be the same OS.  They would require two completely 
=>different sets of support software ...
=>
   Yes, this would be bad. IPC semantics need to be consistent.

=>"> " is Gary D. Duzan
=>">=>" is David Garfield (me)
=>">=>> " is Dennis Marer
=>">=>>> " is Gary D. Duzan

=>>   Well, if we use Ellie, we can always use future return objects. :-)
=>
=>Sounds like its just a language construct for asynchrous messages. :-)
=>
   The call is always synchronous, but in the future case, the return
is asynchronous. Accessing a future object state results in what
amounts to a synchronous call that returns the state.

=>I think we won't have much choice, but it may be reasonable for a 
=>image to specify that only one thread may be active at any time, all 
=>others must wait to get in (subject to rule changes to prevent deadlock).
=>
   The Ellie language has a neat idea called a dynamic interface.
An object itself may determine which methods may be accessed at a
given time, providing for mutual exclusion. We might adapt the idea
for Moose objects.
   If I seem to have a slightly odd view of objects lately, it is
probably because I have Ellie on the brain. It *is* a cool language,
though. Did anyone get around to reading the papers on it?

=>>   Very sparse address spaces and encryption can be used, as in the
=>>Amoeba system. Sparse addressing (i.e. say, a 128-bit number with
=>>object numbers scattered around in it) may be sufficient for a local
=>>system.
=>
=>Even if you do pick them at random in a sparse address, you are only 
=>getting good chances of preventing forgery, not proof.  Remember, if 
=>the OS is not protected (i.e. PROOF) against the applications, any 
=>application can trash the OS.  We call this an unprotected operating 
=>system.  DOS is unprotected.  
=>
   And I suppose you prove the correctness of all the programs you
write, too. :-) If it is going to take 2 years to try addresses at
random to get a hit, that may be good enough. There certainly needs
to be memory protection between objects, between objects and the OS,
and between objects and the hardware. I doubt we would ever get C-2
security certification, anyway, and most users don't need inordinate
levels of security.
   Also "DOS implies unprotected" is not equivalent to "all that is
unprotected is DOS". Protection is a relative thing. Is your machine
protected against my flipping the power switch? Openning the case and
installing a bus tap? Monitoring you serial port or network connection?
Sending you tons of annoying Email? :-)

=>>   Quite so. Unless the hardware has some IPC support, it has to
=>>be in the kernel. The 386 seems to be one of the exceptions in that
=>>the gates (if I remember correctly) can be used here. Other machines
=>>aren't so fortunate. Regardless, it needs to be in the kernel API
=>>whether it actually goes to the kernel or not.
=>
=>All CPUs with multiple protection levels will have a method for a user 
=>level program to invoke something at a higher protection level, and 
=>pass some sort of parameter.  The unusual part of the 386 is that the 
=>parameter is that any of several calls can be used.  Most hardwares 
=>just let you pass an n-bit constant.
=>
   Right, but I was looking at a feature of the 386 (I forget which)
that would allow direct, secure calls between segments using normal
function calls, not going through the kernel or anything else.

=>>   Quite so. So are we going to implement StreetTalk for Moose too? :-)
=>
=>If you can come up with a useful protocol and if failure to provide an 
=>implementation for the protocol will result in different people 
=>writing different implementation for it, then we need to provide an 
=>implementation as part of the original development.  At this time, 
=>TCP/IP fits the bill, as do SCSI hard disks, and MFM/ESDI/IDE hard 
=>disks, and VGA and SVGA displays.  Other protocols and interfaces may 
=>also qualify.  
=>
   I see no reason to provide TCP/IP before releasing a working
package. Certainly we must support standard hardware on supported
platforms. We would probably want to have some sort of
coordination effort among those who would build services and
applications on Moose.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri May 21 02:17:43 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA21376; Fri, 21 May 93 02:17:42 +0200
Return-Path: <ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 21 May 93 02:17:42 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from udel.edu (louie.udel.edu) by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa29248;
          20 May 93 20:16 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa06331; 21 May 93 0:11 GMT
Received: from sol.cis.udel.edu by ori.cis.udel.edu id aa19915;
          21 May 93 0:10 GMT
To: Francois-Rene Rideau <rideau@clipper>
Cc: All the happy Moosers ! <moose-programmers@sfu.ca>
Subject: Re: Bases [far34] 
Date: Thu, 20 May 93 20:09:55 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305210010.aa19915@ori.cis.udel.edu>
Status: OR

In Message <9305172238.AA23280@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=> Well, here is I think the main points we MUST agree before we can
=>begin coding what we call MOOSE (but we already can begin coding
=>IO drivers and suches).
=>
   Not necessarily, if drivers are implemented like normal objects.

=>SPECS
=>~~~~~
=>
=>agreements
=>~~~~~~~~~~
=>a) MOOSE is "OO" (see Unknown, a))

   Yeah, whatever that means.

=>b) we'll develop a generic UI (user interface), that will
=>specialize/extend into a TUI (Text UI) and a GUI (Graphical).

   Fair enough.

=>Unknown
=>~~~~~~~
=>
=>Questions:
=>@) What will we do that will be the same as or different from
=>other systems, currently existing or being developped ?

   I think it is fair to say that there will be no single feature
that won't have been implemented in some other system. The only
real innovation I think we can expect is in our particular
combination of features and overall system structure.

=>a) What does OO means for an OS ; i.e. what do we mean by "object" ?

   An object is a combination of state, code, and interface. Threads
execute the code, and there may be more that one thread executing on
one or more method. Objects are medium to large-sized from the system
level, though larger objects may manage smaller objects, which can
be addressed like the larger ones.

=>b) How light will our basic objects/threads/tasks/processes be ?

   As light as they can be without giving up inter-object
protection.

=>c) What kind of typing/checking will the kernel/base system include,
=>if any ?

   As I've said in the past, types are a mess. We might want to
attach type information with each call and have the called object
(or the kernel) check the information. We could limit passed
types to a set of standard types, building up more complex ones
from there, or maybe have a complex type server. This adds a lot
of additional overhead to building a message. Alternatively, we
could provide a system for callers to determine the type of
object method interfaces and rely on sanity checks in the
destination object. I would suggest the latter, since for the
most part data is data, and nonsense calls would generate
nonsense results, and sanity checks could handle most devistating
cases.

=>d) Must we include a standard LLL in the base system

   No. It might be a good idea on some systems, and there should
be nothing hindering its implementation, but high-level languages
should suffice for the most part. I don't believe the primary
target systems require LLL support.

=>e) Must we prepare for future distributedness (i.e. refuse solutions
=>that won't adapt to a distributed OS).

   Yes. The more flexibility the better.

=>FIRST IMPLEMENTATION
=>~~~~~~~~~~~~~~~~~~~~
=>agreements
=>~~~~~~~~~
=>a) Moose will run on 386 PC compatible machines.
=>
   The 386 version, yeah. :-) I'm thinking that I may get a
SPARC Classic or something and build my code there. The further
I can get from DOS machines, the better.

=>Unknown
=>~~~~~~~
=>
=>Questions:
=>
=>
=>a) Kernel Requirements:
=> - That's just a policy question, and there is a priori no rational
=> arguments about it, but what machines we work on.

   Whatever we can't implement in objects.

=>b) Object ID's.

   A large binary number, possibly arranged to allow addressing
smaller objects within system objects.

=>c) Objects Classes.

   I prefer the Ellie-object model of grouping objects by interface
rather than by inheritance classes. An object's class is its
interface.

=>Solutions proposed:
=>Fare:
=>a) a 386 with extended memory (even 384KB suffice for just booting
=>with a console ?).

   We should focus on making it small, but I don't think it
makes much sense trying to predict the size of the final product
before it is started.

=>b) use DT:Seg identifiers, or DT:Seg:Offset when needed. (when needed,
=>the offset may be considered as an argument to DT:Seg as a function
=>represented by the array of its values).

   Non-portable. The 386 implementation may map object ids to
segment, though.

=>c)  [ ... stuff about object disk images ... ]

   Object code is straightforward enough. I've not been completely
sold on the idea of persistant object state, but it is a good
possibility.  If inter-object references aren't tied to hardware
addresses, restoring them would be easier, assuming the kernel can
rebuild its list of objects.

=>Please state your mind.

   You really don't want to know what is in there. :-)

=>Please recall forgotten points.

   There are plenty of things I would rather forget. :-)

=>Please add your comments.

   _The Simpsons_ is a cool show. :-)

=>Please correct mistype/broken english, or mistakes.

   All English is broken. :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Mon May 24 11:56:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23828; Mon, 24 May 93 11:56:28 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 24 May 93 11:56:28 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA13195; Mon, 24 May 93 01:40:50 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA19964; Mon, 24 May 93 10:40:39 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA13661; Mon, 24 May 93 10:40:38 +0200
Date: Mon, 24 May 93 10:40:38 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305240840.AA13661@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Two Kernels: Sync/Async [pem00]
Status: OR

Dear moosers,

Wait! When I suggest to implement one communication object, providing 
synchronous and one asynchronous communication I only want to be able to 
make eg. a performance analysis. I don't think either, that we will implement
a whole OS for both. BUT: I think it is possible to provide both, without
much more effort. Of course we will restrict ourselves to one communication
scheme (and that should be synchronous ;-) (And there should be no mix of
synchronous and asynchronous applications in our development. Nonetheless,
as it was stated earlier both schemes can be simulated by the other. So it 
should be possible to run asynchronous apps with a sync.-kernel and vice-versa.)

What I want to express was, that in future versions it should be possible to
choose the appropriate kernel, either sync or async. And I still don't see
any reasons for not doing so. Providing 'two' kernels will maybe lead to a
more flexible and user-friendly kernel. 

Peter

From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon May 24 13:16:13 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24716; Mon, 24 May 93 13:16:12 +0200
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 24 May 93 13:16:12 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15030; Mon, 24 May 93 04:12:47 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa21645; 24 May 93 7:07 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa24817;
          24 May 93 11:07 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa17878;
          24 May 93 11:04 GMT
To: Peter Mueller <mueller@sc.zib-berlin.de>
Cc: moose-programmers@sfu.ca
Subject: Re: Two Kernels: Sync/Async [pem00] 
Date: Mon, 24 May 93 07:03:57 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305241104.aa17878@thorin.cis.udel.edu>
Status: OR

In Message <9305240840.AA13661@sc.zib-berlin.dbp.de> ,
   Peter Mueller <mueller@sc.zib-berlin.de> wrote:

=>What I want to express was, that in future versions it should be possible to
=>choose the appropriate kernel, either sync or async. And I still don't see
=>any reasons for not doing so. Providing 'two' kernels will maybe lead to a
=>more flexible and user-friendly kernel. 
=>
   Then you want to have both synchronous and asynchronous primitives
in the kernel API, implementing one over the other. Right?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Mon May 24 13:42:23 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25188; Mon, 24 May 93 13:42:22 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 24 May 93 13:42:22 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15297; Mon, 24 May 93 04:39:39 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA21543; Mon, 24 May 93 13:39:33 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA14364; Mon, 24 May 93 13:39:32 +0200
Date: Mon, 24 May 93 13:39:32 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305241139.AA14364@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Two Kernels: Sync/Async [pem01]
Status: OR

Hi,

it seems, that I've a big communication problem :-)
Here I go again:

What I want is this:

	+-------+----+
	| BLACK |    |
	+-------|    |
	| KERNEL     |
	+------------+

The black box should be the communication stuff. It is
an object, providing an interface to IPC primitives 
such as
	send, receive, reply

I want to change this black box to be either sync or 
async. All other kernel stuff should remain the same.
Thus we actually have only ONE KERNEL box.

Then: We have to come to an agreement, which BLACK box
we choose in our first release. (You already know what
I want, do you :-) Then ALL apps are designed to use
this specific BLACK box, hence, using these IPC
primitives.

I only want to state the following: It should be possible
to make a design suggestion, where the IPC is a black box
which is exchangeable. (And if you all want async IPC
then I will follow you until I have my own system, where
I then will change to the sync. kernel.)

That's all. Please don't get confused for the term
'two kernels'. I still think we should implement a
'homogeneous' system.

I do agree that it is possible to simulate each IPC
form with the other, though I believe simulating sync
IPC out of async IPC is like using a steam hammer to 
crack a nut ... but that's IMHO ... ;-)

cheers,

Peter

From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon May 24 16:36:32 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29422; Mon, 24 May 93 16:36:31 +0200
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 24 May 93 16:36:31 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17814; Mon, 24 May 93 07:33:37 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ab28002;
          24 May 93 10:24 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa26201;
          24 May 93 14:21 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa18534;
          24 May 93 14:21 GMT
To: Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au>
Cc: Moose Project <moose-programmers@sfu.ca>
Subject: Re: Two Kernels: Sync/Async [pem01] 
Date: Mon, 24 May 93 10:21:22 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305241421.aa18534@bifur.cis.udel.edu>
Status: OR

In Message <9305241325.17829@mulga.cs.mu.OZ.AU> ,
   Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:

=> Peter Wrote:
=>
=>> I do agree that it is possible to simulate each IPC
=>> form with the other, though I believe simulating sync
=>> IPC out of async IPC is like using a steam hammer to 
=>> crack a nut ... but that's IMHO ... ;-)
=>
=>Yes, however trying to simulate async using sync is much much worse
=>(you resort to having either 
=>	(a) ugly hacks in the kernel

   Nothing we do should be ugly. Convoluted, perhaps, but not ugly.
:-)

=>	(b) Extra processes floating around who's sole task is to merge 
=>		event streams

   I had foreseen the need for such a beast, and I think that a
system with a light enough thread can handle it without too much
pain. I could, of course, be wrong, but I think it would be worth
the attempt to gain a more object-oriented structure.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Mon May 24 15:28:33 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27633; Mon, 24 May 93 15:28:32 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 24 May 93 15:28:32 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA16630; Mon, 24 May 93 06:25:30 -0700
Received: by mulga.cs.mu.OZ.AU (5.83--+1.3.1+0.50); id AA17829
	Mon, 24 May 1993 23:25:24 +1000 (from winikoff)
Message-Id: <9305241325.17829@mulga.cs.mu.OZ.AU>
Subject: Re: Two Kernels: Sync/Async [pem01]
To: moose-programmers@sfu.ca (Moose Project)
Date: Mon, 24 May 93 23:25:23 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9305241139.AA14364@sc.zib-berlin.dbp.de>; from "Peter Mueller" at May 24, 93 1:39 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> I do agree that it is possible to simulate each IPC
> form with the other, though I believe simulating sync
> IPC out of async IPC is like using a steam hammer to 
> crack a nut ... but that's IMHO ... ;-)

Yes, however trying to simulate async using sync is much much worse
(you resort to having either 
	(a) ugly hacks in the kernel
	(b) Extra processes floating around who's sole task is to merge 
		event streams
)
Michael

> 
> cheers,
> 
> Peter
> 


From uunet.UU.NET!davgar!davgar.arlington.va.us!david Tue May 25 07:10:53 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17083; Tue, 25 May 93 07:10:52 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Tue, 25 May 93 07:10:52 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15566; Mon, 24 May 93 22:07:13 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA19964; Tue, 25 May 93 01:07:09 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 010543.25805; Tue, 25 May 1993 01:05:43 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Tue, 25 May 1993 00:58:09 EDT
Date:      Tue, 25 May 1993 00:58:04 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c01a762.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: Two Kernels: Sync/Async [pem01] [djg26]
Status: OR

Peter Mueller wrote:
> Hi,
>
> it seems, that I've a big communication problem :-)
> Here I go again:
>
> What I want is this:
>
>         +-------+----+
>         | BLACK |    |
>         +-------|    |
>         | KERNEL     |
>         +------------+

Actually, it is probably more like:

        +---------------+
        | BLACK BOX     |
        +--------+      |
        | KERNEL |      |
        +--------+------+

> The black box should be the communication stuff. It is
> an object, providing an interface to IPC primitives
> such as
>         send, receive, reply

Again, I think you have the wrong basic model.  There is (or should
be) no such call as "receive".  ("reply" is questionable, but that
discussion comes later.)

> I want to change this black box to be either sync or
> async. All other kernel stuff should remain the same.
> Thus we actually have only ONE KERNEL box.

One kernel box, but the basic devices (outside the kernel) are easily
10 times the size, probably more like 100 times.  And for them, THE
COMMUNICATIONS MODEL IS CRITICAL!

> Then: We have to come to an agreement, which BLACK box
> we choose in our first release. (You already know what
> I want, do you :-) Then ALL apps are designed to use
> this specific BLACK box, hence, using these IPC
> primitives.
>
> I only want to state the following: It should be possible
> to make a design suggestion, where the IPC is a black box
> which is exchangeable. (And if you all want async IPC
> then I will follow you until I have my own system, where
> I then will change to the sync. kernel.)
>
> That's all. Please don't get confused for the term
> 'two kernels'. I still think we should implement a
> 'homogeneous' system.

Synchronous can be done trivially on top of asynchronous.
Asynchronous on top of synchronous requires a helper thread and lots
of pain.

With a properly implemented system on top of an asynchronous setup,
you will NOT be able to replace it with a synchronous setup.  :-)
With a properly implemented system on top of a synchronous setup, you
WILL be able to replace it with an asynchronous setup.  :-)  Sorry.

> I do agree that it is possible to simulate each IPC
> form with the other, though I believe simulating sync
> IPC out of async IPC is like using a steam hammer to
> crack a nut ... but that's IMHO ... ;-)

Sync from async is using a steam hammer to crack a nut.
Async from sync is using a nutcracker to crack pavement.

The real problem is YOU NEED BOTH!

> cheers,
>
> Peter
>

All right, try this:  under Unix, write a program that reads data from
two data sources and does different things with the data, such that:
        1) only one process is used
        2) select() is not used
        3) either data source can produce data that will be processed
           imeadiately (sp?)
        4) the program does not eat CPU time

If you can do this in Unix, I want to see it.  I don't think Unix,
which only has synchronous IO, can do it.

With VMS and its asyncronous IO, this is trivial.


David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From mueller@sc.ZIB-Berlin.DE Tue May 25 11:50:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20312; Tue, 25 May 93 11:50:53 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Tue, 25 May 93 11:50:53 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21765; Tue, 25 May 93 02:47:04 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA24757; Tue, 25 May 93 11:46:55 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA15795; Tue, 25 May 93 11:33:06 +0200
Date: Tue, 25 May 93 11:33:05 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305250933.AA15795@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Two Kernels: Sync/Async [pem01] [djg26]
Status: OR


> From davgar!davgar.arlington.va.us!david@uunet.UU.NET Tue May 25 07:11:02 1993
> Date:      Tue, 25 May 1993 00:58:04 EDT
> From: "David Garfield" <david@davgar.arlington.va.us>
> Organization: Third Star on the Left
> To: moose-programmers@sfu.ca
> Subject:   Re: Two Kernels: Sync/Async [pem01] [djg26]
> Content-Length: 3159
> 
> Peter Mueller wrote:
> > Hi,
> >
> > it seems, that I've a big communication problem :-)
> > Here I go again:
> >
> > What I want is this:
> >
> >         +-------+----+
> >         | BLACK |    |
> >         +-------|    |
> >         | KERNEL     |
> >         +------------+
> 
> Actually, it is probably more like:
> 
>         +---------------+
>         | BLACK BOX     |
>         +--------+      |
>         | KERNEL |      |
>         +--------+------+
> 

Well, I don't want to start kind of hick-hack how it will look like. I think
that will bring us no step further. Let's do agree that there's a black box.


> > The black box should be the communication stuff. It is
> > an object, providing an interface to IPC primitives
> > such as
> >         send, receive, reply
> 
> Again, I think you have the wrong basic model.  There is (or should
> be) no such call as "receive".  ("reply" is questionable, but that
> discussion comes later.)
> 
> > I want to change this black box to be either sync or
> > async. All other kernel stuff should remain the same.
> > Thus we actually have only ONE KERNEL box.
> 
> One kernel box, but the basic devices (outside the kernel) are easily
> 10 times the size, probably more like 100 times.  And for them, THE
> COMMUNICATIONS MODEL IS CRITICAL!

Stop it! Didn't I have said that I don't want to implement the whole
os in two versions? I only want the possibility to make a sync. kernel. That
require the possibility to change the black box. Ok? AND IF YOU STILL THINK
THAT I WANT TWO WHOLE OS I CAN'T HELP YOU. BTW: Most modern OS uses sync.
IPC within their kernels. eg. PEACE, QNX, ... 

> 
> > Then: We have to come to an agreement, which BLACK box
> > we choose in our first release. (You already know what
> > I want, do you :-) Then ALL apps are designed to use
> > this specific BLACK box, hence, using these IPC
> > primitives.
> >
> > I only want to state the following: It should be possible
> > to make a design suggestion, where the IPC is a black box
> > which is exchangeable. (And if you all want async IPC
> > then I will follow you until I have my own system, where
> > I then will change to the sync. kernel.)
> >
> > That's all. Please don't get confused for the term
> > 'two kernels'. I still think we should implement a
> > 'homogeneous' system.
> 
> Synchronous can be done trivially on top of asynchronous.
> Asynchronous on top of synchronous requires a helper thread and lots
> of pain.

No. Sorry, I do not agree. Async. IPC will force a performance lost for 
some apps, which can be easily handled with sync. IPC. On the other hand
if async. is built with lightweight (AND THAT AREN'T PROCESSES, WHICH
ENABLING CAUSES PLENTY OF TIME) threads, there should be a minimal performance
lost for async apps. If you do it the other way round, the performance lost
for sync. apps. will be much much more greater.

> 
> With a properly implemented system on top of an asynchronous setup,
> you will NOT be able to replace it with a synchronous setup.  :-)
> With a properly implemented system on top of a synchronous setup, you
> WILL be able to replace it with an asynchronous setup.  :-)  Sorry.
> 
> > I do agree that it is possible to simulate each IPC
> > form with the other, though I believe simulating sync
> > IPC out of async IPC is like using a steam hammer to
> > crack a nut ... but that's IMHO ... ;-)
> 
> Sync from async is using a steam hammer to crack a nut.
> Async from sync is using a nutcracker to crack pavement.

Again: NO! Why are modern os using sync. IPC, then?

> 
> The real problem is YOU NEED BOTH!
> 
> > cheers,
> >
> > Peter
> >
> 

FIRST OF ALL: UNIX IS *NO* MODERN OS. IT IS HEAVY, UNFLEXIBLE, LIKE A
DINOSAUR, AND SHOULD BE REPLACED BY ANOTHER SYSTEM. UNIX is a monolithic
OS, where all things, which are to be said to be included in a 'modern'
os are fixed within the kernel. This leads to a tremendeous overhead in all
os related stuff. So, I do agree, that your example is a counterexample IF
YOU COMPARE UNIX AS A MODERN SYSTEM. Sorry, I don't think that this 
comparism is useful.

> All right, try this:  under Unix, write a program that reads data from
> two data sources and does different things with the data, such that:
>         1) only one process is used
>         2) select() is not used
>         3) either data source can produce data that will be processed
>            imeadiately (sp?)
>         4) the program does not eat CPU time
> 
> If you can do this in Unix, I want to see it.  I don't think Unix,
> which only has synchronous IO, can do it.
> 
> With VMS and its asyncronous IO, this is trivial.

VMS is ALSO NOT A MODERN SYSTEM. Stop talking about the old world, think over
the new one and look into future ... In current OS research there is the trend
to ask, what must not be in the kernel and not what do I want to have in it.
Eg. The QNX micro-kernel provides the following four (4!) functions:

	1) Synchronous IPC (send, receive, reply)
	2) Process scheduling (ie. context switch)
	3) Network connection
	4) Interrupt/Signal-handling (a signal is simply converted into
           a message which is then transferred to an appropriate server, which
           resides outside the kernel.)

The latter two points are placed within the smallest units. Sometimes if you
ask, what should the kernel of a modern OS provide, you will hear:

	1) Synchronous IPC (because it must be fast)
	2) Process execution (ie. scheduling)

 
> 
> David
> -- 
> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com
>

cheers, 

Peter 

From mueller@sc.ZIB-Berlin.DE Tue May 25 11:50:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20307; Tue, 25 May 93 11:50:26 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Tue, 25 May 93 11:50:26 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21764; Tue, 25 May 93 02:47:02 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA24754; Tue, 25 May 93 11:46:54 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA15811; Tue, 25 May 93 11:42:13 +0200
Date: Tue, 25 May 93 11:42:13 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305250942.AA15811@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: paper recommendation
Status: OR

hi,

in my previous mail, I've mentioned a system named QNX, which provide a
micro-kernel with a size of at most 8K. If you want to read an 
architectural overview, here is a paper:

%A Dan Hildebrand
%T An Architectural Overview of QNX
%J Proceedings of the Usenix Workshop on Micro-Kernels & Other Kernel
   Architectures, Seattle
%M Apr.
%Y 1992

this paper is anon.-ftp-able as:

ftp.cse.ucsc.edu:/pub/qnx/qnx-paper.ps.Z

bye, (and: Always Look on the Bright Side of Life ...)

Peter

From rideau@clipper Thu May 27 03:23:38 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15458; Thu, 27 May 93 03:23:35 +0200
Return-Path: <rideau@clipper>
Received-Date: Thu, 27 May 93 03:23:35 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from nef.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA27838; Wed, 26 May 93 18:20:39 -0700
Received: from dmi.ens.fr by nef.ens.fr (5.65c8/ULM-1.0)
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fregate.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15430; Thu, 27 May 93 03:20:06 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9305270120.AA15430@clipper.ens.fr>
Subject: various subjects [far35]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Thu, 27 May 93 3:20:05 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR


- Blocking/Async IPC:
Why battle about it ? After all Intel x86 and most CPU instruction sets
provide sync IPC and nothing else (usually CALL, INT, TRAP, JSR or such
instruction). That's why the kernel's job usually is building async IPC
from sync instruction set. Sync communication can be done without the
kernel, using standard servers to connect (=process managin device,
memory managing device for sharing memory)
 Now, the system should porvide both synchronous an d asynchronous IPC
as standard, and building one from the other also should be included in
a standard system (meta-)library, so that synchronousness of IPC be
independent from the kernel.

- I've read the QNX papers: well, MicroKernel seems ok, but the question
is where to put object management in such a system. Moreover, we decided
to have dictionaries (name server) local to objects, etc.

Answer is not to put it in the innermost kernel (the "nucleus" as it was
called)
- MicroKernel: message passing between processes.
- Link: library to link any object with any other. Link understands
meta-typing through add-on libraries, and manages translation of
physical types inside indentical meta-types. This translation is done
according to relative trust between objects: an object can trust
another, thus doing less checking and allowing quicker transfer; it can
even allow direct addressing of its address space to another if it
really trust it, etc. Thus the Link module can handle functions as
parameters (what we want, don't we, Andreas ?), and when the function
is executed, it has more or less acess rights over the caller's address
space, according to the caller's confidence.
 The types of links are:
. existence link: forces the system to have the linked object handy
(the presence of a file in a directory is thus considered as an
existence link from the directory to the file).
. connection: the objects now send data each to the other through the
kernel.
For example, when you want to use some library, first build an existence
link to it, then connect to it each time you use it. This use can involve
a sub-connection, etc (but it is a finite process).
In our system, an existence link IS a connection to the object's class.
Or perhaps a connection is an existence link to an object's instance.

Link is an important part of the system, if not the most important part
of it. It is NOT in the nucleus, but it IS in the standard base system.
Link itself should be modular and include a Link kernel, etc.

- Gary, where can we find papers on Ellie ? on Sather ?

- Soon, my next posts about HLL, LLL and MOOSE Bases. Perhaps Dennis
should maintain a list of our naming conventions (=Kernel, Nucleus,
dictionaries, and so on).

- About HLL, my motto is genericity. The HLL we choose must include
maximal support of genericity. This includes grouping objects by
metaclasses i.e. interface, and not inheritance, and accepting types as
parameters and any other object. Types can also be understood as
restrictions upon objects. To illustrate that, I wrote some
generic module in Pascal (more readable than C, as powerful when you
don't use defines and type casting). Well, Pascal is truly horrible
for that, and well shows the limits of C-like languages.
Unfortunately, these modules were in french, so that I must translate
before I publish it (it was a Power 4 game, using a generic module for
games between two players, and another generic module for minimax
algorithm). The modules also showed that some optimizations that had
to be done manually would have to be included in the compiler (i.e.,
eliminating local variables in a recursive function by using global
ones and saving minor changes of the global variable in the stack), and
that memory management would be done if the language did accept multiple
memory zones (in that case, another stack for some kind of data), that
the optimizer could possibly join into the program's main stack (in a
mono-process version), etc.

- So what about that talk or irc around the net ? Mailing is too slow
for this project.

--
      ,						,           _      ~  ^
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
					'		    / .     

From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri May 28 13:44:06 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00481; Fri, 28 May 93 13:44:05 +0200
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 28 May 93 13:44:05 +0200
Received: from nef (nef.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26426; Fri, 28 May 93 04:40:18 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa08619; 28 May 93 7:33 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa06089;
          28 May 93 11:33 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa19349;
          28 May 93 11:31 GMT
To: Francois-Rene Rideau <rideau@clipper>
Cc: All the happy Moosers ! <moose-programmers@sfu.ca>
Subject: Re: various subjects [far35] 
Date: Fri, 28 May 93 07:31:15 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305281131.aa19349@thorin.cis.udel.edu>
Status: OR

In Message <9305270120.AA15430@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=>
=>- Blocking/Async IPC:
=> Now, the system should porvide both synchronous an d asynchronous IPC
=>as standard, and building one from the other also should be included in
=>a standard system (meta-)library, so that synchronousness of IPC be
=>independent from the kernel.
=>
   Yes, I think this is a good idea, provided that we build it with
the idea that users will generally use synchronous with threads.

=> The types of links are:
=>. existence link: forces the system to have the linked object handy
=>(the presence of a file in a directory is thus considered as an
=>existence link from the directory to the file).

   This brings to mind the idea of garbage collection. I don't
know if we can can do it properly since we can't tell when an object
discards a reference. We could have a "Free Reference" call, but an
antisocial program could easily skip it. Ideas?

=>- Gary, where can we find papers on Ellie ? on Sather ?
=>
   You can FTP papers on Ellie from
ftp.diku.dk:pub/diku/dists/ellie/papers. I believe you can get Sather
papers from ftp.icsi.berkeley.edu. They may be part of the compiler
distribution.

=>- About HLL, my motto is genericity. The HLL we choose must include
=>maximal support of genericity. This includes grouping objects by
=>metaclasses i.e. interface, and not inheritance, and accepting types as
=>parameters and any other object. Types can also be understood as
=>restrictions upon objects. To illustrate that, I wrote some
=>generic module in Pascal (more readable than C, as powerful when you
=>don't use defines and type casting). Well, Pascal is truly horrible
=>for that, and well shows the limits of C-like languages.

   To be fair, that should be Algol-like langauges. In Ellie, any
object can be a metaclass. Extending such a thing to the system
level would be the real trick.

=>- So what about that talk or irc around the net ? Mailing is too slow
=>for this project.

   I rather like it slow, since it gives me time to think things
through a bit, but I would certainly join in an IRC session if we
were to put one together.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Thu Jun  3 13:20:04 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15909; Thu, 3 Jun 93 13:20:03 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Thu, 3 Jun 93 13:20:03 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20241; Thu, 3 Jun 93 04:13:43 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA24256; Thu, 3 Jun 93 13:13:33 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA26113; Thu, 3 Jun 93 13:13:33 +0200
Date: Thu, 3 Jun 93 13:13:33 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9306031113.AA26113@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Pthhbbbt. [06/03, pem]
Status: OR

[Subject should be more like 'phew!']

I know, I know, I know. Actually I'm extremely too late. But I think I should
write something, too. Now.

I'm currently trying to get some order in my received Moose mails. A can't help
me, but I've read some of the 'Pthhbbbt' mails. I read some sort of:

... Moose should be useful ...
... Moose should be easy to program ...
... Moose should grab much acceptance ...

Well, well, well. Nice goals, though. But: How is it in reality? If you want 
Moose to be used in a wide spreaded user area you will have to consider the
following thing:

o  Users don't want to see changes. They don't want to learn a new system from
   scratch. They don't want to use, for example a different text processing
   system even if it is much better than their used old typewriter.
      If we want to make Moose attractive to the normal user, we have to offer
   well known interfaces. Sorry, I know the next sentence will make you flame
   me but it must be said: We have to provide a ms-dos-interface, we have to
   provide a unix-interface. The user must have the feel to work with ms-dos
   or unix, respectively. (OF COURSE: Moose can provide much better things.
   But these things must first establish themselves. And that will cost a 
   lot of time. BTW: There are many examples, where new technology was not
   accepted, although it provides fantastic advantages: It was not compatible
   to old, but used, systems.)

Ok. Now for the goodies. I think it is possible to provide Moose with such
attractiveness. And it is possible to make it available in such a way, that
new facilities can be used. The user will see those things, declares them as
useful, and will told them to his/her friends. And then distribution of Moose
will function automatically ... ;-) (That's the future view.)

Cheers,

Peter 

From mueller@sc.ZIB-Berlin.DE Thu Jun  3 14:08:01 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16475; Thu, 3 Jun 93 14:08:00 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Thu, 3 Jun 93 14:08:00 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20899; Thu, 3 Jun 93 05:02:16 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA24424; Thu, 3 Jun 93 14:02:10 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA26232; Thu, 3 Jun 93 14:02:09 +0200
Date: Thu, 3 Jun 93 14:02:09 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9306031202.AA26232@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: PostScript available?
Status: OR

Hi,

I would like to know, whether all of you are able to print PostScript files.
I think, writing specifications, providing graphical pictures are much more
useful.

(I don't think it must be each specification release, or update. Only one in,
say 4 weeks (?). And I don't know either, how to contribute those files.
I just want to hear your comments on this.)

Cheers,

Peter

From mueller@sc.ZIB-Berlin.DE Thu Jun  3 14:51:48 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17021; Thu, 3 Jun 93 14:51:47 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Thu, 3 Jun 93 14:51:47 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21700; Thu, 3 Jun 93 05:41:41 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/03.06.93)
	id AA24611; Thu, 3 Jun 93 14:40:48 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA26347; Thu, 3 Jun 93 14:40:47 +0200
Date: Thu, 3 Jun 93 14:40:46 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9306031240.AA26347@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: ROI, ORG, [pem 06/03]
Status: OR

Hi,

I want to present two points.

1. Who is absolutely interested in designing ROI for Moose? (I mean, who is
   not able to live without it :-) This is the first attempt to create a smaller
   group. Maybe we can setup a smaller alias list. And others are not bombed
   with mails.

2. I've thinked about a problem, which - in my opinion - covers the area of
   the compiler designers (see below)

Ad 1.

I want to form a smaller group of interested people, to force a useful
specification on ROI (where a 1 is the major number ...). I plan to inform the
whole Moose community periodically each quarter a year. (If this is QUIRKS:
I mean after 3 weeks.) In my opinion we should create smaller groups, where
people talk especially and exactly about one (1) topic, and where mails
referencing to multiple sujects can be avoided. What do you think?

Ad 2.

Last night the following problem (and it's possible solution) came into my
mind. An object is, at least able to have two 'address spaces', namely private
and public. Variables, or 'objects' within the private space are only visible
to the object, whereas objects in the public space are also seen to the outer
world.

Now consider the following object:

class example {
   int i;               // i is private

public:
   int j;               // j is public

   void do_something() {
      i = 1;            // Change object's private state
      j = i + 1;        // Change object's public state
   }
};

Now consider, that 'do_something()' is a service, made available via the
DIRECTORY SERVICE. Then (I take the term now:) client objects can remotely
invoke do_something().

What happens?

For the client object, the example must change its private state! But this
must only be seen to the client object! Not to others. On the other hand,
the change to the public state must be seen to all other clients.

We can say, the change of the private state is a local change to the state
seen by a specific client object, whereas a change of the public state is
a global change seen to all possible client objects.

Where are the problems?

The global change leads to a synchronization problem. In each situation we
have to take care to establish a consistent state. (I think, that's where
the compilers must give as much as help as they can!)

The local change makes it necessary to provide a copy of at least the private
members of an object for each client object! (And therefore we need tools, 
which similiar to those nice stub-making tools for RPC.)

Solutions?

Well, to the local change there is an easy solution. Each client, wanting to 
use other objects' methods remotely, will create an appropriate instance of
a server class. This class will inform the remote object, that there is a new
client. This will lead at the remote object to 'fork' (if you will forgive my
UNIXness ;-) a private copy, especially for this new client. The private copy 
consists of 

   1) The private state as it was created on server startup time. (Each time
      a new client occurs, it will see the same private state.)
   2) The public state at this time. (A newly client can see different states
      than previous ones.)

At the client side, this will be done within the constructor of the server class
instance. The destructor call will inform the remote object to discard the
created client's private view.

I suggest the following terms for the - perhaps - following discussion:

connector - This is the object used by a client object to establish a new
            connection to a remote object. The constructor will inform the 
            remote object, that there is a new client, whereas the destructor
            will say, that the client is finished.

shadow    - This is the (remote) object which is actually seen by a client
            object after connection. Within this object only the private 
            (and/or protected (?)) members of the remote object are hold.
            Public members are still shared through the 'real' remote object.
            The shadow is created after a connection request by a connector.

(The connection between client and shadow must provide a merge between the
valid private and public state. Thus, the shadow 'merges' the local view and
the global view.)

Other Problems?

What's about availability and fault tolerance? Reliability? Garbage collection?

Hope, to hear some comments,

Peter

From danodom@matt.ksu.ksu.edu Thu Jun  3 22:39:46 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25109; Thu, 3 Jun 93 22:39:45 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Thu, 3 Jun 93 22:39:45 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06241; Thu, 3 Jun 93 13:33:42 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA04511; Thu, 3 Jun 93 13:53:01 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306031853.AA04511@matt.ksu.ksu.edu>
Subject: Re: PostScript available?
To: mueller@sc.zib-berlin.de (Peter Mueller)
Date: Thu, 3 Jun 93 13:53:00 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <9306031202.AA26232@sc.zib-berlin.dbp.de>; from "Peter Mueller" at Jun 3, 93 2:02 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Peter Mueller Said:

> I would like to know, whether all of you are able to print PostScript files.
> I think, writing specifications, providing graphical pictures are much more
> useful.

Nope.  If you'll buy me the printer, I'll be happy to say yes... :-)
All I have is an HP Deskjet, but I can get access to a Laserjet.  If
you're using TeX, just send us the TeX source file.

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

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

From danodom@matt.ksu.ksu.edu Thu Jun  3 22:52:27 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25271; Thu, 3 Jun 93 22:52:26 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Thu, 3 Jun 93 22:52:26 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07239; Thu, 3 Jun 93 13:45:39 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA10609; Thu, 3 Jun 93 15:48:05 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306032048.AA10609@matt.ksu.ksu.edu>
Subject: LARRIE
To: moose-programmers@sfu.ca (Moose List)
Date: Thu, 3 Jun 93 15:48:04 CDT
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Would somebody PLEASE get LARRIE off this list?  The 'unknown user'
bounces are annoying.

I'm also kinda curious about how a nonexistant name got added to the
list in the first place...

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

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

From nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Thu Jun  3 23:43:10 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25788; Thu, 3 Jun 93 23:43:08 +0200
Return-Path: <nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Thu, 3 Jun 93 23:43:08 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11260; Thu, 3 Jun 93 14:36:23 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa14730; 3 Jun 93 17:28 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa29831; 3 Jun 93 21:27 GMT
Received: from sol.cis.udel.edu by nori.cis.udel.edu id aa15193;
          3 Jun 93 21:25 GMT
To: Peter Mueller <mueller@sc.zib-berlin.de>
Cc: moose-programmers@sfu.ca
Subject: Re: Pthhbbbt. [06/03, pem] 
Date: Thu, 03 Jun 93 17:25:27 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306032125.aa15193@nori.cis.udel.edu>
Status: OR

In Message <9306031113.AA26113@sc.zib-berlin.dbp.de> ,
   Peter Mueller <mueller@sc.zib-berlin.de> wrote:

=>[Subject should be more like 'phew!']
=>
=>I know, I know, I know. Actually I'm extremely too late. But I think I should
=>write something, too. Now.
=>
=>I'm currently trying to get some order in my received Moose mails. A can't he
lp
=>me, but I've read some of the 'Pthhbbbt' mails. I read some sort of:
=>
=>... Moose should be useful ...
=>... Moose should be easy to program ...
=>... Moose should grab much acceptance ...
=>
=>Well, well, well. Nice goals, though. But: How is it in reality? If you want 
=>Moose to be used in a wide spreaded user area you will have to consider the
=>following thing:
=>
   [ ... Stuff about DOS and Unix interfaces ... ]

   Are you talking about shells, APIs, or binaries? None of these
should be in the base package, IMHO. Well, maybe a shell, but not
the others.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Thu Jun  3 23:44:03 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25797; Thu, 3 Jun 93 23:44:02 +0200
Return-Path: <nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Thu, 3 Jun 93 23:44:02 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11334; Thu, 3 Jun 93 14:37:12 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa14933; 3 Jun 93 17:33 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa29839; 3 Jun 93 21:32 GMT
Received: from sol.cis.udel.edu by nori.cis.udel.edu id aa15218;
          3 Jun 93 21:28 GMT
To: moose-programmers@sfu.ca
Subject: Re: PostScript available? 
Date: Thu, 03 Jun 93 17:28:36 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306032128.aa15218@nori.cis.udel.edu>
Status: OR

In Message <9306031202.AA26232@sc.zib-berlin.dbp.de> ,
   Peter Mueller <mueller@sc.zib-berlin.de> wrote:

=>Hi,
=>
=>I would like to know, whether all of you are able to print PostScript files.
=>I think, writing specifications, providing graphical pictures are much more
=>useful.
=>
   I can print PostScript at work with a bit of hackery.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 08:17:25 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07796; Fri, 4 Jun 93 08:17:24 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 08:17:24 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07543; Thu, 3 Jun 93 23:06:58 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA02017; Fri, 4 Jun 93 02:07:08 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020518.4592; Fri, 4 Jun 1993 02:05:18 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 00:45:58 EDT
Date:      Fri, 04 Jun 1993 00:45:53 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0ed387.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: PostScript available? [djg27]
Status: OR

On Thu, 3 Jun 93 14:02:09 +0200, Peter Mueller wrote:
> Hi,
>
> I would like to know, whether all of you are able to print PostScript files.
> I think, writing specifications, providing graphical pictures are much more
> useful.

I too can handle PostScript, if needed.

We may be able to handle some other formats.  If nothing else, we all
have PC class machines (I think).  Of course, such an other format
probably means on screen displays.

--David

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 08:17:37 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07804; Fri, 4 Jun 93 08:17:36 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 08:17:36 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07574; Thu, 3 Jun 93 23:08:03 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA08273; Fri, 4 Jun 93 02:08:13 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020519.4597; Fri, 4 Jun 1993 02:05:19 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 00:57:16 EDT
Date:      Fri, 04 Jun 1993 00:57:13 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0ed62d.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   On Peters attempt to make a smaller group [djg28]
Status: OR

On Thu, 3 Jun 93 14:40:46 +0200, Peter Mueller wrote:
> Hi,
>
> I want to present two points.
>
> 1. Who is absolutely interested in designing ROI for Moose? (I mean, who is
>    not able to live without it :-) This is the first attempt to create a smaller
>    group. Maybe we can setup a smaller alias list. And others are not bombed
>    with mails.
...
> Ad 1.
>
> I want to form a smaller group of interested people, to force a useful
> specification on ROI (where a 1 is the major number ...). I plan to inform the
> whole Moose community periodically each quarter a year. (If this is QUIRKS:
> I mean after 3 weeks.) In my opinion we should create smaller groups, where
> people talk especially and exactly about one (1) topic, and where mails
> referencing to multiple sujects can be avoided. What do you think?
...
>
> Peter

There is a serious problem with trying to make a smaller group for
ROI.  ROI as you call it is the core of Moose.  It is the one of the
things that makes Moose Moose.  ROI is after all the messaging
facility of Moose, and so is crutial.  No one should even consider not
participating in, or at least paying attention to, this discussion.

David

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 08:17:48 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07808; Fri, 4 Jun 93 08:17:47 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 08:17:47 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07542; Thu, 3 Jun 93 23:06:57 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA02003; Fri, 4 Jun 93 02:07:06 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020520.4602; Fri, 4 Jun 1993 02:05:20 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 01:14:47 EDT
Date:      Fri, 04 Jun 1993 01:14:41 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0eda49.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   On Peter's "address spaces" problem [djg29]
Status: OR

On Thu, 3 Jun 93 14:40:46 +0200, "Peter Mueller" <mueller@sc.ZIB-Berlin.DE> wrote:
> Hi,
> 
> I want to present two points.
...
> 2. I've thinked about a problem, which - in my opinion - covers the area of
>    the compiler designers (see below)
> 
> Ad 2.
> 
> Last night the following problem (and it's possible solution) came into my
> mind. An object is, at least able to have two 'address spaces', namely private
> and public. Variables, or 'objects' within the private space are only visible
> to the object, whereas objects in the public space are also seen to the outer
> world.
> 
> Now consider the following object:
> 
> class example {
>    int i;               // i is private
> 
> public:
>    int j;               // j is public
> 
>    void do_something() {
>       i = 1;            // Change object's private state
>       j = i + 1;        // Change object's public state
>    }
> };
> 

In C++ (the language of your example), these exist, but they are not 
called public and private.  They are called static member variables 
and member variables.  Please use the right notation.  

> Now consider, that 'do_something()' is a service, made available via the
> DIRECTORY SERVICE. Then (I take the term now:) client objects can remotely
> invoke do_something().
> 
> What happens?
> 
> For the client object, the example must change its private state! But this
> must only be seen to the client object! Not to others. On the other hand,
> the change to the public state must be seen to all other clients.
> 
> We can say, the change of the private state is a local change to the state
> seen by a specific client object, whereas a change of the public state is
> a global change seen to all possible client objects.
> 
> Where are the problems?
> 
> The global change leads to a synchronization problem. In each situation we
> have to take care to establish a consistent state. (I think, that's where
> the compilers must give as much as help as they can!)
> 
> The local change makes it necessary to provide a copy of at least the private
> members of an object for each client object! (And therefore we need tools, 
> which similiar to those nice stub-making tools for RPC.)
> 
> Solutions?
> 
> Well, to the local change there is an easy solution. Each client, wanting to 
> use other objects' methods remotely, will create an appropriate instance of
> a server class. This class will inform the remote object, that there is a new
> client. This will lead at the remote object to 'fork' (if you will forgive my
> UNIXness ;-) a private copy, especially for this new client. The private copy 
> consists of 
> 
>    1) The private state as it was created on server startup time. (Each time
>       a new client occurs, it will see the same private state.)
>    2) The public state at this time. (A newly client can see different states
>       than previous ones.)
> 
> At the client side, this will be done within the constructor of the server class
> instance. The destructor call will inform the remote object to discard the
> created client's private view.

I am confused.  It appears that you are trying to say that the client 
owns the data of the class.  This is, IMHO, why we have a kernel.  
When a client wishes to make a new object of a class, a request is 
made to the kernel.  The kernel allocates memory, and invokes the 
constructor, allowing the class driver code access to the object for 
the duration.  This allows the class to set up the clients specific 
data.  The 'shared' data is simply variables local to the classes 
application, that need not have any additional special processing.  

When the application invokes a method of (or "sends a message to" 
depending on your terminology) the object, the class is once again 
given access to the object to do whatever processing needs to be done.  

At no time, IMHO, should the client ever have access to any object 
specific or class specific variables.  If the client needs access to 
data, it should ask for it, not get it itself.

So, all the client ever does have is one number.  This may be an 
object ID or it may be a process specific results of having done an 
open()-like call to gain access to an object (as I suggested once 
before).

> 
> I suggest the following terms for the - perhaps - following discussion:
> 
> connector - This is the object used by a client object to establish a new
>             connection to a remote object. The constructor will inform the 
>             remote object, that there is a new client, whereas the destructor
>             will say, that the client is finished.
> 
> shadow    - This is the (remote) object which is actually seen by a client
>             object after connection. Within this object only the private 
>             (and/or protected (?)) members of the remote object are hold.
>             Public members are still shared through the 'real' remote object.
>             The shadow is created after a connection request by a connector.
> 
> (The connection between client and shadow must provide a merge between the
> valid private and public state. Thus, the shadow 'merges' the local view and
> the global view.)

These terms shoud not be needed.

> 
> Other Problems?
> 
> What's about availability and fault tolerance? Reliability? Garbage collection?

next message...

> 
> Hope, to hear some comments,
> 
> Peter

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 08:17:24 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07795; Fri, 4 Jun 93 08:17:23 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 08:17:23 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07572; Thu, 3 Jun 93 23:08:01 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA08231; Fri, 4 Jun 93 02:08:08 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020521.4607; Fri, 4 Jun 1993 02:05:21 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 01:26:17 EDT
Date:      Fri, 04 Jun 1993 01:26:13 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0edcfa.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   On Garbage Collection [djg30]
Status: OR

The issue of garbage collection has now been brought up.

I hope to end it now.

Garbage Collection is an excuse to be sloppy.

In a kernel, or in anything important, you should be precise, not
sloppy.  If there is ever a time in which the we have lost all
pointers to a block, but not freed it, we have done something wrong.
To attempt to garbage collect it would just cover the problem up, and
it would come back and bite us, over, and over, and over again.

Lets not even consider garbage collection for the kernel or any core
classes.

Garbage collection for specific applications I have no objection to,
and this exists now, so it may continue.

The rule should be: any process (or kernel) that other processes
depend on must be precise and correct.

Comments?  Disagreements?

--David

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 10:19:17 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09597; Fri, 4 Jun 93 10:19:16 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 10:19:16 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07537; Thu, 3 Jun 93 23:06:55 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA01957; Fri, 4 Jun 93 02:07:04 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020521.4612; Fri, 4 Jun 1993 02:05:21 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 01:56:12 EDT
Date:      Fri, 04 Jun 1993 01:56:08 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0ee3fd.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Synchronous/Asynchronous, one more try. [djg31]
Status: OR

Well,

-------------------------

I have looked over the QNX paper.  I was very surprised to learn that
its send() call blocked until after the reply was done.  OK, so QNX is
synchronous.  That does not mean that all modern OSes are synchronous,
just that one 11 year old OS is.

-------------------------

I fully agree that either the standard library (or whatever we call
it) or the kernel should include a synchronous communication layer,
but still assert that the kernel must include an asynchronous
communication layer at at least as low a level.  I agree that
programmers should be encouraged to use the synchronous forms unless
the applications calls for something else.

-------------------------

Peter, my challenge stands.
}} All right, try this:  under Unix, write a program that reads data from
}} two data sources and does different things with the data, such that:
}}         1) only one process is used
}}         2) select() is not used
}}         3) either data source can produce data that will be processed
}}            imeadiately (sp?)
}}         4) the program does not eat CPU time
}}
}} If you can do this in Unix, I want to see it.  I don't think Unix,
}} which only has synchronous IO, can do it.
}}
}} With VMS and its asyncronous IO, this is trivial.

You dismissed this by saying that both Unix and VMS are old operating
systems.  Very well, you are welcome to replace either or both with
something that you consider a new/modern operating system.  I quoted
Unix and VMS because I know them and they are fairly well understood
and available.  If you do use another operating system in your
program, be prepared to explain it.

Good Luck...

-------------------------

The tendency of modern OSes to seperate things into lots of little
chunks outside the kernel is good.  But an OS can be just as modern
linked as one biiiiig image.  And an OS can be just as archaic in
little chunks.  The little chunks gives you modularity and isolation,
which make you programming job easier (usually).  :-)

-------------------------

--David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Jun  4 13:34:01 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13035; Fri, 4 Jun 93 13:33:59 +0200
Return-Path: <ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 4 Jun 93 13:33:59 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15188; Fri, 4 Jun 93 04:28:03 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa21807; 4 Jun 93 7:22 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa07537; 4 Jun 93 11:21 GMT
Received: from sol.cis.udel.edu by ori.cis.udel.edu id aa18201;
          4 Jun 93 11:16 GMT
To: moose-programmers@sfu.ca
Subject: Re: PostScript available? [djg27] 
Date: Fri, 04 Jun 93 07:16:34 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306041116.aa18201@ori.cis.udel.edu>
Status: OR

In Message <2c0ed387.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>We may be able to handle some other formats.  If nothing else, we all
=>have PC class machines (I think).  Of course, such an other format
=>probably means on screen displays.
=>
   Actually, all I have at home is an HP 2621P terminal. I use a
486DX/50 at work, though. I'm thinking of getting a low end Unix box,
like a SPARC Classic for hacking. The sooner I can get away from ISA,
BIOS, and 640K conventional memory, the better. I may end up with a
486 running 386BSD, but I'd rather not.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Jun  4 13:45:48 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13418; Fri, 4 Jun 93 13:45:46 +0200
Return-Path: <ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 4 Jun 93 13:45:46 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15520; Fri, 4 Jun 93 04:38:58 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa22282; 4 Jun 93 7:37 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa07562; 4 Jun 93 11:36 GMT
Received: from sol.cis.udel.edu by ori.cis.udel.edu id aa18286;
          4 Jun 93 11:31 GMT
To: moose-programmers@sfu.ca
Subject: Re: Synchronous/Asynchronous, one more try. [djg31] 
Date: Fri, 04 Jun 93 07:31:23 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306041131.aa18286@ori.cis.udel.edu>
Status: OR

In Message <2c0ee3fd.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>Well,
=>
=>-------------------------
=>
=>I have looked over the QNX paper.  I was very surprised to learn that
=>its send() call blocked until after the reply was done.  OK, so QNX is
=>synchronous.  That does not mean that all modern OSes are synchronous,
=>just that one 11 year old OS is.
=>
   IPC in QNX was discussed on comp.os.research a few weeks back. It
seems that Dan Hildebrant (sp?) and the folks at QNX generally don't
have a need for the asynchronous primitives for the class of programs
that they deal with (real-time applications.)

=>I fully agree that either the standard library (or whatever we call
=>it) or the kernel should include a synchronous communication layer,
=>but still assert that the kernel must include an asynchronous
=>communication layer at at least as low a level.  I agree that
=>programmers should be encouraged to use the synchronous forms unless
=>the applications calls for something else.
=>
   Ok, so we do both, with synchronous being primary, with asynchronous
being equal or secondary, depending on architecture and implementation.
Good enough?

=>Peter, my challenge stands.
=>}} All right, try this:  under Unix, write a program that reads data from
=>}} two data sources and does different things with the data, such that:
=>}}         1) only one process is used
=>}}         2) select() is not used
=>}}         3) either data source can produce data that will be processed
=>}}            imeadiately (sp?)
=>}}         4) the program does not eat CPU time
=>}}

   I think my point would be that the question is flawed. :-)  You
assume that #1 is bad, while I would say that multiple processes
might be a reasonable way of dealing with multiple streams. If the
processes (threads) are light enough, this shouldn't be a problem.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Jun  4 17:53:57 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17835; Fri, 4 Jun 93 17:53:56 +0200
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 4 Jun 93 17:53:56 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22823; Fri, 4 Jun 93 08:47:21 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ag00529; 4 Jun 93 11:40 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id ab09491; 4 Jun 93 15:29 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa21486;
          4 Jun 93 15:27 GMT
To: moose-programmers@sfu.ca
Subject: Re: On Peters attempt to make a smaller group [djg28] 
Date: Fri, 04 Jun 93 11:27:37 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306041527.aa21486@gloin.cis.udel.edu>
Status: OR

In Message <2c0ed62d.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>There is a serious problem with trying to make a smaller group for
=>ROI.  ROI as you call it is the core of Moose.  It is the one of the
=>things that makes Moose Moose.  ROI is after all the messaging
=>facility of Moose, and so is crutial.  No one should even consider not
=>participating in, or at least paying attention to, this discussion.
=>
   Agreed. If others want to split off to discuss the GUI, secondary
storage, etc., fine, but communication is at the heart of the
system.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




