Mac OS X VM (was Re: New VMs)

Marcel Weiher marcel at metaobject.com
Fri Jun 29 15:16:45 UTC 2001



On Thursday, June 28, 2001, at 07:24  Uhr, Doug Way wrote:

> So, to get the VM I downloaded and untarred Squeak3.0.1-MacOSX-
> VM.tar.gz, and it contained all the sources, but I just wanted the 
> compiled VM so I then untarred the Frameworks subpackage as per the 
> Readme instructions.

Is it a problem that it includes source?

>   I tried double-clicking the resulting CocoaSqueak app (which had the 
> correct Squeaky VM icon), but it only bounced for a second and didn't 
> run.  (Also, it's only 60K or so which was odd.)  Drag-and-dropping an 
> .image on it didn't work either.

As you correctly figured out, those 60K contain virtually no code.

> I then realized I probably needed to move the Squeak.framework file 
> into the framework search path, which the Readme mentions.

Both Squeak.framework and SqueakAppKit.framework.

>  I tried moving it to the suggested directories (I had to create them 
> both),

Yes, sadly, the default OS-X install doesn't create those.

>  but I'm not sure if they were actually in my framework search path.

Either

/Library/Frameworks/Squeak.framework
/Library/Frameworks/SqueakAppKit.framework

or

~/Library/Frameworks/Squeak.framework
~/Library/Frameworks/SqueakAppKit.framework

should work.


>   (I checked my environment variables but didn't see one which looked 
> like the right one.  Yes, I am a Cocoa newbie, but I'm familiar with 
> Unix.)

The framework search path is not encoded in environment variables.

>  Double-clicking the VM still didn't work.

That should have done the trick.

> Anyway, do all Cocoa apps need a separate .framework file?

Yes and no.

Frameworks are the 'default' method for bundling functionality (code / 
shared libraries) in MacOS-X.  Look at /System/Library/Frameworks and 
/System/Library/PrivateFrameworks/, almost all the higher level 
functionality in MacOS-X is there.   They differ from shared libraries 
in that they can contain both code and non-code resources, including 
documentation, headers, data-files, user-interface elements, squeak 
images/projects, whatever and also have a versioning mechanism so 
multiple version of frameworks can exist at the same time and be used by 
different applications.

Since just about all applications on MacOS-X require at least some of 
these frameworks, and Cocoa itself comes as (several) frameworks all 
Cocoa applications do, in fact, 'require' separate framework 'files', 
just like programs on other platforms usually require (system) shared 
libraries.

Not all Cocoa programs bring their own framework files, however.  Some 
programs simply aren't themselves modular, all the relevant code is 
heaped into one single executable (apart from references to system 
libraries).  However larger pieces of software tend to also have code 
that is split into individual frameworks (shared libraries), just like 
the system code.  I consider this (i.e. system-supported modularity) a 
Good Thing.  As a matter of fact, absence of this or a comparable 
mechanism is one of the biggest problems I have with Squeak at this 
time.  It's a bit like dynamic messaging:  difficult to do without once 
you've become used to it.

When functionality is packaged as frameworks it ceases to be private to 
your particular application but instead becomes available for others as 
well.  For example, OmniWeb makes virtually all of the functionality of 
a web-browser available as separate frameworks.  Mail.app references a 
Message.framework for mail-delivery that is also available to other 
applications, ScreenSaver functionality is available as a framework, etc.

Apart from the utilitarian effect, this sort of packaging also has a 
positive (and difficult to describe) effect on the code you write, well, 
at least on the code I write.  Together with Objective-C categories 
(which allow you to add methods to pre-existing classes), you can really 
split your code into small, self contained units that do one thing, and 
only one thing, well.  Applications then usually become a matter of a 
little glue to tie several frameworks together, possiby with some UI, 
but maybe also without.  That is why CocoaSqueak.app is only 60K, it 
really just ties together Squeak.framework (base interpreter and 
faceless I/O),  SqueakAppKit.framework  (GUI, interaction, media) and 
Cocoa's application-support.

This opens up a whole range of possibilities.  For example, you can very 
easily build your own Squeak-based Cocoa-applications, using a custom 
icon, custom code etc. but sharing all the common Squeak VM stuff via 
the framework.  The framework could also be a centralized repository for 
other shared Squeak resources, such as the sources file or even one or 
several 'standard' image files.  Squeak-Cocoa apps could then consist of 
the small binary (as you noted about 60K), some custom native classes or 
plugins and maybe a project file.

A Squeak Shell  ( sqsh? ) could benefit from the same mechanism, with a 
small executable linking in the framework and thus being able to execute 
with a standard image.  Of course, the usability of this depends on 
being able to load the 'standard' image file quickly.  CocoaSqueak 
already maps the image-file into memory, so once its there loading time 
is negligible with Mach's very lazy virtual memory subsystem, and 
Andreas hinted that we might soon be able to do without going through 
the image each time on load if we manage to get the same VM address.

However, as you note, the problem with this approach is that it makes 
installation more difficult, requiring detailed instructions or an 
installer program.  (I figured that the average Squeak user at this 
point is savvy enough to deal with it...).  Anyway, MacOS-X also 
provides a mechanism for placing an application's frameworks inside the 
application wrapper (applications and frameworks are both kinds of 
'Bundles', a specific directory structure for packing executable code 
and resources).   Of course, this hides the frameworks again, making 
them, once again, unavailable for others.   Also, this packaging method 
requires some voodoo that isn't entirely well supported by Apple's 
development tools at this point, which is why I haven't gotten around to 
it yet.

However, creating a combined (and possibly binary-only) CocoaSqueak 
package is something that is on the list of things to do, but hasn't 
gotten done (along with lots of other things) because I've had a few 
other things on the table recently.  What would then be great is a 
mechanism for making those frameworks sharable as well.

I hope this answers you question.

Marcel





More information about the Squeak-dev mailing list