OSDev

Вот ссылка на последнее на данный момент описание MiraculixOS API
http://miraculix.ru/docs/mx_api.html

2DinamytE, не стал публиковать здесь сами описания, потому что они будут постоянно дополнятся и уточняться, да и на само описание есть постоянная ссылка указанная выше.

Вот описанные функции:

Диски и файлы:
FindFile
ReadFile
Get_FileAddress
ReadIniFile

Окна и контролы:
Create_CheckButton
Create_StdButton
Draw_StdWindow
GetWinParams
KillWindow
StdHandler

Диалоговые окна:
msgbox
ShellAbout

Курсоры:
Load_Cursor

Сообщения:
ReceiveMessage
SendMessage
WaitMessage

Процессы:
CreateProcess
ExitProcess
GetPID
TaskInfo

Текст:
StyleText
WriteHex
WriteText

Графика:
Draw_BLine
DrawPicture
End_of_redraw
Get_screen_param
PutPixel

В этой теме можно комментировать, обсуждать, конструктивно критиковать и выражать своё мнение по той или иной функции.

Что-то какая-то сплошная мешанина. Системных функций мало, в основном все гуёвые. Низачот :).

Доберусь до системных, будет и их описание ;)
Кстати, возможно, достаточно скоро :)

Вообще опыт показывает - что конкретика в API - это плохо... это не гибко.

Вот свежая байка в тему.

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

Возился я тут намедне с этими балонами...
В win2k3 всплывают, в win2k не всплывают сцуки.
Долго у виндуза ждал я ответа... всмысле разбирался...
Даже написал отдельную прогу, которая только и делает, что показывает балоны...
Но опять таки, в 2k3 показывает, а на 2k не показывает сцуко!!!
Думаю, может я слишком многого хочу, поотрубал все - не показывает (осталось 7 строчек кода!)
Целый день я мучал всех подряд с этими балонами, но очень трудно найти специалиста по балонам.
Многие занимались - но никто не знает че за фигня...

В конце концов ответ конечно же нашелся...

Есть структура NOTIFYICONDATA.
В одном из ее полей хранится ее размер.
Актуальной является структура третьей версии.
Но 2000 понятия про третью версию не имеет.
поэтому думает, что структура должна иметь размер - соответствующий второй версии.
Больший размер вероятно приравнивается к некорректному и замещается размером первой версии структуры, иначе я никак не могу объяснить тот факт, что иконка то на 2k нормально работала, а вот балоны нифига. Это все рулится одной структурой.

Дык самое смешное то, что назмер этой структуры варьируется в зависимости от значения дефайна _WIN32_IE
Который во всех последних проектах по умолчанию выставлен в 0x600
Хотя на самом деле от IE трейиконки нифига не зависят, а зависят только от версии либы shell32.dll. (Я правда не исключаю того факта, что эти вещи взаимосвязанны)

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

И так блин бывает очень часто... меня их сильноотбалдыветвящиеся инклюды бесят.

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

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

Правда в реалии я таких API почти не встречал.
Хотя наблюдая например за эволюцией Win32 API видно что они пытаются объединять схожие по функционалу функции.
Правда WIN32 API с точки зрения майкрософт уже устарел и вряд ли будет развиваться дальше... Да и вряд ли они когда нибудь выкинут из них устаревшие функции... :) так что помойка как была так и остается, а новые функции тока больше все замусоривают.

POSIX - тоже обладает очень большой конкретностью.
Любое нововведение требует расширения API. - поэтому пробивается в жизнь с трудом.

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

Dron, однако posix гибче намного, а разделение на отдельные библиотеки - уже шаг к прогрессу. А в венде... ЧОрт ногу сломит в этом API. Даже разбить этот долбаный windows.h на несколько заголовочных модулей уже сложно.

SadKo, Для посикса есть стандарт всетаки... :) который описывает все функции. Здесь трудно сильно все запутать.
Насчет прогресса - я не стал бы так утверждать. :) ему сто лет в обед...

А у Win32 API - какой нафик стандарт... расширяется по мере надобности и ненадобности...

Но лучше всетаки чтобы API был менее завязан на возможности. (Надеюсь я ясно излагаю?)

Вот щас приведу простой пример.
Берем например месседжбокс.
Но тока мы берем его грамотно и описываем в xml к примеру.
Потом вызываем функцию типа ShowDialog...
Известные виджеты - он выводит нормально всегда.

Неизвестные виджеты он просто игнорирует, но при этом диалог уже соответствует новому видению.

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

Вот такие мысли у меня по поводу API.

PS: А что касается сабжа - оно крайне не гибкое... тот же msgbox...
Как в нем управлять набором необходимых кнопок?
А если захочется иконку?
А если захочется звук пустить?
У меня еще масса идей... :)

Но нереально.

Ну да, согласен. С XML было бы намного проще. И совместимость обратная есть. Хотя бы в том, что здесь нет зависимостей от размера структур и выравнивания :).

SadKo, Точно, никаких зависимостей...

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

Вообще оконная система описываемая на XML - это ИМХО очень хорошо.
Диалоги - это вещь статичная... один раз распарсив описание диалога можно пользоваться им вечно.

PS: Я конечно понимаю, что все эти рассуждения в данном топике - лишь пустое сотрясение воздуха,
ибо API Miraculix - штука состоявшаяся... но может на будующее.. или кому нибудь еще даст пищу для размышлений.

legos, Неплохо изложено, светлая память Капитану Кобальту.

В принципе идея сама действительно далеко не нова.
Взять ту же мозилу!

http://www.mozilla.org/projects/xul/

Так что идеи витают в воздухе...