- add some test results and comments

bochs-testing/plugin-test/test5-execsymbols/README

@@ -10,3 +10,32 @@ Module1 calls operation_occurred() in module2.
 
 Module2 calls register_module() in uselib.cc the first time
 it is called.
+
+Results:
+redhat linux: works fine.
+solaris: works fine.
+macosX: works fine.
+cygwin: 
+  when building a DLL you cannot have undefined symbols at link time.
+  You have to put -no-undefined on the command line, but whether you
+  do or not, you get undefined symbol register_module when you try to
+  link module2.
+
+    test5-execsymbols/module2.cc:11: undefined reference to `register_module(char const *)'
+
+DLLs don't allow any symbols to be undefined at link time.  So you have to
+choose the order of how to build things so that each link is complete.
+For a DLL that's used as a shared library, it must be built and linked on
+its own (without the program), with symbols exported.  This link must be
+complete, so it can't depend on pieces from the program.  Then, the 
+program can be linked with the DLL, with the program reading symbols from
+the DLL.  It can't go both ways.
+
+For a plugin environment, we want the plugin to be able to call functions
+in the main code, without putting every single thing as a function pointer.
+So the main executable should be built first, with appropriate symbols 
+exported, and then the plugin can import those symbols.  The main 
+executable will find symbols in the DLL using lt_dlopen() and lt_dlsym(),
+which probably maps to LoadLibrary() and GetProcAddress().
+
+I will try this in test 6!