Click here to Skip to main content
12,951,548 members (52,960 online)
Rate this:
Please Sign up or sign in to vote.
Hi all,

I appreciate that this is rather an "it depends" type of question, but I need to convert a legacy app of 300kloc which was originally build with VC6, to use a modern UI in VS2010. It's already been updated to VS2005, but with the orignal look, and I want to update it to a tabbed UI and other "MFC Feature Pack" features.

Is it going to be easier to try and update the existing UI code in-place, or to create a new project with the features I want, reconstruct the UI, and import all the other code into it?

Both appear substantial amounts of work so I don't want to head down the wrong path and have to backtrack!

TIA. :)
Posted 7-Feb-13 3:19am
Usually the shortest path is doing it all from scratch, using your legacy code only for reference. Try it isolate UI from other layers as much as possible, it will help you next time you change UI.
Matthew Faithfull 7-Feb-13 10:07am
Agreed, especially if you're going to jump all the way to modern UI from a VC6 MFC approach. I would recreate just the new UI with empty functionality as a prototype, run it past you 'customer' whether that's the boss or an actually customer to make sure it's what is wanted and then port the functionality across.
Sadly this will probably not be easy as old MFC apps often had most of the functional code mixed up with the UI. However you do it 300kloc is going to take a long time and a lot of work.
Chris Reynolds (BNY) 7-Feb-13 10:15am
Agree with the above two posters but also bear in mind that in 5 years time someone will want it updated again so, as SA said, try to seperate business function from GUI to make it easier for the next GUI face lift. Sounds like you'll be busy for a while.
viaducting 7-Feb-13 11:03am
Thanks, guys - I thought that was probably what would be suggested! Extracting the data from the CDocument class into a standalone data structure will be a pain but it does need doing for easier future maintainability.

I will roll up my sleeves and tell them to be patient... :D
SoMad 7-Feb-13 23:29pm
BTW, I think you use the term "modern UI" in a risky way here. Many people out there will take that as "Metro look", but from reading your question, that is not what you mean.
Just my two cents.

Soren Madsen
Rate this: bad
Please Sign up or sign in to vote.

Solution 4

I have done this a number of times. I would recommend that you do a combination of rewrite and reuse. What I suggest is to identify as much of the business logic as possible and move it to non-UI DLLs that your UI code links to. Doing this in the first place is good design but this was not a strong point back in the days when VS6 was around and my experience is that you never really see a project that is perfectly split between UI and Business logic (except one case that was multi-platform). Use of unit testing can be very helpful in this.

After separating the UI and business logic, you want to rewrite the UI portion of it. If the logic is truly seperated from the UI this should now be a simple step.
viaducting 8-Feb-13 4:39am
I think that is a good idea - do a first pass to get the code better-organised and separated, and then worry about the UI afterwards.
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

I write this answer just to indicate the question is answered.

Please see all the comments to the question. I'm sure all three of us have the consensus, and many will agree. I suggest you accept the advice and… what did you say about patience? Right! But also enjoy the opportunity to create more stable, long-lasting and maintainable system.


By the way, if you are interested in cross-platform C++ UI development (it's good at least to keep an eye on it, to have an idea on the prospects), please see my recent answer:
write c/c++ visual programs (cross-platform) with which IDE and compiler?[^].

Wish you the best of luck,
Espen Harlinn 7-Feb-13 17:35pm
Good comments up there below the question :-D
Thank you, Espen.
I just remembered: As I noticed, some much time is actually wasted on the attempts to save working time! :-)
Espen Harlinn 7-Feb-13 18:02pm
Yes, a software system often goes through three stages:
1. The prototype stage, where the developer struggles to understand what he/she is supposed to do
2. The second release, when the developer thinks he/she finally got it - adding tons of feateres until the system nearly crumbles under it's own weight
3. When the developer actually understands the problem at hand - at this stage he/she should seriously consider a rewrite, and as you mentioned think of the previous work as reference material.
Good idea. By some explainable reasons, I often had to advocate importance of the prototype projects to those who though those are extra projects which only take extra time. With different degree of success, I tried to explain that they actually save time, and, importantly, help risk management.

Few ears ago, somebody asked be what is the software architecture, and I answered: "I'll better tell you what is the better architecture. The best architecture is not the one which is free from mistakes. Really good architecture is the one where fixing those mistakes is not too expensive". Risk management...

Espen Harlinn 7-Feb-13 18:21pm
I can only agree with that - I a manner of speaking: systems should be designed to fail; and when they do, provide useful diagnostics that helps pinpoint the source and the reason for the failure.

The easy part of the job is often getting the system to do what it's supposed to do under ideal circumstances ...
Matthew Faithfull 7-Feb-13 20:00pm
I agree very strongly with this. Prototypes are an essential part of development that is so often missed out. I worked in one job where prototypes were banned by the senior developers. It was a very good day when I resigned.
I can understand what did you feel.
Thank you for the note.
SoMad 7-Feb-13 22:08pm
Agree. However, there is always the danger that the prototype you put in front of people suddenly becomes the actual product. If you just kind of mocked up the prototype, that is not what you want. Way back when, I would code prototypes up using Delphi and since the language of choice was Visual C++, there was no chance of my (extreme RAD :)) code becoming part of the actual source base.

Soren Madsen
Тhis problem of work perception is a social problem, related to illiteracy, organizational anti-patterns and the like. It's very important to overcome such problems, not hide them. It's too much of a common place them a knowledgeable and experienced people leave themselves submissive to morons, but part of the responsibilities is on those knowledgeable people who don't understand importance of standing for right views.

For example, I can imagine the views of the one who voted 1 for this answer... :-)
By the way, Delphi is a wonderful system, an ancestor of .NET which misses some of the advanced features of Delphi (but of course, having a great number of fundamental benefits). It was a great mistake of many who perceived Delphi as just a RAD or database client tool. Delphi is a powerful fully functional universal system and language.
SoMad 7-Feb-13 22:33pm
:-) It was not me. I did not vote yet. Here you go.

Soren Madsen
SoMad 7-Feb-13 22:39pm
I liked Delphi too. The way components were handled and could easily be added to the IDE was great. I only got to use it for my own little personal projects, but I think I still have the links to the best sites with free Delphi components :).

Soren Madsen
I did not mean that, but thank you very much :-)
SoMad 7-Feb-13 23:20pm
These days I don't have a lot of time to view, vote and comment on all the answers you guys post, so when I find myself here, I really should put in the effort and click on the star thingy :).

Soren Madsen
michaelmel 7-Feb-13 23:57pm
It was actually me - I gave you one because I thought it was a bad answer. Doesn't necessarily make me a moron and doesn't necessarily make my views any less accurate than yours. Imagine all you like.
Well, just interesting to know you motivation. :-)
michaelmel 8-Feb-13 0:29am
1) You can read my answer regarding what I think in regards to the actual technical situation. On the balance of probabilities and the information provided, I would be very wary of doing medium level surgery on 300k loc project (presumable stable) for the sake of user interface update
2) I do not do appreciate software philosophy and/or lecturing, in cyberspace or a real work environment
3) I do not see the point of cross-referencing the solution to totally unrelated answers (what does it have to do with cross-platform development), even if they are very fresh in your memory because you have just written them.

I have often given 5s to many posters including yourself by the way when I think the answer is a) correct b) addresses the question
viaducting 8-Feb-13 11:00am
One of the big problems with moving data out of the existing CDocument into its own separate structure is file compatibility - MFC Serialization makes it tricky to make large-scale changes or move classes into namespaces etc.
That's why I did not even played with the idea of using MFC Serialization. I developed my own serialization system, which is unfortunately well beyond the topic...
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

I reckon it is totally nuts to rewrite/rearrange 300,000 lines of code just because the UI is a bit dated.

Also, you should consider the effort required to make sure that you haven't broken the actual (non-UI) functionality. Clearly, more changes - more risk - more testing.

Open the old project in VS2010, make sure it compiles (not trivial as the C++ compiler has been made a lot more compliant and hence stricter), and then start fiddling with some UI elements.

Start from the most obvious, ancient things first and work your way up from there.

True colour icons (like in the toolbar) as opposed to crummy 16 colours will be a nice first step and sometimes provide a step change as to how the application is perceived. Get feedbak from supervisors and users. Then take it step by step.

I can just see software purists coming out at me with all guns blazing :)
Espen Harlinn 7-Feb-13 18:44pm
>> I can just see software purists coming out at me with all guns blazing
Ready, aim, fire! ;)
Matthew Faithfull 7-Feb-13 20:05pm
My bazooka is loaded but it depends on the situation. When I handed over ~300KLOC to my replacement after nearly 4 years in my first job I suggested he do exactly as you've suggested. That was because he had 2 weeks in the job and all his previous experiece wasa in Delphi, the product worked and was ahead of its time it just needed maintainence and keeping up with the latest UI tends. I think viaducting has more experience, better knowledge of the codebase and probably a deadline to produce a complete Modern UI product so I would not agree with you in this case. Now were did I put that rocket prope...
SoMad 7-Feb-13 23:11pm
I had to do something similar, except our code base was closer to 1 million lines of code (+35 libraries, +80 DLLs interfacing to 3rd party devices [IP Cameras, ATMs, Cash Registers, Smart Safes, etc.], +10 client applications, 8 Windows services and countless utility, test and demo projects). We just did not have the resources to redo the whole thing.

It actually did not take that long to convert all projects from VC6 to VS2010, get it to build (I think only one or two simple library projects built without errors the first time!), run basic tests and add the new stuff to our source control. As I recall that process took less than two weeks.

Like you pointed out, it is the non-UI bugs that take the longest to identify and weed out. As an example, the functionality of atoi() has changed. We (mis-)used it many places for handling ULONGs (like in XML serialization - ULONG ulFlags = (ULONG)atoi(strFlags)), but if you pass a string representing a ULONG value greater than INT_MAX to the "new version" in the same way, it returns INT_MAX (or is it INT_MIN, I forget) and you have some digging to do. I know we were at fault for doing it this way, but it just worked and was a pretty short form.
Anyway, that was just a little tip from me.

I support the views of Sergey, Espen and Matthew (and others for sure), but sometimes it is just not possible and you have to go down a path that will take a very long time to complete, but in the meantime you still have a product that is evolving and can make money for the company.

Soren Madsen
viaducting 8-Feb-13 4:16am
I don't think anyone was suggesting rewriting the entire code base.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

    Print Answers RSS
Top Experts
Last 24hrsThis month
OriginalGriff 6,084
CHill60 3,480
Maciej Los 3,083
Jochen Arndt 1,975
ppolymorphe 1,830

Advertise | Privacy | Mobile
Web01 | 2.8.170525.1 | Last Updated 7 Feb 2013
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100