Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!CS.PURDUE.EDU!sbm
From: sbm@CS.PURDUE.EDU
Newsgroups: comp.os.xinu
Subject: Re: Running programs from inside XINU
Message-ID: <8904071506.AA03015@merlin.cs.purdue.edu>
Date: 7 Apr 89 15:06:13 GMT
References: <776@jetsun.WEITEK.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 43


     John Mcleod asked whether it is possible for Xinu to load programs
dynamically from a file and run them.

     The Xinu operating system actually consists of a library of system
calls and a main program that boots the system and runs the user's
program as a process, all of which are loaded with the user's program
before run time.  Xinu creates processes running functions that are
already loaded, rather than reading them in from disk; thus, it is
possible for Xinu to run on a machine without a file system (as it often
does in practice).  Modifying Xinu to load processes dynamically from
disk is of limited utility, since Xinu does not have a compiler, and so
you have to leave Xinu to compile a program anyway.  Furthermore, Xinu
will never be able to run arbitrary Macintosh applications, since these
use Macintosh ROM traps instead of Xinu system calls.  In the spirit of
Xinu, though, I have to say that it would be an interesting exercise to
implement dynamically loaded processes in Xinu.  In a nutshell, here is
what it would involve.

     The user would compile and link dynamically loaded executable files
separately from the Xinu operating system itself.  Since none of the
addresses of Xinu system calls are available when compiling and linking
these files, the Xinu system calls would have to be implemented as
traps, rather than as function calls, as they currently are.  Then
creating a dynamic process would require allocating space for the code
and static data (text, data, and bss segments) in the heap using getmem,
reading the file in, relocating the addresses in the newly read code and
data, and creating a Xinu process whose program counter points to the
entry point of the new code.  The 68000 architecture of the Macintosh
makes this job a little easier, since it uses PC-relative code addresses
which are independent of the location of the code in memory.  Hence,
only static data addresses (addresses of data not contained in the
stack) would have to be relocated.  It would be nice to release the
memory the process occupies when it dies, but the process might create
other processes running parts of its code or using its static data, so
the heap memory would have to remain allocated after process exit.

     I wish I had more time to play with ideas like this.  Have fun.

					Steve Munson
					sbm@Purdue.EDU
					sbm@Purdue.CSNET
----------