Краткий обзор представленных материалов
Разработка программ зачастую напоминает священный ритуал, построенный на произнесении ряда обязательных магических заклинаний. Особенно это касается Windows приложений. Windows-заклинания позволяют вывести графическое окно, обработать поступающие сообщения. Порядок их следования предопределен священными руководствами. Часто эти руководства заменяются шпаргалкой, кратко фиксирующей основной каркас:
// Каркасное приложение Windows 95
#include <windows.h>
LRESULT CALLBACK WindowFunc(HWND, UINT, WPARAM, LPARAM);
char szWinName[] = "SimpleWin";
int WINAPI WinMain (HINSTANCE hThisInst,HINSTANCE hPrevInst, LPSTR lpszArgs,int nWinMode) {
HWND hwnd;
MSG msg;
WNDCLASS wcl;
wcl.hInstance = hThisInst;
wcl.lpszClassName = szWinName;
wcl.lpfnWndProc = WindowFunc;
wcl.style = 0;
wcl.hIcon = LoadIcon(NULL,IDI_APPLICATION);
wcl.hCursor = LoadCursor(NULL, IDC_ARROW);
wcl.lpszMenuName = NULL;
wcl.cbClsExtra = 0;
wcl.cbWndExtra = 0;
wcl.hbrBackground= (HBRUSH)GetStockObject (WHITE_BRUSH);
if ( !RegisterClass (&wcl) ) return 0;
hwnd = CreateWindow(szWinName, "Kаркас программы для Windows 95", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, HWND_DESKTOP, NULL, hThisInst, NULL);
ShowWindow(hwnd,nWinMode);
UpdateWindow(hwnd);
while (GetMessage(&msg, NULL,0,0) ) {
TranslateMessage (&msg);
DispatchMessage (&msg);
}
return msg.wParam;
}
// Оконная процедура
LRESULT CALLBACK WindowFunc(HWND hwnd,UINT message, WPARAM wParam,LPARAM lParam) {
switch (message) {
case WM_DESTROY:
PostQuitMessage (0);
break;
default:
return DefWindowProc(hwnd,message,wParam,lParam);
}
return 0;
}
Зачастую начинающие шаманы обходятся и без шпаргалок. Обратившись к волшебникам и мастерам, они получают нужный каркас и целую кучу дополнительных наворотов. Каждый из этих подходов имеет свои положительные и отрицательные стороны. И каждый из них постоянно совершенствется впитывая в себя последние достижения технологии программирования. Ряд этих подходов, как мне кажется являются достаточно интересными как для изучения, так и для практического использования.
Почему плохо использовать MFC
Как программировать и как не программировать
Библиотека классов MFC является вредной для программиста
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Программирование для Windows считается трудным. Библиотеки классов делают программирование для Windows легче. Это истина или ложь?
bool IsWinProgEasier (Method method) {
if (method == WIN_CLASS_LIBRARIES) return false;
else return true;
}
Поговорим серьезно. Если все, чего Вы хотите — это писать программы, которые являются производными от MFC или OWL, и Вы не заботитесь о непроизводительных затратах, то использование библиотек классов и мастеров приложений — это способ, которым можно идти. Но как только Вы захотите шагнуть вне этого пути, вы окажетесь перед огромными проблемами.
Позвольте привести аналогию. Представьте, что вы покупаете набор Lego блоков. Вы можете купить универсальный набор, или специализированный набор для построения пиратского судна. Если все, что Вы хотите сделать, это создать пиратское судно, то второй вариант предпочтительнее. Но если Вы вдруг попробуете попробуете сделать из него Lego автомобиль, то Вам придется преодолеть несколько проблем. В конечном счете вы придумаете нечто, похожее на автомобиль, который будет иметь забавное колесо управления, использовать якорь для торможения, а водитель будет иметь деревянную культю и черную повязку на его глазе.
После работы с этим набором "пиратского" Лего в течении некоторого времени, Вы станете специалистом в формировании почти всего того, что могло бы быть сделано из универсального комплекта. Вы усвоите разные приемы, подобно тому, как удалить заплату с глаза пирата, как закрасить череп и кости и т.д. В конечном счете вы достигнете таких высот, когда количество знания, которое вы ассимилировали относительно Пиратского набора, будет намного больше, чем базисные принципы и техника, которые вы должны были бы узнать, чтобы использовать универсальный Lego. С той вершины вы будете выбрасывать большие деньги после первых малых затрат, вкладывая капитал во все более сложные (и сложные) Пиратские наборы.
Что же Вам делать? Мой совет: накоротко урезать ваши потери, начав сейчас же изучать программирование для Windows. API Windows – не является красивой или простой вещью. Именно поэтому все эти библиотеки классов стали настолько популярными в первое время. Но если Вы хотите выращивать красивые цветы, вам необходимо будет испачкать ваши руки. Объектное программирование и Windows далеки друг от друга, но я не хочу, чтобы Вы повторно изобретали колесо. Имеются некоторые простые OO методы, которые помогут Вам инкапсулировать уродливое лицо Windows API.
Побочный эффект окажется то, что вы будете способны создавать Windows программы, которые являются достаточно малыми, чтобы быть легко загружаемыми из Интернета. Малые программы загружаются очень быстро – они не нуждаются в чем-либо, имеющемся в MFC dll библиотеках. Я спорю с любым MFC энтузиастом, что он не напишет игру "Морской бой", которая будет меньше по размеру, чем наша, и будет обладать теми же функциональным возможностям.
Давайте же начнем наш просмотр Win32 API с самой простой возможной Windows программы … Hello Windows!.
Рекомендуемая литература:[1]
Brent E. Rector, Joseph M. Newcomer. Win32 Programming. Addison-Wesley
Очень полное и детализированное представление Win32 API. Превосходные ссылки.
И имеется письмо от одного из наших посетителей, Дейва Линенберга (Dave Linenberg).
Я потратил приблизительно 20 минут, просматривая ваш сайт, и действительно наслаждался вашими взглядами на программирование — особенно относительно вздутого характера MFC. Я не мог не поделиться своими наблюдениями.
Я начал писать Windows-программы, использующие API в 1991-1992 годах (обучаясь по первой книги Петцолда)… а затем, слушая все эти разговоры об объектно ориентированном программном обеспечении, я попробовал изучать MFC. Я пролистал книгу Просиса, и проработал все упражнения. Я просмотрел пару сотен страниц исходного текста MFC, и наткнулся на большое количество неописанного наполнения. Я изучил внутреннюю организацию MFC. Я был подготовлен, чтобы действительно понять MFC…., но я этого не смог сделать. Эта библиотека вызывала довольно сильное отвращение. MFC, которая делает простые вещи, является чрезвычайно сложной. Потратив 1 год на сырой API, и на увязку его с некоторыми хорошими объектно ориентированными парадигмами, образцами и книгами по программированию на C++, таким как книги Экела (Eckel) или Майераса (Meyers), можно получить намного больше, чем пытаться заняться MFC. Каждый думает, что написание 5 строк программы в MFC или некотором каркасе, чтобы создать окно — это лучше или проще, чем изучение API. Я согласился бы с этим в том случае, если бы каркас был полностью понят – потому что те 5 строк, сцепленные в тысячи строк программы с небольшими возможностями делают намного больше, чем маломасштабные SDI/MDI книжные примеры программ.
Почему Microsoft не может инкапсулировать библиотеки для C эффективно? К чему все эти непроизводительные затраты?
Сначала я был очарован архитектурой документ/вид. Я еще не знал то, что до этого был соответствующий "образец" (pattern). А через MFC было мое первое с ним столкновение. Поскольку мои программы стали беспорядочными циклическими зависимостями, я, реализуя парадигму документ-вид, понял, что MFC ужасна. По крайней мере, в их реализации этой идеи!! Когда-либо обратите внимание, что примеры программ очень малы в книгах. Большинство книг никогда не касается того, как реализовать взаимодействия больших наборов классов. Что было бы, если бы я имел большую программу с 1000 видами, и 1000 документами, и все они находились бы во взаимосвязи. Все передавли бы сообщения. Что, если бы это была многопотчная или распределенная программа…., Какой был бы беспорядок при использовании архитектуры документ/вид, реализованной с использованием MFC. Вот такие пироги!
«Hello Windows!» в классовой обертке
Простейшая Windows программа
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Прежде, чем приступить к программированию для Windows, необходимо понять, как выполняется представленная здесь самая простая программа. Обратите внимание: это — Win32-программа. Она будет выполняться под управлением Windows 95 и Windows NT (если кто-то хочет, чтобы Вы программировали для 16-разрядной платформы, то он должен платить Вам вдвое больше!). Windows API вызовы окрашены в синий цвет, а специфические для Windows типы данных окрашены зеленым. Я буду также ставить два двоеточия перед обращениями к функциям API. В C++ это означает вызов глобальной функции и позволяет, в ряде случаев, избавиться от неоднозначности.
