Для работы с файлами в Windows содержится свой набор функций, позволяющих выполнять основные операции над файлами. В первых 16ти разрядных версиях Windows (по 3.x включительно) эти функции основывались на применении функций MS-DOS. Непосредственно в Windows описан только минимальный набор базовых функций, для выполнения других операций всегда можно воспользоваться прерыванием 0x21. В отличие от них, 32х разрядные версии Windows содержат уже полный набор функций для работы с файлами, при этом использование функций MS-DOS не допускается. Функции Win32 API для работы с файлами -- это расширенный набор функций по сравнению с Windows API.

Работа с файлами, каталогами и томами в Windows API

В Windows 3.x применяется файловая система MS-DOS. В первых версиях Windows вообще вся работа с дисками просто переадресовывалась к функциям MS-DOS, в поздних версиях, например Windows for Workgroup 3.11, в частных случаях может использовать собственные средства, реализующие доступ к диску и к файлам в 32х разрядном защищенном режиме. Это несколько увеличивает производительность системы, работающей в защищенном режиме, так как при обращениям к данным на диске исключаются переключения процессора из защищенного режима в реальный и обратно. При этом система проверяет, возможно ли с помощью имеющихся драйверов обращаться к данному диску, или нет. Если это невозможно (например, используются нестандартные DOS-драйверы), то для доступа к диску и файлам применяются средства MS-DOS, как в предыдущих версиях Windows.

Файлы (file) группируются в каталоги (directory или folder, папки). В одном каталоге может находиться большое количество файлов или других вложенных каталогов. Каталоги образуют строго древовидную структуру -- данный каталог может содержать сколько угодно вложенных, но сам он может быть вложен только в один родительский каталог (каталог верхнего уровня). На каждом томе (volume) существует один каталог самого верхнего уровня -- корневой каталог (root directory). Для обозначения конкретного тома используются буквы английского алфавита, начиная с “a”.

Имена файлов (file name) и каталогов (directory name, folder name) в Windows API, как и в MS-DOS, состоят из имени, длиной до 8 символов и расширения, длиной до 3 символов, отделяемого от имени одной точкой. Таким образом максимальная длина имени составляет 12 символов, включая разделяющую точку. Для точного задания файла необходимо указать не только его имя, но также и каталог, в котором он находится. Причем, так как каталоги могут быть вложенные, то необходимо задавать список каталогов, которые надо пройти на пути от текущего каталога, либо от корневого каталога тома до каталога, содержащего нужный файл.

Имя тома, путь до файла и имя файла составляют так называемое полное имя файла (path name). Полное имя начинается с названия тома, за которым следует двоеточие, обратная косая черта и список каталогов на пути к файлу, разделяемых обратными косыми чертами, затем следует имя файла и его расширение, отделяемое точкой. Например: E:\Mka\Book\Samples\1a.cpp

Указывает на файл 1a.cpp, находящийся к каталоге Samples, вложенном в подкаталог Book и, вместе с ним, в подкаталог Mka, хранящийся на томе E.

Для каждого тома существует понятие текущего каталога (current directory). Кроме того существует понятие текущего тома (диска) (current drive). Для задания файла, находящегося в текущем каталоге текущего тома, достаточно просто указать имя этого файла. Вы можете легко сделать текущий диск другим и перейти в нем в какой-либо иной каталог. В этом случае система запомнит тот каталог, в котором вы были перед переходом на другой диск, и будет считать его текущим каталогом для прежнего диска.

Так, например:

1a.cpp -- задает файл 1a.cpp в текущем каталоге текущего диска

E:1a.cpp -- задает файл 1a.cpp в текущем каталоге тома E

E:\1a.cpp -- задает файл 1a.cpp в корневом каталоге тома E

\1a.cpp -- задает файл 1a.cpp в корневом каталоге текущего диска

Система допускает использование специальных имен “.” (точка) и “..” (две точки) для задания текущего каталога и для задания каталога верхнего уровня. Например, пусть текущий каталог E:\Mka\Book\Samples, тогда:

.\1a.doc -- задает файл E:\Mka\Book\Samples\1a.cpp

..\Chapter2.doc -- задает файл E:\Mka\Book\Chapter2.doc

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

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

Собственно в Windows 3.x содержится небольшой набор функций, повторяющих основные операции над файлами -- создание, открытие, позиционирование файлового указателя, чтение, запись и закрытие; помимо этого предусмотрено несколько дополнительных функций. Функций для разделения доступа, переименования или копирования файлов, создания и смены каталогов и прочего не предусматривается. При необходимости можно воспользоваться прерыванием 0x21, либо функциями стандартной C-библиотеки времени выполнения.

HFILE _lcreat(lpszFilename, fnAttribute);

HFILE _lopen(lpszFilename, fnOpenMode);

LONG _llseek(hf, lOffset, nOrigin);

UINT _lread(hf, hpvBuffer, cbBuffer);

UINT _lwrite(hf, hpvBuffer, cbBuffer);

long _hread(hf, hpvBuffer, cbBuffer);

long _hwrite(hf, hpvBuffer, cbBuffer);

HFILE _lclose(hf);

Назначение этих функций понятно из названия. Среди них интересны только две процедуры -- _hread и _hwrite -- которые предназначены для чтения и записи больших фрагментов файлов за одну операцию. Под большими в данном случае понимаются фрагменты, превышающие 65535 байт (64K), то есть превышающие размер одного 16ти разрядного сегмента. Для 16ти разрядной платформы Windows 3.x это очень удобно.

Неудобным в функциях Windows API для работы с файлами является то, что для флагов этих функций предусмотрены только числовые значения, а не символические. Так, например, для функции _lcreat параметр fnAttribute равный 0, соответствует созданию обычного файла, а 2 -- скрытого. Или для функции _llseek параметр nOrigin равный 1 указывает на задание нового положения относительно текущего, а не относительно начала файла. Все эти константы так и надо указывать в виде числа, предварительно проверив их значение по руководству.

Используемые в Windows хендлы файлов являются хендлами файлов MS-DOS. Это позволяет легко применять обычные средства для работы с файлами. С другой стороны это приводит к типичной ошибке: в Windows принято, что значение 0 для хендла является недопустимым; то есть обычная проверка при получение хендла какого-либо объекта выглядит так:

HANDLE hObject;

hObject = Get...(...); // получаем хендл объекта

if (hObject) {// проверяем его...

// все в порядке

} else {

// ошибка!}

Однако при работе с файлами такой способ ошибочен -- хендл файла, равный 0, в MS-DOS соответствует стандартному устройству для вывода (stdout), а не недопустимому. Для обозначения ошибки применяется значение хендла файла не 0, а -1. Для удобства в windows.h определен специальный символ HFILE_ERROR, равный -1. Предыдущий фрагмент при работе с файлами должен выглядеть так:

HFILE hFile;

hFile = _lcreat(“c:\\myfile.dat”, 0);

if (hFile != HFILE_ERROR) {

// все в порядке

...

_lclose(hFile);

} else {

// ошибка!}

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

HFILE OpenFile(lpszFileName, lpOpenBuff, fuMode);

Параметр lpOpenBuf является указателем на структуру OFSTRUCT. В этой структуре сохраняется информация об открытом файле, что позволяет использовать ее для повторного открытия (или удаления) того-же файла позже. Параметр fuMode обычно указывает режим доступа к открытому файлу (флаги OF_READ, OF_WRITE, OF_READWRITE), выполняемую операцию -- открыть или создать файл (OF_CREATE), ограничение доступа к файлу других приложений (OF_SHARE_...).

Помимо открытия файла данная функция способна выполнять некоторые специфические операции (задаваемые тем-же параметром fuMode):

удаление файла OF_DELETE,

поиск файла OF_SEARCH,

проверка существования файла OF_EXIST,

повторное открытие файла по информации, сохраненной в структуре OFSTRUCT OF_REOPEN,

инициализацию структуры OFSTRUCT OF_PARSE,

сравнение даты и времени создания файла с данными в структуре OFSTRUCT OF_VERIFY,

а также сообщать о невозможности открыть файл (при этом функция OF_PROMPT и не позволяет ни выбрать другой файл, ни указать новое имя файла) OF_CANCEL

Еще несколько функций Windows носят вспомогательный характер. Так, например, функции GetWindowsDirectory и GetSystemDirectory возвращают информацию о каталоге, содержащем win.com -- каталоге Windows и системном каталоге (обычно windows\system).

UINT GetWindowsDirectory(lpszSysPath, cbSysPath)

UINT GetSystemDirectory(lpszSysPath, cbSysPath);

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

Int GetModuleFileName(hInstance, lpszFileName, cbFileName);

Еще пара функций помогает создавать временные файлы. Функция GetTempDrive возвращает букву, обозначающую диск, используемый для хранения временных файлов (при этом параметр функции chDriveLetter не используется). При этом предполагается, что для хранения временных файлов используется первый жесткий диск (обычно C), а если он не существует, то текущий диск. Вторая функция -- GetTempFileName помогает построить уникальное имя временного файла, при этом она использует либо переменную окружения TEMP, либо, если она не определена, то корневой каталог указанного тома, либо, если он не задан, корневой каталог первого жесткого диска (обычно C).

BYTE GetTempDrive(chDriveLetter);

Int GetTempFileName(chDriveLetter, lpszPrefixString, uUnique, lpszTempFileName);

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

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

UINT SetHandleCount(cHandles);

Последняя функция возвращает информацию о типе дискового устройства. К сожалению эта информация крайне скудна -- Windows распознает только три вида дисковых устройств: фиксированные (DRIVE_FIXED), сменные (DRIVE_REMOVABLE) и удаленные (DRIVE_REMOTE):

UINT GetDriveType(nDriveNumber);

Параметр nDriveNumber задает номер диска: устройство “A” имеет номер 0, “C” -- 2 и так далее. Возвращаемое функцией значение тип диска (DRIVE_FIXED, DRIVE_REMOVABLE, DRIVE_REMOTE), либо, в случае ошибки, 0.

Работа с файлами, каталогами и томами в Win32 API

Средства для работы с файлами в Win32 API существенно отличаются от средств в Windows API. Одна из самых существенных, с точки зрения разработчика, особенностей -- использование длинных имен файлов. Так для имени файла и расширения система отводит 255 символов. Это значит, что использование каких-либо буферов фиксированного размера для хранения полных имен файлов недопустимо! Так как полное имя содержит путь, часто насчитывающий добрый десяток вложенных каталогов, а их имена могут быть длиной до 255 символов каждый, да еще само имя файла, то определить достаточный размер такого буфера просто не представляется возможным.

Конечно, теоретически можно резервировать по 5-10 килобайт под каждое имя, надеясь, что использовать столь длинные пути со столь длинными именами никто не будет. Но это дело чисто вероятностное -- пока имена файлов и каталогов приходилось хотя-бы иногда набирать руками, очень длинных путей никто и не делал, но в современных системах интерфейс разработан таким образом, что набирать имя файла или каталога приходится обычно лишь однажды -- при его создании и при этом набирается только имя, а не полный путь. Это до определенной степени провоцирует на применение очень длинных имен.

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

Иногда возможно использование так называемых коротких имен вместо длинных. Дело в том, что в 32х разрядной системе возможен запуск 16ти разрядных приложений Windows и задач MS-DOS, которые, естественно, не могут работать с длинными именами. Для того, что бы старые приложения могли иметь доступ ко всем файлам, система автоматически генерирует так называемые короткие имена, подчиняющиеся соглашениям MS-DOS. Все 16ти разрядные приложения Windows и все задачи MS-DOS имеют дело с этими короткими именами. В Win32 API предусмотрены специальные функции (GetShortPathName и GetFullPathName) для получения короткого имени из длинного и наоборот. Однако надо иметь в виду, что этот механизм все-таки не гарантирует корректную работу старых приложений -- полная длина пути (даже составленного из коротких имен) может превысить 144 символа, так как число вложенных подкаталогов может оказаться значительным. При этом 32х разрядная система (Windows-95 или Windows NT) будет работать с такими глубоко запрятанными файлами совершенно спокойно, но при попытке получить доступ к этим файлам средствами MS-DOS или использовать их старыми 16ти разрядными приложениями Windows возможно возникновение ошибок. Возможно, но не обязательно -- смотря по тому, какие пути используются: абсолютные (длина может превышать 144 символа), или относительные (как правило их длина существенно меньше).

DWORD GetFullPathName(lpszFile, cchPath, lpszLongPath, plpszFileNamePart);

DWORD GetShortPathName(lpszLongPath, lpszShortPath, cchBuffer);

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

Другая проблема -- использование пробелов в именах файлов. Часто при анализе командных строк предполагается, что пробел отделяет один компонент командной строки от другого. Теперь пробел может находиться и внутри имени файла, содержащегося в этой командной строке. В таких случаях принято заключать имя файла в двойные кавычки (этот символ запрещено использовать в самих именах). А раз так, то во все средства разбора командной строки надо включать специальный анализ на выделение имен файлов, заключенных в кавычки (либо не заключенных, если в имени нет пробелов). Больше всего ошибок возникает при переносе старых приложений в Win32. Многие солидные программисты просто не замечали, что какая-то хорошо отлаженная библиотечная функция, служившая много лет им верой и правдой, вдруг даст ошибку, наткнувшись на пробел в имени файла. А поймать все такие ошибки в процессе отладки очень трудно. Такие ошибки проскакивали незамеченными во время отладки в хорошие, коммерческие продукты. Так, например, очень хороший и надежный компилятор Watcom C/C++ 10.5 содержит неожиданно много таких ошибок, причем как в библиотеках времени выполнения, так и в самой среде.

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

Помимо этого следует учесть, что в именах файлов могут встречаться две косые черты подряд. Так, например, открытие файла с именем “\\.\A:” соответствует получению доступа к тому “A” (заметьте, что в программе на C это имя будет записано как “\\\\.\\A:”).

Все рассмотренные функции Windows API реализованы и в Win32 API, однако помимо них добавлено множество других, очень полезных функций. Правда реализация прежних функций несколько изменилась; так функция SetHandleCount при работе в Windows NT просто потеряла смысл -- для описания файлов используется динамически выделяемое пространство, функции _lread и _lwrite полностью совпадают с функциями _hread и _hwrite соответственно. Многие из старых функций получили аналоги в Win32 API, обладающие несколько большими функциональными возможностями, например функции _lread и _lwrite имеют более мощные аналоги ReadFile, ReadFileEx, WriteFile и WriteFileEx.

Работа с томами

Win32 API предоставляет полный набор средств для работы с файлами и томами, в отличие от прежних версий Windows, которые часто использовали функции MS-DOS. Большинство функций Win32 API для идентификации тома используют не одну букву, и не номер тома, как это было в MS-DOS, а путь к корневому каталогу тома. Обычно это строка вида X:\, однако, в сравнительно редких случаях, возможно задание конкретного каталога.

Например, при работе с Windows 3.x и Win32s возможна работа 32х разрядного приложения в 16ти разрядной операционной системе, когда пользователь может обеспечить доступ к тому как к отдельному каталогу другого тома (используя команду join). В этом случае характеристики тома в целом и отдельного каталога этого тома могут существенно различаться -- скажем, том является разделом жесткого диска, а один из его каталогов соответствует CD-ROM или RAM диску.

Итак, коротко рассмотрим основные функции Win32 API для работы с томами.

DWORD GetLogicalDrives(void);

DWORD GetLogicalDriveStrings(nBufferSize, lpszBuffer);

Возвращают информацию о присутствующих в системе томах. Функция GetLogicalDrives возвращает двойное слово, установленные в 1 биты которого соответствуют имеющимся томам. Более интересная функция GetLogicalDriveStrings возвращает список из имен корневых каталогов томов. Имена разделяются между собой символом `\0', а весь список завершается двумя символами `\0'.

В документации можно встретить утверждения, что эта функция реализована только в Windows NT, однако это не так -- в Windows-95 (по крайней мере в локализованной русской версии 4.0.950a) она тоже определена. Точно ее нет только в Win32s. Сравнительно легко можно написать универсальную функцию, которая будет использовать GetLogicalDriveStrings, либо, при ее отсутствии, эмулировать ее с помощью функции GetLogicalDrives (нечто подобное сделано в приводимом ниже примере 2B).

Другой интересный нюанс этой функции связан с тем, что для получения от нее результата, необходимо использовать буфер неизвестной заранее длины (как и для многих других функций Win32 API, работающих с файлами). Можно, конечно, зарезервировать буфер с большим запасом и надеяться, что он почти никогда не будет заполнен полностью. Лучше, однако, сначала узнать требуемое пространство, выделить его, и только затем получить данные:

DWORD dwSize = GetLogicalDriveStrings(0, NULL); // узнать длину

LPTSTR lpszStrings = new TCHAR [ dwSize+1 ]; // +1 = для символа `\0'

GetLogicalDriveStrings(dwSize, lpszStrings);

for (LPTSTR p = lpszStrings; *p; p += lstrlen(p) + 1) {

// `p' указывает на название конкретного тома}

delete lpszStrings;

Следующая рассматриваемая функция -- GetDriveType -- возвращает информацию о типе тома. В прежнем Windows API существовал аналог этой функции, который получал вместо имени корневого каталога тома номер логического диска и распознавал несколько меньшее количество типов томов -- CD-ROMы и RAM диски отдельно не опознавались.

UINT GetDriveType(lpszRoot);

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

Функция GetVolumeInformation возвращает более подробную информацию о томе. С ее помощью можно узнать метку тома (в Windows API для этих целей часто искали файл типа “метка тома” в корневом каталоге этого тома), серийный номер, задаваемый при форматировании тома, тип файловой системы (NTFS, HPFS, CDFS, FAT), а также максимальную длину имени файла, поддерживаемую томом и некоторые другие сведения.

BOOL GetVolumeInformation(

lpszRoot,

lpszVolume, nVolumeSize,

lpdwSerialNumber, lpdwMaxNameLength, lpdwFlags,

lpszFileSystemName, nFileSystemName);

На практике приходилось видеть, когда функция ошибалась с определением файловой системы для удаленных дисков. Такую ошибку трудно четко повторить, так как возможно большое количество комбинаций из систем, установленных на компьютер с запущенным приложением (Windows 3.x + Win32s, Windows-95, Windows-98, Windows NT) и на компьютер, предоставляющий свои диски в общее пользование (список еще больше -- включая системы типа OS/2, Macintosh, Unix и прочее).

Достаточно часто может возникнуть необходимость в проверке свободного пространства и полного размера какого-либо тома. Сделать это можно с помощью функции GetDiskFreeSpace:

BOOL GetDiskFreeSpace(

lpszRoot,

lpdwSectorsPerCluster, lpdwBytesPerSector,

lpdwFreeClusters, lpdwTotalClusters);

Эта функция возвращает информацию о размере кластера данных, размере тома в кластерах и о количестве свободных кластеров. Кластер -- минимальный объем пространства используемый при выделении места для хранения данных. Кластера обычно жестко не связаны с физической организацией тома, они представляют собой некоторое логическое объединение одной или нескольких физически выделяемых единиц информации на томе. Так, все пространство тома обычно разбивается на физические сектора (обычно по 512 байт для жестких и гибких дисков и 2048-2192 байт для CD-ROM)

С помощью функции SetVolumeLabel вы можете изменить название тома:

BOOL SetVolumeLabel (lpszRoot, lpszVolume); // не реализована в Win32s!

Существует специальная функция, осуществляющая взаимодействие непосредственно с драйверами устройств. В некоторой степени применение этой функции может рассматриваться аналогично функциям MS-DOS 0x44?? (device I/O control, IOCTL), однако возможности данной функции гораздо шире. В числе интересных -- возможность узнать, заменялся-ли том в устройстве со сменными носителями (например, гибкий диск), узнать производительность устройства, отформатировать том (дорожки диска), получить информацию о разбиении диска на разделы и даже разбить диск на разделы по-новому, а также многое другое. Функция требует, что бы ей был передан хендл, описывающий данное устройство. Для того, что бы получить этот хендл, можно воспользоваться функцией CreateFile (см. ниже), передав ей условное имя файла, в виде \\.\A: -- для доступа, например, к тому A (буква, естественно, обозначает тот диск, к которому нужен доступ), или \\.\PhysicalDrive0 -- для доступа к физическому жесткому диску 0 (цифра -- номер жесткого диска, как он подключен к контроллеру, обычно 0 или 1). Обратите внимание, что в тексте программы символы “обратная косая черта” должны быть повторены дважды, например “\\\\.\\A:”.

Внимание! для доступа к дискам в Windows NT необходимо иметь права доступа администратора системы!

BOOL DeviceIoControl(// не реализована в Win32s!

hDevice, dwIoControlCode,

lpvInBuffer, cbInBuffer,

lpvOutBuffer, cbOutBuffer,

lpcbBytesReturned,

lpoOverlapped);

В этом разделе дополнительно будут обзорно рассмотрены еще две функции, предназначенные для работы с устройствами (это не обязательно тома). Эти функции реализованы только в Windows NT, так что применяются крайне редко -- обычно стараются разрабатывать приложения, переносимые между разными реализациями Win32.

BOOL DefineDosDevice(dwFlags, lpszDeviceName, lpTargetPath);

DWORD QueryDosDevice(lpszDeviceName, lpBuffer, cbMaxSize);

Обе функции жестко привязаны к тому, как в Windows NT осуществляется доступ к ее устройствам: в системе существуют свой собственный способ определения всех устройств. Например, имя \Device\Parallel0 определяет первый параллельный порт. Однако, обычно для того-же самого используются имена типа LPT1, вошедшие в обиход со времен, более древних, чем первые IBM PC XT. Для удобства в Windows NT определена специальная таблица, устанавливающая соответствия между именами устройств “в стиле MS-DOS” и именами в системе. Эта таблица глобальная, все работающие приложения (не только приложения MS-DOS) осуществляют доступ к устройствам посредством этой таблицы.

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

Имеется одна несколько странная особенность этих функций -- обычно функции Win32 API, не реализованные на той или иной платформе возвращают код ошибки ERROR_CALL_NOT_IMPLEMENTED, который можно получить посредством функции GetLastError. Выглядит такая проверка примерно так:

DefineDosDevice(0, "Z:", buffer);

if (GetLastError() != ERROR_SUCCESS) {

// возникла ошибка - может быть функция не поддерживается

} else {

// все в порядке, работаем как обычно}

Несколько неожиданно, что в Windows 98 эти функции не устанавливают код ошибки, функция GetLastError возвращает код ERROR_SUCCESS. Однако о корректной работе функций говорить к сожалению не приходиться... Подробнее -- в приводимом ниже примере.

Пример 2B -- работа с томами

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

Интересно рассмотреть, каким образом осуществляется вывод информации о томах в окно приложения. Это можно было-бы реализовать разными способами:

Хуже некуда. Изменить в примере 1B.CPP обработку сообщения WM_PAINT (функция Cls_OnPaint), так, что бы при обработке сообщения опрашивать все устройства и выводить необходимую информацию. Очень плохо в этом то, что такой опрос может занимать значительное время, и приводить к обращениям к устройствам при каждой перерисовке окна. Еще хуже то, что при попытке чтения информации с устройства возможно возникновение ошибок, о которых система будет сообщать в отдельном всплывающем окошке, например “Cannot read from drive A:”. Это окошко окажется, с большой вероятностью, поверх окна приложения, следовательно, при закрытии окна сообщения, наше приложение снова получит сообщение WM_PAINT, снова попробует обратиться к тому-же устройству ... и так далее (что бы этого избежать можно воспользоваться функцией SetErrorMode, отключив вывод сообщений об ошибках).

Чуть лучше. Считывать информацию об устройствах при создании окна, формировать где-то в памяти весь текст, затем отображать его при обработке WM_PAINT. Этот способ качественно лучше тем, что получение данных и их отображение осуществляется в разных местах программы и в разное время. Однако и у него есть минусы -- список устройств может изменяться во время работы приложения, а оно этого не отразит, и, кроме того, список может оказаться достаточно большим -- больше размеров окна. Первую проблему мы решать сейчас даже не будем -- этого легко добиться введя меню с командой Обновить (Refresh) или выполняя такое обновление через определенный интервал времени. Вторая проблема приведет к добавлению собственного интерфейса -- обработке сообщений клавиатуры и мыши, что потребует написания значительного кода и продолжительной отладки.

Еще лучше. Чуть разовьем второй способ -- получать информацию будем при создании окна, а отображение и работу с мышью и клавиатурой переложим на Windows. Windows предоставляет разработчикам несколько стандартных классов окон, реализующих самые распространенные элементы управления -- кнопки, флажки, списки, простейшее окно-редактор и другие. Вот окном-редактором мы и воспользуемся, причем специально укажем, что текст является неизменяемым, то есть редактор будет работать как окно просмотра. В этом случае при создании главного окна приложения, мы должны создать дочернее окно-редактор, занимающее всю внутреннюю область главного окна Подробнее о работе с окнами смотри в соответствующих разделах.. Затем, сформировав весь необходимый текст, передать его редактору. Окно редактирования будет снабжено полосами прокрутки, поддерживать работу с клавиатурой и мышью, осуществлять передачу текста в буфер обмена -- и все само, без разработки дополнительного кода. Мы должны доделать совсем немного -- обрабатывать сообщения, связанные с изменением размера главного окна (соответственно менять размер дочернего окна), при уничтожении главного окна не забыть уничтожить окно-редактор, а сообщение WM_PAINT мы можем вообще не обрабатывать.

Приложение рассчитано на работу в Win32, однако это связано только лишь с применением функций Win32 API для получения информации о томах. При создании приложения для Windows 3.x вместо функций, не декларированных в Windows API, используются функции-эмуляторы, включаемые в это приложение при компиляции 16ти разрядного приложения. Это обеспечивает возможность нормальной компиляции и работы приложения на обеих платформах, но с несколько ограниченными возможностями в случае применения Windows API (строго говоря, функции-эмуляторы можно было бы сделать и более мощными, опираясь на функции и структуры данных MS-DOS -- просто это выходит за рамки данной книги).

Функции DefineDosDevice и QueryDosDevice, применяемые в числе прочих в этом приложении, работают только в виде 32х разрядного приложения и только под Windows NT, так как они имеют смысл исключительно для реализации Win32 в Windows NT.

Файл 2B.CPP

#define STRICT

#include <windows.h>

#include <windowsx.h>

#define UNUSED_ARG(arg) (arg)=(arg)

#ifndef __NT__

// определим необходимые функции при компиляции для Windows API

#include "2b16.cpp"

// текст файла 2b16.cpp приведен ниже

#endif

static char szWndClass[]= "test volume functions";

static HINSTANCE hInstance;

BOOL Cls_OnCreate(HWND hwnd, LPCREATESTRUCT lpCreateStruct)

{UNUSED_ARG(lpCreateStruct);

char *temp, *p, *s;

DWORD n, i, sernum, complen, flags, spc, bps, fc, tc;

char file_system[ 128 ], buffer[ 1024 ];

UINT count, errmode;

HWND hwndView;

RECT rc;

HFILE hf;

static OFSTRUCT ofs;

static char tempfile[] = “c:\\test.txt”;

static char devZ[] = “Z:”;

// создадим окно-редактор, занимающее всю внутреннюю область окна

GetClientRect(hwnd, &rc);

// теоретически в CREATESTRUCT указаны размеры окна, но к сожалению они

// могут быть указаны как нулевые, хотя это не так. Функция GetClientRect

// в этом случае все равно возвращает корректные данные

hwndView = CreateWindow(

"EDIT", "",

0, 0, rc.right, rc.bottom, hwnd, (HMENU)1, hInstance, NULL);

if (!IsWindow(hwndView)) {

// если окно просмотра создать не удалось, то завершаем приложение

// сообщив об ошибке

MessageBox(NULL, "Cannot create viewer window!", NULL, MB_OK);

return FALSE;}

// для красоты используем моноширинный шрифт (подробнее см. GDI)

SetWindowFont(hwndView, GetStockObject(ANSI_FIXED_FONT), FALSE);

// функция SetWindowFont в документации не описана, это макрос, определяемый

// в windowsx.h Подробнее -- см. исходный текст этого файла.

// запоминаем хендл окна просмотра в структуре описания главного окна

// (при регистрации класса надо зарезервировать 4 байта -- что бы и в

// Windows API и в Win32 API использовать одинаковые значения и функции)

SetWindowLong(hwnd, 0, (LONG)hwndView);

// 1. мы не знаем заранее, как много места понадобиться для описания всех

// томов и устройств DOS. Для простоты создадим временный файл с заранее

// заданным именем c:\test.txt (строго говоря, надо было бы проверить наличие

// переменной TEMP или TMP, убедиться, что она указывает на корректный

// каталог - в жизни часто она указывает на несуществующий каталог, диск

// или даже на защищенный диск - всякое бывает - и создать файл там -- но это

// все слишком громоздко для примера).

// 2. в этом файле мы соберем нужный текст, а затем разом передадим его окну

// просмотра, после чего файл удалим.

// 3. для работы с файлами используем функции Windows API, что бы сохранить

// переносимость между разными платформами

hf = _lcreat(tempfile, 0);

if (hf == HFILE_ERROR) {

// при ошибке - сообщаем и заканчиваем (окно просмотра будет уничтожено

// позже, при обработке WM_DESTROY

MessageBox(NULL, "Cannot create temporary file!", NULL, MB_OK);

return FALSE;}

// пишем первый заголовок

_lwrite(hf, "******** GET VOLUME INFORMATION ********\r\n\r\n", 44);

SetLastError(ERROR_SUCCESS);

n = GetLogicalDriveStrings(0, NULL);

if (GetLastError() != ERROR_SUCCESS) {

// Функция GetLogicalDriveStrings не реализована в Win32s и (в книгах

// часто утверждают) в Windows-95, возможно, иногда это и так, но у меня

// в Windows-95 версии 4.00.950a, локализованной для России, работает.

// если все же нет, то эмулируем ее работу посредством GetLogicalDrives

// которая точно есть во всех реализациях Win32

n = GetLogicalDrives();

// узнаем, сколько всего устройств

count = 0;

for (i = 1; i; i <<= 1) if (n & i) count++;

// формируем строку с именами устройств

temp = new char [ count * 4 + 1 ];

if (temp) {

p = temp;

for (i = 0; i < 32; i ++) if (n & (1L << i)) {

*p++ = (char)('A' + i); *p++ = ':'; *p++ = '\\'; *p++ = '\0';}

*p++ = '\0';}

} else {

// если функция GetLogicalDriveStrings работает, то используем ее

temp = new char [ n + 1 ];

if (temp) GetLogicalDriveStrings(n, temp);

}

if (temp) {

// исключаем обработку сообщений о критической ошибке

errmode = SetErrorMode(SEM_FAILCRITICALERRORS);

// если строка получена, то разбираем ее по частям

for (p = temp; *p; p += lstrlen(p) + 1) {

wsprintf(buffer, "Root: %s", p);

switch (GetDriveType(p)) {

case 0: s = "???"; break;

case 1: s = "invalid"; break;

case DRIVE_REMOVABLE: s = "REMOVABLE"; break;

case DRIVE_FIXED: s = "FIXED"; break;

case DRIVE_REMOTE: s = "REMOTE"; break;

case DRIVE_CDROM: s = "CD-ROM"; break;

case DRIVE_RAMDISK: s = "RAM DISK"; break;

default: s = "what?!"; break;}

// укажем явное преобразование указателя на строку `s' к типу

// LPSTR -- так как в Windows API для моделей памяти с одним сегментом

Страницы: 1, 2