diamond
Проблема не в том, что путь будет длинным, а в том, что Tinypad использует функцию 58 (не 70). Думаю, изменения будут минимальными.

diamond

Никто не против удаления подфункций 12, 13, 14 функции 58? Их всех заменяет 70.5, я не знаю программ, использующих эти подфункции, кроме того, они не поддерживаются для дискет.

Давай оставим этот вопрос до того момента как перепишем все приложения под 70 функцию.

На очереди подфункция 7 - запуск файла с длинным именем. Тут есть две концептуальные трудности:

1) Переписать функции работы с файловой системой не настолько сложно, так что это решаемо.
2) Есть варианты: а) производить отсечение имени, б) переписывать все приложение. Первое быстрей и проще, второе дольше и сложней. В общем надо подумать.

Удалены подфункции 12, 13, 14. Если какие-то приложения перестанут работать - будем разбираться.

В общем надо подумать.

Ну так давайте подумаем Для этого я и задал вопрос.

diamond
Ну, я больше склоняюсь к тому, что лучше переписать приложения использующие путь. Вроде бы кроме Tinypad написанного mike.dld других приложений нету.
Отсечение имен все же не катит.

По поводу пути - на самом деле если имена папок укладываются в 8.3 байта, то можно использовать как 58-ю, так и 70-ю функцию. Так что частично работать будет. А вот что с именем процесса? Этот вопрос поважнее будет.

diamond
А почему обязательно имя процесса должно совпадать с именем файла? Можно урезать, до нужного числа символов и вообще вроде важен PID процесса, а не имя.

Mario79
А для чего оно вообще введено? Чтобы на панели и в списке процессов можно было узнать нужный процесс. А также некоторые программы могут ориентироваться на имя и, скажем, если запущен процесс cmd, то найти его PID и далее общаться с ним по IPC.

diamond
Ну, а что ты сам тогда предложишь, кроме урезания имени? Переделывать всю структуру, реализованную в ядре? Хлопотное дело будет.

Ни в коем случае! Кстати, я ничего и не предлагаю... Об урезании: что делать с расширением? В текущей реализации расширение (если есть) записывается в последние 3 (из 11) символов. Кажется, @panel на расширение забивает. Что происходит в cpu, я просто не знаю (просветите, а?)

diamond
Дело в том, что у исполняемых файлов нету расширения.
И соответственно имя записывается, как есть.
CPU выводит ровно то, что получает от функции 9.

Тем не менее ничего не мешает запустить файл 1.bin (конечно, если он окажется Kolibri-приложением).

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

Теперь функция 70 умеет работать с папками на рамдиске.
Добавлена функция 70.7 запуска приложений. Замечания:
1. Путь (если он требуется) передаётся "как есть", т.е. как его передало 70-й функции запускающее приложение. При этом длина пути с учётом завершающего нуля не может превосходить 1024 символов (иначе вызов 70-й функции провалится).
2. Файл загружается целиком.
3. Гарантированно обнуляется вся память после конца файла. Для 19-й и 58-й функций неопределено состояние последнего 512-байтного блока. Т.е. если файл занимает 800 байт, то при запуске 19-й или 58-й функцией 224 байта после его конца неопределены (обычно там нули, но полагаться на это нельзя).
(Дальше следуют замечания по реализации)
4. Помещать вызов *fileread в блоки cli/sti (cli/safe_sti для рамдиска), как это сделано в старых функциях, я не стал, поскольку это вообще не нужно.
5. В newproce.inc наряду с тремя старыми функциями для rd, fd, hd появилась одна новая, унифицированная.

diamond
Есть вопросы по твоим пунктам:
1. Почему только 1024? ИМХО мало, надо хоть подогнать под размер сегмента тогда и сделать 4096 хотя бы.
3. Обнуляется только до конца сегмента или вся рабочая память запрошенная под приложение?