ПРОЕЦИРОВАНИЕ СОБСТВЕННЫХ ИНТЕРФЕЙСОВ ПРИКЛАДНОГО ПРОГРАММИРОВАНИЯ ОПЕРАЦИОННОЙ СИСТЕМЫ В ДРУГИЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ Российский патент 2016 года по МПК G06F9/44 G06F9/22 

Описание патента на изобретение RU2598600C2

УРОВЕНЬ ТЕХНИКИ

[0001] Операционная система обычно обладает несколькими интерфейсами прикладного программирования, которые позволяют приложениям осуществлять доступ к функциональности, поддерживаемой операционной системой. Такие API, обычно, определяются операционной системой с использованием именованного файла или объекта на языке программирования компьютера. Например, язык программирования C использует заголовочные файлы, которые могут иметь имя, например, "interface.h". Аналогично, в C# механизм, называемый "P/Invoke", сигнатуры используется для осуществления доступа к API операционной системы. Человек, пишущий компьютерную программу, которая будет использовать API операционной системы, обычно включает ссылку на именованный файл API или объект в программу, или использует другой механизм, обеспечиваемый языком программирования. Эта программа, например, кроме того, включает в себя вызовы функций, определенных этим API, в синтаксисе, используемым этим API.

[0002] API, определенные подобным образом, не могут быть непосредственно доступны посредством языков, отличных от языков, на которых они написаны. Чтобы стать доступными программам, написанным на других языках, API «заключают в оболочку». Это «заключение в оболочку» обычно должно быть сделано вручную для каждого API и для каждого языка и требует глубокого понимания как целевого языка, так и API, и операционной системы. Следовательно, многие API операционной системы недоступны.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0003] Раздел Сущность изобретения обеспечен для представления подборки понятий в упрощенной форме, которые дополнительно описаны ниже по тексту в разделе Подробное описание. Раздел Сущность изобретения не предназначен для идентификации ключевых признаков или существенных признаков заявленного объекта, а также не предназначен для использования его для ограничения объема заявленного объекта.

[0004] Когда строится операционная система, информация о API генерируется и сохраняется в известном формате, в известном месте, в операционной системе. Эта информация полностью описывает все API, подвергающиеся действию посредством операционной системы. Это включает в себя, но не ограничено этим, информацию об именованных элементах API различных типов, таких как базовые типы, перечислимые типы, структуры, делегаты, интерфейсы, классы, методы, свойства и события. Эта информация хранится в файлах метаданных API.

[0005] Компилятор языка или интерпретатор использует эту информацию API для построения естественного и привычного представления API родной системы на целевом языке. Это представление варьируется от языка к языку (как и то, что является естественным и привычным варьируется от языка к языку). Компилятор языка или интерпретатор может считывать информацию API во время компиляции и/или во время выполнения, независимо от того, что является наиболее подходящим для рассматриваемого языка. Например, такой статически-компилируемый язык как C++ будет использовать метаданные только во время компиляции, тогда как такой динамический язык как Python или JavaScript будет использовать метаданные только во время выполнения. Среда, подобная.NET или Java, вероятно использует метаданные как во время компиляции, так и во время выполнения. Метаданные используются для того, чтобы позволить приложению обращаться к именованным элементам в API. Создаются проецирования, которые используют метаданные для отображения именованных элементов в API на именованные элементы в целевом языке и для определения средств заключения в оболочку, которые осуществляют маршалинг данных тех элементов между целевым представлением и представлением собственной операционной системы.

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

[0007] Такое проецирование API операционной системы на другие языки может быть воплощено в реализуемом компьютером процессе, готовом изделии, включающем в себя одну или более сред (носителей) хранения компьютера, или вычислительной машине.

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

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

[0009] Фиг. 1 представляет собой блок-схему системы, которая включает в себя проецирование API на другие языки программирования.

[0010] Фиг. 2 представляет собой блок-схему последовательности операций, иллюстрирующую примерную работу инструмента разработки.

[0011] Фиг. 3 представляет собой блок-схему последовательности операций, иллюстрирующую примерную работу компилятора или интерпретатора.

[0012] Фиг. 4 представляет собой блок-схему примерного вычислительного устройства, в котором такая система может быть реализована.

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

[0013] Нижеследующий раздел обеспечивает примерную операционную среду, в которой может быть реализовано такое проецирование API родной системы на другие языки.

[0014] Обращаясь к фиг. 1, выполняющееся приложение 100 осуществляет доступ к API 102 родной системы во время выполнения. Для того чтобы такое приложение обладало такой функциональностью, программа 106 обычно пишется с использованием инструмента 112 разработки, такого как редактор. Такие программы либо компилируются, либо интерпретируются компилятором или интерпретатором 108 языка, чтобы обеспечить приложение 100 среды выполнения (runtime). Инструмент 112 разработки и компилятор или интерпретатор 108 осуществляют доступ к метаданным 110, которые полностью описывают API 102 операционной системы. Инструмент 112 разработки помогает разработчику в написании программ, но информирует разработчика о доступных API родной системы посредством метаданных и делает возможным доступ к этим API с использованием языка программирования разработчика. Компилятор или интерпретатор воплощает проецирование API родной системы на язык программирования разработчика с использованием метаданных. В частности, именованные элементы в API отображаются на именованные элементы в целевом языке и осуществляется маршалинг значений в тех элементах между форматами, используемыми целевым языком и операционной системой.

[0015] Построение такой системы начинается с построения операционной системы с API, описанными с помощью метаданных. Метаданные представляют каждый именованный элемент описания API в независимой от языка программирования форме. Эти метаданные обеспечивают полное описание интерфейса. Метаданные комбинированной системы могут быть сохранены в ряде файлов метаданных в формате ECMA-335 CLI, но специфичный формат является несущественным для изобретения.

[0016] С учетом этого контекста примерная реализация такой системы будет описана более подробно на фиг. 2-4.

[0017] Сейчас будет описан пример работы инструмента разработки с фиг. 2. При написании компьютерной программы разработчик, как правило, использует такую форму инструмента разработки, как редактор. Этот редактор может выполнять разнообразные задачи, такие как проверка синтаксиса и предложение завершений для строк, вводимых разработчиком. В этой среде метаданные, описывающие интерфейсы прикладного программирования операционной системы, могут быть использованы различными способами. В частности, они могут быть использованы, чтобы позволить разработчику обнаружить доступные API. Инструмент разработки принимает 200 ввод строки, например ключевое слово, которое может быть использовано в API в качестве идентификатора (например, "мышь") или пространства имен (например, имя операционной системы). Может быть осуществлен поиск 202 метаданных для идентификации элементов, имеющих принятый ввод как часть идентификатора или пространства имен. Идентификаторы для набора соответствующих элементов могут быть собраны и возвращены 204 в инструмент разработки. Инструмент разработки может представить 206 элементы разработчику для выбора и использовать информацию из метаданных для представления таких элементов в формате, подходящем для языка компьютера, который использует разработчик.

[0018] Обращаясь теперь к фиг. 3, будет описан пример работы компилятора языка или интерпретатора. При обработке компьютерной программы вне зависимости от того, компилировать или интерпретировать ее, выявляется 300 последовательность элементов компьютерной программы. Определяется 302, является ли элемент компьютерной программы ссылкой на API операционной системы. Например, это может быть определено путем поиска элемента в метаданных. С использованием метаданных создается 304 элемент проецирования, что делает возможной передачу данных между компьютерной программой и операционной системой. В частности, компилятор или интерпретатор реализует проецирование именованного элемента в API операционной системы на именованный элемент в целевом языке. Метаданные делают возможными создание объекта и осуществление маршалинга значений между форматом данных, используемым программой, и форматом, используемым операционной системой. Во время выполнения этот элемент позволяет программе осуществить доступ 306 к API операционной системы и осуществить маршалинг данных между приложением и операционной системой.

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

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

[0021] В этом примере JavaScript является языком программирования, в который API родной системы будут проецироваться с использованием метаданных. В примерах ниже по тексту дается пояснение того, как некоторые виды элементов проецируются в язык программирования JavaScript.

[0022] Когда скрипт пытается создать экземпляр конкретного объекта, определенного посредством API операционной системы, объект Projector отвечает за доступ к метаданным для создания заглушек маршалинга, которые преобразуют данные между разными типами, возможно вовлекая создание прокси-объектов, а также для назначения вызовов методов, управления событиями и управления функциями обратного вызова.

[0023] Для именованных элементов, которые представляют собой базовые типы, такие как целочисленные переменные, строки и т.п., нижеследующее представляет собой способы проецирования таких элементов API в JavaScript.

[0024] Операционная система имеет несколько целочисленных типов со знаком и без знака, таких как целочисленная переменная без знака одного байта (UInt8), целочисленная переменная без знака четырех байтов (UInt32), целочисленная переменная со знаком четырех байтов (Int8) и целочисленная переменная со знаком и без знака восьми байтов (UInt64 и Int64). Именованные элементы этих типов проецируются в качестве значений Number JavaScript. Когда осуществляется маршалинг Number JavaScript в значение операционной системы, то эти значения приводятся по типу в число (number) JavaScript, а затем следует процесс, определенный спецификацией ES5 ToInt32. Для Uint8 результат применил модуль 2^8. Для Int32 применен модуль 2^16. Для UInt32 применен модуль 2^32.

[0025] 64-битная целочисленная переменная, маршалинг которой осуществляется в значение JavaScript, представляется как стандартное значение Number, если она попадает в диапазон [-2^53, 2^53], если со знаком, или [0,2^53], если без знака. Если она попадает за пределы этого диапазона, она представляется как значение Number со специальным резервным хранилищем, которое хранит все 64 бита целочисленных данных. Математические операции в отношении этих специальных значений Number вызывают приведение значения к стандартному представлению Number в диапазоне [-2^53, 2^53] или [0,2^53], если без знака. Если значение находится за пределами этого диапазона, будет инициирована Type Error (ошибка типа). Значение JavaScript, маршалируемое в 64-битную целочисленную переменную, непосредственно назначается, если оно само является проецируемым значением; иначе передается результат применения преобразования EC5 "ToInteger" в отношении значения.

[0026] Именованные элементы операционной системы API, которые являются символами (представленными 16-битым Юникодом), строками или глобальными уникальными идентификаторами (GUID), могут быть представлены как строки JavaScript и спроецированы в именованные строки на JavaScript.

[0027] Символ, маршалируемый в JavaScript, преобразовывается в значение строки JavaScript, содержащее единственный символ, представленный юникод-значением. Значение JavaScript, маршалируемое в символ, приводится по типу в строку JavaScript посредством операции ES5 ToString и сохраняется первый символ. Один символ затем передается в качестве значения Char16.

[0028] Строка, маршалируемая в JavaScript, преобразуется в String JavaScript. Значение JavaScript, маршалируемое в строку, приводится по типу в строку JavaScript.

[0029] GUID, маршалируемый в значение JavaScript, преобразовывается в формат строки. Значение JavaScript, маршалируемое в GUID, приводится по типу в строку, а затем интерпретируется в формат, используемый операционной системой.

[0030] Операционная система может иметь API с именованным элементом, который является структурой DateTime, которая представляет момент во времени, или структурой TimeSpan, которая представляет количество времени. Структура DateTime может быть спроецирована в JavaScript в качестве экземпляра Date с резервным хранилищем, соответствующим данным структуры DateTime (которая имеет диапазон и точность, отличные от экземпляра Date). Структура TimeSpan преобразуется в миллисекунды и возвращается в качестве Number JavaScript. Аналогичным образом число JavaScript может быть преобразовано из миллисекунд в единицы 100-наносекунд для передачи в качестве структуры TimeSpan.

[0031] Следует отметить, что посредством интерпретации метаданных проецирование также может перераспределить типы из родной среды в существующие типы в проецировании языка в некоторых случаях. Например, это возможно и желательно, когда типы в проецированиях языков и родного API имеют совместимую структуру данных, которая может легко происходить с фундаментальными типами данных. С помощью отображения метаданных, проецирование может просто перенаправлять все операции, такие как методы или свойства в отношении языковых типов, непосредственно в собственные типы. Это делает использование этих типов более естественным и привычным для разработчиков языков. Например, перераспределение структуры DateTime может быть реализовано таким образом. В родном API структура DateTime подвергается воздействию как Windows.Foundation.DateTime в метаданных без каких-либо дополнительных операций. В проецировании С# этот тип может быть перенаправлен в System.DateTimeOffset в C# с богатой поддержкой.

[0032] В качестве другого примера, если именованный элемент в API является методом, он имеет значение HRESULT в качестве его возвращаемого типа, которое преобразуется в исключения в JavaScript. Возвращенный HRESULT проверяется на исправность движком JavaScript. Если HRESULT указывает отказ, движок JavaScript выдает исключение на стороне JavaScript. Таким образом, для методов вызова JavaScript операционной системы API отказ HRESULT покрывается как Exception JavaScript. Для методов API, использующих методы JavaScript (например для обратных вызовов или делегатов, описанных ниже по тексту), вызов метода JavaScript заключается в оболочку в блоке исключения (или эквиваленте, как обеспечено посредством размещающего JavaScript (интерфейса) API), так что охваченные исключения могут быть распространены в качестве HRESULT. Однако операционная система также позволяет HRESULT находиться в или вне позиций параметров методов и свойств. В этих случаях HRESULT маршалируются как 32-битное значение без знака (как описано выше по тексту).

[0033] В отношении именованных элементов в API, которые представляют собой перечислимые типы, который представляет собой набор именованных констант, они представлены в JavaScript в качестве объекта, который содержит поле только для чтения для каждого именованного значения.

[0034] В отношении именованных элементов в API, которые представляют собой "структуры" (structs), совокупность именованных полей данных, они представлены в JavaScript как объекты JavaScript. Struct, маршалируемая в JavaScript, преобразовывается в объект. Каждое именованное поле в структуре становится именованным свойством в объекте JavaScript. Значение каждого именованного поля в структуре маршалируется в расчете на каждый базовый тип поля. Value (значение) JavaScript, которое представляет собой тип объекта, может быть маршалировано в Struct (структуру). Object (объект) JavaScript или его прототип содержит именованное поле для каждого именованного поля структуры и значение каждого именованного поля маршалируется согласно базовому типу. Дополнительные поля в Object JavaScript, которые не имеют эквивалента в структуре API операционной системы, игнорируются. Если маршалинг какого-либо значения структуры дает отказ, возвращается ошибка маршалинга.

[0035] В этом примере операционная система не имеет типа для массива, но вместо этого позволяет аргументам для методов быть парой длины целочисленной переменной без знака, представляющей некоторое число элементов, не байтов, в массиве, за которой следует указатель на первый элемент массива.

[0036] При маршалинге массива в JavaScript объект создается со следующими характеристиками. Объект имеет свойства для каждого целочисленного значения между 0 и длиной массива минус 1, которые являются перечислимыми, поддающимися записи и не конфигурируемыми, а свойство 'длины' изначально устанавливается в длину вектора, который является не поддающимся записи, не перечислимым, а также не конфигурируемым. Его прототипом является объект прототипа Array (массива). Его операция [[Put]] в отношении свойств индекса устанавливает точно определенный индекс в отношении к опорному собственному массиву. Его операции [[GetOwnProperty]] в отношении свойств индекса индексируются в опорный собственный массив. Он не имеет [[Class]] в качестве "Array". При маршалинге объекта JavaScript, если объект имеет [[Class]] "Array", то массив копируется в собственный массив и передается ссылка на этот массив. Если объект был проецируемым массивом, то передается опорный собственный массив.

[0037] Также API может иметь именованные элементы, которые являются делегатами или функциями обратного вызова, что является ссылкой на один метод с возможностью вызова. Они могут быть спроецированы в JavaScript как вызываемые объекты. Projector (средство проецирования) заключает в оболочку делегата обратного вызова в объект специализированного маршалинга.

[0038] Делегат маршалируется в JavaScript, заключается в оболочку в объект-функцию JavaScript. Когда вызывается объект-функция, аргументы маршалируются в эквивалентные типы параметров, как точно определено делегатом и после вызывается заключенный в оболочку объект делегат. Если какой-либо аргумент не удается маршалировать, то вызов делегата не удается. Если есть меньше аргументов JavaScript, чем делегат в параметрах, то вызов делегата не удается. Дополнительные аргументы JavaScript за пределами делегата в параметрах игнорируются. После вызова делегата выходные параметры маршалируются в типы JavaScript. Если не удается маршалировать какой-либо выходной параметр, то вызов делегата не удается. Выходные параметры затем маршалируются в значения JavaScript и возвращаются.

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

[0040] Нижеследующий пример иллюстрирует метаданные для делегата, именованного IString Collection, и псевдо-JavaScript код, который создает экземпляр этого делегата.

[0041] Пример метаданных:

[uuid(...)]

delegate HRESULT Comparer([in] HSTRING s1, [in] HSTRING s2,

[out, retval] boolean* value)

interface IStringCollection

{

HRESULT Sort([in] Comparer compare);

}

[0042]

[0043] Pseudo-JavaScript:

//создать экземпляр класса, который реализует IStringCollection

strCol=getIStringCollection()

strCol.sort(function (s1, s2) { return s1>s2; });

[0044] Интерфейсы не проецируются непосредственно в JavaScript в качестве объектов. Однако интерфейсы могут быть параметром и возвращаемыми типами методов API операционной системы.

[0045] Для обеспечения проецирования, которое является естественным на целевом языке программирования, в вышеприведенных примерах, члены проецируются в JavaScript с измененными их именами на camelCase, следуя строгой договоренности в JavaScript использовать имена camelCase для членов. Типы, которые родственны с функциями конструктора JavaScript, обычно являются PascalCased и проецируются в этой форме. Точно так же enum-свойства, поля структуры, имена событий для шаблона addEventListener имеют имена в CamelCase.

[0046] Экземпляр интерфейса, который не является известным, базируется на информации статистического типа, которая должна быть представлением класса среды выполнения (“runtime”), будучи маршалируемым в JavaScript, проходит через следующие этапы. Во-первых, вызов к интерфейсу производится для получения имени класса среды выполнения для интерфейса. В случае успеха объект проецируется в качестве объекта экземпляра класса среды выполнения (см. ниже по тексту). В противном случае объект проецируется, как если бы он был экземпляром не являющегося именованным класса среды выполнения, который точно реализует интерфейс, который, как известно, реализует и свои транзитивно требуемые интерфейсы.

[0047] Значение JavaScript, маршалируемое в некоторый тип интерфейса, проверяется, чтобы выяснить, является ли оно проецируемым объектом-экземпляром класса среды выполнения или проецируемым объектом-экземпляром интерфейса. Если оно является объектом класса среды выполнения, и исходное значение, которое представляет этот объект, реализует некоторый тип интерфейса, то реализация объектов этого интерфейса передается операционной системе. В противном случае вызывается исключение ошибки типа.

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

[0049] Таким образом, объекты API операционной системы проецируются в JavaScript в качестве объектов. Объединение методов, свойств и событий, определенных на всех реализованных интерфейсах класса, представляет члены типа, которые подвергаются воздействию в качестве именованных свойств, доступных на проецируемом объекте JavaScript, с помощью своего прототипа. Потребители проецирования языка JavaScript могут осуществить доступ к любому члену класса непосредственно, не заботясь о том, в отношении какого интерфейса фактически определен метод.

[0050] Объекты JavaScript являются динамическими, что означает, что новые свойства могут быть добавлены или удалены в отношении объектов в любое время. Проецируемые объекты могут поддерживать добавление новых свойств и методов, пока предварительно определенные члены интерфейса не переопределены или удалены. В терминах JavaScript проецируемые объекты являются расширяемыми, но совокупность элементов именованных типов не является конфигурируемой. Проецируемые объекты обладают прототипом с членами экземпляра, определенными в отношении совокупности членов из реализуемых классом среды выполнения интерфейсов.

[0051] Такие интерфейсы, как отмечено выше по тексту, обладают методами, параметрами и событиями.

[0052] Методы на уровне проецирования языка реализуются как vtable со слотом для каждого метода. Метаданные об интерфейсе обеспечивают имя метода, а также имена, типы и направление (входа/выхода) параметров. Методы проецируются в JavaScript в качестве вызываемых свойств в отношении проецируемого объекта интерфейса или среды выполнения. Этими свойствами являются {Writable=false, Enumerable=true, Configurable=false} (“false”-ложь, “true”-истина). При вызове аргументы маршалируются в соответствии с их соответствующими типами параметров, метод вызывается с помощью этих значений. Возвращаемое значение(я) маршалируются в значение JavaScript с объектом JavaScript, возвращаемым в качестве значения.

[0053] Свойства на уровне проецирования языка реализуются как методы get (получения) и/или set (присвоения). Доступ к значению свойства вызывает метод get, тогда как обновление значения свойства инициирует метод set. Свойства могут быть считаны или записаны (то есть доступны методы set и get) или только считаны (то есть доступен только метод get). Свойства проецируются в JavaScript в качестве свойств. Маршалирование значения свойства работает, как описано выше по тексту в зависимости от базового типа свойства.

[0054] События на уровне проецирования языка реализуются в качестве методов прослушивателя событий add (добавления) и remove (удаления). Метод add принимает экземпляр делегата и возвращает данные, описывающие прослушивателя, в то время как метод remove принимает данные, описывающие прослушивателя, и ничего не возвращает.

[0055] В JavaScript любой проецируемый объект интерфейса или класса среды выполнения, который обладает по меньшей мере одним событием, проецируемым на него, получает два дополнительных свойства, добавляемых к его прототипу, addEventListener и removeEventListener. Эти свойства являются {Writable: false, Enumerable: true, Configurable: false} и назначаются, чтобы быть вызываемыми объектами.

[0056] Функция addEventListener принимает аргумент строки, который представляет имя события для прослушивания, функцию обратного вызова для назначения в качестве прослушивателя и необязательный третий параметр, который игнорируется. Эта функция вызывает базовый метод add_Event, передавая маршалируемую функцию обратного вызова в качестве делегата, и сохраняет получившийся в результате токен в сопоставлении, закрепленном посредством ссылочной идентификации объекта функции обратного вызова.

[0057] Функция RemoveEventListener принимает аргумент строки, который представляет имя события, от которого необходимо удалить прослушивателя, функцию обратного вызова, которая должна быть удалена, и необязательный третий параметр, который игнорируется. Эта функция ищет функцию обратного вызова посредством ссылочной идентификации в сопоставлении сохраненных токенов, и если токен найден, вызывает базовый метод remove_Event, передавая извлекаемый токен.

[0058] Когда событие произошло, любые объекты-функции JavaScript, передаваемые в качестве обратных вызовов, будут вызваны. Аргументы, передаваемые к объекту-функции, будут маршалируемыми значениями аргументов, обеспеченных делегату EventHandler.

[0059] Как показано выше по тексту, имея уровень Projection (проецирования) API для языка, именованные элементы API операционной системы, как точно определены метаданными, хранящимися в операционной системе, могут быть использованы для автоматического создания объектов и данных маршалинга между форматом API операционной системы и форматом языка прикладного программирования. Следует понимать, что приведенное выше по тексту является лишь примером проецирования между примерной операционной системой и примерным языком программирования, и что изобретение не ограничено этим примером.

[0060] Теперь описав пример реализации, будет описана вычислительная среда, в которой такая система выполнена с возможностью работы. Нижеследующее описание предназначено для обеспечения краткого, общего описания подходящей вычислительной среды, в которой эта система может быть реализована. Система может быть реализована с многочисленными конфигурациями вычислительного аппаратного обеспечения специального назначения или общего назначения. Примеры хорошо известных вычислительных устройств, которые могут быть пригодны, включают в себя, но не ограничены упомянутым, персональные компьютеры, компьютеры-серверы, карманные или портативные устройства (например, мультимедийные проигрыватели, компьютеры-ноутбуки, сотовые телефоны, карманные персональные компьютеры, диктофоны), многопроцессорные системы, основанные на микропроцессоре системы, телевизионные приставки, игровые консоли, программируемую бытовую электронику, сетевые ПК, суперкомпьютеры, среды распределенных вычислений, которые включают в себя любые из вышеперечисленных систем или устройств и т.п.

[0061] Фиг. 4 иллюстрирует пример подходящей среды вычислительной системы. Среда вычислительной системы является лишь одним примером подходящей вычислительной среды и не предназначена для введения какого-либо ограничения как на объем использования, так и на функциональность такой вычислительной среды. Не следует интерпретировать вычислительную среду как обладающую какой-либо зависимостью или требованием, относящимся к любой комбинации компонентов, проиллюстрированных в примерной операционной среде.

[0062] Со ссылкой на фиг. 4, пример вычислительной среды включает в себя вычислительную машину, такую как вычислительная машина 400. В своей самой базовой конфигурации вычислительная машина 400, как правило, включает в себя по меньшей мере один блок 402 обработки и память 404. Вычислительное устройство может включать в себя многочисленные блоки обработки и/или дополнительные блоки совместной обработки, такие как блок 420 обработки графики. В зависимости от точной конфигурации и типа вычислительного устройства, память 404 может быть энергозависимой (такой как ОЗУ), энергонезависимой (такой как ПЗУ, флэш-память и т.д.) или некоторой комбинацией двух упомянутых. Эта наиболее общая конфигурация проиллюстрирована на фиг. 4 пунктирной линией 406. Дополнительно вычислительная машина 400 также может обладать дополнительными особенностями/функциональностью. Например, вычислительная машина 400 также может включать в себя дополнительное средство хранения (съемное и/или несъемное), включающее в себя, но не ограничиваясь этим, магнитные или оптические диски или ленту. Такое дополнительное средство хранения проиллюстрировано на фиг. 4 съемным средством 408 хранения и несъемным средством 410 хранения. Носители данных компьютера включают в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для сохранения информации, такой как инструкции компьютерной программы, структуры данных, программные модули или другие данные. Память 404, съемное средство 408 хранения и несъемное средство 410 хранения все являются примерами носителей данных компьютера. Носители данных компьютера включают в себя, но не ограничиваются ими, ОЗУ, ПЗУ, EEPROM, флэш-память или другую технологию памяти, CD-ROM, цифровые универсальные диски (DVD) или другое оптическое средство хранения, магнитные кассеты, магнитную ленту, средство хранения на магнитном диске или другие магнитные устройства хранения, или любой другой носитель, который может быть использован для хранения требуемой информации и к которому может быть осуществлен доступ посредством вычислительного устройства 400. Любые носители данных компьютера могут быть частью вычислительной машины 400.

[0063] Вычислительная машина 400 также может содержать соединение(я) 412 связи, которое позволяет устройству осуществлять связь с другими устройствами. Соединение(я) 412 связи является примером сред связи. Среды связи, как правило, переносят инструкции компьютерной программы, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как несущая волна или другой механизм транспортировки, и включает в себя любые среды доставки информации. Термин «модулированный сигнал данных» означает сигнал, который имеет одну или более из его характеристик, установленных или измененных таким образом, чтобы кодировать информацию в сигнале, тем самым изменяя конфигурацию или состояние приемного устройства сигнала. Посредством примера, а не ограничения, среды связи включают в себя проводные среды, такие как проводная сеть или прямое проводное соединение, и беспроводные среды, такие как акустические, радиочастотные, инфракрасные и другие беспроводные среды.

[0064] Вычислительная машина 400 может иметь различные устройства(о) 414 ввода, такие как устройство отображения, клавиатура, мышь, перо, камера, устройство (сенсорного) ввода касанием и так далее. Устройство(а) 416 вывода, такие как громкоговорители, принтер и так далее, также могут быть включены в состав. Все эти устройства хорошо известны в данной области и нет необходимости обсуждать их подробно в этом документе.

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

[0066] Термины "готовое изделие", "процесс", "машина" и "состав вещества" в родовых понятиях приложенных пунктов формулы изобретения предназначены для ограничения этих пунктов объектом, подразумеваемым в рамках объема патентоспособного объекта, определенного посредством использования этих терминов в 35 U.S.C. §101.

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

Похожие патенты RU2598600C2

название год авторы номер документа
СИСТЕМА СРЕДЫ ВЫПОЛНЕНИЯ 2011
  • Ректор Брент Е.
  • Омия Эллиот Х.
  • Дунец Джерри Дж.
  • Лоувелл Мартин С.
  • Холечек Алеш
  • Пракрия Махеш
  • Роу Стефен К.
  • Спрингфилд Джеймс Ф.
  • Кросс Ноэль Р.
  • Басу Тассадук Х.
  • Дассад Патрик Х.
  • Кришнасвами Раджа
  • Лукко Стивен Эдвард
RU2601198C2
ИНТЕРФЕЙС ПРОГРАММИРОВАНИЯ ДЛЯ КОМПЬЮТЕРНОЙ ПЛАТФОРМЫ 2004
  • Богдан Джеффри Л.
  • Релая Роберт А.
RU2371758C2
ИНТЕРФЕЙС ПРОГРАММИРОВАНИЯ ДЛЯ КОМПЬЮТЕРНОЙ ПЛАТФОРМЫ 2004
  • Гузак Крис Дж.
  • Каратал Керем Б.
  • Миллер Марк М.
  • Шелдон Майкл Г.
  • Макки Тимоти П.
RU2365972C2
ИНТЕРФЕЙС ПРОГРАММИРОВАНИЯ ДЛЯ КОМПЬЮТЕРНОЙ ПЛАТФОРМЫ 2004
  • Богдан Джеффри Л.
  • Релая Роберт А.
RU2365978C2
ПРОГРАММНЫЙ ИНТЕРФЕЙС ДЛЯ ЛИЦЕНЗИРОВАНИЯ 2004
  • Гуниакти Каглар
  • Чжан Нинг
  • Хсу Вен-Пин Скотт
RU2377634C2
ИНТЕГРИРОВАНИЕ УЧРЕЖДЕНЧЕСКИХ ПОИСКОВЫХ СИСТЕМ СО СПЕЦИАЛЬНЫМИ ИНТЕРФЕЙСАМИ ПРИКЛАДНОГО ПРОГРАММИРОВАНИЯ УПРАВЛЕНИЯ ДОСТУПОМ 2008
  • Кападиа Аршиш Сайрус
  • Берк Джоуна Сарбин
RU2446456C2
СИСТЕМА И СПОСОБ ПРОЕЦИРОВАНИЯ ДАННЫХ ОТ ОДНОГО КО МНОГИМ 2004
  • Гупта Рохит
  • Манион Тодд Р.
RU2412478C2
УПРАВЛЕНИЕ ДОСТУПОМ ВО ВРЕМЯ ВЫПОЛНЕНИЯ К ИНТЕРФЕЙСАМ ПРИКЛАДНОГО ПРОГРАММИРОВАНИЯ 2014
  • Трофин Мирча
  • Дассад Патрик
  • Мартин Руди
  • Хэмби Джон Лоренс
  • Стреховски Михал
  • Райтон Дэвид Чарльз
  • Канамори Ацуси
  • Ханна Фади М.
RU2658190C2
ПРОГРАММНЫЙ ИНТЕРФЕЙС, СВЯЗАННЫЙ С БЕЗОПАСНОСТЬЮ 2004
  • Таунсенд Стефен В.
  • Фэйкс Томас Ф.
RU2377639C2
ИНТЕРФЕЙСЫ ДЛЯ ПРИКЛАДНОГО ПРОГРАММИРОВАНИЯ ДЛЯ КУРИРОВАНИЯ КОНТЕНТА 2014
  • Григорович Александр В.
  • Литтл Роберт А.
RU2666302C2

Иллюстрации к изобретению RU 2 598 600 C2

Реферат патента 2016 года ПРОЕЦИРОВАНИЕ СОБСТВЕННЫХ ИНТЕРФЕЙСОВ ПРИКЛАДНОГО ПРОГРАММИРОВАНИЯ ОПЕРАЦИОННОЙ СИСТЕМЫ В ДРУГИЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ

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

Формула изобретения RU 2 598 600 C2

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

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

3. Реализуемый компьютером способ по п. 1, в котором создание элемента проецирования содержит при интерпретации программы создание кода, который определяет один или более элементов проецирования.

4. Реализуемый компьютером способ по п. 1, в котором элемент проецирования содержит интерфейс, включающий в себя методы, свойства и события.

5. Реализуемый компьютером способ по п. 1, в котором элемент проецирования распространяет исключения из операционной системы в приложение.

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

7. Носитель по п. 6, при этом создание элемента проецирования содержит во время компилирования создание кода, который определяет один или более элементов проецирования.

8. Носитель по п. 6, при этом создание элемента проецирования содержит при интерпретации программы создание кода, который определяет один или более элементов проецирования.

9. Носитель по п. 6, при этом элемент проецирования содержит интерфейс, включающий в себя методы, свойства и события.

10. Носитель по п. 6, при этом элемент проецирования распространяет исключения из операционной системы в приложение.

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

12. Вычислительная машина по п. 11, при этом создание элемента проецирования содержит во время компилирования создание кода, который определяет один или более элементов проецирования.

13. Вычислительная машина по п. 11, при этом создание элемента проецирования содержит при интерпретации программы создание кода, который определяет один или более элементов проецирования.

14. Вычислительная машина по п. 11, при этом элемент проецирования содержит интерфейс, включающий в себя методы, свойства и события.

15. Вычислительная машина по п. 11, при этом элемент проецирования распространяет исключения из операционной системы в приложение.

Документы, цитированные в отчете о поиске Патент 2016 года RU2598600C2

EP 1845444 B1, 19.05.2010
Колосоуборка 1923
  • Беляков И.Д.
SU2009A1
Колосоуборка 1923
  • Беляков И.Д.
SU2009A1
Способ приготовления лака 1924
  • Петров Г.С.
SU2011A1
МОДЕЛЬ И АРХИТЕКТУРА УПРАВЛЯЕМЫХ ФИЛЬТРОВ ФАЙЛОВОЙ СИСТЕМЫ 2003
  • Пудипедди Рависанкар
  • Браун Эйлин К.
  • Кристьянсен Нил
  • Тинд Равиндер
  • Дивей Брайан К.
  • Гоулдс Дэвид П.
  • Збиковски Марк Дж.
RU2335796C2

RU 2 598 600 C2

Авторы

Пирсон Харольд

Ректор Брент

Лоувелл Мартин

Пракрия Махеш

Роу Стефен

Басу Тассадук

Влодарчик Роберт А.

Омия Эллиот Х.

Дунец Джерри

Холечек Алеш

Остерман Лоуренс В.

Цзэн Вэй

Вадхва Неерай

Солкар Шакил

Аксионкин Майкл

Даты

2016-09-27Публикация

2011-10-11Подача