The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

VC6 to VC 2005

I've been assigned to a project written in VC6, and I've been told by the lead programmer that they don't want to upgrade to the latest version of Visual Studio because:

a) they get too many errors when they compile in VS2005, because it's too "picky"

b) there's no benefits to going to VS2005

Now, I'm not an expert in this field, but my gut tells me that VS2005 is probably giving all those errors for a reason, and that sticking with VC6 is probably restrictive in the long term because we're not getting any benefits of newer technology.

Oh, just to be clear, we're ot converting to .NET, we're just recompiling an MFC app. And this code will be in use for the next 3-5 years at least, supporting XP, Vista and anything else that comes along.

Any thoughts or pointers to places I can find more information on this would be much appreciated. I'm just looking for clarification, without having to go back to the developers and saying "But why?" over and over again like a small child.

And I'll put on my flame-retardant suit, 'cause i know how much you guys like people like me. :) But hey, at least I'm TRYING to be better informed...
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
There are two issues:

1) Changing to a different IDE may break source code.

2) Changing to a different IDE and compiler may break dependencies upon existing binary components (DLLs and the like.)

It seems like #1 is what you think the only issue is and that's the one that your developers are complaining about.

But #2 can kill you (make the applications not even run), unless you are able to obtain updated binary components.

My standard practice, as a self-managed contractor & consultant, is that I will use the "minimal technology" possible to deliver the application to the client. I am maintaining a VC6 based project and I see no need to migrate to VS2005 and create the amount of work that is required to do this.

The end product is the same and the customer doesn't benefit anyway.

What are deadlines and targets like in your group? Is there time available to do this migration in addition to doing real "new" work? Or are the developers just supposed to suck it up because they should?

It almost sounds like you are trying to manufacture unnecessary work.
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
What benefits do you think you'll be getting from said "New Technology" ?

I can list a few problems you're going to have:

1) It will take retraining time for the developers;
2) You'll have to do all the QA again, and not rely on the implicit differential QA everyone's doing. You guys already know the VC6 compiled program works well on Win2K and all the dependencies. Don't be so sure it will work flawlessly with the VC2005 executable (And ... you might have clients running NT4 or something, which makes everything more complex -- ask around).
3) You'll have to buy 2005 licenses for all the teams, and upgraded libraries and tools etc. (Boundchecker / Purify ? new version needed. Same for almost any other addin). It's not just your code that causes problem with VS2005 you know.

Granted, these are meaningless in the "grand scheme of things", and three years after the fact no one will remember they had ever happened, but during the transition everyone will be in pain for a short while.

Now, about the benefits ... what are they ? Perhaps they're worth the pain, most probably not.
Ori Berger
Saturday, April 15, 2006
 
 
Yes - Pointy Haired PM, Ori B. has pointed out an excellent additional point.

This change will percolate through ALL deliverables and activities that are associated with the product itself.

It's not just a change that your developers seem to be unhappy with - it affects many other things.

My guess is that your developers are trying to tell you these things, too, and you are not getting it like you should.

PS: Give your developers some credit for having some decent judgement. Bring them in as partners to this decision, don't simply assume that they are too low level to have good sense. They aren't simply propeller headed underlings. They have to live with the result of a decision you make here and when they say "hard to change over" this means that your entire business will probably be impacted in ways that you can't predict.
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
A lot of code that compiled flawlessly on VC6 does not compile on VC2003/2005 anymore, due to the stricter (and more standard compliant) compiler. Depending on the project, this can be a huge problem. Some things can be easily fixed, like

for (int i=0;i<10;i++)
{
  bla; 
}
int j=i;

- this doesn't compile on VC2005, but compiles on VC6.

There is other, more severe stuff that doesn't work anymore although it did on VC6 (can't give you an example here).

My suggestion is to trust the lead developer, since I'm sure he'd prefer to work with VS2005 if given the chance.
Fritz Huber Send private email
Saturday, April 15, 2006
 
 
Btw., we are in the same boat, too. I've tried to switch our product to VS2005 but gave up after not being able to resolve some really weird error-messages ...
Fritz Huber Send private email
Saturday, April 15, 2006
 
 
We have a product in a niche market with relatively few clients but they pay a lot of money per year for software upgrades and customizations.

The product is expected to keep up with modern technology and techniques. Painting ourselves into a corner is a real danger. For example, if we were unable to compile for 64-bit architecture, or if we were unable to make a Vista version, we would be screwed.

As for dependencies, that's not the problem, it's basically as I described. We're not relying on 3rd party libraries that we don't have the source of.

Are there any resources for helping migration from VC6 to VS2005? And are there really no significant improvements offered in the C++ compiler between the two versions?

Case in point, the developers are always complaining about compiler optimization bugs that introduce problems in the release build that aren't in the debug build - surely some of these compiler issues are addressed in the new versions?

I understand the "if it ain't broke" argument, but my worry is that at any moment it could be broke, and it's easier to have a plan in place to fix it than to just react to it. We could start an ongoing migration plan while things are quiet, to avert a panic situation when things are busy.
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
We just went out and got VC 2005 for our development staff after using VC6 for years and years.

A couple of thoughts...

- We left a lot of major applications in VC 6 because the 3rd party library they relied on wasn't compatible with 2005 and the vendor no longer supplies it... they want you to upgrade to the latest (and not API compatible) stuff.

- Beware CRT dependencies!!  Even my latest and greatest XP SP2 machine doesn't have the right DLLs installed on it (until you install 2005 of course...).  You need to statically link it all in... if size is an issue for you this might be a concern.

-  Finally we have working templates!

-  Finally we have a (mostly) bug-free STL.  (Yes, I know I could have handpatched it from the Dinkumware site, but when I tried that I broke other things).

- In some ways the IDE itself is a LOT nicer.

- Why the heck does it take so long to run a simple macro?  Why does it take so long for help to come up?  Why does it insist on looking everywhere but on my machine for help information?  How the @$&#38;# do you use this new help system anyway?

- Our build scripts worked by calling the IDE on the command-line.  Very helpfully Microsoft changed the name of the executable and the options it takes.  We had to change our scripts accordingly.

- You'll either have to "upgrade" the functions you're using to their safe versions, or drop a lot of defines in your project files, otherwise you'll be overwhelmed with warnings.

- New scope rules.

- New operator new rules.

If you have a big existing system, I wouldn't recommend porting it all, VC6 should be good enough.  If, on the other hand, you have a few small projects then go ahead.
Perl Solution
Saturday, April 15, 2006
 
 
Fritz has nailed it on the head, that's exactly what my guys said, only they haven't really spent any significant time on the errors, so we don't know if any can't be fixed.

As for QA, retraining and cost of new tools, they aren't a problem, we have the resources and time to deal with that.

I do listen to my developers, and never over-ride them. But in this case I get the feeling that they are kind of on-the-fence about this, and management support one way or the other might make the difference. I can get them the time they need to make the change, but maybe they're too focused on the day-to-day issues to really think about the big picture in the same way I have to.
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
It sounds like you just want to hear someone endorse your point of view.

Look: you're still going to have legacy code maintenance. Hello?! You have not moved forward.

>> maybe they're too focused on the day-to-day issues to really think about the big picture in the same way I have to.

Pretty patronizing and I was expecting that. If that's how you frame this debate, then I see no hope for you. You are truly pointy-haired.

You're talking about forward-looking initiatives - great.

Except that shoving code from a 1998 era compiler into Visual Studio 2005 is basically just repackaging, not reengineering.

Developing to new technology will be an entirely separate effort, regardless of the IDE packaging that the application is done in. Therefore, at VERY best, this move is benefit-neutral.

I can see one "benefit" to this, and it's for your programmers: they can now add "Visual Studio 2005" to their resumes. And another manager who also confuses the external packaging with the substance will hire them, thinking "new technology" exposure, while all they have done is munge existing legacy code to work around problems.
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
A couple of other points...

My developers drool over and look longingly at various improvements in the VS2005 IDE.

My developers are constantly complaining about the VC6 compiler (may be grass-is-greener syndrome, as until they compile with the new version they don't know which is better).

We have the time and resources to make the change.


Btw, this feedback is very useful, especially the case studies from people who've done it. Thanks.
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
Now that's weird. Your programmers really want to move to VS2005, they just don't want to do it with their existing code.

Seems like there's more than meets the eye here!
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
>>It sounds like you just want to hear someone endorse your point of view.

Or that I want to be reassured that my developers are correct by finding out more about the subject.

>>Pretty patronizing and I was expecting that. If that's how you frame this debate, then I see no hope for you. You are truly pointy-haired.

I was expecting this kind of reaction. I'm trying to be objective about this, it would be nice if you were too.

>>Developing to new technology will be an entirely separate effort, regardless of the IDE packaging that the application is done in. Therefore, at VERY best, this move is benefit-neutral.

Remember that this product could still be being actively developed in 5 years time - are you saying that there are no net benefits in taking advantage of improved IDEs and compilers over that period of time?
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
If they want to move but don't, then it means that there is probably a pretty good reason why they can't.

That said, there are developers (the old grumpy ones) who are stuck on "their" technology and don't want to learn anything new. If everybody except the lead programmer wants to change, then it's probably time to ask the other teammembers about their opinion.
Fritz Huber Send private email
Saturday, April 15, 2006
 
 
>>Now that's weird. Your programmers really want to move to VS2005, they just don't want to do it with their existing code.

That's perfectly understandable, it's extra work for them to make it compile that takes them away from their regular To Do list.

There's no conspiracy.
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
>>If they want to move but don't, then it means that there is probably a pretty good reason why they can't.

It's just the compile errors.
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
Looking back at my first post, I should revise point b) to "There's no major, significant, immediate improvements to be got from VS2005."
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
PHPM, I think the other posters as well as myself have covered the range of possible issues. I don't know your developers, nor you. You seem to be fair-minded.

But a statement that amounts to saying "my developers are heads down and don't see the big picture" *is* patronizing. That to me sounds like a way to intentionally discredit what they are telling you that you don't agree with.
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
PHPM, I'll be objective and entertain your point of view in just one aspect: moving to a newer and better compiler will result in your developers having to flush out and repair code that isn't standards-compliant. The example of code above that was given may not be understandable to you, but to me it indicates that VS2005 is much more rigorous about the code it will compile.

But - as a developer I view this one issue as somewhat trivial. As in: OK, if I have to use this new tool, I will repair the problems in the existing code that are indicated by it. I would be pragmatic about it. I would probably not protest to my manager based on this one issue.

So I find it hard to believe that this is the only reason your developers are protesting this move.

But, if you are right, then maybe the change *would* benefit them.
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
The above example is trivial, but if the problem is buried somewhere between your sourcecode and the MFC or ATL it can quickly become a nightmare and the conversion might be very hard. It really depends.
Fritz Huber Send private email
Saturday, April 15, 2006
 
 
>>But a statement that amounts to saying "my developers are heads down and don't see the big picture" *is* patronizing. That to me sounds like a way to intentionally discredit what they are telling you that you don't agree with.

In my defense, BB, I did say "maybe." I wasn't outright accusing anyone of anything. And I also didn't say that being focused on day-to-day issues was worse than looking at the big picture. I'm just trying to recognize everyone's perspective.

You are right that I don't agree with them, though, but I realise that it's because I don't know enough about the issues. Hence this thread.

I appreciate your objectivity, btw.

To those who have made the switch, all things considered, is your life easier now?
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
I'd say fire your developers and hire ones with a clue.  The changes in the newer VC versions break older code because of standards compliance.  Good developers should know what is and what isn't standards compliant and shouldn't be relying on non-standards compliant behavior in older versions to the extent that it's that much of a hassle to update. 

I've worked on numerous projects, some fairly large, that have been migrated from VC6 to VS2003 or VS2005 and haven't encountered any compile issues that couldn't resolved in minutes (such as the aforementioned 'for' loop change).  Some of these projects had hundreds of thousands of lines of code written under VC6.  I'd have a hard time imagining what a developer could screw up so bad to make it that hard to just compile. 

VS2005 isn't without issues but my point is that using compile errors as an excuse not to upgrade is just *bad*.  The compile errors are a *good* reason to upgrade.  Fixing these issues will make your code more standards compliant and more easily ported to other platforms (whether that's different versions of Windows or completely different systems).  Another good reason is that the VS2005 compiler produces significantly faster code than VC6.
SomeBody Send private email
Saturday, April 15, 2006
 
 
"Another good reason is that the VS2005 compiler produces significantly faster code than VC6."

Significantly faster? Sure. Noticeably faster? Don't count on it.

There are good reasons to upgrade to VS2005, but speed isn't one of them.

Visual Studio 2005 has, among other things, better help files, better context information, much better debugging capabilities, and (as mentioned) a more standards compliant compiler. But if the developers aren't using Visual Studio 2005 for other projects I can imagine they're not very excited. Porting the code from VC6 to 2005 is not very fun, and since they don't know what kind of bugs to expect they might feel they will be blamed when porting the code takes longer than they initially expected.

Also note that *most* of the improvements that come with Visual Studio 2005 are geared towards .NET, which you are not interested in.

If time and money really aren't in short supply, then by all means, go for it.

Why not get one or two people to port the current code to the new version while the rest of the team sticks to Visual Studio 6? If it doesn't work out your losses are minimal.

That's what I'd do.
Not qualified
Saturday, April 15, 2006
 
 
Most of the non-standards compliant code is from bought-in source or code not made by the current team. My developers are standards-compliant now, for the most part. So I'm not about to fire them for that. :)
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
"""  if we were unable to compile for 64-bit architecture, or if we were unable to make a Vista version, we would be screwed. """

I've been active in this industry for nearly 20 years now. I've seen CPM come and go, PCDOS/MSDOS/DRDOS replace it, a small war between the graphics shells (GEM, DesqView, Windows 2 and then 3) which was quickly won by Windows when it mattered. Then Wfw, Win32s which came around the same time as NT3.5, Win95 alongside NT4 etc etc etc.

Despite how it looks, TECHNOLOGY ISN'T A MOVING TARGET. Lack of 64-bit isn't an issue and won't be for at least a year, possibly much longer - 16 bit apps and DOS apps still work just as well as they used to (and, IIRC, InstallShield only switched to 32 bit a couple of years ago after using the same old 16 bit engine for years).

Running a CPM app is nontrivial these days, granted -- but DOS, Win16, Win32 etc. are trivial. If you believe not having a Vista or 64-bit version is going to screw you, you are either believing Microsoft propaganda too much, or already in extremely bad shape which is not going to be affected by switching to VS2005 (if I need to spell it out, it means your customers have no regard to any merit of your product, but would switch in an instant based on the a "designed for Windows Vista" logo available or not. This is not unheard of, but then, you should understand that you are already screwed).

Oh, and VS2005 by itself won't automagically produce a 64 bit verison. Most probably, you'll have to do a significant rewrite to get 64 bit working.

What I do in these circumstances is to start small, independent, not-on-the-critical-path projects with the new tool. This allows me and my team to get a better grasp of the benefits we can get from new technology (and no, that kind of info cannot be found in a review), the challenges along the way. It will often hint at the best way to get the best of all worlds -- in one case, compiling everything to DLL in one environment, and adding a small loader/wrapper in the new one. Ugly, but it game an unmatched benefit/pain ratio, and bought a lot of time to do the transition properly.
Ori Berger
Saturday, April 15, 2006
 
 
Ori: dead on. PHPM, really listen to Ori and understand the details he is enumerating. The larger point is, you first need to convince your developers that this is a good move, and if you can't, you should reconsider that it's a good idea. Secondly, the transition has to be planned and executed at the nuts and bolts technical level. Third, as Ori already pointed out, this is not a make or break product positioning decision and is relatively unimportant compared to other platform like decisions.

Can you not find even one developer with whom you can build an alliance? If not, then I must assume, objectively, that the developers simply can't communicate to you what they know about the risk factors. IOW, it really must be a bad idea.

A transition like this is best handled incrementally. Small pilot projects are used to get familiar with the new tool, then a migration of a significant bread-and-butter product is attempted.

I have never used a new tool for any billable work when I didn't have a track record with it. I think a similar criteria ought to be used for any ISV work.
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
>>If you believe not having a Vista or 64-bit version is going to screw you,

Those were just broad examples, I know we'll be able to get "something" that works on them. And I know that there's so many users of VC6 that Microsoft would be insane to break it for Vista or XP-64.

It's more the stuff that we don't know about yet that may not have legacy support for VC6-compiled applications.

I know it's easy to worry about things that MIGHT happen, and that it can paralyse you if you're not careful.

Am I right in assuming that once standards-compliance is done, we won't have this problem with VS2007, VS2008 etc.? There's no big compliance gaps left to fill like there is between VC6 and VS2005?
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
That may be it. Maybe they don't want to touch that code because they don't know it at all. They may have good reasons for it - as in very bad code - or they may prefer to spend their time working on more interesting projects. Porting and bug fixing unknown code is tedious and very random. You never know if you are fixing a problem or removing some hack that is covering a bunch of other errors.

Ask for an evaluation of that code. If your team grumbles and does not give you a straight answer (or if they say it is rubbish) then you have a problem. Specially if you are relying on it long term. I am in a team with this sort of problem and we are already losing people.
JSD Send private email
Saturday, April 15, 2006
 
 
BB, it's not an "us and them" situation, we are very open as a company, and I don't have to make alliances to "get my way." I know you desperately want it to be a Dilbert-esque situation (and I guess my handle doesn't dispel that), but it isn't. Sorry. :)

Normally, I don't second guess the developers, but in this particular case I get a feeling it's a very close call. In the same way that you can sense someone might go to a party if you give them a gentle prod, and they'll be really glad they went, but at the moment they're telling you they're tired/have nothing to wear/won't know anyone.

More case studies would be helpful, good or bad, or a guide to the issues people have faced (like Fritz's unfixable bugs - that's gold dust if it was more concrete information).
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
>> have legacy support for VC6-compiled applications.

There are no, I repeat no "cooties" lingering in VC6 applications.

Visual C++ 6.0 produces standard Win32 application programs. VC++ has had new service packs extending up through 2002. It's not a recent product but it does produce solid code.

If you shove the same code into VS2005 and tweak it so it builds and runs correctly, you will have slightly updated libraries and slightly enhanced object code, which will make no difference to anyone whatsoever. VS2005 is capable of producing .Net enabled, managed code, but this will not be used at all for this situation.
 
Any boost in performance due to a "better" compiler in VS2005 will be so unnoticeable as to not even be measurable.

And JSD also added an exceptionally good new point: the code may be badly designed, just held together with masking tape, and a big unknown. Whoever tries to port it to VS2005 may become a scapegoat.

So you THINK this is a problem of bullheaded programmers, but again, I am saying that you probably are only scatching the surface of a deeper management and code maintenance problem at your company.

IE: The idea of porting the code to VS2005 apparently sounds to them like a tar baby. Why? You need to answer THAT question, not keep looking for a strong enough reason to change over that you think will be sufficient to steamroller your programmers.
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
JSD, I think you're partly right, nobody wants to root through someone else's code if they don't have to. They don't think the code is bad (I already asked them), it's just not interesting work.

Although they wouldn't mind being able to rewrite some of it so they can avoid workarounds in future, so it wouldn't be that hard a sell to get them to look at it.

I do have confidence in my team, they are good and they are conscientious. They just don't hang around forums like this to get peer opinions. :)
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
>> BB, it's not an "us and them" situation, we are very open as a company, and I don't have to make alliances to "get my way." I know you desperately want it to be a Dilbert-esque situation (and I guess my handle doesn't dispel that), but it isn't. Sorry. :)

Heh.

You misunderstood my point completely. There are different kinds of alliances. Some are political in order to avoid being stabbed in the back. I didn't mean that kind.

The kind of alliance I am describing one where you obtain intellectual support and justification for your position from someone who is technically knowledgeable. I don't mean to the extent of making pals. I simply mean reinforcement from someone who knows the nuts and bolts who can convince their peers more effectively than you've been able to.

Yours may be a wonderful, open company but you have chosen to not reveal why you are stuck at dead center on a petty issue like this, and why nobody who understands the technical aspects supports what you want to have happen.
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
>>Any boost in performance due to a "better" compiler in VS2005 will be so unnoticeable as to not even be measurable.

This is very computationally intensive software, we feel code speed more than a lot of other software, and we really try not to use assembler code unless we absolutely have to. So even smaller compiler speed improvements may be useful. We've also had to turn off a lot of optimizations to fix release/debug differences - optimizations that should have worked - and if these optimizations have been or will be fixed in later compiler versions, that would be useful.

This discussion IS helping me keep an open mind, I'm not sold on either way yet.
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
""" Those were just broad examples, I know we'll be able to get "something" that works on them. """

Then get some concrete examples. At least two. Really.
 
""" It's more the stuff that we don't know about yet that may not have legacy support for VC6-compiled applications. """

That will become something to worry about a long time into the future -- and when it does, you'll have a better idea of what exactly it is. I can tell you right now that your app will not make the most of the Aero graphical framework available in Vista, and that it's probable you won't be able to use it from VC6 at all. So what? Unless you're maintaining a game (and you aren't) or a new Photoshop (most probably not as well), Aero is nothing more than a distraction. In the same way, you aren't using the capabilities that StarDock's "WindowBlinds" has to offer. So what? It will be long before anyone has Vista, and even longer before anyone considers an Aero-specialized interface a "must have".

I would like to remind everyone that Windows ME _did_ have features not strictly available in Win98, and that anyone that rushed to support them threw their time and money out the window.

Even if some of your users demand a Vista experience sooner than I predict, you will most probably have to support Win2K and XP users for the next 3-5 years, and the easiest way to do that is with VC6.
 
"" I know it's easy to worry about things that MIGHT happen, and that it can paralyse you if you're not careful. """

A concrete, probable scenario is essential for the discussion. What if all your users suddenly see the light and switch to MacOS or Linux?

Draw a few concrete scenarios. Have someone unrelated (outside your company, preferably with 20 or so years of experience in the software market) give some probability estimate. Then reconsider the cost / benefit of switching in light of these scenarios and their probabilities.
 
""" Am I right in assuming that once standards-compliance is done, we won't have this problem with VS2007, VS2008 etc.? There's no big compliance gaps left to fill like there is between VC6 and VS2005? """

Nope. Microsoft is pushing towards microsoftization of the language. There's no guarantee that VS2007 will require your code to be ported to C++/CLI or some other variant of the language -- on the contrary, unmanaged code (as C++ is) is already on its way to become second class citizen.

There's no C++ spec update to "close the gap" to now, but if you believed Microsoft marketing then there wasn't much of a gap back in VS2002 and VS2003 as well. At least for VS2002, there was still a huge gap.

Oh, and VS2005 is compliant, but pushes you _away_ from compliance with it's deprecating of once-standard libraries. Why do you expect VS2007 and friends to be different?

Bottom line: Do a cost / benefit analysis. The cost analysis should be easy, as all transition costs are upfront. The benefit analysis is trickier, and you should try to validate it with both an independent person and one with vested interest. If you can't weight the benefits against costs, you should postpone the resolution by at least 6 months at which time you will, perhaps, have a better perspective (with very little lost, if at all -- most probably, some gained).  If you can't do a cost / benefit analysis, well -- perhaps Peter's principle applies.
Ori Berger
Saturday, April 15, 2006
 
 
Hmm. Sounds like FFTs in software, or some kind of image processing.

My experience over my career has been that businesses tend to not do what you are proposing. Most companies don't migrate a stable product's code base to a new compiler platform unless they are doing a re-write. Most companies tend to "firewall" a certain product with its existing toolchain and stay with it. That's not exactly a "best practice" per se but is how most people deal with the issue.

If code quality is a genuine concern, you should have one of your people look into something like "PC-Lint", which is a product that performs quality checking on C and C++ source code. It looks for the sort of things that VS2005 is probably sensitive to. That would be an excellent quality assurance exercise anyway, regardless whether you port to Vs2005 or not, and would make such a port easier without needing to commit to a new tool chain.
Bored Bystander Send private email
Saturday, April 15, 2006
 
 
I just saw the "computationally intensive" bit. 64-bit may change a lot, but in this case, you should have switched to Linux 2 years ago. Win64 is still not a viable platform for anything, and will take a while to become one (driver availability and stability issues is the most pressing problem, but there are many, many others).

Switch your compiler. Intel has a VC6 compatible compiler that produces code better than VS2005 and is mostly drop-in compatible.

CodePlay has a compiler called "VectorC" which can do wonders if your code is properly structured.

From the outside, it looks like you've made a decision, and are trying to justify it, while paying lip service by saying "Haven't yet made up my mind".

In addition to doing a cost benefit analysis, you can try the following: write down a result that is most significant for you (e.g. "run in half the time") then find ways to achieve it. You'll get much more bang for the buck from that list than switching to VS2005.
Ori Berger
Saturday, April 15, 2006
 
 
>>Yours may be a wonderful, open company but you have chosen to not reveal why you are stuck at dead center on a petty issue like this, and why nobody who understands the technical aspects supports what you want to have happen.

Well, the developers haven't spent any significant time fixing the compiler errors, and I haven't asked them to. And I won't until I have a better understanding of the situation. It's not a stand off, I'm doing this research on my own. There's been a couple of informal discussions about it, and it's not a big deal. I'm trying to save the team time and effort.
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
>>Intel has a VC6 compatible compiler that produces code better than VS2005 and is mostly drop-in compatible.

How is it with AMD processors? Better, worse or the same?

>>CodePlay has a compiler called "VectorC" which can do wonders if your code is properly structured.

I'll check that out. Thanks. It's a big "if" though.

>>From the outside, it looks like you've made a decision, and are trying to justify it, while paying lip service by saying "Haven't yet made up my mind".

You don't get far in management if you don't think like that! :) But at least I'm prepared to change my mind if I can't justify it.
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
>>My experience over my career has been that businesses tend to not do what you are proposing. Most companies don't migrate a stable product's code base to a new compiler platform unless they are doing a re-write. Most companies tend to "firewall" a certain product with its existing toolchain and stay with it. That's not exactly a "best practice" per se but is how most people deal with the issue.


That's my experience too. But this compiler isn't supported any more and we do have the resources and the willpower to migrate, if there's a compelling case for it.

BB, thanks for the PC-Lint tip, we may have tried that already, I'll have to check.
Pointy Haired Project Manager
Saturday, April 15, 2006
 
 
>> Any boost in performance due to a "better" compiler in VS2005 will be so unnoticeable as to not even be measurable. <<

>> Switch your compiler. Intel has a VC6 compatible compiler that produces code better than VS2005 and is mostly drop-in compatible. <<

I'm going to guess from these statements that neither of you have actually done any serious evaluation and benchmarking of the VS2005 compiler versus VC6 or the Intel compiler.  I have.

>> Am I right in assuming that once standards-compliance is done, we won't have this problem with VS2007, VS2008 etc.? There's no big compliance gaps left to fill like there is between VC6 and VS2005? <<

VC6 came out about the same time the C++ standard was being completed.  This was a major factor in the lack of standards compliance with that compiler -- there simply wasn't a completed standard for it to comply to.  No one can predict what direction Microsoft will go in the future but it's clear looking at the C++ compiler's evolution from VC6 to VS2002 to VS2003 to VS2005 that standards compliance has improved greatly with each version and there's no reason to expect this trend to suddenly change.

Seriously, a decent developer could update the projects, fix the code, and get something running in less time than we've spent discussing it here.  Why not just assign someone a few days to get something running?  Then you'll have something to do serious comparisons with instead of trusting the judgment of a bunch of strangers on the internet.
SomeBody Send private email
Saturday, April 15, 2006
 
 
>>I'm going to guess from these statements that neither of you have actually done any serious evaluation and benchmarking of the VS2005 compiler versus VC6 or the Intel compiler.  I have.


Care to share? We actually did test the Intel compiler and the speed improvement was in the 1-2% range, based on a recompile and no specific optimization. An opinion on the VS2005 compiler would be useful.

It's true that most of the posts in this thread have been written by people who haven't actually done what I'm asking about, they're working on experience of "similar" situations or just pure gut feeling. That is the way of the internet.

But this forum is actually quite good at unearthing websites where people do actually document their experiences in this kind of thing, stuff that you can't easily find by googling. And there's no harm in asking.
Pointy Haired Project Manager
Sunday, April 16, 2006
 
 
If its not broke, dont fix it.

We upgraded. It was a tough call, but the 64bit was compelling.  BUT we upgraded on a branch. We still keep the VC6 codebase around for patching the older versions. The project files were a big pain to update. 

What have we gotten out of this?  Not much, performance changes are trvial, we profile and hand tune our code, a 1% would have been great, if it were effortless, but the changeover took a couple weeks.  The improved error messages are nice. We used to use dinkum stl, and now we use VC2005's, so I guess we are saving some money there.  We continue to use smartheap.

IDE improvments? Didnt mean much to use.

Now, our app is not going to take full advantage of the new version - multiplaform statically linked backend server, using several third party libraries, barely any windows libraries.
B
Sunday, April 16, 2006
 
 
Interesting points, B. Thanks.
Pointy Haired Project Manager
Sunday, April 16, 2006
 
 
>> It's true that most of the posts in this thread have been written by people who haven't actually done what I'm asking about, they're working on experience of "similar" situations or just pure gut feeling. That is the way of the internet.

And a manager working on pure gut feeling of "superior technology" is different how, exactly?

I once visited a prospect some years ago who had a DOS product that he needed rewritten. That experience felt a lot like this thread.

I offered the guy my direct experiences with the then-current development languages: C++, VB and Delphi. I made a recommendation of technology based upon similar work.

The guy basically challenged *everything* I said, but not in a constructive way.

It was the weaseling "show me" kind of challenge in which he didn't know about anything he was asking about, but he insisted on peppering me with what-ifs:

Him: "Yeah, but what about Clarion for Windows? I read that it's supposed to really be good."

Me: "Well, I have not used it so I don't have a personal experience with it. But it is very new and the initial reports I have read aren't positive..."

Him: "yes, but said YOU DON'T KNOW. So how can you say? What about Powerbuilder?"

Me: (groan) "Well, I DO know what works in my own hands and what I've seen work in the field. Now as for PB, I have talked to colleagues who say that it's bloated and buggy, and you really should want a small runtime footprint if you're distributing an application".

Him: "Well, you don't know that for sure either! You just said you're going on what your friends said."

It was like one of those comic vignettes of the two Star Trek losers debating a minor plot point of some TOS episode.

The ONLY way I could satisfy this dickhead would be if I claimed that I had a testing lab like Jerry Pournelle's or another magazine writer's and I spent all of my time writing test applications in various new languages. Which I didn't - I made my income actually producing retail software, which wasn't a good enough viewpoint for this guy.

Now, I suppose someone like that existed who could make my prospect at that time happy, but I doubt it.

Just as someone who gives you an anonymous opinion on the internet doesn't really know 1) your code 2) your team 3) the goals of your organization.

All they can offer is their *qualitative* (that means NOT buttressed by facts and figures) opinion.  It's all going to be handwaving until someone sits down, does the port, and reports back on the "wonderful" results.

So, good luck, chief. I'm out of this stupid debate.
Bored Bystander Send private email
Sunday, April 16, 2006
 
 
Pointy haired boss,

I actually agree with you that the development should move to VS2005:
* It provides a better IDE. It crashes less (VC98 crashed every so often) and has a nicer, easier interface to use. Albeit, it takes up a ridiculous amount of memory.
* VS2005 is not only for compiling your old VC98 code. It also does .NET/C#. Most likely you will write some .NET in the future, so it's better to get used to this IDE and use only a single IDE on your system.
* From 98-2005, that's seven years. Update if only for the sake of not running something so damn old. You probably can't buy VC98 any more. I agree with 'don't fix if it ain't broke', but you will get new employees who have never seen VC98 and don't expect them to be seeing that in a positive light.

I believe your developers may have tried VC2005 and seeing the huge amount of errors poping up and decided it wasn't for them. That is, unfortunately, a problem. Changes to STL compilation will generate tons of errors, which require substantial code change. You will also get tons of warnings about strcpy/strcat/strlen etc., which you should  really disable for a ported project. For a small/medium project, fixing these errors is a pain, but can be done within a week (my app at www.AutoUpdatePlus.com was moved in a week, but it is not a huge project). For a large project, yes, I agree, you may be stuck with VC98 due to pure compatability issues.
Simon Send private email
Sunday, April 16, 2006
 
 
>>> It's true that most of the posts in this thread have been written by people who haven't actually done what I'm asking about, they're working on experience of "similar" situations or just pure gut feeling. That is the way of the internet.

>>And a manager working on pure gut feeling of "superior technology" is different how, exactly?

BB, I was including myself in the first paragraph - if I was pointing at you I would have said "most of the replies in this thread." I have appreciated your responses, and as far as I can tell everything you have said has been correct for your experiences. I have not dismissed anything you have said out of hand. I've only clarified my situation when you have made assumptions. And I'm trying to play nice - after all, I'm asking you guys for your help, and I appreciate any and all comments given.

Having said that, there has not been enough anecdotal-based evidence presented here to swing the balance one way or the other.

Take for example this Slashdot thread: http://developers.slashdot.org/article.pl?sid=05/09/27/1653224

And in particular this post: http://developers.slashdot.org/comments.pl?sid=163570&cid=13663466

Now, taking the singled-out post at face value, I'd migrate in a heartbeat, or at least allocate some resources to trying it out.

But as my grandmother said, "Only a fool takes Slashdot posts at face value."

So to get back on target, what comments would people here have about the singled-out post?
Pointy Haired Project Manager
Monday, April 17, 2006
 
 
> Now, taking the singled-out post at face value, I'd migrate in a heartbeat, or at least allocate some resources to trying it out.

I find it quite amazing that you're single out a post that cites both advantages and disadvantages, as if it offers unequivocal support for migrate now.

For example, do you know you're developers machines have enough memory for the new IDE.

Many supposed advantages many not matter to the developers. Things like better templates never matter if the developers don't use them or have any use for them in your app. Things like "Internal Compiler Error" doesn't matter if they developer never sees them [I've compiled millions of lines in VC6, and the number of times I've seen this error could be counted on my fingers]

And apart from the advantages/disadvantages to developers, there are potential deployment issues, mentioned even in your favourite slashdot post, which you'll need to address if you do migrate.

I'm not saying you shouldn't migrate, but I do think:

(a) You may be over-estimating the benefits of migration

(b) If you are putting a lot of weight on the kinds of factors on the supposed advantages in that Slashdot post, you either are, or are dangerously close to falling for the silver bullet syndrome.  Better intellisense, better templates, a few minor bug fixes in the compiler, a few extra warnings in the compiler, etc.  is NOT going to make much, if any, difference to your developers' productivity.

(c) You seem to be dangerously close to closing your eyes to the negatives


In my opinion, the best real reason to migrate, is NOT to get increased productivity (which seems the subtext of your posts).  The reason is because it's safer, in the long-run, not to be stranded on VC6 island.  But note, this is in the long-run, so it's also probably not the most urgent project.

My gut feeling, is that the reason you are not getting buy-in from developers, is that you are using the wrong justification (it appears to them that you are arguing some variant of the silver bullet theory).
S. Tanna
Monday, April 17, 2006
 
 
>>I find it quite amazing that you're single out a post that cites both advantages and disadvantages, as if it offers unequivocal support for migrate now.

Because the advantages listed in that post far outweigh the disadvantages. In our case, anyway.

>>For example, do you know you're developers machines have enough memory for the new IDE.

Yes I do know. Yes they have.

>>Many supposed advantages many not matter to the developers.

True.

>>And apart from the advantages/disadvantages to developers, there are potential deployment issues, mentioned even in your favourite slashdot post, which you'll need to address if you do migrate.

Not a problem in our particular case.

>>(a) You may be over-estimating the benefits of migration

Which is why I'm trying to get a range of opinions from people who've done it.

>>In my opinion, the best real reason to migrate, is NOT to get increased productivity (which seems the subtext of your posts).  The reason is because it's safer, in the long-run, not to be stranded on VC6 island.  But note, this is in the long-run, so it's also probably not the most urgent project.

Like I said, we're going to be still developing this project for at least 3-5 years - developing, not just supporting. So this, to me, is a real concern. We have time to migrate now without too much disruption - in the future, we may be up against a deadline, and that would not be a good time to do it.

>>My gut feeling, is that the reason you are not getting buy-in from developers

Like I said in an earlier post, the developers haven't really spent time on this. It's not a case of trying to convince them when their minds are already made up, it's a case of working out whether it's worth giving them time to do a proper analysis of the situation.

Although in this case, I'm wondering whether it would take more time to analyse the benefits than to just make the code work in VS2005, and just have two forks which we can then test against each other for performance benefits. If it's not worse under VS2005, it's probably worth keeping the new version for the (even slight) benefits.
Pointy Haired Project Manager
Monday, April 17, 2006
 
 
If you spend time on optimizing the current code instead of migrating it to VC 2005 you'll most likely get a more significant performance improvement.

Improving performance is matter of benchmarking, finding the bottlenecks and fixing the problem. Sure, VC 2005 might accidently fix a few performance issues, but that not going to make a big impact on the performance of the software as a whole.

Note that at MS software has to be maintained for a lot longer than 3 to 5 years. So in their case a migration may have been inevitable.

There aren't really any downsides to upgrading to VS 2005, if you don't count all the time (and money) it takes to fix the problems brought to the surface by the new compiler. But *if* you're going to switch to .NET or something else in 5 years anyway, why bother?
Phil
Monday, April 17, 2006
 
 
I've upgrade a fair number of projects to VC 2005. For most of them, the upgrade was pretty smooth. One was a pain, but the code was crap.

1) I have found that many of the things newer compilers are "picky" about are indication of defects in the original program. Good quality code tended to produce fewer "picky" complaints.

2) If you choose not to move off of VC6, move towards compiling everything in the highest warning level and fixing the complaints. This doesn't have to be done all at once.

3) Bugs introduced by "optimizations", etc in newer compilers are, in my opionion, rare. It's more likely that bad code is causing the problem.

4) VC6 isn't going to be supported forever. It tends to be easier to migrate to the next step than to skip over "many" steps.

5) Using the newer version of the compiler is "only" advantageous to your employee's resumes but using current technology also means that there's more reason to stay.
somebody else
Monday, April 17, 2006
 
 
Why don't you assign a single developer to try and port the codebase to VC2005 during a week or so while the others just keep on working? That way, you can properly estimate the cost of switching to 2005, and if you're lucky, he does all the work. :-)  I think the benefits of better optimization in VC2005 will be huge, BTW.
Frederik Slijkerman
Wednesday, April 19, 2006
 
 
I been involved in two projects moving code from VC6 to VC2005. Both were large code masses, around 1000-2000 files and we spent around one man month per project just to fix bugs which either made the application not build or crash during runtime. Another half man month was spent fixing the build environment to build using VC2005 and then around a one man month extra code testing. The reason we did this was:
1. we developers demanded this since we want to use modern tools.
2. we want to start adding new modules done in C# to our unmanaged VC++ application, much easier with VC2005.
Mellowman
Thursday, April 20, 2006
 
 
Those last few comments have been very helpful.

I've decided that I'm going to allow the developers time to look into the work required to migrate - I won't force them to migrate, I'll let them make the final decision, but by giving them enough time to feel confident about the end result (whatever it is), the worst that can happen is they "waste" a couple of weeks exploring a route we won't end up taking.

But it's better to know for sure than to always be wondering - a couple of wasted weeks can be caught up over time just with improved morale (i.e. when you know you're using the right technology for the job, you work faster).

Thanks to all for your help!
Pointy Haired Project Manager
Thursday, April 20, 2006
 
 
I can't comment on moving to VC2005 specifically, but I work on a 200k lines MFC C++ app that started on VC6 and has been migrated VC6 -> VS.NET and then VS.NET -> VS.NET 2003.

As a starting point, the app built cleanly with no warnings under VC6. Migrating to VS.NET took about half a day to fix warnings (we treat all warnings as errors). Most of these warnings were due to stronger comoiler warnings. The modifications needed to fix them didn't interfere with building the code under VC6.

There was one bug that turned out to be due to a change in the size of a struct passed to a Windows API (I think this was because we didn't explicitly specify WINVER and the default changed with the new header files in VS.NET). The move to VS.NET 2003 was even smoother: less than an hour and no issues noticed so far (after a month or so).

I've never noticed a problem where debug and release builds behaved differently that was due to optimization issues. They all turned out to be either side effects from code in an ASSERT() macro or uninitialized variables behaving differently (since debug builds initialize them consistently, while release mode builds don't).


 and virtually all the required changes made the code better (none of them stopped
Stephen C. Steel Send private email
Sunday, April 23, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz