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

[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;

[volvo]

Может, всё-таки процессор? Инструкция call какбы.

Ну да, процессор, ОС, все что угодно. Компилятор умеет условия для работы создавать...

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

Значит, плохо ведом. Паскаль не разрешает (за исключением Extended Pascal, реализуемого компилятором GPC) конструировать функциональный тип в заголовке процедуры. Сначала опиши тип-функцию, потом (в заголовке) - подставляй идентификатор этого типа.

Стиль Паскаля - аварийный вылет при ошибке!
Обработка ошибок, операторы, возвращающие значения и коды ошибок - это СИшная ересь!

Это ты говоришь, что тебе ведом Паскалевский стиль? Если тебе так хочется думать - это твои проблемы. Вообще-то IOResult/DOSError + директива {$I} для отключения моментального вылета, как раз для того, чтобы можно было обработать ошибку - это все есть в паскале, начиная с 3-ей версии. На более старых просто не работал, возможно оно и там есть... Мало того, тебе даже предоставляются возможности (опять же, начиная как минимум с версии 5.5) искусственно создать ошибку, чтобы проверить, как твой код умеет её обрабатывать... А ты говоришь - вылет. Вылет программы в некоторых местах равносилен вылету с работы, причем еще и с занесением в черный список. Будешь потом улицы мести, если возьмут...

Хм, стек имеет тенденцию переполняться

Хм. Ты работаешь на WinXP? Тебе не хватит допустимой вложенности папок (да, да, и у NTFS тоже есть ограничения), чтобы переполнить стек, в особенности, если пользуешься современным компилятором, таким, как FPC. В котором, кстати, размер стека можно и увеличить, если что...

в классическом Паскале вообще нет работы с внешними файлами

А в Паскале ее и не должно быть. Должно быть обращение к функциям ОС для того, чтобы на этой ОС уже работать с ее функциями (насчет бестолковости или толковости - это ты сначала на свой код посмотри, а потом будешь WinAPI обсуждать). Если Турбо-Паскаль был написан в то время, когда кроме DOS ничего не было (а если и было - то TP там не запускался), то ничего кроме Uses DOS в языке и быть не должно. То, что ты запускаешь TP под Windows - это ни разу не проблема Паскаля. Это проблема твоя. Есть компиляторы под Windows - пользуйся ими, там прекрасно реализована работа с WinAPI. Или вообще кроссплатформенные версии - но за это будешь платить размером исполняемых файлов, в частности. Не веришь? Запусти Лазарус и откомпилируй приложение, показывающее форму с одной кнопкой. 12Мб EXE-шник тебе обеспечен. Дельфи (упс, это же только Windows, может поэтому размер EXE-шника меньше? Не надо заботиться о том, как этот же код должен компилироваться в другой ОС, не надо делать обертки разные?) тебе в таком случае уложится в 200К, а на чистом API можно и в 30К уложиться (но это еще ближе к ОСи, замечаешь?). Ты все еще хочешь универсальности, чтоб можно было из любой ОСи работать с функциями ОС однотипно?

а вот в компиляторах полно ограничений, начиная с отсутствия отладчика

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

Ну почему нельзя было сделать расово верный идейно правильный набор примитивов работы с файловой системой - через типизированные указатели для файлов и каталогов, а работу с Dos и Win скрыть от программиста!

И чем тебе FPC-шный FindFirst (из модуля SysUtils) - не расово верный? Работает и под ДОС, и под Windows, да и Unix-ы тоже не забывает. Я ж не виноват, что кое-кто не умеет читать доки, правда?

Как работать с длинными именами файлов, с временем создания файла, полными путями к файлам длинее 255 символов?

Пользоваться современными компиляторами, в них нет этого ограничения. Либо сторонними модулями (типа LDos) для старых компиляторов.