When developing C/C++ based plugins for VMD based on shared libraries, one must be aware of a few of the details about how different platforms perform dynamic linking, and what these means in terms of organizing the internal structure of a plugin.
Beyond differences in symbol resolution and linking, Windows differs from Unix in that memory allocations performed with a DLL can end up being "owned" by that DLL, such that they must also be freed by the DLL rather than the caller. This is the case because the heap management functions used can differ between the caller and the DLL if they aren't compiled against identical C runtime library versions, compilers, etc.
A common case where portability issues with dynamic linking can crop up in VMD is when one implements a molfile_plugin for reading/writing a particular molecule file format. It is commonly the case that new plugin developers are unaware of the "global symbol namespace" behavior of Unix, and so they neglect to restrict the linkage scope of the internal functions of their plugin by adding the "static" keyword to the function declaration. The problem typically goes unnoticed for one or two versions of a plugin, until an incompatible change is made in one of the plugin's internal functions. The first time the plugin author attempts to load their new plugin version, they are mystefied when their new plugin continues behaving like the old code, despite the changes they've made to their source code. This occurs because the behavior of the linker is such that the linker remains bound to the first instance of a symbol exported by one of the plugins. If a new plugin (or new version of a plugin) is subsequently loaded, and it provides duplicate symbols that have already been bound to another shared library, these are ignored. In effect, the net result is that the newly updated internal plugin functions are ignored, and the new plugin will call the old internal functions provided by the old version of the plugin.
To prevent these sorts of portability problems with dynamic linking systems, ALL of the internal-use-only functions of a plugin MUST be declared with file scope linkage (e.g. with the "static" keyword). More specifically for molfile plugins, only the VMDPLUGIN_init(), VMDPLUGIN_register(), and VMDPLUGIN_fini() functions should be declared with external linkage, which is normally handled automatically by the VMDPLUGIN_EXTERN macro.