Принципы, лежащие в основе Window

В Windows API имеется множество как самых незаметных, так и значительных отличий от других API, таких как POSIX API, с которым знакомы программисты, работающие в UNIX и Linux. Многие системные ресурсы Windows представляются в виде объектов ядра (kernel objects), для идентификации и обращения к которым используются деск­рипторы (handles). По смыслу эти дескрипторы аналогичны дескрипторам (descriptors) файлов и идентификаторам (ID) процессов в UNIX.

Любые манипуляции с объектами ядра осуществляются только с использованием Windows API. "Лазеек" для обхода этого правила нет. Подобная ор­ганизация работы согласуется с принципами абстрагирования данных, ис­пользуемыми в объектно-ориентированном программировании, хотя сама система Windows объектно-ориентированной не является.

К объектам относятся файлы, процессы, потоки, каналы межпроцессного взаимодействия, объекты отображения файлов, события и многое другое. Объекты имеют атрибуты защиты.

Windows – богатый возможностями и гибкий интерфейс. Во-первых, одни и те же или аналогичные задачи могут решаться с помощью сразу несколь­ких функций; так, имеются вспомогательные функции (convenience func­tions), полученные объединением часто встречающихся последовательно­стей функциональных вызовов в одну функцию (к числу подобных функций принадлежит и функция CopyFile, используемая в одном из примеров далее). Во-вторых, функции часто имеют многочисленные параметры и флаги, многие из которых обычно игнорируются.

Windows предлагает многочисленные механизмы синхронизации и взаимо­действия, обеспечивающие удовлетворение самых разнообразных запросов.

Базовой единицей выполнения в Windows является поток (thread). В одном процессе (process) могут выполняться один или несколько потоков.

Для функций Windows используются длинные описательные имена. Приве­денные ниже в качестве примера имена функций иллюстрируют не только соглашения об использовании имен, но и многоликость функций Windows:

WaitForSingleObject WaitForSingleObjectEx WaitForMultipleObjects WaitNamedPipe

Существует также несколько соглашений, регулирующих порядок исполь­зования имен типов:

Имена предопределенных типов данных, необходимых API, также являются описательными, и в них должны использоваться прописные буквы. К числу наиболее распространенных относятся следующие типы данных:

BOOL (определен как 32-битовый объект, предназначенный для хране­ния одного логического значения),

HANDLE ,

DWORD (вездесущее 32-битовое целое без знака),

LPTSTR (указатель на строку, состоящую из 8- или 16-битовых символов) LPSECURITY_ATTRIBUTES.

С другими многочисленными типами данных будем знакомиться по ме­ре изложения материала.

В именах предопределенных типов указателей операция * не используется, и они отражают дополнительные отличия между указателями раз­личного типа, как, например, в случае типов LPTSTR (определен как TCHAR *) и LPCTSTR (определен как const TCHAR *). Тип TCHAR может обозначать как обычный символьный тип char, так и двухбайтовый тип wchar_t.

В отношении использования имен переменных, – по крайней мере, в про­тотипах функций, – также имеются определенные соглашения. Так, имя lpszFileName соответствует "длинному указателю на строку, завершаю­щуюся нулевым символом", которая содержит имя файла. Этот пример ил­люстрирует применение так называемой "венгерской нотации", которой мы в данной книге, как правило, не стремимся придерживаться. Точно так же, dwAccess – двойное слово (32 бита), содержащее флаги прав доступа к файлу, где "dw" означает "double word" – "двойное слово".

Наконец, несмотря на то что оригинальный API Win32 с самого начала разра­батывался как совершенно независимый интерфейс, он проектировался с учетом обеспечения обратной совместимости с API Winl6, входившим в состав Windows 3.1. Это привело к некоторым досадным с точки зрения программиста последст­виям:

· В названиях типов встречаются элементы анахронизма, как, например, в случае типов LPTSTR и LPDWORD, ссылающихся на "длинный указатель", ко­торый является простым 32- или 64-битовым указателем. Необходимость в указателях какого-либо иного типа отсутствует. Иногда составляющая "длинный" опускается, и тогда, например, типы LPVOID и PVOID являются эквивалентными.

· В имена некоторых символических констант, например WIN32_FIND_DATA, входит компонент "WIN32", хотя те же константы используются и в Win64.

· Несмотря на то что упомянутая проблема обратной совместимости в на­стоящее время потеряла свою актуальность, она оставила после себя мно­жество 16-разрядных функций, ни одна из которых, как правило, не исполь­зуется, хотя и могло бы показаться, что эти функции играют весьма важную
роль. В качестве примера можно привести функцию OpenFile, которая, су­дя по ее названию, нужна для открытия файлов, тогда как в действительно­сти для открытия существующих файлов всегда следует пользоваться толь­ко функцией CreateFile.