Hi Joerg;
I believe this subject would be of interest to the other guys so I reply in the list, ok?
- You strip the image from everything which does BitBlt.
...
I'm sorry my explanation of the 'dual interface' was not clear.
1. My starting point was a normal BitBlt image + UNIX VM. That compiles/runs fine on OS/2. One can use a physically separate X terminal, or use an X session in the OS/2 box. (In OS/2, sessions are much like Virtual Consoles in Linux). Normally, you always have the Presentation Manager session running. The Presentation Manager uses the same API paradigm as Windows: on Win*, you dynamically link to GDI.EXE/USER.EXE and call certain functions like CreateWindow(). In OS/2, you dynamically link to PMWIN.DLL and call WinCreateWindow() and other functions. At this stage, however, Squeak does not know anything about the Presentation Manager or DLLs. 2. So the first step was to teach Squeak what a DLL was. The design is much like VA's PlatformFunctions. When this was done, I might test it by calling int DosBeep (int freq, int duration) from the OS/2 kernel (DOSCALLS.DLL). (Here of course I'm using the original Squeak interface and tools(BitBlt)). 3. Now that I can link to whatever I want in OS/2 from the Smalltalk image, I write some Smalltalk code to call WinCreateWindow() and the other nice functions which display stuff in the native PM session. So at this moment we have a running Smalltalk with two interfaces: an X one and a PM one:
+-------------------+ +----------------------+ | | | Native OS/2 | | X Screen | | Presentation Manager | | | | Screen | +-------------------+ +----------------------+ ^ ^ X Connection| | Local (TCP/IP or XSHM)+-------------+ +---------------+ API calls | | +---------------+ | Squeak | +---------------+
This is Cheese4 or BiCheese.
4. The next step was to design some platform-isolation level; that is, some widgets who may use some lower-level OS/2-specific widgets but who are themselves platform-neutral. 5. Once we have those platform-neutral widgets, we can use the descent Squeak development tools to create the Cheese Browser, the Cheese Inspector and so on. 6. Now we strip everything which is BitBlt-related. This is Cheese5; the public alpha was released on Jun 10.
Now we have the question, what do we do with this Cheese5 image. All the other guys besides CheeseVM/2 are headless there. The more I think about this the more I want to design something I would call Cheese 4+5. Well of course I have my last Bi image containing all the stuff like the browsers I developed, but the stripping itself was nontrivial and brought in a lot of stuff necessary to run the C5 image alone; so 4+5 will be non-trivial but doable, and that's what I think I should pay my attention in the next week.
---
That implies that it is impossible to use a "normal" Squeak VM to modifiy the image or changes for the native widget Squeak.
Absolutely.
I wonder if it is possible to use HTTP update mechanism which ships with Squeak 2.0.
I was thinking on that. While this is definitely _possible_, I rather doubt it would be much _practical_.
Also: I always thought that if you want native widgets in a Smalltalk environment than most of the work must be done in the VM. After reading your comments I get the impression that most of the work is done in the image.
Absolutely right.
Here is the point where Cheese deviates radically from the whole Squeak VM philosophy. In Squeak, the VM provides for a 'full virtualization' of any aspect of the hardware. You have a standard notion of the display as a two-dimensional array of pixels, and a standard set of Squeak primitives which deal with that display; it's the job of the VM to map that to whatever you actually have in your machine. Same for sound; same for networking. In contrast, the Cheese VM doesn't even suspect of any display or network at all. It provides access to 'the hardware' - the underlying OS services. So to display something on the screen or react to the mouse, or make noise with your soundcard, you need a 'driver' installed in your image. All other parts of the image rely on some standard functions described in CheeseDoc-I and implemented in the driver.
For example, if you look at Cheese5, you see that each instance of Window is stuffed with a reference to an 'implementation widget'. When you say
Window new
you ask the VM what type of underlying host UI ('video hardware') is there (Utilities>>uiType), and the instance of the corresponding implementation class is created.
But I can't see any content in that directory
[ftp.create.ucsb.edu/incoming/squeak]
ftp.create.ucsb.edu/pub/Squeak/Goodies
Regards,
Boris
squeak-dev@lists.squeakfoundation.org