Разработка системного приложения с помощью API функций для Windows в среде Visual Studio 2008

РЕСПУБЛИКА КАЗАХСТАН

АЛМАТИНСКИЙ ИНСТИТУТ ЭНЕРГЕТИКИ И СВЯЗИ

Кафедра Электроники и Компьютерных Технологий

Курсовая Работа

Тема: «Разработка системного приложения с помощью API функций для Windows в среде Visual Studio 2008»

Выполнил:

студент группы БВТ 07-5

Ахияров Р.К.

Проверил:

ст. пр. Мусатаева Г. Т.

Алматы 2009

Содержание

I. Теоретическая часть

Глава 5. Синхронизация 

5.1. Непрерывные действия и команды 

5.2. Определение синхронизации 

5.3. Программная реализация синхронизации 

5.4. Аппаратная реализация синхронизации

5.5. Примитивы синхронизации 

Глава 6. Синхронизация потоков в Windows 

6.1. Критические секции 

6.2. Объекты синхронизации и функции ожидания

6.3. Мьютексы 

6.4. События 

6.5. Семафоры

Глава 44. Работа со списками управления доступом на низком уровне 

44.1. Структура списка управления доступом

44.2. Структура элемента списка управления доступом 

44.3. Инициализация списка управления доступом

44.4. Проверка достоверности списка управления доступом

44.5. Добавление элементов в список управления доступом 

44.6. Получение элементов из списка управления доступом 

44.7. Удаление элементов из списка управления доступом 

44.8. Получение информации о списке управления доступом 

44.9. Установка версии списка управления доступом 

44.10. Определение доступной памяти

II. Практическая часть

Глава 6. Синхронизация потоков в Windows 

6.1. Критические секции 

6.2. Объекты синхронизации и функции ожидания

6.3. Мьютексы

6.4. События 

6.5. Семафоры

Глава 44. Работа со списками управления доступом на низком уровне 

44.1. Структура списка управления доступом

44.2. Структура элемента списка управления доступом 

44.3. Инициализация списка управления доступом

44.4. Проверка достоверности списка управления доступом

44.5. Добавление элементов в список управления доступом 

44.6. Получение элементов из списка управления доступом 

44.7. Удаление элементов из списка управления доступом 

44.8. Получение информации о списке управления доступом 

44.9. Установка версии списка управления доступом 

44.10. Определение доступной памяти

Приложение.             

Заключение             

Список использованной литературы             

Введение

Данная курсовая работа посвящена рассмотрению принципов работы API-функций операционной системы Windows.

Win API - это набор функций, предоставляемых операционной системой каждой программе. Эти функции находятся в стандартных динамически компонуемых библиотеках (Dynamic Linked Library, DLL), таких как kernel32.dll, user32.dll, gdi32.dll. Эти файлы находятся в директории Window\System. Вообще говоря, каждая программа должна самостоятельно заботится о том, чтобы подключить эти библиотеки. DLL могут подключаться к программе статически и динамически. В первом случае программа "освобождает" DLL только при завершении, во втором освобождение может произойти в любой момент. Если после освобождения DLL оказывается, что её больше не использует ни одна программа, она выгружается из памяти. Так как стандартные библиотеки используются самой системой, они всегда находятся в памяти, и поэтому использование динамического подключения бессмысленно.

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

Обычно программа использует довольно большое число функций Win API. Декларировать их все довольно утомительно. К счастью, Visual C++ избавляет программиста от этой работы: все эти функции уже описаны в соответствующих модулях, достаточно упомянуть их имена в разделе подключения. Например, большинство общеупотребительных функций описаны в модулях windows.h и messages.h.

I.                    Теоретическая часть

5.1. Непрерывные действия и команды

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

□ не прерывается во время своего исполнения;

□ контекст действия изменяется только самим действием.

Если непрерывное действие представляется одной командой  микропроцессора, то оно называется непрерывной инструкцией или командой.

5.2. Определение синхронизации

Если рассматривать параллельные процессы абстрактно, то синхронизация

процессов — это есть достижение некоторого фиксированного соотношения

(порядка) между сигналами, которыми обмениваются эти процессы. В 

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

5.3. Программная реализация синхронизации

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

5.4. Аппаратная реализация синхронизации

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

5.5. Примитивы синхронизации

Примитивом синхронизации называется программное средство высокого

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

6.1. Критические секции

В операционных системах Windows проблема взаимного исключения для

параллельных потоков, выполняемых в контексте одного процесса, решается

при помощи объекта типа critical_section, который не является объектом

ядра операционной системы.

2. Объекты синхронизации и функции ожидания

В операционных системах Windows объектами синхронизации называются объекты ядра, которые могут находиться в одном из двух состояний: сигнальном (signaled) и несигнальном (nonsignaled). Объекты синхронизации могут быть разбиты на четыре класса. К первому классу относятся собственно объекты синхронизации, т. е. те, которые служат только для решения задач синхронизации параллельных  потоков.

6.3. Мьютексы

Для решения проблемы взаимного исключения между параллельными  потоками, выполняющимися в контекстах разных процессов, в операционных системах Windows используется объект ядра мьютекс. Слово мьютекс  происходит от английского слова mutex, которое в свою очередь является  сокращением от выражения mutual exclusion, что на русском языке значит  "взаимное исключение".

6.4. События

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

6.5. Семафоры

Семафоры в операционных системах Windows описываются объектами ядра

semaphores. Семафор находится в сигнальном состоянии, если его значение

больше нуля. В противном случае семафор находится в несигнальном 

состоянии. Потоки, ждущие сигнального состояния семафора, обслуживаются

в порядке FIFO, т. е. потоки становятся в очередь к семафору с  дисциплиной обслуживания "первый пришел, первый вышел".

44.1. Структура списка управления доступом

При работе со списком управления доступом на низком уровне сам список

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

44.2. Структура элемента списка управления доступом

Система безопасности операционной системы Windows 2000 поддерживает

следующие три типа элементов, которые могут храниться в списках 

управления доступом любого охраняемого объекта:

□ access_allowed_ace — разрешает доступ к объекту, хранится в списке  DACL;

□ access_denied_ace — запрещает доступ к объекту, хранится в списке  DACL;

□ system_audit_ace — обеспечивает генерацию аудиторской записи при доступе к объекту, хранится в списке SACL

44.3. Инициализация списка управления доступом

Инициализация списка управления доступом заключается в задании размера

буфера памяти, которую может занять список управления доступом, и 

установки версии списка управления доступом. Фактически инициализация

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

этого списка.

44.4. Проверка достоверности списка управления доступом

Под проверкой достоверности списка управления доступом будем понимать

проверку достоверности версии и длины этого списка. Длина списка 

управления доступом должна соответствовать количеству включенных в этот 

список элементов.

II.                      Практическая часть

Multithread

#include <windows.h>

#include "resource.h"

#include <time.h>

#define SUSPENDED                            0

#define ACTIVE                                          1

#define TIMER                                                        2

const MAX_BUFFER=100;

HINSTANCE hInst=NULL;

HWND hwndParent;

HWND hwndList;

HWND hwndChild[4];

int iCount;

int iState[4];

long iRectCount[4];

int dwThreadData[4];

int dwThreadID[4];

HANDLE hThread[4];

HANDLE hDrawMutex;

BOOL bUseMutex;

BOOL bTerminate;

HMENU  hMenu;

int iCmd;

//Functions

LRESULT WINAPI Main_WndProc( HWND hWnd,          // message address

UINT uMessage,      // message type

WPARAM wParam,      // message contents

LPARAM lParam );    // more contents

LRESULT WINAPI Main_WndProcChild

( HWND hWnd,          // message address

UINT uMessage,      // message type

WPARAM wParam,      // message contents

LPARAM lParam );    // more contents

BOOL InitializeApp ( void );

BOOL CreateWindows ( void );

BOOL Main_OnCreate( HWND hWnd, LPCREATESTRUCT lpCreateStruct );

void Main_OnSize( HWND hWnd, UINT uState, int cxClient, int cyClient );

void Main_OnTimer( HWND hWnd, UINT uTimerID );

void Main_OnInitMenu( HWND hWnd, HMENU hMenu );

void Main_OnCommand( HWND hWnd, int iCmd, HWND hwndCtl, UINT uCode );

void DoThread( int iCmd );

LONG StartThread(LPVOID lpThreadData );

void UpdateListBox(void);

void ClearChildWindows(void);

void DrawProc ( DWORD dwID );

int WINAPI WinMain(  HINSTANCE hinstThis, HINSTANCE hinstPrev, LPSTR lpszCmdLine, int iCmdShow)

{

MSG msg;

hInst = hinstThis;          // store in global variable

if( ! InitializeApp( ) )

{

// if the application was not initialized, exit here

return( 0 );

}

ShowWindow( hwndParent, iCmdShow );

UpdateWindow( hwndParent );

// receive and forward messages from our queue

while( GetMessage( &msg, NULL, 0, 0 ) )

{

TranslateMessage( &msg );

DispatchMessage( &msg );

}

return( msg.wParam );

}

//NOTE

BOOL InitializeApp ( void )

{

//Register two window classes

WNDCLASS wcex;

wcex.style=0;

wcex.lpfnWndProc              = (WNDPROC)Main_WndProc;

wcex.cbClsExtra                            = 0;

wcex.cbWndExtra                            = 0;

wcex.hInstance                            = hInst;

wcex.hIcon = (HICON)NULL;

wcex.hCursor = (HCURSOR)NULL;

wcex.hbrBackground              = (HBRUSH)(COLOR_WINDOW+1);

wcex.lpszMenuName              = (LPCSTR)IDS_TITLE;

wcex.lpszClassName              = "MainClass";

RegisterClass(&wcex);

wcex.style=0;

wcex.lpfnWndProc              = (WNDPROC)Main_WndProcChild;

wcex.cbClsExtra                            = 0;

wcex.cbWndExtra                            = 0;

wcex.hInstance                            = hInst;

wcex.hIcon = (HICON)NULL;

wcex.hCursor = (HCURSOR)NULL;

wcex.hbrBackground              = (HBRUSH)(COLOR_WINDOW+1);

wcex.lpszMenuName              = (LPCSTR)IDS_TITLE;

wcex.lpszClassName              = "ThreadClass";

RegisterClass(&wcex);

// mark the initial state of each thread as SUSPENDED

// that is how they will be created

for( iCount = 0; iCount < 4; iCount++ )

{

iState[iCount] = SUSPENDED;

}

// make the primary thread more important to facilitate user i/o

SetThreadPriority( GetCurrentThread(), THREAD_PRIORITY_ABOVE_NORMAL );

// create all the windows

return( CreateWindows( ) );

}

BOOL CreateWindows ( void )

{

char   szAppName[MAX_BUFFER];

char   szTitle[MAX_BUFFER];

char   szThread[MAX_BUFFER];

int    iCount;

// load the relevant strings

LoadString( hInst, IDS_APPNAME, szAppName,  sizeof(szAppName));

LoadString( hInst, IDS_TITLE,   szTitle,    sizeof(szTitle));

LoadString( hInst, IDS_THREAD,  szThread,   sizeof(szThread));

// create the parent window

hMenu = LoadMenu( hInst, MAKEINTRESOURCE(MENU_MAIN) );

hwndParent = CreateWindow( "MainClass", szTitle,

WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN,

CW_USEDEFAULT, CW_USEDEFAULT,

CW_USEDEFAULT, CW_USEDEFAULT,

NULL, hMenu, hInst, NULL );

if( ! hwndParent )

{

return( FALSE );

}

// create the list box

hwndList = CreateWindow( "LISTBOX", NULL,

WS_BORDER | WS_CHILD | WS_VISIBLE |

LBS_STANDARD | LBS_NOINTEGRALHEIGHT,

0, 0, 0, 0,

hwndParent, (HMENU)1, hInst, NULL );

if( ! hwndList )

{

return( FALSE );

}

// create the four child windows

for( iCount = 0; iCount < 4; iCount++ )

{

hwndChild[iCount] = CreateWindow( "ThreadClass", NULL,