Board.KolibriOS.org

<b>diamond</b>
Попробвал дистр! Вот несколько небольших глюков которые я заметил... незнаю насколько это будет полезным, но всё-же
1 Глюк TinyPad - меню отображается в заголовке и нечего не открывается.
2 Система при загрузке с дискеты не открывает почти ничего.
3 CMD - при исполнении команды чёрный экран выходит за границу рамки окна.
4 Игра Mine не закрывается с первого раза.
5 Когда запущено хоть одно окно, при его сворачивании не работает контекстное меню.
6 При сохранении файла в tynipad2 (файл - схранить как) немогу прописать путь. При попытке записать один символ, удаляется педыдущий, при удалении всех вообще ничего больше не пишется.
7 Что за программа infrared. Довольно долго открывается и при открытии ничего не происходит, просто чёрное окно.

с дискеты система загрузилась, но программы запускаться упорно отказывались, с жёсткого всё норма...

Maxxxx32
А нужна ли замена spanel? Для изменения нескольких параметров можно вполне использовать ручную правку panel.dat по аналогии с menu и autorun. А в текущей реализации spanel только создает впечатление сырости системы в целом... Да и не думаю, что кто-то вообще меняет эти параметры...

Сколько багов! Прямо глаза разбегаются, с какого начинать. Проблема в том, что у меня на компе большая часть глюков отсутствует.
Для начала. Специальный уменьшенный образ для любителей отладки (много чего повыкидывано):
http://diamondz.land.ru/menuetd.7z
Просьба всем сообщившим о багах:
a) проверить, был ли баг в Kolibri 0.5.8.1;
б) проверить, появляется ли баг в "уменьшенном" дистрибутиве (если программа отстутствует, внедрите её в образ чем-нибудь типа WinImage или просто скопируйте на дискету).
AqwAS
7. infrared - приёмник сигналов с инфракрасного девайса на COM1. Если соответствующего девайса нет, будет просто чёрное окно.

Ревизия 143/144, из которой выкинуты функции 19 и 58.16 (и подправлена пара мелких багов).

Это означает, что ядро зависло при чтении /hd0/1. В таком случае sysxtree по идее при попытке чтения /hd0/1 тоже должен
повиснуть.

Возможно, многие баги вызваны тем, что не полностью загружается рамдиск. В таком случае в уменьшенном образе всё должно быть нормально.

.
Тогда может стоит залить ее на свн и поставить ее в качестве "tags/0.6.0.0"?

Большинство багов, описанных выше, связано именно с неполной загрузкой рамдиска. В колибри 0.5.8.1 они тоже были, но несколько в других проявлениях (другие программы находились в поврежденной области). Глюк kfar-a (черная правая панель) у меня тоже проявляется в стационарном образе, но только при загрузке с дискеты, так что это тоже следствие поврежденного рамдиска. В отладочном образе все работает нормально (это не касается глюков, описанных AqwAS, там другая история)

Про ставить точки над разными буквами алфавита с ошибками при загрузке рамдиска.
http://diamondz.land.ru/test1.7z (ссылка временная) - тестирующий образ. Залейте его на дискету и загрузитесь с этой дискеты. Псевдоядро kernel.mnt выдаст то, что думает BIOS по поводу карты памяти (вообще говоря, это не совсем истинная карта, но представление даёт), загружает дискету, по ходу дела тестируя прочитанные данные, потом считывает из расширенной памяти рамдиск назад с тестированием. Просьба выложить лог. На моей машине:

=== Memory ranges ===
Base address: 00000000, length: 0009FC00, type: AddressRangeMemory
Base address: 0009FC00, length: 00000400, type: AddressRangeReserved
Base address: 000F0000, length: 00010000, type: AddressRangeReserved
Base address: 00100000, length: 0FEF0000, type: AddressRangeMemory
Base address: 0FFF0000, length: 00008000, type: AddressRangeACPI
Base address: 0FFF8000, length: 00008000, type: AddressRangeNVS
Base address: FFEE0000, length: 00020000, type: AddressRangeReserved
Base address: FEC00000, length: 00001000, type: AddressRangeReserved
Base address: FEE00000, length: 00001000, type: AddressRangeReserved
Base address: FFFC0000, length: 00040000, type: AddressRangeReserved
=== Floppy test ===
All is OK
=== Ramdisk test ===
All is OK

Heavyiron
Можно подумать, только у меня есть доступ на запись к svn-репозиторию. А исходные коды выложены.
all
Кстати, кто-нибудь смотрел папку 'develop' в исходниках дистрибутива?

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

Работает оно. Дело в том, что (цитируя документацию) "с точки зрения 9-й функции минимизированное окно сохраняет положение и размеры". Соответственно @rb при щелчке в области, ранее занимаемой окном минимизированного приложения, считает, что там есть настоящее окно. Щелкай вне этой области. Как любит говорить Microsoft, "this behavior is by design".

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

diamond http://diamondz.land.ru/menuetd.7z
У меня на машине работает нормально и без ошибок, все приложения запускаются, глюков не заметил

Вот лог:

Теперь обо всём по порядку. Многие баги явно связаны с неполной загрузкой рамдиска.

Старый mtldr из Kolibri 0.5.8.1 или mtldr_install из текущего? В первом случае попробуй поставить http://diamondz.land.ru/mtldr.rar - он поновее. Если всё равно не работает - попробуй на образе menuetd.7z.

Какая есть с давних пор... Впрочем, возможно, стоило вывести на рабочий стол click вместо arc-ii.

Ага, есть такое дело с давних пор. Будем исправлять. Похоже, там инвертируется рамка, потом приложение вызывает 0-ю функцию и рамка заменяется на нормальную, а потом рамка инвертируется "назад".

1 - не наблюдал. Симптомы похожи на старое ядро с новым tinypad'ом.
2 - сказано выше
3 - есть такой баг. Будет исправлено
4 - не наблюдал
5 - почему так, я уже объяснил. Осталось добавить, что в связи с недавним расширением функции 9 это исправимо, если заодно проверять состояние окна.
6 - есть такой баг в sysxtree (ответственном за диалоги открытия/сохранения). Будет исправлено
7 - см. выше

Про панель: видимо, наилучшим вариантом будет разработка библиотеки чтения[/записи] ini-файлов, перенос настроек в ini-файл и удаление spanel.
Heavyiron
Спасибо за лог. Выглядит вполне пристойно в смысле, что с рамдиском должно быть всё в порядке. Теперь такая просьба: таким же образом запусти http://diamondz.land.ru/biosdump.7z - псевдоядро дампит на дискету BIOS и таблицу прерываний, потом вышли мне по почте файлы bios и idt. Bochs позволяет использовать свои BIOS, а ошибка, повторяющаяся под Bochs, имеет очень большие шансы быть исправленной. Кстати, остальных, у кого есть проблемы с загрузкой, исчезающие при переходе к menuetd.7z, эта просьба тоже касается.

Отправил!

Лог с моей машины и VM Ware где я обычно работаю:
VMWare Workstation 5.0.0.

=== Kernel test ===
=== Memory ranges ===
Base address: 00000000, lenght: 0009F800, type: AddressRangeMemory
Base address: 0009F800, lenght: 00000800, type: AddressRangeReserved
Base address: 000DC000, lenght: 00024000, type: AddressRangeReserved
Base address: 00100000, lenght: 07DF0000, type: AddressRangeMemory
Base address: 07EF0000, lenght: 0000F000, type: AddressRangeACPI
Base address: 07EFF000, lenght: 00001000, type: AddressRangeNVS
Base address: 07F00000, lenght: 00100000, type: AddressRangeMemory
Base address: FEC00000, lenght: 00010000, type: AddressRangeReserved
Base address: FEE00000, lenght: 00001000, type: AddressRangeReserved
Base address: FFFE0000, lenght: 00020000, type: AddressRangeReserved
=== Floppy test ===
All is OK
=== Ramdisk test ===
All is OK

Реальный компьютер.

=== Kernel test ===
=== Memory ranges ===
Base address: 00000000, lenght: 0009FC00, type: AddressRangeMemory
Base address: 0009FC00, lenght: 00000400, type: AddressRangeReserved
Base address: 000F0000, lenght: 00010000, type: AddressRangeReserved
Base address: FFB00000, lenght: 00500000, type: AddressRangeReserved
Base address: 00100000, lenght: 1FEF0000, type: AddressRangeMemory
Base address: 1FFF3000, lenght: 0000D000, type: AddressRangeACPI
Base address: 1FFF0000, lenght: 00003000, type: AddressRangeNVS
=== Floppy test ===
All is OK
=== Ramdisk test ===
All is OK

Глюков вроде пока не заметил. Хотя может плохо смотрел.

Я не смотрел код,но похоже были сделаны какие-то изменения в работе шедулера.Раньше шедулер распределял время между процессами примерно одинаково,а сейчас на первый процесс отводиться в 2-3 раза больше времени.Я раньше мог спокойно запустить 8 штук 3DCUBE2 ,а теперь еле получается 4(курсор мыши начинает исчезать на 1-3 сукунды и растащить окна практически невозможно).
Лучше вернуть шедулеру прежнюю равнозадачность(равное распределение времени между прцессами).



P.S.
Думаю,что перед выкладыванием дистрибутива,нужно всем кто бывает на форуме - тестировать ядро.
А после уже включать его в дистрибутив(ядро).
Так будет надежнее.

diamond
Тестовый образ у меня тоже не запустился (симптомы те же- виснет при смене видеорежима, даже до загрузки шрифтов не доходит: не появляется никаких надписей). Если заменить ядро из дистрибутива на ядро 134, запускается. Под дистрибутивом я подразумеваю 0.6.0.0.

Ответственно заявляю: ни в КолибриОС, ни в МенуэтОС такого никогда не было. Код шедулера много раз менялся, но алгоритм работы остаётся тем же, что и в древних ядрах МеОС.