What is the proper approach to modern UI for Windows Desktop Apps?

Question

I have an existing app with an extensive C++ model that I would like to hook up to a nice, modern Windows 7 or 8 UI. The current (ancient) UI for our app was developed in the early Windows XP / 95/98 era using pure Win32 API. Our code is currently compiling / linking through Visual Studio 2010.

It seems there's a lot of different development API "standards" on Windows: Win32, MFC, ATL, COM and .NET. Over the past 14 years, my engineers have pretty much towed the Microsoft line: in 2001, it was "MFC is dead — we must move to ATL" (we didn't). Then ".NET will REPLACE MFC" (it doesn't appear to have).

So now we're ready to dump our old UI code. It would be nice to work with a set of standards that are solid and efficient, but also one we could create UI with quickly. Putting aside QT ( on which I've read a lot of well-argued pluses and minuses here on stackoverflow):

1) Would the modern UI development approach for Windows 7 & 8 be to use MFC or .NET?

2) For a .NET approach (assuming there's solid reasons for choosing .NET) could we use our C++ model code UNMANAGED with a .NET app?

3) Is it essential to do development in Visual Studio 2012, even if our app would not initially be design for a Metro appearance?

4) Are there any other Microsoft toolkits that should be considered for desktop app development?

Stephen

Answer 1

Look at this answer I gave back in 2011. I'd argue it still holds today; maybe even more so, given the recent shift back to C++ from Microsoft. I'm not sure how much additional support for win8 there is in MFC, but if you're not fully switching to Metro (which I imagine you won't; if you have a 'product' you'll need to support older Windows for at least, what, 5 years?), it doesn't matter all that much.

I have yet to see a .Net/WPF application that feels as 'solid' as a C++ one (yes I realize those are technically orthogonal, but really, who builds .Net UI's in C++?). I understand why people want to move away from MFC; it's not like I don't understand its negative sides. IMO, what it comes down to is: how much value do you place on rapid development? For some applications (line of business, products with a short lifespan), time to market and speed of making changes is more important than being 'solidly' engineered. For other (professional tools, systems software), creating solid software with a great user experience is more important. I have yet to be shown production software (as opposed to 'tech demos') that do that in the more 'modern' frameworks; MFC (or maybe I should say 'win api used through C++', but MFC in that respect has enough going for it for the positives to trump the negatives) applications are (still) (often) the best tool for that. IMO.

One last thing to consider though is your devs. If they've been programming MFC for 15 years, they are likely programming their careers into a corner. If you insist on continuing to use MFC, you may alienate them. You'll have to weigh the business risks in that versus the technical considerations (I'm taking from your question that you are a business owner). Feel free to contact me for followup discussion if you'd prefer to do so privately.