Migrating from MSVC 6.0 to Studio 2005?

greywar asks: "While the preferred method would be simply use Linux, unfortunately my company is using Microsoft Visual Studio 6.0 with C++. I have been asked to recomend if we should upgrade to the new upcoming visual studio 2005. Has anyone got any real life experience with moving a project of about 220,000 lines of code, 60,000 lines of comments from the old MSVC to the new Studio 2005 which is currently in Beta? What benefits are there, and what things do we lose? What problems will occur?"

Comments

Re:Why bother?

[slcdb]

Is there something wrong with MSVC 6?

Yes. Well, it's not actually anything intrinsically wrong with VC6, but Microsoft has managed to cripple it. All new Platform SDKs are now using a library format that is incompatible with VC6's linker.

So now if an application wants to take advantage of some of the newest Platform SDK functionality (e.g. stuff that's new in Vista), VC6 will likely not be able to link with the required libraries.

I doubt that there was anything that absolutely needed to be changed with regard to the library format. I'm of the opinion that this was a carefully crafted Microsoft strategy to force developers to stop using VC6 (which is the oldest Visual Studio release that still has a large number of active users).

Changing compilers is always fun . . .

[ChefAndCoder]

Interface wise, I think the Microsoft dev products are pretty good and I felt they tended to improve with each version. Guessing based on my transition from VC6 to 2003, you shouldn't have too many problems with the new look and feel.

Now, I'm assuming that you're also planning to change the compiler you use in VC6 to whatever they've got for 2005. And this is where things get fun.

At my last job, we switched compilers on two occassions. The first time was a disaster, and our QA team was flooded with defect reports - see, as we did this shortly before a major release and learned a painful lesson.

Recently, we migrated from VC6 to the VC7 compiler. We continued to compile both versions for almost a year before we finally committed to the new compiler. I think the newer compilers are better for error detection in the compilation phase, but you will have to carefully watch out for subtle bugs that don't appear simply because of how the compiler used to behave.

A couple of years ago, there was a great article in Dr. Dobbs about using multiple compilers from different vendors as a great way to help catch errors in your code as well as use safer programming practices. Our migration pain highlighted just how much this one practice could have spared us in the long run.

Re:Sloppy Programming will cause issues

[ConceptJunkie]

The problem is the compiler, not practice.

If you do a lot of loops, it makes sense to reuse the "i" variable, since it's been a standard iterator name since the days of Fortran in the 60's.

The old compiler (VC6, which I use by the way) didn't recognize variables declared in the for clause as existing only within the scope of the for loop.

So what do you do?

1. Use a different variable name for each loop. Granted sometimes this makes sense. I find myself more and more using short descriptive names anyway, but forcing yourself to use a new variable name for each loop is annoying and yet another in a list of hundreds of ways Microsoft makes you work for their tools rather than the other way around. Or worse, you put extra braces around eacf for loop. All ugly and clumsy, but then again if you've ever seen what ClassWizard does to your code or used AppStudio generated code you know that MS seems to think code needs to look like goat spew.

or

2. Do exactly what you describe, and reuse i over and over even though it's incorrect. What's worse is if you wanted to write code that would work in both versions. Either you have to go through the pointless exercises above, or some other ugly kludge, or you have to disable the proper scoping in the newer compiler. It's messy and ugly either way.

Finally, I'd be mroe than happy to consider upgrading to something newer than VC6, but none of clients have ever wanted to. They insist on staying with the tried and true, and I'm not going to argue because that's perfectly fine with me.

Re:Very poor

[Anonymous Coward]

You're coding in Visual Studio, to paraphrase: "We don't need no steenking portability!"

OT, but you might know...

[bmac]

I've been trying to build a c++ app w/ the original VS Studio .NET, and I'd really like to not link to the standard C libs at all (like libc.lib). I'd really like to just link to the main three: kernel32.lib, user32.lib and gdi32.lib. I've tried /NODEFAULTLIB but that leaves me hanging with a handful of unresolved linker refs to what appears to be auto-generated fct calls (like _RTC_CheckEsp and ___CxxFrameHandler).

Do you know if I can do a clean link to just the "main 3"?

I would really appreciate the help.

Peace & Blessings,
bmac

Re:Why is strlen "unsafe"?

[cookd]

Three issues:

1. Resources. It might slow down the system while scanning for the nul.
2. SegFault is still not a good idea.
3. Most important: The result from strlen gets used elsewhere. If the string is unterminated, you've just put a large random number into your code. Somebody else might assume that the result from strlen is a reasonable size (10-20 bytes), when it really is more like 10k, and you weren't prepared for a 10k string.

Re:Why bother?

[EvlG]

Visual Studio 2005 also includes a new feature called Profile Guided Optimization.

This feature allows you to make a special build of your program which instruments your code with performance metrics gathering code. You run your program and it automatically gathers a bunch of data. Then you rebuild the program and the compiler looks at the performance metrics and can make special optimizations targeted at your application.

I spoke with the developers about this feature and they quoted a 20-30% speedup in Yukon (the next version MS SQL Server) - for free, just by having a better compiler.

Re:VC6 doesn't work with the new "secure" libs

[slcdb]

I find your sig particularly ironic. You'd be right if you believe this line they are feeding people who ask about the incompatibility. But if you scrutinize their answer a little, you'll find that something is fishy about it. I for one, give Microsoft's story little credence :)

The /GS option basically causes the compiler to insert extra code into each compiled function. But that extra code does not need to cause a change to the library format. All it does is add additional instructions and data in the object file. You could actually write your own code that does exactly the same thing, without using the /GS compiler switch. The compiler switch makes it lot easier, because otherwise you'd have to add this code to every function you write.

But it should not change anything from the linker's perspective. It should be able to link an object file regardless of whether this extra code is present or not (and libraries are just collections of object files). From the linker's perspective, it shouldn't matter whether this extra code is generated by /GS or was written by hand by the programmer.

Sure, Microsoft may have chosen to implement the /GS switch in a way that's not backward-compatible -- but they didn't need to and if they really did care about VC6 users, they would have opted to use a backward-compatible approach.

Want proof that this can be done in a backward-compatible way? Read about StackGuard a patch created circa 1998 that brings this exact same functionality to GCC. It is available in some hardened versions of GCC. Another similar GCC patch, ProPolice is also in other hardened versions of GCC (that used by OpenBSD and Hardened Gentoo Linux, for example). Eventually, one of them will be chosen to be included as a standard feature of GCC. Both generate "protected" code that is compatible with unprotected libraries compiled with other compilers.