Windows API , неофициально WinAPI , является основополагающим интерфейсом прикладного программирования (API) , который позволяет компьютерной программе получать доступ к функциям операционной системы Microsoft Windows , в которой запущена программа. Программы получают доступ к функциональности API через технологию динамически подключаемых библиотек (DLL).
Каждая основная версия Windows API имеет свое собственное имя, которое определяет аспект совместимости этой версии. Например, Win32 — это основная версия Windows API, которая работает на 32-разрядных системах. Название Windows API в совокупности относится ко всем версиям этой возможности Windows.
Microsoft предоставляет поддержку разработчикам посредством комплекта средств разработки программного обеспечения Microsoft Windows SDK , который включает документацию и инструменты для создания программного обеспечения на основе Windows API.
В этом разделе перечислены важные службы, предоставляемые Windows API. [1]
Базовые службы включают такие функции, как файловая система , устройства , процессы , потоки и обработка ошибок . Эти функции находятся вядро.exe,krnl286.exeилиkrnl386.exeфайлы на 16-битной Windows, иkernel32.dll и KernelBase.dllна 32 и 64 бит Windows. Эти файлы находятся в папке\Windows\System32во всех версиях Windows. [2]
Расширенные службы включают функции за пределами ядра, такие как реестр Windows , выключение/перезапуск системы (или прерывание), запуск/остановка/создание службы Windows , управление учетными записями пользователей. Эти функции находятся вadvapi32.dllиadvapires32.dllна 32-битной Windows.
Компонент интерфейса графических устройств (GDI) обеспечивает функции вывода графического контента на мониторы , принтеры и другие устройства вывода . Он находится вgdi.exeна 16-битной Windows иgdi32.dllна 32-битной Windows в пользовательском режиме. Поддержка GDI в режиме ядра обеспечивается, win32k.sysчто напрямую взаимодействует с графическим драйвером. [3] [4]
Компонент пользовательского интерфейса предоставляет функции для создания и управления экранными окнами и большинством основных элементов управления, таких как кнопки и полосы прокрутки , прием ввода с мыши и клавиатуры и другие функции, связанные с графическим пользовательским интерфейсом (GUI) Windows. Этот функциональный блок находится впользователь.exeна 16-битной Windows иuser32.dllна 32-битной Windows. Начиная с версий Windows XP , основные элементы управления находятся вcomctl32.dll, вместе с общими элементами управления (Библиотека общих элементов управления). [5]
Библиотека общих диалоговых окон предоставляет стандартные диалоговые окна для открытия и сохранения файлов, выбора цвета и шрифта и т. д. Библиотека находится в файле с именемcommdlg.dllна 16-битной Windows иcomdlg32.dllна 32-битной Windows. Он сгруппирован в категории Пользовательский интерфейс API. [6]
Common Control Library обеспечивает доступ к расширенным элементам управления пользовательского интерфейса, включая такие элементы, как строки состояния , индикаторы выполнения , панели инструментов и вкладки . Библиотека находится в файле DLL с именемcommctrl.dllна 16-битной Windows иcomctl32.dllна 32-битной Windows. Он сгруппирован в категории Пользовательский интерфейс API. [7]
Компонент Windows Shell обеспечивает доступ к оболочке операционной системы . Компонент находится вshell.dllна 16-битной Windows иshell32.dllна 32-битной Windows. Функции Shell Lightweight Utility находятся вshlwapi.dll. Он сгруппирован в категории «Пользовательский интерфейс» API. [8] [9]
Сетевые службы предоставляют доступ к различным сетевым возможностям операционной системы. Его подкомпоненты включают NetBIOS , Winsock , NetDDE , удаленный вызов процедур (RPC) и многое другое. Этот компонент находится вnetapi32.dllна 32-битной Windows. [10]
Веб-браузер Internet Explorer (IE) предоставляет API и, таким образом, может считаться частью Windows API. IE был включен в операционную систему с Windows 95 OSR2 и предоставлял веб-сервисы приложениям с Windows 98. [ 11]
Windows API — это API на основе языка C. [12] Функции и структуры данных доступны через синтаксис C путем включения windows.h , но API может использоваться через любой язык программирования, который может взаимодействовать со структурами данных API и соглашениями о вызовах для вызовов функций и обратных вызовов .
Следует отметить, что реализация функций API была разработана на нескольких языках, отличных от C. [a]
Несмотря на то, что C не является языком объектно-ориентированного программирования (ООП), Windows API в некоторой степени объектно-ориентирован из-за использования дескрипторов. Различные другие технологии от Microsoft и других делают этот объектно-ориентированный аспект более очевидным, используя язык ООП, такой как C++ — см. Microsoft Foundation Class Library (MFC), Visual Component Library (VCL), GDI+ . Следует отметить, что Windows 8 предоставляет Windows API и WinRT API, который реализован на C++ [13] и является объектно-ориентированным по своей сути. [13]
Windows.pas — это модуль Delphi , который раскрывает возможности Windows API — эквивалент windows.h на Pascal . [14]
Многие технологии Microsoft используют Windows API, как и большинство программного обеспечения, работающего в Windows. В качестве промежуточного ПО между Windows API и приложением следующие технологии предоставляют некоторый доступ к Windows API. Некоторые технологии описываются как обёртки Windows API, но это спорно, поскольку они не предоставляют или не раскрывают все возможности Windows API.
Хотя почти все программы Windows используют Windows API, в линейке операционных систем Windows NT программы, которые запускаются на ранних этапах процесса загрузки Windows, вместо этого используют Native API . [15]
Windows API всегда открывал большую часть базовой структуры систем Windows программистам. Это давало им преимущество в виде большей гибкости и власти над их приложениями, но также создавало большую ответственность за то, как приложения обрабатывают различные низкоуровневые, иногда утомительные операции, связанные с графическим пользовательским интерфейсом .
Например, начинающий программист на языке C часто пишет простое "hello world" в качестве своего первого задания. Рабочая часть программы — это всего лишь одна строка printf в основной подпрограмме. Накладные расходы на привязку к стандартной библиотеке ввода-вывода также составляют всего одну строку:
#include <stdio.h> int main ( void ) { printf ( "Привет, мир! \n " ); } Чарльз Петцольд , написавший несколько книг о программировании для Windows API, сказал: «Оригинальная программа hello world в Windows 1.0 SDK была немного скандальной. HELLO.C была длиной около 150 строк, а скрипт ресурсов HELLO.RC имел еще около 20 строк. (...) Опытные программисты часто сжимались от ужаса или смеха, сталкиваясь с программой Windows hello-world». [16] Петцольд объясняет, что, хотя это был первый пример программ Windows, с которым познакомились разработчики, он был довольно «замысловатым» и более сложным, чем требовалось. Устав от людей, высмеивающих длину примера, он в конечном итоге сократил его до простого вызова MessageBox. [17]
На протяжении многих лет в системы Windows вносились различные изменения и дополнения, и Windows API менялся и рос, отражая это. [18] Windows API для Windows 1.0 поддерживал менее 450 вызовов функций , тогда как современные версии Windows API поддерживают тысячи. Однако в целом интерфейс оставался довольно последовательным, и старое приложение Windows 1.0 по-прежнему будет выглядеть знакомым для программиста, привыкшего к современному Windows API. [19]
Microsoft приложила усилия для поддержания обратной совместимости . Чтобы добиться этого, при разработке новых версий Windows Microsoft иногда внедряла обходные пути [20], чтобы обеспечить совместимость со сторонним программным обеспечением, которое использовало предыдущую версию недокументированным или даже нецелесообразным образом. Рэймонд Чен , разработчик Microsoft, работающий над Windows API, сказал: «Я мог бы, вероятно, месяцами писать только о плохих вещах, которые делают приложения, и о том, что нам пришлось сделать, чтобы заставить их снова работать (часто вопреки им самим). Вот почему я особенно злюсь, когда люди обвиняют Microsoft в злонамеренном взломе приложений во время обновлений ОС. Если какое-либо приложение не запускалось в Windows 95, я воспринимал это как личную неудачу». [21]
Одним из самых больших изменений в Windows API был переход с Win16 (поставляемого в Windows 3.1 и более ранних версиях) на Win32 (Windows NT и Windows 95 и более поздние версии). Хотя Win32 изначально был представлен в Windows NT 3.1 , а Win32s позволял использовать подмножество Win32 до Windows 95, только в Windows 95 началось широкомасштабное портирование приложений на Win32. Чтобы облегчить переход, в Windows 95 для разработчиков вне и внутри Microsoft использовалась сложная схема API- преобразователей , которая позволяла 32-битному коду вызывать 16-битный код (для большинства API Win16) и наоборот. Плоские преобразователи позволяли 32-битному коду вызывать 16-битные библиотеки, и эта схема широко использовалась внутри библиотек Windows 95, чтобы избежать портирования всей ОС на Win32 за один пакет. В Windows NT ОС была чисто 32-битной, за исключением частей для совместимости с 16-битными приложениями, и только общие преобразователи были доступны для преобразования из Win16 в Win32, как и для Windows 95. Platform SDK поставлялся с компилятором, который мог производить код, необходимый для этих преобразователей. Версии 64-битной Windows также могут запускать 32-битные приложения через WoW64 . Папка SysWOW64, расположенная в папке Windows на диске ОС, содержит несколько инструментов для поддержки 32-битных приложений. [22]
Каждая версия Microsoft Windows содержит версию Windows API, и почти каждая новая версия Microsoft Windows вносит дополнения и изменения в Windows API. [23]
Название Windows API относится по сути к одной и той же возможности в каждой версии Windows, но есть и другое название этой возможности, основанное на основных архитектурных аспектах версии Windows, которая ее содержит. Когда была только одна версия, она называлась просто Windows API. Затем, когда было сделано первое крупное обновление, Microsoft дала ей название Win32, а первой версии — Win16. Термин Windows API относится к обеим версиям и всем впоследствии разработанным основным версиям. [24]
Проект Wine обеспечивает уровень совместимости Win32 API для Unix-подобных платформ между API ядра Linux и программами, написанными для API Windows. ReactOS идет на шаг дальше и стремится реализовать полную операционную систему Windows, тесно сотрудничая с проектом Wine для содействия повторному использованию кода и совместимости. DosWin32 и HX DOS Extender — другие проекты, которые эмулируют API Windows, позволяя выполнять простые программы Windows из командной строки DOS . Odin — проект по эмуляции Win32 на OS/2 , заменяющий исходную эмуляцию Win-OS/2, которая была основана на коде Microsoft. Другие второстепенные реализации включают библиотеки MEWEL и Zinc , которые были предназначены для реализации подмножества API Win16 на DOS (см. Список платформенно-независимых библиотек GUI ).
Windows Interface Source Environment (WISE) — это программа лицензирования от Microsoft, которая позволяла разработчикам перекомпилировать и запускать приложения на базе Windows на платформах Unix и Macintosh . WISE SDK были основаны на эмуляторе Windows API, который мог работать на этих платформах. [28]
Усилия по стандартизации включали в себя Открытый интерфейс Windows (PWI) от Sun для Win16 (см. также: Двоичный интерфейс приложений Windows ( Wabi ) от Sun), Интерфейс программирования приложений для Windows (APIW) от Willows Software для Win16 и Win32 (см. также: Willows TWIN ) и ECMA-234 , который пытался стандартизировать API Windows в обязательном порядке.
Для разработки программного обеспечения, использующего Windows API, компилятор должен иметь возможность использовать специфичные для Microsoft DLL, перечисленные выше (COM-объекты находятся вне Win32 и предполагают определенную структуру vtable). Компилятор должен либо обрабатывать файлы заголовков, которые раскрывают имена внутренних функций API, либо предоставлять такие файлы.
Для языка C++ Zortech (позже Symantec , затем Digital Mars ), Watcom и Borland выпустили известные коммерческие компиляторы, которые часто использовались с Win16, Win32s и Win32. Некоторые из них поставляли расширители памяти , позволяя программам Win32 работать на Win16 с распространяемой DLL Win32s от Microsoft. Компилятор Zortech был, вероятно, одним из первых стабильных и пригодных для использования компиляторов C++ для программирования Windows, до того, как у Microsoft появился компилятор C++.
Для определенных классов приложений система компилятора также должна уметь обрабатывать файлы языка описания интерфейса (IDL). В совокупности эти предварительные требования (компиляторы, инструменты, библиотеки и заголовки) известны как Microsoft Platform SDK . Какое-то время Microsoft Visual Studio и интегрированная система разработки Borland были единственными интегрированными средами разработки (IDE), которые могли это обеспечить (хотя SDK можно бесплатно загрузить отдельно от всего набора IDE, из Microsoft Windows SDK для Windows 7 и .NET Framework 4).
По состоянию на 2016 год проекты [update]MinGW и Cygwin также предоставляют такую среду на основе GNU Compiler Collection (GCC), используя автономный набор заголовочных файлов, чтобы упростить компоновку с специфичными для Win32 DLL. LCC -Win32 — это компилятор C, поддерживаемый Jacob Navia, бесплатное программное обеспечение для некоммерческого использования. Pelles C — это бесплатное программное обеспечение для компиляции C, поддерживаемое Pelle Orinius. Free Pascal — это бесплатный программный компилятор Object Pascal , поддерживающий Windows API. Пакет MASM32 — это зрелый проект, обеспечивающий поддержку Windows API в Microsoft Macro Assembler (MASM) с помощью специально созданных или преобразованных заголовков и библиотек из Platform SDK. Плоский ассемблер FASM позволяет собирать программы для Windows без использования внешнего компоновщика, даже при работе в Linux.
Поддержка компилятора Windows, специфичная для Windows, также необходима для структурированной обработки исключений (SEH). Эта система служит двум целям: она предоставляет основу, на которой может быть реализована обработка исключений , специфичная для языка , и именно так ядро уведомляет приложения об исключительных ситуациях, таких как разыменование недопустимого указателя или переполнение стека. Компиляторы Microsoft/Borland C++ имели возможность использовать эту систему, как только она была представлена в Windows 95 и NT, однако фактическая реализация была недокументирована и должна была быть подвергнута обратному проектированию для проекта Wine и свободных компиляторов. SEH основана на помещении кадров обработчиков исключений в стек, а затем добавлении их в связанный список, хранящийся в локальном хранилище потока (первое поле блока среды потока). Когда возникает исключение, ядро и базовые библиотеки раскручивают стек, запуская обработчики и фильтры по мере их возникновения. В конечном итоге каждое исключение, не обработанное приложением, будет обработано обработчиком backstop по умолчанию, который выводит общее диалоговое окно сбоя Windows.