Hi,
  Probably more than you ever wanted to know about how the Mac 
does this.  I did just try moving Squeak3D into a folder named
Squeak 2.7 inside my extensions folder and the prims were found.

  The applications library directory concept might be the best choice.
It would allow a folder in the same directory as the app to hold
all of the plugins.  I'd tend to shy away from the folder within
the extensions folder just because I bet we get odd errors when the
wrong copy of some prim library is found..

cheers

bruce


http://developer.apple.com/techpubs/mac/PPCSoftware/PPCSoftware-41.html

Import Library Searching

When searching for an import library to find code or data that is
imported by some other fragment, the Code Fragment Manager follows a
standard search path. It looks in various files and folders in a
specific order until it finds an import library that exports the code
or data imported by the fragment being loaded. Once the Code Fragment
Manager finds a library that it deems compatible with the fragment
it's loading, it stops searching and resolves imports in the fragment
to code or data in that library. In general, the exact order in which
the Code Fragment Manager searches for import libraries is transparent
to your software. However, you might need the information in this
section to ensure that a particular import library is found before
some other import library, which might also be compatible with your
fragment.

Note See the next section, "Version Checking" beginning on page 3-7,
for information on how the Code Fragment Manager determines whether
some import library is compatible with a fragment.

When loading and preparing an application that imports code or data
from an import library, the Code Fragment Manager searches first in
the application file itself, by looking for import libraries indicated
in the application's 'cfrg' resource. Typically, any import libraries
contained in your application are located in your application's data
fork, either before or after the container that holds your
application's code and data. Less commonly, you can put an import
library into a resource in your application's resource fork. The
'cfrg' resource specifies the location of any import libraries that
you've included with your application, whether in the data or the
resource fork.

If an import library used by your application is not found in the
application file itself, the Code Fragment Manager next searches in
any directory designated as the application's library directory, a
directory used by the application to store import libraries or aliases
to import libraries. You specify a library directory by including in
the appropriate field of your 'cfrg' resource the ID of an alias
resource that picks out the library directory. See "The Code Fragment
Resource" beginning on page 3-28 for details.

The Code Fragment Manager searches a directory by looking for files of
type 'shlb' that contain a resource of type 'cfrg'. The 'cfrg'
resource identifies the logical name of the import library, which is
needed to match the library's name generated at link time. There can
be more than one logical name listed in a single 'cfrg' resource. This
might happen if there are multiple import libraries contained in the
data fork of a single 'shlb' file. This might also happen if a single
import library or application is to be identified by more than one
name. Within a directory, the Code Fragment Manager also looks for
aliases to files of type 'shlb' and resolves them to their
targets. The alias file must itself be of type 'shlb'.

If no suitable import library has been found yet, the Code Fragment
Manager searches next in the directory that contains the
application. If any import libraries--whether located in the
application's directory or targeted by an alias in the application's
directory--are determined to be compatible with the fragment whose
imports are being resolved, the Code Fragment Manager chooses the most
compatible library and stops searching.

IMPORTANT The Code Fragment Manager looks only in the top level of the
application's directory, not in any subdirectories contained in it.

If no suitable import library has been found yet, the Code Fragment
Manager searches next in the Extensions folder in the System Folder
and in all the subdirectories of the Extensions folder, including any
directories that are targets of directory aliases in the Extensions
folder.  Once again, both files of type 'shlb' and targets of aliases
of type 'shlb' are candidates for compatibility checking. This scheme
allows you to store your import libraries in a vendor-specific
location in the Extensions folder.

If the Code Fragment Manager still hasn't found a compatible import
library that exports the imported symbols in the fragment it's trying
to prepare, it continues by looking in a ROM registry, which keeps
track of all import libraries that are stored in the ROM of a
Macintosh computer. The Code Fragment Manager registers all ROM-based
import libraries in this registry at system startup time.

The final stage of the search path is a file and directory registry
that it maintains internally. This registry is a list of files and
directories that, for various reasons, cannot be put into the normal
search path followed by the Code Fragment Manager or would not be
recognized as import libraries even if they were in that path. For
example, to be registered automatically by the Component Manager, a
component must be stored in a file of type 'thng'. To inform the Code
Fragment Manager that the file also contains one or more import
libraries in its data fork, it can be registered in the file and
directory registry.

Note The Code Fragment Manager routine to register a file or directory
is currently private.

If your application or other software loads a fragment explicitly from
disk by calling the GetDiskFragment routine, the Code Fragment Manager
first looks for any needed import libraries in the load directory, the
directory that contains the fragment being loaded. (This directory is
the one specified in the fileSpec parameter you pass to
GetDiskFragment.) If no suitable import library is found there, the
search continues along the path followed when loading and preparing an
application. However, the Code Fragment Manager looks in the load
directory first only if it is different from the application's
directory. Otherwise, the load directory is searched in its normal
sequence, after the application file itself and the library directory.

In summary, the Code Fragment Manager looks in the following places
when searching for an import library to resolve one or more imports in
a fragment being loaded:

   1.The load directory (the directory containing the fragment being
loaded). The load directory, however, is searched only when a fragment
is loaded in response to a call to GetDiskFragment or
GetSharedLibrary, and only when it's different from the application's
directory.
   2.The application file, if the application's 'cfrg' resource
indicates that the application file contains import libraries. The
application fragment is implicitly treated here as an import library.
   3.The application's library directory (as specified in the
application's 'cfrg' resource).
   4.The application's directory. Only the top level of this directory
is searched.
   5.The Extensions folder in the System Folder. The Extensions folder
and all directories in the Extensions folder are searched.
   6.The ROM registry maintained internally by the Code Fragment
Manager.
   7.The file and directory registry maintained internally by the Code
Fragment Manager.

At any stage, the Code Fragment Manager selects the one import library
of all those available to it that best satisfies its compatibility
version checking. If an import library meets the relevant criteria,
the library search stops. Otherwise, the search continues to the next
stage.  If the final stage (the file and directory registry) is
reached and no suitable library can be found, the Code Fragment
Manager gives up and does not load the original fragment.

Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> On Fri 10 Mar, agree at carltonfields.com wrote:
> > > On a related note, what about making it easier to hide or share the
> > > plug-ins? On the Mac, they all need to be in the same > directory as the VM,
> > > which is normally in the same directory as the image. How > about a VM that
> > > knows to look out on the net for plug-ins, or a format of > plug-in archive?
> > 
> > That isn't inherently the case (indeed, I'm not sure if its actually the case
> right no
> > w).  Mac apps can be made to search interior and blessed folders, as well as
> system fo
> > lders.
> I've just got to where I start trying this stuff on my PB, so if you can offer
> advice on _how_ to do this I'd be very grateful.
> 
> tim
> 
> 
> -- 
> If the code and the comments disagree, then both are probably wrong.  - Schryer
> Tim Rowledge: tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>