| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Религиозные войны > Что такое WinAPI? |
| Автор: Rohoss 17.5.2010, 04:07 |
| Вот всегда интересовало мнение на этот счёт |
| Автор: KelTron 17.5.2010, 04:46 |
| Это суровая необходимость..) |
| Автор: Alexeis 17.5.2010, 09:10 |
| Rohoss, учитывая время создания - начало 90х годов. Времена, когда язык С был еще весьма популярен, то это весьма приличный набор библиотек. По тем временам оно было весьма продуманно и удобно. На текущий момент такого уже не скажешь, но сейчас Microsoft уже и не предлагает его использовать. Написали свой .NET framework , который закрывает во многом типичные нужды. |
| Автор: GoldFinch 17.5.2010, 13:35 |
| WinAPI это внешний интерфейс ядра ОС. Ядро нативное. Интерфейс должен быть совместим с любыми языками, не только С. Этому интерфейсу много лет, и его последняя версия он полностью обратно совместима с устаревшим софтом. Мне сложно придумать как можно было бы сделать winapi лучше. |
| Автор: Alexeis 17.5.2010, 14:20 | ||
| GoldFinch, компиляторы пишут под платформы, а не платформы под компиляторы. Так что неправ. Возьмем язык шейдеров, что винда тоже должна обеспечивать совместимый интерфейс? Или же возьмем COM объекты шела. Что они делались для совместимости с языком С? Для ОС важно соблюсти или утвердить некий бинарный стандарт, который должны поддерживать компиляторы. Первоначально расчет был на совместимость на уровне машинных кодов i386, для того чтобы расширить круг имеющихся компиляторов и облегчить адаптацию. После они дополнили бинарным стандартом COM/ActiveX и он стал похожим на объектный, далее расширили до .NET и представили полноценный объектный бинарный стандарт на уровне CLR.
Если говорить о части user api, то на сегодняшний день .NET заметно удобнее. |
| Автор: MAKCim 17.5.2010, 14:48 | ||
посмотреть на unix-api ;) |
| Автор: Exception 17.5.2010, 15:06 |
| Ящик Пандоры. |
| Автор: Alexeis 17.5.2010, 15:35 | ||
Не поможет  . Нужно заменять всю базу. |
| Автор: GoldFinch 17.5.2010, 15:47 |
| 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 код? |
| Автор: Exception 17.5.2010, 15:54 | ||||
Интересная информация какая.
Зачем его делать лучше? |
| Автор: djamshud 17.5.2010, 15:55 |
| WinAPI ругают те, кто сталкивался с ее ужасающим программным интерфейсом (чем она по сути и является) и при этом видел хорошо ораганизованные системные библиотеки. >Почему в винде куча языков - ассемблеры, Си, дельфи, >а в никсах только Си? >Потому что в винде АПИ ОС развернуто лицом к разработчику языка, а не только к Си, как в никсах. Когда чего-то не знаешь, принято молчать или интересоваться, а не морозить глупость. Я так считаю. |
| Автор: GoldFinch 17.5.2010, 16:21 | ||
Ты путаешь обертку к АПИ ОС, и АПИ ОС. возьмем например fopen. оно работает с огромной структурой которая дублирует структуру в ядре ОС, оно получает флаги парсингом строки о_О оно не умеет и половины того что умеет CreateFile |
| Автор: djamshud 17.5.2010, 16:40 |
| GoldFinch, сравни винапишный CreateFile и юниксовый системный вызов open. Почувствуй разницу так сказать. А ведь CreateFile еще далеко не лидер по количеству бездарных параметров. http://www.opennet.ru/man.shtml?topic=open&category=2 |
| Автор: GoldFinch 17.5.2010, 18:15 |
| djamshud, WinAPI - это АПИ ОС. Оно максимально отражает сущности в ОС и обеспечивает управление ими. Почему CreateFile - называется "Create" а не open? Потому что в ядре ОС есть объект "файл". CreateFile создает этот объект. При этом при создании этого объекта надо обеспечить возможность указать все необходимые параметры создаваемого объекта. Почему в никсах open есть перегрузки, а у CreateFile нет? Потому что никсы заточены под на Си, и там можно юзать манглинг Си. А WinApi рассчитано на любые языки, по этому там не может быть использован манглинг, а значит там не может быть перегрузок. |
| Автор: Rohoss 17.5.2010, 18:16 | ||
А слабо привести пример? Где именно они лучше, и чем? Добавлено через 2 минуты и 43 секунды Миня лично бесят оконные процедуры... Как по мне, весь их функционал должен быть реализован в других функциях... При чем тут вообще окно?  |
| Автор: GoldFinch 17.5.2010, 18:20 | ||
WinAPI - это не библиотека языка Си или какого-то еще языка.
как вызвать "юниксовый системный вызов open" не из Си, а например из асма? |
| Автор: Alexeis 17.5.2010, 18:41 | ||||||||
Еще скажи, что это не изобретение Microsoft. А вот как ты получишь доступ к объектам шела на WinApi не используя COM? Или как создашь устройство DirectX? Чушь это все. COM объект реализуется в исполняемом модуле PE стандарта Windows, при регистрации требует реестр. Ну просто пипец как не связан с Windows. Ну просто ничего общего.
Однако она не работает НИ ГДЕ кроме как на Windows машинах. Переносимый код пишется на CF или Mono.
Это приложения, которые имеют строгую архитектуру, в их исполняемых модулях нет прямых ссылок на API функции (разве что kernel32), точно также как и QT. Если дом построили из железобетона, никто ведь не говорит, что дом построили из песка, цемента и арматуры, а говорят панельный дом.
В винде нет кучи языков. Языки существуют безотносительно платформы. В никсах также доступно много компиляторов. Для того же Delphi-Object Pascal существует компилятор Free Pascal под линукс. Аналогично на C# можно писать под Mono, CF или .NET . |
| Автор: djamshud 17.5.2010, 18:46 | ||||
| >WinAPI - это АПИ ОС. Оно максимально отражает сущности в ОС и обеспечивает управление ими. АПИ - это _интерфейс_. Это не потроха операционки, это ее интерфейс. Факт, что винда высовывает наружу кучу своего внутреннего дерьма. А еще больше прячет, что несомненно к лучшему. >Потому что в ядре ОС есть объект "файл". CreateFile создает этот объект. При этом при создании этого объекта надо обеспечить возможность указать все необходимые параметры создаваемого объекта. open тоже создает объект файл и возвращает его идентификатор (HANDLE). Функция позволяет (а не заставляет) задать любые необходимые параметры. >Почему в никсах open есть перегрузки, а у CreateFile нет? Потому что никсы заточены под на Си, и там можно юзать манглинг Си. А WinApi рассчитано на любые языки, по этому там не может быть использован манглинг, а значит там не может быть перегрузок. open - это скорее исключение. Причем никакого манглинга не используется судя по ассемблерному листингу (мне ж самому интересно стало). В целом же перегрузок функций вообще нет. Юзать эти функции принципиально может любой язык, так или иначе бинарно совместимый с ядром ОС, то есть как и в винде. Добавлено через 36 секунд >как вызвать "юниксовый системный вызов open" не из Си, а например из асма? call open Добавлено через 4 минуты и 44 секунды
GCC это сделал так. Руками очевидно можно также или чуть по-другому, но я понимаю асм только в ридонли, поэтому сам не напишу. |
| Автор: GoldFinch 17.5.2010, 19:03 | ||||||||
Alexeis, оболочка windows (шелл) - это не более чем обычная программа. Это не ОС. Это оболочка ОС. Ее можно заменить на что-то другое, без COM.
даже не смешно. 99.95% программ - это PE. 88% работают с реестром. COM - это не интерфейс ОС. Не каждый COM объект это часть ОС.
зато есть в mscoree и т.п. Alexeis, у ОС есть ядро. Оно нативное. Оно не использует COM. WinAPI - это интерфейс ядра ОС. А не интерфейс системных компонентов COM и библиотек .NET. В конце концов это весьма странный спор. Я много раз дебажил программы, попробуйте и вы. Возьмите отладчик и подебажте системные компоненты COM или .NET. Вы сразу увидите как именно они связаны с ОС.
VB, который чистый COM, под никсы есть? Я что-то с трудом представляю себе строчку
|
| Автор: GoldFinch 17.5.2010, 19:22 | ||
djamshud, а зачем ОС что-то прятать? все что *нужно* прятать, в винде "спрятано" в native API, все что может быть доступно программисту - то доступно программисту.
мне это говорит только о том, что где-то есть библиотека (.lib) которая и вызывает непосредственно системную open эта .lib (наверное libc.lib) линкуется с твоим .obj и получается программа которая вызывает open но это все средства Си представь что я хочу написать для никсов компилятор нативного кода, чтоб сразу elf генерил (или что там исполняемое в никсах) что мне надо сгенерить чтобы вызвать эту самую open? как оно все выглядит изнутри? прочем я сомневаюсь что ты можешь ответить на этот вопрос, т.к. наверное не знаешь как исполняемые модули в твоих любимых никсах выглядят изнутри =) |
| Автор: GoldFinch 17.5.2010, 19:37 | ||
посмотрел на ELF. вопрос снят. |
| Автор: Alexeis 17.5.2010, 20:08 | ||||||||
Visual Basic это компилятор бейсика под Windows. Язык это Basic или его разновидность. Для линукса есть REALbasic.
Читаем вики
Где тут хоть слово про ядро ОС? Речь об интерфейсах программирования операционной системы. Интерфейсы могут описываться как функциями так и объектами при условии что определен объектный стандарт. Функции Shell, DirectX, BITS это также интерфейсы программирования операционной системы Windows. И чем дальше тем больше.
Ну так и что с того? Разве непосредственный вызов внутренних функций документирован как API? Есть документация на программный интерфейс DirectX Там английским по черному написано про COM объекты. Тоже самое и взаимодействие с оболочкой, тоже самое и с .NET . Программный интерфейс такой какой он определен, а не такой как реализован. Любая недокументированная функция может впоследствии менять свое поведение или полностью исчезать. Для программиста это должен быть черный ящик. Такие функции как CreateFile это интерфейс основанный на функциях, IDirect3D9::CreateDevice прикладной интерфейс основанный на COM объектах, даже если метод CreateDevice вызывает внутри только функции ядра. Я об это не знаю, более того я об этом не должен знать, потому что автор оставляет за собой право менять реализацию как он хочет. |
| Автор: GoldFinch 17.5.2010, 20:28 |
| Alexeis, если я разработаю свою технологию компонентов FinchComponentObjectModel ™, и сделаю компонент FSystem который позволит работать с системой, то вы назовете это winAPI? А если я разработаю свою платформу FinchNET, в ней будет встроенная библиотека System, то вы тоже назовете это winAPI? > черный ящик > Я об это не знаю, более того я об этом не должен знать а я знаю. знаю что внутри этого черного ящика, и знаю почему именно так, а не иначе. |
| Автор: djamshud 17.5.2010, 20:35 |
| GoldFinch, не надо прятать. Надо давать хороший интерфейс. Да, open не совсем "системный" вызов, это небольшой враппер над реальным системным вызовом sys_open, К которому можно обратиться либо по имени, либо через его код. Но интерфейс sys_open аналогичен простому open-у (и других sys_ - в подавляющем большинстве случаев). Благодарю, что дал повод глубже просветиться в этом вопросе. Но это не отменяет того факта, что интерфейс винапи на примере того же CreateFile просто отвратителен. Про работу с окнами (они ведь до сих пор в ведре наверное?) я промолчу. Про непосредственно структуру ELF не знаю, оно мне пока как бы и не надо. |
| Автор: GoldFinch 17.5.2010, 20:35 | ||
мне одному кажется что это неправильный перевод "API" применительно к windows API? API - это интерфейс программирования (программного управления) приложений, но в случае windows API - в роли приложения выступает windows, и windows API надо понимать как "интерфейс программного управления windows". Добавлено через 6 минут и 41 секунду djamshud, а что с CreateFile не так? То что там флаги сгруппированы по нескольким аргументам? Это удлиняет сигнатуру, но не более того, кому-то такая группировка будет даже удобней. То что там опции безопасности есть? У всех хендлов объектов ядра есть опции безопасности, в ряде случае их необходимо заполнять, но обычно их заполнять не надо, то что тут плохого? Обычный опциональный параметр. То что там хендл файла-шаблона есть? Опять же необязательная вещь. Или ты предлагаешь сделать не 1 функцию, а 4 с разными комбинациями опциональных параметров? Сомнительное решение, учитывая что там нельзя использовать перегрузки. |
| Автор: djamshud 17.5.2010, 21:17 |
| GoldFinch, в нем не так безумное число параметров и длинное сложное имя. Причем как известно по обоим пунктам это еще цветочки в мире winAPI. Вырвиглазные имена типов, опять же. У меня нет никаких конкретных предложений по улучшению, потому что в деле я это видел последний раз лет пять назад. И оно мне не нравилось. И оно никому не нравилось. АПИ ОС не обязано быть сложным. Как пример простого АПИ я не просто так привел лаконичное юниксовое, я его время от времени использую. И я использовал винАПИ. Исходя из этого (а не потому, что юникс фарева!!!11 (хотя это так:) )) я и заявляю, что винАПИ - это просто чудовищный п-ц и издевательство над программистом. Добавлено через 1 минуту и 59 секунд Плюс к разговору о разбиении функций на несколько. В винАПИ и сплошь и рядом наблюдаются функции с разными префиксами или постфиксами. |
| Автор: GoldFinch 17.5.2010, 21:39 | ||||
короткое популярное имя в глобальной области видимости - это зло длинные развернутые имена (и типов тоже) позволяют исключить пересечения имен и лучше документируют код
тем кто это юзает - тем нравится |
| Автор: djamshud 17.5.2010, 21:53 |
| >короткое популярное имя в глобальной области видимости - это зло Как показывает практика, короткие емкие имена и такая же система типов - это просто сказка. Возрастает как скорость написания, так и понимание кода, который не прячется за забором БесконечноДлинныхФункций(И,НЕВМЕНЯЕМЫХ,ПАРАМЕТРОВ). >>И оно никому не нравилось. >тем кто это юзает - тем нравится В данном случае я приводил мнения тех, кто юзал (а может и сейчас юзают). Впрочем пруфов IRL не будет. |
| Автор: Alexeis 17.5.2010, 21:53 | ||||
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, которые призваны заменить старые. Весь набор избыточный. |
| Автор: MAKCim 17.5.2010, 23:17 | ||||
| каков размер winapi? имеется в виду количество системных функций и их отображений в userspace удовлетворяет ли он принципу Оккама? касаемо параметров, большое их количество свидетельствует о недостаточной продуманности интерфейса пример продуманности...взять тот же ioctl основан на уровнях доступа и концепции файлов по сути все, что надо для работы с любым объектом, обладающим файловой семантикой это сам объект (его отображение в userspace в виде дескриптора), команда и параметр ни убавить, ни прибавить рассмотрим open/creat vs. CreateFile зачем пихать все в CreateFile, если, скажем фактически для создания важны только режим доступа и идентификатор? все остальное - ioctl Добавлено через 3 минуты и 45 секунд
уровни доступа слышал про setsockopt работает со всеми доменами и протоколами для любых типов сокетов 5 исчерпывающих параметров Добавлено через 9 минут и 26 секунд
есть еще С++, java, perl, python, Go, haskell, lisp и много много других ;) а то, что С используется чаще всего, так это потому, что в умелых руках он превращается в мощнейшее орудие разработки стОит ли говорить, что подавляющее большинство либ написаны на С и этим богатством можно воспользоваться напрямую без всяких кривых биндингов |
| Автор: Alexeis 17.5.2010, 23:34 | ||
В общем слив засчитывается. Функция должна иметь столько параметров сколько будет реально использовано при 90% ее вызовов. Остальное должно настраиваться опционально. Некоторые функции этим страдают. Нельзя сказать что многие. |
| Автор: Rohoss 17.5.2010, 23:39 | ||
А лучше всего, когда передаёшь параметром специальный объект... |
| Автор: Alexeis 18.5.2010, 00:11 | ||
Так оно всегда так и происходит. Дескрипторы которые создают и повсеместно используют фактически указатели на системные объекты. Или речь о другом специальном объекте? |
| Автор: GoldFinch 18.5.2010, 00:25 | ||||||
Затем что при создании объекта ядра, если указывать его атрибуты безопасности, то их надо надо указывать сразу. (иначе может так случиться что будет поздно) А лишний NULL - никому не мешает.
ни один из них не работает с АПИ ОС напрямую. а в винде даже VB, который компилится в байткод, может вызывать winapi (экспорты любых dll)
Потому и написаны на Си, что больше не на чем. В винде достаточно значительная часть системного кода пишется не на Си. Собственно зачем писать на неудобном Си, если есть более удобная высокоуровневая дельфи, и более удобный низкоуровневый масм? |
| Автор: bems 18.5.2010, 02:41 | ||
Посмотрел. Увидел пару fork-exec. Испытал неуловимо гнетущее впечатление. Содрогнулся. (с) |
| Автор: W4FhLF 18.5.2010, 03:31 | ||
Да что там CreateFile. Вот когда дело касается реестра или окон... Разве не прелесть:
На самом деле WinAPI простые, но явно избыточные. Слишком много сущностей, которые невозможно держать в голове. Это заставляет часто останавливаться, думать, нырять в справку. |
| Автор: Wisdom 18.5.2010, 05:28 |
| Шедевр. |
| Автор: A5uKa 18.5.2010, 07:55 |
| земля. |
| Автор: MAKCim 18.5.2010, 08:52 | ||||||||||||
я говорю о более глобальных вещах естественно, если чего-то требует архитектура, то никуда от этого не денешься другое дело, что 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 определенно менее гибок засчет того, что в принципе привязывает процесс к программе а между тем - это _разные_ сущности программа (образ) - это лишь ресурс, как и прочие таблицы и объекты |
| Автор: Alexeis 18.5.2010, 09:07 | ||
Это еще как? Переход по адресу разве это не напрямую? Или ты имеешь ввиду, что API это прослойка к нативной ntdll.dll? |
| Автор: GoldFinch 18.5.2010, 09:22 |
| Alexeis, MAKCim видимо имеет ввиду механизм статического импорта для .obj : для каждой длл используются библиотеки импорта с переходниками на функции API. При этом имена переходников не совпадают с именами функций winAPI (добавляется манглинг). |
| Автор: MAKCim 18.5.2010, 10:06 | ||
а вот так компилятор формирует код, использующий либы, а не дергает напрямую сисколы а первичное отображение api есть сисколы |
| Автор: Alexeis 18.5.2010, 11:38 | ||||||||
Какой компилятор делает так? Вот смотрю пример вызова CreateEvent
Адрес хранящийся в памяти по адресу 007a3548 - 0E 18 28 76 Переход к kernel32.CreateEventW
Где тут использование дополнительной либы? |
| Автор: MAKCim 18.5.2010, 13:21 | ||
kernel32 ;) вот ежели б компилятор генерил код, напрямую дергающий sysenter/syscall, int и пр. механизмы межуровневых переходов процессора тогда да |
| Автор: Alexeis 18.5.2010, 13:49 | ||
Причем тут язык С тогда? По другому к винде системе не обратишься из юзермода . Это не библиотека языка С, а библиотека ядра ОС. Что с того, что часть ее кода выполняется в юзермоде? В чем принципиальная разница будут ли эти операции производиться в твоей программе или же в системой библиотеке? На самом деле вызов функции из kernel32 это лишь начало целой цепочки вызовов. Обычно стек внутренних системных вызовов разрастается до 6ти и более функий. |
| Автор: MAKCim 18.5.2010, 13:58 | ||||||
| Alexeis, GoldFinch выдвинул тезис
это касаемо C++, Java, Python и т. д.
я ответил
компилятор преобразует С код в код, юзающий libc равно как Java преобразует байт-код в нативный код, который либо юзает api системы через сисколы напрямую (тогда тезис априорно не верен) либо через ту же libc, как и С и в этом случае тезис не верен ;) Alexeis, ты как бы теряешься в сути разговора |
| Автор: Alexeis 18.5.2010, 15:04 | ||
Да где же в приведенном мной куске код использования libc ? Я вижу прямой вызов WinAPI функции. Почему ты определяешь что системные вызовы это только вызовы в режиме ядра? Операционная система не предоставляет другого документированного способа для доступа к ее внутренним ресурсам. Я не опровергаю, того что другие языки также могут также компилировать свой код в вызовы WinAPI. Я не вижу где в приведенном коде прослойка рантайма С. Некоторые функции библиотеки С действительно внутри используют вызовы WinAPI, но программист может, их не использовать совсем. Например отключить полностью CRT. |
| Автор: MAKCim 18.5.2010, 15:18 | ||
режим ядра - это работа на нулевом кольце привилегий где я об этом говорил? api системы - это не врапперы в libc или kernel32.dll это то, что непосредственно предоставляет ядро ОС в той же libc тысячи функций, но не все они - api |
| Автор: GoldFinch 18.5.2010, 15:46 |
| MAKCim, часть функций winapi работает только в юзермоде, им не надо syscall\sysenter и т.п. ядро работает как в ring3, так и в ring0 |
| Автор: MAKCim 18.5.2010, 15:48 | ||
| я понял у нас разные представления об api
что из ядра работает в ring3? |
| Автор: GoldFinch 18.5.2010, 16:13 | ||
| MAKCim, у нас разные представления об ядре. ring3 и ring0 - это состояния потока. поток постоянно переключается из ring0 в ring3 и наоборот. ядро не "работает в кернелмоде". часть кода ядра выполняется потоками в ring0. причем один и тот же код может работать как в ring3, так и в ring0 Вот что пишет MS в справке к WRK
Например функция RtlRemoteCall - работает в юзермоде, и это часть RTL ядра. |
| Автор: Alexeis 18.5.2010, 16:35 | ||
Да я думаю что половина кода, если не больше работает в юзермоде. Но WinAPI это не только само ядро, но и куча вспомогательных сервисов и библиотек, которые, сами не переходят в режим ядра. Думаю что в линуксе некоторые из этих задач выполняют сторонние библиотеки. |
| Автор: MAKCim 18.5.2010, 18:03 |
| блин, ребята я всегда понимал и понимаю под ядром непосредственно то, что отлично от любой внешней программы для linux это все, что в /usr/src/linux так вот, эта хрень под названием ядро работает только в ring0 а вот уже _пользовательские процессы_ постоянно переключаются ring3 <-> ring0 |
| Автор: bems 18.5.2010, 21:55 | ||
О, кстати как раз вот нужно. Не подскажешь системный вызов, соответствующий GetCurrentProcessId? |
| Автор: MAKCim 18.5.2010, 22:04 |
| bems, getpid() |
| Автор: bems 18.5.2010, 22:06 |
| MAKCim, я вобще-то про винду говорил |
| Автор: GoldFinch 18.5.2010, 22:19 | ||
интереснее выглядит функция ядра GetCurrentProcess (и GetCurrentThread) хотя с Id тоже ничего |
| Автор: bems 18.5.2010, 22:22 | ||
Ну возвращают они константы, ничего особенно интересного не вижу. Так где тут системные вызовы? (за 5 минут мы 4 штуки насчитали где их нет) Добавлено через 45 секунд GoldFinch, изивиняюсь. вопрос был к MAKCim |
| Автор: MAKCim 18.5.2010, 22:28 | ||
я должен наизусть все номера знать? ;) |
| Автор: GoldFinch 18.5.2010, 22:30 |
| bems, тех которые работают в юзермоде - полно. Те же GetModuleHandle и прочие, работающие с TEB и PEB. Добавлено через 2 минуты и 35 секунд MAKCim, а как отличать функции ядра от не-функций ядра? лазать в сорцы ядра, и смотреть, должна функция работать в ring0 или нет? |
| Автор: bems 18.5.2010, 22:33 | ||||
Нет. Признать что они отсутствуют. А значит это
в винде неверно Добавлено через 33 секунды GoldFinch, му говорим об одном и том же. |
| Автор: MAKCim 18.5.2010, 22:40 |
| GoldFinch, ты что, издеваешься? функция ядра по определению - часть исходного кода ядра или драйвера, работающего в ядре в ring0 все остальное - userspace функции они работают в ring3 и при необходимости обращаются к ядру через механизм syscall'ов т. е. к примеру, fork() - это userspace функция, которая через int 80h, syscall/syseneter передает управление функции ядра sys_fork()/sys_clone() какая-то демогогия пустая... |
| Автор: bems 18.5.2010, 22:43 |
| MAKCim, то есть функция-геттер для данных ядра, отображенных на юзерспейс, не является функцией ядра? |
| Автор: MAKCim 18.5.2010, 22:44 |
| bems, ну PEB/TEB берутся не из потолка, правильно значит косвенно, тот же CreateThread/CreateProcess и соответствующие им syscall'ы формируют PEB/TEB либо сама реализация функций предусматривает, скажем вызов недокументируемой функции получения идентификатора и его кэширования для ускорения последующего доступа |
| Автор: bems 18.5.2010, 22:47 | ||
Она просто достаёт нужное значение из памяти. Поддержка этой структуры (чтобы было что доставать)- работа ядра (в основном). Без кеширования. Так это функция ядра или нет? Добавлено через 1 минуту и 50 секунд MAKCim, и в догонку вопрос про GetCurrentProcess. Она возвращает константу. Но она win32 api. Ты куда её отнесеш? |
| Автор: MAKCim 18.5.2010, 22:50 | ||||
нет свою "ядерность" она утрачивает но это скорее вопрос терминологии и кто как считает логичным Добавлено через 1 минуту и 45 секунд
нет я бы еще мог согласиться, если бы она была аналогом vsyscall функций в linux |
| Автор: bems 18.5.2010, 22:54 | ||
Вот. А значит это тоже неверно
и компилятор все-таки напрямую вызывает апи. |
| Автор: gcc 18.5.2010, 23:08 |
| perl, python, etc экспортируют названия фукнций ядра с sys/syscall.h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/syscall.h?rev=1.211.2.6.2.1;content-type=text%2Fx-cvsweb-markup |
| Автор: bems 18.5.2010, 23:11 | ||
это значит что ядро написано на perl и python? |
| Автор: Alexeis 18.5.2010, 23:24 | ||
MAKCim, уже прокомментировал, что под апи он понимал только вызовы ядра, т.е. юзермодную прослойку winapi воспринимал не как часть апи, а как дополнительную либу. Т.е. спор был о разных понятиях названных одним термином. |
| Автор: bems 18.5.2010, 23:38 | ||
Не имеет значения что он имел в виду. Потому что приведенные мной примеры объективно принадлежат множеству винапи. |
| Автор: Alexeis 18.5.2010, 23:42 | ||
А CreateEvent объективно не относиться к WinAPI? Видишь как в линуксе понятия об api ОС несколько отличаются. |
| Автор: bems 18.5.2010, 23:49 | ||||
Если есть хоть одна винапи, без соответствующего ядерного вызова, это значит что нельзя считать что винапи это набор обёрток над ядерными вызовами. А то что ты говоришь мне напоминает анекдот
|
| Автор: Alexeis 19.5.2010, 05:21 |
| bems, ты не прав. Мы с MAKCim уже определились что вызов функции CreateEvent также производиться в режиме юзермода. В режиме ядра реально вызывается та функция, которую изнутри вызовет CreateEvent . |
| Автор: MAKCim 19.5.2010, 09:08 |
| по определению api ОС - это что-то, предоставляемое ОС ОС определяется ядром если какая-то функция работает в userspace, то это лишь вспомогательная функция, которая прямо или косвенно зависит от ядра и вне его не имеет смысла Добавлено через 4 минуты и 9 секунд bems, мы что-то ушли в сторону от вопроса используют ли java, python и т. д. api напрямую ;) еще как используют если не согласен, объясни, что в твоем понимании напрямую |
| Автор: bems 19.5.2010, 16:03 | ||||||
|
| Автор: gcc 19.5.2010, 17:39 | ||||
нашел
syscall входит наверное в #include <stdio.h> sys/syscall.h в этом файлике перечисленные все функции ядра и этот файл автоматически создается (в нем написано) вот я нашел код где проверяются какие функции какие есть в каждой операционной системе
или вопрос в другом? |
