component crashes.....

[Vedam Shashank]

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 ??????

[cilu]

Well, if I were you, I would port all the components to VS8.

[Paul McKenzie]

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++.

Regards,

Paul McKenzie

[Krishnaa]

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.

[Vedam Shashank]

Well, if I were you, I would port all the components to VS8.

This is the only component owned by me..... the rest are being ported, but could take some time

[Vedam Shashank]

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.

void CLASS_DECLSPEC SJP_LoadXMLFile (CString XMLfile, CMarkupMSXML** pRet);

where CMarkupMSXML is....

class CMarkupMSXML  
{
public:
#ifdef MARKUP_MSXML3
	MSXMLNS::IXMLDOMDocument2Ptr m_pDOMDoc;
#else
	MSXMLNS::IXMLDOMDocumentPtr m_pDOMDoc;
#endif

	CMarkupMSXML();
	CMarkupMSXML( LPCTSTR szDoc );
	virtual ~CMarkupMSXML();

	// Navigate
	BOOL Load( LPCTSTR szFileName );
	BOOL SetDoc( LPCTSTR szDoc );
	BOOL FindElem( LPCTSTR szName=NULL );
	BOOL FindChildElem( LPCTSTR szName=NULL );
	BOOL IntoElem();
	BOOL OutOfElem();
	void ResetChildPos() { if ( m_pChild ) m_pChild.Release(); };
	void ResetPos();
	CString GetTagName() const { return x_GetTagName(m_pCurrent); };
	CString GetChildTagName() const { return x_GetTagName(m_pChild); };
	CString GetData() const { return x_GetData( m_pCurrent ); };
	CString GetChildData() const { return x_GetData(m_pChild); };
	CString GetAttrib( LPCTSTR szAttrib ) const { return x_GetAttrib( m_pCurrent, szAttrib ); };
	CString GetChildAttrib( LPCTSTR szAttrib ) const { return x_GetAttrib( m_pChild, szAttrib ); };
	CString GetAttribName( int n ) const;
	CString GetError() const { return m_csError; };

	// Create
	BOOL Save( LPCTSTR szFileName );
	CString GetDoc() const;
	BOOL AddElem( LPCTSTR szName, LPCTSTR szData=NULL );
	BOOL InsertChildElem( LPCTSTR szName, LPCTSTR szData=NULL );
	BOOL AddChildElem( LPCTSTR szName, LPCTSTR szData=NULL );
	BOOL AddAttrib( LPCTSTR szAttrib, LPCTSTR szValue );
	BOOL AddChildAttrib( LPCTSTR szAttrib, LPCTSTR szValue );
	BOOL AddAttrib( LPCTSTR szAttrib, int nValue );
	BOOL AddChildAttrib( LPCTSTR szAttrib, int nValue );
	BOOL AddChildSubDoc( LPCTSTR szSubDoc );
	BOOL InsertChildSubDoc( LPCTSTR szSubDoc );
	CString GetChildSubDoc() const;

	// Modify
	BOOL RemoveElem();
	BOOL RemoveChildElem();
	BOOL SetAttrib( LPCTSTR szAttrib, LPCTSTR szValue );
	BOOL SetChildAttrib( LPCTSTR szAttrib, LPCTSTR szValue );
	BOOL SetAttrib( LPCTSTR szAttrib, int nValue );
	BOOL SetChildAttrib( LPCTSTR szAttrib, int nValue );
	BOOL SetData( LPCTSTR szData, int nCDATA=0 ) { return x_SetData(m_pCurrent,szData,nCDATA); };
	BOOL SetChildData( LPCTSTR szData, int nCDATA=0 ) { return x_SetData(m_pChild,szData,nCDATA); };

protected:
	MSXMLNS::IXMLDOMNodePtr m_pCurrent;
	MSXMLNS::IXMLDOMNodePtr m_pChild;
	CString m_csError;

	HRESULT x_CreateInstance();
	MSXMLNS::IXMLDOMNodePtr x_FindElem( MSXMLNS::IXMLDOMNodePtr pParent, MSXMLNS::IXMLDOMNodePtr pNode, LPCTSTR szPath );
	CString x_GetTagName( MSXMLNS::IXMLDOMNodePtr pNode ) const;
	CString x_GetData( MSXMLNS::IXMLDOMNodePtr pNode ) const;
	CString x_GetAttrib( MSXMLNS::IXMLDOMNodePtr pNode, LPCTSTR szAttrib ) const;
	MSXMLNS::IXMLDOMNodePtr x_Insert( MSXMLNS::IXMLDOMNodePtr pParent, MSXMLNS::IXMLDOMNodePtr pBefore, LPCTSTR szName, LPCTSTR szData );
	MSXMLNS::IXMLDOMNodePtr x_InsertSubDoc( MSXMLNS::IXMLDOMNodePtr pParent, MSXMLNS::IXMLDOMNodePtr pBefore, LPCTSTR szSubDoc );
	BOOL x_SetAttrib( MSXMLNS::IXMLDOMNodePtr pNode, LPCTSTR szAttrib, LPCTSTR szValue );
	BOOL x_SetData( MSXMLNS::IXMLDOMNodePtr& pNode, LPCTSTR szData, int nCDATA );
};

[Vedam Shashank]

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....

[Vedam Shashank]

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....

forgot to attach the file....

here are the errors that pop up.... in sequence.......have attached it as a zip file

[Krishnaa]

when i run a debug version of my exe.....these are the errors that pop up.... not from my application.... unfortunately.

It might not be because of your logic, it's highly possible that use of diff. versions of CRT,MFC can cause such problems.

It looks like there is some heap corruption....

agree.

[Vedam Shashank]

It might not be because of your logic, it's highly possible that use of diff. versions of CRT,MFC can cause such problems.

what i meant was..... if my app had caught the error it would have been a little bit easier for to debug.....