Jarvis wrote: 
>Sounds like another reason for a headless Squeak that doesn't need to
>open a window.  :-)

Sounds like another reason to modularize the VM and the image...

If we "modularize" the VM to have the opportunity to load its parts when the "upper (image) objects" need it, the complete building of the VM can be done dynamically.
In commercial versions of Smalltalk like PPD, the user have the possibility to write some primitives in an external module (e.g. DLL) and bind/unbind a service to a primitive number to expand or patch VM behavior.
If we work a little in the Squeak Interpreter layer in this direction (I hope) it will be more easy (and fun) to produce VM plug-ins (for example to provide network, audio, video capabilities ONLY when the upper-object support is present in the image and needs it).

I think that we must try to fractionate the image, and support dynamically bound subspaces of objects. It will help to produce native OS wrappers and other loadable-on-demand frameworks.
And, ..., the Squeak's window creation must be done in the upper level (in Smalltalk) and not by the VM ! Provably all the GUI and resource work done when image boots must be reduced to be minimum and code moved to Smalltalk startUp code.

Cheers,
Ale.

Alejandro F. Reimondo
Feel free to visit Smalltalk User Group of Argentina (SUGAR)
at http://www.sugarWeb.com



>From:	Andreas Raab [SMTP:raab at isgnw.cs.Uni-Magdeburg.DE]
>> Your best bet is probably to use the SRVANY utility from the NT resource
>> kit, which allows any executable to be run as a service under NT.  Just
>> a thought, hope it helps.
>It's the right idea but at the moment Squeak will open a window and I
>don't think that will work when running as a service (although I didn't
>try).
>Andreas