# Slow Chat Archives > Slow Chat: Visual C++: Yesterday, Today, and Tomorrow >  [RESOLVED] Backward compatibility problem

## karthikoncodeguru

Hi all,
I was previously worked in Visual C++6.0. Now i am working in Visual Studion 2005. But once we changed the existing code of VC6.0 to Visual studio 2005, it is not possible to regain the code to work in VC6.0 environment. Why it so ?

Is there any Backward compatibililty problem ?

Regards,
Karthik M

----------


## Siddhartha

> I was previously worked in Visual C++6.0. Now i am working in Visual Studion 2005. But once we changed the existing code of VC6.0 to Visual studio 2005, it is not possible to regain the code to work in VC6.0 environment. Why it so ?


There are a lot of differences between MSVC 6.0 and VS 7.x+.

Depending on the nature of your project you might have had to make many changes (mostly for the better) and one or more of the following may be applicable:

* C++:*
VS 2005 compiler  is (or in general VC++ 7.x+ compilers are) a lot more C++ Standard compliant than MSVC 6.0VS 2005 will recommend the secure versions of string manipulation functions: i.e. strcpy_s instead of strcpySTL implementation with VS 2005 has many bugs prevalent in that of MSVC 6.0 corrected.VS 2005 will detect and recommend compatibility issues for 64-bit platforms as warnings - something that MSVC 6.0 doesn't.*MFC / ATL:*
CString in MSVC 6.0 is replaced by a specialization of templated version CStringT.By default, implicit conversions of strings in VS 7.x+ is turned off due to macro _ATL_CSTRING_EXPLICIT_CONSTRUCTORS (details).Presence of other specializations CStringA and CStringW not present in MSVC 6.0.Presence of helper classes like CComSafeArray that are not available with MSVC 6.0Etc...So, as you can see - many of the cases above are not backward compatible wherein code once modified to work with VS 2005 may not compile with MSVC 6.0. This is most often due to improvement in the quality of the product.

There are ways by which one can remain backward compliant - i.e. for instance continue using strcpy instead of strcpy_s by choosing to hide those security warnings using macros, but this isn't really recommended. 

Some more differences...

* Project / Workspace File Formats:*
A workspace in MSVC 6.0 is a DSW file, while that in VS 7.x+ is a solution (SLN) that can hold projects belonging to multiple programming environments (VC++, VB, etc)A C++ Project in MSVC 6.0 is a DSP file, whereas that in VS 7.x+ is a VCPROJ file.Hope this answers your question.

----------


## karthikoncodeguru

Thanks siddhartha for your elaborate reply.

But the Microsoft Team may think of binary level version control when we convert previous version of VC++ to Visual Studio 6.0 that will enable the developer to regain source atleast before the modifications with Visual Studio 2005.

Regards,
Karthik M

----------


## Siddhartha

> But the Microsoft Team may think of binary level version control when we convert *previous version of VC++ to Visual Studio 6.0* that will enable the developer to regain source atleast before the modifications with Visual Studio 2005.


I am not sure as to what this means... 

But, if you make changes to your code files / projects for sake of compatibility with VS 2005, and save it, then, the only way by which the previous code functional with MSVC 6.0 is retrievable is by recovering the previous versions of the same from your source control.

----------


## karthikoncodeguru

Sorry Siddharth, i misplaced Visual C++ 6.0 instead of Visual Studio 2005.

Thanks for you Reply,

I just suggested the Microsoft Visual C++ development team to develop Version control at compiler level not at the code level. [i.e., Compatible with VC6.0 and VS2005 atleast nothing is used from VS2005 Library but only running VC6.0 at the VS2005 Environment] 

thanks a lot !


Regards,
Karthik

----------


## Siddhartha

> I just suggested the Microsoft Visual C++ development team to develop Version control at compiler level not at the code level. [i.e., Compatible with VC6.0 and VS2005 atleast nothing is used from VS2005 Library but only running VC6.0 at the VS2005 Environment]


From the looks of it, why would one want to use VS 2005 at all if one wishes to use the same (relatively inferior) libraries and frameworks that came with MSVC 6.0?

Having said this, I must add that most of the changes that VS 2005 enforces are over-rideable via project settings and macros. So, it is possible for most of the implementation in MSVC 6.0 to be carried forward to VS 2005 with little or no change - however, this is not a good idea as the changes it recommends are desirable.

Why is backward compatibility important to you / your project?



> thanks a lot !


 You are welcome...  :Wink:

----------

