Hi Michael,
I am not used to the restriction that MD compiled Dlls do not work together
with MDd compiled applications.
It is probably due to the use of STL data types: Normally, I use C-APIs
across Dll boundaries and only pointers not references, then, the mix of MD
and MDd or MT or MTd does not have any impact.
But I really can deal with it, now I am aware of this :-)
Even in plain C you can have problems. Those runtime DLL have internal static variables, and you turn into problem when you want to use the value from one DLL into the other one. The typical example is IO (file descriptors and FILE* objects). The runtime DLL keeps an internal table to map the file descriptors to Win32 HANDLE. If you open a file in one DLL and try to use the descriptor in the other one, you'll turn into problems (a segfault or an exception thrown), because the descriptor is unknown in the other DLL.
But I have one more question: There is a file called octaverc which in the
Octave installation directory. It seems that this must be called at startup
to set all Octave paths.
No, the octave_main function is responsible for that.
Otherwise, I get these "function 'unimplemented'
not found"- error messages when,e.g. calling a command like "plot(...);",
and also the plot environment looks a little odd.
You will have a hard time using the plotting framework without having a REPL in octave. FLTK toolkit requires to use readline, and the gnuplot toolkit requires to call the drawnow() function, which is only done automatically when using octave in interactive mode.
What kind of file is that and how can I call it using eval_string C/C++ API
such that "my own version of the Octave application" has the same look and
feel as the original installation?
So you may have another problem here.
Michael.