I ported my app to VS 2005.
For the changes that I did, I don't expect it to result in a crash. But, the result is different....
The changes that i did were... add type int where it was missing...since VC 6 allowed no type to be specified.
and.... some functions like string functions which have become more secure. (just pass a new parameter... size of string u pass in)
Let me brief what i tried....
In a test machine....
I loaded a release version of the software (Previous release....with no VC 8 components).
Then i copied my exe, built with VC 8.0, to the test machine and tried to run. There was some problem with dependencies (MFC...). So i copied a bunch of VC 8 dll's to system32 folder (i alos have VC 8.0 installed on the same machine), then when i checked dependency walker... it was fine. But when i run the component it crashes.
The crash occours when my exe calls a function from a dll (some other dll... the dll is one of our components). My component is only one among a bunch of many components.
my question is.... can it (my vc 8 exe) work along with a bunch of VC 6.0 dlls and exe's........ or should i work on a release where other components are also built in VC 8.0 ??????
C++ program ran... C++ program crashed... C++ programmer quit !!
my question is.... can it (my vc 8 exe) work along with a bunch of VC 6.0 dlls and exe's
I have DLL's created with VC 5.0 that work with Visual Studio 2005, so it isn't what language or compiler that created the DLL that makes the difference -- it's what you're passing to the DLL and the DLL understanding what you are passing to it that counts.
For example, if you are calling exported DLL or EXE functions, and the function takes an MFC object (CWnd, CMenu, CString, whatever), then you must realize that these objects are different for the various versions of Visual C++, so you can't just pass them from a VC 8.0 app to a DLL created with VC 6.0 without difficulties. The same thing can be said about any class that could have changed between versions -- you just can't pass them back and forth between the app and DLL without either recompiling everything with the new compiler, or introducing another DLL that can "translate" between the incompatible types.
If on the other hand, the DLL functions just has parameters of passes int's, doubles, pointers, etc. then that DLL can be used with any version of Visual C++.
Mixing the DLL version can be a great problem esp. when you use different versions of CRT functions. But still can not be 100% sure of this as reason for your problem.
You need to at least build all components in Debug version (VC8 dll as well as VC6 dlls) and then debug them, you can use VC8 to debug VC6 project, the only thing to take care is not compile the VC6 dll's in VC8, just open them and start debugging.
I have DLL's created with VC 5.0 that work with Visual Studio 2005, so it isn't what language or compiler that created the DLL that makes the difference -- it's what you're passing to the DLL and the DLL understanding what you are passing to it that counts.
For example, if you are calling exported DLL or EXE functions, and the function takes an MFC object (CWnd, CMenu, CString, whatever), then you must realize that these objects are different for the various versions of Visual C++, so you can't just pass them from a VC 8.0 app to a DLL created with VC 6.0 without difficulties. The same thing can be said about any class that could have changed between versions -- you just can't pass them back and forth between the app and DLL without either recompiling everything with the new compiler, or introducing another DLL that can "translate" between the incompatible types.
If on the other hand, the DLL functions just has parameters of passes int's, doubles, pointers, etc. then that DLL can be used with any version of Visual C++.
Regards,
Paul McKenzie
Thanks Paul.....
Earlier I had mentioned that I am calling a function from the dll.
Below is the function. 2 parameters to it, one being a CString.
I know that CString has undergone changes in latest version of MFC.
Could that cause problems ???
The 2'nd parameter is a class whoose declaration is below.
Mixing the DLL version can be a great problem esp. when you use different versions of CRT functions. But still can not be 100% sure of this as reason for your problem.
when i run a debug version of my exe.....these are the errors that pop up.... not from my application.... unfortunately.
It looks like there is some heap corruption....
C++ program ran... C++ program crashed... C++ programmer quit !!
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.