Alejandro,

the Squeak's window creation must be done in the upper level (in Smalltalk) and not by the VM !

Absolutely. Cheese (all versions) does it that way.

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.

This is what I dreamed for from day 1 of Cheese.

In Cheese 5, the design is such that *the image*, not only *the source code*, is completely platform-indepenent. That is, imagine a scenario like this: a Squeaker starts his image on his NT box and sees a native NT Transcript.

From Transcript's menu, he opens a browser where he creates

a subclass of Window with instance variables 'text' and 'saveButton', and implements the following instance methods:

open saveButton _ PushButton named: 'Save'. saveButton topAttachment: #self; topOffset: 30. saveButton whenClickedSend: #save to: self. text _ MLE new. text bottomAttachment: #pane pane: saveButton. self addPane: saveButton; addPane: text. super open

save | string | string _ text text. ... code to save string into file ...

(The code shown does actually work with my current image, but only on OS/2 PM).

Then, our fellow saves his image and transfers it to an OS/2 (PM) or Unix (Motif/Lesstif) machine. The only thing he should care about is to correctly transfer the file. Then he starts the image, does 'MyEditor new open', and enjoys the new look and feel. But that's not all: one can save the image with a MyEditor being open, transfer to another OS, and see the window upon startup.

Cheese 5 achieves this by using proxies for all its classes. Class Window implements doesNotUnderstand: which forwards all messages to the actual object which was created in Window class>>new. The latter obtains which l&f flavour from the VM and prefixes the name of the class.

So there are platform-neutral Cheese classes like ListBox, PushButton, MLE and so on, and parallel <Platform>ListBox, <Platform>PushButton etc. classes, like PmListBox, WinListBox, and so on. In an image configured for PM and Motif, the are ListBox, PmListBox, and MotifListBox classes, all in one image, and code in Window decides which one to use at any given moment. To port to another platform, you don't need to modify any existing code, just add WinListbox or MacListBox and other classes (and classes that support their fuctionality, like classes in SqApi for Win*).

And here is where I want to modularize the image. Why should I have to load Win*, Mac*, and Pm* if I live under Motif? But on the other hand, I want to share my work with you who are on Win. If we had a mechanism to split the image into load-on-demand modules, the problem would go away because then I'll just have a Motif module on my machine and you'll have a Win one on yours.

So I definitely see modular images as really necessary, but I still don't know how to implement them. If anyone has any hint...

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.

I was already looking into that. Neat idea. But why make Squeak do all the work where we can put it on the OS? Just put different sets of primitives in different DLLs. My own vision for VM modularity came from the UPs. I had Ian's sqUserPrimitives.c with his sample primitives, and my own one with DLL callout (like your SqApi, but for OS/2). 'Ok', - I said, - 'now I want both, should I produce a merged sqUserPrimitives.c by hand???' Didn't look like an option... now it searches for all DLL in the cwd to see if there are some user primitives to load.

Regards,

Boris