API for OS

[crazy-mike]

Только в данном случае различаем API и GUI
http://en.wikipedia.org/wiki/Applica...ming_interface
http://en.wikipedia.org/wiki/Graphical_user_interface
:cheer:

А тебя низкоуровневый или высокоуровневый интерфейс интересует?

[Радригес]

А тебя низкоуровневый или высокоуровневый интерфейс интересует?

Создайте еще более понятный интерфейс и мир создаст еще более тупого юзера.

[crazy-mike]

Создайте еще более понятный интерфейс и мир создаст еще более тупого юзера.

Так он не про user API ведь хотел...:grum:

[crazy-mike]

Каким должен быть API for OS :?: :cheer:

"В идеале" - его вообще не должно быть (с точки зрения "security").
:grum:Нет API - вирусы труднее писать.
Но тут есть ещё один идиотизм - что должно "юзать кеш-память" : OS или application?
А OS API ко всему прочему ещё и снижает производительность системы. Даже в случае передачи параметров через регистры - в эти самые регистры нужно ещё и загнать значения по одной команде mov на регистр и потом ещё выполнить "системный вызов" (SVC,emt,int,syscall - и т.д. ).
Даже просто call - это "медленно". Тем более - что всё это выполняется "очень часто".
Наверное могло бы существовать два вызова "API init" и "API end".
По apiInit - проверялись бы "полномочия пользователя" и создавалась бы его ВМ (в зависимости от "прав пользователя". При этом они бы не имели ничего общего с правами юзеров OS ) для OS API (со своей системой команд , адресным пространством и memory mapping). И вся эта хрень бы загружалась в кеш-память и оставалась бы там до выполнения apiEnd.
А "функции API" бы в этом случае существовали в виде команд одноадесной или даже безадресной виртуальной машины.
:grum: Ну и весь "сеанс" бы выполнялся как отдельный process (с notification messages для application). User Application в этом случае работало бы только с OS data view - а не с реальными OS data и практически никогда не могло бы их "испортить".

[Sixteen]

"В идеале" - его вообще не должно быть (с точки зрения "security").
:grum:Нет API - вирусы труднее писать.
Но тут есть ещё один идиотизм - что должно "юзать кеш-память" : OS или application?
А OS API ко всему прочему ещё и снижает производительность системы. Даже в случае передачи параметров через регистры - в эти самые регистры нужно ещё и загнать значения по одной команде mov на регистр и потом ещё выполнить "системный вызов" (SVC,emt,int,syscall - и т.д. ).
Даже просто call - это "медленно". Тем более - что всё это выполняется "очень часто".
Наверное могло бы существовать два вызова "API init" и "API end".
По apiInit - проверялись бы "полномочия пользователя" и создавалась бы его ВМ (в зависимости от "прав пользователя". При этом они бы не имели ничего общего с правами юзеров OS ) для OS API (со своей системой команд , адресным пространством и memory mapping). И вся эта хрень бы загружалась в кеш-память и оставалась бы там до выполнения apiEnd.
А "функции API" бы в этом случае существовали в виде команд одноадесной или даже безадресной виртуальной машины.
:grum: Ну и весь "сеанс" бы выполнялся как отдельный process (с notification messages для application). User Application в этом случае работало бы только с OS data view - а не с реальными OS data и практически никогда не могло бы их "испортить".

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

[crazy-mike]

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

Под монитором виртуальных машин - как раз к этому и сводится. Но я постил немного о другом - об оптимизации последовательностей "системных вызовов" (и привел самый варварский пример возможности реализации такой хреновины - хотя у IBM на AS/400 много всего и покруче было).
:grum:

[Sixteen]

Под монитором виртуальных машин - как раз к этому и сводится. Но я постил немного о другом - об оптимизации последовательностей "системных вызовов".
:grum:

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

[crazy-mike]

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

Вообще-то моноядерные работают быстрее микроядерных (ну очень "в среднем" :grum. Просто "моноядро" могло бы одновременно выглядеть "по-разному" для разных юзеров (кому-то мурчать , а на кого-то и гавкать) :grum:
Кстати - а куда автор темы swap out? :evillaugh:
//GO.SYSOUT DD SYSPUNCH
:grum:

[Sixteen]

Вообще-то моноядерные работают быстрее микроядерных (ну очень "в среднем" :grum. Просто "моноядро" могло бы одновременно выглядеть "по-разному" для разных юзеров (кому-то мурчать , а на кого-то и гавкать) :grum:

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

[Sixteen]

афтар темы абидилсо и убижал?
патаму што паласатому муху никакой апи ваще не нужен?

format /hda0