Вот всегда интересовало мнение на этот счёт   

Это суровая необходимость..)

Rohoss, учитывая время создания - начало 90х годов. Времена, когда язык С был еще весьма популярен, то это весьма приличный набор библиотек. По тем временам оно было весьма продуманно и удобно. На текущий момент такого уже не скажешь, но сейчас Microsoft уже и не предлагает его использовать. Написали свой .NET framework , который закрывает во многом типичные нужды. 

WinAPI это внешний интерфейс ядра ОС. Ядро нативное. Интерфейс должен быть совместим с любыми языками, не только С.
Этому интерфейсу много лет, и его последняя версия он полностью обратно совместима с устаревшим софтом.

Мне сложно придумать как можно было бы сделать winapi лучше.

GoldFinch, компиляторы пишут под платформы, а не платформы под компиляторы. Так что неправ. Возьмем язык шейдеров, что винда тоже должна обеспечивать совместимый интерфейс? 
  Или же возьмем COM объекты шела. Что они делались для совместимости с языком С? 

  Для ОС важно соблюсти или утвердить некий бинарный стандарт, который должны поддерживать компиляторы. Первоначально расчет был на совместимость на уровне машинных кодов i386, для того чтобы расширить круг имеющихся компиляторов и облегчить адаптацию. После они дополнили бинарным стандартом COM/ActiveX и он стал похожим на объектный, далее расширили до .NET и представили полноценный объектный бинарный стандарт на уровне CLR. 
  

  Если говорить о части user api, то на сегодняшний день .NET заметно удобнее. 

посмотреть на unix-api ;)

Ящик Пандоры.

  Не поможет  . Нужно заменять всю базу.

Alexeis, не надо путать winAPI, COM, и .NET
WinAPI - это Windows API - программный интерфейс Windows для приложений.
COM - это набор соглашений о взаимодействии компонентов вообще, без какой либо привязки к ОС. 
.NET - это платформа для выполнения MSIL, без какой либо привязки к ОС. 

Компоненты COM отвечающие за взаимодействие с ОС, работают через WinAPI.
Та часть .NET которая отвечает за взаимодействие с ОС, работает через WinAPI.
По сути системные компоненты COM и .NET это не более чем обычные нативные приложения, ни чем не отличающиеся от любых других приложений.
Точно также можно сказать о платформе питона в windows. Это такая же платформа, что и .NET.


==================

Почему в винде куча языков - ассемблеры, Си, дельфи,
а в никсах только Си?

Потому что в винде АПИ ОС развернуто лицом к разработчику языка, а не только к Си, как в никсах.

Добавлено через 2 минуты и 35 секунд
Алсо у меня есть впечатление, что WinAPI ругают те кто не умеет его использовать, и не понимают как оно работает.

Добавлено через 4 минуты и 44 секунды
Но все же, как сделать winapi лучше, сохранив весь legacy код?

Интересная информация какая.




Зачем его делать лучше?

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

>Почему в винде куча языков - ассемблеры, Си, дельфи,
>а в никсах только Си?
>Потому что в винде АПИ ОС развернуто лицом к разработчику языка, а не только к Си, как в никсах.

Когда чего-то не знаешь, принято молчать или интересоваться, а не морозить глупость. Я так считаю.

Ты путаешь обертку к АПИ ОС, и АПИ ОС.

возьмем например fopen.
оно работает с огромной структурой которая дублирует структуру в ядре ОС,
оно получает флаги парсингом строки о_О
оно не умеет и половины того что умеет CreateFile

GoldFinch, сравни винапишный CreateFile и юниксовый системный вызов open. Почувствуй разницу так сказать. А ведь CreateFile еще далеко не лидер по количеству бездарных параметров.

http://www.opennet.ru/man.shtml?topic=open&category=2

Это сообщение отредактировал(а) djamshud - 17.5.2010, 16:45

djamshud, WinAPI - это АПИ ОС. Оно максимально отражает сущности в ОС и обеспечивает управление ими.

Почему CreateFile - называется "Create" а не open?
Потому что в ядре ОС есть объект "файл". CreateFile создает этот объект. При этом при создании этого объекта надо обеспечить возможность указать все необходимые параметры создаваемого объекта.

Почему в никсах open есть перегрузки, а у CreateFile нет? Потому что никсы заточены под на Си, и там можно юзать манглинг Си. А WinApi рассчитано на любые языки, по этому там не может быть использован манглинг, а значит там не может быть перегрузок.

А слабо привести пример? Где именно они лучше, и чем?

Добавлено через 2 минуты и 43 секунды
Миня лично бесят оконные процедуры... Как по мне, весь их функционал должен быть реализован в других функциях... При чем тут вообще окно?  

WinAPI - это не библиотека языка Си или какого-то еще языка.


как вызвать "юниксовый системный вызов open" не из Си, а например из асма?

  Еще скажи, что это не изобретение Microsoft. А вот как ты получишь доступ к объектам шела на WinApi не используя COM? Или как создашь устройство DirectX? Чушь это все. COM объект реализуется в исполняемом модуле PE стандарта Windows, при регистрации требует реестр. Ну просто пипец как не связан с Windows. Ну просто ничего общего.
  

  Однако она не работает НИ ГДЕ кроме как на Windows машинах. Переносимый код пишется на CF или Mono. 


  Это приложения, которые имеют строгую архитектуру, в их исполняемых модулях нет прямых ссылок на API функции (разве что kernel32), точно также как и QT. 
  Если дом построили из железобетона, никто ведь не говорит, что дом построили из песка, цемента и арматуры, а говорят панельный дом.


  В винде нет кучи языков. Языки существуют безотносительно платформы. В никсах также доступно много компиляторов. Для того же Delphi-Object Pascal существует компилятор Free Pascal под линукс. Аналогично на C# можно писать под Mono, CF или .NET .

 

>WinAPI - это АПИ ОС. Оно максимально отражает сущности в ОС и обеспечивает управление ими.

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

>Потому что в ядре ОС есть объект "файл". CreateFile создает этот объект. При этом при создании этого объекта надо обеспечить возможность указать все необходимые параметры создаваемого объекта.

open тоже создает объект файл и возвращает его идентификатор (HANDLE). Функция позволяет (а не заставляет) задать любые необходимые параметры.

>Почему в никсах open есть перегрузки, а у CreateFile нет? Потому что никсы заточены под на Си, и там можно юзать манглинг Си. А WinApi рассчитано на любые языки, по этому там не может быть использован манглинг, а значит там не может быть перегрузок.

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

Добавлено через 36 секунд
>как вызвать "юниксовый системный вызов open" не из Си, а например из асма?

call open

Добавлено через 4 минуты и 44 секунды




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

Alexeis, оболочка windows (шелл) - это не более чем обычная программа. Это не ОС. Это оболочка ОС. Ее можно заменить на что-то другое, без COM.

даже не смешно. 99.95%  программ - это PE. 88% работают с реестром. 
COM - это не интерфейс ОС. Не каждый COM объект это часть ОС.

зато есть в mscoree и т.п.

Alexeis, у ОС есть ядро. Оно нативное. Оно не использует COM. WinAPI - это интерфейс ядра ОС. А не интерфейс системных компонентов COM и библиотек .NET.
В конце концов это весьма странный спор. Я много раз дебажил программы, попробуйте и вы. Возьмите отладчик и подебажте системные компоненты COM или .NET. Вы сразу увидите как именно они связаны с ОС.


VB, который чистый COM, под никсы есть? Я что-то с трудом представляю себе строчку

djamshud, а зачем ОС что-то прятать? все что *нужно* прятать, в винде "спрятано" в native API, все что может быть доступно программисту - то доступно программисту.


мне это говорит только о том, что где-то есть библиотека (.lib) которая и вызывает непосредственно системную open
эта .lib (наверное libc.lib) линкуется с твоим .obj и получается программа которая вызывает open
но это все средства Си

представь что я хочу написать для никсов компилятор нативного кода, чтоб сразу elf генерил (или что там исполняемое в никсах)
что мне надо сгенерить чтобы вызвать эту самую open? как оно все выглядит изнутри?

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

посмотрел на ELF. вопрос снят.

  Visual Basic это компилятор бейсика под Windows. Язык это Basic или его разновидность. Для линукса есть REALbasic.


  Читаем вики

  Где тут хоть слово про ядро ОС? Речь об интерфейсах программирования операционной системы. Интерфейсы могут описываться как функциями так и объектами при условии что определен объектный стандарт. Функции Shell, DirectX, BITS это также интерфейсы программирования операционной системы Windows. И чем дальше тем больше. 
  

  Ну так и что с того? Разве непосредственный вызов внутренних функций документирован как API? Есть документация на программный интерфейс DirectX Там английским по черному написано про COM объекты. Тоже самое и взаимодействие с оболочкой, тоже самое и с .NET . Программный интерфейс такой какой он определен, а не такой как реализован. Любая недокументированная функция может впоследствии менять свое поведение или полностью исчезать. Для программиста это должен быть черный ящик.
  Такие функции как CreateFile это интерфейс основанный на функциях, IDirect3D9::CreateDevice прикладной интерфейс основанный на COM объектах, даже если метод CreateDevice вызывает внутри только функции ядра. Я об это не знаю, более того я об этом не должен знать, потому что автор оставляет за собой право менять реализацию как он хочет.

Alexeis, если я разработаю свою технологию компонентов FinchComponentObjectModel ™, и сделаю компонент FSystem который позволит работать с системой, то вы назовете это winAPI?

А если я разработаю свою платформу FinchNET, в ней будет встроенная библиотека System, то вы тоже назовете это winAPI?

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

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

Благодарю, что дал повод глубже просветиться в этом вопросе. Но это не отменяет того факта, что интерфейс винапи на примере того же CreateFile просто отвратителен. Про работу с окнами (они ведь до сих пор в ведре наверное?) я промолчу.

Про непосредственно структуру ELF не знаю, оно мне пока как бы и не надо.

мне одному кажется что это неправильный перевод "API" применительно к windows API?
API - это интерфейс программирования (программного управления) приложений, но в случае windows API - в роли приложения выступает windows,
и windows API надо понимать как "интерфейс программного управления windows".

Добавлено через 6 минут и 41 секунду
djamshud, а что с CreateFile не так? То что там флаги сгруппированы по нескольким аргументам? Это удлиняет сигнатуру, но не более того, кому-то такая группировка будет даже удобней. То что там опции безопасности есть? У всех хендлов объектов ядра есть опции безопасности, в ряде случае их необходимо заполнять, но обычно их заполнять не надо, то что тут плохого? Обычный опциональный параметр. То что там хендл файла-шаблона есть? Опять же необязательная вещь.
Или ты предлагаешь сделать не 1 функцию, а 4 с разными комбинациями опциональных параметров? Сомнительное решение, учитывая что там нельзя использовать перегрузки.

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

АПИ ОС не обязано быть сложным. Как пример простого АПИ я не просто так привел лаконичное юниксовое, я его время от времени использую. И я использовал винАПИ. Исходя из этого (а не потому, что юникс фарева!!!11 (хотя это так:) )) я и заявляю, что винАПИ - это просто чудовищный п-ц и издевательство над программистом.

Добавлено через 1 минуту и 59 секунд
Плюс к разговору о разбиении функций на несколько. В винАПИ и сплошь и рядом наблюдаются функции с разными префиксами или постфиксами.

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

тем кто это юзает - тем нравится

>короткое популярное имя в глобальной области видимости - это зло

Как показывает практика, короткие емкие имена и такая же система типов - это просто сказка. Возрастает как скорость написания, так и понимание кода, который не прячется за забором БесконечноДлинныхФункций(И,НЕВМЕНЯЕМЫХ,ПАРАМЕТРОВ).

>>И оно никому не нравилось.
>тем кто это юзает - тем нравится 

В данном случае я приводил мнения тех, кто юзал (а может и сейчас юзают). Впрочем пруфов IRL не будет.

  Windows не может быть приложением к самой себе. Windows является базовой программой, а программы под Windows изначально определялись как дополнения к ней, приложения, почти что плагины к ОС. Кстати неплохая аналогия. Windows для приложения тоже, что приложение для плагина. Т.е. программа (Windows) предоставляет набор прикладных интерфейсов и сервисов для взаимодействия оборудованием. Кроме того каждый интерфейс определяет некий бинарный стандарт определяющий правила воздействия на закрытый конечный автомат (или группу таких конечных автоматов). Изменение состояния такого автомата возможно только путем посылки ему сигнала, но не более того.
  Сигналом, в общем случае может быть все что угодно, например функция, аппаратный регистр, пакет данных полученный из сети (функция приема одна, пакеты могут быть разные), и т.д. Сигналом можно считать не только то что непосредственно реализуется в машинных кодах, в конечном итоге его следует рассматривать не более чем оператор, реализация же не определяет его логической сути.

  Windows API нельзя определять только как набор функций для взаимодействия с модулями kernel32 user32 gdi32 . Куда же в таком случае отнести Comctl32.dll ? Shscrap.dll ? Ole32.dll ? comsvcs.dll ? setupapi.dll ? crypt32.dll ? ws2_32.dll ? shell32.dll 

Кстати вот что есть в английской Wiki по Win API
The functionality provided by the Windows API can be grouped into eight categories
Base Services
Advanced Services
Graphics Device Interface
User Interface
Common Dialog Box Library
Common Control Library
Windows Shell
Network Services

Речь о самых крупных частях. Далее упоминается о Web движке включая IE msxml,  Multimedia (DirectX), Program interaction (DDE, OLE, COM и т.д.) 

Т.е. понятие Windows API намного более широкое чем просто 3 базовых модуля ядра.

Добавлено через 7 минут и 5 секунд

  Не нужно смешивать все в кучу. Первоначально всего этого не было. Объем это результат сохранения обратной совместимости. С префиксами и постфиксами все просто. Например постфикс Ex означает расширенную версию. Цифровой постфикс версию API. 
  Правильным является изучение новых API, которые призваны заменить старые. Весь набор избыточный. 

каков размер winapi?
имеется в виду количество системных функций и их отображений в userspace
удовлетворяет ли он принципу Оккама?
касаемо параметров, большое их количество свидетельствует о недостаточной продуманности интерфейса
пример продуманности...взять тот же ioctl
основан на уровнях доступа и концепции файлов
по сути все, что надо для работы с любым объектом, обладающим файловой семантикой
это сам объект (его отображение в userspace в виде дескриптора), команда и параметр
ни убавить, ни прибавить
рассмотрим open/creat vs. CreateFile
зачем пихать все в CreateFile, если, скажем фактически для создания важны только режим доступа и идентификатор?
все остальное - ioctl

Добавлено через 3 минуты и 45 секунд

уровни доступа
слышал про setsockopt
работает со всеми доменами и протоколами для любых типов сокетов
5 исчерпывающих параметров

Добавлено через 9 минут и 26 секунд

есть еще С++, java, perl, python, Go, haskell, lisp и много много других ;)
а то, что С используется чаще всего, так это потому, что в умелых руках он превращается в мощнейшее орудие разработки
стОит ли говорить, что подавляющее большинство либ написаны на С и этим богатством можно воспользоваться напрямую без всяких кривых биндингов

  В общем слив засчитывается. Функция должна иметь столько параметров сколько будет реально использовано при 90% ее вызовов. Остальное должно настраиваться опционально. Некоторые функции этим страдают. Нельзя сказать что многие.

А лучше всего, когда передаёшь параметром специальный объект... 

  Так оно всегда так и происходит. Дескрипторы которые создают и повсеместно используют фактически указатели на системные объекты. Или речь о другом специальном объекте?

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


ни один из них не работает с АПИ ОС напрямую.
а в винде даже VB, который компилится в байткод, может вызывать winapi (экспорты любых dll)

Потому и написаны на Си, что больше не на чем.
В винде достаточно значительная часть системного кода пишется не на Си.
Собственно зачем писать на неудобном Си, если есть более удобная высокоуровневая дельфи, и более удобный низкоуровневый масм?

Это сообщение отредактировал(а) GoldFinch - 18.5.2010, 00:30

Посмотрел. 
Увидел пару fork-exec. 
Испытал неуловимо гнетущее впечатление. Содрогнулся. (с)

Да что там CreateFile. Вот когда дело касается реестра или окон... Разве не прелесть:



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

Шедевр.

земля.

я говорю о более глобальных вещах
естественно, если чего-то требует архитектура, то никуда от этого не денешься
другое дело, что api - Это отображение архитектуры ;)



если уж на то пошло
то и С не юзает напрямую api ;)



C - определенный стандарт в unix-like системах
и не потому, что больше не на чем (как раз выбор больше), а потому, что С одновременно и простой, и мощный
одна из концепций unix заключается в принципе, чем проще тем лучше



значит архитектура подсистемы безопасности кривая
в linux, к примеру, во первых подсистема безопасности модульная (DAC, selinux)
а во-вторых, не потребовала ни разу изменить posix api
и в -третьих, легко позволила получить eal4 (rhel5)
http://www.niap-ccevs.org/cc-scheme/st/?vid=10125
а NULL может быть и не мешает
но тем не менее доля статистики опроса на его совести ;)

Добавлено @ 08:54

вот и я про то же
каков размер winapi (количество непосредственно отображаемых в userspace системных вызовов)?
соблюдается ли принцип Оккама?

Добавлено @ 08:58

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

  Это еще как? Переход по адресу разве это не напрямую? Или ты имеешь ввиду, что API это прослойка к нативной ntdll.dll?

Alexeis, 
MAKCim видимо имеет ввиду механизм статического импорта для .obj : для каждой длл используются библиотеки импорта с переходниками на функции API. При этом имена переходников не совпадают с именами функций winAPI (добавляется манглинг).


Это сообщение отредактировал(а) GoldFinch - 18.5.2010, 09:23

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

  Какой компилятор делает так? 

Вот смотрю пример вызова CreateEvent





Адрес хранящийся в памяти по адресу 

007a3548 - 0E 18 28 76

Переход к kernel32.CreateEventW


Где тут использование дополнительной либы?

Это сообщение отредактировал(а) Alexeis - 18.5.2010, 11:49

kernel32 ;)
вот ежели б компилятор генерил код, напрямую дергающий sysenter/syscall, int и пр. механизмы межуровневых переходов процессора
тогда да

  Причем тут язык С тогда? По другому к винде системе не обратишься из юзермода . Это не библиотека языка С, а библиотека ядра ОС. Что с того, что часть ее кода выполняется в юзермоде? В чем принципиальная разница будут ли эти операции производиться в твоей программе или же в системой библиотеке? 
  На самом деле вызов функции из kernel32 это лишь начало целой цепочки вызовов. Обычно стек внутренних системных вызовов разрастается до 6ти и более функий.

Alexeis, 
GoldFinch выдвинул тезис

это касаемо C++, Java, Python и т. д.


я ответил


компилятор преобразует С код в код, юзающий libc
равно как Java преобразует байт-код в нативный код, который либо юзает api системы через сисколы напрямую
(тогда тезис априорно не верен)
либо через ту же libc, как и С
и в этом случае тезис не верен ;)


Alexeis, 
ты как бы теряешься в сути разговора

  Да где же в приведенном мной куске код использования libc ? Я вижу прямой вызов WinAPI функции. Почему ты определяешь что системные вызовы это только вызовы в режиме ядра? Операционная система не предоставляет другого документированного способа для доступа к ее внутренним ресурсам.

  Я не опровергаю, того что другие языки также могут также компилировать свой код в вызовы WinAPI. Я не вижу где в приведенном коде прослойка рантайма С. Некоторые функции библиотеки С действительно внутри используют вызовы WinAPI, но программист может, их не использовать совсем. Например отключить полностью CRT. 

режим ядра - это работа на нулевом кольце привилегий
где я об этом говорил?

api системы - это не врапперы в libc или kernel32.dll
это то, что непосредственно предоставляет ядро ОС
в той же libc тысячи функций, но не все они - api

MAKCim, часть функций winapi работает только в юзермоде, им не надо syscall\sysenter и т.п.
ядро работает как в ring3, так и в ring0

я понял 
у нас разные представления об api



что из ядра работает в ring3?

MAKCim, у нас разные представления об ядре.

ring3 и ring0 - это состояния потока. поток постоянно переключается из ring0 в ring3 и наоборот.
ядро не "работает в кернелмоде". часть кода ядра выполняется потоками в ring0. 
причем один и тот же код может работать как в ring3, так и в ring0

Вот что пишет MS в справке к WRK

Например функция RtlRemoteCall - работает в юзермоде, и это часть RTL ядра.

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

блин, ребята
я всегда понимал и понимаю под ядром непосредственно то, что отлично от любой внешней программы
для linux это все, что в /usr/src/linux
так вот, эта хрень под названием ядро работает только в ring0
а вот уже _пользовательские процессы_ постоянно переключаются ring3 <-> ring0

О, кстати как раз вот нужно. Не подскажешь системный вызов, соответствующий GetCurrentProcessId?

bems, 
getpid()

MAKCim, я вобще-то про винду говорил

интереснее выглядит функция ядра GetCurrentProcess (и GetCurrentThread)

хотя с Id тоже ничего

Это сообщение отредактировал(а) GoldFinch - 18.5.2010, 22:22

Функция ядра?
Ну возвращают они константы, ничего особенно интересного не вижу.
Так где тут системные вызовы? (за 5 минут мы 4 штуки насчитали где их нет)

Добавлено через 45 секунд
GoldFinch, изивиняюсь. вопрос был к MAKCim

я должен наизусть все номера знать? ;)

bems, тех которые работают в юзермоде - полно. Те же GetModuleHandle и прочие, работающие с TEB и PEB.

Добавлено через 2 минуты и 35 секунд
MAKCim, а как отличать функции ядра от не-функций ядра? лазать в сорцы ядра, и смотреть, должна функция работать в ring0 или нет?

Нет. Признать что они отсутствуют.
А значит это

в винде неверно

Добавлено через 33 секунды
GoldFinch, му говорим об одном и том же. 

GoldFinch,
ты что, издеваешься?
функция ядра по определению - часть исходного кода ядра или драйвера, работающего в ядре в ring0
все остальное - userspace функции
они работают в ring3 и при необходимости обращаются к ядру через механизм syscall'ов

т. е. к примеру, fork() - это userspace функция, которая через int 80h, syscall/syseneter передает управление функции ядра sys_fork()/sys_clone()

какая-то демогогия пустая...

MAKCim, то есть функция-геттер для данных ядра, отображенных на юзерспейс, не является функцией ядра?

bems, 
ну PEB/TEB берутся не из потолка, правильно
значит косвенно, тот же CreateThread/CreateProcess и соответствующие им syscall'ы формируют PEB/TEB
либо сама реализация функций предусматривает, скажем вызов недокументируемой функции получения идентификатора и его кэширования для ускорения последующего доступа

Она просто достаёт нужное значение из памяти. Поддержка этой структуры (чтобы было что доставать)- работа ядра (в основном). Без кеширования.
Так это функция ядра или нет?

Добавлено через 1 минуту и 50 секунд
MAKCim, и в догонку вопрос про GetCurrentProcess. Она возвращает константу. Но она win32 api. Ты куда её отнесеш?

нет
свою "ядерность" она утрачивает
но это скорее вопрос терминологии и кто как считает логичным

Добавлено через 1 минуту и 45 секунд

нет
я бы еще мог согласиться, если бы она была аналогом vsyscall функций в linux

Вот. А значит это тоже неверно

и компилятор все-таки напрямую вызывает апи.

perl, python, etc экспортируют названия фукнций ядра с sys/syscall.h

http://www.freebsd.org/cgi/cvsweb.cgi/src/...x-cvsweb-markup

Это сообщение отредактировал(а) gcc - 19.5.2010, 05:37

это значит что ядро написано на perl и python?

MAKCim, уже прокомментировал, что под апи он понимал только вызовы ядра, т.е. юзермодную прослойку winapi воспринимал не как часть апи, а как дополнительную либу. Т.е. спор был о разных понятиях названных одним термином. 

Не имеет значения что он имел в виду. Потому что приведенные мной примеры объективно принадлежат множеству винапи. 

  А CreateEvent объективно не относиться к WinAPI? Видишь как в линуксе понятия об api ОС несколько отличаются.