Prisoner
Цитата:
|
слову будет упомянуто, что апишные функции быстрее
|
Не всегда, зависит от реализации. wcslen реализуется в ntdll.dll одним образом, в msvcrt.dll - другим.
Цитата:
|
а VCL - код ... но делает это медленне и кушает при этом больше
|
Тоже не всегда. Виртуальная память, например, быстрее выделяется, потому что она выделяется из собственного (уже зарезервированного) пула.
Guest
Цитата:
|
все функции API вызываются из динамических библиотек
|
Неверно. Бывает API, которое сводится к набору сообщений и реализуется только лишь через SendMessage (сама по себе функция SendMessage не знает про этот API, потому относить ее к нему было бы неверно). Примеры - работа с Common Controls (в заголовочных файлах *.h макросы, имеющие вид функций, заменяются на SendMessage), в принципе, работа с панелями приложений на рабочем столе и областью нотификаторов на панели задач - также через SendMessage вся сделана, и если бы не единственная вошедшая в их API функция, они бы тоже были примером работы через SendMessage.
Еще как вариант - Native NT API реализуется через INT 2Eh либо SYSENTER/SYSEXIT (зависит от версии NT).
Бывает, что интерфейс программирования реализован в виде обращений к некоторому COM-объекту по опубликованному COM-интерфейсу. В итоге также, ни экспортируемых фукнций, ни сообщений, ни прерываний.
Это то,что с ходу вспомнилось.
Surround
API - расшифровка аббревиатуры верная - вовсе не обязательно низкоуровневый и вовсе не обязательно состоит из функций. Хотя бы потому, что в расшифровке аббревиатуры про это ни слова нет.
Общее API (настолько общее, что о нем никогда не говорят, ибо в этом нет смысла) делится обычно на части по некоторым критериям.
Например,
по области применимости (только системы на базе Windows NT, или только компьютеры в домене, или только в Active Directory, или Windows 2003 и выше, и т.д.),
по кругу решаемых задач (NetAPI, PSAPI, MAPI, TAPI, ..., это деление наиболее часто используется),
по "степени кроссплатформенности" (например, msvcrt.dll экспортирует функции, входящие в C-runtime, доступный не только для платформы Windows, тем не менее, имеющий право называться API не меньше, чем любое другое доступное для программирования, эти же функции частично экспортируют ntdll.dll и crtdll.dll и еще несколько библиотек),
по степени документированности (тут все ясно, создатель API упорно не желает его документировать, но уже 10 лет как его не меняет, пользоваться таким API или нет - решаем сами),
и так далее.
По поводу низкоуровневости. Все API (все перечисленное выше и то, о котором не упомянуто), работающее с файлами (в том числе, все сетевое API, даже WinSock и Берклевские сокеты, работа с драйверами,...), обязано использовать фукнции открытия файла, работы с ним и закрытия, и не только на платформе Windows. Потому практически всегда под одним API лежит другое (однако, не всегда более низкоуровневое, то есть, выражаясь более точно, допустимо рекурсивное использование различных API друг другом, даже при условии раннего связывания).
Тема неисчерпаема, так что по факту появления вопросов - милости просим.
