Why does Microsoft insist on using MFC without providing it with a truly healing upgrade?

Firstly, MFC is not originally designed for you to use for interface development. VC++/MFC is currently the most efficient C++development platform on the Windows platform, and its running efficiency is slightly lower than pure C calling the W32 API. At the same time, its development efficiency and entry threshold are basically the lowest in Windows platform development, second only to using pure C to call the W32 API. In order to achieve maximum efficiency, MFC adopts a shallow closed approach to Win32 and allows users to directly embed assembly code when necessary. Everything MS has done on the MFC system is very unfriendly to beginners, and in many places, in order to run efficiently, it has adopted many anti human design solutions. For example, in the message processing of CWnd subclasses, people’s intuitive feeling is to use virtual function overloading, which is very intuitive and easy to understand. However, the message mapping method adopted by Microsoft, to be honest, the implementation principle of this method is basically confusing for beginners. But if you really understand the logic in between, you will find that its implementation method is very clever, much more efficient than the BC++implemented with virtual functions at the same time that year, because virtual function tables are difficult to compile and optimize. In the entire MFC system, there are many similar anti human design designs, some of which are very valuable, while others, in my personal understanding, are actually just one thing, such as encapsulating the main function into the CWinAPP class. Therefore, MFC is designed in the Windows system to produce software that requires extremely high operational efficiency, such as many industrial grade embedded software on the Windows platform that compresses PC costs to the extreme, image processing software that requires real-time processing, large-scale data stream processing software, and so on. In industrial applications, using lower level CPUs not only brings procurement cost advantages, but also significant overall design cost advantages due to lower cooling requirements. At the same time, MFC is actually a shallow closed Wins2 API that allows users to directly access the underlying Windows platform, which determines that in many scenarios, you must use MFC. As for the development of interface applications, such as OFFICE, I’m sorry, this is not a scenario that MFC needs to care about and pay attention to. In this scenario, C # is much better than MFC. As for what you said about deleting the runtime of MFC, which resulted in a large number of software not working, this is too normal. Some of these software, such as OFFICE’s underlying modules, use MFC. If you delete the runtime of MFC, these software cannot run anymore, because some of Microsoft’s suggestions are like this: use MFC to do the underlying modules that care about efficiency, and use C # or similar to do the upper interface.