Применение Windows API

Применение Windows API

Краткий обзор представленных материалов

Разработка программ зачастую напоминает священный ритуал, построенный на произнесении ряда обязательных магических заклинаний. Особенно это касается 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 книжные примеры программ.

1

Имеется превосходная статья Элен Ульман (Ellen Ullman), которае должна быть рекомендована для чтения каждому, кто все еще чувствует позывы к использованию MFC или OWL. Она доступно интерактивно:

Часть 1

Часть 2

или, в печатном виде, в августовском издании журнала Харпера за 1998 год. Предлагаем Вам несколько цитат:

"… В этом мире программирования, написание моего кода перемещалось с акцента на задачу, в сторону становления набором придатков к архитектуре системы, выстроенной Microsoft."

"… Для чего изучать весь сложный код, который волшебники генерируют для меня, если он и так всегда работает?"

"… Искушение никогда не знать, что лежит в основе той легкости, подобно ослабляющей пассивности телевидения. Успокаивающая пустота, когда театр темен. Как приятно ощущать себя потребителем! (подчеркнуто мной. А.Л. )"

Если вы — энтузиаст объектно-ориентированного программирования, то найдете это цитирование официальных Руководящих принципов MFC для написания расширений библиотеки классов довольно забавным.

Ограничьте использование "Private" в Ваших классах. Это необходимо, чтобы пользователи, были способны использовать разработанные Вами MFC-дружественные классы способами, которые Вы могли бы первоначально не предусмотреть. Храня большую часть методов, элементов данных, и общих операторов публично, Вы допускаете гибкость в их использовании. В MFC, даже функции, объявленные в разделе Реализации класса обычно общие (public) или защищенные (protected).