СИСТЕМА СРЕДЫ ВЫПОЛНЕНИЯ Российский патент 2016 года по МПК G06F9/06 G06F9/455 

ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ

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

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

КРАТКОЕ ИЗЛОЖЕНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

Это краткое изложение сущности изобретения приведено в качестве введения для описания подборки концепций в упрощенном виде, которые более подробно описаны ниже в разделе "Подробное описание". Подразумевается, что это краткое изложение сущности изобретения не служит ни для определения ключевых признаков или существенных признаков заявленного изобретения, ни для его использования для ограничения объема заявленного изобретения.

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

Некоторые варианты осуществления изобретения обеспечивают возможность моделирования одного или большего количества интерфейсов операционной системы объектно-ориентированным способом с использованием системы абстрактного типа. В некоторых вариантах осуществления изобретения расширенный язык определения интерфейсов (IDL) может включать в себя синтаксис для описания соотношений между одним или большим количеством интерфейсов. В некоторых вариантах осуществления изобретения бинарный контракт может быть сконфигурирован для выявления характера поведения, соответствующего системе абстрактного типа.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

На всех чертежах одинаковые номера использованы для ссылки на сходные признаки.

На Фиг. 1 проиллюстрировано рабочее окружение, в котором могут использоваться различные описанные здесь принципы, согласно одному или большему количеству вариантов осуществления изобретения.

На Фиг. 2 проиллюстрирована архитектура согласно одному или большему количеству вариантов осуществления изобретения.

На Фиг. 3 изображена схема последовательности операций, на которой описаны этапы способа согласно одному или большему количеству вариантов осуществления изобретения.

На Фиг. 4 проиллюстрирована схема соотношения согласно одному или большему количеству вариантов осуществления изобретения.

На Фиг. 5 проиллюстрирован пример системы, которая может использоваться для реализации одного или большего количества вариантов осуществления изобретения.

ПОДРОБНОЕ ОПИСАНИЕ

Общий обзор

Различные варианты осуществления изобретения обеспечивают возможность описания, независимо от языка программирования, одного или большего количества интерфейсов, ассоциированных с операционной системой. Система абстрактного типа в сочетании с языком определения интерфейсов (IDL) может быть сконфигурирована для описания и/или задания интерфейсов. В некоторых вариантах осуществления изобретения интерфейс может быть описан объектно-ориентированным способом. В альтернативном варианте или в дополнение к этому компилятор, соответствующий конкретному языку программирования, может быть сконфигурирован для соотнесения независимого от языка описания интерфейса (независимых от языка описаний интерфейсов) с надлежащими конструкциями на конкретном языке программирования. В альтернативном варианте или в дополнение к этому среда выполнения приложений на языке программирования может быть сконфигурирована для динамического (например, во время исполнения в среде выполнения) преобразования независимого от языка описания интерфейса (независимых от языка описаний интерфейсов) в надлежащие конструкции в конкретной среде выполнения. В некоторых вариантах осуществления изобретения приложение может быть сконфигурировано для программного определения независимого описания интерфейса (независимых описаний интерфейсов). В некоторых случаях независимое описание интерфейса может быть сохранено (независимые описания интерфейсов могут быть сохранены) в машинно-считываемом формате.

В приведенном ниже представлен раздел, озаглавленный "Рабочее окружение", и в нем описано одно окружение, в котором могут использоваться один или большее количество вариантов осуществления изобретения. После него приведен раздел, озаглавленный “Доступ к компонентам операционной системы”, в котором описана архитектура, обеспечивающая для множества языков программирования возможность программного доступа к компонентам системы. В следующем разделе, озаглавленном “Моделирование объектно-ориентированных языков при помощи системы абстрактного типа”, описано то, как может использоваться система абстрактного типа совместно с расширенным языком IDL для описания интерфейсов операционной системы объектно-ориентированным способом. Наконец, в разделе, озаглавленном “Пример системы”, описана приведенная в качестве примера система, которая может быть использована для реализации одного или большего количества вариантов осуществления изобретения.

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

Рабочее окружение

На Фиг. 1 проиллюстрировано рабочее окружение согласно одному или большему количеству вариантов осуществления изобретения, обозначенная в целом номером позиции 100. Среда 100 включает в себя вычислительное устройство 102, имеющее один или большее количество процессоров 104 и один или большее количество считываемых посредством компьютера запоминающих носителей 106. Считываемые посредством компьютера запоминающие носители могут включать в себя, в качестве примера, а не ограничения, энергозависимые и энергонезависимые запоминающие устройства и/или носители информации всех типов, которые обычно относятся к вычислительному устройству. Такими носителями информации могут являться в том числе постоянное запоминающее устройство (ПЗУ), оперативное запоминающее устройство (ОЗУ), флэш-память, накопитель на жестких дисках, съемные носители и т.п. Один конкретный пример вычислительного устройства показан и описан ниже на Фиг. 5.

Кроме того, вычислительное устройство 102 включает в себя операционную систему (ОС) 108 и соответствующий интерфейс (соответствующие интерфейсы) операционной системы 110. Несмотря на то, что они показаны как отдельные модули, следует осознавать и понимать, что операционная система 108 и интерфейс (интерфейсы) операционной системы 110 могут быть реализованы в виде отдельных модулей, объединенных модулей или любой их комбинации, не выходя за пределы объема заявленного изобретения. Операционная система 108 представляет функциональные возможности, сконфигурированные для управления программным обеспечением и/или аппаратными ресурсами вычислительного устройства 102. Интерфейс (интерфейсы) операционной системы 110 предоставляет программируемый доступ к службам и/или функциональным возможностям, обеспечиваемым операционной системой 108, таким как, например, управление памятью, управление файлами, службы, функции, управление ресурсами, управление периферийными устройствами и т.п.

Вычислительное устройство 102 также включает в себя один или большее количество файлов 112 на дескриптивном языке, которые представляют собой один или большее количество файлов, сконфигурированных для описания одного или большего количества интерфейсов. В некоторых вариантах осуществления изобретения интерфейс может соответствовать операционной системе, например, интерфейсу (интерфейсам) 110 операционной системы. Файлы на дескриптивном языке могут описывать интерфейсы с использованием любого подходящего описания, языка разметки и/или синтаксиса, например, с использованием языка определения интерфейсов (IDL), расширяемого языка разметки (XML) и т.п.

Кроме того, вычислительное устройство 102 также включает в себя один или большее количество модулей 114 редактора/компилятора. В некоторых вариантах осуществления изобретения модуль 114 редактора/компилятора предоставляет функциональные возможности, которые обеспечивают считывание и/или интерпретацию файла (файлов) 112 на дескриптивном языке и генерацию выходных данных, таких как, например, один или большее количество бинарных файлов 116 метаданных, на основе файла (файлов) 112. Бинарный файл (бинарные файлы) 116 метаданных представляет собой один или большее количество машинно-считываемых файлов, которые включают в себя информацию, соответствующую интерфейсу (интерфейсам) 110 операционной системы и/или операционной системе 108, например информацию о типах входных параметров, о порядке вызова параметра, о соотношениях между интерфейсами и т.п.

В альтернативном варианте или в дополнение к этому модуль (модули) 114 редактора/компилятора предоставляет (предоставляют) функциональные возможности, обеспечивающие считывание и/или расшифровку одного или большего количества файлов 118) исходного кода. Файл (файлы) 118 исходного кода соответствует одному или большему количеству файлов, содержащих операторы программы, соответствующие по меньшей мере одному языку программирования. В некоторых случаях файл (файлы) 118 исходного кода может (могут) включать в себя операторы, обращающиеся к одному или к большему количеству интерфейсов операционной системы. Модуль (модули) 114 редактора/компилятора интерпретирует (интерпретируют) файл (файлы) 118 исходного кода и генерирует (генерируют) машинно-выполнимый код на основании исходного файла (исходных файлов).

Вычислительное устройство 102 может быть реализовано как любое подходящее вычислительное устройство, такое как, например, настольный компьютер, портативный компьютер, ноутбук, карманный компьютер, такой как, например, персональное цифровое информационное устройство (PDA), сотовый телефон и т.п., а эти примеры не являются ограничивающим признаком.

После того как было приведено описание примера операционной среды, теперь будет рассмотрено описание демонстрации программного действия одного или большего количества языков программирования на компоненты операционной системы.

Доступ к компонентам операционной системы

Приложения, работающие в вычислительном устройстве, часто используют функции, обеспечиваемые операционной системой, работающей в вычислительном устройстве. Операционная система может обеспечивать возможность упрощенного доступа к соответствующим ресурсам в вычислительном устройстве, а также обеспечивает службы. Иногда может осуществляться программный доступ к этим признакам, службам и/или ресурсам. Однако, если операционная система представляет эти функциональные возможности в формате языка программирования, являющегося иным, чем язык программирования, на котором написано приложение, то программист обычно пишет интерфейсные функции для содействия при переходе между различными языками программирования. Например, рассмотрим интерфейс, который был написан и/или представлен как плоская экспортируемая функция на языке "С". Программист на языке С# (Си-шарп) или Visual Basic, желающий использовать функцию в стиле языка "С", может включать в состав программы специальные операторы и/или дополнительный код для обеспечения возможности успешного вызова их языком программирования функции в стиле языка "С". Вследствие этого приложения из представленных интерфейсов, написанные на ином языке программирования, не имеют доступа к интерфейсам до тех пор, пока не будут написаны дополнительные операторы и/или интерфейсные функции.

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

Рассмотрим Фиг. 2, на которой проиллюстрирована архитектура 200 согласно одному или большему количеству вариантов осуществления изобретения. Архитектура 200 включает в себя операционную систему 202, которая может быть сконфигурирована для выполнения в вычислительном устройстве. Следует понимать, что для краткости операционная система 202 не проиллюстрирована в полном объеме. Операционная система 202 включает в себя один или большее количество компонентов 204 операционной системы, сконфигурированных для управления ресурсами, соответствующими вычислительному устройству. В некоторых вариантах осуществления изобретения компонент (компоненты) 204 операционной системы может обеспечивать программируемый доступ к ресурсам, а также к одной или большему количеству служб и/или функций, связанных с управлением ресурсами. Компонент (компоненты) 204 операционной системы также может включать в себя базовые элементы, соответствующие операционной системе 202, а также комплексные элементы, созданные из базовых элементов.

В некоторых вариантах осуществления изобретения компонент (компоненты) 204 операционной системы может подвергаться воздействию через один или большее количество интерфейсов, таких как, например, API. В этом примере операционная система 202 включает в себя новые семейства 206 API, семейства 208 API на основе модели компонентных объектов (COM) и семейства 210 плоских API на основе экспорта. Новые семейства 206 API представляют собой один или большее количество родственных API, где функциональные возможности (то есть классы, интерфейсы, методы, свойства, события и т.п.) описаны непосредственно с использованием системы абстрактного типа, что более подробно описано ниже. Семейства 208 API на основе COM представляют собой один или большее количество API, где функциональные возможности описаны с использованием системы типа "модель компонентных объектов" (COM). Семейства 210 плоских API на основе экспорта представляют собой один или большее количество API, где функциональные возможности описаны с использованием сигнатуры метода (то есть сигнатура метода включает в себя наименование метода, соглашение о вызовах, количество и тип аргументов метода). Кроме того, плоские API на основе экспорта представляют собой интерфейсы прикладного программирования (API), которые только лишь идентифицированы по их наименованию, но не скомпонованы по классам и/или объектно-ориентированным способом. Программист, желающий определить то, какие API доступны, может вручную и/или программно осуществить доступ к описаниям каждого API. Например, для определения того, какие интерфейсы существуют для новых семейств API 206 и как их вызвать, программист может осуществить доступ к соответствующим метаданным 212. Несмотря на то, что семейства 208 API на основе COM и семейства 210 плоских API на основе экспорта имеют соответствующие описания системы независимого от языка типа в метаданных соответственно 214 и 216, программист сначала пишет код оболочки для преобразования описания системы независимого от языка типа в интерфейсы прикладного программирования (API) на основе COM и/или в плоские API на основе экспорта.

Метаданные 212, 214 и 216 могут быть сконфигурированы так, что включают в себя информацию, описывающую различные аспекты соответствующего интерфейса (соответствующих интерфейсов), такую как, например, информация о версии, о доступных способах, о параметрах, которые принимает интерфейс (принимают интерфейсы), о типах данных, которые имеют параметры, о порядке передачи параметров и т.д. В некоторых вариантах осуществления изобретения эти метаданные могут включать в себя иерархически организованную информацию, соответствующую интерфейсу, например информацию, описывающую соотношения между интерфейсом (интерфейсами) и/или описывающую интерфейс (интерфейсы) объектно-ориентированным способом. Эти метаданные могут быть сконфигурированы так, что включают в себя описания класса, соответствующих методов, параметров класса и т.п. В некоторых случаях один или большее количество файлов на языке IDL могут быть расширены так, что включают в себя некоторые из этих описаний и используются при генерации одного или большего количества файлов метаданных. В некоторых случаях метаданные могут быть основаны, по меньшей мере частично, на одном или на большем количестве файлов на языке IDL, что более подробно описано ниже.

Операционная система 202 также включает в себя двоичный интерфейс (двоичные интерфейсы) 218 приложений (ABI). ABI описывает на машинном уровне бинарный контракт для вызова функций, методов, интерфейсов прикладного программирования (API) и т.п. Бинарный контракт может включать в себя идентификатор или имя, соответствующие функции, сигнатуре, которая может использоваться для вызова функции, порядок следования параметров, передаваемых в функцию и/или в типы данных, соответствующие параметрам, и т.д. В альтернативном варианте или в дополнение к этому бинарный контракт может включать в себя определения и/или правила для проявления характера поведения, соответствующего по меньшей мере одному типу из типов системы. Как правило, характер поведения, соответствующий бинарному контракту и/или заданный им, не изменяется. Например, если сигнатура и/или идентификатор бинарного контракта остаются неизменными, то соответствующий характер поведения контракта также остается неизменным.

Двоичный интерфейс 218 приложений представляет функциональные возможности, подвергаемые воздействию бинарными средствами, которые могут быть надежно вызваны другими приложениями. В этом примере двоичный интерфейс (двоичные интерфейсы) 218 приложений включает в себя интерфейсы, базовые типы и базовые шаблоны, соответствующие компоненту (компонентам) 204 операционной системы. Одно или большее количество приложений, являющихся внешними для операционной системы 202, такие как, например, приложение (приложения) 220, могут осуществлять доступ к компонентам операционной системы 204 через один или большее количество двоичных интерфейсов 218 приложений.

Приложения 220 могут включать в себя одно или большее количество приложений, сгенерированных из одного или большего количества языков программирования, таких как, например, язык гипертекстовой разметки (HTML), JavaScript, Visual Basic, C#, C++ и т.п. В некоторых вариантах осуществления изобретения приложения 220 включают в себя один или большее количество вызовов к компоненту операционной системы. В некоторых случаях приложение (приложения) 220 может быть сконфигурировано так, что сначала программно определяют, какой интерфейс доступен (какие интерфейсы доступны), и затем вызывают один или большее количество из определенных интерфейсов. В некоторых случаях приложение (приложения) 220 осуществляет доступ к интерфейсу (интерфейсам) через двоичный интерфейс (интерфейсы) 218 приложений при помощи одного или большего количества сгенерированных модулей 222 проекции языка, более подробное описание которых приведено ниже.

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

Рассмотрим пример, когда программист хочет осуществить доступ к компоненту операционной системы. При написании приложения, такого как, например, приложение (приложения) 220, программист генерирует исходный код в редакторе/компиляторе, соответствующем по меньшей мере одному конкретному языку программирования. Редактор/компилятор может быть сконфигурирован для доступа к файлу (файлам) метаданных для получения информации, соответствующей тому, какие интерфейсы и/или интерфейсы прикладного программирования (API), соответствующие операционной системе, являются доступными. Например, в некоторых вариантах осуществления изобретения, когда программист пишет строку кода, которая включает в себя вызов класса, реализованного как часть компонента операционной системы, компилятор/редактор может запрашивать метаданные, соответствующие этому классу, и возвращать программисту перечень того, какие именно методы, свойства и т.п. соответствуют этому классу. Этот перечень может включать в себя любую информацию, сведения о соответствующих методах и/или свойствах класса и т.п. В альтернативном варианте или в дополнение к этому этот перечень может включать в себя перечень имеющихся классов. В некоторых вариантах осуществления изобретения эта информация может быть предоставлена как часть функции автозавершения, сконфигурированной для визуального представления соответствующих методов, свойств и т.д. интерфейса для выбора пользователем. После выбора способа и/или свойства компилятор/редактор может вставлять соответствующий синтаксис в исходный код для более эффективной и точной генерации исходного кода.

В некоторых вариантах осуществления изобретения программист может написать исходный код, сконфигурированный для создания экземпляра объекта класса компонентов операционной системы. При вызове в среде выполнения операционная система динамически создает экземпляр класса для возвращения коду вызова. Однако, как более подробно описано ниже, экземпляром, возвращенным коду вызова, может являться "абстрактный объект" или объект, описанный в системе абстрактного типа, соответствующей компонентам операционной системы. Для связывания между собой объекта абстрактного типа и данных конкретного типа на языке программирования, соответствующего коду вызова, компилятор может быть сконфигурирован для преобразования и/или соотнесения абстрактного объекта в сопоставимые типы на соответствующем ему языке программирования, например, посредством сгенерированного модуля (модулей) 222 проекции языка. В некоторых случаях может использоваться прокси-объект для связывания запросов между абстрактным объектом в компонентах операционной системы и конкретным объектом, соответствующим языку программирования.

Рассмотрим прокси-объект, сконфигурированный для эмуляции характера поведения класса компонентов операционной системы. В некоторых случаях может быть создан прокси-объект, включающий в себя заглушки соответствующих типов, методов, свойств, событий, интерфейсов и т.д. для класса. Прокси-объект может быть создан на языке программирования кода вызова, обеспечивая, таким образом, возможность вызова кода для доступа к прокси-объекту способом, свойственным коду вызова. Заглушки могут включать в себя надлежащие сведения и/или код для преобразования и/или соотнесения этих вызовов в операционную систему (и из нее). Например, в некоторых вариантах осуществления изобретения прокси-объект может обмениваться информацией с двоичным интерфейсом (интерфейсами) 218 приложений.

В некоторых вариантах осуществления изобретения язык программирования может прерывать описанную выше интерфейсную функцию и/или описанный выше прокси-объект для преобразования абстрактного типа в тип, свойственный языку программирования. Редактор/компилятор языка программирования может быть сконфигурирован для считывания метаданных, таких как, например, файлы 212, 214 и 216 метаданных, определять, какие абстрактные типы используются, преобразовывать абстрактный тип (абстрактные типы) в один или в большее количество сопоставимых типов на соответствующем языке программирования и привязывать соответствующую интерфейсную функцию и/или прокси-объект к абстрактному типу, соответствующему компонентам операционной системы. Когда существует соответствие для каждого типа между языком программирования и системой абстрактного типа, язык программирования может автоматически осуществлять доступ к любым текущим или будущим интерфейсам, заданным системой абстрактного типа, без дополнительного программирования программистом.

В качестве примера рассмотрим Фиг. 3, на которой проиллюстрирована схема последовательности операций, на которой описаны этапы способа согласно одному или большему количеству вариантов осуществления изобретения. Это способ может выполняться любыми подходящими аппаратными средствами, посредством программного обеспечения, аппаратно-реализованного программного обеспечения (firmware) или посредством их комбинации. По меньшей мере в некоторых вариантах осуществления изобретения аспекты способа выполняются посредством программного обеспечения, например, модулем 114 редактора/компилятора, исполняющимся в вычислительном устройстве 102.

На этапе 302 принимают запрос на получение информации, соответствующей доступным интерфейсам операционной системы. Например, этот запрос может быть сконфигурирован для запрашивания того, какие интерфейсы являются доступными, и/или на получение иной информации, соответствующей имеющимся интерфейсам. Это может быть осуществлено любым подходящим способом. В некоторых вариантах осуществления изобретения этот запрос может быть автоматически сгенерирован редактором исходного кода, в котором разрабатывается исходный код. Редактор кода может идентифицировать вызов интерфейса и/или компонента операционной системы и после идентификации послать запрос о доступных способах, свойствах и т.д., соответствующих интерфейсу операционной системы. В некоторых вариантах осуществления изобретения этот запрос может быть сгенерирован вручную посредством выбора элемента ниспадающего меню, кнопки-переключателя и т.п. Этот запрос может быть сконфигурирован для выдачи запроса на получение информации, соответствующей всем доступным интерфейсам операционной системы, некоторым доступным интерфейсам операционной системы, отдельным интерфейсам операционной системы или любой их комбинации. В некоторых вариантах осуществления изобретения этот запрос может быть сгенерирован посредством исполняющегося приложения, такого как, например, приложение (приложения) 220 из Фиг. 2.

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

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

Рассмотрим пример языка описания интерфейса, описывающего ABI для класса OpenPicker среды выполнения. В классе OpenPicker среды выполнения содержится метод PickMultipleltems, сконфигурированный для возврата набора объектов FileItem. В этом конкретном примере класс FileItem содержит метод GetProperties, сконфигурированный для возврата объекта FileItemProperties, содержащий значение "Имя" (Name).

runtimeclass OpenPicker {

interface IOpenPicker;

}

interface IOpenPicker: IInspectable {

HRESULT PickMultipleItems( [out, retval]

IVector<IFileItem*>* folder );

}

interface IFileItem: IInspectable {

HRESULT GetProperties([out, retval]

FileItemProperties** retVal);

}

interface IFileItemProperties: IInspectable {

[propget] HRESULT Name([out, retval] HSTRING

*value);

}

В некоторых вариантах осуществления (изобретения) компилятор языка C# может преобразовывать описание в конструкции на языке C#. Путем преобразования описания в конструкции, ориентированные на конкретный язык, доступ к интерфейсам операционной системы может быть осуществлен способом, свойственным языку программирования C#, который проиллюстрирован ниже:

OpenPicker picker = new OpenPicker();

var items = picker.PickMultipleItems();

foreach (FileItem item in items) {

Display (item.GetProperties().Name);

}

В еще одном примере структура, заданная независимым от языка способом, может быть преобразована в объект на языке JavaScript. Рассмотрим пример структуры FrameRate, заданной с использованием:

typedef struct FrameRate {

UINT32 Numerator;

UINT32 Denominator;

} FrameRate;

Структура FrameRate включает в себя два поля UINT32: "числитель" (Numerator) и "знаменатель" (Denominator). Поскольку структура FrameRate задана с использованием независимых от языка элементов, то доступ к этой структуре могут осуществлять различные программы, ориентированные на конкретный язык, с использованием надлежащего соотнесения, например, путем доступа посредством языка JavaScript. Однако, язык JavaScript не включает в себя концепцию структуры, содержащей поля, или концепцию 32-битовых целых чисел без знака. Вместо этого JavaScript включает в себя концепцию объекта со свойствами и концепцию "число" (Number). В этом примере вышеупомянутое определение структуры может являться объектом с двумя свойствами, именуемыми "числитель" (Numerator) и "знаменатель" (Denominator), оба из которых относятся к типу "число" (Number):

// использование вышеупомянутого в языке JavaScript

var framerate = videoType.Framerate; // Get a framerate

object

var ratio = framerate.Numerator / framerate.Denominator;

Рассмотрев программное воздействие одного или большего количества языков программирования на компоненты операционной системы, теперь рассмотрим обсуждение моделирования объектно-ориентированных языков системой абстрактного типа согласно одному или большему количеству вариантов осуществления изобретения.

Моделирование объектно-ориентированных языков системой абстрактного типа

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

Различные варианты осуществления изобретения обеспечивают возможность моделирования одного или большего количества интерфейсов операционной системы объектно-ориентированным способом с использованием системы абстрактного типа. В некоторых вариантах осуществления изобретения расширенный язык IDL может включать в себя синтаксис для описания соотношений между одним или большим количеством интерфейсов. В альтернативном варианте или в дополнение к этому расширенный язык IDL может включать в себя правила, управляющие тем, как может быть описан и/или задан интерфейс. В некоторых вариантах осуществления изобретения бинарный контракт может быть сконфигурирован с возможностью выявления характера поведения, соответствующего системе абстрактного типа, и дополнительно сконфигурирован так, что включает в себя информацию, соответствующую агрегированным типам данных.

Объектно-ориентированная модель описывает объекты с использованием иерархии классов, где класс может включать в себя методы, свойства, наследование и т.д. Как правило, но не обязательно, объектно-ориентированный класс включает в себя один или большее количество конструкторов. Конструктор представляет собой функцию класса, которая при ее вызове создает в памяти экземпляр/объект класса для его использования. Некоторые конструкторы класса содержат дополнительный код, который подготавливает создаваемый экземпляр/объект к использованию. Например, дополнительный код может инициализировать переменные-члены класса, исполнять соответствующие подпрограммы запуска класса и т.д. Конструктор, заданный по умолчанию, не имеет каких-либо входных параметров, тогда как конструктор, не заданный по умолчанию, имеет один или большее количество входных параметров.

В некоторых вариантах осуществления изобретения один или большее количество конструкторов из компонента операционной системы могут быть ограничены соблюдением условий конкретного варианта реализации и/или конструкций. Вследствие соблюдения условий конкретных вариантов реализации вызывающие операторы конструкторов могут зависеть от характера поведения конструктора и/или результирующего объекта. Например, конструктор компонента операционной системы, заданный по умолчанию, может быть ограничен и/или сопоставлен с заданным по умолчанию конструктором метода ActivateInstance интерфейса IActivationFactory объекта фабрики классов. Объект фабрики классов представляет собой шаблон разработки, смоделированный для создания объектов без указания точного класса создаваемого объекта.

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

Одним из способов задания описания интерфейса является использование файла на дескриптивном языке, таком как, например, расширенный язык описания, подобный языку IDL и/или расширяемому языку разметки (XML). В некоторых вариантах осуществления изобретения расширенный язык описания может быть сконфигурирован так, что обеспечивает возможность описания и/или обозначения одного или большего количества интерфейсов конструктора компонента операционной системы. Например, рассмотрим класс "компрессор" (Compressor), проиллюстрированный ниже. В этом примере класс "компрессор" (Compressor) объявляет, что его интерфейс ICompressorFactory содержит по меньшей мере одно определение метода (методов) конструктора, не заданного по умолчанию, который соответствует классу.

[version(NTDDI_WIN8), activatable(ICompressorFactory, NTDDI_WIN8)]

runtimeclass Compressor {

[default] interface ICompressor;

}

[version(NTDDI_WIN8), uuid(5F3D96A4-2CFB-442C-A8BA-D7DUB039DA0)]

interface ICompressorFactory: IInspectable {

HRESULT CreateCompressor([in]

Windows.Foundation.OutputStream * UnderlyingStream, [in]

CompressAlgorithm Algorithm, [out, retval] Compressor

**CreatedCompressor);

}

Эти описания могут содержаться в одном или в большем количестве файлов и использоваться совместно по меньшей мере с одним компилятором для генерации описания (описаний) одного или большего количества интерфейсов в машинно-считываемом формате, более подробное описание которого приведено ниже.

Объектно-ориентированный класс может быть сконфигурирован так, что включает в себя по меньшей мере один статический метод, по меньшей мере одно статическое свойство, по меньшей мере одно статическое событие или любую их комбинацию. Аналогично наложению ограничения на определение конструктора, статические методы, статические свойства и/или статические события могут быть спроектированы так, что соответствуют одному или большему количеству специально назначенных интерфейсов. Рассмотрим пример класса CallControl, который объявляет статические методы, свойства и события. В этом примере статические методы, свойства и события заданы в интерфейсе ICallControlStatics:

[version(NTDDI_WIN8), uuid("03945AD5-85AB-40E1-AF19- 56C94303B019"), exclusiveto(CallControl)]

interface ICallControlStatics: IInspectable

{

HRESULT GetDefault([out, retval] CallControl **callControl);

HRESULT FromId([in] HSTRIN6 deviceInterfaceId, [out, retval] CallControl **callControl);

}

// Runtime classes

[version(NTDDI_WIN8),

static(ICallControlStatics, NTDDI_WIN8)]

runtimeclass CallControl{

[default] interface ICallControl;

}

Объектно-ориентированный класс может быть сконфигурирован так, что включает в себя по меньшей мере один метод экземпляра класса, по меньшей мере одно свойство экземпляра, по меньшей мере одно событие экземпляра или любую их комбинацию. Члены экземпляра (методы, свойства и события) работают в заданном экземпляре класса, тогда как статические члены совместно используются всеми членами класса. Класс может быть спроектирован так, что соответствует одному или большему количеству специально назначенных интерфейсов, как в вышеупомянутом примере, где класс CallControl объявляет, что соответствующие ему методы экземпляра класса, свойства и события заданы в интерфейсе ICallControl. В некоторых вариантах осуществления изобретения один или большее количество компонентов операционной системы могут моделировать/реализовывать эти интерфейсы после шаблона разработки фабрики классов/на шаблоне разработки фабрики классов.

Если конкретный язык программирования вызывает специфический для конкретного языка конструктор, статические члены или члены экземпляра, то модуль проекции языка, например, сгенерированный модуль 222 проекции языка из Фиг. 2, может соотносить программируемые вызовы, специфические для конкретного языка, с надлежащим методом и/или интерфейсом, соответствующим надлежащему объекту из фабрики классов или экземпляру. В некоторых вариантах осуществления изобретения объект из фабрики классов соответствует компоненту операционной системы и/или классу среды выполнения. Например, сигнатура метода кода, управляющего компилятором для создания экземпляра класса среды выполнения, может быть сопоставлена с надлежащим методом интерфейса конструктора объекта фабрики классов. В еще одном примере модуль проекции языка может быть сконфигурирован сопоставлять ориентированную на конкретный язык сигнатуру метода, управляющую компилятором для вызова статического метода, с надлежащим методом согласованного интерфейса в статическом интерфейсе, соответствующем компоненту операционной системы. В еще одном примере модуль проекции языка может быть сконфигурирован сопоставлять специфическую для конкретного языка сигнатуру метода, управляющую компилятором для вызова метода экземпляра класса, с надлежащим методом согласованного интерфейса в интерфейсе, соответствующем конкретному экземпляру компонента операционной системы.

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

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

Рассмотрим чертеж Фиг. 4, на котором проиллюстрировано соотношение между файлом (файлами) 402 на расширенном языке IDL, компилятором 404 и файлом (файлами) 406 метаданных согласно одному или большему количеству вариантов осуществления изобретения. Здесь компилятор 404 принимает и обрабатывает расширенный файл (файлы) 402 на расширенном языке IDL для создания файла (файлов) 406 метаданных. По меньшей мере в некоторых вариантах осуществления изобретения модули, проиллюстрированные как имеющие связь друг с другом, могут быть реализованы в виде программного обеспечения, аппаратных средств или любой их комбинации, как, например, модуль 114 редактора/компилятора, выполняющийся в вычислительном устройстве 102.

В проиллюстрированном и описанном варианте осуществления изобретения файл (файлы) 402 на расширенном языке IDL может включать в себя один или большее количество файлов, которые задают один или большее количество интерфейсов компонента операционной системы, такого как, например, API операционной системы. Может быть описан компонент операционной системы любого подходящего типа, такой как, например, объект/класс "файл", объект/класс "строка", объект/класс "графика", объект/класс "культура" и т.п. Каждый объект может включать в себя информацию о методах, свойствах, наследовании и т.д., которая может соответствовать объектно-ориентированному классу. Расширенный язык IDL может включать в себя синтаксис для обеспечения возможности описания соотношений этих типов между одним или большим количеством интерфейсов. В альтернативном варианте или в дополнение к этому расширенный язык IDL может описывать систему абстрактного типа.

В некоторых вариантах осуществления изобретения система абстрактного типа может быть сконфигурирована так, что обеспечивает поддержку и/или описывает различные типы данных. Например, интерфейс метода может быть задан так, что сопоставляет физическое требование, с которым работают все интерфейсы, с экземпляром объекта. В другом примере система абстрактного типа может использоваться для задания указателя функции, который может быть вызван через язык программирования и границы компоненты. Первый компонент может порождать указатель функции, или делегата, связанного с методом. Затем делегат может быть передан через границу бинарной компиляции во второй компонент, написанный на произвольном языке программирования, и вызван. Различные варианты осуществления изобретения обеспечивают для расширенного языка IDL возможность задания и/или описания этих типов данных, задания правил для составления фундаментальных типов данных, а также для объединения типов данных в составные типы.

В проиллюстрированном и описанном варианте осуществления изобретения компилятор 404 принимает один или большее количество входных файлов, таких как, например, файл (файлы) 402 на расширенном языке IDL, и создает один или большее количество файлов 406 метаданных. Файл (файлы) 406 метаданных может быть сконфигурирован (могут быть сконфигурированы) для автоматизированного доступа. Например, файлы метаданных могут храниться в машинно-считываемом формате. В некоторых вариантах осуществления изобретения файл (файлы) 406 метаданных соответствует одному или большему количеству компонентов операционной системы. Как описано выше, в альтернативном варианте или в дополнение к этому компилятор 404 может генерировать заглушенные прокси-объекты связи.

Приложение (приложения) 408 может динамически определять, какие интерфейсы прикладного программирования (API) являются доступными, например, путем считывания файла (файлов) 406 метаданных. В некоторых вариантах осуществления изобретения приложение (приложения) 408 может быть сконфигурировано (могут быть сконфигурированы) как редактор/компилятор 114 из Фиг. 1. Посредством файла (файлов) 406 метаданных приложение может определять, присутствуют ли более поздние версии функциональных возможностей, какие параметры принимает API, а также сообщать пользователю о том, какие функциональные возможности для API имеются в среде выполнения. Соответственно, за счет включения описаний API в машинно-считываемом формате, а также описания интерфейсов прикладного программирования (API) посредством системы абстрактного типа, приложения и/или языки, обеспечивающие поддержку соответствия между системой абстрактного типа и конкретным языком программирования, имеют легкий доступ к интерфейсам прикладного программирования (API) при небольшом объеме работы программиста.

Рассмотрев моделирование объектно-ориентированных языков посредством системы абстрактного типа, теперь рассмотрим обсуждение примера системы согласно одному или большему количеству вариантов осуществления изобретения.

Система, приведенная в качестве примера

На Фиг. 5 проиллюстрирован пример вычислительного устройства 500, которое может использоваться для реализации различных описанных выше вариантов осуществления изобретения. Вычислительным устройством 500 может являться, например, вычислительное устройство 102 из Фиг. 1 или любое другое подходящее вычислительное устройство.

Вычислительное устройство 500 включает в себя один или большее количество процессоров или блоков 502 обработки данных, одно или большее количество запоминающих устройств и/или компонентов 504 запоминающего устройства, одно или большее количество устройств 506 ввода-вывода (I/O) и шину 506, которая позволяет различным компонентам и устройствам обмениваться информацией друг с другом. Шина 508 представляет собой одну или большее количество шин со структурой любого из нескольких типов, включая шину памяти или контроллер памяти, шину периферийных устройств, ускоренный графический порт и процессор или локальную шину с использованием любой из множества архитектур шины. Шина 508 может включать в себя проводные и/или беспроводные шины.

Компонент 504 памяти/запоминающего устройства представляет собой один или большее количество компьютерных носителей информации. Компонент 504 может включать в себя энергозависимые носители (например, оперативное запоминающее устройство (ОЗУ)) и/или энергонезависимые носители (например, постоянное запоминающее устройство (ПЗУ), флэш-память, оптические диски, магнитные диски и т.д.). Компонент 504 может включать в себя стационарные носители (например, ОЗУ, ПЗУ, стационарный накопитель на жестких дисках и т.д.), а также съемные носители (например, карту флэш-памяти, съемный жесткий диск, оптический диск и т.д).

Одно или большее количество устройств 506 ввода-вывода позволяют пользователю вводить команды и информацию в вычислительное устройство 500, а также позволяют предоставлять информацию пользователю и/или другим компонентам или устройствам. Примерами устройств ввода являются в том числе клавиатура, устройство управления курсором (например, манипулятор типа "мышь"), микрофон, сканер и т.д. Примерами устройств вывода являются в том числе дисплей (например, монитор или проектор), громкоговорители, принтер, сетевая плата и т.д.

Различные способы могут быть описаны здесь в общем контексте программного обеспечения или программных модулей. Обычно программное обеспечение включает в себя подпрограммы, программы, объекты, компоненты, структуры данных и т.д., которые выполняют конкретные задачи или реализуют конкретные абстрактные типы данных. Реализация этих модулей и способов может быть сохранена на считываемых посредством компьютера носителях информации какого-либо типа или передана посредством них. Считываемыми посредством компьютера носителями информации могут являться любой существующий носитель информации или любые существующие носители информации, к которым может осуществлять доступ вычислительное устройство. В качестве примера, не являющегося ограничением, считываемые посредством компьютера носители информации могут содержать "считываемые посредством компьютера запоминающие среды".

"Считываемые посредством компьютера запоминающие среды" включают в себя энергозависимые и энергонезависимые, сменные и стационарные среды, реализованные любым способом или посредством любой технологии, для хранения информации, такой как, например, считываемые посредством компьютера команды, структуры данных, программные модули или иные данные. Считываемыми посредством компьютера запоминающими средами являются в том числе ОЗУ, ПЗУ, электрически стираемое программируемое постоянное запоминающее устройство (ЭСППЗУ), флэш-память или запоминающее устройство, выполненное по другой технологии, постоянное запоминающее устройство на компакт-диске (CD-ROM), универсальные цифровые диски (DVD) или иное оптическое запоминающее устройство, магнитные кассеты, магнитная лента, запоминающее устройство на магнитных дисках, или другие запоминающие устройства на магнитных носителях, или любая иная среда, которая может использоваться для хранения желательной информации и к которой может осуществлять доступ компьютер, но эти примеры не являются ограничивающим признаком.

Заключение

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

Несмотря на то, что изобретение было описано на языке, характерном для структурных признаков и/или методологических действий, следует понимать, что объем изобретения, определяемый прилагаемой формулой изобретения, не обязательно ограничен конкретными признаками или действиями, которые описаны выше. Наоборот, конкретные признаки и действия, которые описаны выше, раскрыты в виде примеров реализации формулы изобретения.

Изобретение относится к технологиям описания интерфейсов прикладного программирования. Техническим результатом является автоматизация описания интерфейса прикладного программирования. Предложен компьютерно-реализуемый способ описания интерфейсов операционной системы. Способ содержит этап, на котором принимают запрос информации, связанной с одним или более доступными интерфейсами операционной системы. Далее согласно способу получают информацию, связанную с этими одним или более доступными интерфейсами операционной системы, причем эти интерфейсы операционной системы описаны с использованием системы абстрактных типов, при этом система абстрактных типов сконфигурирована для обеспечения описаний интерфейсов, которые являются независимыми от конкретных языков программирования, причем по меньшей мере одно описание интерфейса операционной системы включает в себя описания типов параметров для вызова. 3 н. и 16 з.п. ф-лы, 5 ил.

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

2. Компьютерно-реализуемый способ по п. 1, в котором упомянутая информация, связанная с одним или более доступными интерфейсами операционной системы, дополнительно содержит иерархически организованную информацию.

3. Компьютерно-реализуемый способ по п. 1, в котором упомянутая информация содержит информацию о версии, соответствующую по меньшей мере одному интерфейсу, типы данных отдельных параметров, относящихся к этому по меньшей мере одному интерфейсу, и порядок вызова этих отдельных параметров, относящихся к по меньшей мере одному интерфейсу.

4. Компьютерно-реализуемый способ по п. 1, в котором при упомянутом получении информации, связанной с одним или более доступными интерфейсами операционной системы, получают информацию программно из по меньшей мере одного файла метаданных.

5. Компьютерно-реализуемый способ по п. 1, в котором бинарный контракт включает в себя одну или более сигнатур функций.

6. Компьютерно-реализуемый способ по п. 5, в котором бинарный контракт включает в себя одно или более имен функций.

7. Считываемый компьютером носитель данных, содержащий считываемые компьютером команды, которые при их исполнении по меньшей мере одним процессором реализуют:
один или более модулей интерфейса прикладного программирования (API), сконфигурированных для обеспечения программного доступа к функциональным возможностям, соответствующим операционной системе;
один или более файлов метаданных, относящихся к этим одному или более модулям API, причем эти один или более файлов метаданных сконфигурированы так, что они включают в себя по меньшей мере одно описание упомянутых одного или более API, причем в этом по меньшей мере одном описании используется система абстрактных типов для описания программного доступа к упомянутым одному или более API;
один или более модулей двоичного интерфейса приложений (ABI), сконфигурированных так, что они включают в себя один или более бинарных контрактов машинного уровня для вызова этих одного или более API; и
один или более сгенерированных модулей проекции языка, сконфигурированных соотносить по меньшей мере один тип системы абстрактных типов с по меньшей мере с одним типом из одного или более конкретных языков программирования, при этом система абстрактных типов сконфигурирована для обеспечения описаний API, которые являются независимыми от этих одного или более конкретных языков программирования, включая описания типов параметров для вызова, относящиеся к упомянутым API.

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

9. Считываемый компьютером носитель данных по п. 7, при этом сгенерированный модуль проекции языка содержит по меньшей мере один прокси-объект, сконфигурированный для эмуляции по меньшей мере одного типа системы абстрактных типов способом, свойственным упомянутым одному или более конкретным языкам программирования.

10. Считываемый компьютером носитель данных по п. 7, при этом бинарный контракт для вызова упомянутых одного или более API содержит по меньшей мере одно определение характера поведения, соответствующее по меньшей мере одному типу системы абстрактных типов.

11. Считываемый компьютером носитель данных по п. 7, при этом упомянутые один или более модулей API содержат объектно-ориентированный класс, причем упомянутые один или более файлов метаданных сконфигурированы для описания этого объектно-ориентированного класса объектно-ориентированным способом.

12. Считываемый компьютером носитель данных по п. 11, при этом объектно-ориентированный класс содержит класс файла.

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

14. Считываемый компьютером носитель данных, на котором воплощены исполняемые компьютером команды, которые являются исполняемыми, чтобы:
предоставлять одну или более функциональных возможностей, соответствующих операционной системе, используя один или более интерфейсов;
описывать эти один или более интерфейсов с использованием системы абстрактных типов, при этом система абстрактных типов сконфигурирована для обеспечения иерархически организованных описаний этих одного или более интерфейсов, причем система абстрактных типов сконфигурирована для обеспечения описаний, которые являются независимыми от конкретных языков программирования, при этом по меньшей мере одно описание включает в себя описания типов параметров для вызова, относящиеся к упомянутым одному или более интерфейсам;
генерировать одно или более машиночитаемых описаний упомянутых одного или более интерфейсов, на основе, по меньшей мере частично, системы абстрактных типов и языка описания;
определять один или более бинарных контрактов, соответствующих системе абстрактных типов, причем эти один или более бинарных контрактов сконфигурированы так, что они включают в себя одно или более правил, описывающих характер поведения, связанный с по меньшей мере одним типом системы абстрактных типов, при этом упомянутые один или более бинарных контрактов содержат определения машинного уровня; и
соотносить систему абстрактных типов с одним или более конкретными языками программирования на основе, по меньшей мере частично, упомянутых одного или более бинарных контрактов.

15. Считываемый компьютером носитель данных по п. 14, при этом упомянутые машиночитаемые описания содержат по меньшей мере один файл метаданных.

16. Считываемый компьютером носитель данных по п. 14, при этом упомянутый по меньшей мере один тип системы абстрактных типов содержит указатель функции.

17. Считываемый компьютером носитель данных по п. 14, при этом упомянутые один или более интерфейсов содержат по меньшей мере один объектно-ориентированный интерфейс.

18. Считываемый компьютером носитель данных по п. 14, дополнительно содержащий команды, которые являются исполняемыми, чтобы генерировать по меньшей мере один прокси-объект связи, ассоциированный с упомянутыми одним или более интерфейсами.

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