Georg Heeg, ObjectStudio integrated inside VW. This is an ongoing project, being doen both by Heeg and the Cincom Smalltalk engineering team. History: Cincom purchased ObjectStudio in 1994-1996, and VW later in 1999. Since then, OST customers have wanted many of the same features that exist in VW. Here's Georg:

VW goes back (as does Squeak) to Smalltalk-80 (and predecessors) at PARC. The image is a direct descendant of the original images at PARC (as are all the objects). ObjectStudio was developed as an "Enterprise Object-Oriented Development Environment", called Enfin. ObjectStudio can be bootstrapped any time. VW is fast, and has a solid meta-model. OST is oriented towards client side, enterprise development.

OST customers really want the speed of VW, as well as the tools. They really like the Enterprise integration tools in OST.

It's so commonplace it hurts: A press conference is called. The media is alerted. The top executives gather for much backslapping and multisyllabic descriptions of the synergistic opportunities abounding in this, a fresh new partnership. There's a champagne toast and then the most extraordinary thing happens...nothing! Nothing at all.

Jigsaw, many industry mergers, even a prior attempt to push the VW VM under OST (The HPSOS project). This time, the project was started without promoting it ahead of time to customers, and instead starting with a proof of concept modeling attempt. The idea: Model ObjectStudio in VisualWorks.

• Use Meta Modeling
• Use all reflection capabilities

Both OSt and VW live in the same image. Both share the same kernel and base classes. This allows for mixing and matching.

Heh - the first step started when Georg had a case of laryngitis, and couldn't speak for a week. Thus was started this project with a basic proof of concept. At that point:

• Smalltalk worked
• UI did not
• primitives did not

So, the next step was to have an intern take a swing at doing a DLL that would implement the MFC functions that are currently called from the OST DLL. He took that one function at a time. Over time, it started to work. The plan was to take it slowly, and not modify the VW VM until it was absolutely required. The things that might require speeding up would help all - OST and VW.

The issue - there are 450 MFC primitives, so doing one primitive per day was going to be really slow. So that approach would be way, way too slow - stopped that in January 2005. Instead - take the entire OST C/C++ codebase and make that a callable DLL. There is a pre-alpha ready, but it needs major shake-out work.

So OST is embedded in a single namespace, and it shares most of the VW base. Most OST classes are subclasses (with the requisite differences) of VW classes. There were some adaptations required - PoolDictionaries and Globals move to namespaces (as happened from VW 3 to VW 5i).

Also required - special readers for pulling in OST code, based on the code storage mechanism that OST uses. As well - a special parser, since OST syntax is slightly different. Some semantic differences in the libraries - #at:, #at:put: behave differently (in terms of what they return). So, the implementation substitutes OST specific methods in based on the sender. This technique has been used wherever necessary. The list is not small; there are 40+ of those now.

Another difference - OST has a thin border between Smalltalk and C; they call back and forth all the time. This is largely because OST is interpreted (no JIT), and is thus up to 30x slower than VW in most respect. There are 5 ways to call:

• Direct primitive
• Numbered primitives
• Named primitives
• Module/ENFINModule - programmatic creation of interface methods
• ExternalProcedures - programmatic creation of interfaces with C datatypes

Introduced a VW wrapper - uses regular VW DLLCC. And... There's natice widgets in this project, using MFC. Callbacks come back to VW. So - we can get native widgets now (on Windows).

Class Proxies - it works, but via file-in (so it's slower). Application loading also works, but again, is slow. However - an awful lot of this is due to refresh requests to the RB. A much smaller (but significant) slow down is from disk flushes (for the change file). Other issues in the speed of callbacks (Smalltalk/C)

So - the idea is to make it work, then - afterwards - make it fast. There are still OST packages to deal with (Modeling tool, Database stuff). The plan is to have a Technology Preview (pre-alpha) this winter. We hope to have product by the 2006 major release (winter 2006). Ok - and now a demo of what's there now. He started a stock VW image (Seemingly) - with an additional menu pick - "Start ObjectStudio". The ObjectStudio windows are using native widgets. It's still rough - you get exceptions from time to time.