Which one? Win32, MFC or Windows Forms?

[[MPGH]master131]

I've been learning C++ for a week or two and I've reached the point where I need to decide which one to choose. Win32, MFC or Windows Forms. I have absolutely no idea which one to choose and I was wondering if any of you guys had any recommendations. I'm probably going to use C++ to make hacks and maybe sometimes some GUI apps if that makes it easier (which assume that I'd need to stick with Win32 mostly).

[freedompeace]

It really depends on what you want and like. Go look at the syntax and usage examples and pick whichever you prefer. None of these are "better", just preferred.

However.. even within Microsoft, very few.. in fact, almost no applications have been written using MFC - Microsoft uses almost entirely C++ with their own tailor made classes

Pretty much, the difference is managed vs native. WinForms is managed, MFC is native. If I completely had to give you a suggestion, I'd suggest WinForms. There are thousands of classes that are available to you that you'd otherwise need to write yourself, and you don't really need to worry about memory management.

Want to use a powerful third party WinForms grid control in your application? Add a WinForm. Want to handle some XML? .NET has some good classes for that. Need to do some cryptography? .NET has good classes for that too. Need to build in application security? .NET is strong in this area as well.

C++ native has none of these.

You might to read this wall of text:

Okay, so should I use MFC or WinForms?
Good question. I wish I had an easy answer, but I don't. So let me throw out some information that will hopefully at least help a few developers with the decision. If you know whether you need to go managed or native, then the answer is pretty easy today because WinForms is managed and MFC is native. However, the answer may not always be this easy, as there has been a little research done internally on the feasibility of porting MFC to .NET. While I'm on the topic, let me throw the question out there:

Q: Would MFC.NET be useful to you? What, specifically, would be the value for you? Or are you happy with the current native/managed framework dividing lines?

If you're undecided on managed vs. native frameworks, then answering the question obviously requires a deeper look. Generally speaking, I would default to a decision of WinForms unless there was a specific reason why this would not be possible. Some of these reasons might include necessity of control over performance characteristics, application startup time, working set size issues, .NET Framework runtime deployment concerns, or maybe a need for extensive OLE document support. Some reasons I would default to WinForms include the superior design time experience, my preference for working in managed code, my personal affinity for the componentized WinForms framework structure, and the availability of resources on the newer frameworks should I need help. With all of that said, it's also worth noting that while WinForms is a great windowing framework, MFC is more mature as an application framework.

As a final note here, I think the fact that all of this is so difficult to explain is because a hole has developed in our application framework story. I think the time is coming due for a new MS framework that blends the rich application features of MFC with the more modern design philosophies of WinForms or even Avalon. I personally think it would be really cool is if such a framework could also accommodate forms written in MFC, WinForms, Avalon or even straight Win32 API and tie them all into one coherent application architecture. This is just me mentally riffing, though. I know there are some framework research projects underway, but I'm haven't yet looked into the directions they're heading. At any rate, such an effort -- if we did end up going for it -- would probably be at least 18-24 or more months out.

So, what does MS use?
Almost all current Microsoft products are written in VC++. Very few use MFC. Some newer projects are being done in C# and C++/CLI.

I don't think it was ever a huge secret that MFC never caught on significantly within Microsoft. The Office apps would seem to have been the biggest candidates, but each is instead written with its own very specialized framework tailor made for the application. At any rate, that ship has sailed, and we're unlikely to see new Microsoft projects being written from the ground up in MFC.

Regarding managed code, people often ask me, "What does Office use?" After all, the Office apps represent enormous native C++ code bases, so .NET must be really ready for serious application when the Office team buys into it, right? Hard to argue with that logic.

If the Word team, or any ISV, asked me when they should use .NET I would tell them this: use it were it makes sense for you. Don't just jump into .NET and hope for the best; understand where you can get the most value from .NET and use C++/CLI to move in those directions. The .NET framework has a lot of great features that can help you build better, cooler, more reliable software, faster. However, that doesn't mean it would make sense to take a large, perfectly functional native code base and migrate it all to .NET just to say it's now managed code. What would be the value in that? Rather, if you own a substantial native C++ application today, introduce managed code where it makes sense...

Want to use a powerful third party WinForms grid control in your application? Add a WinForm. Want to handle some XML? .NET has some good classes for that. Need to do some cryptography? .NET has good classes for that too. Need to build in application security? .NET is strong in this area as well.

In the case of Office, they are introducing a new .NET-based programmability framework, and they're also using .NET for some of their server-side bits. Again, adding value with .NET where it makes sense and not rewriting working code just for the sake of rewriting.

Parts of your application may remain native code indefinitely, again mixing in managed code where there is value. For example, MS SQL Server 2005 - about as performance sensitive an application as it gets - plans to keep the core database in native code. However, they are exposing a programmability interface that opens the door to any .NET language plugging into the server.

One of the cool things about VC++ 2005 is that it's equally comfortable in native or managed and the interoperability is really smooth. As a VC++ developer, you're free to use the platform or library that solves the problem best for you.

[why06]

Excellent quote & explanation freedom. I wish to add one more thing though Windows API is a must for using MFC. MFC uses automatic code generation so while there are some classes and things to speed things up you may need to get down to the API's yourself to do somethings, and even if you do not choose this path the WinAPI is an excellent insight into how Windows works.
Also I don't think it has to be a choice like one or the other. When I first learned C++ I focused only on C++ ANSI and a little WinAPI, just enough to venture into DirectX. Now I'm going back and learning MFC and CLI.

[[MPGH]master131]

Hmm, I've learnt most of the basic C++ concepts like pointers, arrays, classes, enums, structs, overloading, etc. Mm, might think about going into DirectX. Sounds interesting...