Folks,

Many thanks for all your hints and ideas. I was busy over the weekend,
but will be digging into this problem with renewed vigor today.

You're right, Andrew, it looks like GetDiskFragment() should do the trick,
but it doesn't seem to. If I specify "kFindLib" it fails, and if I
specify "kLoadLib" it succeeds, but then the Mac crashes as soon as I
try to run the primitives. The reason is, I believe, that GetDiskFragment()
is loading a new copy of the VM, not the one loaded by Netscape.
This new copy has its own set of (uninitialized) VM state, and goes
off the deep end when it tries to use this state.

There are many ways to skin this cat. I actually spent quite a bit
of time working on the stub approach that Eric suggested (since it
is the one used with great success by the Win32 plugin), but, as
Andreas said, this turns out to be extremely difficult on the Mac,
since the Mac OS doesn't support child windows and simulating them
is more difficult that it first appears.

A reasonable approach is to merely package the named primitives
that are normally linked into the VM as an external library. This worked
until we wanted to add some named, "built-in" primitives that call back
into Netscape. This made it again desirable for the primitives live in the
same code fragement as the rest of the VM plugin, so they can call
back into Netscape directly.

Of course, we could avoid all these problems by using old-fashioned
numbered primitives for the six plugin callback primitives. But
that's not aesthetically pleasing, so it remains the recourse of
last resort.

Again, thanks for all your suggestions. I haven't yet checked out
all your leads, and with luck one of these will give me the answer.
Lawson's pointer to the Mozilla source file "macdll.c" is especially
interesting.

	-- John


Re: At 7:04 PM -0500 2/5/00, Andrew C. Greenberg wrote:
>>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.