Насколько ли практично с нуля создавать графические приложения под Windows NT 3.x?

[tretdm]

Windows NT 3.1, 3.5 и 3.51 - это те операционки, которые особенно были нужны разработчикам, поскольку обычная Windows с DOS была весьма капризной, чтобы делать под них любой софт.

Кооперативная многозадачность, однопоточность и общие ограничения DOS и Win16 ставили жирный крест на стабильности обычной Windows 3.x. У меня с Open Watcom IDE был неприятный опыт разработки - мало того, что на моменте сборки EXE-файла винда решила намертво зависнуть, так ещё и
сломала SYSTEM.INI вместе с файловой системой на корню.

С Microsoft Visual C++ 2.0, установленный на Windows NT 3.1, у меня особых нареканий нет, за исключением структуры проекта, сгенерированной AppWizard.

Обычно структура проекта выглядит следующим образом:

• WinDebug/WinRelease - исполняемые файлы, файлы объектов и предварительно скомпилированных заголовков, необходимы для связки библиотеки или программы;
• res - директория для размещения ресурсов программы;
• Исходники и заголовки диалогов;
• Исходники и заголовки фреймов и их активной области (если это SDI или MDI);
• Исходники и заголовки класса приложения;
• Прочий мусор, который оставляет AppWizard.

Это приводит к тому, что нет четкой иерархии - непонятно куда относить к диалогам, а куда к фреймам. Да, Microsoft в те года очень любила таким образом разбрасывать файлы налево и направо.

Ярким примером является Диспетчер файлов из Windows 3.x/NT, как на первом скриншоте. В исходниках там полная каша.

У меня только недавно пришла в голову мысль о том, что было бы неплохо написать MFC-приложение с нуля, не опираясь на бесстыжий AppWizard, и у меня даже получилось.

Вообще с такой чистой архитектурой, да еще и с поддержкой фреймворка MFC, можно будет и полноценный интернет-браузер написать, только в разы проще, чем шаблонным способом.

Приятно то, что большая часть функций MFC корректно работает даже на Visual C++ 2026 за исключением функции Enable3dControls. Она уже устарела, начиная с MFC 5.0, а вот функции из Win32 API по умолчанию задействуют аналоги из UTF-16, так что литера L перед кавычками обязательна.

В любом случае написание софта под такую древную систему 1993 года - увлекательное занятие.