Re: Am I missing something?

[craig (Craig Chambers)]

Well, I just tried both the Sun-4 and the Sun-3 binaries on SunOS 4.1, and 
they worked fine.  They were developed under SunOS 4.0.3, and so they should
work fine on those OS's as well.  Other people have been able to ftp the 
binaries and use the system.  Have you tried ftp'ing the binaries again?

You can certainly run Self when you're not on the console; I almost never run
Self from the console of a machine.  The only problem is that the UI and the
_Spy monitor always put their output on the console, so if you're not on the
console, then you won't see the output (and if someone else is on the console,
they'll get these weird images on their screen).  But in any case, Self should
never crash just because you run the UI or the _Spy.  Self should never crash
no matter what you do to it [See Below for Comment].

As far as porting goes, there are no immediate plans for us to port Self to 
another machine.  I've always wanted to port Self to a PMAX (Decstation 3100,
MIPS RISC-based machine) so that I could feel good about having my compiler
be reasonably retargettable, but have always had more pressing things to do.
Other people have requested that we port Self to other machines, mostly 68k-
based machines.  I wouldn't be too hard to port Self to a machine that's
68K-based or SPARC-based, if the run-time conventions are similar to what's
on a Sun (i.e. all UNIX boxes?), since the Self compiler wouldn't have to be
changed.  A Macintosh port has been attempted several times, and each time 
we've run up against problems in various Mac program development tools (such
as the C++ compiler on the Mac not compiling some of our files, or the A/UX
tools like the preprocessor not working).  I think at last check we were able
to get most of our code to compile using MPW C++, but since MacOS has a 
different run-time architecture than SunOS, there's still some work remaining
to change the code generated by the Self compiler.

In summary, we should do some ports to the more common machines.  Perhaps some
of these can be done by people other than us, for the machines which are very
close to either the Sun-3 or the Sun-4.  Previous messages have discussed
whether people need the source released before it's cleaned up and documented,
and if we do release source people can attempt their own ports to similar
machines.  It's a much harder task to port to a different machine, since the
Self compiler would have to be retargetted; changing complex undocumented C++
code is not recommended for the faint at heart.

As far as X primitives goes, once upon a time the UI was based on X/InterViews,
and we had Self primitives that accessed X and InterViews operations.  It 
wouldn't be too hard to add them back in.  With a source release, it wouldn't
be too hard for people to add their own primitives to the system; there's even
a tool written in Self to help automate the process of generating the required
Self and C++ stub routines to interface Self programs to C++ programs.  There
is the TCP primitive for low-level access to the X server, but I can understand
the desire to have a higher-level interface to X than TCP links, especially if
it's already implemented.

The followup comment that adding Xlib primitives to Self would lead to memory
management problems is partially true.  However, we currently have a similar
problem managing bitmaps using the existing Pixrect interface, since these
bitmaps currently reside in the C heap, not the Self heap.  So explicit
memory management (calls to _PrClose) are required to manage space in the C
heap.  Similar calls would be required to manage Xlib resources, too, but this
is no worse than in C (just not as good as in Self).

-- Craig Chambers

[Self Never Crashing Comment]  This is not completely true.  There are a couple
of holes that a terribly malicious user could exploit to get Self to crash.
Some of these are documented on pages I-2 and I-3 of the Self manual.  Others
are that certain Pixrect primitives don't fully check that their arguments are
legal (such as using a bogus or freed pixrect handle or writing to arbitrary
parts of bitmaps with clipping disabled) and so could crash the system inside
a pixrect primitive.  These problems shouldn't occur unless a programmer is
working directly with Self primitives (not through the Self wrapper methods)
and attempting to cause problems.