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 и много много других ;)
а то, что С используется чаще всего, так это потому, что в умелых руках он превращается в мощнейшее орудие разработки
стОит ли говорить, что подавляющее большинство либ написаны на С и этим богатством можно воспользоваться напрямую без всяких кривых биндингов