Hi,

I've not looked at the Display smalltalk code or the VM C generated and hand
written code yet, but it occurs to me that an object oriented approach at
the C level like what the "Io Language", http://www.IoLanguage.com, uses
would be really nice for the squeak vm. The approach to writing C level code
that Steve Dekorte has taken is influenced by Objective-C, which in turn is
influence by Smalltalk. It is a unique (and thus new as far as I've seen for
writing C style) and elegant means of naming C structure and functions as if
they were classes and methods in Objective-C. His page
http://iolanguage.com/Software/C/Notes/OOC.html describes his approach.

How does this relate to the multiple os windows and other parts of the
squeak vm, like multiple drivers for sound cards, multiple copies of the
squeak vm, squeak vm embedded in another application such as apache, etc...?

The answer is that the os window becomes a "OOC level class" with "OOC
functions" for all it's operations. Thus it would be easy to open an
additional os window by simply instantiating a new one!

There could even be an automatic mapping between OOC classes and Smalltalk
level code. For that a OOC method would be needed that reported on the OOC
methods and their parameter types. Although that could also be obtained
automatically from the OOC class and method definitions (i.e. .c and .h)
files. Since most of the vm code is generated this should be easy.

The speed of OOC is just as fast as regular C since it's a "style" of
writing C to make it more understandable and more object oriented.

A very cool feature of the Io Langauge vm is that it can be embedded within
other C programs and it can also have multiple vm's instantiated at the same
time in the same process space! Very nice features. Imagine squeak running
inside of Apache as Perl does! To support this a restructing of the vm
generated and handwrtiten code is needed such that they all refer to their
vm via a pointer since there are multiple vm's possible.

A really nice capability that this offers is more bullet proof debugging.
Imagine one squeak vm instance in a process debugging the other vm instance
in the image. What happens to images in this case? Each loads it's own
image! But they have more intimate access possibilities than seperate
processes. In some ways this is similar to the unix squeak vm that can
"fork" off child processes and control them from the parent image.

Just some thoughts for the vm 4.0 re-design.

All the best,

peter