[Prisoner]

Application Programming Interface (API) - интерфейс программирования приложения (склонять как угодно внутренней грамотности).  Низкоуровневые функции которые собственно и вызываются когда надо скажем создать окно, показать его, обновить, передвинуть и так далее. Просто ЯВУ скрывают их от тебя, облегчая написание программ... к слову будет упомянуто, что апишные функции быстрее, а VCL - код (в Delphi) раздут хотя и позволяет выполнять всю туже работу, что выполнят апишные функции, но делает это медленне и кушает при этом больше. В общем есть критичное по быстроте место - юзай их.

[s]Исправлено: Prisoner, 0:50 11-10-2003[/s]

[[mzd]]

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

[s]Исправлено: [mzd], 18:36 14-10-2003[/s]

[Guest]

Хочу добавить, что все функции API
вызываются из динамических
библиотек Windows таких как
USER32.DLL KERNEL и тому подобных,
которые описаны в Windows.h.

[vasketsov]

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 друг другом, даже при условии раннего связывания).

Тема неисчерпаема, так что по факту появления вопросов - милости просим.

[Prisoner]

vasketsov
Учту, но замечу, что большинство случаев (растекаюсь абстрактной мыслью по древу) пусть и не универсум таковых, но все же большенство. Ведь всегда есть исключения, не так ли?