>They are all dealt with as if external (on any platform, BTW). However, for
>an external named primitive you need some sort of handle to the module it's
>contained in (call it fragment on Macs, DLLs on Win, or DSO on Unix) and the
>'trick' is to get a handle to the VM itself. Normally, you get this handle
>by loading the external module into the address space of the VM but since
>the VM itself is already loaded you need an implicit way of getting a handle
>to the VM. That's what John is fighting here.

I think we've got that.  What we don't really understand is why:

myErr = GetDiskFragment(
	myFileSpec, myoffSet, myLen, fragName, myFlag,
	&myConnID, &myMain, myErrorName);

DESCRIPTION
The GetDiskFragment function locates and possibly also loads a disk-based
fragment into your application's context. The actions of GetDiskFragment
depend on the action flag you pass in the findFlags parameter. The Code
Fragment Manager recognizes these constants:


enum {
    kLoadLib          = 1,  /*load fragment*/
    kFindLib          = 2,  /*find fragment*/
    kLoadNewCopy      = 5   /*load fragment with new copy of data*/
};

The kFindLib constant specifies that the Code Fragment Manager search for
the specified fragment. ***If the fragment is already prepared and connected
to your application, GetDiskFragment returns fragNoErr as its function
result and the <<<existing connection ID in the connID parameter.>>>***

won't provide you with the connID for which you are looking.  I think 
John said this failed him before, but I'm not sure.  Can you give us 
some code and context in which it failed, because that's the most 
straightforward way I can find to load up a connID to a preloaded 
segment.

On the other hand, if that won't work, the suggestion of having a 
stub fragment loading the rest seems fairly attractive as well.