It's often the case that in a stand-alone EXE, the user-interface
changes input parameters in an interactive way. Without doing the
analysis, how can one be certain, if this is the case here, that some
parameters are exposed both to the user-interface and to the
computational routines as "globals"?
Of course if you think it likely that was not so much the case, then
one can proceed to throw all of the old code into a new DLL project,
label the desired routines as callable entry points, and see how it
works. Possibly one could identify and fix incrementally problems
like the above, e.g. by creating new entry points that set the values
of global variables or by writing startup code for the DLL that
assigns default values appropriately.
For multi-threaded applications such an approach is apt to prove
unsatisfactory. While separate threads have essentially their own
stacks, so that local variables and calling parameters are segregated
by thread, any global variables in the code are at risk of being
shared indiscriminantly (unless these are all read only for the
purpose of the computations needed).
best wishes, mathtalk-ga |