Робота з файлами, каталогами і дисками в Win32. Отримання інформації про диски, вільний простір

Файлова система
Для роботи з файлами в 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 містить несподівано багато таких помилок, причому як в бібліотеках часу виконання, так і в самому середовищі.
Ще один нюанс, щоправда порівняно невеликий, пов'язаний з тим, що символ "." (Точка) може зустрічатися не тільки для відділення імені від розширення, але також і в самому імені, причому неодноразово. У таких випадках під розширенням мається на увазі частина імені, відокремлена самій правій точкою. Ця особливість порівняно рідко призводить до помилок, тому що при розборі імені його зазвичай аналізують справа наліво [0].
Крім цього слід врахувати, що в іменах файлів можуть зустрічатися дві косі риси поспіль. Так, наприклад, відкриття файлу з ім'ям "\ \. \ 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. Однак про коректній роботі функцій говорити на жаль не доводиться... Докладніше - в наводиться нижче.