Hi Joerg;

I believe this subject would be of interest to the other guys
so I reply in the list, ok?

> 1. 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