проблемы работы с директориями Опции

[ddn]

Есть много вопросов по работе в BP7, TMT (3.90), FPC (2.4.0.i386-win32) под WinXP:
1) верно ли, процедуры FindFirst и FindNext могут одновременно работать с несколькими директориями и даже с одной директорией через несколько указателей;
2) верно ли, что указатель поиска в директории определяется только записью файла SR (тип TSearchRec), но не директорией в которой она расположена, т.е. только по записи файла SR возможно непосредственно определить ее директорию и ее расположение в директории;
3) верно ли, что вызов FindNext(SR) возвращает в SR следующую запись (если она есть, если нет - SR неопределено или исходное значение?) в директории ее (исходной записи SR) расположения, а не в директории из последнего вызова процедуры FindFirst;
4) верно ли, что вызов FindClose(SR) прекращает поиск (работу с указателем) в директории расположения записи, а не в директории из последнего вызова процедуры FindFirst, поиск в других директориях не прекращается (непонятно, зачем вообще нужна эта процедура, если вся работа идет с данными из записи SR);
- без выполнения данных взаимосвязанных утверждений рекурсивный поиск в директориях НЕВОЗМОЖЕН (по крайней мере, без создания списков их содержимого),

далее:
5) верно ли, что путь к директории в вызове процедуры FindFirst должен заканчиваться разделителем '\';
6) возможна ли проверка существования файла, директории или лог. диска по его имени/полному_имени без использования процедур FindFirst и FindNext;
7) возможна ли работа с текущей директорией (получение абс. пути, изменение);
8) верно ли, что имена директорий SR.name в их записях SR из их наддиректорий не содержат разделителя '\';
9) верно ли, что записи в любой не изменившейся директории при каждой ее обработке процедурами FindFirst и FindNext выдаются в одном и том же порядке (лексикографическом по именам?);
10) как обеспечить работу с длинными именами файлов (как вызвать Win под FPC);
11) верно ли, что поле Time в TSearchRec - это время создания файла (если нет, как узнать/изменить время создания), или это время его последнего изменения/открытия;
12) что представляют собой неизвестные компилятору типы полей записи SR файла в директории под Win: TFileName (=string ?), THandle, TWin32FindData, каким характеристикам файла они и Fill (тип array[1..21] of Byte) отвечают;

Win32 target
type
  TSearchRec = record
    Fill : array[1..21] of Byte;
    Attr : Byte;
    Time : Longint;
    Size : Longint;
    Name : TFileName;
    ExcludeAttr : Longint;
    FindHandle : THandle;
    FindData : TWin32FindData
  end;

[TarasBer]

> (* Dir1 - директория расположения записи SR1 *)

Дальше не читал. Что имеется в виду? Проходим по директории Dir при помощи записи SR1 (храня временные результаты в ней). Так и надо писать.

[ddn]

> (* Dir1 - директория расположения записи SR1 *)

Дальше не читал. Что имеется в виду? Проходим по директории Dir при помощи записи SR1 (храня временные результаты в ней). Так и надо писать.

Записи файла расположенной в бинарном содержимом директории, а отвечающего ей файла - содержащегося в директории.

Первоначально, я решил что SR просто вспомогательная переменная, хранящая только значение элемента каталога = запись некоторого файла из этого каталога (т.е. содержащей характеристики файла и его индекс/адрес_начального_байта). Но тогда SR не привязан ни конкретному каталогу, ник его структуре, ни к маске, ни к указателю поиска. А где тогда могут храниться параметры и указатель поиска? - только в некоторой ГЛОБАЛЬНОЙ переменной ОСи одной для всех каталогов, либо по одной для каждого открытого каталога.

Потом подумал, может SR это дескриптор каталога, как при чтении любого типизированного файла (тип = каталоговый). Любой дескриптор неявно хранит положение указателя после открытия файла. Связывание и одновременное открытие с чтением первого элемента осуществляется процедурой FindFirst (вместо Assign, Reset и первого Read). Маска задается не типом SR, а при открытии (как и число считываемых байт для нетипизированных файлов) и также неявно хранится в дескрипторе. Но дескриптор не имеет компонент, ему нельзя присваивать, нельзя использовать в выражениях (присваивать его, сравнивать).

Теперь выходит, что SR это некий гибрид буферной переменной (копия паспорта файла) и дескриптора поиска.
Последний хранит (все?) параметры конкретного поиска ЛОКАЛЬНО: адрес каталога, маска, адрес текущей записи поиска, дерева поиска каталога или адреса его отдельных узлов (само дерево хранится в бинарном содержимом каталога либо создается динамически). Поскольку тип SR не ссылочный, то память под нее освобождаться не может, SR определенно содержит ссылку на какую-то безымянную динамическую структуру, создаваемую под поиск, иначе какой смысл в процедуре FindClose?
Значит можно даже в одном каталоге одновремено вести несколько независимых поисков, хотя копировать одну переменную SR в другую SR0 и затем вести независимый поиск по каждой из них все же нельзя (ведь указанная динамическая структура не скопируется так просто, останется общей для SR и SR0).
Хм, интересно, что будет, если каталог изменяется во время поиска?

Если так, моя программа в принципе должна работать правильно.
Для компиляции возможно не хватает подсоединения каких-то модулей и директив.