Диспетчер задач. WinAPI

 

 

содержание

 

      1. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

    1.1 Общие сведения

      1. Наименование системы

       Система диспетчеризации процессов.

      1. Плановые  сроки начала и окончания работы

     Разработка  данной системы была начата 20.02.2008 г.

     Завершение  разработки планируется на 25.04.2008 г.

      1. Порядок оформления работы

1. Обоснование  необходимости разработки программы

  • Постановка задачи.
  • Сбор исходных материалов.
  • Выбор и обоснование критериев эффективности и качества разрабатываемой программы.

2. Научно-исследовательские  работы

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

3. Разработка  и утверждение технического задания

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

      1.2. Назначение и цели создания системы

      1.2.1. Назначение системы

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

      1.2.2 .Цели создания  системы

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

      1.3. Характеристики объектов  систематизации

      1.3.1. Краткие сведения об объекте автоматизации

      Объектом  автоматизации является представление  списка процессов, запущенных в системе, в виде удобном для восприятия пользователем и реализация операций над ними.

      1.3.2. Сведения об условиях эксплуатации

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

      1.4. Требования к системе

      1.4.1. Требования к  функциональным характеристикам

     Приложение  должно содержать и выполнять следующие действия

    • Работа с процессами
      1. Завершение процесса;
      2. Отображение идентификатора процесса;
      3. Отображение имени процесса;
      4. Отображение количества памяти, занятое процессом;
      5. Отображение количества потоков, запущенных процессом;
      6. Отображение модулей, используемых при работе процесса;
      7. Отображение приоритета процесса;
      8. Отображение общего количества процессов системы;
      9. Возможность изменения приоритета процесса.
    • Дополнительные возможности
      1. Выключение компьютера;
      2. Перезагрузка компьютера;
      3. Смена профиля.

      1.4.2. Требования к надёжности

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

      1.4.3. Условия эксплуатации

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

      1.4.4. Требования к  составу и параметрам технических  средств

     Для нормального функционирования приложения необходимы:

    • ОС Windows 98/ME/NT/2000/XP
    • Процессор i80486 и выше
    • Не менее 16Мб RAM
    • Не менее 3 Мб свободного места на жестком диске
    • Клавиатура и манипулятор мышь

              1.4.5. Требования к  информационной и программной  совместимости

      Среда проектирования, используемая при разработке данного проекта – Microsoft Visual Studio 2005. Для работы с приложением требуется установленная операционная система Windows 98 или более поздняя версия, приложение совместимо только с ОС семейства Windows. Работа продукта основана на стандартных библиотеках системы, и не требует установки дополнительных.

      1.4.6. Требования к  транспортированию и хранению

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

      1.5.Требования  к программной  документации

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

 

2. ИССЛЕДОВАТЕЛЬСКАЯ  ЧАСТЬ

      2.1. Постановка задачи

     Реализовать программу представляющую собой  диспетчер задач. Программа должна отображать необходимую информацию о процессах (идентификатор процесса, количество запущенных потоков каждым процессом, имя процесса, уровень приоритета процесса,  а также количество памяти, занимаемое процессом), предоставлять функции по завершению процесса, изменять приоритет процесса, отображать модули, используемые процессом, предоставлять средства по работе с компьютером (выключение, перезагрузка, смена профиля). Среда проектирования - Microsoft Visual Studio 2005 с использованием средств Win32 API.

      2.2. Общие сведения

      2.2.1. Выбор программной и аппаратной платформ

      В качестве программной платформы  была выбрана платформа операционных систем семейства Windows (98/ME/NT/2000/XP). Выбор платформы связан с несколькими факторами. Прежде всего - это распространенность операционных систем семейства Windows. Ведь подавляющее большинство операционных систем в мире на данный момент относятся к семейству Windows. Операционные системы Windows – это графические операционные системы, впервые представленные в ноябре 1985 года для использования на компьютерах типа IBM PC и совместимых с ним в виде системы Windows 1.0. По мере проникновения на рынок персональных компьютеров (ПК) системы Windows почти полностью вытеснили всех имеющихся конкурентов и стали, фактически, эталоном операционной системы для ПК. Для разработчиков Windows-приложений фирма Microsoft предоставляет специальный интерфейс программирования приложений под названием Win32 API (application programming interface), содержащий совокупность функций, к которым может обращаться приложение. Win32 API реализован на следующих платформах: Win32s, Windows 95/98/NT/2000/XP. Фирма Microsoft стремилась включить все Win32-функции во все платформы, поддерживающие интерфейс Win32 API. Для разработчиков программного обеспечения это означает, что тексты программ не приходится переписывать для каждой платформы заново, приложение достаточно лишь перекомпилировать под другую платформу. Все Win32-платформы содержат Win32-функции, а значит, можно вызывать любую из функций интерфейса Win32 API независимо от того на какой платформе компилируется приложение. Но реализация реализации рознь. Когда Microsoft заявляет, что все Win32-функции будут реализованы на каждой платформе, то на деле это означает, что все Win32-функции будут существовать на каждой платформе, но поддерживаться на некоторых из них они будут только частично. Но, несмотря на очевидные различия между Win32-платформами, их объединяют более существенные черты. В частности, предполагается, что большинство простых Windows-приложений совместимы со всеми Windows-платформами с незначительными изменениями или вовсе без них.

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

      В качестве аппаратной платформы были выбраны PC-совместимые компьютеры, позволяющие работать с операционными системами семейства Windows.

      2.2.2. Выбор средства  разработки

      Как уже отмечалось, программа написана на функциях Win32 API и скомпилирована в среде MS Visual Studio 2005. Поэтому при разработке был использован синтаксис языка высокого уровня C++, который на сегодняшний момент является одним из ведущих языков программирования для разработки практически любых приложений и программ. И, так как система Windows написана на Си, все описания функций Win32 API даны в соответствии с синтаксисом именно этого языка. Это немного упрощает и ускоряет процесс изучений функций и написания приложений.

      2.2.3. Процессы

               2.2.3.1. Общие сведения

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

         2.2.3.2. Состояние процесса

      В многозадачной (многопроцессной) системе процесс может находиться в одном из трех основных состояний:

      ВЫПОЛНЕНИЕ - активное состояние процесса, во время  которого процесс обладает всеми  необходимыми ресурсами и непосредственно  выполняется процессором;

      ОЖИДАНИЕ - пассивное состояние процесса, процесс заблокирован, он не может выполняться по своим внутренним причинам, он ждет осуществления некоторого события, например, завершения операции ввода-вывода, получения сообщения от другого процесса, освобождения какого-либо необходимого ему ресурса;

      ГОТОВНОСТЬ - также пассивное состояние процесса, но в этом случае процесс заблокирован в связи с внешними по отношению  к нему обстоятельствами: процесс  имеет все требуемые для него ресурсы, он готов выполняться, однако процессор занят выполнением другого процесса.

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

      В состоянии ВЫПОЛНЕНИЕ в однопроцессорной системе может находиться только один процесс, а в каждом из состояний ОЖИДАНИЕ и ГОТОВНОСТЬ - несколько процессов, эти процессы образуют очереди соответственно ожидающих и готовых процессов. Жизненный цикл процесса начинается с состояния ГОТОВНОСТЬ, когда процесс готов к выполнению и ждет своей очереди. При активизации процесс переходит в состояние ВЫПОЛНЕНИЕ и находится в нем до тех пор, пока либо он сам освободит процессор, перейдя в состояние ОЖИДАНИЯ какого-нибудь события, либо будет насильно "вытеснен" из процессора, например, вследствие исчерпания отведенного данному процессу кванта процессорного времени. В последнем случае процесс возвращается в состояние ГОТОВНОСТЬ. В это же состояние процесс переходит из состояния ОЖИДАНИЕ, после того, как ожидаемое событие произойдет.

          2.2.3.3. Контекст и дескриптор  процесса

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

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

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

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

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

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

         2.2.3.4 Приоритет процесса

      Приоритет - это число, характеризующее степень привилегированности процесса при использовании ресурсов вычислительной машины, в частности, процессорного времени: чем выше приоритет, тем выше привилегии.

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

      Существует  две разновидности приоритетных алгоритмов: алгоритмы, использующие относительные  приоритеты, и алгоритмы, использующие абсолютные приоритеты.

      В обоих случаях выбор процесса на выполнение из очереди готовых  осуществляется одинаково: выбирается процесс, имеющий наивысший приоритет. По-разному решается проблема определения момента смены активного процесса. В системах с относительными приоритетами активный процесс выполняется до тех пор, пока он сам не покинет процессор, перейдя в состояние ОЖИДАНИЕ (или же произойдет ошибка, или процесс завершится). В системах с абсолютными приоритетами выполнение активного процесса прерывается еще при одном условии: если в очереди готовых процессов появился процесс, приоритет которого выше приоритета активного процесса. В этом случае прерванный процесс переходит в состояние готовности.

          2.2.3.5 Алгоритмы планирования

      Существует два  основных типа процедур планирования процессов - вытесняющие (preemptive) и невытесняющие (non-preemptive).

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

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

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

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

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

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

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

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

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

      Однако  почти во всех современных операционных системах, ориентированных на высокопроизводительное выполнение приложений (UNIX, Windows NT, OS/2, VAX/VMS), реализована вытесняющая многозадачность. В последнее время дошла очередь и до ОС класса настольных систем, например, OS/2 Warp и Windows 95. Возможно, в связи с этим вытесняющую многозадачность часто называют истинной многозадачностью.

 

3. КОНСТРУКТОРСКАЯ ЧАСТЬ

      3.1.Общие сведения

      Программа представляет собой исполняемый exe–файл kurs_rab.exe, созданный в процессе компиляции проекта, написанного на языке С++ с использованием API функций Windows.

      При написании курсового проекта  использовалось следующее программное  обеспечение:

      Microsoft Visual Studio 2005

      Microsoft Word 2003

      Microsoft Visio 2003

      3.2. Руководство программиста

      3.2.1.Назначение программы

     Данная  программа создана в среде  Visual Studio 2005. Она позволяет пользователю выполнять диспетчеризацию процессов, запущенных в системе.

      3.2.2.Условия выполнения  программы

     Программа может быть запущена на любом компьютере, на котором установлена одна из операционных систем Windows 98/ME/NT/2000/XP. Программа занимает 176 КБ  дискового пространства. Для её выполнения достаточно 16 Мб оперативной памяти.

      3.2.3.Тестирование  программы

Для тестирования программы следует произвести следующие действия:

  1. Запустить файл “ kurs_rab.exe”.
  2. Выбрать какой-либо процесс из списка. В результате должна отобразиться информация об этом процессе.
  3. Выбрать какой-либо процесс из списка процессов и завершиь процесс.
  4. Выбрать какой-либо процесс из списка процессов и поменять уровень привилегии данного процесса.
  5. Выключить компьютер с помощью программы. Это можно сделать, нажав на кнопку с соответствующим названием.
  6. Перезагрузить компьютер. Это можно сделать, нажав на кнопку с соответствующим названием.
  7. Поменять профиль пользователя. Это можно сделать, нажав на кнопку с соответствующим названием.
  8. После выполнения всех вышеперечисленных действий программа будет протестирована.

      3.2.4.Обращение к  программе

    Для обращения к программе необходимо запустить файл ““ kurs_rab.exe” с жёсткого диска.

      3.2.5.Структура программы

     Программа состоит из одной модульной части:

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

      3.2.6. Структуры модели данных

    1. Основные  переменные для работы с процессами
      • HANDLE h – дескриптор моментального снимка процессов, запущенных в системе, этот дескриптор может быть использован для получения снимка модулей, используемых процессом, все зависит от того флага, который будет передаваться в функцию, создающую этот снимок;
      • PROCESSENTRY32 pe32 – структура для описания каждого процесса, её поля содержат всю необходимую базовую информацию о процессах;
      • PROCESS_MEMORY_COUNTERS prm – структура, одним из полей которой является количество памяти в байтах, занятое процессом;
      • MEMORYSTATUS ms – структура, содержащая информацию о текущем состоянии физической и виртуальной памяти
      • PROCESS_INFORMATION pi – структура, содержащая информацию о новом созданном процессе и ее основных нитях.
      • DWORD id – 32-х битное беззнаковое целое число
 
    1. Некоторые переменные для работы с приложением
      • HICON hIcon – дескриптор иконки окна;
      • HWND hwnd – дескриптор окна приложения;
      • MSG msg – структура, хранящая информацию от нитей набор сообщений.

      3.2.4. Реализация пользовательского  интерфейса программы

     Функция int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow);

     Данная  функция создана для выполнения основных задач:

    1. регистрация оконного класса, создание окна программы, отображение его на экране, организация цикла обработки сообщений;
    2. инициализации стандартных элементов управления;
Диспетчер задач. WinAPI