There is an idea on Visual Studio User Voice about open-sourcing MFC.
What do you think about it? Would it be good or bad for the development of MFC and for the MFC community?
For new C++ projects there are several options available. For example: using Qt to develop cross-platform C++ applications, or WTL for something more Windows-specific, just to name a few.
But MFC is still used in several C++legacy projects (including very large enterprise applications) still active in maintenance mode. With MFC open source, the community and Microsoft could submit new code and patches while Microsoft could monitor the quality of the submitted code and support an official branch.
My original Visual C++ 6 box (…memories from the MFC’s “Golden Days” 🙂 )
Please feel free to share your opinions on Visual Studio User Voice, or leave comments here.
Please try to develop a civilized discussion, and be courteous and kind even when you disagree.
In today’s world, there are so many programming languages to choose from when  developing software projects. So, oftentimes, this question arises: “With so many simpler and higher-level programming languages, why should I choose C++ to do X?”
Well, programming languages (and frameworks) are just tools. And my usual guidance is: use the right tool for the job. So, if for your project a simpler/more productive/higher-level programming language is well suited, then just go for it!
But, there are cases in which C++ is just The Best Tool For The Job.
A key point is that the .NET Framework/CLR is a high-impact runtime, with associated performance issues for in-proc extensions:
“Performance issues can arise with runtimes that impose a significant performance penalty when they are loaded into a process. The performance penalty can be in the form of memory usage, CPU usage, elapsed time, or even address space consumption. The CLR, JavaScript/ECMAScript, and Java are known to be high-impact runtimes. Since in-process extensions can be loaded into many processes, and are often done so at performance-sensitive moments (such as when preparing a menu to be displayed the user), high-impact runtimes can negatively impact overall responsiveness. […]”
The aforementioned MSDN documentation continues with a brief discussion of issues associated to high resource consumption as well.
Then, another paragraph about “Issues Specific to the .NET Framework” briefly touches on COM interop related problems. It’s important to keep in mind that the in-proc shell extension model was designed around native code, and there is a kind of “impedance mismatch” between that and the managed .NET world.
Note that the use of .NET is considered acceptable for other types of extensions, like out-of-process extensions.
A common type of shell extensions are the context-menu extensions.
Example of customized context-menu via shell extensions
