Tim Rowledge wrote:
> Actually, I'd suggest it might be useful to indirect ALL calls to 'outside' apis, so that the platform specific code can cleanly intercept any that might not be suitable; there aren't many so it wouldn't be too onerous. Let's see, malloc,
>  fread, frite, fseek, fopen, fclose, math stuff.... that's about it. The easy way would be to have the SQ code refer to some munged name and to use macro definitions to make use of the 'normal' calls where acceptable.
> Thus we could easily intercept all the file handling but leave macros for exp, floor, sin etc.

I second this. 

When dealing with code for the Newton, which doesn't support files, this
is a source of complexity. For the most part, it isn't that bad.  But
there is one place in the VM when it starts up where the shell creates a
file handle and passes it to the VM (for reading the image) which
created the worst difficulty. That is one place that Squeak does not use
its own file primitives and the workaround is ugly.

It would help if there was a test program written in C that exercised
the Squeak shell code. The test program woudl be much smaller than
Squeak itself - like one hundred lines of code or so. That way a port
could focus on getting a shell to work first.  

That test case could be as simple as:
Draw a diagonal line, respond to a mouse down or key by drawing another
line, play a sound, and maybe read a file. These could be individual
tests or run together based on compiler flags.  One could progress in
some arbitrary order - like first get the bitmap to work, then get
keyboard, then the mouse, then files, then TCPIP, then sounds. There
could be feedback provided at each stage by the test program.

On a related issue, there is much value in having a machine independent
GUI shell that collects keystrokes, tracks the mouse, interacts with
file like streams, displays bitmaps, does TCP/IP, and plays and records
sounds. With a little restructuring, the Squeak shell could turn into a
beautiful machine independent framework on top of which *anything* could
be placed. This might entail a slight performance hit depending on how
nternal Squeak data structures like strings were passed to the shell.

For example, if a group wanted to make a portable version of Python with
TK widgets, they could just put it on top of the Squeak shell platform.

This would potentially bring a lot more people into the machine
independent Squeak shell API fold. Even though they wouldn't have much
to say about Squeak, they might have an interest in porting the Squeak
shell to new platforms for their own reasons, and then Squeak could
follow. It might also multiply the number of people interested in
sharing the work of maintaining and debugging existing Squeak shell
ports.

Maybe if the Squeak low level API had a name it would be treated more
like a thing on its own. Anyone with a catchy name for the Squeak shell
and related API? 
Conch? 
Squeak API? Squeak Happy? 
The Nest?
Squeal?
Low Squeak? Rumble? 

-Paul Fernhout
Kurtz-Fernhout Software
===========================================================
Developers of custom software and educational simulations
Download our Garden Simulator for Windows & source from:
http://www.gardenwithinsight.com