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
|