Marc Nijdam wrote:
> I'm looking for a way to start the Squeak VM from, say C or C++ like
> JNI does for Java. This would allow me to embed Squeak in "legacy"
> applications...

Marc -

If you don't want a GUI in your "legacy" apps, (or even if you do), you
might want to look at Embedded Squeak (Squeakette):
http://www.kurtz-fernhout.com/squeak

I created the original slimmed down version for Windows (mostly by
throwing things out), and Markus Kohler and Marcus Denker have created
UNIX ports. Marcus' is at: ftp://ftp.ira.uka.de/pub/squeak/esqueak/
They are doing exciting stuff with it, and it's possible we might have a
headless CGI bin scripting version of Squeak someday soon.

Embedded Squeak (A.K.A. Squeak-e, eSqueak, or Squeakette) is a version
of Squeak with the image compiled into the executable and most I/O
primitives removed. It would be possible to link it into an existing C
programs, however the "interoperability" of Squeak and your legacy app
is very limited. As Blake McBride pointed out on the list last month,
calling into and out of Squeak is a non trivial thing. Python
http://www.python.org has this call in/call out problem pretty well
solved; maybe we could adapt some of their ideas to Squeak. These
involve locking and unlocking intepreter threads, among other things.

Embedded Squeak excels at text/input output -- like CGI scripting for
putting your toaster on the net. Of course, since you have the source,
you could add embedded control primitives for other I/O, like a vision
system for determining when your toast is optimally burned. :-)

I should call your attention to the Squeak license clause as it relates
to making source available for changes to the VM when a modified EXE is
distributed. If you tightly couple your code and the VM you may risk
your legacy code falling under this this. 

This is one area where the Squeak license may impede its use for
embedded systems. For example, with the Python license, you would have
no source redistribution requirement when using SWIG http://www.swig.org
to generate C wrappers for your legacy code and then linking them with
Python. Actually, Python is also more modular, so it's very clear your
additions are a new module, and the functions are added by calling the
interpreter new-function-loading functions at run time, which isn't the
case when adding function calls from the Squeak VM. 

You might want to do a tight intertwining like this, say if you wanted
to use scripts written in Squeak to exercise and test your legacy code.
SWIG/Python, SWIG/Perl, and SWIG/TCL are commonly used to do this. If
you want to call all your legacy functions somehow from Squeak (like
through primitives?), and then distribute that application, you may risk
an interpretation of the license that all your code is now part of the
VM and must be shared. 

To get around that, you may need to take advantage of Squeak's new
dynamic linking features (plugins) or come up with some other approach
to cleanly separate your code from the VM.

Personally, I'd love to see Squeak able to support the Python module
definition / object interface protocols. This would give Squeak access
to high speed numerical array manipulation code, as well as a variety of
other Python addins. With such an approach, we could compile C modules
written for Python (or generated from C/C++ with SWIG) with the Squeak
VM and have them appear as Squeak objects, with a clear sense that the
new functions were "linked at runtime", even if statically linked into
the Squeak EXE. The linking happens when an initialization function is
called and function pointers are associated with names in the intepreter
(Plugins already must do something like this, for code outside the EXE).
I imagine we would have to take all the base Python interoperation
functions (like converting a float to a Python object) and make them
convert to Squeak objects. However, since Python is pure OOP, this may
not be that hard. Alternatively, or additionally, maybe SWIG could be
adapted for Squeak.

Of course, some people read that part of the license to mean that you
just have to supply the changes to the VM code to make the legacy call,
and not the actual code it calls. That clearly is a riskier
intepretation. Personally, I think that interpretation is probably
justified based on the license's intent and the common meaning of a
"virtual machine". VM to me means pretty much just the byte code
interpreter and supporting primitives for housekeeping type functions,
as opposed to say an add-on 3D graphics package accessed through
primitive calls. I'm not a lawyer though, so check with one first if
this is an issue for your work. Even though I believe the interpretation
is justified, I still would avoid depending on it myself, instead doing
some form of dynamic linking or other approach just to be safe.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the open source Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com/