о файлах-имиджах
-
Давайте сделаем поддержку сменных RAM-дисков...то есть на винте с FAT32 или FAT16 ищем, например в MFAR, файл типа disk1.img (длиной 1 474 560, тип FAT12) и нажатием отдельной кнопки "монтируем" этот файл на свободный RAM-диск...плюс отдельной программой скидываем содержимое любого из RAM-дисков (думаю, 4 штук одновременно хватит) на дискету или обратно в его файл-имидж (т.е. список кластеров для этого файла запоминаем при считывании в отдельную область в пространстве ядра...для FAT32 и 512-байтных секторов - самый длинный список - это будет 4 байтаx2880 кластеров = 12 Кбайт)...т.е. не делаем запись для логических дисков с FAT12 и FAT32 (чтобы не нарушить данные при расширении каталогов для записи в них новых файлов или некорректной записи в таблицу FAT), а реализуем только чтение каталогов (для вывода списка файлов), проверку типа файла (действительно ли img-файл - по сигнатуре FAT12) и чтение сначала списка его кластеров, а потом и всего содержимого...
А зачем сменные рамдиски, если есть доступ к винту? По-моему с винтом удобнее работать.
На продвинутых Спектрумах как раз было сделано так: образа дискет *.trd хранятся на винте и при необходимости можно было их открывать в файловом менеджере и работать с ними как с рам-диском.
А можно ли обойтись без RAM-диска вообще? Чтобы ядро с винтом работало?
kiwi_mani
Violinier
Эта идея уже давно предлагается и рассматривается и возможно в некотором не очень отдаленном будущем будет реализована. Особенно это будет полезно для компов с малым количеством ОЗУ (менее 16 Мб.)
Правда это потребует переписывания некоторого количества приложений и оптимизации существующего драйвера FAT16/32.
Также потребуется наличие инсталлятора. Для очень ленивых пользователей.
german
В чем юмор?
Эта идея уже давно предлагается и рассматривается и возможно в некотором не очень отдаленном будущем будет реализована. Особенно это будет полезно для компов с малым количеством ОЗУ (менее 16 Мб.)
Правда это потребует переписывания некоторого количества приложений и оптимизации существующего драйвера FAT16/32.
Также потребуется наличие инсталлятора. Для очень ленивых пользователей.
german
В чем юмор?
Об этом писали в свое время на старом форуме (meos.fastbb.ru), но вскоре забыли. А идея очень хорошая. С RAM-диском работать неудобно, а если делать поддержку сменных дисков, то надо будет выделять некую особенную область памяти, а это гемор еще тот.
Может тему создать по поводу работы с винтом?
Может тему создать по поводу работы с винтом?
Mario79
Кстати, поддержка образов дисков на винте, возможно, будет реализована (только они будут не RAM). Дело в том, что есть безопасный способ писать на NTFS винт без изменения размера файла. В таком случае образ диска становится посредником между Windows и Kolibri. Кроме того, это позволяет безопаснее тестировать поддержку новых файловых систем.
Violinier
C RAM диском удобно работать, когда загружаешься с флопика или флешки (USB в самой системе еще не поддержано).
В случае с флопиком получается вообще в десятки раз быстрей.
А в случае с винчестером, надо переписывать драйвер, так как сейчас алгоритм загрузки и записи не оптимален. Можно даже в PIO режиме ускорить в 1,5-2 раза. Сейчас максимальная пиковая скорость едва дотягивает до 3 Мб/с.
german
Или ты в одном из видов опьянения, или под твоим ником кто-то другой.
Да, похоже, ломают таки форум.
halyavin
Поддержку образов вполне можно реализовать и на уровне приложения. Нет смысла сильно засорять ядро.
C RAM диском удобно работать, когда загружаешься с флопика или флешки (USB в самой системе еще не поддержано).
В случае с флопиком получается вообще в десятки раз быстрей.
А в случае с винчестером, надо переписывать драйвер, так как сейчас алгоритм загрузки и записи не оптимален. Можно даже в PIO режиме ускорить в 1,5-2 раза. Сейчас максимальная пиковая скорость едва дотягивает до 3 Мб/с.
german
Или ты в одном из видов опьянения, или под твоим ником кто-то другой.
Да, похоже, ломают таки форум.
halyavin
Поддержку образов вполне можно реализовать и на уровне приложения. Нет смысла сильно засорять ядро.
Mario79
Так, чтобы это было прозрачно для остальных программ этого сделать нельзя. В лучшем случае на уровне приложений можно написать что-то типа winimage. Кроме того, код поддержки образов не нужен при загрузке ядра, а это значит, что его (теоретически) можно реализовать в виде драйвера, который подгружается по желанию пользователя.
Так, чтобы это было прозрачно для остальных программ этого сделать нельзя. В лучшем случае на уровне приложений можно написать что-то типа winimage. Кроме того, код поддержки образов не нужен при загрузке ядра, а это значит, что его (теоретически) можно реализовать в виде драйвера, который подгружается по желанию пользователя.
halyavin
Сначала нам нужно придумать внятную концепцию драйверной модели. А то мы так уже вот 2 года рассуждаем того бы этого бы, а воз и ныне там. Конечно, можно использовать принцип VRR драйвера или IPC. Но в обоих вариантах есть минусы, первый требует доработки ядра для каждого драйвера, а второй медленно работает. Надо думать надо ломать голову. Универсальность подключения и максимальная скорость, вот главные принципы, которые должны быть при реализации.
Если я не ошибаюсь, то кто-то на форуме вроде обещал поддержку библиотек сделать, и если я опять же не ошибаюсь, это был ты?
Сначала нам нужно придумать внятную концепцию драйверной модели. А то мы так уже вот 2 года рассуждаем того бы этого бы, а воз и ныне там. Конечно, можно использовать принцип VRR драйвера или IPC. Но в обоих вариантах есть минусы, первый требует доработки ядра для каждого драйвера, а второй медленно работает. Надо думать надо ломать голову. Универсальность подключения и максимальная скорость, вот главные принципы, которые должны быть при реализации.
Если я не ошибаюсь, то кто-то на форуме вроде обещал поддержку библиотек сделать, и если я опять же не ошибаюсь, это был ты?
Про концепцию драйверной модели: нужно сделать, чтобы драйверы запускались в кольце 0. Тогда они смогут перехватывать прерывания от устройств.
/off: Мне показалось, или я тут написал пост, а потом он исчез?
mike.dld
Лично я не трогал. Ломают блин все таки похоже...
Лично я не трогал. Ломают блин все таки похоже...
Who is online
Users browsing this forum: Semrush [Bot] and 8 guests