Re: [MACTCL] Loading extensions under Tk on Macintosh

[Jean-Claude W. <jc...@eq...>]

Michael A. Cleverly <mi...@cl...> wrote:

>I'm writing a multimedia Tk application which will be distributed on a
>CD-ROM.  It uses the Snack extension for audio, and for video either
>QuickTimeTcl/TMCI (Windows) or xanim drawing into a Tk frame (Linux;
>probably eventually Solaris & *BSD too).
[...]
>I only have limited experience with the Macintosh.  Can someone clue me in
>on how I can have my app run on a Macintosh without making the end user
>first install Tcl/Tk & then the extensions? Would it be possible to build
>Tcl/Tk with QuickTimeTcl & Snack statically linked, and would this solve
>my problem? (Not that I have a C compiler for the Mac, but I'd be happy to
>PayPal someone who did.)  Or are my problems caused due to the fact that
>the CD doesn't have data/resource fork info? And, without Tcl/Tk being
>installed, could I work around this using the Mac-specific Tcl commands?

Other replies already cover most aspects I think, but allow me to single
out and summarize the issue of "what differs on the Mac" (macos pre-X,
that is):

 - mac applications store code in the data fork for PPC, and in the
   resource fork for 68K, these can be combined to make a "fat" binary
 - but no matter what, you need a resource fork with *some* info in it,
   and that's what makes cd's, file xfers, and vfs "different" on mac
 - for a mac application to run off the cd, it has to be written using
   the HFS(+) format AFAIK, i.e. the mac's filesystem as image on a cd,
   that's the only way to have resource forks without unpacking
 - to use the cd on multiple platform, you create a "hybrid cd", which
   stores files once, but contains multiple catalogs/indexes, so that
   each O/S sees a native fmt (unix: rockridge, mac: hfs, win: joliet)

If you're going for the hybrid, then you have a normal Mac context, and
you can have Mac files with data + resource forks on the CD.  In your
case, you'd have a couple such files: Daniels shared tclkit, and
extensions such as Snack.

If you don't create a hybrid CD, then you will *have* to ask Mac users do
unpack things before use.  This need not be a show stopper, but it's less
of a runs- out-of-the box type experience.  This approach does treat Mac
users as second-class citizens, IMO.  But having said that, it's not
uncommon, many people go through stuffit-expander for network downloads.
 In this scenario, you store Mac files in a packed single-file form, such
as MacBinary (.bin) or BinHex (.hqx), and ask then to unpack before use.
 You'll need to decide on what to unpack, and how to find the different
parts (loading the unpacked Snack shared library).

I'm pondering on a third option, in which tclkit is augmented with at
least MacBinary unpack support.  This would allow Mac shared libs to run
from vfs, and hence scripted documents.  It would not avoid the initial
unpack of tclkit itself (this is unavoidable without HFS on cd), but it'd
make it possible to create multi-platform setups without access to a Mac,
even if shared libraries such as Snack are used.  The end result is a
non-hybrid CD with a "myapp.bin" on it (this is tclkit), plus a few more
mac-specific .bin files and/or one or more scripted documents (i.e. all
normal single-fork datafiles).  To use it on a mac, one stuffit-expands
myapp.bin (once) to the hard disk, and launches it.  Other unpacking
would then happen under control of the application, and on-the-fly.  This
is not perfect, but is as minimal as I can come up with, and one can
still claim that it does not clutter the user's disk - uninstall is a
matter of dragging the expanded "myapp" application file to the trash.

This third option does not exist today.  I'm not sure to what extent the
mac supports launching an app on disk-insertion.  If it doesn't for non-
HFS disks, for example, then this third option will remain an imperfect
solution no matter what.  Then again, if the goal is to produce cd's
which run anywhere - including on the mac, then for some this might be
good enough?

-jcw