СИСТЕМЫ И СПОСОБЫ УПРАВЛЕНИЯ ДРАЙВЕРАМИ В ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЕ Российский патент 2007 года по МПК G06F19/00 

Область применения изобретения

Настоящее изобретение относится к системам и способам управления драйверами в вычислительной системе.

Предшествующий уровень техники

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

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

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

Приложения, драйверы и пр. обычно пишут на языке высокого уровня, например, «С». Для реализации таких языков используют, в основном, компиляцию в собственный код. При этом драйверы прописывают отдельно от приложений и других программ, работающих на системе. Затем приложения и драйверы обычно компонуют друг с другом либо в процессе инсталляции, либо динамически (например, DLL) при выполнении приложения. Преимущество такой системы состоит в том, что можно создать компилятор, оптимизирующий код для конкретного класса процессоров (например, Х86). Однако компилятор может не оптимизировать код для конкретного микропроцессора, например, PENTIUM IV в отличие от PENTIUM III. Кроме того, компилятор не оптимизирует код для других параметров системы, включая версии драйвера, и других аппаратных компонентов или учитывает конкретные системные ограничения системы назначения. В результате система уровня приложений или рабочей среды должна применять логику высокой вычислительной мощности для определения таких параметров и ограничений процессора, чтобы скомпилировать программу так, чтобы она могла выполняться на целом классе компьютерных систем.

Другая общеизвестная парадигма программирования заключается в компилировании кодов во время выполнения. Примером такой системы является оперативный компилятор (JIT). Другие системы, компилирующие во время выполнения, включают в себя системы непрерывной компиляции, которые в режиме интерпретации немедленно начинают выполнение, но компилируют код в течение времени и непрерывно оптимизируют компиляцию. При использовании оперативных компиляторов по мере загрузки классов в виртуальную машину указатели метода в виртуальной таблице методов заменяются указателями на оперативный компилятор. Затем при первом вызове каждого метода для компиляции метода происходит обращение к JIT (оперативному) компилятору. После этого указатель из виртуальной таблицы методов вставляют для указания версии собственного кода для данного метода, что позволяет при дальнейших обращениях к методу осуществлять переход к собственному коду. Преимущество таких систем оперативной компиляции состоит в том, что машина назначения получает код на промежуточном языке (ПЯ), например, в виде байт-кодов JAVA, команд CLRT и т.п. Компилятор предназначен для преобразования ПЯ в команды, выполняемые центральным процессором. В результате одни и те же команды ПЯ можно посылать на компьютеры с разными центральными процессорами и выполнять их независимо от процессора назначения.

Хотя такие компиляторы промежуточного языка компилируют команды промежуточного языка на компьютерной системе назначения, они также не оптимизируют код для конкретной компьютерной системы назначения с учетом версий драйверов и других аппаратных компонентов.

Сущность изобретения

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

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

Краткое описание чертежей

Система и способы управления кодом описаны далее со ссылкой на прилагаемые чертежи, в которых:

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

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

фиг.3А и 3В - различные модели драйвера для разных вычислительных систем;

фиг.4 - блок-схема компьютерной системы, имеющей архитектуру драйвера пользовательского режима в виде DLL, согласно аспекту изобретения;

фиг.5 - схема последовательности событий, происходящих, когда приложение осуществляет вызовы API, на примере графического приложения;

фиг.6 - схема применения JIT компиляции к приложению и рабочей среде согласно аспекту изобретения;

фиг.7 - схема применения оперативной (JIT) компиляции к приложению, драйверу и рабочей среде согласно аспекту изобретения.

Подробное описание изобретения

Обзор

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

Описанное здесь изобретение предусматривает, что управляемый код, включая приложения, рабочую среду и драйвер, должен заранее располагать информацией о точной конфигурации оборудования клиента, подобно тому, как оперативному JIT-компилятору заранее известен тип микропроцессора на клиенте. Например, в ходе динамической компиляции системе известна эффективная версия графического драйвера (DirectX 6.0, DirectX 7.0 и т.п.), и если приложение или драйвер являются управляемыми, то оперативный (JIT) компилятор может эмитировать выполняемый код, настроенный на конкретную версию драйвера.

Иллюстративные сетевые и распределенные среды

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

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

На фиг.1 представлена схема иллюстративной сетевой или распределенной вычислительной среды. Распределенная вычислительная среда содержит вычислительные объекты 10а, 10b и т.д. и вычислительные объекты или устройства 110а, 110b, 110с и т.д. Эти объекты могут содержать программы, методы, запоминающие устройства, программируемую логику (логические устройства) и пр. Объекты могут содержать фрагменты одинаковых или разных устройств, например, PDA (персональный электронный секретарь), телевизоров, проигрывателей записей в формате МР3, телевизоров, персональных компьютеров и т.п. Каждый объект может связываться с другим объектом посредством сети связи 14. Эта сеть может сама содержать другие вычислительные объекты и вычислительные устройства, предоставляющие услуги системе, изображенной на фиг.1. Согласно аспекту изобретения каждый объект 10 или 110 может содержать данные, для которых было бы желательно осуществлять очерчивание или задание границ изображения. Может также оказаться желательным сравнивать очертание изображения из одного объекта 10 или 110 с очертанием изображения другого объекта 10 или 110.

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

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

Очевидно, что объект, например, 110с, может размещаться на другом вычислительном устройстве 10 или 110. Таким образом, хотя в изображенной физической среде соединенные устройства показаны в виде компьютеров, такая схема является всего лишь иллюстрацией, и альтернативно можно изображать или описывать физическую среду, содержащую различные цифровые устройства, например, PDA, телевизоры, проигрыватели МР3 и пр., программные объекты, например интерфейсы, объекты СОМ (модели составных объектов в Windows) и т.п.

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

Под сетью Интернет обычно понимают совокупность сетей и шлюзов, которые используют стек протоколов TCP/IP, широко распространенных в технике компьютерных сетей. Название TCP/IP- это акроним выражения «Transport Control Protocol/ Interface Program» (протокол управления передачей/ протокол интерфейса). Интернет можно описать как систему географически распределенных удаленных компьютерных сетей, соединенных между собой компьютерами, выполняющими сетевые протоколы, которые позволяют пользователям взаимодействовать и совместно использовать информацию по сетям. Благодаря такому широко распространенному совместному использованию информации удаленные сети, например Интернет, в целом, эволюционировали в открытую систему, для которой разработчики могут создавать программные приложения для осуществления специализированных операций или услуг, практически без ограничения.

Таким образом, сетевая инфраструктура обеспечивает разнообразные сетевые топологии, например, типа клиент-сервер, соединения равноправных узлов или архитектуры смешанного типа. «Клиент» - это элемент класса или группы, который пользуется услугами другого(й) класса или группы, к которому(й) не относится. Таким образом, в вычислении клиент - это процесс, т.е., грубо говоря, набор команд или заданий, который запрашивает услугу, обеспечиваемую другой программой. Чтобы воспользоваться запрашиваемой услугой, процессу-клиенту не требуется «знать», как работает другая программа или сами услуги. В архитектуре клиент-сервер, в частности, в сетевой системе клиент обычно представляет собой компьютер, который обращается к совместно используемым сетевым ресурсам, обеспечиваемым другим компьютером, например, сервером. В примере, представленном на фиг.1, компьютеры 110а, 110b и т.д. можно рассматривать как клиенты, а компьютеры 10а, 10b и т.д. можно рассматривать как серверы, причем сервер 10а, 10b и т.д. поддерживает данные, которые затем дублируются на компьютерах-клиентах 110а, 110b и т.д.

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

Клиент и сервер связываются друг с другом с использованием функций, обеспечиваемых на уровне протоколов. Например, во Всемирной паутине (WWW) или просто «паутине» широко используется протокол передачи гипертекстовых файлов (HTTP). Для идентификации компьютеров-серверов или компьютеров-клиентов по отношению друг к другу используется обычно адрес компьютерной сети, например, универсальный указатель ресурсов (URL) или адрес Интернет-протокола (IP). Под сетевым адресом можно понимать адрес универсального указателя ресурсов. Связь можно обеспечивать, например, посредством среды связи. В частности, для обеспечения высокой пропускной способности линии связи клиент и сервер можно подключать друг к другу посредством соединений TCP/IP.

Таким образом, на фиг.1 показана иллюстративная сетевая или распределенная среда, отвечающая настоящему изобретению, в которой сервер поддерживает связь с компьютерами-клиентами через сеть/шину. В частности, несколько серверов 10а, 10b и т.д. соединены через сеть связи /шину 14, которая может представлять собой ЛВС, ГС, интранет, Интернет и т.п., с несколькими клиентами или удаленными вычислительными устройствами 110а, 110b, 110с, 110d, 110е и т.д., например, портативным компьютером, карманным компьютером, «тонким» клиентом, сетевым оборудованием или иным устройством, например, видеомагнитофоном, телевизором, печкой, осветительным прибором, нагревателем и т.п. в соответствии с настоящим изобретением. Предусматривается, что настоящее изобретение применимо к любому вычислительному устройству, в связи с которым желательно связываться с другим вычислительным устройством в отношении услуг очерчивания изображения или задания границ.

В сетевой среде, в которой сеть связи /шина 14 представляет собой, например, Интернет, серверы 10 могут являться веб-серверами, с которыми клиенты 110а, 110b, 110с, 110d, 110е и т.д. связываются посредством любого из нескольких известных протоколов, например, протокола передачи гипертекстовых файлов (HTTP). Серверы 10 могут также выступать в качестве клиентов 110, что может быть характерным для распределенной вычислительной среды. Каналы связи могут быть проводными или беспроводными по мере необходимости. Устройства-клиенты 110 могут осуществлять или не осуществлять связь через сеть связи /шину 14 и могут иметь собственные независимые каналы связи. Например, в случае телевизора или видеомагнитофона для управления ими можно применять или не применять сетевой аспект. Каждый компьютер-клиент 110 или компьютер-сервер 10 можно снабдить различными прикладными программными модулями или объектами 135 и соединениями или доступом к различным типам запоминающих элементов или объектов, в которых можно хранить файлы или в которые можно загружать или перемещать фрагмент(ы) файлов. Любой компьютер 10а, 10b, 110а, 110b и т.д. может отвечать за поддержку и обновление базы данных 20 или другого запоминающего элемента в соответствии с настоящим изобретением, например, базы данных для хранения программного обеспечения обработки изображений для обработки изображений в соответствии с настоящим изобретением. Таким образом, настоящее изобретение можно применять в среде компьютерной сети, содержащей компьютеры-клиенты 110а, 110b и т.д., которые могут иметь доступ и взаимодействовать с компьютерной сетью/ шиной 14, и компьютеры-серверы 10а, 10b и т.д., которые могут взаимодействовать с компьютерами-клиентами 110а, 110b и т.д. и другими устройствами 111 и базами данных 20.

Иллюстративное вычислительное устройство

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

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

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

Согласно фиг.2 иллюстративная система для реализации изобретения включает в себя вычислительное устройство общего назначения в виде компьютера 110. Компоненты компьютера 110 могут включать в себя, но не только, обрабатывающий блок 120, системную память 130 и системную шину 121, которая подключает различные компоненты системы, в том числе системную память к обрабатывающему блоку 120. Системная шина 121 может относиться к любому из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, использующих любую из разнообразных шинных архитектур. Например, но не исключительно, такие архитектуры включают в себя шину, соответствующую промышленному стандарту архитектуры (ISA), шину, соответствующую стандарту микроканальной архитектуры (МСА), шину, соответствующую расширенному ISA (EISA), локальную шину, соответствующую стандарту Ассоциации по стандартам в области видеоэлектроники (VESA), и шину, соответствующую стандарту подключения периферийных компонентов (PCI) (именуемую также шиной расширения).

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

Системная память 130 включает в себя компьютерные носители для хранения данных в виде энергозависимой и энергонезависимой памяти, например, постоянного запоминающего устройства (ПЗУ) 131 и оперативного запоминающего устройства (ОЗУ) 132. Базовая система ввода/вывода (BIOS) 133, содержащая базовые процедуры, обеспечивающие перенос информации между элементами компьютера 110, например, при запуске, обычно хранится в ПЗУ 131. В ОЗУ 132 обычно хранятся данные и программные модули, подлежащие быстрому доступу со стороны обрабатывающего модуля 120 или обрабатываемые им в данный момент. Для примера, но не для ограничения общности, на фиг.2 показаны операционная система 134, прикладные программы 135, другие программные модули 136 и программные данные 137.

Компьютер 110 может также содержать другие сменные/стационарные, энергозависимые/энергонезависимые компьютерные носители для хранения данных. Исключительно для примера на фиг.2 показан жесткий диск 141 (привод жесткого диска), который позволяет считывать информацию со стационарного энергонезависимого магнитного носителя и записывать информацию на него, дисковод 151 для дискет, который считывает информацию со сменного энергонезависимого магнитного диска 152 или записывает информацию на него, и дисковод 155 для оптических дисков, который считывает информацию со сменного энергонезависимого оптического диска 156, например, CD-ROM или иного оптического носителя, или записывает информацию на него. В иллюстративной операционной среде можно также использовать другие сменные/стационарные, энергозависимые/энергонезависимые компьютерные носители для хранения данных, например, кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, ленту для цифровой видеозаписи, ОЗУ на кристаллах, ПЗУ на кристаллах и т.д. Жесткий диск 141, как правило, подключен к системной шине 121 через интерфейс запоминающего устройства со стационарным носителем, например, интерфейс 140, а дисковод 151 для дискет и дисковод 155 для оптических дисков, как правило, подключены к системной шине 121 через интерфейс запоминающего устройства со сменным носителем, например, интерфейс 150.

Вышеупомянутые и изображенные на фиг.2 приводы и соответствующие компьютерные носители для хранения данных обеспечивают хранение компьютерно-считываемых команд, структур данных, программных модулей и других данных для компьютера 110. Например, согласно фиг.2, на жестком диске 141 хранится операционная система 144, прикладные программы 145, другие программные модули 146 и программные данные 147. Заметим, что эти компоненты могут быть идентичны операционной системе 134, прикладным программам 135, другим программным модулям 136 и программным данным 137 или отличны от них. Операционная система 144, прикладные программы 145, другие программные модули 146 и программные данные 147 обозначены другими позициями, поскольку они, как минимум, могут представлять собой разные копии. Пользователь может вводить команды и информацию в компьютер 110 через устройства ввода, например, клавиатуру 162 и указательное устройство 161, в качестве которого может выступать мышь, шаровой манипулятор или сенсорная панель. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровой пульт, спутниковую тарелку, сканер и т.д. Эти и другие устройства ввода обычно подключаются к обрабатывающему модулю 120 через интерфейс 160 пользовательского ввода, подключенный к системной шине 121, но могут подключаться посредством других интерфейсов и шинных структур, например, параллельного порта, игрового порта или универсальной последовательной шины (USB). К системной шине 121 также можно подключать графический интерфейс 182, например, Northbridge (Северный мост). «Северный мост» - это набор микросхем, который поддерживает связь с ЦП или главным обрабатывающим блоком 120 и предусмотрен для связи через AGP (ускоренный/усовершенствованный графический порт). С графическим интерфейсом 182 может/могут поддерживать связь один или несколько графических процессоров 184 (ГП). Монитор 191 или другое устройство отображения также подключены к системной шине 121 посредством интерфейса, например, видеоинтерфейса 190, который, в свою очередь, поддерживает связь с видеопамятью 186. Помимо монитора 191 компьютеры могут также содержать другие периферийные устройства вывода, например, громкоговорители 197 или принтер 196, которые могут подключаться через интерфейс 195 периферийных устройств вывода.

Компьютер 110 может работать в сетевой или распределенной среде, используя логические линии связи с одним или несколькими удаленными компьютерами, например, удаленным компьютером 180. Удаленный компьютер 180 может представлять собой персональный компьютер, сервер, маршрутизатор, сетевой ПК, равноправное устройство или другой общий узел сети и обычно содержит многие или все элементы, описанные выше в отношении компьютера 110, хотя на фиг.2 изображено только запоминающее устройство 181. Логические линии связи, обозначенные на фиг.2, включают в себя локальную вычислительную сеть (ЛВС) 171 и глобальную сеть (ГС) 173, а также, возможно, и другие сети/шины. Такие сетевые среды широко распространены в жилых домах, учреждениях, учрежденческих компьютерных сетях, сетях интранет и в сети Интернет.

При использовании сетевой среды ЛВС компьютер 110 подключают к ЛВС 171 посредством сетевого интерфейса или адаптера 170. При использовании сетевой среды ГС компьютер 110 обычно содержит модем 172 или другое средство установления связи через ГС 173, например, Интернет. Модем 172, который может быть внутренним или внешним, можно подключать к системной шине 121 через интерфейс 160 пользовательского ввода или посредством другого подходящего механизма. В сетевой среде программные модули, указанные применительно к компьютеру 110, или их фрагменты могут храниться в удаленном запоминающем устройстве. В порядке примера, но не в целях ограничения, на фиг.2 показано, что удаленные прикладные программы 185 хранятся в запоминающем устройстве 181. Следует понимать, что помимо сетевых линий связи, показанных в качестве примера, для установления линии связи между компьютерами можно использовать другие средства.

Иллюстративные структуры или архитектуры распределенного вычисления

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

Например, платформа .Net фирмы MICROSOFT® включает в себя серверы, услуги компоновки из стандартных блоков, например, хранение данных на базе Интернет и загружаемое программное обеспечение устройства. В целом, платформа .Net обеспечивает (1) возможность заставить целый ряд вычислительных устройств работать совместно и автоматически обновлять и синхронизировать пользовательскую информацию на всех устройствах, (2) повышенную интерактивную способность веб-сайтов за счет более широкого использования XML вместо HTML, (3) онлайновые услуги, характеризующиеся настраиваемыми доступом к продуктам и услугам и их доставкой пользователю из центральной начальной точки для управления различными приложениями, например, электронной почтой, или программным обеспечением, например, Office.Net, (4) централизованное хранение данных, которое повышает эффективность и простоту доступа к информации, а также синхронизацию информации между пользователями и устройствами, (5) способность интегрировать различные средства связи, например, электронную почту, факсы и телефоны, (6) для разработчиков - возможность создавать модули многоразового использования, что повышает производительность и снижает количество ошибок программирования, и (7) многие другие особенности межплатформенной интеграции.

Управление драйверами в вычислительной системе

Фиг.3А и 3В представляют собой простые схемы, поясняющие, как прикладная программа 135, рабочая среда 302 и драйвер 303 взаимодействуют посредством API и DDI.

Применительно к развертыванию графических API/DDI, в настоящее время имеются две распространенные модели драйвера: модель оперативного драйвера и модель многоуровневого драйвера. На фиг.3А представлена модель оперативного драйвера, в сущности, полная реализация API, которая имеет возможность работать на отдельной части аппаратуры, например, видеоинтерфейсе 190 (фиг.2). Примеры API, в которых используются модели оперативного драйвера, включают в себя соответствующие графические API, например, 3Dfx Glide и ATI CIF, а также OpenGL.

Многоуровневые драйверы, представленные на фиг.3В, вводят дополнительный уровень косвенности, на котором реализация API задействует некоторую логику (например, подтверждение правильности параметров) и код (например, геометрический конвейер) до вызова драйвера 303 через DDI. Термин «многоуровневый драйвер» подразумевает не только, что API вызывает DDI после выполнения работы, но также то, что драйвер 303 может реализовывать различные «уровни» в зависимости от того, насколько оборудование 306 реализует функции. Например, DDI для графического аппаратного продукта, в котором реализовано только наложение растра, имеет более низкий уровень, чем для продукта, в котором помимо наложения растра реализованы преобразование и подсветка.

Поддержка разнообразных многоуровневых драйверов повышает сложность реализации рабочей среды 302. Например, DIRECTX 7.0 от MICROSOFT, который поддерживает аппаратно-ускоренные преобразование и подсветку, должен проверять, реализует ли эту особенность драйвер 303 более низкого уровня. Если да, то приложения 135 могут создавать и использовать устройства с этой особенностью, в противном случае особенность нужно программным образом эмулировать с помощью рабочей среды 302. В результате кодовые пути, выполняемые DIRECTX 7.0 значительно различаются в зависимости от того, работает ли он на драйвере типа DIRECTX 7.0, или на драйвере более ранней версии.

Фиг.4 дополнительно иллюстрирует уровни иллюстративных приложений, рабочей среды и драйвера в системе. Приложение 135, рабочая среда 302 и часть драйвера 303 действуют в пользовательском режиме для записи команд рисования в буферы аппаратно-ориентированных команд в памяти прямого доступа. В современной системе ПК эти записи обычно являются постоянными записями в память AGP (усовершенствованного графического порта); и, как указано в этом примере реализации, приложение 135 размещается в EXE-файле, и рабочая среда 302 и драйвер 303 пользовательского режима размещаются в DLL-файлах, которые динамически присоединяются к приложению 135. Эти детали фрагмента системы, относящегося к пользовательскому режиму, могут изменяться; в частности, управляемый код может представлять собой приложение 135, приложение 135 в совокупности с рабочей средой 301 или приложение 301 в совокупности с рабочей средой 302 и драйвером 303 пользовательского режима.

Для защиты от несанкционированной замены драйвера пользовательского режима (например, 303) система обычно запрашивает драйвер 405 ядра (поскольку на код ядра можно полагаться с точки зрения безопасности), чтобы загрузить DLL драйвера 303 пользовательского режима.

В режиме ядра диспетчер командного буфера 404 («диспетчер») и драйвер 405 ядра действуют совместно, отправляя командные буферы оборудованию 306 (диспетчер 404 решает, какой командный буфер отправить, а драйвер 405 ядра дает команды аппаратному обеспечению 406 на отправку командного буфера по запросу диспетчера 404). В этой системе предусмотрено, что массив логики драйвера размещается в драйвере 403 DLL пользовательского режима, а не драйвера 405 ядра. В то время как драйвер 303 пользовательского режима может содержать большие объемы кода, который отображает вызовы уровня DDI в аппаратно-ориентированные команды (каковая операция может быть затруднена и подвержена ошибкам, в особенности при компиляции программы построения вершин и/или теней), драйвер 405 ядра сравнительно мал и прост, что максимизирует живучесть системы.

Фиг.5 на примере графических операций поясняет последовательность событий, происходящих, когда приложение 135 делает вызовы API. На фиг.5 командные буферы конкретно не указаны как компонент аппаратного обеспечения; согласно фиг.4 драйвер 303 пользовательского режима записывает аппаратно-ориентированные команды в текущий командный буфер устройства, диспетчер командного буфера (будучи частью блока 530 поддержки ядра системы) отправляет командный буфер оборудованию 306 через драйвер 405 режима ядра, и законченные командные буферы освобождаются для использования приложением 135 в системе. Заметим, что несколько приложений 135 могут, в принципе, совместно использовать пул имеющихся командных буферов, при этом блок 530 поддержки ядра системы организует совместное использование этого ресурса.

Когда приложение 135 первоначально создает контекст 501 рисования, блок 530 поддержки ядра системы проверяет 531, можно ли создать новый командный буфер. Если да, то происходит создание 532 и инициализация 533 нового командного буфера, и цепочка выполняемых задач получает 534 инициализированный командный буфер, после чего приложение 135 может осуществить вызовы 502 рисования. Если на этапе 531 выясняется, что командный буфер создать нельзя, то приложение 135 должно ожидать 534, пока не появится инициализированный командный буфер. В случае получения приложением 135 командного буфера, приложение 135, рабочая среда 302 и драйвер 303 пользовательского режима вступают в обычное взаимодействие между тремя компонентами, в результате чего происходит запись аппаратно-ориентированных команд в командный буфер. Рабочая среда 302 подтверждает 511 вызовы 502 рисования, полученные от приложения 135, затем проверяет 512, необходим ли сброс текущего командного буфера. Если нет, то команда рисования транслируется 513 в более простой, канонический вызов DDI и поступает на драйвер 303 пользовательского режима. Драйвер транслирует вызов DDI в аппаратно-ориентированные команды и пытается записать их в командный буфер. Если при проверке 522 необходимости сброса выясняется, что в командном буфере нет места, то надлежит передать командный буфер блоку 530 поддержки ядра системы и получить от него новый командный буфер, после чего записать команду и продолжить выполнение. Если рабочая среда 302 либо драйвер 303 пользовательского режима принимает решение о необходимости сброса, то на этапе 535 командный буфер добавляется в очередь ожидания. В это время ядро системы может проверить 536, можно ли немедленно передать командный буфер (обычно потому что ни один командный буфер не работает). Если нет, то командный буфер остается в очереди ожидания и следует получить 534 новый командный буфер. Заметим, что этот функциональный блок, который ожидает, пока не появится подходящий инициализированный командный буфер, после чего выделяет его устройству, идентичен операции, необходимой приложению 135, чтобы оно могло начать рисование.

Когда готовый командный буфер выбран 540 для отправки, блок 530 поддержки ядра системы заставляет драйвер 405 ядра осуществлять переключение 551 контекста оборудования на соответствующий контекст и отправлять 552 командный буфер на оборудование. Оборудование 306 считывает и выполняет командный буфер (561), пока эта операция не будет прервана или пока не закончится командный буфер. Если командный буфер завершается нормально (563), то оборудование сигнализирует о прерывании и выполняется программа 553 обслуживания прерываний. При этом ISR (программа обслуживания прерываний) может сохранить контекст 554 оборудования, хотя драйвер может пожелать отложить эту операцию до переключения 551 контекста в случае, когда оборудованию требуется выполнить рядом два командных буфера, которые действуют на одном и том же контексте. После этапа 554 блок 530 поддержки ядра системы может освободить ресурсы, необходимые командному буферу 538, а также сигнализировать посредством любых механизмов извещения, например, событий, чтобы заинтересованные клиенты могли знать о завершении командного буфера. После этапа 538 перед блоком поддержки ядра системы стоят две различные задачи: повторно инициализировать вновь доступный командный буфер и добавить его к инициализированному пулу (533) и разблокировать любые ожидающие командные буферы и переместить их в очередь готовности (539). После этапа 539 можно выбрать другой командный буфер для отсылки 540.

Сложность межпроцессовых связей, описанных со ссылкой на фиг.4 и 5, иллюстрирует необходимость в управляемом коде в соответствии с аспектом изобретения. В частности, система, описанная со ссылкой на фиг.5, может усиливать (преобразовывать) управляемый код, в котором фрагменты приложения 135, рабочей среды 302 и/или драйвера 303 пользовательского режима доставляются на промежуточном языке и подвергаются оперативной (JIT) компиляции на клиенте. Три компонента доставляются клиенту по отдельности на промежуточном языке. Оперативный JIT-компилятор синтезирует их в унифицированный фрагмент объектного кода, который включает в себя фрагменты всех трех компонентов. Такая архитектура обеспечивает систему, в которой выполняется более оптимальный объектный код. Кроме того, константы в вызове приложения 135 в точку ввода можно передавать рабочей среде 302 и драйверу 303 пользовательского режима, что, в принципе, может влиять на объектный код, который записывал в командный буфер несколько слов-констант вместо того, чтобы пересечь несколько границ вызова функций для достижения того же результата. Промежуточный язык из приложения 135 все же является аппаратно-независимым, поскольку драйвер 303 пользовательского режима ориентирован на аппаратное обеспечение графики на клиенте. Кроме того, весь управляемый код можно доставлять в систему по сети, что описано выше со ссылкой на фиг.1.

Хотя наилучшие потенциальные улучшения работы следует достигать путем генерации управляемого кода для трех компонентов (т.е. приложения 135, рабочей среды 302 и драйвера 303 пользовательского режима), система может управлять приложением 135 и рабочей средой 302 и взаимодействовать с отдельным драйвером 303 пользовательского режима или даже управлять просто приложением 135 и взаимодействовать с отдельными рабочей средой 302 и драйвером 303 пользовательского режима. Фактически можно добиться, чтобы такие подсистемы мирно сосуществовали ввиду того, что рабочая среда 302 и/или драйвер 303 пользовательского режима имеются как на промежуточном языке, так и в виде DLL пользовательского режима.

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

Управляемый код

Традиционный механизм развертывания программного обеспечения предусматривает написание исходного кода, компиляцию исходного кода в выполняемую форму для конкретного типа компьютера и инсталляцию выполняемого кода на компьютере-клиенте, обеспечивающую возможность его прогона. Согласно другой методологии, применяемой в инфраструктуре .NET, в этом процессе предусмотрен дополнительный этап. Исходный код транслируют в легко компилируемую промежуточную форму, и в таком виде инсталлируют на компьютере-клиенте. Затем компьютер-клиент использует JIT (оперативный) компилятор для трансляции промежуточного кода в собственный выполняемый «управляемый» код, который можно прогонять. Такой подход имеет ряд преимуществ. Одно из них состоит в том, что промежуточный код является платформонезависимым; поскольку трансляция в выполняемый код осуществляется на клиенте, то любой клиент, которому известно, как компилировать промежуточный код, может выполнять приложение. С этим связано еще одно преимущество, состоящее в том, что платформонезависимый промежуточный код можно передавать для прогона на платформу, которой не существовало во время написания кода.

Однако, применительно к изобретению, наиболее важное преимущество оперативной компиляции состоит в том, что в процессе генерации управляемого кода оперативному компилятору заранее известен точный характер компьютера назначения (т.е. клиента, на котором работает оперативный компилятор). Если компьютер-клиент имеет конкретный тип микропроцессора, то оперативный компилятор может эмитировать код, который является собственным для этого конкретного микропроцессора. Например, в микропроцессоре Pentium Pro имеются команды условного перемещения, дополняющие набор команд х86, а в микропроцессоре Pentium 3 имеются команда упреждающей выборки и другие команды управления кэшем, которых не было у его предшественников. Для поддержки этих команд микропроцессора в традиционно развертываемом программном обеспечении требуется, чтобы разработчик записал исходный код, в котором используются всевозможные особенности, а затем записал детектирующее программное обеспечение, чтобы определить путь к коду для выполнения на клиенте в случае прогона на нем кода. Этап оперативной компиляции освобождает разработчика от этой задачи и даже предлагает разработчику защиту от дальнейших инноваций. Иными словами, компьютер, в который включена новая команда, которая помогает приложению разработчика, может включать в себя оперативный компилятор, которому известно, как эмитировать эту команду; приложение будет пользоваться этой командой даже, если ее не существовало во время разработки приложения.

Сторонники оперативных моделей драйверов мотивируют необходимость внедрения реализации API в драйвер улучшением качества функционирования. Однако такое внедрение имеет много нежелательных побочных эффектов, главным образом, из-за неспособности последующих версий рабочей среды добавлять особенности, усовершенствования в работе или изменения в политике API к драйверам, которые появились раньше данной версии рабочей среды. История DIRECTX знает немало примеров, которые подчеркивают полезность усовершенствований API, которые работают на инсталлированной базе драйверов. Эти усовершенствования API могут представлять собой упрощенные методы рисования, например, API DrawPrimitive DIRECTX 5.0, который работал на драйверах, предшествовавших DIRECTX 5.0; усовершенствования в работе, например, геометрический конвейер DIRECTX 6.0, который работал на драйверах, предшествовавших DIRECTX 6.0; и изменения в политике уровня API, например, администратор текстуры DIRECTX 6.0, который работал на драйверах, предшествовавших DIRECTX 6.0. Эти типы усовершенствований трудно или невозможно доставлять, если рассматриваемые драйверы являются оперативными драйверами.

Поскольку оперативному компилятору заранее известен тип микропроцессора на клиенте, ему также заранее известна точная конфигурация оборудования клиента. В частности, ему известен тип графического процессора и соответствующего драйвера на клиенте. Например, в процессе оперативной компиляции системе известна эффективная (действующая) версия графического драйвера (DIRECTX 6.0, DIRECTX 7.0 и т.д.), поэтому если приложение и драйвер являются управляемыми, то оперативный компилятор может эмитировать выполняемый код, настроенный на эту версию драйвера. Такая система изображена на фиг.6.

Приложение 135 и рабочая среда 302 принимаются на промежуточном языке (ПЯ), например, CLRT фирмы MICROSOFT. Оперативный компилятор 602 берет приложение ПЯ 135 и рабочую среду ПЯ 302 и внедряет их в единое компилированное управляемое приложение 604. Это приложение осуществляет связь с драйвером 303 и оборудованием 306 вышеописанным образом.

Основанный на оперативном компилировании подход, представленный на фиг.6, обеспечивает многочисленные оптимизации, в том числе:

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

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

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

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

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

На фиг.7 представлен альтернативный вариант осуществления системы управляемого кода. Данная архитектура обеспечивает компилированному приложению 135 записывать аппаратно-ориентированные команды непосредственно в командные буферы или буферы обратного магазинного типа. Потенциальные выгоды данного варианта осуществления, помимо влияния на функционирование, включают в себя снижение технических усилий, необходимых независимым поставщикам оборудования для доставки межплатформенных драйверов, и улучшение обеспечения средств приемочных испытаний, которые позволяют гарантировать правильность драйверов. Приложение 135, рабочая среда 302 и драйвер 303 поступают на JIT 602 в виде ПЯ. JIT преобразует их в управляемое приложение 604.

Исторически сложилось так, что DIRECTX был реализован в рамках модели многоуровневого драйвера, согласно которой рабочая среда транслирует графику и команды рисования в поток упрощенных, аппаратно-независимых маркерных потоков. Когда рабочая среда DIRECTX определяет, что необходим «выпуск» (т.е. что команды потока должны выполняться аппаратными средствами), она переходит в режим ядра и направляет командный поток к графическому драйверу. Драйвер анализирует командный поток и транслирует его в аппаратно-ориентированные команды и обычно записывает эти команды в буфер памяти для использования аппаратурой.

Согласно фиг.4 в сочетании с фиг.6 и 7 драйвер 405 режима ядра имеет минимальный размер, реализует вполне достаточный объем кода, чтобы инициализировать оборудование, инициировать операцию прямого доступа к памяти для использования ранее составленного командного буфера, а также для задания и обработки прерываний. Согласно фиг.4 изобретение можно реализовать в двух формах. Во-первых, как отмечено выше, оперативный компилятор 602 может компилировать приложение 135 и рабочую среду 302 так, чтобы позднее ограниченный управляемый код взаимодействовал с DLL драйвера 303. Тогда оперативный компилятор 602 будет знать точные характеристики DLL драйвера 303 на время компиляции (например, реализует ли он ускорение преобразования и подсветки) и сможет пользоваться преимуществом знания того, когда генерировать код для компьютера-клиента.

Во-вторых, вариант «управляемого драйвера» изобретения, представленный на фиг.4, предусматривает, что оперативный компилятор 602 компилирует приложение 135, рабочую среду 302 и драйвер 303 DLL, так что унифицированный фрагмент выполняемого кода осуществляет трансляцию из API и запись аппаратно-ориентированных команд в память прямого доступа 410. Эта архитектура объединяет живучесть и другие преимущества модели многоуровневого драйвера с эффективностью, обеспечиваемой аппаратно-ориентированным характером модели оперативного драйвера. Поэтому эта «модель управляемого драйвера» обеспечивает более высокий потенциал функционирования по сравнению с другими архитектурами драйвера.

Как отмечено выше, хотя иллюстративные варианты осуществления настоящего изобретения были описаны в связи с различными вычислительными устройствами и сетевыми архитектурами, его основные идеи применимы к любым вычислительным устройствам или системам, в которых желательно управлять приложениями и драйверами. Таким образом, способы управления приложениями, отвечающие настоящему изобретению, можно применять к разнообразным приложениям и устройствам. Например, преимущества изобретения можно применять к графической системе вычислительного устройства, предусмотренной на устройстве в виде отдельного объекта, как часть другого объекта, как объект, загружаемый с сервера, как «посредник» между устройством или объектом и сетью и т.д. Генерированное управляемое приложение можно сохранить для последующего использования или вывести в другой(ую) независимый(ую), зависимый(ую) или родственный(ую) процесс или услугу. Хотя иллюстративные языки программирования, названия и примеры выбраны здесь из разнообразных вариантов выбора, эти языки, названия и примеры не предназначены для ограничения.

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

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

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

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

Изобретение относится к вычислительным системам. Его использование при управлении драйверами позволяет получить технический результат в виде обеспечения возможности получить наиболее эффективный исполняемый код для текущей конфигурации компьютерной системы, с учетом возможности обновления ее компонентов. Этот результат достигается благодаря тому, что в компьютерной системе вводят программу приложения на промежуточном языке программирования в память компьютерной системы, вводят программу рабочей среды на промежуточном языке программирования в память компьютерной системы, компилируют программу приложения и программу рабочей среды компилятором компьютерной системы в единую выполняемую программу для выполнения на компьютерной системе назначения. 2 н. и 15 з.п. ф-лы, 7 ил.

1. Компьютерная система, содержащая

процессор, выполняющий операционную систему, имеющую избранный драйвер, взаимодействующий с вычислительным устройством,

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

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

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

вводят программу приложения на промежуточном языке программирования в память компьютерной системы,

вводят программу рабочей среды на промежуточном языке программирования в память компьютерной системы,

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