Board.KolibriOS.org

Пытались сделать юзер фриндли практически интерфейс
При правильной работе и запуске без параметров сначала спрашивает цель для выполнения (all kernel ...), при выборе kernel или all так же потребуется ввести язык из 3-ех предложенных. Также можно сразу запустить с параметрами build.bat all ru ,а после для очистки результатов build.bat clean .
Ну я думаю этим не обойдётся... Интересна какая именно конструкция ему неизвестна. У всех WinXP SP2 вроде бы нормально работает.

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

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

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

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

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

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

Спасибо.

Эта же схема использовалась в 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.

_________________
Ушёл к умным, знающим и культурным людям.

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

В 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 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 функция оптимизирована.

_________________
Ушёл к умным, знающим и культурным людям.