Является ли MFC sitll доминирующей средой для настольных приложений Windows?

Question

Мне просто интересно об этом. Говорят, что .NET лучше, чем MFC во многих аспектах. Но когда я использую свой PEID для рекурсивного сканирования моего каталога «программных файлов», оказывается, что еще много программы, написанные на Visual C ++ 6 (особенно для программного обеспечения безопасности), чей графический интерфейс должен быть написан на MFC.

Итак, мои вопросы:

• Является ли МФЦ по-прежнему доминирующей структурой для рабочего стола Windows?
• Какие фреймворки используют IE, Firefox, Microsoft Office (или другие известные приложения для настольных компьютеров, если вы хотите перечислить их)?
• Какие платформы используют настольные приложения (например, проводник, карточные игры) самой Windows?

спасибо.

Answer 1

Для новых проектов я не думаю, что MFC является доминирующей платформой, но в основном потому, что новые платформы защищают разработчиков от особенностей Win32 и самого MFC и позволяют ускорить разработку. Приложения MFC развиваются дольше, но, на мой взгляд, они не имеют себе равных по быстродействию.

Я не буду отрицать, что некоторые части платформы не имеют значения в 2010 году (например, CArchive и большинство основ Doc / View); вдобавок ко всему, немного снижается доступность сторонних компонентов (в основном, GUI). FP1 / MFCNext был шагом в правильном направлении, мне очень хотелось бы узнать о новых функциональных возможностях MFC в VS 2010.

Для оптимальной интеграции с ОС imo C ++ / MFC по-прежнему является лучшим выбором из-за природы C ++ как низкоуровневой и того факта, что Win32 по-прежнему является основой Windows и что к нему проще всего обращаться в C или C ++.

Answer 2

Кстати, мне пришлось написать код для изменения разрешения экрана, и я обнаружил, что C # может обрабатывать только определение разрешения экрана, но не изменять его.

Чтобы изменить разрешение, вам пришлось сделать много Interop gobbldygook, который я пробовал, но он был слишком сложным, потому что для Win32 API было слишком много аргументов старого стиля.

Итак, вместо этого я написал быструю MFC DLL, которая напрямую обращалась к Win32 API и упаковывала все вызовы Win32 в простой API. Затем я сделал вызов взаимодействия с моим простым API в dll пользователя MFC.

Все работало нормально.

Итак, Win32 API по-прежнему не заменит. Это имеет максимальную силу, и у вас есть полный доступ к нему через MFC. Да, MFC все еще актуален, как и ATL, и прямой Win32, который я вынужден использовать время от времени.

Таким образом, вы можете выполнить 90 процентов своей работы с .NET, но вам придется укрыться под покровом нескольких вещей. Кроме того, я сделал много Qt и никогда не буду использовать его для быстрых заданий, которые являются только окнами. Qt также стал чрезмерно дорогим, если вы делаете что-то коммерческое, а также он очень раздутый. Это библиотеки занимают гигабайты.

Answer 3

Я говорю, что формы окон и WCF довольно широко распространены. C # / VB.NET хорошо укоренились в корпоративной Америке.

IE основан на COM. Офис МФЦ / СОМ. Приложения Windows обычно представляют собой собственный код для демонстрации платформы.