Помогите новичку
-
Видимо код уже ненужен, но возможно пригодится новичкам, IMHO.
- Attachments
-
-
WriteInFile.7z (1.07 KiB)Downloaded 241 times
-
How can I use relative path to work with files? I have a executable .kex and a file (image.raw) and I want to use only the name of the file, not the full path. In the root directory /rd/1/ it works, but in another directory, for example /hd0/1/projects/ don't work. I remember hearing something about this but I do not remember where. Thanks in advance.
default path is /sys/ (= /rd1/1/)
It can be changed with sysfn 30.1
The path of the executable can be obtained through the last dword in header.
It can be changed with sysfn 30.1
The path of the executable can be obtained through the last dword in header.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
See line 162 of dungeons.asm for an example implementation
http://websvn.kolibrios.org/filedetails ... ngeons.asm
http://websvn.kolibrios.org/filedetails ... ngeons.asm
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Thanks hidnplayr for your quick response. Very well explained
Бдагодарю!Yason wrote:Держи исправленый вариант. Программа отображает число нажатий на кнопку, и завершается, если на кнопку снизу, нажать 10 раз.gc986 wrote:Странно. Запустил под отладчиком. Данные аккумулируются в переменной, [button2], но у меня её нет в тексте программы. В отладчике вроде всё правильно - происходит аккумуляция, а далее ожидание события, требуется нажать на кнопку, Но когда программа работает нормально, я один раз нажимаю (видимо происходит цикл) и программа заканчивается.Gluk wrote:А вы пользуетесь отладчиком?
Оказывается из-за невнимательности забыл вызвать функцию определения нажатой кнопки )))
Я делаю калькулятор и теперь необходимо формировать строку из чисел соответствующих нажатой клавише. Чтобы поместить символ в строку на определённую позицию необходимо к адресу строки прибавить необходимое количество байт и затем помещать туда символ, например так
Но что делать если требуется постепенно перемещать курсор ввода (перемещаться по строке) и вводить данные, как в обычном калькуляторе? Или есть способ получше?
много вариантов перепробовал но постоянно нарушаю семантику языка
Code: Select all
mov byte [str+2], '1'
много вариантов перепробовал но постоянно нарушаю семантику языка
Если я правильно понял, то тебе нужна косвенная адресация.gc986 wrote:Я делаю калькулятор и теперь необходимо формировать строку из чисел соответствующих нажатой клавише. Чтобы поместить символ в строку на определённую позицию необходимо к адресу строки прибавить необходимое количество байт и затем помещать туда символ, например такНо что делать если требуется постепенно перемещать курсор ввода (перемещаться по строке) и вводить данные, как в обычном калькуляторе? Или есть способ получше?Code: Select all
mov byte [str+2], '1'
много вариантов перепробовал но постоянно нарушаю семантику языка
З.Ы. А вообще почитай книгу по Ассемблеру (например:Зубков С.В. - Ассемблер язык неограниченных возможностей), прежде чем задавать вопросы. Там, есть ответ на твой вопрос.
- Attachments
-
-
Screenshot.png (2.43 KiB)Viewed 6688 times
-
hello (493 Bytes)Downloaded 220 times
-
Какой алгоритм копирования файла наиболее оптимальный? В Eolite сейчас идет считывание всего файла за раз, и дальнейшая запись. Но, насколько я понимаю, это плохо. Копирования блоками фиксированного размера тоже плохо, если я понял правильно из последних обсуждений. Тоесть, наиболее оптимальный вариантЮ копироватиьб блоками размером x% от свободной ОЗУ, верно?
to infinity and beyond
тот, который быстрее других найдет куда писать и откуда брать и выполнит копирование за меньшее количество операций с ОЗУ:
при копировании блоками тратится время на доступ к блоку за каждое обращение; если блоки не последовательны и не попали в кеш НЖМД, а они не попали в >99% случаев, то тратится время на доступ к каждому фрагменту; если сектор долго не читается, то проще его пропустить и вернутся к нему и другим таким в конце и т.д. и т.п.
эффективнее управлять DMA конечно, когда и если он будет...
а так, да, но для тестирования копирования чем больше, тем...
при копировании блоками тратится время на доступ к блоку за каждое обращение; если блоки не последовательны и не попали в кеш НЖМД, а они не попали в >99% случаев, то тратится время на доступ к каждому фрагменту; если сектор долго не читается, то проще его пропустить и вернутся к нему и другим таким в конце и т.д. и т.п.
эффективнее управлять DMA конечно, когда и если он будет...
а так, да, но для тестирования копирования чем больше, тем...
Мне больше для правильной реализации в Eolite, а то длгадываюсь, что при текущей реализации для копирования фильма например, ОЗУ у меня не хватитkiv wrote:тот, который быстрее других найдет куда писать и откуда брать и выполнит копирование за меньшее количество операций с ОЗУ:
при копировании блоками тратится время на доступ к блоку за каждое обращение; если блоки не последовательны и не попали в кеш НЖМД, а они не попали в >99% случаев, то тратится время на доступ к каждому фрагменту; если сектор долго не читается, то проще его пропустить и вернутся к нему и другим таким в конце и т.д. и т.п.
эффективнее управлять DMA конечно, когда и если он будет...
а так, да, но для тестирования копирования чем больше, тем...
to infinity and beyond
punk_joker, а Eolite вообще проверяет сколько памяти свободно? Если да, то можешь не торопиться - сейчас фильм будет копироваться где-то час. Поскольку память задействуется кратковременно, думаю, оптимально брать половину памяти. Тут такой момент, я в ntfs пока фрагментацию не делал, ищется цельное место. Когда сделаю редактирование файла, копирование маленькими кусками сможет приводить к сильной фрагментации, подход будет похерен и придётся писать ещё и дефрагментатор.
Или вот такой подход, без ограничений. Делишь размер файла на количество памяти, а потом делишь файл на равные куски.
Или вот такой подход, без ограничений. Делишь размер файла на количество памяти, а потом делишь файл на равные куски.
В том то и дело, что не проверяет, и даже не сообщает о ошибке выделения. Потому и хочу переписать, чтоб было нормально. Думаю копирование кусками размером половину свободной ОЗУ будет наиболее оптимальным вариантом.Pathoswithin wrote:punk_joker, а Eolite вообще проверяет сколько памяти свободно? Если да, то можешь не торопиться - сейчас фильм будет копироваться где-то час. Поскольку память задействуется кратковременно, думаю, оптимально брать половину памяти. Тут такой момент, я в ntfs пока фрагментацию не делал, ищется цельное место. Когда сделаю редактирование файла, копирование маленькими кусками сможет приводить к сильной фрагментации, подход будет похерен и придётся писать ещё и дефрагментатор.
Или вот такой подход, без ограничений. Делишь размер файла на количество памяти, а потом делишь файл на равные куски.
Eolite писался Leency еще когда он только начинал изучать программирование, потому под красивой шкуркой много плохого кода Хоть он многое и переписал уже в приличный вид, но некоторые куски все еще оставляют желать лучшего
to infinity and beyond
Я тут в ядре решил кодом побаловаться, с WINDOW.INC . Добавил в функцию calculatescreen немного кода - запустил - вылетело всё. Исправил баги - опять вылетело. Вместо своего кода запихнул много nop'ов - вылетело. Тут я уже впал в некоторое недоумение. Вопрос такой: что такого сдвигает растолстевший немного calculatescreen и как всё таки мне сделать свою хотелку? Если что, вылет выглядит так: загрузился синий экран с 5 секундами успешно, нажимаю энтер и комп тут же на перезапуск. Ни логи, ни чего-то ещё не показывается(или не успеваю заметить, хотя вряд ли). Ещё в одной из моих глючных модернизаций вылетел драйвер RDC.SYS(в доске отладки написало), мышь перестала перерисовываться(подвигаю - не двигается, нажму кнопку Пуск - перерисовалась в новом месте). Вот. Версия ядра - 5665.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Есть вероятность, что ты залез в стек ядра. Посмотри внимательно карту памяти ядра. Самый надёжный способ найти ошибку - протрассировать в Bochs. Даже 100% правильный на первый взгляд код может содержать ошибки.
Who is online
Users browsing this forum: No registered users and 42 guests