• Главная
• В избранное
• Наш E-MAIL
• Добавить материал
• Нашёл ошибку
• Вниз

Нередко самыми первыми средствами операционной системы (ОС), с которыми разработчик сталкивается в любой системе, являются файловая система и простой терминальный ввод/вывод. Ранние ОС для PC, такие как MS-DOS, не могли дать ничего больше, кроме возможностей работы с файлами и терминального (или консольного) ввода/вывода, но эти же ресурсы и сейчас занимают центральное место почти в любой ОС.

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

На примере программ копирования файлов, которые рассматривались в главе 1, вы уже познакомились с четырьмя важными функциями, обеспечивающими последовательную обработку файлов:

CreateFile

ReadFile

WriteFile

CloseHandle

В данной главе не только подробно описываются эти и родственные им функции, но и обсуждаются функции, предназначенные для обработки символов и обеспечения консольного ввода/вывода. Сначала будут кратко охарактеризованы существующие типы файловых систем и их основные свойства. Далее будет показано, каким образом введение расширенной формы символов в кодировке Unicode помогает приложениям справиться с проблемой поддержки национальных языков. Главу завершает введение в управление файлами и каталогами в Windows.

Windows поддерживает на непосредственно подключенных устройствах файловые системы четырех типов, но только первый из них будет иметь для нас существенное значение на протяжении всей книги, поскольку именно полнофункциональная файловая система этого типа рекомендуется компанией Microsoft для использования в качестве основной:

1. Файловая система NT (NTFS) — современная файловая система, которая поддерживает длинные имена файлов, а также безопасность, устойчивость к сбоям, шифрование, сжатие, расширенные атрибуты, и позволяет работать с очень большими файлами и объемами данных. Заметьте, что на гибких дисках (флоппи-дисках, или дискетах) система NTFS использоваться не может; не поддерживается она и системами Windows 9x.

2. Файловые системы FAT и FAT32 (от File Allocation Table — таблица размещения файлов) происходят от 16-разрядной файловой системы (FAT16), первоначально использовавшейся в MS-DOS и Windows 3.1. FAT32 впервые была введена в Windows 98 для поддержки жестких дисков большого объема и других усовершенствованных возможностей; далее под термином FAT мы будем подразумевать любую из вышеуказанных версий. FAT является единственно доступной файловой системой для дисков (но не компакт-дисков), работающих под управлением Windows 9x, а также гибких дисков. Разновидностью FAT является TFAT — ориентированная на поддержку механизма транзакций версия, используемая в Windows СЕ. Постепенно FAT выходит из употребления и в большинстве случаев ее можно встретить лишь на устаревших системах, особенно тех, обновление которых после первоначальной установки на них Windows 9x выполнялось без преобразования типа существующей файловой системы.

3. Файловая система компакт-дисков (CDFS), как говорит само ее название, предназначена для доступа к информации, записанной на компакт-дисках. CDFS удовлетворяет требованиям стандарта ISO 9660.

4. Универсальный дисковый формат (Universal Disk Format, UDF) поддерживает диски DVD и, в конечном итоге, должен полностью вытеснить систему CDFS. Поддержка UDF в Windows XP поддерживает как чтение, так и запись файлов, тогда как в Windows 2000 для UDF обеспечивается только запись.

Windows поддерживает, причем как на стороне клиента, так и на стороне сервера, такие распределенные файловые системы, как Networked File System (Сетевая файловая система), или NFS, и Common Internet File System (Общая межсетевая файловая система), или CIFS; на серверах обычно используют NTFS. В Windows 2000 и Windows Server 2003 обеспечивается широкая поддержка сетевых хранилищ данных (Storage Area Networks, SAN) и таких развивающихся технологий хранения данных, как IP-хранилища. Кроме того, Windows дает возможность разрабатывать пользовательские файловые системы, которые поддерживают тот же API доступа к файлам, что и API, рассматриваемый в этой и следующей главах.

Доступ к файловым системам любого типа осуществляется одинаковым образом, иногда с некоторыми ограничениями. Например, поддержка защиты файлов обеспечивается только в NTFS. В необходимых случаях мы будем обращать ваше внимание на особенности, присущие только NTFS, но в этой книге, как правило, будет предполагаться использование именно этой системы.

Формат файловой системы (FAT, NTFS или пользовательской), будь то для диска в целом, или для его разделов, определяется во время разбивки диска на разделы.

Windows поддерживает обычную иерархическую систему имен файлов, соглашения которой, однако, несколько отличаются от соглашений, привычных для пользователей UNIX, и основаны на следующих правилах:

• Полное имя файла на диске, содержащее путь доступа к нему, начинается с указания буквенного имени диска, например, А: или С:. Обычно буквы А: и В: относятся к флоппи-дисководам, а С:, D: и так далее — к жестким дискам и приводам компакт-дисков. Последующие буквы алфавита, например, Н: или K:, обычно соответствуют сетевым дискам. Примечание. Буквенные обозначения дисков не поддерживаются в Windows СЕ.

• Существует и другой возможный вариант задания полного пути доступа — использование универсальной кодировки имен (Universal Naming Code, UNC), в соответствии с которой указание пути начинается с глобального корневого каталога, обозначаемого двумя символами обратной косой черты (\\), с последующим указанием имени сервера и имени разделяемого ресурса (share name) для определения местоположения ресурса на файловом сервере сети. Таким образом, первая часть полного пути доступа в данном случае будет иметь вид: \\servername\sharename.

• При указании полного пути доступа в качестве разделителя обычно используется символ обратной косой черты (\), но в параметрах API для этой цели можно воспользоваться также символом прямой косой черты (/), как это принято в С.

• В именах каталогов и файлов не должны встречаться символы ASCII, численные значения которых попадают в интервал 1-31, а также любой из перечисленных ниже символов:

< > : " | ? * \ /

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

• Строчные и прописные буквы в именах каталогов и файлов не различаются, то есть имена не чувствительны к регистру (case-insensitive), но в то же время они запоминают регистр (case-retaining); другими словами, если файл был создан с именем MyFile, то это же имя будет использоваться и при его отображении, хотя, например, для доступа к файлу может быть использовано также имя myFILE.

• Длина имени каталога и файла не должна превышать 255 символов, а длина полного пути доступа ограничивается значением параметра МАХ_РАТН (текущим значением которого является 256).

• Для отделения имени файла от расширения используется символ точки (.), причем расширения имен (как правило, два или три символа, находящиеся справа от самой последней точки, входящей в имя файла) обозначают предположительные типы файлов в соответствии с определенными соглашениями. Так, можно ожидать, что файл atou.EXE — это исполняемый файл, а файл atou.С — файл с исходным текстом программы на языке С. Допускается использование в именах файлов нескольких символов точки.

• Одиночный символ точки (.) и два символа точки (..), используемые в качестве имен каталогов, обозначают, соответственно, текущий каталог и его родительский каталог.

После этого вступления мы можем продолжить изучение функций Windows, начатое в главе 1.

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

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

Простейшее использование функции CreateFile иллюстрирует приведенный в главе 1 пример ознакомительной Windows-программы (программа 1.2), содержащей два вызова функций, в которых для параметров dwShareMode, lpSecurityAttributes и hTemplateFile были использованы значения по умолчанию. Параметр dwAccess может принимать значения GENERIC_READ и GENERIC_WRITE.

HANDLE CreateFile(LPCTSTR lpName, DWORD dwAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreate, DWORD dwAttrsAndFlags, HANDLE hTemplateFile)

Возвращаемое значение: в случае успешного выполнения — дескриптор открытого файла (типа HANDLE), иначе — INVALID_HANDLE_VALUE.

Имена параметров иллюстрируют некоторые соглашения Windows. Префикс dw используется в именах параметров типа DWORD (32-битовые целые без знака), в которых могут храниться флаги или числовые значения, например счетчики, тогда как префикс lpsz (длинный указатель на строку, завершающуюся нулем), или в упрощенной форме — lр, используется для строк, содержащих пути доступа, либо иных строковых значений, хотя документация Microsoft в этом отношении не всегда последовательна. В некоторых случаях для правильного определения типа данных вам придется обратиться к здравому смыслу или внимательно прочесть документацию.

lpName — указатель на строку с завершающим нулевым символом, содержащую имя файла, канала или любого другого именованного объекта, который необходимо открыть или создать. Допустимое количество символов при указании путей доступа обычно ограничивается значением МАХ_РАТН (260), однако в Windows NT это ограничение можно обойти, поместив перед именем префикс \\?\, что обеспечивает возможность использования очень длинных имен (с числом символов вплоть до 32 К). Сам префикс в имя не входит. О типе данных LPCTSTR говорится в одном из последующих разделов, а пока вам будет достаточно знать, что он относится к строковым данным.

dwAccess — определяет тип доступа к файлу — чтение или запись, что соответственно указывается флагами GENERIC_READ и GENERIC_WRITE. Ввиду отсутствия флаговых значений READ и WRITE использование префикса GENERIC_ может показаться излишним, однако он необходим для совместимости с именами макросов, определенных в заголовочном файле Windows WINNT.H. Вы еще неоднократно столкнетесь с именами, которые кажутся длиннее, чем необходимо. 

Указанные значения можно объединять операцией поразрядного "или" (|), и тогда для получения доступа к файлу как по чтению, так и по записи, следует воспользоваться таким выражением:

GENERIC_READ | GENERIC_WRITE

dwShareMode — может объединять с помощью операции поразрядного "или" следующие значения:

• 0 — запрещает разделение (совместное использование) файла. Более того, открытие второго дескриптора для данного файла запрещено даже в рамках одного и того же вызывающего процесса.

• FILE_SHARE_READ — другим процессам, включая и тот, который осуществил данный вызов функции, разрешается открывать этот файл для параллельного доступа по чтению.

• FILE_SHARE_WRITE — разрешает параллельную запись в файл.

Используя блокирование файла или иные механизмы, программист должен самостоятельно позаботиться об обработке ситуаций, в которых осуществляются одновременно несколько попыток записи в одно и то же место в файле. Более подробно этот вопрос рассматривается в главе 3.

lpSecurityAttributes — указывает на структуру SECURITY_ATTRIBUTES. На первых порах при вызовах функции CreateFile и всех остальных функций вам будет достаточно использовать значение NULL; вопросы безопасности файловой системы рассматриваются в главе 15.

dwCreate — конкретизирует запрашиваемую операцию: создать новый файл, перезаписать существующий файл и тому подобное. Может принимать одно из приведенных ниже значений, которые могут объединяться при помощи операции поразрядного "или" языка С.

• CREATE_NEW — создать новый файл; если указанный файл уже существует, выполнение функции завершается неудачей.

• CREATE_ALWAYS — создать новый файл; если указанный файл уже существует, функция перезапишет его.

• OPEN_EXISTING — открыть файл; если указанный файл не существует, выполнение функции завершается неудачей.

• OPEN_ALWAYS — открыть файл; если указанный файл не существует, функция создаст его.

• TRUNCATE_EXISTING — открыть файл; размер файла будет установлен равным нулю. Уровень доступа к файлу, установленный параметром dwAccess, должен быть не ниже GENERIC_WRITE. Если указанный файл существует, его содержимое будет уничтожено. В отличие от случая CREATENEW выполнение функции будет успешным даже в тех случаях, когда указанный файл не существует. 

dwAttrsAndFlags — позволяет указать атрибуты файла и флаги. Всего имеется 16 флагов и атрибутов. Атрибуты являются характеристиками файла, а не открытого дескриптора, и игнорируются, если открывается существующий файл. Некоторые из наиболее важных флаговых значений приводятся ниже.

• FILE_ATTRIBUTE_NORMAL — этот атрибут можно использовать лишь при условии, что одновременно с ним не устанавливаются никакие другие атрибуты (тогда как для всех остальных флагов одновременная установка допускается).

• FILE_ATTRIBUTE_READONLY — этот атрибут запрещает приложениям осуществлять запись в данный файл или удалять его.

• FILE_FLAG_DELETE_ON_CLOSE — этот флаг полезно применять в случае временных файлов. Файл будет удален сразу же после закрытия последнего из его открытых дескрипторов.

• FILE_FLAG_OVERLAPPED — этот флаг играет важную роль при выполнении операций асинхронного ввода/вывода, описанных в главе 14.

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

• FILE_FLAG_WRITE_THROUGH — устанавливает режим сквозной записи промежуточных данных непосредственно в файл на диске, минуя кэш.

• FILE_FLAG_NO_BUFFERING — устанавливает режим отсутствия промежуточi ной буферизации или кэширования, при котором обмен данными происходит непосредственно с буферами данных программы, указанными при вызове функций ReadFile или WriteFile (описаны далее). Соответственно требуется, чтобы начала программных буферов совпадали с границами секторов, а их размеры были кратными размеру сектора тома. Чтобы определить размер сектора при указании этого флага, вы можете воспользоваться функцией GetDiskFreeSpace.

• FILE_FLAG_RANDOM_ACCESS — предполагается открытие файла для произвольного доступа; Windows будет пытаться оптимизировать кэширование файла применительно к этому виду доступа.

• FILE_FLAG_SEQUENTIAL_SCAN — предполагается открытие файла для последовательного доступа; Windows будет пытаться оптимизировать кэширование файла применительно к этому виду доступа. Оба последних режима реализуются системой лишь по мере возможностей.

hTemplateFile — дескриптор с правами доступа GENERIC_READ к шаблону файла, предоставляющему расширенные атрибуты, которые будут применены к создаваемому файлу вместо атрибутов, указанных в параметре dwAttrsAndFlags. Обычно значение этого параметра устанавливается равным NULL. При открытии существующего файла параметр hTemplateFile игнорируется. Этот параметр используется в тех случаях, когда требуется, чтобы атрибуты вновь создаваемого файла совпадали с атрибутами уже существующего файла.

Оба вызова функции CreateFile в программе 1.2 максимально упрощены за счет использования для параметров значений по умолчанию, и, тем не менее, они вполне справляются со своими задачами. В обоих случаях было бы целесообразно использовать флаг FILE_FLAG_SEQUENTIAL_SCAN. (Эта возможность исследуется в упражнении 2.3, а соответствующие результаты тестирования производительности приведены в приложении В.)

Заметьте, что для данного файла могут быть одновременно открыты несколько дескрипторов, если только это разрешается атрибутами совместного доступа и защиты файла. Открытые дескрипторы могут принадлежать одному и тому же или различным процессам. (Управление процессами описано в главе 6).

В Windows Server 2003 предоставляется функция ReOpenFile, которая возвращает новый дескриптор с иными флагами, правами доступа и прочим, нежели те, которые были указаны при первоначальном открытии файла, если только это не приводит к возникновению конфликта между новыми и прежними правами доступа.

Для закрытия объектов любого типа, объявления недействительными их дескрипторов и освобождения системных ресурсов почти во всех случаях используется одна и та же универсальная функция. Исключения из этого правила будут оговариваться отдельно. Закрытие дескриптора сопровождается уменьшением на единицу счетчика ссылок на объект, что делает возможным удаление таких не хранимых постоянно (nonpersistent) объектов, как временные файлы или события. При выходе из программы система автоматически закрывает все открытые дескрипторы, однако лучше все же, чтобы программа самостоятельно закрывала свои дескрипторы перед тем, как завершить работу.

Попытки закрытия недействительных дескрипторов или повторного закрытия одного и того же дескриптора приводят к исключениям (исключения и обработка исключений обсуждаются в главе 4). Не только излишне, но и не следует закрывать дескрипторы стандартных устройств, которые обсуждаются в разделе "Стандартные устройства и консольный ввод/вывод" далее в этой главе. 

BOOL CloseHandle(HANDLE hObject)

Возвращаемое значение: в случае успешного выполнения функции — TRUE, иначе — FALSE. 

Функции UNIX, сопоставимые с рассмотренными выше, отличаются от них в нескольких отношениях. Функция (системный вызов) UNIX open возвращает целочисленный дескриптор (descriptor) файла, а не дескриптор типа HANDLE, причем для указания всех параметров доступа, разделения и создания файлов, а также атрибутов и флагов используется единственный целочисленный параметр oflag. Возможные варианты выбора, доступные в обеих системах, перекрываются, однако набор опций, предлагаемый Windows, отличается большим разнообразием.

В UNIX отсутствует параметр, эквивалентный параметру dwShareMode. Файлы UNIX всегда являются разделяемыми.

В обеих системах при создании файла используется информация, касающаяся его защиты. В UNIX для задания хорошо известных разрешений на доступ к файлу для владельца, членов группы и прочих пользователей используется аргумент mode.

Функция close, хотя ее и можно сопоставить с функцией CloseHandle, отличается от последней меньшей универсальностью.

Функции библиотеки С, описанные в заголовочном файле <stdio.h>, используют объекты FILE, которые можно поставить в соответствие дескрипторам (дисковые файлы, терминалы, ленточные устройства и тому подобные), связанным с потоками. Параметр mode функции fopen позволяет указать, должны ли содержащиеся в файле данные обрабатываться как двоичные или как текстовые. Имеются также опции открытия файла в режиме "только чтение", обновления файла, присоединения к другому файлу и так далее. Функция freopen обеспечивает возможность повторного использования объектов FILE без их предварительного закрытия. Средства для задания параметров защиты стандартной библиотекой С не предоставляются.

Для закрытия объектов типа FILE предназначена функция fclose. Имена большинства функций стандартной библиотеки С, предназначенных для работы с объектами FILE, снабжены префиксом "f".

BOOL ReadFile(HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped)

Возвращаемое значение: в случае успешного выполнения (которое считается таковым, даже если не был считан ни один байт из-за попытки чтения с выходом за пределы файла) — TRUE, иначе — FALSE. 

Вплоть до главы 14 мы будем предполагать, что дескрипторы файлов создаются без указания флага перекрывающегося ввода/вывода FILE_FLAG_OVERLAPPED в параметре dwAttrsAndFlags. В этом случае функция ReadFile начинает чтение с текущей позиции указателя файла, и указатель файла сдвигается на число считанных байтов.

Если значения дескриптора файла или иных параметров, используемых при вызове функции, оказались недействительными, возникает ошибка, и функция возвращает значение FALSE. Попытка выполнения чтения в ситуациях, когда указатель файла позиционирован в конце файла, не приводит к ошибке; вместо этого количество считанных байтов (*lpNumberOfBytesRead) устанавливается равным 0.

Описательные имена переменных и естественный порядок расположения параметров во многом говорят сами за себя. Тем не менее, ниже приводятся некоторые краткие пояснения.

hFile — дескриптор считываемого файла, который должен быть создан с правами доступа GENERIC_READ. lpBuffer является указателем на буфер в памяти, куда помещаются считываемые данные. nNumberOfBytesToRead — количество байт, которые должны быть считаны из файла.

lpNumberOfBytesRead — указатель на переменную, предназначенную для хранения числа байт, которые были фактически считаны в результате вызова функции ReadFile. Этот параметр может принимать нулевое значение, если перед выполнением чтения указатель файла был позиционирован в конце файла или если во время чтения возникли ошибки, а также после чтения из именованного канала, работающего в режиме обмена сообщениями (глава 11), если переданное сообщение имеет нулевую длину.

lpOverlapped — указатель на структуру OVERLAPPED (главы 3 и 14). На данном этапе просто устанавливайте значение этого параметра равным NULL.

BOOL WriteFile(HANDLE hFile, LPCVOID lpBuffer, DWORD nNumberOfBytesToWrite, LPDWORD lpNumberOfBytesWritten, LPOVERLAPPED lpOverlapped)

Возвращаемое значение: в случае успешного выполнения — TRUE, иначе — FALSE.

Все параметры этой функции вам уже знакомы. Заметьте, что успешное выполнение записи еще не говорит о том, что данные действительно оказались записанными на диск, если только при создании файла с помощью функции CreateFile не был использован флаг FILE_FLAG_WRITE_THROUGH. Если во время вызова функции указатель файла был позиционирован в конце файла, Windows увеличит длину существующего файла.

Функции ReadFileGather и WriteFileGather позволяют выполнять операции чтения и записи с использованием набора буферов различного размера. 

Сопоставимыми функциями UNIX являются функции read и write, которым программист в качестве параметров должен предоставлять дескриптор файла, буфер и счетчик байтов. Возвращаемые значения этих функций указывают на количество фактически переданных байтов. Возврат функцией read значения 0 означает чтение конца файла, а значения –1 — возникновение ошибки. В противоположность этому в Windows для подсчета количества переданных байтов используется отдельный счетчик, а на успех или неудачу выполнения функции указывает возвращаемое ею булевское значение.

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

Входящие в состав стандартной библиотеки С функции read и fwrite, выполняющие операции ввода/вывода в двоичном режиме, вместо счетчика одиночных байтов, как в UNIX и Windows, используют размер объекта и счетчик объектов. Преждевременное прекращение передачи данных может быть вызвано как достижением конца файла, так и возникновением ошибки; точная причина устанавливается с использованием функций feof или ferror. Библиотека предоставляет полный набор функций, ориентированных на работу с текстовыми файлами, таких как fgets или fputs, для которых в каждой из рассматриваемых ОС аналоги вне библиотеки С отсутствуют.

Прежде чем двигаться дальше, необходимо кратко объяснить, как Windows обрабатывает символы и различает 8-битовые, 16-битовые и обобщенные символы. Эта тема весьма обширна и выходит за рамки данной книги, поэтому мы не будем выделять ее обсуждение в отдельную главу и ограничимся приведением лишь самых необходимых сведений в минимальном объеме.

Windows поддерживает стандартные 8-битовые символы (типы char или CHAR) и (исключая Windows 9x) 16-битовые символы расширенной формы (тип WCHAR, определенный в библиотеке С как wchar_t). В документации Microsoft 8-битовый набор фигурирует как символьный набор ASCII, хотя фактически он является символьным набором Latin-1, однако в целях удобства изложения название "ASCII" будет использоваться и в нашем обсуждении. Обеспечиваемая Windows с использованием кодировки Unicode UTF-16 поддержка обобщенных символов расширенной формы позволяет представлять в стандарте Unicode символы и буквы, встречающиеся во всех основных языках, включая английский, французский, испанский, немецкий, русский, японский и китайский. 

Ниже описаны шаги, которые обычно предпринимаются при написании обобщенных (generic) Windows-приложений, то есть приложений, предусматривающих использование как символов Unicode (UTF-16, а не, например, UCS-4), так и 8-битовых ASCII-символов.

1. Определите все символы и строки с использованием обобщенных типов TCHAR, LPTSTR и LPCTSTR.

2. Чтобы иметь возможность работать с символами в расширенной форме Unicode (wchar_t в ANSI С), включите во все модули исходного кода определения #define UNICODE и #define _UNICODE; если этого не сделать, то тип TCHAR будет эквивалентен типу CHAR (char в ANSI С). Это определение должно помещаться перед директивой #include <windows.h>, и его часто задают в командной строке компилятора. Первая из указанных переменных препроцессора управляет определениями функций Windows, вторая — библиотекой С.

3. Размеры буферов для хранения символов, указываемые, например, при вызове функций ReadFile, могут определяться с использованием функции sizeof(TCHAR).

4. Используйте входящие в состав библиотеки С функции ввода/вывода обобщенных символов и строк, описанные в файле <tchar.h>. В качестве наиболее характерных из доступных функций можно назвать такие функции, как _fgettc, _itot (вместо itoa), _stprintf (вместо sprintf), _tstcpy (вместо strcpy), _ttoi, _totupper, _totlower и _tprintf.[12] Полный и исчерпывающий список таких функций можно найти в оперативной справочной системе. Все перечисленные определения зависят от определения символьной константы _UNICODE. Описанная коллекция функций не является полной. Примером функции, для которой еще не реализован аналог, позволяющий работать с символами расширенной формы, может служить функция memchr. Новые версии предоставляются по мере возникновения необходимости в них.

5. Строковые константы могут принимать одну из трех допустимых форм. Эти же соглашения следует применять и к одиночным символам. Первые две формы предоставляются стандартом ANSI С, третья — макрос _Т (эквиваленты — TEXT и _ТЕХТ) — поставляется вместе с компилятором Microsoft С.

"В этой строке используются 8-битовые символы"

L"B этой строке используются 16-битовые символы"

_Т("В этой строке используются обобщенные символы")

6. Чтобы получить доступ к необходимым определениям текстовых макросов и обобщенным функциям библиотеки С, в модуль следует включить заголовочный файл <tchar.h>, объявление которого должно предшествовать объявлению файла <windows.h>.

16-битовые символы Unicode (кодировка UTF-16) используются в Windows повсеместно; для внутреннего представления имен файлов и путей доступа в файловой системе NTFS также используется Unicode. Если определена символьная константа _UNICODE, то все вызовы функций Windows требуют использования строк, состоящих из расширенных символов; в противном случае строки 8-битовых символов преобразуются в расширенные строки. В случае программ, которые должны выполняться под управлением систем Windows 9x, не являющихся Unicode-системами, определять символические константы UNICODE и _UNICODE не следует. В средах NT или СЕ решение об использовании указанных определений вы принимаете по своему усмотрению, если только для программы не должна быть одновременно сохранена возможность выполнения под управлением Windows 9x.

Во всех последующих примерах вместо обычного типа char для символов и символьных строк будет использоваться тип TCHAR, если только по каким-то вполне обоснованным причинам не возникнет необходимости в обработке отдельных 8-битовых символов. Точно так же, тип LPTSTR соответствует указателю на обобщенную строковую переменную, а тип LPCTSTR — указателю на обобщенную строковую константу. В результате принятия этих мер программа может стать более громоздкой, однако лишь своевременный учет различных возможных вариантов обеспечивает гибкость, необходимую для разработки и тестирования приложений, допускающих как кодировку Unicode, так и 8-битовую кодировку символов, что позволит легко преобразовать программу к использованию символов Unicode, если впоследствии в этом возникнет необходимость. Более того, предоставление возможности выбора между обеими разновидностями кодировок соответствует общепринятой, если не универсальной, практике, которая сложилась к настоящему времени.

Немалую пользу может принести просмотр системных заголовочных файлов, изучив которые вы поймете, как определяются тип TCHAR и интерфейсы системных функций и как они зависят от того, определены или не определены символьные константы UNICODE и _UNICODE. Соответствующие строки обычно выглядят так:

#ifdef UNICODE

#define TCHAR WCHAR

#else

#define TCHAR CHAR

#endif

В тех случаях, когда при сравнении строк необходим учет специфики языковых и региональных, или локальных, особенностей на стадии выполнения, или же когда требуется сравнивать не строки, а слова,[13] то вместо функций _tcscmp и _tcscmpi вам могут понадобиться функции lstrcmp и lstrcmpi. Сравнение строк осуществляется путем простого сравнения числовых значений символов, тогда как при сравнении слов принимаются во внимание специфические для конкретного языка особенности словообразования. Если применить указанные два метода сравнения к таким парам строк, как coop/co-op и were/we're, то они приведут к противоположным результатам.

В Windows также существует группа функций, предназначенных для работы с символами и строками в представлении Unicode. Эти функции обеспечивают прозрачную обработку региональных особенностей. Типичными функциями этой группы являются функция CharUpper, которую можно применять как к строкам, так и к отдельным символам, и функция IsCharAlphaNumeric. К числу других функций для работы со строками принадлежат функция CompareString (учитывающая особенности локализации) и функция MultiByteToWideChar. Многобайтовые символы Windows 3.1 и 9х расширяют наборы 8-битовых символов, позволяя применять для представления наборов символов, используемых в языках дальневосточных стран, сдвоенные байты. Чтобы продемонстрировать использование функций обоих типов, будут рассмотрены примеры программ, в которых используются как обобщенные функции библиотеки С (_tprintf и подобные ей), так и функции Windows (CharUpper и подобные ей). Примеры в последующих главах в основном опираются на обобщенную библиотеку С.

Обозначение С-функции main с ее списком аргументов (argv[]) следует заменить макросом _tmain. В зависимости от определения символической константы _UNICODE макрос разворачивается либо до main, либо до wmain. _tmain определяется в заголовочном файле <tchar.h>, который следует включать после файла <windows.h>. Тогда типичный заголовок основной программы будет иметь следующий вид:

#include <windows.h>

#include <tchar.h>

int _tmain(int argc, LPTSTR argv[]) {

 …

}

В Microsoft С функция _tmain поддерживает дополнительный третий параметр, используемый для строк окружения. Такое нестандартное расширение является обычным в UNIX.

В качестве примера рассмотрим функцию CreateFile. Если символьная переменная UNICODE определена, то эта функция определяется как CreateFileA, а если не определена — то как CreateFileW. Строковые параметры в объявлениях также описываются как строки 8-битовых символов или символов в расширенной форме. Следовательно, если в исходном коде присутствуют такие, например, ошибки, как использование неподходящих параметров в функции CreateFile, то в сообщениях компилятора об этих ошибках будут указываться функции CreateFileA или CreateFileW.

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

1. Только 8-битовые символы. Игнорируйте Unicode и продолжайте использовать для таких функций, как printf, atoi и strcmp, типы данных char (или CHAR) и стандартную библиотеку С.

2. 8-битовые символы, но с возможностью использования символов Unicode. Следуйте ранее данным рекомендациям в отношении обобщенных приложений, но не определяйте константы UNICODE и _UNICODE директивами препроцессора. В приведенных в данной книге примерах программ используется именно эта стратегия.

3. Только символы Unicode. Следуйте рекомендациям в отношении обобщенных приложений, но при этом определите директивами препроцессора обе константы UNICODE и _UNICODE. Другой возможный вариант состоит в том, чтобы использовать исключительно расширенную форму символов и функций для работы с символами. Результирующие программы не смогут правильно выполняться под управлением Windows 9x.

4. Символы Unicode и 8-битовые символы. Программа ориентируется на работу как с символами Unicode, так и с ASCII-символами, причем решение относительно того, какие участки программного кода должны работать, принимается программой на стадии выполнения с использованием переключателей времени выполнения или других возможных средств.

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

Параметры локализации могут устанавливаться во время выполнения программы. В программе 2.2 показано, как определить язык, который должен использоваться в сообщениях об ошибках.

Стандарт локализации приложений POSIX XPG4, предоставляемый многими поставщиками UNIX, существенно отличается от стандарта Unicode. Помимо всего прочего, символы в этом стандарте могут представляться 4, 3 или 1 байтами в зависимости от контекста, особенностей локализации и так далее.

Microsoft С реализует функции стандартной библиотеки С, среди которых имеются также версии, рассчитанные на работу с символами в расширенной форме. Так, заголовочный файл <wchar.h> содержит описание функции _tsetlocale. В Windows NT используются символы Unicode, тогда как в Windows 9x используются те же многобайтовые символы (смесь 8– и 16-битовых символов), что и в Windows 3.1.

Как и в UNIX, в Windows предусмотрены три стандартных устройства, предназначенные, соответственно, для ввода данных (input), вывода данных (output) и вывода сообщений об ошибках (error). В UNIX для этих устройств используются известные системе значения дескрипторов файлов (0, 1 и 2), однако в Windows доступ к стандартным устройствам осуществляется с помощью дескрипторов типа HANDLE, для получения которых предоставляется специальная функция.

HANDLE GetStdHandle(DWORD nStdHandle)

Возвращаемое значение: в случае успешного выполнения — действительный дескриптор, иначе — значение INVALID_HANDLE_VALUE.

Параметр nStdHandle должен принимать одно из следующих значений:

• STD_INPUT_HANDLE

• STD_OUTPUT_HANDLE

• STD_ERROR_HANDLE

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

Вызов функции GetStdHandle не приводит к созданию новых или дублированию существующих дескрипторов стандартных устройств. Последовательные вызовы с указанием в качестве аргумента одного и того же устройства будут возвращать одно и то же значение дескриптора. Закрытие дескриптора стандартного устройства делает это устройство недоступным для дальнейшего использования. По этой причине в примерах ниже мы будем часто открывать дескриптор стандартного устройства, но не закрывать его. 

BOOL SetStdHandle(DWORD nStdHandle, HANDLE hHandle)

Возвращаемое значение: в случае успешного выполнения — TRUE, иначе — FALSE. 

Допустимые значения параметра nStdHandle функции SetStdHandle являются теми же, что и в случае функции GetStdHandle. Параметр hHandle указывает открытый файл, который назначается в качестве стандартного устройства.

Одним из методов перенаправления стандартного ввода/вывода является последовательный вызов функций SetStdHandle и GetStdHandle. Полученный в результате этого дескриптор используется в последующих операциях ввода/ вывода.

Для указания путей доступа к консольному вводу (клавиатуре) и консольному выводу предусмотрены два зарезервированных имени: "CONIN$" и "CONOUT$". Роль стандартных устройств ввода, вывода и вывода ошибок первоначально отводится консоли. Однако консоль можно использовать даже после того, как операции ввода/вывода, требующие применения стандартных устройств, будут перенаправлены; для этого требуется лишь открыть дескрипторы для файлов "CONIN$" и "CONOUT$", вызвав функцию CreateFile. 

В UNIX стандартный ввод/вывод может быть перенаправлен одним из трех способов (см. [40], стр. 61—64).

Первый метод является косвенным и основывается на том, что функция dup возвращает дескриптор файла с наименьшим доступным номером. Предположим, вы хотите переназначить стандартный ввод (файловый дескриптор 0) открытому файлу, описанному как fd_redirect. Тогда можно записать следующий код:

close (STDIN_FILENO);

dup (fd_redirect);

Во втором методе используется функция dup2, а третий метод предполагает вызов замысловатой перегруженной функции fcntl с использованием в качестве параметра значения F_DUPFD.

Операции консольного ввода/вывода могут выполняться с помощью функций ReadFile и WriteFile, но проще использовать предназначенные специально для этого функции консоли ReadConsole и WriteConsole. Основное преимущество этих функций заключается в том, что они манипулируют не байтами, а обобщенными символами (TCHAR), и, кроме того, обрабатывают символы в соответствии с текущими режимами консоли, которые устанавливаются функцией SetConsoleMode. 

BOOL SetConsoleMode(HANDLE hConsoleHandle, DWORD fdevMode)

Возвращаемое значение: тогда, и только тогда, когда функция завершается успешно — TRUE, иначе — FALSE. 

hConsoleHandle — дескриптор буфера ввода консоли или буфера дисплея, который должен быть создан с правами доступа GENERIC_WRITE, даже если устройство предназначено только для ввода информации.

Параметр fdevMode задает способ обработки символов. В имени каждого из его флагов содержится компонент, указывающий, к чему относится данный флаг— к вводу (input) или выводу (output). Ниже перечислены пять обычно используемых флагов, причем все они устанавливаются по умолчанию.

• ENABLE_LINE_INPUT — возврат из функции чтения (ReadConsole) происходит только после считывания символа возврата каретки.

• ENABLE_ECHO_INPUT — эхо-отображение вводимых символов на экране.

• ENABLE_PROCESSED_INPUT — установка этого флага приводит к обработке системой управляющих символов возврата на одну позицию, возврата каретки и перехода на новую строку.

• ENABLE_PROCESSED_OUTPUT — установка этого флага приводит к обработке системой управляющих символов возврата на одну позицию, табуляции, подачи звукового сигнала, возврата каретки и перехода на новую строку.

• ENABLE_WRAP_AT_EOL_OUTPUT — переход на следующую строку экрана как при обычном выводе символов, так и при их эхо-отображении в процессе ввода.

В случае неудачного завершения функции SetConsoleMode текущий режим остается неизменным, и функция возвращает значение FALSE. Как обычно, для получения номера ошибки следует воспользоваться функцией GetLastError.

Функции ReadConsole и WriteConsole аналогичны функциям ReadFile и WriteFile. 

BOOL ReadConsole(HANDLE hConsoleInput, LPVOID lpBuffer, DWORD cchToRead, LPDWORD lpcchRead, LPVOID lpReserved)

Возвращаемое значение: тогда, и только тогда, когда функция завершается успешно — TRUE, иначе — FALSE.

Параметры у этой функции почти те же, что и у функции ReadFile. Значения обоих параметров, связанных с количеством подлежащих считыванию (cchToRead) и фактически считанных (lpcchRead) символов, выражаются в терминах обобщенных символов, а не байтов, а значение параметра lpReserved должно быть равным NULL. Как и во всех остальных подобных случаях, никогда не используйте для собственных нужд зарезервированные поля, аналогичные lpReserved, которые встречаются в некоторых функциях. Параметры функции WriteConsole имеют тот же смысл и не нуждаются в дополнительных пояснениях. В очередном примере будет проиллюстрировано применение функций Read-Console и WriteConsole, и, кроме того, будет показано, как использовать возможности управления режимом консоли.

Любому процессу в каждый момент времени может быть назначена только одна консоль. Приложениям того типа, с которым мы имели дело до сих пор, консоль передается обычно на стадии инициализации. Однако в целом ряде других случаев, например, в случае серверных или GUI-приложений, у вас может возникнуть необходимость в получении отдельной консоли, на которую можно было бы выводить информацию о состоянии программы или отладочную информацию. Для этих целей можно воспользоваться двумя простыми функциями, не имеющими параметров. 

BOOL FreeConsole(VOID)

BOOL AllocConsole(VOID)

 

Функция FreeConsole отключает процесс от его консоли, тогда как функция AllocConsole создает новую консоль, ассоциированную с дескрипторами стандартного ввода информации, стандартного вывода информации и стандартного вывода сообщений об ошибках, принадлежащими данному процессу. Если консоль у процесса уже имеется, функция AllocConsole завершится с ошибкой; чтобы избежать этого, следует предварительно вызывать функцию FreeConsole.

Примечание

GUI-приложения Windows не имеют консоли по умолчанию и должны получить ее, прежде чем смогут воспользоваться функциями WriteConsole или printf для вывода на консоль. Процессы на стороне сервера также могут не иметь консоли. О том, как создать процесс без консоли, рассказано в главе 6. 

Имеется также множество других функций консольного ввода/вывода, предназначенных для установки позиции курсора, а также задания атрибутов выводимых символов (например, цвета) и так далее. Принятый в данной книге подход состоит в том, чтобы использовать лишь те функции, которые необходимы для создания примеров работоспособных программ, поэтому углубляться больше, чем это необходимо, в пользовательские интерфейсы мы не будем. После того как вы разберете примеры, для вас не составит большого труда изучить дополнительные функции, воспользовавшись справочными материалами. 

Исторически сложилось так, что ОС Windows ориентирована на использование терминалов или консолей в меньшей степени, чем UNIX, и не полностью воспроизводит функциональные средства UNIX, поддерживающие работу с терминалами. В книге [40] одна из глав посвящена рассмотрению обеспечиваемых UNIX возможностей терминального ввода/вывода (глава 11), а другая — псевдотерминалам (глава 19).

Разумеется, работа в Windows почти всегда ведется с использованием мощных графических интерфейсов, поддерживающих мышь и ввод с клавиатуры. Несмотря на то что рассмотрение GUI выходит за рамки данной книги, все, что мы здесь обсуждаем, будет работать и в GUI-приложениях.

Функция ConsolePrompt, входящая в программу 2.1, является полезной утилитой, которая выводит на консоль заданное сообщение и возвращает ответ пользователя на него. Данная утилита предусматривает возможность подавления эхо-отображения ответной информации, полученной от пользователя. В указанной функции используются функции консольного ввода/вывода и обобщенные символы. Двумя другими точками входа в этом модуле являются функции Print-Strings и PrintMsg; эти функции допускают использование любого дескриптора, однако обычно они применяются совместно с дескрипторами устройств стандартного вывода информации и стандартного вывода сообщений об ошибках. В первой функции разрешается использовать список аргументов переменной длины, тогда как во второй в качестве аргумента можно задавать только одну строку, что в некоторых случаях может оказаться удобнее. Для обработки списка аргументов переменной длины функция PrintStrings использует функции va_start, va_arg и va_end стандартной библиотеки С.

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

Примечание

Коды программ, находящиеся на Web-сайте книги, содержат подробные комментарии и тщательно документированы, тогда как в самой книге большинство комментариев с целью сокращения места были опущены, и основное внимание в ней уделяется использованию Windows.

Следует также отметить, что в примере вводится заголовочный файл Envirmnt.h (его код приведен в приложении А и предоставлен на Web-сайте книги), который должен использоваться совместно со всеми приводимыми в книге программами. Этот файл содержит определения символических констант UNICODE и _UNICODE (сами определения "закомментированы"; при компоновке приложений, предназначенных для работы с символами стандарта Unicode, символы комментариев следует удалить), а также необходимых макропеременных, учитывающих особенности окружения. В заголовочных файлах, находящихся на Web-сайте, определены также дополнительные модификаторы, которые обеспечивают импортирование и экспортирование имен функций, а также гарантируют соблюдение соответствующих соглашений о вызове функций.

/* PrintMsg.с: ConsolePrompt, PrintStrings, PrintMsg */

#include "Envirmnt.h" /* В этом файле устанавливаются директивы #define и #undef для UNICODE. */

#include <windows.h>

#include <stdarg.h>

BOOL PrintStrings (HANDLE hOut, ...)

/* Запись сообщений в буфер экрана консоли. */

{

 DWORD MsgLen, Count;

 LPCTSTR pMsg;

 va_list pMsgList; /* Строка текущего сообщения. */

 va_start (pMsgList, hOut); /* Начать обработку сообщений. */

 while ((pMsg = va_arg(pMsgList, LPCTSTR)) != NULL) {

  MsgLen = _tcslen(pMsg);

  /* Функция WriteConsole может применяться только с дескриптором буфера экрана консоли. */

  if (!WriteConsole(hOut, pMsg, MsgLen, &Count, NULL)

      /* Функция WriteFile вызывается только в случае неудачного завершения функции WriteConsole. */

      && !WriteFile(hOut, pMsg, MsgLen * sizeof (TCHAR), &Count, NULL)) return FALSE;

 }

 va_end(pMsgList);

 return TRUE;

}

BOOL PrintMsg(HANDLE hOut, LPCTSTR pMsg)

/* Версия PrintStrings для вывода одиночного сообщения. */

{

 return PrintStrings(hOut, pMsg, NULL);

}

BOOL ConsolePrompt(LPCTSTR pPromptMsg, LPTSTR pResponse, DWORD MaxTchar, BOOL Echo)

/* Вывести на консоль подсказку для пользователя и получить от него ответ. */

{

 HANDLE hStdIn, hStdOut;

 DWORD TcharIn, EchoFlag;

 BOOL Success;

 hStdIn = CreateFile(_T("CONIN$"), GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

 hStdOut = CreateFile(_T("CONOUT$"), GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

 EchoFlag = Echo ? ENABLE_ECHO_INPUT : 0;

 Success = SetConsoleMode(hStdIn, ENABLE_LINE_INPUT | EchoFlag | ENABLE_PROCESSED_INPUT) &&

           SetConsoleMode (hStdOut, ENABLE_WRAP_AT_EOL_OUTPUT | ENABLE_PROCESSED_OUTPUT) &&

           PrintStrings (hStdOut, pPromptMsg, NULL) &&

           ReadConsole (hStdIn, pResponse, MaxTchar, &TcharIn, NULL);

 if (Success) pResponse [TcharIn – 2] = '\0';

 CloseHandle (hStdIn);

 CloseHandle (hStdOut);

 return Success;

}

Обратите внимание, что при вычислении возвращаемого функцией значения булевской переменной Success, которое служит индикатором успешности выполнения, в программе, с выгодой для логики ее работы, используется тот факт, что стандартом ANSI С гарантируется так называемое "сокращенное" вычисление логических выражений в направлении слева направо; поэтому, как только при вычислении части выражения, расположенной слева от любой из операций логического "и" (&&), в качестве результата будет получено значение FALSE, остальная часть выражения, расположенная справа от данной операции, вычисляться не будет, поскольку результат вычисления всего выражения в целом оказывается предопределенным. Данный стиль написания программ может показаться чересчур компактным, однако он обладает тем преимуществом, что позволяет организовать логически стройную и понятную последовательность системных вызовов, не загромождая программу многочисленными операторами условных переходов. Для получения более подробной информации о возможных ошибках можно воспользоваться функцией GetLastError. Распространенный в Windows возврат функциями логических значений поощряет подобную практику.

В данной функции сообщения об ошибках не выводятся; их вывод, если это будет необходимо, можно предусмотреть в вызывающей программе.

В программном коде используется тот документированный факт, что при использовании функции WriteConsole вместе с дескриптором, который не является дескриптором консоли, ее выполнение будет завершено с ошибкой. В связи с этим предварительный запрос свойств дескриптора не является обязательным. Функция воспользуется консольным режимом лишь в том случае, если указанный в ее вызове дескриптор действительно связан с консолью.

Кроме того, функция ReadConsole возвращает управляющие символы возврата каретки и перехода на новую строку, что диктует необходимость вставки дополнительных нулевых символов после символов возврата каретки в соответствующих местах.

В программе 1.2 было продемонстрировано использование лишь самых примитивных средств обработки ошибок, а именно, получение номера ошибки в переменной типа DWORD с помощью функции GetLastError. Вызов функции, а не просто получение глобального номера ошибки, как это делается при помощи функции UNIX errno, гарантирует уникальную идентификацию системных ошибок для каждого из потоков (глава 7), использующих разделяемую область хранения данных.

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

В программе 2.2 представлена полезная универсальная функция ReportError, предназначенная для обработки ошибок и по своим возможностям аналогичная входящей в состав библиотеки С функции perror, а также описанным в [40] функциям err_sys и err_ret. Функция ReportError передает в выходной буфер сообщение в виде, определяемом первым аргументом, и либо прекращает выполнение с кодом выхода по ошибке, либо осуществляет обычный возврат управления, в зависимости от значения второго аргумента. Третий аргумент определяет, должны ли отображаться системные сообщения об ошибках.

Обратите внимание на аргументы функции FormatMessage. В качестве одного из параметров используется значение, возвращаемое функцией GetLastError, a на необходимость генерации сообщения системой указывает флаг. Сгенерированное сообщение сохраняется в буфере, выделяемом функцией, а соответствующий адрес возвращается в параметре. Имеются также другие параметры, для которых указаны значения по умолчанию. Язык сообщений может быть задан как во время компиляции, так и во время выполнения. В этой книге функция Format-Message далее нигде не используется, поэтому никаких дополнительных пояснений относительно нее в тексте не дается. 

Функция ReportError упрощает обработку ошибок, и будет использоваться почти во всех последующих примерах. В главе 4 она будет модифицирована для генерации исключений.

В программе 2.2 вводится заголовочный файл EvryThng.h. Как следует из самого его названия, этот файл включает в себя файлы <windows.h>, Envirmnt.h и все остальные заголовочные файлы, которые были явно указаны в программе 2.1. Кроме того, в нем описаны такие обычно используемые функции, как PrintMsg, PrintStrings и ReportError. Во всех остальных примерах будет использоваться только этот заголовочный файл, листинг которого приведен в приложении А.

Обратите внимание на вызов функции HeapFree, находящийся почти в конце программы. Об этой функции будет рассказано в главе 5.

#include "EvryThng.h"

VOID ReportError(LPCTSTR UserMessage, DWORD ExitCode, BOOL PrintErrorMsg)

/* Универсальная функция для вывода сообщений о системных ошибках. */

{

 DWORD eMsgLen, LastErr = GetLastError();

 LPTSTR lpvSysMsg;

 HANDLE hStdErr = GetStdHandle(STD_ERROR_HANDLE);

 PrintMsg(hStdErr, UserMessage);

 if (PrintErrorMsg) {

  eMsgLen = FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM, NULL, LastErr, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR)&lpvSysMsg, 0, NULL);

  PrintStrings (hStdErr, _T("\n"), lpvSysMsg, _T("\n"), NULL);

  /* Освободить блок памяти, содержащий сообщение об ошибке. */

  HeapFree(GetProcessHeap(), 0, lpvSysMsg); /* См. гл. 5. */

 }

 if (ExitCode > 0) ExitProcess (ExitCode);

 else return;

}

В программе 2.3 иллюстрируется использование стандартных устройств ввода/вывода, а также демонстрируется, как улучшить контроль ошибок и усовершенствовать взаимодействие с пользователем. Эта программа представляет собой вариант ограниченной реализации команды UNIX cat, которая копирует один или несколько заданных файлов (или содержимое буфера стандартного устройства ввода, если файлы не указаны) на стандартное устройства вывода.

Программа 2.3 включает полную обработку ошибок. В большинстве других примеров проверка ошибок опущена или сведена к минимуму, но полностью включена в завершенные документированные варианты программ, находящиеся на Web-сайте. Обратите внимание на функцию Options (ее листинг приведен в приложении А), вызываемую в начале программы. Эта функция, которая включена в состав программ, находящихся на Web-сайте, и используется на протяжении всей книги, просматривает параметры в командной строке и возвращает индекс массива argv, соответствующий имени первого файла. Функция Options аналогична функции getopt, которая используется во многих программах в UNIX.

/* Глава 2. cat. */

/* cat [параметры] [файлы] Допускается только параметр –s, предназначенный для подавления вывода сообщений об ошибках в случае, если один из указанных файлов не существует. */

#include "EvryThng.h"

#define BUF_SIZE 0x200

static VOID CatFile(HANDLE, HANDLE);

int _tmain(int argc, LPTSTR argv[]) {

 HANDLE hInFile, hStdIn = GetStdHandle(STD_INPUT_HANDLE);

 HANDLE hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);

 BOOL DashS;

 int iArg, iFirstFile;

 /* Переменная DashS будет установлена только в случае задания параметра "-s" в командной строке. */

 /* iFirstFile — индекс первого входного файла в списке argv[]. */

 iFirstFile = Options(argc, argv, _T("s"), &DashS, NULL);

 if (iFirstFile == argc) { /*Отсутствие входных файлов в списке аргументов.*/

  /* Использовать стандартное устройство ввода. */

  CatFile(hStdIn, hStdOut);

  return 0;

 }

 /* Обработать каждый входной файл. */

 for (iArg = iFirstFile; iArg < argc; iArg++) {

  hInFile = CreateFile(argv [iArg], GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

  if (hInFile == INVALID_HANDLE_VALUE && !DashS) ReportError (_T("Cat: ошибка при открытии файла"), 1, TRUE);

  CatFile (hInFile, hStdOut);

  CloseHandle (hInFile);

 }

 return 0;

}

/* Функция, выполняющая всю работу:

/* читает входные данные и копирует их на стандартное устройства вывода. */

static VOID CatFile(HANDLE hInFile, HANDLE hOutFile) {

 DWORD nIn, nOut;

 BYTE Buffer [BUF_SIZE];

 while (ReadFile(hInFile, Buffer, BUF_SIZE, &nIn, NULL) && (nIn != 0) && WriteFile(hOutFile, Buffer, nIn, &nOut, NULL));

 return;

}

Программа 2.4 достраивает программу 1.3, в которой использовалась вспомогательная функция CopyFile. С копированием файлов вы уже знакомы, поэтому в данном примере эта операция дополняется преобразованием файла к кодировке Unicode в предположении, что первоначальной кодировкой символов является ASCII, хотя проверка этого предположения не производится. В программе предусмотрены некоторые возможности вывода сообщений об ошибках и параметр, позволяющий подавить замену существующего файла; завершающий вызов функции CopyFile заменен в программе вызовом новой функции, которая Выполняет преобразование символьных строк файла из кодировки ASCII в кодировку Unicode.

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

Обратите внимание на вызов функции _taccess, проверяющей существование файла. Эта функция является обобщенной версией функции access, которая имеется в библиотеке UNIX, но не входит в состав стандартной библиотеки С. Ее определение содержится в файле <io.h>. Если говорить точнее, функция _taccess осуществляет проверку прав доступа к файлу в соответствии с режимом, установленным значением второго параметра. Значение 0 задает проверку существования файла, 2 — проверку наличия разрешения на запись в файл, 4 — проверку наличия разрешения на чтение из файла, 6 — проверку наличия разрешения как на чтение из файла, так и на запись в файл (эти значения не связаны напрямую с такими параметрами доступа, используемыми в Windows, как GENERIC_READ). Альтернативой проверке существования файла могло бы быть открытие дескриптора при помощи функции CreateFile и его последующее закрытие после проверки действительности дескриптора. 

/* Глава 2. atou – копирование файлов с преобразованием из ASCII в Unicode. */

#include "EvryThng.h"

BOOL Asc2Un(LPCTSTR, LPCTSTR, BOOL);

int _tmain(int argc, LPTSTR argv[]) {

 DWORD LocFileIn, LocFileOut;

 BOOL DashI = FALSE;

 TCHAR YNResp[3] = _T("y");

 /* Получить параметры командной строки и индекс входного файла. */

 LocFileIn = Options(argc, argv, _T("i"), &DashI, NULL);

 LocFileOut = LocFileIn + 1;

 if (DashI) { /* Существует ли выходной файл? */

  /* Обобщенная версия функции access, осуществляющая проверку существования файла. */

  if (_taccess(argv[LocFileOut], 0) == 0) {

   _tprintf(_T("Перезаписать существующий файл? [y/n]"));

   _tscanf(_T ("%s"), &YNResp);

   if (lstrcmp(CharLower(YNResp), YES) != 0) ReportError(_T("Отказ от перезаписи"), 4, FALSE);

  }

 }

 /* Эта функция построена на основе функции CopyFile. */

 Asc2Un(argv[LocFileIn], argv [LocFileOut], FALSE);

 return 0;

}

Программа 2.5 — это вызываемая в программе 2.4 функция Asc2Un, осуществляющая преобразование кодировки символов.

#include "EvryThng.h"

#define BUF_SIZE 256

BOOL Asc2Un(LPCTSTR fIn, LPCTSTR fOut, BOOL bFailIfExists)

/* Функция копирования файлов с преобразованием из ASCII в Unicode. Функция построена на основе функции CopyFile. */

{

 HANDLE hIn, hOut;

 DWORD dwOut, nIn, nOut, iCopy;

 CHAR aBuffer[BUF_SIZE];

 WCHAR uBuffer [BUF_SIZE];

 BOOL WriteOK = TRUE;

 hIn = CreateFile(fin, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); 

 /* Определить поведение функции CreateFile, если выходной файл уже существует. */

 dwOut = bFailIfExists ? CREATE_NEW : CREATE_ALWAYS;

 hOut = CreateFile(fOut, GENERIC_WRITE, 0, NULL, dwOut, FILE_ATTRIBUTE_NORMAL, NULL);

 while (ReadFile(hIn, aBuffer, BUF_SIZE, &nIn, NULL)  && nIn > 0 && WriteOK) {

  for (iCopy = 0; iCopy < nIn; iCopy++)

   /* Преобразовать каждый символ. */

   uBuffer[iCopy] = (WCHAR)aBuffer [iCopy];

  WriteOK = WriteFile(hOut, uBuffer, 2 * nIn, &nOut, NULL);

 }

 CloseHandle(hIn);

 CloseHandle(hOut);

 return WriteOK;

}

Как показано в приложении В, производительность программы преобразования файлов можно повысить, предоставив буфер большего размера и задав флаг FILE_FLAG_SEQUENTIAL_SCAN при вызове функции CreateFile. В приложении В также сравниваются показатели производительности программы для файловых систем NTFS и распределенных файловых систем.

В этом разделе вводятся основные функции, предназначенные для управления файлами и каталогами.

Для управления файлами Windows предоставляет целый ряд функций, работа с которыми обычно не представляет сложности. Ниже описаны функции, с помощью которых можно удалять, копировать и переименовывать файлы. Существует также функция, предназначенная для создания имен временных файлов.

При удалении файла достаточно указать его имя. Вспомните, что все полные имена файлов начинаются с буквы диска или имени сервера. Открытый файл, вообще говоря, удалить невозможно (это допускается в Windows 9x и UNIX); попытка выполнения подобной операции закончится неудачей. У такого ограничения есть свои положительные стороны, поскольку оно предотвращает случайное удаление открытых файлов. 

BOOL DeleteFile(LPCTSTR lpFileName)

 

Чтобы скопировать файл целиком, достаточно использовать одну функцию. 

BOOL CopyFile(LPCTSTR lpExistingFileName, LPCTSTR lpNewFileName, BOOL fFailIfExists)

 

Функция CopyFile копирует существующий файл с заданным именем и присваивает копии указанное новое имя. В случае существования файла с таким же именем он будет заменен новым файлом только в том случае, если значением параметра fFailIfExists является FALSE.

Под управлением NT5 можно создать жесткую ссылку (hard link) для двух файлов, аналогичную жестким ссылкам в UNIX, используя для этого функцию CreateHardLink. Жесткие ссылки делают возможным существование файла под двумя различными именами. Заметьте, что в подобных случаях файл как таковой существует в единственном числе, и поэтому можно произвольно использовать любое из его имен, независимо от того, какое из них было использовано для открытия файла.

BOOL CreateHardLink(LPCTSTR lpFileName, LPCTSTR lpExistingFileName, BOOL lpSecurityAttributes)

 

Два первых аргумента имеют тот же смысл, что и в функции CopyFile, хотя и расположены в обратном порядке. Оба имени файла, новое и существующее, должны относиться к одному и тому же тому файловой системы, но могут соответствовать различным каталогам. Атрибуты защиты файла, если таковые имеются, применимы и к новому имени файла.

Если заглянуть в документацию Microsoft, то можно увидеть, что в структуре BY_HANDLE_FILE_INFO имеется поле "количество ссылок", и именно этот счетчик используется для определения того, может или не может быть удален данный файл. Функция DeleteFile удаляет имя из каталога файловой системы, но сам файл не может быть удален до тех пор, пока значение счетчика "количество ссылок" не станет равным 0.

Гибких ссылок (soft link) в Windows не существует, хотя оболочки Windows (но не сама Windows), руководствующиеся при определении местоположения файла его содержимым, поддерживают ярлыки (shortcuts). Ярлыки предоставляют средства, подобные гибким ссылкам, но воспользоваться ими могут только пользователи оболочки.

Доступны две функции, позволяющие переименовывать, или "перемещать", файл. Эти же функции применимы и к каталогам. (Функции DeleteFile и CopyFile могут применяться только к файлам.) 

BOOL MoveFile(LPCTSTR lpExistingFileName, LPCTSTR lpNewFileName)

BOOL MoveFileEx(LPCTSTR lpExistingFileName, LPCTSTR lpNewFileName, DWORD dwFlags)

 

Если новый файл уже существует, функция MoveFile завершается с ошибкой; в этом случае следует использовать функцию MoveFileEx. Заметьте, что суффикс "Ех" обычно применяется для обозначения усовершенствованных версий функций, обладающих расширенными (extended) функциональными возможностями.

lpExistingFileName — указатель на строку, содержащую имя существующего файла или каталога.

lpNewFileName — указатель на строку, содержащую имя нового файла или каталога, которые, в случае функции MoveFile, до ее вызова существовать не должны. Новый файл может принадлежать другой файловой системе или находиться на другом диске, но новые каталоги обязательно должны находиться на одном и том же диске. Если значение этого параметра положить равным NULL, то существующий файл будет удален.

dwFlags — позволяет задавать следующие опции:

• MOVEFILE_REPLACE_EXISTING — разрешает замену существующего файла.

• MOVEFILE_WRITETHROUGH — используйте этот флаг, если необходимо, чтобы функция выполнила возврат лишь после того, как файл будет фактически перемещен на диске.

• MOVEFILE_COPY_ALLOWED — если новый файл находится на другом томе, перемещение осуществляется путем последовательного выполнения функций CopyFile и DeleteFile.

• MOVEFILE_DELAY_UNTIL_REBOOT — установка этого флага, использование которого является прерогативой администратора системы и который не может применяться совместно с флагом MOVEFILE_COPY_ALLOWED, приводит к тому, что фактическое перемещение файла будет осуществлено только после перезагрузки системы.

С перемещением (переименованием) файлов связаны некоторые ограничения.

• В Windows 9x функция MoveFileEx не реализована; вместо нее вы должны использовать последовательные вызовы функций CopyFile и DeleteFile. Это делает возможным одновременное существование двух экземпляров файла, что порождает определенные проблемы в случае дисков, близких к заполнению, или файлов большого размера. При этом временные атрибуты файлов изменяются иначе, нежели при истинном перемещении.

• Использование групповых символов в именах файлов или каталогов запрещено. Необходимо указывать фактические имена. 

Полные имена файлов в UNIX не включают имен дисков и серверов; корневой системный каталог обозначается обратной косой чертой. В то же время, функции для работы с файлами, входящие в библиотеку Microsoft С, поддерживают имена дисков, как того требуют соглашения Windows относительно именования файлов.

В UNIX отсутствует функция непосредственного копирования файлов. Вместо этого, чтобы выполнить команду cp, вы должны написать небольшую программу или использовать системный вызов system ().

В UNIX эквивалентом функции DeleteFile служит функция unlink, которая, к тому же, может удалять и каталоги.

В библиотеку С входят функции rename и remove, однако функция remove не позволяет присваивать файлу имя уже существующего файла или присваивать каталогу имя существующего непустого каталога. Новое имя может совпадать с именем существующего каталога только в том случае, если этот каталог пустой.

Создание и удаление каталогов осуществляется при помощи двух простых функций. 

BOOL CreateDirectory(LPCTSTR lpPathName, LPSECURITY_ATTRIBUTES lpSecurityAttributes)

BOOL RemoveDirectory(LPCTSTR lpPathName)

lpPathName является указателем на завершающуюся нулевым символом строку, которая содержит путь к создаваемому или удаляемому каталогу. Как и в случае других функций, на данном этапе атрибуты защиты файла должны полагаться равными NULL; вопросы безопасности файлов и объектов рассматриваются в главе 15. Удалить можно только пустой каталог.

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

BOOL SetCurrentDirectory(LPCTSTR lpPathName)

 

lpPathName определяет путь к новому текущему каталогу. Это может быть относительный путь или абсолютный полный путь, в начале которого указаны либо буква диска и двоеточие (например, D:), либо имя UNC (например, \\ACCTG_SERVER\PUBLIC).

Если в качестве пути к каталогу указывается только имя диска (например, А: или С:), то рабочим каталогом становится рабочий каталог данного диска. Например, если рабочие каталоги устанавливались в последовательности:

C:\MSDEV

INCLUDE

A:\MEMOS\TODO

С:

то результирующим рабочим каталогом будет:

C:\MSDEV\INCLUDE

Следующая функция возвращает абсолютный полный путь к текущему каталогу, помещая его в буфер, предоставляемый программистом: 

DWORD GetCurrentDirectory(DWORD cchCurDir, LPTSTR lpCurDir)

Возвращаемое значение: длина строки, содержащей путь доступа к текущему каталогу, или требуемый размер буфера, если буфер не достаточно велик; в случае ошибки — нуль.

cchCurDir — размер буфера, содержащего имя каталога, который определяется количеством символов (а не байт). Размер буфера должен рассчитываться с учетом завершающего нулевого символа строки. lpCurDir является указателем на буфер, предназначенный для получения строки, содержащей путь.

Заметьте, что в случае если размер буфера оказался недостаточным для того, чтобы в нем уместилась вся строка пути, функция возвратит значение, указывающее на требуемый размер буфера. Поэтому при тестировании успешности выполнения функции следует проверять два условия: равно ли возвращаемое значение нулю и не превышает ли оно значение, заданное аргументом cchCurDir.

Подобный метод возврата строк и их длины широко распространен в Windows и требует внимательной обработки результатов. Программа 2.6 иллюстрирует типичный фрагмент кода, реализующего эту логику. Аналогичная логика реализуется и в других примерах. Вместе с тем, указанный метод применяется не всегда. Некоторые функции возвращают булевские значения, а параметр размера в них используется дважды: перед вызовом функции его значение устанавливается равным размеру буфера, а затем изменяется функцией. В качестве одного из многих возможных примеров можно привести функцию LookupAccountName, с которой вы встретитесь в главе 15. 

Альтернативный подход, демонстрируемый в программе 15.4 функцией GetFileSecurity, заключается в выделении буферной памяти в промежутке между двумя вызовами функций. Первый вызов обеспечивает получение длины строки, на основании чего и выделяется память, тогда как второй — получение самой строки. Самым простым подходом в данном случае является выделение памяти для строки, насчитывающей МАХ_РАТН символов.

Программа 2.6 реализует очередную версию команды UNIX pwd. Размер буфера определяется значением параметра МАХ_РАТН, однако проверка ошибок все равно предусмотрена, чтобы проиллюстрировать работу функции GetCurrent-Directory.

/* Глава 2. pwd – вывод на печать содержимого рабочего каталога. */

#include "EvryThng.h"

#define DIRNAME_LEN MAX_PATH + 2

int _tmain(int argc, LPTSTR argv[]) {

 TCHAR pwdBuffer [DIRNAME_LEN];

 DWORD LenCurDir;

 LenCurDir = GetCurrentDirectory(DIRNAME_LEN, pwdBuffer);

 if (LenCurDir == 0) ReportError(_T("He удается получить путь."), 1, TRUE);

 if (LenCurDir > DIRNAME_LEN) ReportError(_T("Слишком длинный путь."), 2, FALSE);

 PrintMsg(GetStdHandle(STD_OUTPUT_HANDLE), pwdBuffer);

 return 0;

}

Наряду с функциями, предназначенными для обработки символов, в Windows поддерживается полный набор функций, обеспечивающих управление файлами и каталогами. Кроме того, вы можете создавать переносимые, обобщенные приложения, которые могут быть рассчитаны на работу как с символами ASCII, так и с символами Unicode.

Функции Windows во многом напоминают их аналоги в UNIX и библиотеке С, хотя различия между ними также очевидны. В приложении Б представлена таблица, в которой сведены функции Windows, UNIX и библиотеки С и показано, в чем они соответствуют друг другу, а в чем заметно отличаются. 

Нашим следующим шагом будет обсуждение в главе 3 прямого доступа к файлам и использования таких атрибутов файлов и каталогов, как размер файла и метки времени. Кроме того, в главе 3 показано, как управлять каталогами, а в завершение главы обсуждается работа с API реестра, аналогичного API управления каталогами.

В книге [22] содержится исчерпывающее обсуждение всего спектра возможных вариантов организации хранения данных в Windows как на непосредственно подключенных, так и на сетевых устройствах. Наряду с внутренними деталями реализации описаны все последние достижения и успехи в данной области, а также прогресс в отношении повышения быстродействия устройств хранения данных.

Книга [10] — это небольшая монография, в которой описаны цели и особенности реализации NTFS. Содержащаяся в ней информация пригодится вам как для этой, так и для следующей глав.

В книге [19] показано, как использовать Unicode на практике. Изложение сопровождается различными рекомендациями, а также рассмотрением международных стандартов и вопросов программирования, связанных с учетом региональных особенностей.

На домашней странице компании Microsoft вы найдете несколько полезных статей о стандарте Unicode. Основной является статья "Unicode Support in Win32" ("Поддержка Unicode в Win32"), отталкиваясь от которой вы, используя средства поиска, сможете отыскать все остальные.

В главах 3 и 4 книги [40] рассматриваются файлы и каталоги UNIX, а в главе 11 — терминальный ввод/вывод.

Для быстрого ознакомления с командами UNIX можете обратиться к книге [15].

2.1. Напишите небольшую программу для тестирования обобщенных версий функций printf и scanf.

2.2. Модифицируйте функцию CatFile в программе 2.3 таким образом, чтобы при связывании дескриптора стандартного вывода с консолью в ней использовалась не функция WriteFile, а функция WriteConsole.

2.3. Параметры вызова функции CreateFile позволяют задавать различные характеристики способа доступа к файлу, что может быть использовано для повышения производительности программ. В качестве примера можно привести параметр FILE_FLAG_SEQUENTIAL_SCAN. Используйте этот флаг в программе 2.5 и выясните, приведет ли это к улучшению показателей производительности при работе с файлами большого размера. Результаты для нескольких систем приведены в приложении В. Исследуйте также влияние флага FILE_FLAG_NO_BUFFERING.

2.4. Исследуйте, насколько ощутимы различия в производительности для файловых систем FAT и NTFS при использовании функции atou в случае преобразования файлов большого размера.

2.5. Выполните программу 2.4 с использованием и без использования определения символической константы UNICODE. Как это влияет на результаты, если таковое влияние вообще наблюдается? Если имеется такая возможность, выясните, способны ли программы правильно выполняться в системах Windows 9x.

2.6. Сопоставьте информацию, предоставляемую функциями perror (библиотека С) и ReportError в случае таких распространенных ошибок, как попытка открытия несуществующего файла.

2.7. Протестируйте подавление функцией ConsolePrompt (программа 2.1) эхо-отображения клавиатурного ввода, используя ее для вывода запроса на ввод и подтверждение пароля пользователем.

2.8. Выясните, что происходит, когда для вывода на консоль используются смешанные вызовы функций обобщенной библиотеки С и функций Windows WriteFile и WriteConsole. Дайте происходящему свое объяснение.

2.9. Напишите программу сортировки массива строк Unicode. Изучите различия между случаями сортировки слов и строк с помощью функций lstrcmp и _tcscmp. Приводит ли использование функции lstrlen к получению иных результатов по сравнению с функцией _tcslen? Вам могут пригодиться содержащиеся в оперативной справочной системе Microsoft замечания в описании функции CompareString. 

2.10. Расширьте реализацию функции Options таким образом, чтобы она выводила сообщение об ошибке, если в командной строке указаны опции, которые отсутствуют в списке разрешенных опций, заданных в параметре OptionString данной функции.

2.11. В приложении В приводятся данные о показателях производительности для копирования файлов и их преобразования при помощи функции atou с использованием различных вариантов реализации программы и файловых систем. Исследуйте с помощью тестовых программ показатели производительности на доступных вам системах. Кроме того, если возможно, исследуйте показатели производительности для сетевых файловых систем, SAN и так далее, чтобы выяснить, каким образом проявляются различия в организации хранения данных при осуществлении последовательного доступа к файлам.

Примечания:

1

Тем не менее, в тех местах книги, где речь идет о средствах, неприменимых в Windows 9х, делаются соответствующие оговорки.

12

Символ подчеркивания (_) указывает на то, что данная функция или ключевое слово предоставляются компилятором Microsoft С, тогда как буквы t и Т указывают на то, что данная функция предназначена для работы с обобщенными символами, имеющими расширенную форму. Аналогичные возможности предлагаются и другими средами разработки приложений, хотя используемые в них имена функций и ключевые слова могут отличаться от приведенных выше.

13

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