И где вводить all ru?

Если в тотале, то можно в панели запуска ввести build all ru или en/de - для разных языков соответственно. При этом в папке с исходниками должна создаться папка bin и в нее будут помещены ядро выбранного языка, драйверы и скин

Можно просто ткнуть в новый build.bat: он при этом спросит, что собирать (all kernel drivers skins clean) - пишешь all, жмешь Enter, он спросит на каком языке - пишешь язык (ru en de), нажимаешь Enter. И не нужно при этом запускать никакой консоли...

Если развернуть KFAR 0.17 на весь экран получается интересная цветомузыка в виде левой и правой панели (окна нету), притом, что правая панель жутко подмигивает.
Все это великолепие жрет 99% ресурсов системы.

Буду исправлять. Правда, я такого не наблюдал, видимо, потому что работаю в разрешениях 800*600 (стандартное для Kolibri) и 1024*768 (в Windows), (а также 640*480 под Bochs и VMWare); под 1280*1024 я проверить просто не додумался. Спасибо.

Кстати скажи, пожалуйста, сколько кушает KFAR если его развернуть на весь экран (при разрешении 1280*1024)?

На один файл расходуется 304+4 байта. Теоретически помимо этого основная память идёт под изображение консоли, которое занимает чуть-чуть меньше 3*1280*1024 = 3.75Mb. Практически дополнительно возникают приколы с тем, что используемый менеджер памяти работает на 64-й функции и не всегда может освободить память, которая уже не используется (в смысле, может освободить только память в конце адресного пространства). Я уже некоторое время пинаю halyavin'а с просьбой переписать memalloc.inc на новые функции 68.12/13, но пока безуспешно.

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

Тут хвалиться не обязательно, факты говорят сами за себя. И, к сожалению (для меня), явно не в пользу KFar'а.

Есть и положительный момент - скорость вывода в обычном режиме (без разворачивания на весь экран) практически сравнялась с KFM.

Оптимизация ещё только начинается...

Удачи.

Спасибо.

Эта же схема использовалась в KFar 0.01. В версии 0.04 уже использовался менеджер памяти, поскольку такая простая схема вообще не проходит, когда необходимо выделять динамическую память под разные цели.
KFar 0.18. Ссылки всё те же.
http://diamondz.land.ru/kfar
http://diamondz.land.ru/kfar_src.7z
http://diamondz.land.ru/kfar.txt
Дальнейшая оптимизация по скорости. Теперь gmon показывает, что (при сравнении в окнах одного и того же размера) KFar занимает меньше процессорного времени, чем KFM. Ликвидировано зависание при максимизации окна. Добавлено сочетание Alt+F9.

Произошла описка. Я имел в виду KFAR, так что текст от этих слов и ниже относится к KFAR.

Я так и понял. Но подобное мероприятие снизит производительность, поскольку при прорисовке ядро будет вынуждено заново генерировать изображение, которое сейчас хранится в памяти программы.

В MFAR память используется немного по-другому (или я ошибаюсь). Есть текстовый буфер изменяемого размера формата 0xB800. Сделано это было для того, чтобы потом облегчить портирование для работы в нативном текстовом режиме. Плюс, каждый раз, когда нужно нарисовать какую-то часть окна, под буфер, на этот раз уже пиксельный, выделяется блок, соответствующий размеру прямоугольника обновления; в него перекидываются данные из текстового буфера, потом он рисуется функцией #7, и после этого освобождается. Это позволяет не держать всё время выделенный пиксельный буфер, максимальный размер которого может составлять ширину на высоту экрана на 3, и не очень сильно влияет на скорость отрисовки.

KFar 0.19. Исправлен баг с пересканированием панели по Ctrl+R, внесённый в версии 0.17. Требует последнего ядра (ревизия 283), поскольку в рамках уменьшения используемого объёма памяти использует новую функцию 65 - аналог функции 7 для 8-битовых изображений. Это сильно уменьшает объём требуемой памяти и немного ускоряет отрисовку. Перерисовка выполняется по методу, описанному mike.dld, эксперименты показывают, что это действительно практически не влияет на производительность. В результате с текущим ядром при каждой отрисовке объём свободной памяти немного уменьшается (в среднем на 8Кб), скорее всего, это утечка памяти в ядре, в реализации функции 64.

У меня KFAR неправильно копирует файлы.
Если размер файла не превышает несколько сотен килобайт,то всё копируется правильно.А вот если размер к примеру мегабайт или десятки мегабайт,то копируется только несколько сотен килобайт от начала.
К примеру файл размером 3371008 байт превращается в файл размером 360448 байт.
При запуске KFAR-а в эмуляторе всё правильно копируется(неправильно работает только в реальной системе).

И ёще. При запуске KFAR-а на правой панели вместо строчек типа

......
ReadError

появляется чёрный прямоугольник.

p.s.
Естественно проверял с последней версией KFAR-а и ядра.

andrew_programmer
Попробуй скопировать те же файлы через COPY2. Из 0.6.3.0 (на 70-й функции).

Я пробовал копировать те-же файлы через программу copy2.Они копируются правильно и ничего не виснет.

При копировании KFAR-ом опирования он частенько подвисает.В большинстве случаев это подвисание приводит к тому,что перестаёт работать чтение/запись жёсткого диска.

При копировании KFAR-ом опирования он частенько подвисает.В большинстве случаев это подвисание приводит к тому,что перестаёт работать чтение/запись жёсткого диска.

У себя тоже такое наблюдал. Уже даже начал молиться за свой винчестер, когда после копирования файла стали зависать все файловые менеджеры колибри

Я это понял, когда в винду перегрузился и обнаружил, что все в порядке, но сразу было не до этого

KFar 0.2. Нормальная обработка ошибок чтения папок (больше никто не увидит псевдофайла "Read error" ). Использование флага C в 0-й функции (не путать с CF из eflags).
Виснет не сам kfar, а ядро то ли в функции чтения, то ли в функции записи. Сути дела это, правда, не меняет. Кстати, попробуйте положить кирпич на PageDown при просмотре больших файлов.

KFar 0.21. Нормальная обработка всех ошибок. Поддержка создания папок (F7) при условии наличия ядра svn.321.
Висло, разумеется, ядро, в svn.321 это исправлено.

Если операция обращения к жесткому диску завершилась без снятия флага, то доступ к файловой системе будет блокирован до перезагрузки.

Если прибить процесс, работающий с файловой системой, доступ будет блокирован до перезагрузки. Меня это достало и я добавил в функцию terminate код для освобождения free_hd_channel (освобождение hd1_status там уже было). svn.321.

Копирование больших файлов - очень медленное. Нужно увеличивать размер однократно копируемого блока.

Копирование было очень медленным не из-за малого размера блока, а из-за неоптимальности функции 70.3. В svn.321 функция оптимизирована.