"Ночные" сборки KolibriOS

Sat Jul 30, 2011 6:56 pm

SVN r.2031-2032 wrote:make: *** No rule to make target `../../programs/fs/Eolite/trunk/Eolite.c--', needed by `File Managers/eolite'.
make: Target `all' not remade because of errors.

Sat Jul 30, 2011 8:39 pm

Попробовал исправить.
1) В ревизии 2034 поправил makefile все три, образ собрался, но увидел ругань компилятора подумал из за расширения *.с вместо *.с--
2) В ревизии 2035 исправил обратно makefile все три, и переименовал Eolite.c в Eolite.c--, однако ругань не исчезла.
Есть вероятность что исходники залиты кривые вообще.

Sat Jul 30, 2011 8:52 pm

Leency wrote:Эээ... я сделал программу, которая ГАРАНТИРОВАНО убивает курсор при запуске. Жаль у меня не сохранился код, но там было по-моему
mov eax,70
mov ebx,1
mcall

без указания mov ecx,header.

Может быть мы наконец-то отловим причину смерти курсора.

Файл собранный из выложенных исходников уже гарантированно подыхает и тащит с собой курсор.

Sat Jul 30, 2011 9:11 pm

Зачем трогать отработанную процедуру в ascgl.inc, мне совершенно не понятно и главное логики в таком изменении нету. Там ведь очистка области функцией 13, куда выводится число функцией 47. Какой смысл в функции 71 ?

Spoiler:

if ~(delcolor eq )
mov eax, 71
mov ebx,1
mcall
;mov ebx,x*65536+30
;mov ecx,y*65536+7
;mov edx,delcolor
;mov eax,13
;mcall

end if
mov dword [ttt],fps_show_frequency
mov eax,47
mov ebx,5*65536
; mov bl,0
mov edx,x*65536+y
mov esi,color
mov ecx,[fps]
mcall

Единственно что ты нашел это недостаток проверки параметра в функции 71. Проблемы с курсором это не решит - код в ядре аварийно падает и тащит собой указатель включенности курсора.

Sat Jul 30, 2011 10:18 pm

Mario wrote:Единственно что ты нашел это недостаток проверки параметра в функции 71.

Ну собственно ради этого я написал пост. Жаль, что исправить нельзя.

Sat Jul 30, 2011 10:37 pm

Да ну ругань эта была всегда. Там просто во флагах компиляции можно выставить не показывать часть ошибок. Но если кто-то знает как решить эти ошибки милости просим

Tue Aug 02, 2011 1:48 pm

Leency, "Там просто во флагах компиляции можно выставить не показывать часть ошибок." - ну так выстави.

Tue Aug 02, 2011 2:15 pm

Разве они кому-то мешают? Вот мой конфиг файл "c--.ini".

Code: Select all

; В этом файле можно изменить настройки компилятора по умолчанию.
J0			; не делать начальный jump на main() 
8			; оптимизация для Pentium II процессора.
r-			; запретить изменение доступной памяти в *.com файлах
X			; запретить включение в выходной файл надписи SPHINXC--
oc			; опримизация по размеру кода
w			; выдавать предупреждения
wf=warning.txt		; предупреждения выводить в файл warning
nw=1			; не показывать кое-какие ошибки в warning.txt
nw=2			; не показывать кое-какие ошибки в warning.txt
de			; использовать временное расширение типа при делении
ON			; включить оптимизацию чисел
ost			; оптимизировать текстовые константы

Tue Aug 02, 2011 2:49 pm

На сервере c--.ini такой:

Code: Select all

; В этом файле можно изменить настройки компилятора по умолчанию.
J0			; не делать начальный jump на main() 
r-			; запретить изменение доступной памяти в *.com файлах
X			; запретить включение в выходной файл надписи SPHINXC--
4			; компилировать код для 80386 процессора
oc			; опримизация по размеру кода
w			; выдавать предупреждения
de			; использовать временное расширение типа при делении
ON			; включить оптимизацию чисел
ost			; оптимизировать текстовые константы
;dos4gw
;env

У него есть одно преимущество - с ним все C-- программы заведомо собираются автосборкой и работают, причём список ошибок виден на сайте автосборки, а не пишется в абстрактный warning.txt где-то на сервере. Поскольку я убила кучу времени на то, чтобы добиться такого эффекта, глобальные настройки я изменять не хочу. Для выставления локальных настроек при компиляции одной программы есть дополнительные аргументы командной строки, легко настраиваемые в сборочном Makefile.

Tue Aug 02, 2011 2:57 pm

Ну, мне на самом деле без разницы - раз уж компиляторы настолько продвинутые, что собирают рабочий бинарник даже с ошибками.
Просто научившись реагировать на любой "Апчхи" от FASM - это выглядело несколько диким на первый взгляд.

Sat Aug 20, 2011 6:35 am

Почему дискеты не читаются в ночной сборке? Кто испортил ядро?
Перепробывал все manager'ы, но не один не читает. Пишут "ошибка файловой системы". А вот в оф. версии 0.7.7.0, всё читается.

Sat Aug 20, 2011 3:35 pm

Mario wrote:компиляторы настолько продвинутые, что собирают рабочий бинарник даже с ошибками.

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

Sat Aug 20, 2011 4:16 pm

Rock_maniak_forever wrote:Почему дискеты не читаются в ночной сборке? Кто испортил ядро?
Перепробывал все manager'ы, но не один не читает. Пишут "ошибка файловой системы". А вот в оф. версии 0.7.7.0, всё читается.

В ревизии 1380 размаскировка прерываний при загрузке была убрана Евгением Гречниковым. Я уже сейчас не помню зачем он это сделал, где-то на форуме написано мельком, но была какая-то проблема вроде с загрузкой на некоторых конфигурациях компьютеров. По идее нужно размаскировать прерывание 6 для флопика либо при загрузке, либо при первом использовании.

З.Ы. Может более разбирающиеся люди подскажут как лучше сделать? А то я давно уже в ядре не ковыряюсь и там некоторые моменты в работе с прерываниями менялись.

Sat Aug 20, 2011 6:09 pm

Лучше при первом обращении.

Sat Aug 20, 2011 6:26 pm

Поскольку наличие флопика определяется выставленным в BIOS значением (в свое время это было лучшее решение которое я смог найти), то и разрешение IRQ6 я сделал там-же. Если есть флопик - прерывание размаскируется, нет - оставляется как есть. SVN r. 2084.
Если кто захочет прикрутить более элегантное решение, то никаких возражений у меня нет.

"Ночные" сборки KolibriOS

Who is online