Click here to Skip to main content
15,748,330 members
Please Sign up or sign in to vote.
5.00/5 (2 votes)
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. :)
Sergey Alexandrovich Kryukov 7-Feb-13 9:22am    
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 (UK) 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.
hairy_hats 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

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.
Share this answer
hairy_hats 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.
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,
Share this answer
Espen Harlinn 7-Feb-13 17:35pm    
Good comments up there below the question :-D
Sergey Alexandrovich Kryukov 7-Feb-13 17:55pm    
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.
Sergey Alexandrovich Kryukov 7-Feb-13 18:09pm    
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 ...
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 :)
Share this answer
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
hairy_hats 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)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900