Is MFC sitll the dominating framework for windows desktop application?

I just wondering about this.It is said that .NET is better than MFC in a lot of aspects.But when I use my PEID to re开发者_运维问答cursive scan my 'program files' directory,it turns out there are still a lot of programs written with 'Visual C++ 6'(esp. for security software),whose GUI should be written with MFC.

So my questions are:

• Is MFC still the dominating framework for windows desktop aplication?
• What frameworks do IE,firefox,Microsoft office(or other famouse desktop applications,if you'd like to list some) use?
• What frameworks do the desktop applications(e.g. explorer,card games) of Windows itself use?

thanks.

I say windows forms and WCF are pretty widespread. C#/VB.NET are well-entrenched in corporate america.

IE is COM-based. Office is MFC/COM. Windows Apps are usually native code to demo the platform.

For new projects I don't think MFC is the dominant platform, but mostly because newer platforms shield developers from the idiosyncrasies of Win32 and MFC itself and allow for faster development. MFC applications take longer to develop but are, imo, unmatched in responsiveness.

I will not deny that some parts of the platform are irrelevant in 2010 (for example CArchive and most of the Doc/View foundation); on top of that, the dwindling availability of 3rd party components (mostly GUI) is a bit worrisome. FP1/MFCNext was a step in the right direction, I'm anxious to learn about the new MFC functionality in VS 2010.

For optimal integration with the OS, imo C++/MFC is still the best choice because of the nature of C++ as low-level and the fact that Win32 is still the foundation of Windows and that it can most easily be accessed in C or C++.

By the way, I had to write code to change screen resolution and found that C# could only handle detecting screen resolution but not changing it.

To change resolution you had to do a lot of Interop gobbldygook which I tried but was too complex because the Win32 APIs to do that had too many old style arguments.

So, instead I wrote a quick MFC DLL that accessed Win32 API directly and wrapped all the calls to Win32 in a simple API. Then I did an interop call to my simple API in an MFC User dll.

Everything worked fine.

So, there's still no substitute for Win32 API. That has the ultimate power, and you have full access to it via MFC. So, yes MFC is still relevant and so is ATL and so is direct Win32 all of which I'm forced to use from time to time.

So, you may get 90 percent of your work done with .NET, but you have to go under the covers for a few things. Also, I've done a lot of Qt, and would never use it for quick jobs that are windows only. Qt also has become prohibitively expensive if you're doing anything commercial and also it is very very bloated. It's libraries take up gigabytes.