======**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**