ЭФФЕКТИВНОЕ ИСПРАВЛЕНИЕ ПРОГРАММ Российский патент 2009 года по МПК G06F9/44 

Область техники, к которой относится изобретение

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

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

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

Установленные программы преимущественно составлены из модулей исполняемого кода. В качестве одного примера многие программы, предназначенные для исполнения в операционной системе WINDOWS XP от корпорации Майкрософт (Microsoft Corp.) из Редмонта, Вашингтон, преимущественно составлены из модулей исполняемого кода, называемых динамическими подключаемыми библиотеками (DLL). В одном из популярных известных подходов к исправлению программ идентифицируют среди модулей исполняемого кода, составляющих программу, которая должна быть исправлена, модуль исполняемого кода, содержащий код программы, который желательно модифицировать с помощью исправления; создают новую версию идентифицированного модуля исполняемого кода, в котором сделана желаемая модификация; и распространяют новую версию идентифицированного модуля исполняемого кода вместе с программой установки пользователям, которые могут пожелать применить исправление. Каждый пользователь затем определяет, желает ли он/она применить исправление, и если это так, исполняет программу установки, которая замещает исходную версию идентифицированного модуля исполняемого кода новой версией идентифицированного модуля исполняемого кода.

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

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

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

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

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

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

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

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

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

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

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

Перечень фигур чертежей

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

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

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

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

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

Фиг.6 - блок-схема алгоритма, показывающая этапы, в типичном случае выполняемые программным средством, чтобы выполнять проверку действительности параметра, заданную исправлением.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Накопители и дисководы, связанные с ними компьютерные носители информации, обсужденные выше и проиллюстрированные на фиг.1, обеспечивают хранение машиночитаемых инструкций, структур данных, программных модулей и других данных для компьютера 110. На фиг.1, например, накопитель 141 на жестких дисках проиллюстрирован в качестве хранящего операционную систему 144, прикладные программы 145, другие программные модули 146 и данные 147 программ. Заметим, что эти компоненты могут либо быть теми же самыми или отличными от операционной системы 134, прикладных программ 135, других программных модулей 136 и данных 137 программ. Операционной системе 144, прикладным программам 145, другим программным модулям 146 и данным 147 программ даны в настоящем описании другие ссылочные номера, чтобы проиллюстрировать, что, как минимум, они являются другими копиями. Пользователь может вводить команды и информацию в компьютер 110 через устройства ввода, такие как планшет для ввода или электронный цифровой преобразователь 164, микрофон 163, клавиатура 162 и координатно-указательное устройство 161, как правило, упоминаемое как мышь, шаровой манипулятор или сенсорная панель. Другие устройства ввода, не показанные на фиг.1, могут включать в себя джойстик, игровую панель, спутниковую антенну, сканирующее устройство или подобное. Эти и другие устройства ввода часто присоединены к блоку 120 обработки данных через интерфейс 160 пользовательского ввода, который присоединен к системной шине 121, но могут быть присоединены другими структурами интерфейсов и шин, такими как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 191 или другой тип отображающего устройства также присоединен к системной шине 121 посредством интерфейса, такого как видеоинтерфейс 190. Монитор 191 может также быть объединен с панелью сенсорного экрана или подобными. Заметим, что монитор и/или панель сенсорного экрана могут быть физически связаны с корпусом, в котором заключен компьютер 110, такой как планшетный персональный компьютер. В дополнение, компьютеры, такие как вычислительное устройство 110, могут также включать в себя другие периферийные устройства вывода, такие как громкоговорители 195 и печатающее устройство 196, которые могут быть подсоединены через интерфейс 194 периферийного вывода или ему подобный.

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

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

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

Фиг.2 - блок-схема последовательности обмена данными, показывающая типичный обмен данными между компьютерными системами в соответствии с настоящим изобретением. Компьютерные системы, показанные на фиг.2 (компьютерные системы 210, 220, 221, 222, 230, 231 и 232), в типичном случае имеют некоторые или все из компонентов, показанных и обсужденных в связи с фиг.1. На сервере распространения исправлений программное средство генерирует одно или несколько исправлений. Эти исправления 201 отправляются с сервера распространения исправлений на один или более серверов администрирования, таких как серверы 220 и 230 администрирования. Каждый сервер администрирования, в свою очередь, переадресовывает исправления на одну или более целевых компьютерных систем, таких как целевые компьютерные системы 221, 222, 231 и 232. В некоторых вариантах осуществления (не показаны) сервер распространения исправлений отправляет исправления непосредственно одной или более целевым компьютерным системам или через более опосредованный маршрут, чем через один сервер администрирования. Исправления, принятые в целевой компьютерной системе, обрабатываются в целевой компьютерной системе, как более подробно описано ниже. Сервер администрирования может также отправлять команды 202 конфигурирования исправлений одной или более целевым компьютерным системам, которые применяют команды конфигурирования исправлений, чтобы переконфигурировать работу конкретных исправлений. Как описано более подробно ниже, исправление может быть полностью отключено; если исправление не отключено, уведомление о его работе и обработке результата его теста может быть независимо активировано или деактивировано. Когда уведомление о его работе активировано, уведомления могут быть визуально отображены или сохранены локально в целевой компьютерной системе или могут быть отправлены как уведомления 203 соответствующему серверу администрирования.

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

  Таблица 1 1 <Softpatch Patch="Q382429"> 2 <AffectedApplication AffectedExe="sqlservr.exe"> 3 <AffectedVersion Version="9.*"> 4 <AffectedModules Name="SQLSORT.DLL"> 5 <Version "8.0.*, 9.*"> 6 <Function Name="SsrpEnumCore" Address="0x0802E76B" 7 Param="2" Paramtype="LPSTR"> 8 <Filter MaxByteLength="60" /> 9 <Resolution ActionType="BOOL" Action="FALSE" /> 10 </Function> 11 </Version> 12 <Version "10.*, 11.*"> 13 <Function Name="SsrpEnumCore" Address="0x0802D283" 14 Param="2" Paramtype="LPSTR"> 15 <Filter MaxByteLength="128" /> 16 <Resolution ActionType="BOOL" Action="FALSE" /> 17 </Function> 18 </Version> 19 </AffectedModules> 20 </AffectedVersion> 21 </AffectedApplication> 22   23 <Signature Hash="MD5" Signature="C509-64AA-9161-8C52- 24 9F6D-BF5A-AEF2-ECE1-0038-34D1"/> 25 </Softpatch>

Строка 1 содержит уникальный идентификатор исправления. Строка 2 определяет приложение, затрагиваемое исправлением. Строка 3 определяет версию приложения, затрагиваемого исправлением. Строка 4 определяет исполняемый модуль, затрагиваемый исправлением. Строка 5 определяет две версии затрагиваемого исполняемого модуля - версии 8.0.* и 9.*, - для которых предусмотрены направления исправления. Строки 6-10 содержат направления исправления для этих двух версий исполняемого модуля. Строки 6-7 определяют функцию, которая должна быть исправлена, ее адрес в исполняемом модуле, ее параметр, который должен быть протестирован исправлением, и тип параметра, который должен быть протестирован. Строка 8 указывает, что параметр, определенный в строках 6-7, должен быть протестирован, чтобы определить, превышает ли его длина 60 байт. Строка 9 указывает, что вызов функции должен завершиться неудачей, если проверка проходит успешно. Строка 12 определяет еще две версии затрагиваемого исполняемого модуля - версии 10.* и 11.*, - для которых предусмотрены направления исправления. Строки 13-17 содержат направления исправления для этих двух версий исполняемого модуля. Строки 13-14 определяют функцию, которая должна быть исправлена, ее адрес в исполняемом модуле, ее параметр, который должен быть протестирован исправлением, и тип параметра, который должен быть протестирован. Можно видеть, что адрес функции, которая должна быть исправлена в исполняемом модуле, определенной в строках 13-14 для версий 10.* и 11.*, отличается от адреса функции, которая должна быть исправлена, определенной в строках 6-7 для версий 8.0.* и 9.*. Строка 15 указывает, что параметр, определенный в строках 13-14, должен быть протестирован, чтобы определить, превышает ли его длина 128 байт. Строка 16 указывает, что вызов функции должен завершиться неудачей, если проверка проходит успешно. Исправление может задавать множество типов действий обработки результатов, включая неудачное завершение вызова исправляемой функции, вызов исключения, завершение процесса, в котором исправляемая исполняемая модель исполняется, или исправление некорректного значения (например, посредством усечения слишком длинной строки). Строки 23-25 содержат подпись для исправления, которая и определяет источник исправления, и удостоверяет, что исправление не было изменено с момента выхода из источника.

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

Таблица 2 1 00411А7Е push 3Ch 2 00411А80 mov eax, dword ptr [str] 3 00411А83 push Eax 4 00411А84 call ValidateStringLength (411082h) 5 00411А89 add esp, 8 6 00411А8С movzx ecx, al 7 00411А8F test ecx, ecx 8 00411А91 je 411A9Ah 9 00411А93 jmp foo+2 (411AD2h) 10 00411А9А xor eax, eax 11 00411А9C ret  

Строки 1-3 помещают параметры функции тестирования в стек. Строка 4 вызывает функцию тестирования. Строки 5-8 переходят по коду возврата к функции тестирования. Если выполнение функции тестирования завершилось успешно, строка 9 переходит обратно в начало, исполняя тело исправленной функции. Если выполнение функции тестирования завершилось неудачно, строки 10-11 помещают код результата отказа в стек и возвращаются от исправленной функции к цвету исправленной функции. В целях удобочитаемости таблица 2 опускает определенные подробности, присутствующие в управляемых кодом исправлениях, включая проверяемую подпись, инструкции, которые проверяют текущие значения флагов конфигурирования исправлений, и инструкции, перемещенные из начала кода исправленной функции.

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

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

Фиг.4 - диаграмма структуры данных, показывающая пример таблицы исправлений, являющейся типичной для таблиц, используемых программным средством. Таблица 400 исправлений содержит строки, такие как строки 401 и 402, каждая из которых разделена на следующие столбцы: столбец 411 идентификатора исправления, содержащий идентификатор исправления, извлеченный из исправления; столбец 412 исполняемого модуля, содержащий информацию, определяющую исполняемый модуль, который должен быть исправлен, например, его имя; столбец 413 версий исполняемого модуля, определяющий все версии исполняемого модуля, определенного в столбце 412, к которым применяется исправление; столбец 414 разрешения выполнения теста, содержащий текущее значение конфигурации в отношении того, должен ли тест, заданный в исправлении, выполняться каждый раз, когда исправляемая функция вызывается; столбец 415 разрешения уведомления о выполнении теста, содержащий текущее значение конфигурации в отношении того, должно ли генерироваться уведомление каждый раз, когда выполняется тест исправления; столбец разрешения 416 уведомления о результате теста, содержащий текущее значение конфигурации в отношении того, должно ли генерироваться уведомление каждый раз, когда тест исправления проходит успешно; столбец 417 разрешения обработки результата теста, содержащий текущее значение конфигурации в отношении того, должна ли обработка результата теста быть реализована каждый раз, когда тест исправления завершается неудачно; и столбец 418 исправления, который содержит указатель на само исправление, задавая тест и обработку результатов теста, которая должна быть выполнена каждый раз, когда тест завершается неудачно. В некоторых вариантах осуществления вместо того, чтобы содержать указатель на исправление, как показано, столбец 418 исправления содержит непосредственно каждое исправление. Конкретная таблица исправлений может содержать или указывать на исправления различных типов, такие как только управляемые кодом исправления, только управляемые данными исправления или сочетание управляемых кодом и управляемых данными исправлений.

На этапе 305 после того, как программное средство добавило принятое исправление в таблицу исправлений и инициализировало его конфигурации, исправление доступно для автоматического применения программным средством к исполняемому модулю. На этапе 305 программное средство может использовать множество подходов для применения исправления, включая те, которые описаны в заявке, включенной посредством ссылки, а также перехват вызова функции в реальном времени и/или перезапись кода (1) уже загруженных исполняемых модулей, (2) одного или нескольких дисковых образов исполняемого модуля или (3) экземпляров исполняемых модулей, загруженных средством загрузки операционной системы. После этапа 305 средство переходит к этапу 301, чтобы принять следующее исправление.

Фиг.5 - блок-схема алгоритма, показывающая этапы, в типичном случае выполняемые программным средством, для того чтобы обновлять инструкции по конфигурированию конкретного исправления. На этапе 501 программное средство принимает инструкции по конфигурированию конкретного исправления, например, от администратора. В некоторых вариантах осуществления такие инструкции по конфигурированию могут быть сгенерированы администраторами с помощью групповых политик. На этапе 502 программное средство обновляет конфигурацию исправления в таблице исправлений в соответствии с принятыми инструкциями. После этапа 502 средство переходит к этапу 501, чтобы принять следующие инструкции по конфигурированию.

Фиг.6 - блок-схема алгоритма, показывающая этапы, в типичном случае выполняемые программным средством, чтобы выполнять проверку действительности параметров, заданную исправлением. На этапе 601 вызывается исправленная функция. На этапе 602, если разрешено тестирование для исправления, которое затрагивает вызванную функцию, то средство переходит к этапу 603, иначе средство переходит к этапу 601, чтобы обработать следующий вызов исправленной функции. На этапе 603, если разрешено уведомление о выполнении теста исправления, то программное средство переходит к этапу 604, иначе программное средство переходит к этапу 605. На этапе 604 программное средство генерирует уведомление о том, что тест был выполнен. Этапы 604, 608 и 610 могут задействовать визуальное отображение или сохранение индикации в целевой вычислительной системе в отношении того, что тест был удовлетворен, и/или передачу этой индикации удаленной компьютерной системе для визуального отображения или регистрации в ней.

На этапе 605 программное средство выполняет тест по проверке действительности, заданный исправлением. В некоторых вариантах осуществления этап 605 включает в себя вызов одной или группы стандартных процедур, используемых программным средством для тестирования. На этапе 606, если тест, выполненный на этапе 605, удовлетворен, то программное средство переходит к этапу 601, иначе программное средство переходит к этапу 607. На этапе 607, если разрешено уведомление о результатах теста для исправления, то программное средство переходит к этапу 608, иначе программное средство переходит к этапу 609. На этапе 608 программное средство генерирует уведомление о том, что тест не был удовлетворен. На этапе 609, если разрешена обработка результатов теста, то программное средство переходит к этапу 610, иначе программное средство переходит к этапу 601. На этапе 610 программное средство выполняет обработку результатов теста, заданную исправлением. После этапа 610 программное средство переходит к этапу 601.

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

Изобретение относится к обновлению работы установленных компьютерных программ. Техническим результатом является исправление установленного компьютерного программного кода. Способ содержит этапы, на которых: принимают в целевой компьютерной системе спецификацию усовершенствования. Спецификация задает (а) функцию, которая должна быть усовершенствована, при этом заданная функция находится среди программного обеспечения, исполняемого в вычислительной системе, (b) параметр функции, который должен быть протестирован, (с) тест, подлежащий применению к заданному параметру, и (d) модификацию, подлежащую выполнению по отношению к поведению функции, если заданный параметр не удовлетворяет заданному тесту. Когда заданная функция вызывается в целевой компьютерной системе, если заданный параметр не удовлетворяет заданному тесту, выполняют заданную модификацию по отношению к поведению заданной функции. 4 н. и 35 з.п. ф-лы, 6 ил., 2 табл.

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

2. Способ по п.1, в котором модификация, заданная спецификацией усовершенствования, предотвращает исполнение заданной функции.

3. Способ по п.1, в котором модификация, заданная спецификацией усовершенствования, исполняет заданную функцию после изменения заданного параметра.

4. Способ по п.1, в котором принимают совокупность спецификаций усовершенствования в целевой компьютерной системе.

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

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

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

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

9. Способ по п.1, в котором спецификация усовершенствования содержит код.

10. Способ по п.9, в котором код, содержащийся в спецификации усовершенствования, включает в себя код, вызывающий функцию тестирования параметра, код которой не включен в спецификацию усовершенствования.

11. Способ по п.1, в котором спецификация усовершенствования содержит текст, идентифицирующий функцию тестирования параметра, код которой не включен в спецификацию усовершенствования.

12. Способ по п.11, в котором код функции тестирования параметра, идентифицированной текстом, содержащимся в спецификации усовершенствования, содержится в спецификации усовершенствования.

13. Способ по п.11, в котором код функции тестирования параметра, идентифицированной текстом, не содержащимся в спецификации усовершенствования, не содержится в спецификации усовершенствования.

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

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

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

17. Способ по п.14, в котором предоставленный интерфейс разрешает конфигурирование действия спецификации усовершенствования в соответствии со стратегией.

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

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

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

21. Способ по п.20, дополнительно содержащий этап, на котором объединяют сгенерированные уведомления в единое объединенное уведомление.

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

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

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

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

26. Способ по п.25, в котором код заданной функции изменяют посредством вставки в код заданной функции перехода на отдельную процедуру, которая выполняет заданный тест.

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

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

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

30. Машиночитаемый носитель по п.29, в котором заданный тест является тестом, который всегда удовлетворяется, независимо от значения заданных данных.

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

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

33. Способ по п.31, в котором пользователь конфигурирует активный диагностический рабочий режим для спецификации усовершенствования, при этом применение принятой спецификации усовершенствования образом, совместимым с рабочим режимом, сконфигурированным для принятой спецификации усовершенствования содержит этап, на котором, если заданные данные не удовлетворяют заданному тесту, выполняют и (1) заданную модификацию по отношению к поведению заданного программного обеспечения, и (2) генерацию уведомления о том, что заданные данные не удовлетворяют заданному тесту.

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

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

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

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

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

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