>Andrew,
>I guess you are right. The primitive should fail without any error
>message, and I'll modify that right now in the OS/2 VM.

I think that's the correct solution.

>In case the changeset you sent gets into the standard release image I
>will put the error message again.

I would not put the error message back again, even if the Appletalk 
stuff were purged from the system entirely,

I believe the proper semantics for failing to find a .DLL or shared 
library is for the primitive to fail silently, so that the Smlltalk 
code can decide what to do.  There are several reasons for this:

	1)  One of the excellent features of Squeak is that a plugin 
can be built and tested to run in Squeak, long before any translation 
or compilation takes place.  The typical setup for a primitive (at 
least during development) is to code something like:

	foo: aParmObject with: anotherParmObject

		<primitive:'primFoo' module: 'FooPlugin'>
		^FooPlugin
			doPrimitive: 'primFoo:with:'
			withArguments: {aParmObject. anotherParmObject}

which code will, if the first execution of a FooPlugin primitive 
call, will check to see if FooPlugin is present, and if primFoo is in 
FooPlugin.


	If unsuccessful, the primitive will "fail," executing 
FooPlugin>>doPrimitive:withArguments:, thereby simulating the plugin 
on the parameters.

	If successful, the primitive will be called.

In this way, the programmer can develop his primitive almost 
exclusively in the Squeak environment (except to the extent the 
plugin is making systems calls).

	2)  You may wish to maintain a separate machine independent 
version of the code, precisely so that the functionality can be 
present across all platforms, but speeded up (substantially) when the 
local plugin is made available.

Ideally, the Plugin (and any code that relies upon the plugin) will 
recognize and gracefully cater to the possibility that the DLL may 
not be present.  I am presently looking at various ways to build such 
bulletproofing into the plugin building system.