Slashdot Mirror
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?"
Not sure if this is an issue still (from what I read it didn't seem like MS was going to change it), or even for you.
.NET 1.0/1.1 - 2.0 only.
Several months ago the beta wasn't able to compile
My last experence with VS 2005 was very poor. The IDE itself may be ok, but the real problem lies with the C++ compiler.
On a project roughly the same size as yours. Moving from VS 2003 to VS 2005 generated 400+ compiler errors and thousands of warnings. This is up from 0 errors and 0 warnings with VS 2003 and g++.
The problem is one of lockin. MS depricated ALL of the C standard library. Every strlen() is now a compile error. Best of all the only documented way to enable the old functionality (some obscure #pragma) was broken.
if 6.0 to 2003 is any indication Get ready for a lot of manual header adding. To convert, I had to create fresh ATL projects and re add all my header files because VS 2005 doesn't recognize the dsw. Kind of a pain in the ass, and, I cant really think of any benifits attained from doing it. If you're just coding w/ C/C++ id stick to 6.0. If you are trying to migrate to .net/c#, well I guess you'll have to go through this sooner or later.
Top 10 Reasons To Procrastinate
10.
Our code base is about 1M lines of C++ code + comments. We support production builds on MSVC6 and Linux (gcc 3.2) and solaris. We recently started building in .NET 2003. Apart from issues that we already confronted when porting to Linux (we had previously has some code using old iostreams, no longer supported after VC6), we had no siginificant porting issues. One issue that we have not yet solved is that link times are much worse, particularly when building against debug libraries. This is the main thing keeping us from moving to .NET for our production builds. We are hoping the situation improves with 2005, and if so may leap frog over 2003.
In my experience MS cares a lot about backwards compatibility. So if you used standard C++ code (may be with some anti-standards tweaks to get the VC++ 6.0 compiler work - it's a shitty compiler when it comes to C++ standards compliance) you should be fine. The APIs are still there, albeit some are now deprecated like the unsafe string handling functions - Your code will still compile but with warnings.
Needless to say your projects will be converted automatically.
And you might want to clean up the code of any VC6 compiler specific kludges as the VS 2005 C++ compiler is nearly perfect when it comes to C++ standards compliance.
If you are using any 3rd party libraries compiled with VC++ 6.0 you might need to get an updated version compiled for VS2005. I found it problematic mixing C++ libraries compiled by VC6 and VC7, for example.
We're using VS2005 for the development of our next gen software here at work (C# though, not C++). VS2005 offers a lot of improvements in the IDE over VS2003, which itself was a huge improvement over the VS6 IDE. Go ahead and try installing VS2005, like the parent poster said, you will likely see large gains in productivity just because of the new IDE and debugging tools available.
so things like this (which you shouldnt be doing anyway):Wont Work Anymore
Several deprecation issues but overall it was a fairly smooth transition, but for us we already suffered and bled going from VC6 to 2003.NET
--Im an oven mitt, not an engineer! (SLArbys Radio Commercial)
Our company's main product currently has around 1.9 million lines of code. I've been running the beta compiler for months, and have found excellent performance gains over our normal builds which are created with VC6. Generally, I'm seeing execution times of around 2/3 of what they were before. This is on P4's, Athlons, and AMD-64's.
I had no trouble converting my projects from VC7 to the Beta, and I presume the VC6 to Beta would work well too. There will be a ton of warnings at first about deprecated functions like strcpy, but you can easily tell the compiler to ignore those (or use the new M$ functions if that's your style).
There are tons of new features that I haven't had a chance to use yet, but am looking forward to trying (like OpenMP).
And yes, this endorsement even comes from someone who in general is VERY anti-M$.
--
Twoflower
I would love to use VS2005 as an IDE for embedded development. Unfortunately, certain things are easy with VC6 and nmake, but awkward or impossible with VS2005 and VCBuild.
I was unable to setup my cross-compiler. With VS2005 it's possible to override the rule for *.c files and specify an alternate compiler, but there is no way (in beta2) to replace the built-in rule for *.o files and use an alternate linker. VC++ "custom build rules" are insufficient because they only act upon files that appear in the project, not files that are generated as output from a previous build stage. There are some half-baked workarounds like adding "dummy" *.o files to the project, but nothing I've found reasonable.
The MSBuild system looks awesome, but VC++ 2005 only has support for the VCBuild subset. It's a lot more limiting, and something to keep in mind.
On the subject of debugging tools, does 2005 come with a profiler? I'm told 6 did. I know 2003 did not. It greatly disappointed me, because I have grown otherwise quite fond of the IDE. It has some strangeness, but is pretty decent for the most part. (One example of the strangeness is that I have to build my app as a multithreaded DLL or else I have problems. I'm sure a VC guru would spot the issue in a heartbeat, but I am thoroughly confused about it, and gave up researching the issue. It's an executable, not a DLL...)
:)
P.S. I discovered that AMD has a free profiler for download. It works great with VS.NET !
Because VC6 generates poor code for today's CPU's. Numerous issues which are generally only known to assembly language geeks or compiler writers cause the code to not work as efficiently as possible. Our rendering code under VC2005 executes on average in about 2/3 the time that it does under VC6. How much is a CPU/system upgrade going to cost you to get that kind of performance gain??? ;)
To get a rough idea of how bad it will be, download MS Visual C++ Toolkit 2003 (available for free) and recompile your code. From my limited experience with porting Visual C++ 6.0 code to Visual C++ 2003, look for lots of compiler errors. Those may be good to fix, though, since the C++ compiler seems to more closely follow the standards, and you'll be forced to make your code more standards compliant and probably more portable, too.
What a fool believes, he sees, no wise man has the power to reason away.
You can, you have to set a compiler flag for old syntax and 1.1
I work at MS, and we generally stay on top with compilers. In fact, our new security policies require all shipping code to be compiled with the 7.1 compilers, and pretty soon all code will be required to use 8.0.
/Zc:forscope- and /Zc:wchar_t- flags at first. One thing to be aware of is that some "errors" are actually warnings that are turned up to "error" status (see the /we flag). These can be changed with the /w flag or with a #pragma warning.
I'm the one who upgraded our 2-million line product from 6.0 to 7.1 and from 7.1 to 8.0. In the process, we had about 20,000 compile errors or warnings to fix. I think I was able to fix about 5,000 per week. It was a lot of work, but we actually found bugs and issues in the code. It was certainly worth the effort. Note that we don't actually use the VS IDE to build -- we use the compiler directly from the command line with makefiles.
In general, I would update to the new compiler and turn off all of the new warnings and errors until I got everything building. Then I would re-enable all of the new warnings and work on fixing them. Use the
Advantages to the new compiler:
* Better C++ Standards compliance.
* Much better code generation (your program runs faster).
* Many fixed "Internal Compiler Error" issues.
* A few fixed code generation (invalid optimization) issues.
* Many new warnings about things that deserve them.
* Much better debug information.
* Much better handling of templates.
Disadvantages to the new compiler:
* Somewhat slower compile time in some cases.
* Larger PDB (debug symbol) files.
Advantages to new C library:
* Much better C++ compliance.
* Many bugs fixed.
* Better performance.
* Many security fixes.
Disadvantages to new C library:
* Cannot expect runtime to be present on the user's system. (msvcrt.dll and mfc42.dll are already installed on most computers, but msvcr71.dll and mfc71.dll are not).
* Some porting incompatibilities.
Advantages to the new Visual Studio IDE:
* Better Intellisense.
* Support for excellent code coverage, profiling, unit test, and static analysis tools.
* Better debugging.
* Supported (VS 6.0 is 7 years old now -- all support for it is over).
Disadvantages to the new IDE:
* Uses more memory and system resources.
* Beta version has several performance issues. The final version should fix them (cross fingers).
General issues:
* You'll need to recreate your project (*.dsp) and workspace (*.dsw) files.
* Some porting will be required for MFC and ATL apps.
* You may hit one or two CRT changes.
* You may have several thousand warnings or errors. Nearly all of these can be eliminated via compiler flags or #pragmas, but you should really fix them if possible.
* Some CRT functions have been deprecated. You can add a #define to ignore this, but if you care about buffer overflows in your code, you should really take a look at using the "safe" versions.
Time flies like an arrow. Fruit flies like a banana.
Yes, you can. You just have to disable the compiler features that correspond to the function calls you don't want.
/GZ or /RTCs compiler switches. Turn off the "Runtime Checks" options.
/GX or /EH??. Turn off the "Exception Handling" options.
_RTC_CheckEsp comes from the
___CxxFrameHandler comes from
With more recent versions, you might see something about "security_cookie". For that, turn off the buffer overflow detection (/GS).
Good luck!
Time flies like an arrow. Fruit flies like a banana.
Yes. I was happy to see it come back. Great profiler with code coverage and everything.
Time flies like an arrow. Fruit flies like a banana.