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

OLE (англ. Object Linking and Embedding, произносится как oh-lay [олэй]) -- технология связывания и внедрения объектов в другие документы и объекты, разработанные корпорацией Майкрософт.

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

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

Использование ActiveX -- последнего продукта в эволюции OLE. Проигрывание музыкального файла.

OLE используется при обработке составных документов (англ. compound documents), может быть использована при передаче данных между различными несвязанными между собой системами посредством интерфейса переноса (англ. drag-and-drop), а также при выполнении операций с буфером обмена. Идея внедрения широко используется при работе с мультимедийным содержанием на веб-страницах (пример -- Веб-ТВ), где используется передача изображения, звука, видео, анимации в страницах HTML (язык гипертекстовой разметки) либо в других файлах, также использующих текстовую разметку (например, XML и SGML). Однако, технология OLE использует архитектуру «толстого клиента», то есть сетевой ПК с избыточными вычислительными ресурсами. Это означает, что тип файла либо программа, которую пытаются внедрить, должна присутствовать на машине клиента. Например, если OLE оперирует таблицами Microsoft Excel, то программа Excel должна быть инсталлирована на машине пользователя.

41.Понятие COM

Component Object Model -- модель многокомпонентных объектов

· Cоставные документы -- лишь частный случай более общей проблемы: как разные программные компоненты должны предоставлять друг другу сервисы?

Для решения этой проблемы архитекторы OLE создали группу технологий, область применения которых гораздо шире составных документов. Основу OLE 2 составляет важнейшая из этих технологий -- Модель многокомпонентных объектов (Component Object Model -- СОМ).

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

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

Итак, что же такое СОМ? Чтобы ответить на этот вопрос, зададимся сначала другим: "Каким образом одна часть программного обеспечения должна получать доступ к сервисам, предоставляемым другой частью? " На сегодняшний день ответ зависит от того, что представляют собой эти части:

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

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

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

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

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

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

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

Клиенты могут получить доступ к сервисам объекта СОМ только через вызовы методов интерфейсов объекта -- у них нет непосредственного доступа к данным объекта.

Представим себе, например, корректор орфографии, реализованный в виде объекта СОМ. Такой объект может поддерживать интерфейс, включающий методы типа “НайтиСлово” (LookUpWord), “ДобавитьКСловарю” (AddToDictionary) и “УдалитьИзСловаря” (RemoveFromDictionary).

Если позднее разработчик объекта СОМ захочет добавить к этому объекту поддержку словаря синонимов, то объекту потребуется еще один интерфейс, возможно, с единственным методом, вроде “НайтиСиноним” (ReturnSynonym). Методы каждого из интерфейсов сообща предоставляют связанные друг с другом сервисы: либо корректировку правописания, либо доступ к словарю синонимов.

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

Чтобы вызывать методы интерфейса объекта СОМ, клиент должен получить указатель на этот интерфейс.

· Обычно СОМ-объект предоставляет свои сервисы посредством нескольких интерфейсов, и клиенту требуется отдельный указатель для каждого интерфейса, методы которого он намерен вызывать.

Например, клиенту нашего простого объекта СОМ понадобился бы один указатель интерфейса для вызова методов интерфейса корректора орфографии и другой -- для вызова методов интерфейса словаря синонимов.

Любой СОМ-объект -- это экземпляр определенного класса. Объекты одного класса могут, например, реализовывать сервисы корректировки орфографии и словаря синонимов, тогда как объекты другого класса -- представлять банковские счета.

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

Эта библиотека COM присутствует на любой системе, поддерживающей СОМ, и имеет доступ к справочнику всех доступных на данной машине классов СОМ-объектов.

· Клиент может, например, вызвать функцию библиотеки СОМ, передав ей класс нужного ему СОМ-объекта и задав один из поддерживаемых объектом интерфейсов, указатель которого нужен клиенту в первую очередь. (Эти сервисы реализованы библиотекой СОМ в виде обычных вызовов функций, а не через методы интерфейса СОМ.)

· Затем библиотека СОМ запускает сервер, реализующий объекты данного класса. Кроме того, библиотека возвращает клиенту указатель требуемого интерфейса вновь созданного экземпляра объекта. Далее клиент может запросить указатели на другие необходимые ему интерфейсы непосредственно у самого объекта.

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

В большинстве объектных технологий объект поддерживает только один интерфейс с одним набором методов. А вот СОМ-объекты могут -- и почти всегда это делают -- поддерживать более одного интерфейса.

· Например, у С++-объекта лишь один интерфейс, включающий в себя все методы объекта. СОМ-объект с его несколькими интерфейсами может быть отлично реализован с несколькими объектами C++ -- по одному на каждый интерфейс СОМ-объекта.

Но в большинстве объектных технологий объект поддерживает только один интерфейс с одним набором методов. А вот СОМ-объекты могут -- и почти всегда это делают -- поддерживать более одного интерфейса.

· Например, у С++-объекта лишь один интерфейс, включающий в себя все методы объекта. СОМ-объект с его несколькими интерфейсами может быть отлично реализован с несколькими объектами C++ -- по одному на каждый интерфейс СОМ-объекта.

Компонентный подход СОМ находит различные применения в технологиях Microsoft для Интернета и WWW. Например, средство просмотра WWW фирмы Microsoft -- Проводник по Интернету (Internet Explorer) -- активно использует расширение технологии составных документов OLE -- Документы ActiveX (ActiveX Documents). Благодаря этому расширению, пользователь может просматривать информацию разного типа в дополнение к обычным страницам HTML (Hypertext Markup Language -- Язык разметки гипертекста).

Управляющие элементы ActiveX -- не отдельные приложения. Напротив, они являются серверами, которые подключаются к контейнеру элементов. Как обычно, взаимодействие между управляющим элементом и его контейнером определяется различными интерфейсами, поддерживаемыми СОМ-объектами

· Итак, OLE - это набор стандартов для связи и внедрения объектов при создании компонентов программного обеспечения.

· Одним из стандартов OLE является спецификация модели составного объекта (или COM), основа для бинарных соединений между компонентами.

42.Управляющие элементы ActiveX

Элементы управления ActiveX

Элементы управления ActiveX являются миниатюрными серверами автоматизации ActiveX, которые загружаются и выполняются в процессе. Последнее указывает на то, что они работают исключительно быстро. Раньше их принято было называть элементами управления OLE. Они были разработаны для замены элементов управления VBX, 16-битовых элементов управления, написанных для использования в Visual Basic и Visual C++. (Имеется достаточное количество существенных технических причин, по которым технология VBX не может быть распространена на 32-битовые приложения.) Поскольку элементы управления OLE традиционно хранились в файлах с расширением .OCX, многие ссылались на элементы управления OLE, как на элементы управления OCX или просто OCX. Хотя технология OLE со временем была замещена ActiveX, создаваемые Visual C++ 6.0 элементы управления ActiveX по-прежнему хранятся в файлах, имеющих расширение .OCX.

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

Если вы уже имеете опыт создания OCX в одной из более ранних версий Visual C++, у вас могло сложиться впечатление, что подобная работа является непростой. Однако пакет Control Developer Kit, интегрированный в новую версию Visual C++, принимает на себя большую часть работы по обеспечению требований ActiveX и дает вам возможность сконцентрироваться на вычислениях, отображении на экран или любых других действиях, для выполнения которых и предназначен данный элемент. Мастер ActiveX Control значительно упрощает работу, позволяя начать с уже имеющейся пустой заготовки.

Поскольку элементы управления являются небольшими серверами автоматизации ActiveX, они должны использоваться контроллерами автоматизации ActiveX. Чтобы не путать контроллер и элемент управления (что безотносительно к ActiveX есть одно и то же), вместо термина контроллер автоматизации будем пользоваться более привычным термином приложение-контейнер или просто контейнер. И Visual C++, и Visual Basic являются контейнерами, ими являются также многие программы, входящие в состав Office, и другие программы Microsoft.

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

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

43.Возможности AppWizard по созданию приложений, поддерживающих технологию ActiveX

Шаг 3. Поддержка составных документов. Третий этап создания выполняемого приложения Windows с помощью AppWizard - выбор уровня поддержки операции с составными документами.

На выбор предлагается пять вариантов поддержки:

если не планируется создание OLE-приложения, выберите переключатель None (Никакой);

если вы хотите, чтобы в приложении использовались связанные или внедренные объекты OLE (например, такие, как документы Word или рабочие листы Excel), выберите переключатель Container (Контейнер);

-если планируется создание приложения, документы которого могли бы быть внедрены в другое приложение, но при этом само приложение не будет использоваться автономно, выберите переключатель Mini-server (Мини-сервер);

если ваше будущее приложение будет не только служить сервером для других приложений, но и сможет работать автономно, выберите переключатель Full-server (Полный сервер);

если создаваемое приложение должно обладать способностью включать документы других приложений и само обслуживать их своими объектами, выбирайте переключатель Both container and server (и контейнер, и сервер).

Если вы выбрали какой-либо из вариантов поддержки составных документов, то придется поддерживать и составные файлы (compound files). Составные файлы содержат один или более объектов ActiveX и сохраняются на диске в особом формате, так что один из объектов может быть заменен без переписи всего файла. Таким образом, удается сберечь довольно много времени. В середине диалогового окна Step 3 имеется группа из двух переключателей - “Would you like to support compound files?” (Необходима ли поддержка составных файлов?)

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

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

44.Библиотеки динамической компоновки DLL. Статическое подключение DLL. Экспортирование функций из DLL

С самого рождения (или чуть позже) операционная система Windows использовала библиотеки динамической компоновки DLL (Dynamic Link Library), в которых содержались реализации наиболее часто применяемых функций.

Практически невозможно создать приложение Windows, в котором не использовались бы библиотеки DLL.

В DLL содержатся все функции Win32 API и несчетное количество других функций операционных систем Win32

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

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

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

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

Статическое подключение DLL (неявное подключение)

При статическом подключении DLL имя соответствующего ей .lib-файла определяется среди прочих параметров редактора связей в командной строке или на вкладке “Link” диалогового окна “Project Settings” среды Developer Studio.

Однако .lib-файл, используемый при неявном подключении DLL, -- это не обычная статическая библиотека. Такие .lib-файлы называются библиотеками импортирования (import libraries).

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

Загрузка неявно подключаемой DLL

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

Каталог, в котором находится ЕХЕ-файл.

Текущий каталог процесса.

Системный каталог Windows.

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

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

Экспортирование функций из DLL

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

Есть два способа занести функцию в эту таблицу на этапе компиляции.

Можно экспортировать функцию из DLL, поставив в начале ее описания модификатор __declspec (dllexport)

Метод __declspec применяется не так часто, как второй метод, работающий с файлами определения модуля (.def), и позволяет лучше управлять процессом экспортирования.

Синтаксис файлов определения модуля (с расширением .def) в Visual C++ достаточно прямолинеен, главным образом потому, что сложные параметры, использовавшиеся в ранних версиях Windows, в Win32 более не применяются.

Как станет ясно из следующего простого примера, .def-файл содержит имя и описание библиотеки, а также список экспортируемых функций:

MyDLL.def

LIBRARY “MyDLL”

DESCRIPTION `MyDLL - пример DLL-библиотеки'

EXPORTS

MyFunction @1

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

На самом деле компилятор присваивает порядковые номера всем экспортируемым объектам. Однако способ, которым он это делает, отчасти непредсказуем, если не присвоить эти номера явно.

В строке экспорта можно использовать параметр NONAME. Он запрещает компилятору включать имя функции в таблицу экспортирования DLL:

MyFunction @1 NONAME

Иногда это позволяет сэкономить много места в файле DLL. Приложения, использующие библиотеку импортирования для неявного подключения DLL, не “заметят” разницы, поскольку при неявном подключении порядковые номера используются автоматически. Приложениям, загружающим библиотеки DLL динамически, потребуется передавать в GetProcAddress порядковый номер, а не имя функции.

Экспортирование классов

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

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

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

45.Библиотеки динамической компоновки DLL. Динамическая загрузка и выгрузка DLL. Экспортирование функций из DLL

С самого рождения (или чуть позже) операционная система Windows использовала библиотеки динамической компоновки DLL (Dynamic Link Library), в которых содержались реализации наиболее часто применяемых функций.

Практически невозможно создать приложение Windows, в котором не использовались бы библиотеки DLL.

В DLL содержатся все функции Win32 API и несчетное количество других функций операционных систем Win32

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

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

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

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

Динамическая загрузка и выгрузка DLL

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

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

Например, приложение, предназначенное для независимой передачи данных, сможет в ходе выполнения принять решение, загружать ли DLL для протокола TCP/IP или для другого протокола.

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

Стандартным расширением файла библиотеки Windows считает .dll, если не указать другое расширение. Если в имени файла указан и путь, то только он будет использоваться для поиска файла. В противном случае Windows будет искать файл по той же схеме, что и в случае неявно подключенных DLL, начиная с каталога, из которого загружается exe-файл, и продолжая в соответствии со значением PATH.

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

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

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

Файл библиотеки также несколько отличается от обычных файлов на языке C для Windows. В нем вместо функции WinMain имеется функция DllMain.

После трансляции и компоновки файлов библиотеки появляются два файла - MyDLL.dll (сама динамически подключаемая библиотека) и MyDLL.lib (ее библиотека импорта).

При неявном подключения DLL следует в исходный текст помимо вызова функции MyFunction из DLL-библиотеки включить и заголовочный файл этой библиотеки MyDLL.h.

Также необходимо на этапе компоновки приложения подключить к нему библиотеку импорта MyDLL.lib (процесс неявного подключения DLL к исполняемому модулю).

Чрезвычайно важно понимать, что сам код функции MyFunction не включается в файл MyApp.exe. Вместо этого там просто имеется ссылка на файл MyDLL.dll и ссылка на функцию MyFunction, которая находится в этом файле. Файл MyApp.exe требует запуска файла MyDLL.dll.

Заголовочный файл MyDLL.h включен в файл с исходным текстом программы MyApp.c точно так же, как туда включен файл windows.h. Включение библиотеки импорта MyDLL.lib для компоновки аналогично включению туда всех библиотек импорта Windows. Когда программа MyApp.exe работает, она подключается к библиотеке MyDLL.dll точно так же, как ко всем стандартным динамически подключаемым библиотекам Windows.

Экспортирование функций из DLL

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

Есть два способа занести функцию в эту таблицу на этапе компиляции.

Можно экспортировать функцию из DLL, поставив в начале ее описания модификатор __declspec (dllexport)

Метод __declspec применяется не так часто, как второй метод, работающий с файлами определения модуля (.def), и позволяет лучше управлять процессом экспортирования.

Синтаксис файлов определения модуля (с расширением .def) в Visual C++ достаточно прямолинеен, главным образом потому, что сложные параметры, использовавшиеся в ранних версиях Windows, в Win32 более не применяются.

Как станет ясно из следующего простого примера, .def-файл содержит имя и описание библиотеки, а также список экспортируемых функций:

MyDLL.def

LIBRARY “MyDLL”

DESCRIPTION `MyDLL - пример DLL-библиотеки'

EXPORTS

MyFunction @1

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

На самом деле компилятор присваивает порядковые номера всем экспортируемым объектам. Однако способ, которым он это делает, отчасти непредсказуем, если не присвоить эти номера явно.

В строке экспорта можно использовать параметр NONAME. Он запрещает компилятору включать имя функции в таблицу экспортирования DLL:

MyFunction @1 NONAME

Иногда это позволяет сэкономить много места в файле DLL. Приложения, использующие библиотеку импортирования для неявного подключения DLL, не “заметят” разницы, поскольку при неявном подключении порядковые номера используются автоматически. Приложениям, загружающим библиотеки DLL динамически, потребуется передавать в GetProcAddress порядковый номер, а не имя функции.

Экспортирование классов

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

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

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

46.Создание и использование динамически связываемых библиотек. Привести пример

Создание DLL

Теперь, познакомившись с принципами работы библиотек DLL в приложениях, рассмотрим способы их создания.

При разработке приложении функции, к которым обращается несколько процессов, желательно размещать в DLL. Это позволяет более рационально использовать память в Windows.

Проще всего создать новый проект DLL с помощью мастера AppWizard, который автоматически выполняет многие операции. Для простых DLL необходимо выбрать тип проекта Win32 Dynamic-Link Library.

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

Если же планируется в полной мере использовать функциональные возможности MFC, такие как документы и представления, лучше выбрать тип проекта MFC AppWizard (dll).

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

Функция DllMain

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

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

Функция DllMain вызывается в нескольких случаях: при первой загрузке библиотеки DLL процессом, каждый раз при создании процессом нового потока, при уничтожении потока (кроме первого), по окончании работы процесса с DLL.

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

47.Создание рабочего потока. Управление приоритетами потоков

Для создания рабочего потока предназначена функция

AfxBeginThreadбиблиотеки MFC:

CWinThread* AfxBeginThread( AFX_THREADPROC pfnThreadProc,

LPVOID pParam, int nPriority = THREAD_PRIORITY_NORMAL,

UINT nStackSize = 0, DWORD dwCreateFlags = 0,

LPSECURITY_ATTRIBUTES lpSecurityAttrs = NULL );

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

Адрес данной функции (т.е. входная точка в поток) передается в параметре pfnThreadProc. Все потоковые функции должны иметь следующий прототип: UINT pfnThreadProc(LPVOID pParam);

Значение параметра pParam функции AfxBeginThread передается потоковой функции в качестве параметра. Это 32-разрядное число может использоваться для любых целей.

Начальный приоритет потока указывается в параметре nPriority. Если этот параметр равен 0, то используются установки приоритета текущего (родительского) потока. Каждый поток имеет свой собственный стек. Размер стека указывается в параметре nStackSize. Если этот параметр равен нулю (общепринятый подход), то создаваемому потоку будет выделен стек такого же размера, что и у родительского потока, а при необходимости размер стека может быть увеличен.

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

Параметр lpSecurityAttrs является указателем на набор атрибутов прав доступа, относящийся к данному потоку. Если этот параметр равен NULL, то набор атрибутов будет унаследован от родительского окна.

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

Управление приоритетами потоков

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

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

Получить класс приоритета процесса можно с помощью функции GetPriorityClass, а установить класс приоритета можно с помощью функции SetPriorityClass. Обе эти функции являются API-функциями и не входят в класс CWinThread.

Ниже показаны константы, соответствующие классам приоритетов в порядке убывания (по умолчанию программе присваивается приоритет

NORMAL_PRIORITY_CLASS; причин менять его, как правило, нет):

REALTIME_PRIORITY_CLASS

HIGH_PRIORITY_CLASS

NORMAL_PRIORITY_CLASS

IDLE_PRIORITY_CLASS

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

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

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

Определить значение приоритета можно с помощью метода GetThreadPriority, а изменить его - с помощью метода SetThreadPriority. Ниже приведены константы, соответствующие установкам приоритетов потоков в порядке убывания:

THREAD_PRIORITY_TIME_CRITICAL

THREAD_PRIORITY_HIGHEST

THREAD_PRIORITY_ABOVE_NORMAL

THREAD_PRIORITY_NORMAL

THREAD_PRIORITY_BELOW_NORMAL

THREAD_PRIORITY_LOWEST

THREAD_PRIORITY_IDLE

Замечание. Благодаря различным сочетаниям значений приоритета процесса и приоритета потока в Win32 поддерживается 31 различная установка приоритета.

48.Синхронизация потоков. Объекты синхронизации и классы MFC

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

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

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

Объекты синхронизации и классы MFC.

Интерфейс Win32 поддерживает четыре типа объектов синхронизации - все они так или иначе основаны на понятии семафора.

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

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

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

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

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

В MFC механизм синхронизации, обеспечиваемый интерфейсом Win32, поддерживается с помощью следующих классов, порожденных от класса CSyncObject:

CCriticalSection - реализует критический раздел;

CEvent - реализует объект события;

CMutex - реализует исключающий семафор;

CSemaphore - реализует классический семафор.

Кроме этих классов в MFC определены также два вспомогательных класса синхронизации: CSingleLock и CMultiLock. Они контролируют доступ к объекту синхронизации и содержат методы, используемые для предоставления и освобождения таких объектов. Класс CSingleLock управляет доступом к одному объекту синхронизации, а класс CMultiLock - к нескольким объектам.

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

CSingleLock( CSyncObject* pObject, BOOL bInitialLock = FALSE );

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

Когда объект типа CSingleLock создан, доступ к объекту, на который указывал параметр pObject, может контролироваться с помощью двух функций: Lock и Unlock класса CSingleLock.

Метод Lock предназначен для получения доступа к объекту синхронизации.

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

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

При работе с классом CSingleLock общая процедура управления доступом к ресурсу такова:

1.Создать объект типа CSyncObj (например, семафор), который будет использоваться для управления доступом к ресурсу.

2.С помощью созданного объекта синхронизации создать объект типа CsingleLock.

3.Для получения доступа к ресурсу вызвать метод Lock.

4.Выполнить обращение к ресурсу.

49.Потоки в Visual C++. Работа с исключающим семафором

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

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

Рассмотрим текст файла заголовка CountArray2.h для класса СCountArray2. За исключением нового имени класса и объекта мьютекс, этот файл идентичен предыдущей версии файла CountArray.h.

class CCountArray2

{

private:

int array[10];

CMutex mutex;

public:

CCountArray2() {};

~CCountArray2() {};

void SetArray(int value);

void GetArray(int dstArray[10]);

}

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

#include "stdafx.h"

#include "CountArray2.h"

void CCountArray2::SetArray(int value)

{

CSingleLock singleLock(&mutex);

singleLock.Lock();

for (int x=0; x<10; ++x)

array[x] = value;

}

void CCountArray2::GetArray(int dstArray[10])

{

CSingleLock singleLock(&mutex);

singleLock.Lock();

for (int x=0; x<10; ++x)

dstArray[x] = array[x];

}

Для получения доступа к объекту мьютекс необходимо создать объект класса CSingleLock для объекта mutex, как показано ниже:

CSingleLock singleLock(&mutex);

Аргумент конструктора является указателем на обеспечивающий синхронизацию потоков объект, с помощью которого и осуществляется управление. Затем для получения доступа к мьютексу вызывается метод Lock() объекта класса CSingleLock:

singleLock.Lock();

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

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

50.Потоки в Visual C++. Работа с критической секцией

Использование критических секций. Критическая секция (Critical Section) это участок кода, в котором поток получает доступ к ресурсу (например, переменной), который доступен из других потоков(см. Рис. 50.1.).

Рис 50.1. Схема критической секции

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

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

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

Для создания в программе, использующей библиотеку MFC, объекта критической секции необходимо создать экземпляр объекта класса ССritical Section, как это показано ниже:

CCriticalSection criticalSection;

Когда в программе необходимо получить доступ к данным, защищенным критической секцией, вызывается метод Lock() объекта этой критической секции, как показано ниже:

criticalSection.Lock();

Если объект критической секции в данный момент не захвачен другим потоком, функция Lock() передаст этот объект во владение данному потоку. Теперь поток может получить доступ к защищенным данным. Завершив обработку данных, поток должен вызвать метод Unlock() объекта критической секции:

criticalSection.Unlock();

Функция Unlock() освобождает объект критической секции. В результате другой поток сможет его захватить и получить доступ к защищенным данным.

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

Для ознакомления с объектом критической секции, создадим в разработанном приложении Example новый пункт Critical Section в меню Thread. При выборе этого пункта будут запускаться две потоковые функции: записи элементов в массив и считывание элементов из массива. Операции чтения и записи в массив защищены критическими секциями.

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

1.С помощью редактора ресурсов добавьте новый пункт Critical Section в меню Thread приложения. Присвойте этому пункту идентификатор ID_CriticalSection.

2.С помощью СlassWizard свяжите команду ID_CriticalSection с функцией обработки сообщения void CExampleView::OnCriticalsection(). Перед тем как добавить новую функцию, убедитесь, что в поле Class Name выбрано значение CExampleView.

3.Щелкните на кнопке Edit Code и введите приведенные ниже операторы в новую функцию OnCriticalsection().

AfxBeginThread(WriteThreadProc,this);

AfxBeginThread(ReadThreadProc,this);

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

4.Выполните необходимые действия по созданию класса CCountArray. Добавьте в проект два новых пустых файла CountArray.h и CountArray.срр, пользуясь меню File->New. Выберите вкладку Files, типы файлов C/C++ Header File и C++ Source File.

Добавьте в пустой файл CountArray.h следующий текст.

#include "afxmt.h"

class CCountArray

{private:

int array[10];

CCriticalSection criticalSection;

public:

CCountArray() {};

~CCountArray() {};

void SetArray(int value); void GetArray(int dstArray[10]);};

В начале файла к программе подключается файл заголовка библиотеки MFC afxmt.h, обеспечивающий доступ к классу CCriticalSection. В объявлении класса CCountArray выполняется объявление целочисленного массива из десяти элементов, предназначенного для хранения защищаемых критической секцией данных, а также объявляется объект критической секции criticalSection. Открытые методы класса CCountArray включают обыкновенный конструктор и деструктор, а также две функции для чтения и записи массива. Именно два последних метода класса и должны работать с объектом критической секции, так как только они имеют доступ к массиву.

5.Добавьте в пустой файл CountArray.cpp следующий текст.

void CCountArray::SetArray(int value){

criticalSection.Lock();

for (int x=0; x<10; ++x)

array[x] = value;

criticalSection.Unlock();}

void CCountArray::GetArray(int dstArray[10]){

criticalSection.Lock();

for (int x=0; x<10; ++x)

dstArray[x] = array[x];

criticalSection.Unlock();}

Каждый метод этого класса обеспечивает захват и освобождение объекта критической секции. Это означает, что любой поток может вызвать эти методы, абсолютно не заботясь о синхронизации потоков. Например, если поток номер один вызовет функцию SetArray(), - первое, что сделает эта функция, -- будет вызов criticalSection.Lock(), которая передаст объект критической секции во владение этому потоку. Затем весь цикл for выполняется в полной уверенности, что его работа не будет прервана другим потоком. Если в это время поток номер два вызовет функцию SetArray() или GetArray(), то очередной вызов criticalSection.Lock() приостановит работу потока до тех пор, пока поток номер один не освободит объект критической секции. А это произойдет тогда, когда функция SetArray() закончит выполнение цикла for и вызовет criticalSection.Unlock(). Затем система возобновит работу потока номер два, передав ему во владение объект критической секции.

...