> How about an architectural independent format for multi-platform
> distrubution.  It won't give you the speed of native binaries, but at
> least it will give portablity.

> Two candiates that come to mind are: RTL (this is abit of a problem,
> if two versons of NetBSD differ significantly, although it could be
> argued that if an application is platform specific then it should be
> native anyway), and the Java virtual machine.

> The Java virtual machine (start at http://java.sun.com - I think), of
> which I am currently reading, seems to be a better platform, although
> I wonder if it is workable.

I would be inclined to doubt it.  I know little about Java, only what
I've seen when I spent a few hours browsing their web pages...but the
Java machine seems to have too much security cruft to be usable as a
general-purpose machine language.  I suppose you could add lots of new
primitives (corresponding to C-coded stuff in a traditional Java
implementation), but then what's the difference between just inventing
a new p-code language from scratch?

Of course, this p-code would not be usable for things like the kernel
and init; it would be useful only for distributing application-level
software.  And we already have a good application-level language for
the purpose; it's called C.

> Another idea that was muted many moons ago was to get the exec call
> to recognise the AR format files.  It would look in the archive for a
> file that was named like the CPU. Ie. "ix86", "m68k-nfpu", etc. and
> then load that file.  This fits the classical idea of a fat file.

Yes.  Unless the archive is very carefully constructed, though, it
would have to treat the file like an OMAGIC (or is it NMAGIC?) file,
since page boundaries in the executable won't in general be aligned on
page boundaries on disk.  Perhaps such a situation should just impose a
performance penalty; perhaps it should produce ENOEXEC.

Or perhaps something else should be done.  Maybe an attempt to exec() a
directory that's mode 4000 (ie, --S------) should search it for a file
named after the machine architecture and attempt to execute that
instead.  Or is there some present use for mode 4000 directories?
Overloading directory mode bits like that is _really_ ugly, tho....

How about the following as a fat binary?  (Obviously the btoa data
sections are not for real. :-)

#! /bin/sh
fn=/tmp/$$.exec
case `arch` in
	sun4)	atob << \EOF
xbtoa Begin
B\#CQ5ecXN;^@DA[Basc'Hcrl'gfa%M,Mg.86AgYiT#,\*c;J(4"'0B%q`_G#?Q%"[#T*^.`!)`1R@
3X3Or7.r3]^XruUgqC&`a]Vm,CA-j78Dotk@6F>7L94`C(h:56au'M`_@3@'tj8<Pnoq`=T>QKK'i=
IP%W!cP`&>!SH(#RV[IS35Tk8QW"7AZ)K[Xuapc\c>B.DWAd>VITrYY17I&NO2KQVi8aV=ghB_EZ2H
qf/Y@2jn0&:C'^FsMtQef*Asdk#PcL65/2#n8;h)/E_amGM`^=o4%.4&D4I/&:k4UXOFk:(C49RPSM
Lm^`LpYo+)4I\GD)pG9,m@j[/+uppd;rcMM7([)'/k%G)1.#eJM,[?LiI;BX4N\9BeNAh&ghMXt**M
,j!So36QqGY.<lR"L9ZG79RMV<e9\ckM8#fX@Z-]2D)Pof2Q6h3$UXfYp&Q3qNlj./<st.@&\(%KdK
/:CqhGhW!9,C
xbtoa End N 384 180 E 54 S c262 R 6c84e301
EOF
		;;
	sun3)	atob << \EOF
xbtoa Begin
8Ng8jhqY=Aj_j<666ai<H+:,e<#S\%G,Ve,aKq#le/aM$NrZHgl$s)-m.`nr.@Dc2CO?ZSTnNj%c,_
53Gf;IN\/\+HI,Sl[pK*:>GRGZ\<-IVlJ.VXN<&t4/^Lm0t"S"4(N(0rd)n#l[,Dh`LfcV!&k.5'cC
kX]``$pLl]`3I<eaIbY(NWHi0LC#H>5[`H&*@S-^:]/Sa_)g5OVb3?(4tX)YBNCZBX9/AR$6PqRE*s
^>e.sAFPI<4f1kM,*Yn[&WGsnKqEUQGK2dWocHd,,\:r6eb(UD;Cg?ui\bC?4g1*O6^t&<bcYDo./K
QRZ<:m,C6`)oEdc$T1^:^LK9i*Z<[XO><d/:ddQ^s-`i;se!JL+40%ThkM<)oJcT]pYS7N&:Q%R-jd
&da!!.Kd?&3p,2Cm>s"?5paiGDF)YiEV.JDYm?V5E(DbOA<IKsGe>ZKWU+j;,.L,A#AL19m\MH)Wh3
JKW+j/Pjf3RP
xbtoa End N 384 180 E 55 S c443 R cc4a45be
EOF
		;;
	*)	echo 'No support for '`arch`' in this binary.' 1>&2
		exit 1
		;;
esac > $fn
if [ -s $fn ]; then
	chmod 700 $fn
	case $# in
		0)	exec $fn ;;
		*)	exec $fn "$@" ;;
	esac
fi
exit 1

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu