Реферат: Контроллер связываемых объектов

Реферат: Контроллер связываемых объектов

Разработка программы контроллера автоматически связываемых объектов для управления конструкторской документацией в среде Windows 95/NT.

АННОТАЦИЯ

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

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

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

 Компьютерные средства проектирования, кроме непосредственно компьютерного оборудования, включают в себя программное обеспечение. На нынешнем этапе развития программного обеспечения систем проектирования, имеется много разработок систем автоматизации проектирования. Рынок программного обеспечения насыщен большим количеством разнообразных пакетов прикладных программ включающих в себя различные инструментальные средства, позволяющие во многом упростить работу конструктора ЭВА. Сейчас у нас в стране и за рубежом наиболее распространены такие пакеты программного обеспечения, как PCAD, AutoCAD, MicroCAPS, Pspice, MathCad и другие. Эти программные средства позволяют автоматизировать сложные и однообразные процессы присутствующие на многих этапах проектирования ЭВА. Например, различного рода математические расчеты всевозможной сложности, логическое моделирование схем, разработка топологии микросхем, разводка печатного монтажа печатной платы, создание готовых конструкторских документов высокого качества и т.д.

 Рост популярности автоматизированных систем проектирования возник во многом благодаря улучшению пользовательского интерфейса программного обеспечения в целом и систем проектирования в частности. За последние несколько лет у разработчиков программного обеспечения все большие симпатии вызывает платформа Windows для создания высоко качественных программных продуктов предоставляющих пользователю наиболее удобный для восприятия интерфейс. Удобство интерфейса Windows обусловлено высокими требованиями с эргономической точки зрения предъявленному создателями Windows к своей операционной системе. Свою систему Windows фирма Microsoft создала для платформы IBM, не случайно. Надо отметить значительную популярность в мире компьютеров совместимых с IBM AT. Ставшей в наше время своеобразным мировым эталоном сочетания качества и низкой цены. Более половины компьютерного рынка принадлежит компьютерам совместимым с IBM AT.

 Однако, любой пакет программ не может обеспечить полную универсальность своей системы, но это собственно не к чему. Любое программное обеспечение, благодаря своей специфичности в той или иной области автоматизации проектирования, позволяет получить максимальную эффективность конкретно в своей области. Но, последнее время наметилась тенденция к интеграции программного обеспечения на базе так называемых автоматически связываемых объектов. Этот термин на самом деле означает не интеграцию программ в прямом смысле, а лишь ее эмуляцию. Тем не менее, для конечного пользователя это выглядит как полная интеграция программного обеспечения различных направлений и различных фирм разработчиков программного обеспечения. Идея заключается в том, что любое приложение для Windows, обеспечивающее OLE Automation (Objekt Linking and Embedding Automation - автоматическое связывание и внедрение объектов), может управляться извне другими приложениями, которые пользуются им основываясь на предоставленных приложением программных интерфейсах и таким образом выполнять те же функции, что и приложение прародитель функций.

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

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

1.1. Выбор и обоснование операционной системы

1.1.1. Графические операционные системы

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

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

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

 Графический режим Windows, как и графический режим любой другой графической операционной среды (Windows NТ,ОS/2, Soleras, Motif ) имеет мало общего с знакоместным графическим режимом, доступным во многих программах для МS-DОS, всегда размещающих на экране стандартное количество символов, например 8Оx25 или 80x43. Windows (а следовательно, и любая Windows -программа) позиционирует графические объекты с точностью до пикселя.

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

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

 Выпуск графической операционной оболочки Microsoft Windows 3.0 стал главным событием 1990 года на программном рынке, затмившим одновременное появление IBM OS/2 1.3. Кроме приятного пользовательского интерфейса среда Windows предоставляла значительный комплекс услуг.

 С системой поставлялось большое количество драйверов для самых разных моделей устройств ввода-вывода, таких как видеоадаптеры и принтеры. Широчайшая аппаратная совместимость была одним из факторов успеха Windows. Комплект Windows 3.0 содержал несколько вариантов драйверов для разных моделей клавиатур, мышей и видеоадаптеров и большое количество драйверов принтеров. В Multimedia для Windows 3.0, а затем в Windows 3.1 появились драйверы звуковых карт, МIDI устройств и синтезаторов. Количество наименований поддерживаемых устройств быстро росло...

 1.1.2. Windows 3.Х

 С точки зрения массового пользователя, не избалованного OS/2, Windows 3.0 была действительно передовой средой. Она использовала весь объем памяти, адресуемой микропроцессорами 80286, 80386 и выше. С 32-разрядными микропроцессорами (80386 и выше) и при наличии не менее 2 Мбайт памяти Windows 3.0 могла использовать виртуальную память, то есть работать с некоторым пространством на жестком диске как с продолжением оперативной памяти компьютера, размещая в нем данные и код программ.

 Windows имела многозадачные возможности с кооперативным использованием процессорного времени “одновременно” работающими приложениями. Кооперативную

 многозадачность можно назвать многозадачностью “второй ступени” поскольку она использует более передовые методы, чем .простое переключение задач, реализованное многими известными программами (например, МS-DOS shell из МS-DOS 5.0 при простом переключении активная программа получает все процессорное время, а фоновые приложения полностью замораживаются. При кооперативной многозадачности приложение может захватить фактически столько процессорного времени, сколько оно считает нужным. Все приложения делят процессорное время, периодически опрашивая друг друга.

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

 С апреля 1992 года Windows 3.1 официально именуется операционной системой. Интерфейс ее был несколько улучшен, в частности были усилены возможности управления экранными объектами мышью (Drag - and - drop метод перетаскивания). Windows стала непосредственно поддерживать динамический обмен данными между приложениями (DDЕ - Dynamic Data Exchange ). В систему вошли средства мультимедиа, ранее поставлявшиеся отдельно в пакете Windows Multimedia Extension. Для расширения издательских возможностей в Windows была встроена поддержка системы масштабирования шрифтов TrueType.

 Windows 3.11 for Workgroups (“для рабочих групп”) позиционировалась как самостоятельная сетевая операционная система для одно-ранговой локальной сети, а также как сетевой клиент для сервера Windows NТ. В остальном Windows 3.11 для рабочих групп являлась слегка улучшенной модификацией Windows 3.1, работающей только в 386-м Расширенном режиме на 32-разрядных микропроцессорах.

 А теперь мы постараемся разобраться в том, как устроена Windows.

 Режимы работы Windows 3.X Чтобы запустить мотор Windows на полную мощность, конечно, нужны прежде всего мегабайты и мегабайты оперативной памяти. Но их невозможно использовать на микропроцессорах 8088/86. Не слишком удачным решением был и защищенный режим 80286: для того чтобы использовать на компьютере приложения для новой операционной среды вместе с МS-DOS приложениями, приходилось переключать микропроцессор из защищенного режима в реальный и обратно.

 Здесь уместно вспомнить о том, что фирма Microsoft весьма тесно сотрудничала с Intel во время разработки микропроцессора i80386. Microsoft фактически навязала инженерам Intel собственную концепцию режима виртуального микропроцессора 8086-V86, наиболее удобную для разработки операционной системы, использующей МS-DOS приложения вместе с программами защищенного режима. Поскольку в 1990 году рынок еще не был готов к полному переходу на операционную систему для микропроцессора 80386, Windows 3.О могла функционировать в трех режимах, в каждом из которых микропроцессор и память использовались по-разному.

 В реальном режиме работы Windows система функционировать даже на компьютере с микропроцессором 8088 или 8086, оборудованном только обычной памятью для работы приложений в реальном режиме Windows 3.0 использовалась только обычная память МS-DOS и отображаемая память.

 Стандартный режим Windows 3.0 требовал для работы микропроцессор 80286 и всего 1 Мбайт памяти - 640 Кбайт стандартной и 384 Кбайт дополнительной (настоящая работа начиналась при объеме памяти 4 Мбайт). Для приложений Windows использовалась расширенная память (ХМS). Для программ МS-DOS, загружаемых из-под Windows, применялась обычная память и переключение микропроцессора из защищенного режима в реальный.

 Более полно использовал аппаратные ресурсы 386-й Расширенный режим Windows . В этом режиме версии Windows 3.0 и 3.1 работали с виртуальной памятью, имевший примерно втрое больший объем, чем физическая оперативная память. Приложениям МS DOS в 386-м Расширенном режиме отводилась произвольная область памяти, которая в виртуальном режиме 8086 размечалась как обычная память MS DOS . По умолчанию МS-DOS программы загружались занимая, как обычно, весь экран, но могли быть переведены в графическое окно - стандартное окно Windows. Приложения МS-DOS, запущенное из-под Windows в 386-м Расширенном режиме, работало в виртуальной машине, иными словами, считало себя загруженным на своем собственном компьютере и знать не знало о существовании Windows.

 Разумеется, для работы в 386-м Расширенном режиме требовался компьютер с микропроцессором не ниже 80386. Объявленные требования к объему памяти (2 Мбайт) опять-таки не стоило принимать всерьез. Минимумом являлись 4 Мбайт памяти, а для более или менее серьезной работы требовались 8 Mбайт или больше.

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

 Ядро Windows состоит из трех компонентов Kernel ,User и GDI. При помощи дополнительных DLL-файлов (динамически загружаемых библиотек) поддерживаются отображением стандартных диалоговых окон, протоколы DDЕ (динамического связывания данных) и ОLЕ (связывания и встраивания объектов), взаимодействие с драйверами устройств ввода-вывода и другие черты Windows. Windows -драйверы устройств бывают, кстати, двух видов - “обычные” DLL-драйверы и 386драйверы, последние предназначены опять-таки для работы только в 386-м Расширенном режиме Windows.

 Наиболее низкоуровневой частью ядра Windows является модуль Kernel, управляющий распределением памяти, процессами, файловым вводом-выводом и так далее. В разных режимах работы Windows 3.О функции Kernel выполняли различные файлы: kernel.ЕХЕ для Реального режима krnl286.Еxe для Стандартного режима, КrnlЗ86.ЕХЕ для 38б-го Расширенного режима.

 Так что Windows 3.0 была разработана как операционная система, имеющая три разных ядра. Когда был упразднен Реальный режим работы, из комплекта поставки Windows 3.1 и исчез файл Kernel.dll. Следующий шаг был сделан, Windows 3.11 для рабочих групп - эта система работала только в 386-м Расширенном режиме. Модуль User (user.ЕХЕ) служит для работы с клавиатурой, мышью, таймером и портами, а также выполняет функции отображения элементов графического интерфейса (окон, меню). Он управляет такими драйверами, как, например, различные драйверы клавиатуры и мыши.

 Наконец, модуль GDI (интерфейс графических устройств, файл GDI.ЕХЕ) поддерживает графические процедуры - прорисовку линий, закрашивание, отображение шрифтов (начиная с Windows 3.1 - все операции со шрифтами TrueType) и взаимодействует с драйверами графических устройств - дисплея и принтера. С Windows 3.1 поставлялось более десятка драйверов видеоадаптеров. Для поддержки принтеров в Windows 3.1 впервые была применена архитектура мини-драйверов. Универсальный драйвер принтера NIDRV.DLL выполнял аппаратно-независимые функции печати -несколько десятков мини-драйверов, поставляемых производителями, дополняли универсальный драйвер функциями обходимыми специально для поддержки конкретных устройств и не повторяли уже написанный общий код.

1.1.3. Windows 95

 В 1996 году фирмой Microsoft , была выпушена следующая версия операционной системы Windows. Которая была названа фирмой 32 разрядной многозадачной графической системой. / 1 /

 Архитектура Windows 95.Что должна была сделать Microsoft, чтобы прийти к 32-разрядной операционной системе с обеспечением вытесняющей многозадачности, которая бы при этом оставалась полностью совместима с прикладными программами для Windows 3.x и MS-DOS, не требовала бы для работы самой МS DOS и “умещалась” в четырех мегабайтах оперативной памяти ?

 Фирмой Microsoft уже выпущены системы, удовлетворяющие самым серьезным требованиям к управлению памятью и процессами, - Windows NТ SERVER и Windows NТ workstation (выпущены версии 3.51 и готовятся к выпуску 3.52), Однако эти системы сами предъявляют серьезнейшие требования к аппаратуре, а заодно и к пользователю. Windows NТ SERVER предназначается не для десятков миллионов потребителей Windows, а для сетевого администрирования. Windows NТ workstation нужна тем пользователям, которые используют приложения с высокой интенсивностью вычислительной обработки, тем, кто нуждается в высокой степени безопасности данных, и тем, кто больше беспокоится о надежности системы, чем о совместимости с приложениями для MS DOS и Windows 3.x.

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

 Ядро Windows 95. Ядро Windows 95, как и во всех предыдущих версиях Windows, имеет трехуровневую структуру Kernel -User- GDI. Все эти модули должны бы быть 32-разрядными, но в действительности полностью 32-разрядной сделана только самая низкоуровневая часть ядра Windows 95 - Кегне1. Вполне понятно, что, объявляя о 32-разрядной системе, Microsoft обязана была выполнить в 32-разрядном коде хотя бы такие базовые вещи, как функции ввода- вывода, управления памятью и процессами, поддержку сетевой и файловой систем.

 Что касается двух других модулей ядра, то расчеты показали, что полностью 32-разрядные USER и GDI вместе потребуют для работы более 1 Мбайт памяти, Windows 95 использует 1б-разрядный код, когда он необходим для обеспечения совместимости или если 32-разрядное кодирование нецелесообразно, то есть увеличило бы расход памяти без заметного увеличения производительности.

 Поэтому модуль User, остался в Windows 95 преимущественно 1б-разрядным, а его 32-разрядная часть используется для переадресации вызовов 32-разрядных приложений 16-разрядному блоку. Большая часть функций ОВ1, включая подсистему буферизации входных и выходных потоков, подсистему печати, растеризатор шрифтов TrueТуре и основные операции рисования, перенесена в 32-разрядный модуль, оставшийся 16-разрядный код описывает управление окнами. 16-разрядные функции ядра Windows 95 написаны преимущественно на ассемблере .Что же касается Kernel, то его 16-разрядная часть задействуется только при загрузке Windows 95 и используется только для инициализации 32-разрядной части Kernel. Сам Kernel32 никогда не обращается к Kernel16. На рис.1.2. показано, для каких функций используется 32-разрядный код, а для каких 16-разрядный код модулей ядра Windows 95.

 Многозадачность. Анализируя выполнение под Windows 95 16-разрядных приложений для Windows 3.x и МS-DOS, мы видим по большей части знакомые, хотя и серьезно улучшенные методы Windows 3.x.

 Как показано на рис. 1.3., 16-разрядные приложения для Windows (“приложения win16”) выполняются в общем пространстве адресов в пределах системной виртуальной машины. Такие варианты, как выполнение каждого приложения win16 в отдельной виртуальной машине (что возможно в ОS/2) или полная эмуляция Windows 3.x в пределах операционной системы (как это делается в Windows NТ).

 32-разрядные приложения, созданные с учетом требований Windows 95 (“приложения win32”), выполняются в режиме “подлинной” вытесняющей многозадачности. Кроме того, Windows 95 поддерживает многопоточные приложения, способные запускать параллельно несколько процессов.

 Для каждого win32-приложения и для области адресов приложений win1б используются отдельные очереди сообщений. Таким образом, приложения win16 фактически изолированы от остальных процессов. Кроме того, в Windows 95 примененные методы очистки и восстановления системы в случае ошибок. Если ошибка в программе, выполняющейся под Windows 3.x, могла запросто “обрушить всю” систему, то ошибка в одном из приложений под Windows 95 обычно не влияет на выполнение остальных программ. Низкоуровневые компоненты операционной системы изолированы от прикладных программ, поскольку пользуются сервисом другого уровня защиты микропроцессора 80386.

 Использование памяти. Для разработчиков программного обеспечения 1ВМ РС долгие годы оставалась камнем преткновения сегментированная модель памяти 1б-разрядных микропроцессоров 8088/86 и 80286.

 Сегментом является непрерывная область памяти, адресуемая 16-разрядными числами ( 64 Кбайт ). Для того чтобы использовать более б4 Кбайт памяти, пришлось разработать систему адресации памяти при помощи двух чисел - адреса начала сегмента и 1б-разрядного смещения внутри сегмента. Микропроцессоры 80386, способные оперировать 32-разрядными адресами, могли бы без всяких премудростей ( и отнимающих время вычислений! ) адресовать до 4 Гбайт, оперативной памяти, Но МS-DOS и Windows 3.x вынужденно продолжали использовать устаревшую сегментированную модель памяти.

 Для win32-приложений доступна плоская ( несегментированная) модель памяти Windows 95. Система полностью использует адресуемую память 38б-х процессоров, при этом прикладные программы могут работать с объемом памяти до 2 Гбайт, остальные 2 Гбайт Windows 95 использует для собственных нужд. Файл виртуальной памяти Windows 95 имеет динамический размер, ограниченный только объемом жесткого диска и не зависящий от фрагментации.

 Использование системных ресурсов. Под системными ресурсами в терминологии Windows понимают области памяти, используемые модулями USER и GDI. В ресурсах GDI располагается информация о графических объектах, используемых системой в данный момент. Ресурсы USER включают информацию об окнах, меню и так далее. Для того чтобы максимально ускорить процедуру обращения к ресурсам USER и GDI, в Windows 3.x их объемы ограничили сегментами по б4 Кбайт. Каждое порожденное системой окно отнимало примерно 2% системных ресурсов, а когда процент свободных системных ресурсов падал до 20%, загрузка новых приложений становилась невозможной.

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

 Файловая система. Одно из самых назойливых ограничений систем МS-DOS и Windows 3.x - имена файлов, состоящие не более чем из 11 (8+3) символов. Новая файловая система позволяет win32-приложениям пользоваться длинными (до 255 символов) именами файлов и при этом остается полностью совместимой с FAT. Разумеется, пользоваться такими именами файлов гораздо удобнее.

 Некоторые компоненты новой файловой системы были использованы еще в Windows 3.11 для рабочих групп - драйвер устанавливаемых файловых систем, 32-разрядный драйвер FАТ, 32-разрядное кэширование жесткого диска. Все эти черты получили дальнейшее развитие в Windows 95. Кроме того, появились 32-разрядный драйвер CD-ROM, более мощная подсистема блокового ввода-вывода и другие черты.

Страницы: 1, 2, 3, 4, 5