Что показалось неприятным
В дополнение к "плохим" свойствам Win32, многие аспекты этого интерфейса автор характеризует как "неприятные". По мнению автора, многие соглашения и приемы программирования в API Win32 выбраны не лучшим образом.
В предыдущем разделе перечислялись некоторые несогласованности, которые автор относит к плохим свойствам. Имеются и такие несогласованности, которые автор называет неприятными, например, несогласованный подход к именованию функций. Многие функции, такие как CreateFile(), именуются путем соединения глагола и существительного. Автора не беспокоит это соглашение, поскольку связанные функции рассеяны по всему руководству программиста. (Да, помогает гипертекст!) Однако в Win32 это соглашение не используется согласованным образом. Для функций RegCreateKey(), DeviceControl() и DosDateToFileTime() соглашение не соблюдается.
Во многих файлах заголовков, требуемых для построения приложений Win32, наблюдается большая свобода именования, что затрудняет программирование. Хотя некоторые подобные деффекты присутствуют и в API UNIX, в новых стандартах применяются тщательные меры, чтобы избежать этой проблемы. Имена в файлах заголовков Win32, похоже, используются случайным образом. Такие слова как IN, OUT, FAR, TRUE, FALSE, DELETE, UNALIGNED, VOID, IGNORE, INFINITIVE и MAXCHAR определены в стандартных файлах заголовков. Имена других символических констант, таких как SP_BAUD, GPRT, PST_FAX, GHND и LPTR (упомянем лишь несколько), трудно запомнить.
Многие имена функций в интерфейсе Win32 кажутся чрезмерно длинными. Это усложняет и написание, и чтение программы. Использование длинных английских имен не приносит пользу неанглоязычным программистам. Примером длинного имени функции может служить GetFileInformationByHandle(). Эту функцию можно было бы назвать GetFileInfo(), потому что в API нет никакой функции, позволяющей получить информацию о файле, кроме той, которой сообщается хендл. Из-за длинных имен и большого числа аргументов для вызова функции часто требуется несколько строк, что затрудняет поиск ошибок при чтении программы.
Автору не нравится соглашение о включении в имя переменной информации о ее типе. Например, имя структурной переменной dwProcess должно означать, что элемент Process является двойным словом. Это та информация, в которой автор не нуждается и которую не хочет помнить. Представим себе, что в будущей системе для Process потребуется 64 бита. В этом случае имя, по всей видимости, будет изменено, и придется изменять тесты программ.
Автор строго предпочитает соглашения UNIX по именованию типов с суффиксом _t, чем использование только прописных букв для имен типов. По соглашению, символические константы именуются только прописными буквами, и их использование затрудняет чтение программы.
Автору не нравится определение по крайней мере двух, а иногда и трех типов для каждого абстрактного типа. Например, в дополнение к типу идентификатора объекта SID имеется тип PSID, который означает всего-навсего SID*. Для типа FILETIME имеются два дополнительных заклинания - PFILETIME и LFILETIME.
Автор заключает статью тем, что после двух лет программирования для Win32 он находит интерфейс нескладным и трудным для использования. Ему по-прежнему часто приходится обращаться к руководству. Часто приходится писать небольшие тестовые программы, чтобы определить, что будет делать библиотечная подпрограмма в конкретных условиях. Как кажется, API UNIX гораздо проще, и благодаря U/WIN можно программировать с использованием этого интерфейса и запускать программы на системах Windows.