API for OS

[algoritm]

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

[algoritm]

Для выполнения некоторых действий с помощью сервисов OS существует определенный набор правил обращения к OS и передачи параметров. Что рассматривается в тенденциях развития API OS :?: и каким будет API OS :?: каким должен быть на твой взгляд ультрасовременный API OS :?: :cheer:

[Sixteen]

ОС это такой полосатый мух?

[Sixteen]

я лично считаю что если ультрасовременный [API for OS]
не мурчит и не бегает лапками, то нафиг он такой нужен?

[algoritm]

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

[Vrag]

Эта ... наука полагает что [API] должен быть как минимум сантиметров десять. В длинну, значить. А может и дленнее еще, это уже от [OS] зависит.

[Sixteen]

Эта ... наука полагает что [API] должен быть как минимум сантиметров десять. В длинну, значить. А может и дленнее еще, это уже от [OS] зависит.

и мурчать должен приятно. да. нафиг не нужен противный немурчащий неудоный эйпиай, даже если он 20 сантиметров.

[profAleks]

Причем должен поддерживать скачивание мурчалок по протоколу BitTorrent. :grum:

[Lor]

Причем должен поддерживать скачивание мурчалок по протоколу BitTorrent ... ... с автоматической отсылкой логов в FBI

:grum:

[crazy-mike]

Причем должен поддерживать скачивание мурчалок по протоколу BitTorrent. :grum:
А если у компа нет подключения к интернету - то вызов любой функции OS API должен приводить к выключению компьютера. :grum:

[crazy-mike]

Только в данном случае различаем API и GUI
http://en.wikipedia.org/wiki/Application_programming_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

[crazy-mike]

это правда. но их трудней мутиравать, монойадерных этих.
а у нас оптимизацыонный кернел-функтор не связан с реальным временем, он работает виртуальным временем, поэтому с точки зрения решения оптимизационной задачи последовательности вызова функций и выбора наилутшего эйпиайя неважно какой кернел, монойадерный или микрокернел, патипу типа.
(ясен пень что с точки зрения реала это не так)
Я хотел - чтобы функции вообще не вызывались , а создавалась и выполнялась "сопрограмма" в системе команд ВМ юзера (почти как канальная программа в System 360). :grum:
И пусть себе виртуально мутирует в виртуальном времени ...:grum:

[Sixteen]

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

а што такое сопственно вм юзера если не бальшой и толстый майкрокернел?

[crazy-mike]

а што такое сопственно вм юзера если не бальшой и толстый майкрокернел?
Под VM/VSE - "теоретически" как бы и так. Но вся шиза в том - что все равно надо было делать SVC 202 - а это неправильно из-за нарушения control flow. :grum:
Верх кайфа - когда внутри "user objects space" вообще не надо (формально)обращаться к любой из разновидностей OS API calls. :grum:

[crazy-mike]

Интересно - автора темы мы еще не совсем напугали? :grum:

[algoritm]

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

[algoritm]

"В идеале" - его вообще не должно быть (с точки зрения "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 и практически никогда не могло бы их "испортить".
То есть API в том числе должен обеспечивать возможность security :?: :cheer:

[algoritm]

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

[crazy-mike]

То есть API в том числе должен обеспечивать возможность security :?: :cheer:
API в "классическом виде" вообще не должно быть - для обеспечения security и сохранеия работоспособности системы.
Но реализация этого концепта в моноядерных и микроядерных системах - существенно различается.
Кстати - по этомоу поводу таки можно вспомнить Automotive RTOS. :grum:

[algoritm]

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

[crazy-mike]

То есть чтобы API в том числе мог включать новый код в состав сервиса :?: :cheer:
Нет.
Все частично сводилось к dynamic create application environement.
И даже здесь приложение лишено возможности "юзать API" в классическом смысле.

[crazy-mike]

То есть чтобы API мог эффективно использовать функции сервиса :?: :cheer:
API мог бы существовать в виде команд виртуальной машины пользователя.
Но реальное "изменение состояния ресурсов OS" делалось бы только при "загрузке приложения" и "завершении приложения". :grum:

[algoritm]

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

format /hda0
Все ok, продолжаем. :cheer:

[algoritm]

Я хотел - чтобы функции вообще не вызывались , а создавалась и выполнялась "сопрограмма" в системе команд ВМ юзера (почти как канальная программа в System 360). :grum:
И пусть себе виртуально мутирует в виртуальном времени ...:grum:
А как эта сопрограмма получалы бы доступ к устройству :?: :cheer:

[crazy-mike]

А как эта сопрограмма получалы бы доступ к устройству :?: :cheer:
К "реальному" - вообще никак! :grum:
Но там notification есть - данные прибыли на виртуальный дивайс без ошибок и их можно юзать!
И никаких пересылок данных! Все уже по notification - внутри application objects (variables)

[algoritm]

Интересно - автора темы мы еще не совсем напугали? :grum:
Все ok, продолжаем :cheer:

[algoritm]

API в "классическом виде" вообще не должно быть - для обеспечения security и сохранеия работоспособности системы.
Но реализация этого концепта в моноядерных и микроядерных системах - существенно различается.
Кстати - по этомоу поводу таки можно вспомнить Automotive RTOS. :grum:
Тогда какой должна быть структура API :?: :cheer:

[algoritm]

Нет.
Все частично сводилось к dynamic create application environement.
И даже здесь приложение лишено возможности "юзать API" в классическом смысле.
То есть чтобы API мог использовать dynamic create application environement :?: :cheer:

[algoritm]

API мог бы существовать в виде команд виртуальной машины пользователя.
Но реальное "изменение состояния ресурсов OS" делалось бы только при "загрузке приложения" и "завершении приложения". :grum:
То есть чтобы API мог эффективно использовать переменные для часто используемых данных :?: :cheer:

[algoritm]

К "реальному" - вообще никак! :grum:
Но там notification есть - данные прибыли на виртуальный дивайс без ошибок и их можно юзать!
И никаких пересылок данных! Все уже по notification - внутри application objects (variables)
То есть чтобы API мог проверять данные передаваемые устройству :?: :cheer:

[crazy-mike]

То есть чтобы API мог эффективно использовать переменные для часто используемых данных :?: :cheer:
Нет. Все очень похоже на принцип "выполнение команд по готовности операндов этих команд". Это даже можно считать отказом от концепции "программирования последовательности выполнения команд".

[algoritm]

Нет. Все очень похоже на принцип "выполнение команд по готовности операндов этих команд". Это даже можно считать отказом от концепции "программирования последовательности выполнения команд".
То есть чтобы API осуществлял сервисы в произвольном порядке :?: :cheer:

[crazy-mike]

То есть чтобы API осуществлял сервисы в произвольном порядке :?: :cheer:
Нет. Просто "традиционные" API сводились к наборам "системных вызовов". Этим системным вызовам передавались параметры через регистры или через стек. Планировать выделение ресурсов на уровне OS и обслуживание множества таких приложений - довольно трудно, особенно для оптимизации функционирования такой системы. Там ведь желательно анализировать код приложения при загрузке приложения ( load link-edit and-go ). Всё бы хорошо - но при выполнении dlopen или LoadLibrary всю эту лабуду надо проделывать снова. Я попробовал представить решение без этих излишеств - ну и позаимствовал кучу всего из очень старой документации IBM.

[Sixteen]

Нет. Просто "традиционные" АПИ сводились к наборам "системных вызовов". Этим системным вызовам передавались параметры через регистры или через стек. Планировать выделение ресурсов на уровне ОС и обслуживание множества таких приложений - довольно трудно, особенно для оптимизации функционирования такой системы. Там ведь желательно анализировать код приложения при загрузке приложения ( лоад линк-едит анд-го ). Всё бы хорошо - но при выполнении длопен или ЛоадЛибрары всю эту лабуду надо проделывать снова. Я попробовал представить решение без этих излишеств - ну и позаимствовал кучу всего из очень старой документации ИБМ.

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

[algoritm]

Современный API представляет из себя набор функций запросов с параметрами, но обеспечивает ли этот набор все потребности при создании application :?:, конечно это трудный вопрос ответить на который можно по принципу что создавая и добавляя новые функции все становится более универсальным, но при этом следует учесть возможность создания более эффективных моделей разработки API особенно для специальных систем с новым уровнем возможностей :!: :grum: :popcorn: :cheer:

[crazy-mike]

традиционные ейпиайи не просто через регистры и/или стек передают параметры.
при системном колле еще и происходит переклучка процессора какова нибудь из юзер режыма в кернел режым. я никогда нипанимал в чом разница, но вроде как таск свитчинг в кернел моуде не работает.
а дапустим если у тя весь апи лежит в юзер спейсе и просто кладет мессадж типа на кернеловский ББС, где сам кернел работает на другом процессоре ваще, то не происходит этаво дурацково разделения на юзер и кернел моуды.
это типа тем чем гордяцца эти микрокернелисты вовсю.
Да ! И там разница в том - что в kernel mode используется flat addressing относительно совсем другого "сегмента памяти". :grum:
Но при "обмене сообщениями" между kernel и юзер application без переключения режимов нужно гонять слишком большие объёмы данных по pipe. :grum:
Хотя в multiprocesssing это даже и предпочтительный вариант - потому как не надо думать о синхронизации таймингов памяти и процессоров. :grum:

[MolliM]

Да ! И там разница в том - что в кернел моде используется флат аддрессинг относительно совсем другого "сегмента памяти". :грум:
Но при "обмене сообщениями" между кернел и юзер апплицатион без переключения режимов нужно гонять слишком большие объёмы данных по пипе.


то есть кернел не юзает виртуальную память сам? у как хитро все.

[crazy-mike]

Современный API представляет из себя набор функций запросов с параметрами
Уже давно всё не так!!!!!! Даже на "бюджетных платформах".
Есть - кстати - ещё один вариант - делать все системные запросы через запросы к System DBMS!!!!!! :grum:
С такой реализацией - полный дурдом программеров и сисадминов будет! :grum:

[algoritm]

я лично считаю что если ультрасовременный [API for OS]
не мурчит и не бегает лапками, то нафиг он такой нужен?
Это скорее интерфейс робота но для этого надо типа определить сам API :grum: :popcorn: :cheer:

[crazy-mike]

то есть кернел не юзает виртуальную память сам? у как хитро все.
Даже это может быть реализовано (и даже реализовано уже давно).

[MolliM]

Современный АПИ представляет из себя набор функций запросов с параметрами, но обеспечивает ли этот набор все потребности при создании апплицатион :?:, конечно это трудный вопрос ответить на который можно по принципу что создавая и добавляя новые функции все становится более универсальным, но при этом следует учесть возможность создания более эффективных моделей разработки АПИ особенно для специальных систем с новым уровнем возможностей :!: :грум: :попцорн: :чеер:

у ОС АПИ нету цели обеспечивать все потребности при создании аппликейшена. для этого есть всяческие эсдикейз и так далее, а у ОС АПИ совсем другие цели. Это только глупий микрософт все смешал в кучу, а безграмотные ВБ-бобики все подлизали.

[crazy-mike]

Это скорее интерфейс робота но для этого надо типа определить сам API :grum: :popcorn: :cheer:
Нет - это интерфейс между микроядрами и user application! :grum:

[MolliM]

Уже давно всё не так!!!!!! Даже на "бюджетных платформах".
Есть - кстати - ещё один вариант - делать все системные запросы через запросы к Сыстем ДБМС!!!!!! :грум:
С такой реализацией - полный дурдом программеров и сисадминов будет! :грум:

не блин, пусть будет кернелный форум на адресе лоцалхост, а юзер программы пусть на него реквесты кладут через [HTTP] в формате [XHTML].

[algoritm]

у ОС АПИ нету цели обеспечивать все потребности при создании аппликейшена. для этого есть всяческие эсдикейз и так далее, а у ОС АПИ совсем другие цели. Это только глупий микрософт все смешал в кучу, а безграмотные ВБ-бобики все подлизали.
In computer science, an application programming interface (API) is an interface defining the ways by which an application program may request services from libraries and/or operating systems.
http://en.wikipedia.org/wiki/Application_programming_interface
:cheer:

[crazy-mike]

не блин, пусть будет кернелный форум на адресе лоцалхост, а юзер программы пусть на него реквесты кладут через [HTTP] в формате [XHTML].
Web OS!!!! - уже есть!!!!! :grum:
http://www.eyeos.org
- эту можно даже своего рода прототипом считать...:grum:

[crazy-mike]

Это только глупий микрософт все смешал в кучу, а безграмотные ВБ-бобики все подлизали.
Если сравнивать с IBM - то в мелкософте пытались одно время заново изобрести велосипед фактически...:grum:

[MolliM]

Ин цомпутер сциенце, ан апплицатион программинг интерфаце (АПИ) ис ан интерфаце дефининг тхе щаыс бы щхич ан апплицатион програм маы реэуест сервицес фром либрариес анд/ор оператинг сыстемс.
хттп://ен.щикипедиа.орг/щики/Апплицатион_программинг_интерфаце
:чеер:

как компютерная саентистка я ответственно заявляю
што компьютерный саенс вообще не занимается такой ерундой как определение значения всяких дурных трехбуквенных акронимов типа [API]
Компьютерный саенс занимается теорией вычислений а вовсе не тем каким должен быть [API], а особенно системый [API]. Это спец. сабджект в архитектурах операционных систем. Что вообще имеет слабое отношение к "разработке аппликейшенов". Это вообще другая специальность. Всех этих "разработчиков аппликейшенов" и близко нельзя подпускать к разработке оэсов. в связи с чем слово АПИ не должно использоваться по отношению к операционным системам вообще.

[MolliM]

Если сравнивать с ИБМ - то в мелкософте пытались одно время заново изобрести велосипед фактически...:грум:

лисапедисты-бурократо-маркетологи блин.

[algoritm]

Создавая все большее количество функций и параметров API для выполнения определенных действий следует учесть что сочетание 5 действий в разных варинтах создает 5!=120 наборов действий а 10 действий 10!=3628800 наборов действий, так нужно ли тогда продумывать создание специализированных функций в API :?: :grum: :popcorn: :cheer:

[crazy-mike]

лисапедисты-бурократо-маркетологи блин.
:grum:
Примерно так. Кроме того они всю SAA практически "стырили" у IBM. :grum:

[crazy-mike]

Создавая все большее количество функций и параметров API для выполнения определенных действий следует учесть что сочетание 5 действий в разных варинтах создает 5!=120 наборов действий а 10 действий 10!=3628800 наборов действий, так нужно ли тогда продумывать создание специализированных функций в API :?: :grum: :popcorn: :cheer:
Это одна из основных причин - по которой я настаиваю на том , что классический OS API является анахронизмом из 1970го года. :grum:

[crazy-mike]

Всех этих "разработчиков аппликейшенов" и близко нельзя подпускать к разработке оэсов. в связи с чем слово АПИ не должно использоваться по отношению к операционным системам вообще.
:girl_cray2: Вот оно - Logos (Слово Истины - которая "где то рядом" :grum: ) !!!!!!!!!!!!

[MolliM]

:грум:
Примерно так. Кроме того они всю САА практически "стырили" у ИБМ. :грум:

а што это такое, [SAA]?

[crazy-mike]

а што это такое, [SAA]?
System Application Architecture
:grum: (старое такое - примерно 1980-1984й год )
Потом её подмножество ещё обозвали CUA (Common User Access)

[algoritm]

Так как некоторые функции и параметры API иногда модернизируют на новые варианты то часть application приходится модернизировать или создавать для них специальную среду функционирования, но можно ли тогда автоматически модернизировать application :?: и возможно ли сделать модернизацию выполнимой для каждого конкретного случая :?: :grum: :popcorn: :cheer:

[crazy-mike]

Так как некоторые функции и параметры API иногда модернизируют на новые варианты то часть application приходится модернизировать или создавать для них специальную среду функционирования, но можно ли тогда автоматически модернизировать application :?: и возможно ли сделать модернизацию выполнимой для каждого конкретного случая :?: :grum: :popcorn: :cheer:
Рассказать о том - как в процессе вызова "функции API" модифицировался и код, и данные приложения на платформе System 360?
:grum:
:vacation:
А тебе это всё для курсовой или для дипломной нужно? :grum::girl_cray2:

[algoritm]

А что тогда собственно требовалось application :?: в чем смысл обращения application к API :?: а application на самом деле требуется рассказать OS что нужно сделать и какие данные при этом использовать :!: :grum: :popcorn: :cheer:

[crazy-mike]

А что тогда собственно требовалось application :?: в чем смысл обращения application к API :?: а application на самом деле требуется рассказать OS что нужно сделать и какие данные при этом использовать :!: :grum: :popcorn: :cheer:
Я именно об этом и постил в самом начале. А по описанию сама OS должна "скомпилить Application Environement" или выполнить запрос к БД таких AE и выдать соотвествующий результат!!!!!! :grum:
Если тебе это для курсовой - то твоего "препода" отправят на Канатчикову Дачу!!!!! Ты с ними - пожалуйста - поосторожнее. Многие из них ещё Фортран-2 юзали...:grum:

[algoritm]

Я именно об этом и постил в самом начале. А по описанию сама OS должна "скомпилить Application Environement" или выполнить запрос к БД таких AE и выдать соотвествующий результат!!!!!! :grum:
Если тебе это для курсовой - то твоего "препода" отправят на Канатчикову Дачу!!!!! Ты с ними - пожалуйста - поосторожнее. Многие из них ещё Фортран-2 юзали...:grum:
Чтобы пояснить можно привести очень примитивный и приблизительный на вид пример этого как роль XML запросов AJAX в web API :grum: :popcorn: :cheer:

[crazy-mike]

Чтобы пояснить можно привести очень примитивный и приблизительный на вид пример этого как роль XML запросов AJAX в web API :grum: :popcorn: :cheer:
Не совсем. Хотя отдалённая аналогия есть. Просто hypervisor-у вообще говоря "данные приложения и логика выполнения приложения" принципиально "по барабану". Ему только надо оценить ресурсоёмкость приложения и затолкать его environment в соответствующий "класс обслуживания". При этом - конечно же есть и класс обслуживания "Execution is not allowed". :grum:

[algoritm]

как компютерная саентистка я ответственно заявляю
што компьютерный саенс вообще не занимается такой ерундой как определение значения всяких дурных трехбуквенных акронимов типа [API]
Компьютерный саенс занимается теорией вычислений а вовсе не тем каким должен быть [API], а особенно системый [API]. Это спец. сабджект в архитектурах операционных систем. Что вообще имеет слабое отношение к "разработке аппликейшенов". Это вообще другая специальность. Всех этих "разработчиков аппликейшенов" и близко нельзя подпускать к разработке оэсов. в связи с чем слово АПИ не должно использоваться по отношению к операционным системам вообще.
Это не так :cheer:

[algoritm]

Не совсем. Хотя отдалённая аналогия есть. Просто hypervisor-у вообще говоря "данные приложения и логика выполнения приложения" принципиально "по барабану". Ему только надо оценить ресурсоёмкость приложения и затолкать его environment в соответствующий "класс обслуживания". При этом - конечно же есть и класс обслуживания "Execution is not allowed". :grum:
Это другое :cheer:

[algoritm]

Это одна из основных причин - по которой я настаиваю на том , что классический OS API является анахронизмом из 1970го года. :grum:
Так он до сих пор почти такой же, и менять его особо не спешат, у них типа принцип есть что особые наборы действий application должен строит сам из небольших основных функций, причем после модернизации которых application иногда просто перестает работать :cheer:

[crazy-mike]

Так он до сих пор почти такой же, и менять его особо не спешат, у них типа принцип есть что особые наборы действий application должен строит сам из небольших основных функций, причем после модернизации которых application иногда просто перестает работать :cheer:
Ты имеешь ввиду Win32 API?

[algoritm]

Из основных функций application может создавать запросы на наборы действий и можно сказать что решение найдено, но если подумать как же тогда развивать API то приходится добавлять новые функции, а каждое application будет думать как создать из основных функций запрос так чтобы выполнить нужные действия наиболее эффективным образом, но так как сами основные функции не предоставляют возможности определить как они выполняются реально, то реально application часто не сможет использовать их эффективно :grum: :popcorn: :cheer:

[algoritm]

Ты имеешь ввиду Win32 API?
Все известные современные OS и виндоусы линуксы юниксы в том числе :grum: :popcorn: :cheer:

[MolliM]

прежде чем трендеть про КИ, надо хотя бы понять что такое интерфейс вообще. ёмаё.

вот ты алгоритм. вот ты знаешь что такое интерфейс?

[MolliM]

а еще палезно панимать, зачем вообще нужен ОС

[crazy-mike]

Все известные современные OS и виндоусы линуксы юниксы в том числе :grum: :popcorn: :cheer:
Не все. :grum:
А в юниксах всё совсем не так - как это было в 1970м.
:grum:

[algoritm]

Сторонниками OS с открытым исходным кодом иногда видимо предполагается что раз они знают вообще весь код OS, то уж как работают основные функции, из которых application предлагается создать запрос набора действий, они знают и соответственно application в такой OS могут создавать эффективные запросы, но это не так, и дело даже не в том что модернизации могут происходить на лету например из-за автоматических отладок кода, а в том что и устройства могут быть разными и различно использоваться OS в такой момент :grum: :popcorn: :cheer:

[crazy-mike]

а еще палезно панимать, зачем вообще нужен ОС
Не пугайте автора темы. А то ведь как начнём говорить о постепенном стирании семантических различий между Operating System и Application Operating Environеment с использованием двухуровневых грамматик - он опять убежит. :grum:

[crazy-mike]

Сторонниками OS с открытым исходным кодом иногда видимо предполагается что раз они знают вообще весь код OS, то уж как работают основные функции, из которых application предлагается создать запрос набора действий, они знают и соответственно application в такой OS
Нельзя смешивать пиво и сакэ! Поищи аббревиатуру JCL. :grum: Это тебе яркий и красивый пример API у "OS без файловой системы".
А ещё поюзай аббревиатуру SLOS - Single Language Operating System. Ну и - IMS. :grum:

[algoritm]

Не пугайте автора темы. А то ведь как начнём говорить о постепенном стирании семантических различий между Operating System и Application Operating Environеment с использованием двухуровневых грамматик - он опять убежит. :grum:
Тема "API for OS", не надо устраивать личные споры и заниматься троллингом и гоблингом, что очень распространено на этом форуме, скомпрометировать ты здесь можешь только себя :grum: :popcorn: :cheer:

[algoritm]

Нельзя смешивать пиво и сакэ! Поищи аббревиатуру JCL. :grum: Это тебе яркий и красивый пример API у "OS без файловой системы".
А ещё поюзай аббревиатуру SLOS - Single Language Operating System. Ну и - IMS. :grum:
Это другое :grum: :popcorn: :cheer:

[crazy-mike]

Тема "API for OS"
Объясняю - далеко не все элементы API OS в функциональной записи являются настоящими системными запросами (syscall, emt, svc ...). Это и "декларативная семантика в процедурной нотации" , и "конфигурирование параметров Runtime Library" даже для "ассемблерной программы".
:grum: Не все вызовы транслируются в call. Есть ещё и inline. Поэтому help по OS API практически не содержит информации о том - что будет выполняться на самом деле.

[crazy-mike]

Это другое :grum: :popcorn: :cheer:
Не другое - а самый настоящий OS API с выполнением системных функций в user space. :cheer: :beer2:
JCL имелось ввиду. В Java Application Deployment это делается при помощи XML. :beer2:

[MolliM]

виэмваре хороший пример.

[crazy-mike]

виэмваре хороший пример.
Очень хороший! И Xen - тоже!

[crazy-mike]

троллингом и гоблингом
А я даже и не знаю - что это за хреновина такая...:grum:

[MolliM]

а все таки. абьясните мне глупой Молли для чего вообще нужен ОС
и чего он полезного делает?

[crazy-mike]

а все таки. абьясните мне глупой Молли для чего вообще нужен ОС
и чего он полезного делает?
Мы автора темы сейчас "опять напугаем" (Уже напугали - судя по последним постам). :grum:
Как только он начнёт постить "без подглядывания в википедию" - я начну серьёзно отвечать.
Можно было бы даже сказать - что ОС "ни для чего не нужна". В embedded systems и так application runtime library и OS фактически объединены в "единое целое". Но не всё так просто - хотя бы потому , что основной функцией OS является "распределение ресурсов вычислительной системы между процессами в этой системе". :grum:
А различия между Operating Environments и Operating Systems тем не менее существуют - тем более , что под одной OS могут сосуществовать и взаимодействовать несколько Operating Environements. :popcorn: Если это при помощи формальной грамматики начать описывать - автор совсем убежит. :grum:

[MolliM]

Мы автора темы сейчас "опять напугаем" (Уже напугали - судя по последним постам). :грум:
Как только он начнёт постить "без подглядывания в википедию" - я начну серьёзно отвечать.
Можно было бы даже сказать - что ОС "ни для чего не нужна". В ембеддед сыстемс и так апплицатион рунтиме либрары и ОС фактически объединены в "единое целое". Но не всё так просто - хотя бы потому , что основной функцией ОС является "распределение ресурсов вычислительной системы между процессами в этой системе". :грум:
А различия между Оператинг Енвиронментс и Оператинг Сыстемс тем не менее существуют - тем более , что под одной ОС могут сосуществовать и взаимодействовать несколько Оператинг Енвиронементс. :попцорн: Если это при помощи формальной грамматики начать описывать - автор совсем убежит. :грум:


типа: МС ДОС был ОС, а Щин 3.1 был оперейтинг енвиронмент.

у аперационнай системы есть несколько функций:

самые базовые:
доступ к жылезу (драйверы)
процессинговые и мультипроцессинговые функции
регулировка доступа к жылезу для процессов
файл систем и нетворк систем

менее базовые, относящиеся уже к ОЕ:

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

и совсем не базовые, типа х-виндозе сервера, што уже относица к юзерскому оперейтинг энвиронменту

[crazy-mike]

типа: МС ДОС был ОС, а Щин 3.1 был оперейтинг енвиронмент.

у аперационнай системы есть несколько функций:

самые базовые:
доступ к жылезу (драйверы)
процессинговые и мультипроцессинговые функции
регулировка доступа к жылезу для процессов
файл систем и нетворк систем

менее базовые, относящиеся уже к ОЕ:

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

и совсем не базовые, типа х-виндозе сервера, што уже относица к юзерскому оперейтинг энвиронменту
Всё намного запутаннее на самом деле. GNOME и KDE , например , содержат свои собственные функции распределения ресурсов для приложений (включая даже "доступ к железу"). Чёткой границы просто нет. Я не говорю о таких "экстравагантных системах" как OS PICK (R83 и AP Native Implementation - кончилось с ними всё примерно в 1990е. Сейчас "это" существует исключительно в виде "Operating Environement"). А куча "мутантов" от Oralcle? (8i,9i,10i,...) :grum:
IBM DB2 в ранних вариантах фактически была компонентой OS поскольку поддерживала "специальные методы доступа к томам DB2".
IMS/CICS --- там CICS тоже одновременно был как бы и "компонентой OS"...

[algoritm]

Таким образом реально application нужно не обращаться к каким-то функциям, а рассказать OS о том что нужно сделать и какие данные при этом использовать, тогда вопрос как application должно рассказывать OS об этом, наиболее удобным решением является использование обычной текстовой речи с оформлением в виде типа XML конструкции, тогда при разработке API нужно стремиться не к созданию все большего количества специализированных функций а повышению способности OS понимать разные запросы в виде текстовой речи с оформлением типа XML конструкции, то есть OS понимает запрос и сама анализирует возможно ли и как его выполнить, и в случае не возможности возвращает ответ с предполагаемой причиной трудности, а в случае возможности определяет как наиболее эффективно выполнить запрос и контролирует и оптимизирует его выполнение и возвращает результат :v: :popcorn: :cheer:

[algoritm]

Для выполнения некоторых действий с помощью сервисов OS существует определенный набор правил обращения к OS и передачи параметров. Что рассматривается в тенденциях развития API OS :?: и каким будет API OS :?: каким должен быть на твой взгляд ультрасовременный API OS :?: :cheer:
Повторяю если кто-то не понял тему или затрудняется понять смысл сказаного. :cheer:

[MolliM]

Повторяю если кто-то не понял тему или затрудняется понять смысл сказаного. :чеер:

хамити парниша! Разгавора у нас не выйдет! - страшным голосом сказала Молли.

[crazy-mike]

хамити парниша! Разгавора у нас не выйдет! - страшным голосом сказала Молли.
У меня бы он пересдавал раза три ....И курсовую бы переделывал...:grum:

[crazy-mike]

Таким образом реально application нужно не обращаться к каким-то функциям, а рассказать OS о том что нужно сделать
Для ЯВУ (языков высокого уровня) это делает "компилятор" и "библиотека времени выполнения". Все "твои любимые" вызовы API сводятся к "экранированным описаниям"(декларациям в функциональной форме). И даже к генерации описаний inline. Даже для программ win32 есть шизофренический термин "База Данных Задачи" (в любой книге по Windows "не для чайников" об этом есть. Да и на MSDN - тоже :grum:)

[algoritm]

Можно сказать что нужно AI дополнение к API :!: :grum: :popcorn: :cheer:

[algoritm]

Для ЯВУ (языков высокого уровня) это делает "компилятор" и "библиотека времени выполнения". Все "твои любимые" вызовы API сводятся к "экранированным описаниям"(декларациям в функциональной форме). И даже к генерации описаний inline. Даже для программ win32 есть шизофренический термин "База Данных Задачи" (в любой книге по Windows "не для чайников" об этом есть. Да и на MSDN - тоже :grum:)
Это смешно, типа если некуда послать можно послать к компилятору, например к компилятору АЛГОЛ'а, АЛГОЛ рулит :grum:, и зачем тогда вообще OS, вместо них просто поставить компилятор АЛГОЛ'а :grum: (it's a joke and not serious :grum: :!:) :cheer:

[crazy-mike]

Это смешно, типа если некуда послать можно послать к компилятору, например к компилятору АЛГОЛ'а, АЛГОЛ рулит :grum:, и зачем тогда вообще OS, вместо них просто поставить компилятор АЛГОЛ'а :grum: (it's a joke and not serious :grum: :!:) :cheer:
К runtime library скорее - чем к компилятору.
И ещё к "загрузчику"...:grum:
AI - задействовано как раз там. В винде - к примеру - это "тупое AI" заменяло load on demand на preloaded в дескрипторах сегментов...:grum::grum:
В "серьёзных системах" (TKB под RSX-11 :grum:) вообще использовался термин "процедура создания исполняемого образа задачи"...

[crazy-mike]

Можно сказать что нужно AI дополнение к API :!: :grum: :popcorn: :cheer:
Linkage Editor как раз был довольно интеллектуальным (AI features) в OS/360...:grum: