There is another way to go with the dynamic linking issue, and that is to
approach it on a middle ground.  Instead of saying "Every existing opcode
needs to be in a DLL", we could instead have a plug-in structure.  The plug-in
has a single entry in entry.c, with an arbitrary number of optional inputs and
outputs.  When the parser goes to check syntax, after it checks entry.c and
does not find a match, then it checks the plug-in registry for a match.  All
calls are then handled through the plug-in registry.  Only a few basic
functions (like print to screen) are included in the plug-in API.  If you want
to write an opcode which does more complex csound system calls, you write it
the traditional way.
	This would allow us to offload a number of the newer opcodes (like the phys.
models) into plug-ins.  You can choose to have them or not.  Adding new
plug-ins then does not require recompiling the entire source.  All of the
basic opcodes could remain in the source.
	Here is what I think would be required:

1.) A plug-in registry at startup which finds any available plug-ins.
2.) An insertion into the orc parser which checks the plug-in registry for
opcode matches.
3.) An opcode called pluginregistry, which makes the connection to the proper
piece of i, k, and/or a code.

	I have a similar system in my program GrainWave.  A plug-in is almost nothing
but the actual sound processing code.  This also means we can sidestep the
thorny issues of what can and cannot be allowed to happen inside an opcode. 
We just set a limit.  If your opcode has to do something that is not allowed
by the plug-in, then you fall back on the traditional way of adding an opcode.
-- 
Mike Berry
mikeb@nmol.com
http://www.nmol.com/users/mikeb