Is it really worth porting from VC6 ->vc2005,2008?

Question

What are all the problem that you foresee in doing that.

Yolk

Answer 1

1. VC 6 is no longer supported by Microsoft, in any way. If something goes wrong and for whatever reason we were not able to compile, we would be completely on our own unable to get any assistance from Microsoft. It seems unlikely that something could go wrong in this way, but if the code in question is a main source of revenue then you have take things in balance.
2. It is impossible to compile 64-bit code in VC6. 32-bit programs run on 64-bit Windows -- at least for now. But if you need to take advantage of the potential speed and memory gains from creating a native 64-bit product (for example, being able to use more than 3 GB of RAM in a single process), then VC6 is out.
3. VC9 has much better Standards compliance. VC6's Standards compliance was very poor. This is actually both a reason to port and possibly a reason not to. Programmers who used VC6 got used to doing things the 'Wrong Way', and much of that code will need to be refactored to work in VC9.

A simple example of #3 above is a for loop:

for( int n = 0; n < someMax; ++n )
{
  // do stuff
}

printf("Did %d stuffs", n);

This code works in VC6 but won't in VC9. It is in fact a malformed program -- the fact that VC6 allows it is a defect in VC6.

The decision to port from VC6 to VC9 is not a slam dunk. You have to consider how difficult the project will be and balance that with any gains you get and any problems you avoid.

You should review Microsoft's lists of breaking changes when deciding if and how to undertake this project. The first list, breaking changes from VC6 to VC7, is a huge list. The others are much smaller in comparison. Which suggests that if you port from VC6 to anything, it should be at least 2005.

• Breaking Changes VC 2005 - 2008 (VC 2005 -> VC 2008)
• Breaking Changes in the Visual C++ 2005 Compiler (VC 2003 -> VC 2005)
• Breaking Changes in Visual C++ .NET 2003 (VC6 -> VC 2003)

Dykstra

Answer 2

How big of a code base are you talking about?

Porting a little program (that is mostly non-templated C++ code) should be fairly trivial.

However I once had to convert 100.000 lines of template-using code from VC6 to VC2005, and it was a nightmare week(5 days of work), the main problem was that I had to fix by hand about 30% of the problems (70% were fairly trivial and could fix them with search & replaces). But more of an issue was the fact that the old code had no test cases and no test framework, so even after I got the application to compile and not segfault, and look ok(?), I had no assurance everything it was actually working as it was supposed to be.

So actually my advice is to consider the size of the code, and the availability of tests, and also consider if the code really needs to be ported (in my case that was a Yes, but its not always the case, especially if the software will be faded out soon)

Fusee

not much template programming but have used standard containers – Yolk

Standard containers should be ok, VC6's stl implementation is basically a broken subset of VC2005, so most of the time its ok, but there might be some special "fixes" in there, from the developers, to counter the old stl container's bugs. Beware of those! – Fusee