void *ioLoadModule(char *pluginName)
Parms:
pluginName character string, ascii
return:
void* some magic handle we will be passed later that defines this module
From: Interpreter
Why:
to load a module
Responsibility:
In order to use external plugins, versus internal plugins we must load them from some storage system. This interface works by giving you the name of the plugin "foobar" you in turn locate the "foobar" plugin somewhere according to what is acceptable on your platform and return a handle to it.
The plugin might be beside the VM, in a plugins folder by the VM, in a public library area, etc....
MacIntosh
os-9/OSXCarbon
This started life as a copy of the unix loader, but was changed to reduce the amount of loading attempts that go on because it was noticed that if you tried to load an internal plugin then why over 88 calls were made to load the plugin from 88 places or combinations of names before deciding it couldn't be loaded and to look for it internally.
The SqueakPluginsBuiltInOrLocalOnly info.plist setting when set to true makes the lookup logic only consider unix libraries or os-x bundles in the ./Plugins folder or the application (read VM) Resources folder, or as a foo.framework in the /System/Library/Frameworks/.
Otherwise we take the foo name and look for foo foolib foo.so foo.dylib foo.framework. PLus of course foo can be a unix executable, a library, a bundle, or a framework.
Cocoa:
Rewritten unix code. If you are here looking to figure out the search path, you should look at the code instead
iPhone
*Loading external plugins is not permitted according to the iPhone license*
Unix
we take the foo name and look for foo foolib foo.so foo.dylib foo.framework
Windows
Much simplier, look for foo.dll or foo32.dll in the image or VM path.
BUGS
