Мое имхо.
Данную функцию можно реализовать как подфункцию 18-й. А возвращаемые параметры могут выглядеть как строка "Kolibri", номер версии и подверсии и возврашаться через регистры (а не через область памяти). В общем, как то что происходит по команде CPUID.
функция версии ядра
угу, и версия ядра МеОС взятого за основу...
Может есть смысл указывать в ядре инфу подробнее?
Ну например сделать версию графического фейса. Т.е. чтобы можно было узнать вносились ли в него изменения.
etc
Ну например сделать версию графического фейса. Т.е. чтобы можно было узнать вносились ли в него изменения.
etc
Вариант с перспективой на будущее. Есть 3 функции:
1. Возвращает в 32-байтный участок памяти следующую информацию:
2. Возращает кодовое имя.
3. Проверяет совместимость текущей ОС с информацией о версии переданной в 32-байтном участке памяти (в том же формате, что и в функции 1, длина кодового имени игнорируется). (результат 0 - текущая ОС имеет, возможно, меньше возможностей, чем указанная, 1 - это дальнейшее развитие указанной системы)
Можно не передавать длину кодового имени, если ограничить ее максимальное значение, скажем, 256 байтами. uid нужен для будущих расхождений/слияний веток развития. Например, если какая-нибудь версия Kolibri станет официальным дистрибутивом, то нужно будет добавить новый uid 3 - New MenuetOS (based on Kolibri) оставив кодовое имя 'MenuetOS'.
1. Возвращает в 32-байтный участок памяти следующую информацию:
Code: Select all
+0x00: номер версии - четыре 32-битных числа (1.4.0.0 для Kolibri 4, 1.0.80.0 для MenuetOS)
+0x10: uid кодового имени - уникальное число, идентифицирующее кодовое имя операционной системы. 1 для MenuetOS, 2 - для Kolibri. (0 - функция выдачи версии не реализована)
+0x14: длина кодового имени.
3. Проверяет совместимость текущей ОС с информацией о версии переданной в 32-байтном участке памяти (в том же формате, что и в функции 1, длина кодового имени игнорируется). (результат 0 - текущая ОС имеет, возможно, меньше возможностей, чем указанная, 1 - это дальнейшее развитие указанной системы)
Можно не передавать длину кодового имени, если ограничить ее максимальное значение, скажем, 256 байтами. uid нужен для будущих расхождений/слияний веток развития. Например, если какая-нибудь версия Kolibri станет официальным дистрибутивом, то нужно будет добавить новый uid 3 - New MenuetOS (based on Kolibri) оставив кодовое имя 'MenuetOS'.
предлагаю все-таки добавить версию графической системы + остальное зарезервированно.
Mario79
Лучше занимайся пока поддержкой ФС, а-то писать файловые менеджер ни меня, ни Лисовина, ни Павлюшина не прёт, когда не знаешь, что ждёт впереди. Или хотя бы тестовые ядра выкладывай с новой семантикой и кратким описанием.
А насчёт версии... думаю, что задумка Халявина хороша, но хватило бы функции 1:Естественно, формат кодового имени должен быть стандартизирован.
Лучше занимайся пока поддержкой ФС, а-то писать файловые менеджер ни меня, ни Лисовина, ни Павлюшина не прёт, когда не знаешь, что ждёт впереди. Или хотя бы тестовые ядра выкладывай с новой семантикой и кратким описанием.
А насчёт версии... думаю, что задумка Халявина хороша, но хватило бы функции 1:
Code: Select all
+0x00 [16]: номер версии - четыре 32-битных числа (1.4.0.0 для Kolibri 4, 1.0.80.0 для MenuetOS)
+0x10 [4]: uid кодового имени - уникальное число, идентифицирующее кодовое имя операционной системы. 1 для MenuetOS, 2 - для Kolibri. (0 - функция выдачи версии не реализована)
+0x14 [236]: кодовое имя.
Мое имхо.
Я против возвращения параметров через область данных (а не через регистры). Определение версии ОС в приложении обычно требуется нечасто, и под это дело еще и область данных резервировать? А 6 регистров - это 24 байта, достаточно, чтобы впихнуть все что хочется. Единственное пожелание - номер версии должен быть в старшей, а номер подверсии - в младшей части регистра. (а уж что это будет - слово, байт или тетрада - не важно). Так легче осуществить проверку "версия не ниже такой-то".
Я против возвращения параметров через область данных (а не через регистры). Определение версии ОС в приложении обычно требуется нечасто, и под это дело еще и область данных резервировать? А 6 регистров - это 24 байта, достаточно, чтобы впихнуть все что хочется. Единственное пожелание - номер версии должен быть в старшей, а номер подверсии - в младшей части регистра. (а уж что это будет - слово, байт или тетрада - не важно). Так легче осуществить проверку "версия не ниже такой-то".
Раз требуется не часто - не в таком большом количестве приложений придется резервировать память. Кроме того, можно использовать стек - проверка наверняка будет в начале приложения, а, следовательно, стек еще не будет активно использоваться. Правда, придется проверять корректность буфера, что не быстро. С возращением значений в регистрах так же есть некоторые проблемы. В текущей версии ядра системная функция может возращать значения только в регистрах eax,ebx и ecx. Можно расширить набор возращаемых регистров, но это приведет к небольшому замедлению системных вызов (примерно 1 такт на каждый дополнительный регистр - в принципе не так много). Так же придется отказаться от кодового имени. Возможно, имеет смысл сделать 2 функции. Одна (быстрая) возращает информацию (без кодового имени) через регистры, другая - как в посте mike.dld
упор должен быть на скорость.
Code: Select all
UID_NONE=0
UID_MENUETOS=1
UID_KOLIBRI=2
iglobal
version_inf:
dd 1,4,0,0 ;1.4.0.0
dd UID_KOLIBRI
db 'Kolibri',0
version_end:
endg
sys_get_version:
;eax - subfunction number
;ebx - buffer address
mov eax,[0x3010]
add ebx,[eax+0x10] ;add base address
mov edi,ebx
mov esi,version_inf
mov ecx,version_end-version_inf
rep movsb
xor eax,eax ;ok
ret
Code: Select all
cmp eax,get_version_subfunction_number ;заменить на число
jnz no_sys_get_version
call sys_get_version
;если ничего в стек еще не записывалось,
;иначе добавить сюда соотвествующие команды pop/popad.
mov [esp+36],eax
ret
no_sys_get_version:
Mario79
Код, который будет переводить число из 1-байтого в 4-байтное сам займет лишних 3 байта (ну может я преувеличиваю...). Так зачем извращаться?
В числовом виде на случай если версии больше 10, а кому-то понадобиться сравнивать номер версии. Если ограничиться диапозоном до 255 для версии, то можно все возратить в одном 4-байтном слове. 4 части, поскольку это наиболее принятый способ нумерации. Для колибри 4.5 должно быть 1.4.5.0, 0.4.5.0,
или 0.0.45.0 - как тебе больше нравится .
Кстати, я опять забыл команду cld .
Код, который будет переводить число из 1-байтого в 4-байтное сам займет лишних 3 байта (ну может я преувеличиваю...). Так зачем извращаться?
В числовом виде на случай если версии больше 10, а кому-то понадобиться сравнивать номер версии. Если ограничиться диапозоном до 255 для версии, то можно все возратить в одном 4-байтном слове. 4 части, поскольку это наиболее принятый способ нумерации. Для колибри 4.5 должно быть 1.4.5.0, 0.4.5.0,
или 0.0.45.0 - как тебе больше нравится .
Кстати, я опять забыл команду cld .
Предлагаю возвращать в 5-том байте буфера не UID, а номер ветки ядра (0-trunk, 1-net, 2-hd_kolibri, 3-Kolibri_A, например) или зарезервировать байт. Колибри давно уже не руссифицированный менует, и заботится о совместимости с Менуетом в этом плане не нужно, ИМХО.
ушёл...
Зарезервировать или использовать под идентификатор ветки ядра? - вот в чём вопрос.
ушёл...
Насколько мне известно ни одна программа не использует эту функцию, но я естественно могу и ошибаться. В целом идея здравая и полезная, если никто не возразит можно и сделать.
Nasarus
Ветки появляются и исчезают. Не везде будут править коды, легко создать путаницу.
Ветки появляются и исчезают. Не везде будут править коды, легко создать путаницу.
Who is online
Users browsing this forum: No registered users and 37 guests