> I guess that if the image is stripped of all "platform glue" classes (file
> system, memory access and all the like) it would be safe enough.

Implement a custom 'safe' VM minus the primitives.  That would fix it
regardless of what the image wanted to do.  Incidentally, the VM doesn't
need to be thread-safe.  Simply compile as an ActiveX EXE with its wrapper
class marked as Single Use.  Then a new process starts up every time you
instantiate a Squeak script --- memory-hungry, ugly, but no worse than CGI
scripting and a good first step and proof-of-concept.

> The command-line only squeak is called "HEADLESS" ?

Or server-only Squeak.  It's good for eg. Web or multi-user game servers.

> Microsoft's terminology is really obscure (to me at least).

Not just to you.  It's not even internally consistent.

> What I had in mind is to have some kind of factory that will instanciate a
> wrapper class for each kind of COM insterface.

Wrapper method generation can be done efficiently in advance if you can
query the methods supported by the interface.  You'd need the type-library
information to do this.  You'd then have the ability to support
early-binding from your wrapper class into COM.  Not sure I'd bother with
efficiency though (see below).

> Then override
> "doesNotUnderstand" to try to send the message to the wrapped object.

This is essentially what IDispatch does anyway within COM.  Late binding is
already dreadfully slow; I don't see that this would make it unreasonably
slower.  VBScript and JScript seem to get on perfectly well using late
binding 100% of the time, and Squeak already has a number of proxies that
inherit from ProtoObject and use dNU: to do flash things with whatever
method they get handed.

I reckon you could get away with six primitives and a wrapper class,
corresponding to CoCreateInstance+AddRef, QueryInterface, GetIDForName,
GetNoOfArguments, GetArgumentType, and Dispatch (the names may be wrong on
the last four; they're the extra IDispatch calls).  Use finalization in the
image to call Release (and beware image termination!), and you've pretty
much got a working script interface.

One question: How do you intend to get the initial script *into* your
scripting interpreter?  Is the 'script' an entire image?  A block?  A chunk
of text to be compiled as if in a Transcript?  If it's not an image, that
implies that the pre-existing image must be tricked into running the script
at startup, which might be an interesting exercise.

Just my 0.02 Euros (around $0.02, and worsening :-).

		- Peter
--
Peter Crowther, MCSE+I, MCSD, MCDBA, MCT, CCI, LLAHN
Training Manager, IT-IQ Training Limited, Warrington, UK