Разработка концептуально новой ОС

Кем доказано? Микросовт?
Да, нет математической теорией!!!

Прошу прощения, но это заведомо неправда :-[
Во-первых, никакая математическая теория в принципе не доказывает утверждений о реальном мире - только о математической же модели. А то, насколько модель соотносится с реальным миром, это уже в ведении не математики, а естественных наук (собственно, только этим они и занимаются).

Кроме того, есть всем известный контрпример - программа "Hello World!". Осмелюсь утверждать, что в ней нет ошибок.

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

Цитата SergeS, 07.09.03, 23:31:14

Ядро сделанно так что при запуске игры ( после подтверждения юзверя ) отдаёт всё ресурсы гаме и занимает самый минимум

А в чем польза от такой ОС? Цель в том, чтобы избавить западных пользователей тратиться на приобретение Windows?
Кроме того, я подозреваю, что подавляющее большинство игрушек усиленно эксплуатируют WinAPI, а его реализовывать - не лучший способ самоубийства..

Цитата nvm, 08.09.03, 17:03:22

Кем доказано? Микросовт?
Да, нет математической теорией!!!

Прошу прощения, но это заведомо неправда :-[
Во-первых, никакая математическая теория в принципе не доказывает утверждений о реальном мире - только о математической же модели. А то, насколько модель соотносится с реальным миром, это уже в ведении не математики, а естественных наук (собственно, только этим они и занимаются).

Кроме того, есть всем известный контрпример - программа "Hello World!". Осмелюсь утверждать, что в ней нет ошибок.

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

А в чем польза от такой ОС? Цель в том, чтобы избавить западных пользователей тратиться на приобретение Windows?
Кроме того, я подозреваю, что подавляющее большинство игрушек усиленно эксплуатируют WinAPI, а его реализовывать - не лучший способ самоубийства..

Есди вы напишите программу которач получая другую программу определит напечатает ли та в процессе выполнения hello word
ТО ВАМ ПОЛОГАЕТСЯ МИЛЛИОН ДОЛЛАРОВ И МИРОВАЯ ИЗВЕСТНОСТЬ

ТАК ЧТО НЕ ТАК ВСЕ ПРОСТО
ибо доказано чтода же компьютеры с бесконечной памятью не смогут этого сделать
конечно это модель как вы говорите ведь в реале память конечна но ведь от этого компы= лишь ограниченней

Цитата leemouse, 08.09.03, 16:41:31

Представляется разумным определиться сначала с так наз. "оргкомитетом" проекта, ответственным за принятие стратегических архитектурных решений. Ибо если проект стартует без должного "устаканивания" основных концепций, архитектуры системы, общих для всех разработчиков идиом и т.д., то он гарантированно умрёт.

Отчасти концептуальные посылки уже изложены: открытость, простота, модульность (объектность), виртуализация, абстракция ключей.
Вообще, для начала можно вести вполне свободное обсуждение, на основе которого составить один или несколько вариантов ТЗ, а потом уже решать, будет ли кто из этого что реализовывать.

Цитата

Опять же видится перспективной мысль о системе, полностью обьектно-ориентированной. Т.е. с ТОТАЛЬНЫМ следованием принципам инкапсуляции, единообразия и т.д. на уровне системы.

Это самое главное! ..Только, чтобы не было похоже на COM-технологию, потому что она, ИМХО, - уродство.

Цитата

К вопросу о файловой системе: для новой ОС это вообще не должно быть проблемой. Она должна полностью абстрагироваться от конкретной ФС и общаться только со спец. интерфейсом. (аналогия с архитектурой COM). Тогда можно будет установить поддержку любой ФС существующей в природе.

Согласен, но только отчасти.
ФС - это второстепенный вопрос, и начал я с него именно из соображений, чтобы выбрать для начала попроще. А основные идеи еще в процессе изложения (в голове картина более-менее цельная и прозрачная, но описать ее - непростая задача), пока в документе есть середина, но не хватает начала, поэтому еще не выложил..
Что касается ФС, то содержание сказывается и на интерфейсе. Предлагаемая PlainFS по возможностям богаче распространенных систем, поэтому подразумеваемый ею интерфейс позволяет обращаться к другим ФС, но не наоборот.
Правда, другие ФС в данном интерфейсе будут поддерживаться "не вполне буквально": в PlainFS не поддерживается понятие пользователя и группы, а вместо этого используется системная категория ключа (более общая), но видов доступа всего два (ср. с NTFS), и для доступа к файлу не нужен доступ к файло-каталогам, его содержащим.

Цитата esperanto, 08.09.03, 18:17:26

Есди вы напишите программу которач получая другую программу определит напечатает ли та в процессе выполнения hello word
ТО ВАМ ПОЛОГАЕТСЯ МИЛЛИОН ДОЛЛАРОВ И МИРОВАЯ ИЗВЕСТНОСТЬ
ТАК ЧТО НЕ ТАК ВСЕ ПРОСТО
ибо доказано чтода же компьютеры с бесконечной памятью не смогут этого сделать
конечно это модель как вы говорите ведь в реале память конечна но ведь от этого компы= лишь ограниченней

А зачем писать другую программу?! Я посмотрю код и по нему скажу, напечатает она hello world или нет.
Кто-то действительно разрабатывает теории доказательства правильности кода. Правда, я отношусь к ним очень скептически, так как они не объяснили, как собираются доказывать правильность доказательства правильности кода... а потом правильность доказательства доказательства.. ну и так, понятно, до бесконечности.
Хотя, любой язык программирования - это строгий формальный язык, поэтому любая программа сама является формальным доказательством своей правильности.

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

Hello netlanders!

Я уже довольно давно читаю этот форум, но на этот раз не мог удержаться, чтобы не сказать пару слов.
Дело в том, что я и сам интересуюсь проблемой создания новой ОС, если не сказать больше: я пытаюсь её написать. К сожалению, не всё так просто, и продвинулся я в этом совсем недалеко. Но кое-какие знания всё же накопил. Так что не обессудьте ворчуна – он вам только помочь желает. Всё ниже мною сказанное – в большей степени моё imho, и в какой-то мере – опыт, который я накопил.

Цитата nvm, 05.09.03, 20:03:40

2. Концептуальные основы современных систем не менялись последние 30 лет: все работающие сейчас идеи были заложены в UNIX. Исключение составляет идеология Turbo Vision, разработанная десяток лет назад компанией Borland. Эту технологию MS как раз и положило в основу Windows: вопрос, оплатила ли она лицензию за использование.

Вообще-то, в Turbo Vision не было ничего принципиально нового. ООП и "окошки" появились куда раньше. Посмотрите [link=http://www.parc.com/about/history/]здесь[/link], за 1972 год.

Цитата nvm, 05.09.03, 20:03:40

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

UNIX является далеко не первой ОС, и она могла и не быть такой удачной. Её вообще могло бы не быть, если бы Кен Томпсон и Деннис Ритчи в своё время не участвовали в проекте по созданию ОС MULTICS. Только благодаря этому они смогли довольно быстро создать свою ОС с нуля. И далеко не сразу UNIX стал таким округло-элегантным, каким мы его привыкли видеть.

Цитата nvm, 05.09.03, 20:03:40

4. Новую систему разумно сделать без <дыр> (без ошибок в защите). Это вполне достижимо: один из путей - за каждый написанный под данную систему вирус выплачивать премию (хотя бы $10000). Разработчики вирусов - очень квалифицированные тестеры программных продуктов, а поскольку они работают в значительной степени на энтузиазме, то их правильное использование может быть очень эффективно.

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

Цитата nvm, 05.09.03, 23:45:24

Файловая система PlainFS.

Логическая структура файла (образ на диске):
struct File
{
     key read;      ключ доступа на чтение
     key write;       ключ доступа на запись
     int8 refs[];      ссылки на файлы (смещения до первых секторов)
     char name[];      имя файла
     char data[];      данные
};

Файл является единственным элементом системы, содержит ссылки на другие файлы, заменяя каталоги.
Права на запись не дают прав на чтение. Если ключи доступа пустые, то используются ключи предка.
Ссылки все двусторонние. Первая ссылка - на предка.

Каждый сектор диска имеет следующие служебные поля:
- относительный адрес начального сектора файла,
- признаки исправности предыдущего и следующего секторов (?),
- относительный адрес следующего сектора файла.

Все области диска равноправны, выделенные служебные структуры (области) отсутствуют, положение корневого файла произвольно.

Каждую идея требует критической оценки. Здесь до кучи всяких аспектов:

1. Устойчивость ФС к логическим и физическим ошибкам. Это значит, чтобы маленькая ошибка не приводила к потере большого объёма данных.
2. Компактность хранения данных. Накладные расходы – каталоги, индексы, метаданные должны занимать относительно мала места.
3. Высокая производительность. Сама архитектура ФС должна способствовать быстродействию. Данные не должны быстро фрагментироваться. Минимизация числа действий, необходимых для чтения/записи (перемещения головок диска при поиске фрагментов файла). Удобная структура данных для проецирования файлов в виртуальную память.
4. Гибкая система управления правами доступа. Не только традиционные rwx-rwx-rwx, но и suid, права на добисывание к концу файла, ACL-листы и др.
5. Простота реализации. Это сократит число ошибок в драйвере, облегчит портирование на другие платформы и снизит затраты памяти и времени процессора во время выполнения.
6. Различные фичи.
6.1. Индексирование для ускорения поиска.
6.2. Возможность нескольких потоков в файле.
6.3. Возможность назначения дополнительных атрибутов файлам/каталогам.
6.4. Специфические объекты ФС – линки, каналы, и проч.
6.5. Компрессия.
6.6. Шифрование.
6.7. Журналирование.
6.8. Поддержка различных RAID.
6.9. Hot-fix.
6.10. Поддержка локалей или Юникод.

Если я что забыл, поправьте.
Кроме того, выбираемое решение зависит от предполагаемой сферы применения и типа носителя: магнитный перезаписываемый диск, ROM-диск, магнитная лента, Flash, RAM, ROM. Например, в наладонниках используется Flash и ROM, и там совершенно излишне журналирование, индексирование и гибкое управление правами на доступ. Естественно, не нужен и RAID, и Hot-fix.

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

PS: и вообще, со своей ФС лучше повременить до создания действительно работающей ОС. На первых порах можно обойтись FATом или UFS.

Цитата nvm, 06.09.03, 20:24:36

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

В таком случае, ОС вряд ли будет надёжной, поскольку этом случае из-за сбоя в одном приложнии-драйвере будет разрушена целостность всей системы. А эти сбои более чем вероятны, потому что приложение – это, по своей сути, процесс с большими ограничениями, которому позволено допускать ошибки. Например, если мы в системе с виртуальной памятью (с подкачкой страниц из файла) драйвер жёсткого диска реализуем на уровне приложения, то страничный сбой в драйвере приведёт к тому, что система зависнет, поскольку для обработки страничного сбоя нужно, чтобы работал драйвер диска, но это невозможно, потому что сбой произошёл именно в нём. Конечно, некоторые драйверы можно реализовать на уровне приложения, например, драйвер принтера. Да так и сделано в WinNT...

Сложнее обстоит с теми драйверами, от эффективности работы которых зависит производительность всей системы. Например, графический драйвер. Именно поэтому в WinNT 4.0+ GDI работает в режиме ядра. У такого подхода, конечно, есть свои минусы, но во всяком случае, драйверы дисков должны работать только в ядрёном режиме.

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

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

Цитата nvm, 06.09.03, 20:24:36

Сама ОС не занимается файлами, она только фиксирует интерфейс, по которому одно приложение может запросить (передать) файл у другого приложения.
Сам интерфейс предположительно состоит из абсолютно стандартных функций: open, read, write etc.

Это сродни VFS в UNIX: декларация интерфейса для доступа к различным ФС. В этом случае, все драйверы файловых систем имеют одинаковый интерфейс: open, close, read, write, который представляет собой таблицу указателей на ф-ции.

Цитата nvm, 06.09.03, 20:24:36

Цитата Shaman, 06.09.03, 14:24:42

Может всё-таки изучить существующие проекты. Выяснить, какие перед ними стоят цели, что уже достигнуто, какие проблемы возникали, и тд, и тп, и др...

Это было бы хорошо, но не взамен, а в дополнение.
Идеальным ИМХО был бы такой вариант: просто высказывать и обсуждать идеи, как должна быть устроена идеальная ОС, причем оптимально, если половина высказываний будет авторскими, а половина цитированными из других источников.

Изучение того, что было сделано до нас, просто необходимо – в противном случае мы будем только повторять ошибки наших предшественников. И чтобы всё обсуждение не повисло в воздухе, для начала надо иметь мало-мальски работающее тривиальное ядро ОС, драйвер консоли, бутлоадер и портированную (хотя бы частично!) стандартную библиотеку компилятора Си (imho, лучше GCC). Основываясь на этом, можно двигаться дальше – выдвигать идеи и тут же проверять их на работающем коде. Исли же идеи не проверять на жизнеспособность, то можно построить ОС, совершнно ни к чему не пригодную.

Цитата nvm, 06.09.03, 20:24:36

Другие проекты, я естественно изучал, и то что здесь предлагаю (вернее, большей частью еще только начал описывать) основано на идеях, встречавшихся в разных источниках.
Во-первых, это идея ключа (видел где-то в одной классической работе).

Честно говоря, ничего не знаю об этой работе. Не дадите ссылку? Вообще, было бы очень здорово организовать что-то вроде библиотеки ссылок, наподобие вот [link=http://aarongray.members.beeb.net/links/alt-os-development.html]этой[/link]. Я, со своей стороны, тоже мог бы поделиться некоторыми по этой теме.

Сообщение отредактировано: vilmor - 08.09.03, 15:24

Цитата Vilmor, 08.09.03, 19:13:33

Каждую идея требует критической оценки. Здесь до кучи всяких аспектов:
1. Устойчивость ФС к логическим и физическим ошибкам. Это значит, чтобы маленькая ошибка не приводила к потере большого объёма данных.

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

Цитата

2. Компактность хранения данных. Накладные расходы – каталоги, индексы, метаданные должны занимать относительно мала места.

С этим похуже, чем в FAT, но 2\% накладных расходов - не так страшно.

Цитата

3. Высокая производительность. Сама архитектура ФС должна способствовать быстродействию. Данные не должны быстро фрагментироваться.

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

Цитата

4. Гибкая система управления правами доступа. Не только традиционные rwx-rwx-rwx, но и suid, права на добисывание к концу файла, ACL-листы и др.

Хуже! Даже не rwx-rwx-rwx, а один rw !
Если нужно что еще, для этого есть Базы данных.

Цитата

6. Различные фичи.

И это - либо в БД, либо спец. файловом менеджере - не стоит грузить этим ОС.

Цитата

Так вот, если говорить о вашей ФС, то там ещё много белых пятен. Не ясно, как происходит поиск свободного места на диске

Sorry, забыл в структуру файла вставить поле атрибута: живой/удаленный.

Цитата

как предотвращается зацикливание ссылок

Оно разрешается, правда не для "генеалогических" ссылок

Цитата

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

Кеширование - нет, а проецирование (да и чтение) замедлит. Но несильно: добавляется только одна векторная операция копирования памяти - это, думаю, недолго, по сравнению с чтением с диска.

Цитата Vilmor, 08.09.03, 19:14:22

В таком случае, ОС вряд ли будет надёжной, поскольку этом случае из-за сбоя в одном приложнии-драйвере будет разрушена целостность всей системы.

Наоборот, если драйвер работает в пользовательском режиме, то система его при сбое может выкинуть или перестартовать - а в режиме ядра он может сам попортить систему.

Цитата

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

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

Цитата

но во всяком случае, драйверы дисков должны работать только в ядрёном режиме.

На это можно идти разве что от безысходности - если архитертура процессора иного не позволяет..

Цитата

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

Не любая!! У каждой задачи есть Битовая карта ввода-вывода. Она задает маску разрешенных для задачи портов устройств. То есть даже в пользовательском режиме можно управлять доступом.

Цитата

И ещё надо помнить, что драйверы традиционно отделены от приложений ещё и потому, что работа приложений построена по принципу недоверия друг к другу,

Писателям драйверов тоже не очень стоит доверять..

Цитата

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

Возврат во времена MS-DOS. Отсутствие защиты.

Цитата

Не любая!! У каждой задачи есть Битовая карта ввода-вывода. Она задает маску разрешенных для задачи портов устройств. То есть даже в пользовательском режиме можно управлять доступом.

По какому принципу можно отдавать приложению права на устройство. В итоге все ими смогут управлять.
А если еще и все прерывания таким образом отдавать всем приложениям.

IMHO со стороны безопасности и надежности это неправильно. Надо как-то этот уровень защитить.  Поэтому в любом случае драйвер будет идти как-то отдельно.

Цитата

Писателям драйверов тоже не очень стоит доверять..

В данной системе получится, что не надо доверять и обычным писателям.

Цитата

Наоборот, если драйвер работает в пользовательском режиме, то система его при сбое может выкинуть или перестартовать - а в режиме ядра он может сам попортить систему.

Может лучше обдумать как выкинуть драйвер из защищенного режима.

Вот грубое описание идеи ключей. Это довольно абстрактная идея, поэтому многие ее возможности не сразу очевидны..

Ключ – универсальный идентификатор «субъекта» (приложения).
Вид:
root\parent1\...\parentN\name, где name – идентификатор ключа, parentX – идентификаторы предков.

Действия:
– ключ можно создать,
– уничтожить,
– передать,
– ключом можно владеть,
– можно ассоциироваться с ключом,
– на ключ можно ссылаться.

Правила.
Каждый ключ уникален (нельзя создать «дубликат»).
Создать ключ можно только как потомка одного из ключей, уже находящихся во владении. Исключение составляет root.
Владелец ключа имеет право уничтожить всех его потомков, но не сам ключ.
Владелец может передать владение любому приложению, при этом он также остается владельцем.
Каждому приложению должен быть назначен идентифицирующий его ключ, который находится в его владении. При уничтожении идентифицирующего ключа приложение аварийно завершается.
Ключ – единственный способ идентифицировать приложение, и единственное средство определения прав доступа.
Во всех сообщениях, отправляемых приложениями, указываются ключи отправителя и получателя (выступают в роли адреса). При отправке сообщения потомку ключ отправителя может фальсифицироваться – в остальных случаях система (ядро) гарантирует его достоверность.

Цитата rcz, 08.09.03, 21:06:43

Возврат во времена MS-DOS. Отсутствие защиты.

При чем здесь DOS?? Речь идет о пользователе с правами root - остальные вообще ничего вредоносного сделать не смогут.
А root - он и в Африке root.. Только думаю работу в привилегированном режиме и ему не стоит разрешать.

Цитата

По какому принципу можно отдавать приложению права на устройство. В итоге все ими смогут управлять.
А если еще и все прерывания таким образом отдавать всем приложениям.

Идея такая.
В начале работы все порты и прерывания открыты.
В ходе выполнения autoexec загружаются приложения-драйвера, которые "забирают" порты себе.
Для ядра ВСЕ приложения изначально равноправны, поэтому, кто первый попросит - тому права на порт и будут отданы. После чего порт помечается занятым, и никто больше к нему не допускается.
Задача администратора - включить в autoexec все, чтобы перехватить важнейшие устройства.

Цитата

IMHO со стороны безопасности и надежности это неправильно. Надо как-то этот уровень защитить.  Поэтому в любом случае драйвер будет идти как-то отдельно.

Так мы получим Linux, который уже и так есть...
А надежность гарантируется 100\%.

Цитата

Может лучше обдумать как выкинуть драйвер из защищенного режима.

Это сильно усложнит дизайн.
А схема с микроядром и равноправными объектами представляется простой и изящной. 8)

Вот общий дизайн системы.

Файл=каталог, процесс=задача=приложение, поток=нить.

Указатели в системе все 6-байтные – включают сегмент.
Handle — целое число, позволяющее ссылаться на объект приложения (уникален лишь в пределах приложения и для заданного класса объектов).

Ключ – уникальный идентификатор объекта.
Используется тремя способами:
— ассоциирование объекта с ключом,
— ссылка на объект через ключ, авторизация,
— владение ключом: получение прав на объект.
Ключи образуют иерархию порождения. Родитель имеет полный контроль над потомками, имеет право перехватывать адресованные им сообщения, подменять в них ключ отправителя, посылать сообщения от имени потомков.
Ключ задается текстовым именем, включающим имена всех предков.

Функции ядра:
— управление памятью и портами ВУ,
— управление потоками,
— поддержка (обеспечение) ключей,
— транспортировка сообщений.

Список функций.

GetMemory — выделяет память заданного размера на заданный указатель (приложение само конфигурирует свой виртуальный образ). Вариант функции: вместо размера передается handle памяти, полученной от другого процесса.
FreeMemory — освобождает память по заданному указателю.
handle CreateThread(proc_ptr,stack).
handle CreateSemaphore()

handle CreateKey(name,password[,parent_key]) — создать ключ.
handle FindKey(name) — найти ключ.
GrantKey(handle key, handle recipient_key) — передать права на ключ.

CreateTask(mem_handle, task_key) — при создании задачи ей должен быть передан ключ, который будет с ней ассоциирован.

PostMessage — поставить сообщение в очередь процессу.
SendMessage — поставить сообщение в очередь процессу с ожиданием обработки и получить ответное сообщение (эквивалент функционального вызова).
RunMessage(stack) — переслать сообщение ожиданием обработки и получить ответное сообщение. При этом в принимающей задаче автоматически создается новый поток в счет ресурсов отправителя (получается полный эквивалент функционального вызова).

TraceMessages(child_key) — включить перехват сообщений задачи.

GrantPort — передает приложению доступ к порту.

Все функции вызываются в форме сообщений RunMessage (кроме самих функций сообщений).