a.out.h,adventure operating systems, JMP indirects, C for Apples, etc..

[M.J.Shannon]

> 
>   Basically, I'm writing a unix-like operating system on a micro to base
> an adventure-type game on.  I'm doing preliminary work on the unix system
> itself, and the operating system seems to intercept many of the things I
> must do.  The problem is as follows:  To load in the desired procedure
> (function) into the memory swapping space, call it, free the swap space,
> and continue this indefinitely.  I've written a small program segment,
> which SHOULD work, but appears not to.  
> 
> ----------------------------------------------------------------------
> 
> #include <stdio.h>
> 
> static char *filename = "file.data";
> 
> main()
> {
> int call();
> char s[2048],*s2;
> FILE *fp;
> 
> if ( fp=fopen( filename,"r" ) )
>   {
>   s2 = s;
>   while ( ( *(s2++) = getc(fp) ) != EOF);
>   
>   call( s );
>   }
> else printf("Can't open %s\n",filename);
> }
> 
> call(p)
> /* calls function located at pointer given */
> int (*p) ();
> {
>   (*p) ();    /* basically a JMP indirect op */
> }
> 
> ---------------------------------------------------------------------
> 
> It loads in an executable file (file.data), and calls the location it was 
> loaded into.  The operating system responds with "illegal instruction", 
> meaning, as I see it, that unix pre-pends some junk at the beginning of 
> the file which cannot be executed.  As I see it it's the junk from the 
> /usr/include/aout.h file.  Is this common in most C environments?
> Keeping info about a file SHOULD be kept in the directory, not in the file 
> itself.  Would anyone know how to get around this problem in a "standard"
> sort of way?   Also, I'm looking for a good ( but cheap ) copy of C for
> the Apple ][ computer and any help in that quest would be greatly ap-
> preciated as well...
> 
> 						kevvy at amsaa.arpa

If your executable program was generated on a UNIX System for a UNIX System,
then yes, there will be a header on the file which the operating system uses to
set up the memory image for the process.  This header contains information like
the size of the text, data, and bss segments, entry point, type of memory image
(some machines allow text segments to be shared among all processes executing
it, and force the text to be read-only, or `pure', etc.).  When you load the
file to execute it, you must also take this information into account.  Also,
few compilers generate totally position independent code; that is, there will
be references to absolute locations of memory in your `file.data' program.
These references will probably conflict with those in the program you're using
to load this file.  Once you've dealt with these problems, then you can work on
ignoring the header as it appears in the file.  In general, the header is a
multiple of either the memory management memory unit or of the block size of
the filesystem.  So, you have to seek past the header before you can start
reading in your file.  What you've chosen to do is decidedly nontrivial, but it
can be done.  To do it portably will take considerably more work.  Perhaps some
of the folks who wrote the `autoload' code for Franz Lisp, or the author of the
dynamic load package that was posted to the net a while back can shed more
light on the problem.  Good luck.
-- 
	Marty Shannon
UUCP:	ihnp4!eagle!mjs
Phone:	+1 201 522 6063