"..\" означает родительский каталог для текущего. Но в системе нет понятия текущего каталога. Я не могу вызвать для своей программы SetCurrentDir("d:\\os\\Kolibri\\programs\\my_program") и потом открывать файлы в этой папке просто open_file("my_file.1") open_file("my_file.2) или open_file("..\another_file.dat") для файла который находится в папке d:\os\Kolibri\programs. Система просто не поймет что значит "..\" потому что у нее нету понятия о текущих (рабочих) каталогах. А поддержка папок на рамдиске не самая актуальная проблема. Работа с каталогами на дисках намного важней. Думаю что стоит взять для примера файловые функции MS DOS, посмотреть как они работают и сделать свои аналоги. Этого хватило бы для нормальной работы файловой системы и для портирования C ( fopen, fread, fwrite, fseek).

Serge
Я не очень люблю СИ.
Но это ИМХО (поташнивает меня от него, несварение, однако).
А разве трудно сделать такую вещь как "..\" на уровне приложения? Код, который добавляет к названию файла еще и путь достаточно прост в моем понимании, а для ядра опять таки придется выделять область памяти, где будет, хранится этот путь, причем для каждого приложения своя область. Все реализуемо на уровне приложения, зачем нагружать ядро?
Не понимаю я этого удобства, наверное, это скорее сила привычки.

Это ведь не только C но и другие языки программирования. А относительные пути это ведь не прихоть MS DOS, всё идёт от UNIX и теперь во всех системах. Если этого не делать, то портировать код будет намного сложнее. Это пока программы достаточно простые и обходятся без своих каталогов. А попробуй представить здесь какой-нибудь майл-клиент или Firefox c кучей папок, пойдут проблемы. В общем получается спихивание проблемы на прнкладного программера. А они этого не любят и просто выбирают другие ОС.

Я тоже не очень люблю C,но приходиться на нем писать,так как не многие знают ассемблер.
Сейчас пишу на C одну программу.И всё больше понмаю,что по сравнению с ассемблером,C более ущемленный язык.То что на ассемблере делается легко,в C требует знания всяких библиотечных функций из-за которых алгоритм нагромождается и код разбухает.А вот математическая часть в C довольно прилично компилируется(если алгоритм короткий).Но с усложнение алгоритма,код становиться всёмене оптимальнее и начинает в разы и в десятки раз проигрывать ассемблеру.

Но без знания C невозможно портировать: Mesa(отрытая реализация библиотеки OpenGL),видео декодеры,интернет браузеры(пока нет ассемблерщика хорошо разбирающегося в сетевом программироании) и некоторые другие программы.
Знание C -это необходимость.

Mario79 wrote: А разве трудно сделать такую вещь как "..\" на уровне приложения? Код, который добавляет к названию файла еще и путь достаточно прост в моем понимании, а для ядра опять таки придется выделять область памяти, где будет, хранится этот путь, причем для каждого приложения своя область. Все реализуемо на уровне приложения, зачем нагружать ядро?

А одновременный доступ к файлам тоже на уровне приложения делать? Вообще я тихо офигеваю от того, что приложение должно выделять буфер для работы файловой функции ОС.

А чтение файлов фиксированными блоками?

При чём здесь фиксированные блоки?

>При чём здесь фиксированные блоки?

Вот до чего доводит программирование на C.Люди начинают думать,что при чтении файла кэш память под блоки(файл ведь по блокам читается) не выделяется.А куда он по вашему должен деться ?
Для чего пишется
указатель=fopen("file.dat","r"); ?

В C эти проблемы берет на себя компилятор,а в ассемблере программист сам говорит сколько блоков(у каждого блока свой номер) и куда загружать.


>А одновременный доступ к файлам тоже на уровне приложения делать?

А это вообще забота операционной системы(точнее драйвера файловой системы).Програмист вызывает системную функцию чтения файла,а как организовать очередь доступа к файлу - это забота драйвера.

Вот до чего доводит программирование на C.Люди начинают думать,что при чтении файла кэш память под блоки(файл ведь по блокам читается) не выделяется.А куда он по вашему должен деться ? Smile
Для чего пишется
указатель=fopen("file.dat","r"); ?

Файловый ввод/вывод в Си корнями уходит в Unix и работает не с собственно файлами, а с потоками в том числе stdin, stdout, stderr. Но вот прерывания ДОС позволяют читать/писать произвольное количество байт и с произвольной позиции так же как и ReadFile/WriteFile в WinAPI и без всяких блоков и вспомогательных буферов, поэтому я пользуюсь ими а не Си-шными fread/fwrite. Если мне надо считать из файла 20 байт по заданному адресу в структуру то мне не надо определять номер блока, считывать весь блок в специальный буфер и потом уже копировать необходимые данные. Все заботы по кешированию и буфированию берёт на себя система. А если использовать CreateFileMapping/MapViewOfFie то с файлом можно работать так, словно он весь уже загружен в память. Удобно однако

andrew_programmer wrote: Вот до чего доводит программирование на C.Люди начинают думать,что при чтении файла кэш память под блоки(файл ведь по блокам читается) не выделяется.А куда он по вашему должен деться ?

Вот кусок из инструкции:

======================================================================
========== Функция 58, подфункция 0 - прочитать файл/папку. ==========
======================================================================
Параметры:
* eax = 58
* ebx = указатель на информационную структуру
Формат информационной структуры:
* +0: dword: 0 = номер подфункции
* +4: dword: номер блока для чтения (считая с 0)
* +8: dword: число блоков для чтения
* +12 = +0xC: dword: указатель на буфер, куда будут записаны данные
* +16 = +0x10: dword: указатель на буфер для работы системы
(4096 байт)
* +20 = +0x14: ASCIIZ-имя файла, правила формирования имён указаны в
общем описании


Ну-ка расскажи, зачем тут нужен буфер по смещению 16? И каким образом чтение файла по блокам спасёт его от модификации другой программой?

andrew_programmer wrote: >А одновременный доступ к файлам тоже на уровне приложения делать?
А это вообще забота операционной системы(точнее драйвера файловой системы).Програмист вызывает системную функцию чтения файла,а как организовать очередь доступа к файлу - это забота драйвера.

Так вот, выделением буферов под нужды операционной системы должна заниматся ОС, а не приложение.

rabid rabbit wrote:Ну-ка расскажи, зачем тут нужен буфер по смещению 16?

Для привидения имени файла в формат 8.3.

Ещё раз, почему выделением буфера под нужды ОС должно заниматься приложение?

Serge
Прикладные программеры много чего не любят.
Они вообще любят лепить код парой щелчков мыши, а то, что он будет занимать по 1-2 Мб на каждый щелчок мышки их как-то слабо интересует. В результате пользователь, тихо матерясь, и проклиная все на свете, покупает новый комп, потому что "Наш новый софт на новом железе работает быстрей, чем старый на старом".
Извиняюсь за флуд, но пробило, мочи нету.

Если ты считаешь что:

Если мне надо считать из файла 20 байт по заданному адресу в структуру то мне не надо определять номер блока, считывать весь блок в специальный буфер и потом уже копировать необходимые данные. Все заботы по кешированию и буфированию берёт на себя система. А если использовать CreateFileMapping/MapViewOfFie то с файлом можно работать так, словно он весь уже загружен в память. Удобно, однако

То это можно со временем реализовать, не все сразу, однако. Проблемы мы решаем по мере поступления. Если оно не решалось раньше, значит, никто не ставил такой задачи и очень может быть, просто не было людей, который могли четко сформулировать конкретные вопросы. Ведь очень часто только и слышно "У вас нету, того и этого" при этом люди сыплют терминами мало распространенными и специфичными, даже не пытаясь объяснить суть. На вопросы что это такое обычно молчание с намеком, "Какие все тут ламеры", впрочем, речь не идет о постоянных посетителях форума.

rabid rabbit

А одновременный доступ к файлам тоже на уровне приложения делать? Вообще я тихо офигеваю от того, что приложение должно выделять буфер для работы файловой функции ОС.

Я конечно отмазываюсь, но:
1) Это разработано еще Великом - большим специалистом по написанию ОС (он уже 4-ю ОС пишет, насколько я понимаю).
2) Что офигительного в выделении буфера в области приложения? Приложение что жаба задушит?
Ядро все равно с одинаково скоростью организует доступ, что к памяти, отведенной под себя, что к памяти отведенной к приложению.
Конкретно выделив место под буфер, нет нужды занимать стек, то есть, он лишний раз не распухнет, и не дойдет критического значения, то есть не пересечет выделенную для него область.
Теперь приведи свои доводы против такой реализации (не считая эмоций) и того, что так не привычно, я с удовольствием выслушаю и возможно мы изменим ситуацию.

Mario79
Конечно файловые сервисы одни из самых сложных в любой ОС и за два дня их не напишешь. Я это прекрасно понимаю. Но всё же, думаю стоит взять за основу хотя бы функции MS DOS. Можно конечно идти своим особым путём но тогда не стоит ждать, что будет большое количество желающих написать что-то для Колибри.
Что касается места под буфер то скорее всего нужен один буфер на все приложения. А если каждая программа будет выделять свой собственный буфер, то будет впустую расходоваться память. Еще один аргумент. Файловые сервисы могут выполняться не в контексте вызвавшей задачи, а отдельным потоком в адресном пр-ве ядра. Такая схема сложнее но надёжней потому что только один сервис будет иметь доступ к диску и можно избежать ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала.