Board.KolibriOS.org

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

Spoiler:

Code: Select all

START:				; start of execution
	mov	edi, filename
	cmp	byte [edi], 0
	jnz	param
	mov	esi, default_filename
@@:
	lodsb
	stosb
	test	al, al
	jnz	@b
param:

Код Sorcerer делает особую уличную магию (без обид). Первый указатель 16 битный, тогда как у нас 32 битная адресация, дальше еще не понятней сохраняем 8 битную часть и все это идет как указатель. В общем мудрено и непонятно чего ты пытался получить.

ужас какой! Сам испугался, когда увидел свой код сейчас.

Ночью надо спать.

eBox-3350MX: Скачал http://builds.kolibrios.org/Vortex86MX- ... 997-img.7z (который уже с новым BOARD в автозагрузке). После загрузки выводится пустой BOARD (без лога вообще) и использование процессора 100%. Если прибить этот BOARD через "Task Manager", то всё становится нормально, загрузка опускается до 0, и если запустить BOARD ещё раз, то лог выводится исправно.

В AUTORUN.DAT вроде всё написано правильно, ничего не менял, и до изменения всё работало:

Проблема в том что при загрузке передается неправильный параметр (не являющийся путем к файлу) и код этого не учитывает. Нужна проверка на обратный слеш "/" параметра переданного при загрузке.

З.Ы. Если Вероника сама не поправит вечером сделаю.

Mario wrote:Проблема в том что при загрузке передается неправильный параметр (не являющийся путем к файлу) и код этого не учитывает. Нужна проверка на обратный слеш "/" параметра переданного при загрузке.

Ну ты же сам говорил, что <NO> нужен как "Place Holder", если я не хочу передавать никакой параметр, верно? Потому что второй параметр - это время задержки, а он обязательно должен быть вторым.

Нет, тут дело не в этом, а как раз в том что передается параметр "<NO>". Другие приложения проверяют переданную строку на валидность, хотя-бы проверкой обратного слеша "/". BOARD же тупо копирует если есть хоть какие-то данные отличные от 0. Поскольку файл с путем "<NO>" создать невозможно, то происходит хрень.

Mario wrote:Нет, тут дело не в этом, а как раз в том что передается параметр "<NO>". Другие приложения проверяют переданную строку на валидность, хотя-бы проверкой обратного слеша "/". BOARD же тупо копирует если есть хоть какие-то данные отличные от 0. Поскольку файл с путем "<NO>" создать невозможно, то происходит хрень.

Тогда я неверно понял другое твоё сообщение на эту тему:

Mario wrote:Нет, каждый передаваемый параметр определяется исключительно кодом содержащимся в самом запускаемом приложении. Параметр <NO> определен как компромиссное решение - ни одна программа такой параметр теоретически не обрабатывает в качестве допустимого входного параметра.

А где идёт обработка файла AUTORUN.DAT? В ядре? А там нельзя поставить проверку, что если в AUTORUN.DAT для приложения указан параметр <NO>, то приложению не передаётся никакой параметр?

Имя файла вполне может и не начинаться со слеша. Я поправила код, чтобы board не входил в бесконечный цикл при ошибке создания файла. Я считаю, что вопрос с передачей параметров имеет смысл решать на уровне launcher, обрабатывающего autorun.dat, причём заодно сделать задание параметров с пробелами, обрабатывая - дополнительно к текущему варианту - кавычки как начало/конец параметра. Тогда пустой параметр можно задать, написав "". Если не будет возражений, я несколько позже добавлю соответствующий код в launcher.

yogev_ezra

А где идёт обработка файла AUTORUN.DAT? В ядре?

Обработкой AUTORUN.DAT занимается приложение LAUNCHER.

А там нельзя поставить проверку, что если в AUTORUN.DAT для приложения указан параметр <NO>, то приложению не передаётся никакой параметр?

Вероятно можно, но никто не задавался такой целью раньше.

UPD. Немного опоздал с ответом.

CleverMouse
ИМХОется мне что возражений не будет.
Полезная вещь.

З.Ы. Когда ты только все успеваешь. У меня работа забирает все силы и мозг.

Я закоммитила обещанное изменение в launcher.

Если board добавлен в автозагрузку с параметром записи лога на жёсткий диск (/hd0/1), то после загрузки Колибри проходит несколько секунд, прежде чем board начинает выводить сообщения на экран и в файл. Я поставил в автозагрузку только board и ac97snd (ну чтоб было хоть что-то выводить в лог), и задержка на несколько секунд всё равно происходила. Если в параметре ничего не указать (то есть, использовать рамдиск по умолчанию), то запись в лог начинается мгновенно. Вероятно, что-то в ядре блокирует запись на жёсткий диск при загрузке Колибри.

r2101+r2103 фиксят проблему?

В моем случае задержка исчезла (я проделал так как написал yogev_ezra), но я в основном наблюдал задержку при запуске USB ядра.