Использование длинных путей Pascal

[mons]

- выходим из среды, при этом TP ругнется, что не может сохранить настройки (путь ведь поменяли)
- в строке приглашения интерпретатора видим, что сидим в той папке, где надо.

Вроде все правильно сделал, тут и ошибиться то негде, но в итоге не выходит.
- при выходе из среды TP не ругнулся, а вежливо предложил сохранить изменения
- и путь не поменялся, а остался я сидеть в Паскалевской папке
Кстати верся TP7.1

[mons]

Так, вроде все работает.
Но появилась другая проблема: мне надо в этой папке похимичить с файлами, но при использовании append,reset,rewrite,erase и т.д. пишет path not found.
Я так понимаю теперь для каждой такой команды надо какие-то вставки на ассемблере писать?

[somewhere]

Видимо да, все зависит от самих манипуляций с файлами. Только тут уже будут другие файловые переменные, точнее их хендлы. По большому счету для обычной работы всего 3 небольшие процедуры - открытие, чтение, запись. Для тех, кому надо много файлов открывать - еще и закрытие. Если сложность задачи позволяет переписать стандартные функции работы на свои - то нет проблем, хотя отличий от снандартных в параметрах очень мало.
Непонятно только одно - почему разработчики Borland решили использовать именно те функции MS-DOS, в которых есть ограничение на длину пути 64-байтным массивом, хотя ничего нигде не сказано по этому поводу - все хэлпы молчат в тряпочку, пока внутрь системы не копнешь - не узнаешь...

[Игорь Акопян]

использовать Subst на полпути?

[mons]

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

[BBB]

Не знаю, в тему я или нет, но на всякий случай напишу.
В Windows есть функция "Получить короткое имя файла", т.е. имя файла, где и имя самого файла, и всех каталогов пути будет в формате 8+3.
Причем, эта функция (через соответсвующее прерывание) доступна и из DOS-программ. Написал я в свое время для себя такой unit (чтобы можно было в DOS-паскалевской программе обрабатывать длинные именя). Если интересно, могу привести исходный текст.

[Игорь Акопян]

суть в общей длине пути а не в длинном имени файла/папки
Просто очень большая вложенность, только вот зачем? Если уж не уйти от такой вложенности - я бы решал проблему Subst'ом

[BBB]

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

[somewhere]

Подгоняя длину пути под 64 байта проблему не решить. Тут два пути - создать каким угодно способом отражение папки в диск (например, подключить сетевой диск к самому себе или использовать средства администрирования) или создать процедуры-эквиваленты стандартным используя ассемблер (назвать их например, OpenFile, CloseFile, ReadFromFile, WriteToFile). Subst тоже вряд-ли проканает, потому как корень проблемы в Assign и ChDir. Точнее в используемых ими функциях MS-DOS Open File и Set Current Directory. Ну так что, процедуры выкладывать на ASM?

[mons]

Ну так что, процедуры выкладывать на ASM?

Он еще спрашивает, конечно, выкладывай, если не сложно. Буду рад поюзать.