In areas of the library not normally used by model code (i.e. user interface, reflection, file reification, portability framework, image management, etc), we decided to feel completely free to innovate, so these areas are much different:
UI: The user-interface is designed to allow
much more finely-grained widgets, with full support for
imbedding native widgets. For example, the line of text
you are reading is actually a general GlyphRow full of
individual CharacterGlyph widgets that draw themselves.
Here is a real, live, imbedded MS-Windows button, to show
that any widget, including native ones, can be put
anywhere:
Reflection: Reflection is done with mirrors (a concept borrowed from Self), so that the system does not have to go through an object's interface to reflect on it, as in other Smalltalks. This means that objects are free, for example, to override #class so they can closely mimic some other kind of object, and this won't break system code or inspectors, etc, since they don't use those messages.
Constructors: Because of the type system and mixins, Strongtalk must support more top-level constructs and more independent options for their constructors than other Smalltalks. For example, there are also protocols and type aliases. Also, classes and protocols can be generic or non-generic, classes can be abstract or concrete, classes need to be able to declare what protocols they support, and superclasses may have mixins applied to them. All of this severely strained the 'constructor message to the superclass' approach used by other Smalltalks, so a more flexible declarative constructor framework was devised. It is normally hidden by the programming environment, but it means that the file-out format is different for top-level constructs, although it still uses the same 'chunk' format as other Smalltalks.
Images: Image management is very different. This is due to observation of the problems that many new Smalltalk programmers have when they are introduced to images. The first problem is that they try to use images as an actual database for their production application data, which images are completely unsuited for. A second problem is that deploying a program as an image means that you can never quite be sure what history-dependent state got mixed in with your program. So most programmers end up always having to do extra work to build a fresh image before testing and delivery, to be sure that there isn't some state floating around the image they weren't aware of. A third problem is that objects that relate to the outside world (i.e. file editors, open file descriptors, database connections, etc) can easily end up corrupted or in the wrong state, unless complex management code is written to fix them up when an image is restored.<\p>
So in practice, images are really only useful as a convenient way for developers to keep the state of their programming environment between sessions. In Strongtalk, we use an external HTML start page that can hold Strongtalk browsers and code, to fulfill this function. The image itself is declarative, meaning that it only contains the program declarations themselves, with no variable state. This way, delivered programs always behave predictably, and start in a state defined solely by the program code.