Данная статья предназначена для начинающих программистов, которые никогда не работали с потоками, и хотели бы узнать основы работы с ними. Желательно, чтоб читатель знал основы ООП и имел какой-нибудь опыт работы в Delphi.
Для начала давайте определимся, что под словом "поток" я подразумеваю именно Thread, который еще имеет название "нить". Нередко встречал на форумах мнения, что потоки не нужны вообще, любую программу можно написать так, что она будет замечательно работать и без них. Конечно, если не делать ничего серьёзней "Hello World" это так и есть, но если постепенно набирать опыт, рано или поздно любой начинающий программист упрётся в возможности "плоского" кода, возникнет необходимость распараллелить задачи. А некоторые задачи вообще нельзя реализовать без использования потоков, например работа с сокетами, COM-портом, длительное ожидание каких-либо событий, и т.д.
Всем известно, что Windows система многозадачная. Попросту говоря, это означает, что несколько программ могут работать одновременно под управлением ОС. Все мы открывали диспетчер задач и видели список процессов. Процесс - это экземпляр выполняемого приложения. На самом деле сам по себе он ничего не выполняет, он создаётся при запуске приложения, содержит в себе служебную информацию, через которую система с ним работает, так же ему выделяется необходимая память под код и данные. Для того, чтобы программа заработала, в нём создаётся поток. Любой процесс содержит в себе хотя бы один поток, и именно он отвечает за выполнение кода и получает на это процессорное время. Этим и достигается мнимая параллельность работы программ, или, как её еще называют, псевдопараллельность. Почему мнимая? Да потому, что реально процессор в каждый момент времени может выполнять только один участок кода. Windows раздаёт процессорное время всем потокам в системе по очереди, тем самым создаётся впечатление, что они работают одновременно. Реально работающие параллельно потоки могут быть только на машинах с двумя и более процессорами.
Для создания дополнительных потоков в Delphi существует базовый класс TThread, от него мы и будем наследоваться при реализации своих потоков. Для того, чтобы создать "скелет" нового класса, можно выбрать в меню File - New - Thread Object, Delphi создаст новый модуль с заготовкой этого класса. Я же для наглядности опишу его в модуле формы. Как видите, в этой заготовке добавлен один метод - Execute. Именно его нам и нужно переопределить, код внутри него и будет работать в отдельном потоке. И так, попробуем написать пример - запустим в потоке бесконечный цикл:
Запустите пример на выполнение и нажмите кнопку. Вроде ничего не происходит - форма не зависла, реагирует на перемещения. На самом деле это не так - откройте диспетчер задач и вы увидите, что процессор загружен по-полной. Сейчас в процессе вашего приложения работает два потока - один был создан изначально, при запуске приложения. Второй, который так грузит процессор - мы создали по нажатию кнопки. Итак, давайте разберём, что же означает код в Button1Click:
тут мы создали экземпляр класса TNewThread. Конструктор Create имеет всего один параметр - CreateSuspended типа boolean, который указывает, запустить новый поток сразу после создания (если false), или дождаться команды (если true).
свойство FreeOnTerminate определяет, что поток после выполнения автоматически завершится, объект будет уничтожен, и нам не придётся его уничтожать вручную. В нашем примере это не имеет значения, так как сам по себе он никогда не завершится, но понадобится в следующих примерах.
Свойство Priority, если вы еще не догадались из названия, устанавливает приоритет потока. Да да, каждый поток в системе имеет свой приоритет. Если процессорного времени не хватает, система начинает распределять его согласно приоритетам потоков. Свойство Priority может принимать следующие значения:
tpTimeCritical - критический
tpHighest - очень высокий
tpHigher - высокий
tpNormal - средний
tpLower - низкий
tpLowest - очень низкий
tpIdle - поток работает во время простоя системы
Ставить высокие приоритеты потокам не стоит, если этого не требует задача, так как это сильно нагружает систему.
Ну и собственно, запуск потока.
Думаю, теперь вам понятно, как создаются потоки. Заметьте, ничего сложного. Но не всё так просто. Казалось бы - пишем любой код внутри метода Execute и всё, а нет, потоки имеют одно неприятное свойство - они ничего не знают друг о друге. И что такого? - спросите вы. А вот что: допустим, вы пытаетесь из другого потока изменить свойство какого-нибудь компонента на форме. Как известно, VCL однопоточна, весь код внутри приложения выполняется последовательно. Допустим, в процессе работы изменились какие-то данные внутри классов VCL, система отбирает время у основного потока, передаёт по кругу остальным потокам и возвращает обратно, при этом выполнение кода продолжается с того места, где приостановилось. Если мы из своего потока что-то меняем, к примеру, на форме, задействуется много механизмов внутри VCL (напомню, выполнение основного потока пока "приостановлено"), соответственно за это время успеют измениться какие-либо данные. И тут вдруг время снова отдаётся основному потоку, он спокойно продолжает своё выполнение, но данные уже изменены! К чему это может привести - предугадать нельзя. Вы можете проверить это тысячу раз, и ничего не произойдёт, а на тысяча первый программа рухнет. И это относится не только к взаимодействию дополнительных потоков с главным, но и к взаимодействию потоков между собой. Писать такие ненадёжные программы конечно нельзя.
Синхронизации потоков
Если вы создали шаблон класса автоматически, то, наверное, заметили комментарий, который дружелюбная Delphi поместила в новый модуль. Он гласит: "Methods and properties of objects in visual components can only be used in a method called using Synchronize". Это значит, что обращение к визуальным компонентам возможно только путём вызова процедуры Synchronize. Давайте рассмотрим пример, но теперь наш поток не будет разогревать процессор впустую, а будет делать что-нибудь полезное, к примеру, прокручивать ProgressBar на форме. В качестве параметра в процедуру Synchronize передаётся метод нашего потока, но сам он передаётся без параметров. Параметры можно передать, добавив поля нужного типа в описание нашего класса. У нас будет одно поле - тот самый прогресс:
Вот теперь ProgressBar двигается, и это вполне безопасно. А безопасно вот почему: процедура Synchronize на время приостанавливает выполнение нашего потока, и передаёт управление главному потоку, т.е. SetProgress выполняется в главном потоке. Это нужно запомнить, потому что некоторые допускают ошибки, выполняя внутри Synchronize длительную работу, при этом, что очевидно, форма зависает на длительное время. Поэтому используйте Synchronize для вывода информации - то самое двигание прогресса, обновления заголовков компонентов и т.д.
Вы наверное заметили, что внутри цикла мы используем процедуру Sleep. В однопоточном приложении Sleep используется редко, а вот в потоках его использовать очень удобно. Пример - бесконечный цикл, пока не выполнится какое-нибудь условие. Если не вставить туда Sleep мы будем просто нагружать систему бесполезной работой.
Надеюсь, вы поняли как работает Synchronize. Но есть еще один довольно удобный способ передать информацию форме - посылка сообщения. Давайте рассмотрим и его. Для этого объявим константу:
В объявление класса формы добавим новый метод, а затем и его реализацию:
Используя функцию SendMessage, мы посылаем окну приложения сообщение, один из параметров которого содержит нужный нам прогресс. Сообщение становится в очередь, и согласно этой очереди будет обработано главным потоком, где и выполнится метод SetProgressPos. Но тут есть один нюанс: SendMessage, как и в случае с Synchronize, приостановит выполнение нашего потока, пока основной поток не обработает сообщение. Если использовать PostMessage этого не произойдёт, наш поток отправит сообщение и продолжит свою работу, а уж когда оно там обработается - неважно. Какую из этих функций использовать - решать вам, всё зависит от задачи.
Вот, в принципе, мы и рассмотрели основные способы работы с компонентами VCL из потоков. А как быть, если в нашей программе не один новый поток, а несколько? И нужно организовать работу с одними и теми же данными? Тут нам на помощь приходят другие способы синхронизации. Один из них мы и рассмотрим. Для его реализации нужно добавить в проект модуль SyncObjs.
Критические секции
Работают они следующим образом: внутри критической секции может работать только один поток, другие ждут его завершения. Чтобы лучше понять, везде приводят сравнение с узкой трубой: представьте, с одной стороны "толпятся" потоки, но в трубу может "пролезть" только один, а когда он "пролезет" - начнёт движение второй, и так по порядку. Еще проще понять это на примере и тем же ProgressBar'ом. Итак, запустите один из примеров, приведённых ранее. Нажмите на кнопку, подождите несколько секунд, а затем нажмите еще раз. Что происходит? ProgressBar начал прыгать. Прыгает потому, что у нас работает не один поток, а два, и каждый из них передаёт разные значения прогресса. Теперь немного переделаем код, в событии onCreate формы создадим критическую секцию:
У TCriticalSection есть два нужных нам метода, Enter и Leave, соответственно вход и выход из неё. Поместим наш код в критическую секцию:
Попробуйте запустить приложение и нажать несколько раз на кнопку, а потом посчитайте, сколько раз пройдёт прогресс. Понятно, в чем суть? Первый раз, нажимая на кнопку, мы создаём поток, он занимает критическую секцию и начинает работу. Нажимаем второй - создаётся второй поток, но критическая секция занята, и он ждёт, пока её не освободит первый. Третий, четвёртый - все пройдут только по-очереди.
Критические секции удобно использовать при обработке одних и тех же данных (списков, массивов) разными потоками. Поняв, как они работают, вы всегда найдёте им применение.
В этой небольшой статье рассмотрены не все способы синхронизации, есть еще события (TEvent), а так же объекты системы, такие как мьютексы (Mutex), семафоры (Semaphore), но они больше подходят для взаимодействия между приложениями. Остальное, что касается использования класса TThread, вы можете узнать самостоятельно, в help'е всё довольно подробно описано. Цель этой статьи - показать начинающим, что не всё так сложно и страшно, главное разобраться, что есть что. И побольше практики - самое главное опыт!
Компоненты Delphi для работы с базами данных были созданы в расчете на работу с SQL и архитектурой клиент/сервер. При работе с ними вы можете воспользоваться характеристиками расширенной поддержки удаленных серверов. Delphi осуществляет эту поддержку двумя способами.
1. Введение
Во-первых, непосредственные команды из Delphi позволяют разработчику управлять таблицами, устанавливать пределы, удалять, вставлять и редактировать существующие записи.
Второй способ заключается в использовании запросов на языке SQL, где строка запроса передается на сервер для ее разбора, оптимизации, выполнения и передачи обратно результатов.
Данный документ делает акцент на втором методе доступа к базам данных, на основе запросов SQL (pass-through). Авторы не стремились создать курсы по изучению синтаксиса языка SQL и его применения, они ставили перед собой цель дать несколько примеров использования компонентов TQuery и TStoredProc. Но чтобы сделать это, необходимо понимать концепцию SQL и знать как работают selects, inserts, updates, views, joins и хранимые процедуры (stored procedures). Документ также вскользь касается вопросов управления транзакциями и соединения с базой данных, но не акцентирует на этом внимание. Итак, приступая к теме, создайте простой запрос типа SELECT и отобразите результаты.
2. Компонент TQuery
Если в ваших приложениях вы собираетесь использовать SQL, то вам непременно придется познакомиться с компонентом TQuery. Компоненты TQuery и TTable наследуются от TDataset. TDataset обеспечивает необходимую функциональность для получения доступа к базам данных. Как таковые, компоненты TQuery и TTable имеют много общих признаков. Для подготовки данных для показа в визуальных компонентах используется все тот же TDatasource. Также, для определения к какому серверу и базе данных необходимо получить доступ, необходимо задать имя псевдонима. Это должно выполняться установкой свойства aliasName объекта TQuery.
Свойство SQL
Все же TQuery имеет некоторую уникальную функциональность. Например, у TQuery имеется свойство с именем SQL. Свойство SQL используется для хранения SQL-запроса. Ниже приведены основные шаги для составления запроса, где все служащие имеют зарплату свыше $50,000.
Создайте объект TQuery
Задайте псевдоним свойству DatabaseName. (Данный пример использует псевдоним IBLOCAL, связанный с демонстрационной базой данных employee.gdb).
Выберите свойство SQL и щелкните на кнопке с текстом - '...' (три точки, Инспектор Объектов - В.О.). Должен появиться диалог редактора списка строк (String List Editor).
Введите:
. Нажмите OK.
Выберите в Инспекторе Объектов свойство Active и установите его в TRUE.
Разместите на форме объект TDatasource.
Установите свойство Dataset у TDatasource в Query1.
Разместите на форме TDBGrid.
Установите его свойство Datasource в Datasource1.
Свойство SQL имеет тип TStrings. Объект TStrings представляет собой список строк, и чем-то похож на массив. Тип данных TStrings имеет в своем арсенале команды добавления строк, их загрузки из текстового файла и обмена данными с другим объектом TStrings. Другой компонент, использующий TStrings - TMemo. В демонстрационном проекте ENTRSQL.DPR (по идее, он должен находится на отдельной дискетте, но к "Советам по Delphi" она не прилагается - В.О.), пользователь должен ввести SQL-запрос и нажать кнопку "Do It" ("сделать это"). Результаты запроса отображаются в табличной сетке. В Листинге 1 полностью приведен код обработчика кнопки "Do It".
Листинг 1
Свойство Params
Этого должно быть достаточно для пользователя, знающего SQL. Тем не менее, большинство пользователей не знает этого языка. Итак, ваша работа как разработчика заключается в предоставлении интерфейса и создании SQL-запроса. В Delphi, для создания SQL-запроса на лету можно использовать динамические запросы. Динамические запросы допускают использование параметров. Для определения параметра в запросе используется двоеточие (:), за которым следует имя параметра. Ниже приведе пример SQL-запроса с использованием динамического параметра:
Если вам нужно протестировать, или установить для параметра значение по умолчанию, выберите свойство Params объекта Query1. Щелкните на кнопке '...'. Должен появиться диалог настройки параметров. Выберите параметр Dept_no. Затем в выпадающем списке типов данных выберите Integer. Для того, чтобы задать значение по умолчанию, введите нужное значение в поле редактирования "Value".
Для изменения SQL-запроса во время выполнения приложения, параметры необходимо связать (bind). Параметры могут изменяться, запрос выполняться повторно, а данные обновляться. Для непосредственного редактирования значения параметра используется свойство Params или метод ParamByName. Свойство Params представляет из себя массив TParams. Поэтому для получения доступа к параметру, необходимо указать его индекс. Для примера,
Query1.params[0].asInteger := 900;
Свойство asInteger читает данные как тип Integer (название говорит само за себя). Это не обязательно должно указывать но то, что поле имеет тип Integer. Например, если тип поля VARCHAR(10), Delphi осуществит преобразование данных. Так, приведенный выше пример мог бы быть записан таким образом:
Query1.params[0].asString := '900';
или так:
Query1.params[0].asString := edit1.text;
Если вместо номера индекса вы хотели бы использовать имя параметра, то воспользуйтесь методом ParamByName. Данный метод возвращает объект TParam с заданным именем. Например:
Query1.ParamByName('DEPT_NO').asInteger := 900;
В листинге 2 приведен полный код примера.
Листинг 2
Обратите внимание на процедуру, первым делом подготовливающую запрос. При вызове метода prepare, Delphi посылает SQL запрос на удаленный сервер. Сервер выполняет грамматический разбор и оптимизацию запроса. Преимущество такой подготовки запроса состоит в его предварительном разборе и оптимизации. Альтернативой здесь может служить подготовка сервером запроса при каждом его выполнении. Как только запрос подготовлен, подставляются необходимые новые параметры, и запрос выполняется.
[pagebreak]
Источник данных
В предыдущем примере пользователь мог ввести номер отдела, и после выполнения запроса отображался список сотрудников этого отдела. А как насчет использования таблицы DEPARTMENT, позволяющей пользователю легко перемещаться между пользователями и отделами?
Примечание: Следующий пример использует TTable с именем Table1. Для Table1 имя базы данных IBLOCAL, имя таблицы - DEPARTMENT. DataSource2 TDatasource связан с Table1. Таблица также активна и отображает записи в TDBGrid.
Способ подключения TQuery к TTable - через TDatasource. Есть два основных способа сделать это. Во-первых, разместить код в обработчике события TDatasource OnDataChange. Например, листинг 3 демонстрирует эту технику.
Листинг 3 - Использования события OnDataChange для просмотра дочерних записей
Техника с использованием OnDataChange очень гибка, но есть еще легче способ подключения Query к таблице. Компонент TQuery имеет свойство Datasource. Определяя TDatasource для свойства Datasource, объект TQuery сравнивает имена параметров в SQL-запросе с именами полей в TDatasource. В случае общих имен, такие параметры заполняются автоматически. Это позволяет разработчику избежать написание кода, приведенного в листинге 3 (*** приведен выше ***).
Фактически, техника использования Datasource не требует никакого дополнительного кодирования. Для поключения запроса к таблице DEPT_NO выполните действия, приведенные в листинге 4.
Листинг 4 - Связывание TQuery c TTable через свойство Datasource
Выберите у Query1 свойство SQL и введите:
Выберите свойство Datasource и назначьте источник данных, связанный с Table1 (Datasource2 в нашем примере)
Выберите свойство Active и установите его в True
Это все, если вы хотите создать такой тип отношений. Тем не менее, существуют некоторые ограничения на параметризованные запросы. Параметры ограничены значениями. К примеру, вы не можете использовать параметр с именем Column или Table. Для создания запроса, динамически изменяемого имя таблицы, вы могли бы использовать технику конкатенации строки. Другая техника заключается в использовании команды Format.
Команда Format
Команда Format заменяет параметры форматирования (%s, %d, %n и пр.) передаваемыми значениями. Например,
Format('Select * from %s', ['EMPLOYEE'])
Результатом вышеприведенной команды будет 'Select * from EMPLOYEE'. Функция буквально делает замену параметров форматирования значениями массива. При использовании нескольких параметров форматирования, замена происходит слева направо. Например,
Результатом команды форматирования будет 'Select * from EMPLOYEE where EMP_ID=3'. Такая функциональность обеспечивает чрезвычайную гибкость при динамическом выполнении запроса. Пример, приведенный ниже в листинге 5, позволяет вывести в результатах поле salary. Для поля salary пользователь может задавать критерии.
Листинг 5 - Использование команды Format для создания SQL-запроса
В этом примере мы используем методы Clear и Add свойства SQL. Поскольку "подготовленный" запрос использует ресурсы сервера, и нет никакой гарантии что новый запрос будет использовать те же таблицы и столбцы, Delphi, при каждом изменении свойства SQL, осуществляет операцию, обратную "подготовке" (unprepare). Если TQuery не был подготовлен (т.е. свойство Prepared установлено в False), Delphi автоматически подготавливает его при каждом выполнении. Поэтому в нашем случае, даже если бы был вызван метод Prepare, приложению от этого не будет никакой пользы.
Open против ExecSQL
В предыдущих примерах TQuerie выполняли Select-запросы. Delphi рассматривает результаты Select-запроса как набор данных, типа таблицы. Это просто один класс допустимых SQL-запросов. К примеру, команда Update обновляет содержимое записи, но не возвращает записи или какого-либо значения. Если вы хотите использовать запрос, не возвращающий набор данных, используйте ExecSQL вместо Open. ExecSQL передает запрос для выполнения на сервер. В общем случае, если вы ожидаете, что получите от запроса данные, то используйте Open. В противном случае допускается использование ExecSQL, хотя его использование с Select не будет конструктивным. Листинг 6 содержит код, поясняющий сказанное на примере.
Листинг 6
Все приведенные выше примеры предполагают использования в ваших приложениях запросов. Они могут дать солидное основание для того, чтобы начать использовать в ваших приложениях TQuery. Но все же нельзя прогнозировать конец использования SQL в ваших приложених. Типичные серверы могут предложить вам другие характеристики, типа хранимых процедур и транзакций. В следующих двух секциях приведен краткий обзор этих средств.
[pagebreak]
3. Компонент TStoredProc
Хранимая процедура представляет собой список команд (SQL или определенного сервера), хранимых и выполняемых на стороне сервера. Хранимые процедуры не имеют концептуальных различий с другими типами процедур. TStoredProc наследуется от TDataset, поэтому он имеет много общих характеристик с TTable и TQuery. Особенно заметно сходство с TQuery. Поскольку хранимые процедуры не требуют возврата значений, те же правила действуют и для методов ExecProc и Open. Каждый сервер реализует работу хранимых процедур с небольшими различиями. Например, если в качестве сервера вы используете Interbase, хранимые процедуры выполняются в виде Select-запросов. Например, чтобы посмотреть на результаты хранимой процедуры, ORG_CHART, в демонстрационной базе данных EMPLOYEE, используйте следующих SQL-запрос:
При работе с другими серверами, например, Sybase, вы можете использовать компонент TStoredProc. Данный компонент имеет свойства для имен базы данных и хранимой процедуры. Если процедура требует на входе каких-то параметров, используйте для их ввода свойство Params.
4. TDatabase
Компонент TDatabase обеспечивает функциональность, которой не хватает TQuery и TStoredProc. В частности, TDatabase позволяет создавать локальные псевдонимы BDE, так что приложению не потребуются псевдонимы, содержащиеся в конфигурационном файле BDE. Этим локальным псевдонимом в приложении могут воспользоваться все имеющиеся TTable, TQuery и TStoredProc. TDatabase также позволяет разработчику настраивать процесс подключения, подавляя диалог ввода имени и пароля пользователя, или заполняя необходимые параметры. И, наконец, самое главное, TDatabase может обеспечивать единственную связь с базой данных, суммируя все операции с базой данных через один компонент. Это позволяет элементам управления для работы с БД иметь возможность управления транзакциями.
Транзакцией можно считать передачу пакета информации. Классическим примером транзакции является передача денег на счет банка. Транзакция должна состоять из операции внесения суммы на новый счет и удаления той же суммы с текущего счета. Если один из этих шагов по какой-то причине был невыполнен, транзакция также считается невыполненной. В случае такой ошибки, SQL сервер позволяет выполнить команду отката (rollback), без внесения изменений в базу данных. Управление транзакциями зависит от компонента TDatabase. Поскольку транзакция обычно состоит из нескольких запросов, вы должны отметить начало транзакции и ее конец. Для выделения начала транзакции используйте TDatabase.BeginTransaction. Как только транзакция начнет выполняться, все выполняемые команды до вызова TDatabase.Commit или TDatabase.Rollback переводятся во временный режим. При вызове Commit все измененные данные передаются на сервер. При вызове Rollback все изменения теряют силу. Ниже в листинге 7 приведен пример, где используется таблица с именем ACCOUNTS. Показанная процедура пытается передать сумму с одного счета на другой.
Листинг 7
И последнее, что нужно учесть при соединении с базой данных. В приведенном выше примере, TDatabase использовался в качестве единственного канала для связи с базой данных, поэтому было возможным выполнение только одной транзакции. Чтобы выполнить это, было определено имя псевдонима (Aliasname). Псевдоним хранит в себе информацию, касающуюся соединения, такую, как Driver Type (тип драйвера), Server Name (имя сервера), User Name (имя пользователя) и другую. Данная информация используется для создания строки соединения (connect string). Для создания псевдонима вы можете использовать утилиту конфигурирования BDE, или, как показано в примере ниже, заполнять параметры во время выполнения приложения.
TDatabase имеет свойство Params, в котором хранится информация соединения. Каждая строка Params является отдельным параметром. В приведенном ниже примере пользователь устанавливает параметр User Name в поле редактирования Edit1, а параметр Password в поле Edit2. В коде листинга 8 показан процесс подключения к базе данных:
Листинг 8
Этот пример показывает как можно осуществить подключение к серверу без создания псевдонима. Ключевыми моментами здесь являются определение DriverName и заполнение Params информацией, необходимой для подключения. Вам не нужно определять все параметры, вам необходимо задать только те, которые не устанавливаются в конфигурации BDE определенным вами драйвером базы данных. Введенные в свойстве Params данные перекрывают все установки конфигурации BDE. Записывая параметры, Delphi заполняет оставшиеся параметры значениями из BDE Config для данного драйвера. Приведенный выше пример также вводит такие понятия, как сессия и метод GetTableNames. Это выходит за рамки обсуждаемой темы, достаточно упомянуть лишь тот факт, что переменная session является дескриптором database engine. В примере она добавлена только для "показухи".
Другой темой является использование SQLPASSTHRU MODE. Этот параметр базы данных отвечает за то, как натив-команды базы данных, такие, как TTable.Append или TTable.Insert будут взаимодействовать с TQuery, подключенной к той же базе данных. Существуют три возможных значения: NOT SHARED, SHARED NOAUTOCOMMIT и SHARED AUTOCOMMIT. NOT SHARED означает, что натив-команды используют одно соединение с сервером, тогда как запросы - другое. Со стороны сервера это видится как работа двух разных пользователей. В любой момент времени, пока транзакция активна, натив-команды не будут исполняться (committed) до тех пор, пока транзакция не будет завершена. Если был выполнен TQuery, то любые изменения, переданные в базу данных, проходят отдельно от транзакции.
Два других режима, SHARED NOAUTOCOMMIT и SHARED AUTOCOMMIT, делают для натив-команд и запросов общим одно соединение с сервером. Различие между двумя режимами заключаются в передаче выполненной натив-команды на сервер. При выбранном режиме SHARED AUTOCOMMIT бессмысленно создавать транзакцию, использующую натив-команды для удаления записи и последующей попыткой осуществить откат (Rollback). Запись должна быть удалена, а изменения должны быть сделаны (committed) до вызова команды Rollback. Если вам нужно передать натив-команды в пределах транзакции, или включить эти команды в саму транзакцию, убедитесь в том, что SQLPASSTHRU MODE установлен в SHARED NOAUTOCOMMIT или в NOT SHARED.
5. Выводы
Delphi поддерживает множество характеристик при использовании языка SQL с вашими серверами баз данных. На этой ноте разрешите попрощаться и пожелать почаще использовать SQL в ваших приложениях.
1. Нужно создать resource script file (*.RC) с помощью простого текстового файла (например блокнота), и вписать всего одну строку:
1 RCDATA "MyPic.jpg"
Единичка – это просто номер ресурса, RCDATA - определяет, что мы имеем дело с user-defined resource. Последнее – имя файла с JPG рисунком.
2. Компилируем его в .RES файл, при помощи BRCC32.EXE. В MS-DOS набираем:
BRCC32 MyPic.RC
Это должно создать файл MyPic.RES.
3. Добавляем директиву компилятор в исходный код нашей программы. Она должна следовать за директивой формы, как показано здесь:
{$R *.DFM}
{$R MyPic.RES}
4. Добавляем следующую процедуру в программу:
Код:
Посмотрите на второй параметр процедуры CreateFromID объекта TresourceStream. Это просто индекс ресурса. Вы можете включить более, чем один jpeg в своей программе просто добавляя новую строчку для каждого jpeg (с другим индексом) в .RC файл.
Доступность оборудования и простота организации делают беспроводные локальные сети всё более популярными. Даже небольшие компании стараются идти в ногу со временем и избавляются от традиционных кабельных "локалок". Использование беспроводных сетей не ограничивается небольшими офисами и домашними системами - крупные же фирмы применяют Wi-Fi для подключения к корпоративным сетевым ресурсам в тех местах, где технически невозможна прокладка кабелей.
Однако решение об устройстве беспроводной сети далеко не всегда оправданно, тем более что во многих случаях безопасности таких сетей уделяется слишком мало внимания. По оценкам специалистов, почти 70 процентов удачных хакерских атак через беспроводные сети связаны с неправильной настройкой точек доступа и клиентского программного обеспечения, а также с установкой чересчур низкого уровня безопасности при слишком сильном сигнале, с лёгкостью "пробивающего" стены офиса.
По каким-то необъяснимым причинам организаторы беспроводных сетей нередко считают, что при их включении автоматически обеспечивается надлежащий уровень безопасности. Производители оборудования, в свою очередь, устанавливают низкие настройки безопасности "по умолчанию", либо вовсе отключают их, чтобы при развёртывании сети клиенты случайно не столкнулись с невозможностью доступа. При минимальных настройках безопасность оборудование лучше всего совместимо с самым широким спектром других устройств и практически с любым современным программным обеспечением. Поэтому после настройки и проверки сети на совместимость с существующей инфраструктурой системный администратор должен изменить настройки безопасности, для того чтобы предотвратить несанкционированное проникновение в корпоративную сеть.
В отличие от проводных сетей, беспроводные требуют повышенного внимания к безопасности, поскольку проникнуть в них гораздо проще, поскольку для этого не нужен физический доступ к каналу. Радиоволны можно принимать на любое совместимое устройство, а если данные не защищены, то их сможет перехватить любой желающий. Разумеется, не стоит отказываться от паролей прочих традиционных средств авторизации, однако их явно недостаточно для защиты от несанкционированного доступа. Рассмотрим вкратце несколько способов повышения защищённости беспроводных сетей.
Отключаем передачу SSID
Последовательность цифр и букв, называемая SSID (Service Set Identifier) - это уникальный идентификатор вашей беспроводной сети. Передача идентификатора сети является встроенным средством защиты, по умолчанию включённым в большей части продающегося сегодня оборудования, и оно позволяет с лёгкостью обнаружить имеющиеся точки доступа в процессе развёртывания сети. Передача SSID требуется именно для того, чтобы ваше оборудование смогло подключиться к сети.
Точки доступа, которые являются базовыми станциями для подключаемых к сети компьютеров, являются потенциальным слабым местом, через которое злоумышленник может проникнуть в сеть. На уровне точек доступа отсутствует система авторизации по умолчанию, что делает внутренние сети незащищёнными, поэтому системные администраторы должны реализовать существующую корпоративную систему в беспроводных базовых станциях.
Для обеспечения повышенной безопасности можно запретить трансляцию точками доступа идентификатора сети. При этом возможность подключения к сети остаётся только у тех, кто знает правильный SSID, то есть, у сотрудников вашей компании, а случайные пользователи, обнаружившие вашу сеть при помощи сканирования, просто не смогут получить к ней доступ. Отключение передачи SSID возможно в подавляющем большинстве устройств ведущих производителей, что позволяет фактически скрыть вашу сеть от чужих. Если ваша сеть не передаёт идентификаторов, и если вы не афишируете использование беспроводной технологии, то этим вы осложните задачу злоумышленников. Подробные инструкции по отключению SSID обычно приводятся в руководствах по эксплуатации беспроводных точек доступа или маршрутизаторов.
Включаем средства шифрования
Уже давно используемое при пересылке важной электронной корреспонденции шифрование данных нашло применение и в беспроводных сетях. Для защиты данных от чужих глаз, в аппаратуре для беспроводной связи реализованы различные криптографические алгоритмы. При покупке оборудования важно убедиться в том, что оно поддерживает не только низкоуровневое 40-разрядное шифрование, но и 128-битный шифр повышенной стойкости.
Чтобы включить криптографическую защиту можно задействовать системы WEP (Wired Equivalent Privacy - "эквивалент проводной безопасности") или WPA (Wi-Fi Protected Access - "защищённый доступ к Wi-Fi"). Первая система менее стойкая, поскольку в ней используются статические (постоянные) ключи. Защищённые по этому протоколу сети взламываются хакерами без особого труда - соответствующие утилиты нетрудно найти в интернете. Тем не менее, по оценкам специалистов, даже этот протокол не задействован в более половины работающих корпоративных беспроводных сетей. Одним из средств повышения действенности WEP является регулярная автоматическая смена ключей, но даже в этом случае сеть не получает стопроцентной защиты. Попытки проникнуть в такую сеть оставят лишь случайные люди, обнаружившие её, но злонамеренных специалистов WEP не остановит, поэтому для полноценной защиты корпоративных сетей данный протокол использоваться не может.
В недалёком прошлом у организаторов беспроводных сетей не было иного выбора, как использовать протокол WEP, поддержка которого сохраняется в современных устройствах как в целях обеспечения совместимости оборудования, так и для обеспечения хотя бы минимального уровня безопасности в случае невозможности использования более современных протоколов. Сегодня WEP реализуется в двух модификациях: с 64- и 128-разрядным шифрованием. Однако корректнее было бы говорить о ключах длиной 40 и 104 бит, поскольку 24 бит из каждого ключа содержат служебную информацию и никак не влияют на стойкость кода. Однако это не столь важно, поскольку главным недостатком WEP являются статические ключи, для подбора которых злоумышленникам необходимо лишь в течение определённого времени сканировать сеть, перехватывая передаваемую информацию.
Повторим, что более-менее приемлемый уровень безопасность можно лишь при помощи регулярной смены ключей и при использовании 128-битного шифрования. Частота смены ключей зависит от частоты и длительности соединений, при этом необходимо обеспечить отработанную защищённую процедуру передачи новых ключей тем сотрудникам, которые пользуются доступом в беспроводную сеть.
Более эффективное шифрование обеспечивает протокол WPA, в котором реализовано динамическое создание ключей, что исключает возможность перехвата или подбора ключа, а также система идентификации (логин-пароль) при подключении к сети на основе протокола EAC (Extensible Authentication Protocol - "расширяемый протокол аутентификации"). В протоколе WPA 128-разрядные ключи генерируются автоматически при передаче каждых десяти килобайт данных, причём число этих ключей достигает сотен миллиардов, что делает практически невозможным подбор при помощи сканирования даже при отработанной методике перехвата информации. Кроме того, в этом протоколе реализован алгоритм проверки целостности данных MIC (Message Integrity Check), предотвращающий возможность злонамеренного изменения передаваемых данных. А вот выбору паролей следует уделять особое внимание: по мнению экспертов, для обеспечения высокого уровня безопасности длина пароля должна составлять не менее 20 знаков, причём он не должен представлять собой набор слов или какую-то фразу, поскольку такие пароли легко вскрываются методом словарного подбора.
Проблема с WPA заключается в том, что официально он был внесён в спецификации IEEE 802.11 лишь в середине 2004 года, поэтому далеко не всё беспроводное оборудование, выпущенное более полутора лет назад, способно работать по этому стандарту. Более того, если в сети есть хотя бы одно устройство, не поддерживающее WPA, будет применяться простое шифрование WEP, даже если WPA включён в настройках всего прочего оборудования.
Тем не менее, оборудование постоянно совершенствуется и в современных устройствах поддерживается новая, ещё более защищённая версия WPA2, работающая с динамическими ключами длиной 128, 192 и 256 бит. К таким устройствам, относится, например, трёхдиапазонный контроллер Intel PRO/Wireless 2915ABG.
Регулируем силу сигнала и его направленность
Технология беспроводной связи сама по себе по своей природе меньше защищена от постороннего вмешательства, поэтому при организации таких сетей особенно важно максимально затруднить несанкционированное проникновение в них. Среди чисто технических способов самым эффективным является снижение мощности транслируемого сигнала, ведь радиоволны с лёгкостью преодолевают стены зданий, а в сельской равнинной местности могут преодолевать весьма большие расстояния. Злоумышленники могут поставить свой автомобиль рядом со зданием, в котором расположен ваш офис, и в комфортной обстановке неторопливо подбирать ключ к вашей сети. Поэтому важно отрегулировать мощность сигнала, чтобы он не проникал за границы вашей территории. Кроме того, точки доступа следует располагать вдалеке от окон, внешних стен зданий, общих коридоров, холлов и лестниц.
Беспроводные сети являются очень удобным средством связи быстрого развёртывания, позволяющим объёдинить в сеть компьютеры даже в тех местах, где по тем или иным причинам невозможна прокладка кабеля. Однако поскольку незащищённые беспроводные сети куда проще поддаются взлому, чем проводные, следует уделять повышенное внимание защите от постороннего проникновения. Разумеется, стопроцентной гарантии безопасности дать невозможно, но некоторые действенные способы затруднения несанкционированного доступа в беспроводные сети мы описали в данном материале. Более подробные инструкции по реализации этих методов на практике обычно приводятся в документации к сетевому оборудованию, поэтому мы не ставили перед собой цели описать конкретные действия, тем более что они различаются в зависимости от модели и производителя беспроводных точек доступа и маршрутизаторов. Надеемся, что этот материал привлечёт внимание к проблеме обеспечения защиты беспроводных сетей.
Графический интерфейс операционной системы Windows поддерживает копирование (перенос) файлов при помощи мыши. Это реализуется технологией Drag and Drop. Если ваша программа много работает с файлами, то можно облегчить процесс открытия файлов. Метод Drag and Drop позволяет отказаться от стандартной схемы открытия файлов при помощи диалогов открытия файлов.
Используя Drag'n'Drop вы можете перенести мышью объект рабочего стола (проводника) на форму программы и этот объект будет найден и обработан. Технология Drag and Drop поддерживает следующие объекты: файлы, папки, ярлыки, ссылки интернет и др. Функция Drag'n'Drop является родной функцией проводника (Windows Explorer),
то есть она поддерживается не операционной системой, оболочкой. Поэтому, если вы пользуетесь другой оболочкой (напр. DesqView), то поддержка Drag and Drop не гарантируется.
Реализация
Для того, чтобы реализовать этот метод на Delphi, необходимо:
1) Подключить модуль ShellApi в секции Uses в Unit1 формы. 2) Затем в Unit1, найти оператор private и выше него добавить следующие строки:
3) Добавить в Unit1 процедуру WMDropFiles и ввести её тело:
4) Чтобы форма могла принимать объекты, необходимо в обработчик события OnCreate, записать:
Заключение
Технология Drag and Drop очень облегчает работу с такими программами, как кодировщики музыки, интернет-качалки, файловые утилиты и архиваторы.
Все очень просто. Если у таблицы высота строки - 12 пикселей, печатная форма выгружается мгновенно. Поэтому перед Таб.Показать() вставляем 2 строчки...
Все очень просто. Если у таблицы высота строки - 12 пикселей, печатная форма выгружается мгновенно. Поэтому перед Таб.Показать() вставляем 2 строчки:
Как вариант - можно открывать отчет сразу в Экселе, используя следующую глобальную процедуру (естественно, показ в 1С можно закомментировать)
Главное о чем стоит упомянуть это, что ваш хранитель экрана будет работать в фоновом режиме и он не должен мешать работе других запущенных программ. Поэтому сам хранитель должен быть как можно меньшего объема. Для уменьшения объема файла в описанной ниже программе не используется визуальные компоненты Delphi, включение хотя бы одного из них приведет к увеличению размера файла свыше 200кб, а так, описанная ниже программа, имеет размер всего 20кб!!!
Технически, хранитель экрана является нормальным EXE файлом (с расширением .SCR), который управляется через командные параметры строки. Например, если пользователь хочет изменить параметры вашего хранителя, Windows выполняет его с параметром "-c" в командной строке. Поэтому начать создание вашего хранителя экрана следует с создания примерно следующей функции:
Поскольку нам нужно создавать небольшое окно предварительного просмотра и полноэкранное окно, их лучше объединить используя единственный класс окна. Следуя правилам хорошего тона, нам также нужно использовать многочисленные нити. Дело в том, что, во-первых, хранитель не должен переставать работать даже если что-то "тяжелое" случилось, и во-вторых, нам не нужно использовать таймер.
Процедура для запуска хранителя на полном экране - приблизительно такова:
Во-первых, мы проинициализировали некоторые глобальные переменные (описанные далее), затем прячем курсор мыши и создаем окно хранителя экрана. Имейте в виду, что важно уведомлять Windows, что это - хранителя экрана через SystemParametersInfo (это выводит из строя Ctrl-Alt-Del чтобы нельзя было вернуться в Windows не введя пароль). Создание окна хранителя:
Теперь окна созданы используя вызовы API. Я удалил проверку ошибки, но обычно все проходит хорошо, особенно в этом типе приложения.
Теперь Вы можете погадать, как мы получим handle родительского окна предварительного просмотра ? В действительности, это совсем просто: Windows просто передает handle в командной строке, когда это нужно. Таким образом:
Как Вы видите, window handle является вторым параметром (после "-p").
Чтобы "выполнять" хранителя экрана - нам нужна нить. Это создается с вышеуказанным CreateThread. Процедура нити выглядит примерно так:
Нить просто заставляет обновляться изображения в нашем окне, спит на некоторое время, и обновляет изображения снова. А Windows будет посылать сообщение WM_PAINT на наше окно (не в нить !). Для того, чтобы оперировать этим сообщением, нам нужна процедура:
Если мышь перемещается, кнопка нажала, мы спрашиваем у пользователя пароль:
Это также демонстрирует использование registry на уровне API. Также имейте в виду как мы динамически загружаем функции пароля, используюя LoadLibrary. Запомните тип функции?
TVSSFunc ОПРЕДЕЛЕН как:
Теперь почти все готово, кроме диалога конфигурации. Это запросто:
Трудная часть -это создать диалоговый сценарий (запомните: мы не используем здесь Delphi формы!). Я сделал это, используя 16-битовую Resource Workshop (остался еще от Turbo Pascal для Windows). Я сохранил файл как сценарий (текст), и скомпилированный это с BRCC32:
Почти также легко сделать диалоговое меню:
После того, как пользователь выбрал некоторые установочные параметры, нам нужно сохранить их.
Загружаем параметры так:
Легко? Нам также нужно позволить пользователю, установить пароль. Я честно не знаю почему это оставлено разработчику приложений ! Тем не менее:
Мы динамически загружаем (недокументированную) библиотеку MPR.DLL, которая имеет функцию, чтобы установить пароль хранителя экрана, так что нам не нужно беспокоиться об этом.
TPCPAFund ОПРЕДЕЛЕН как:
(Не спрашивайте меня что за параметры B и C ! :-)
Теперь единственная вещь, которую нам нужно рассмотреть, - самая странная часть: создание графики. Я не великий ГУРУ графики, так что Вы не увидите затеняющие многоугольники, вращающиеся в реальном времени. Я только сделал некоторые ящики.
И последнее - глобальные переменные:
Затем исходная программа проекта (.dpr). Красива, а!?
Ох, чуть не забыл! Если, Вы используете SysUtils в вашем проекте (например фуекцию StrToInt) вы получите EXE-файл больше чем обещанный в 20k. :) Если Вы хотите все же иметь20k, надо как-то обойтись без SysUtils, например самому написать собственную StrToInt процедуру.
Если все же очень трудно обойтись без использования Delphi-форм, то можно поступить как в случае с вводом пароля: форму изменения параметров хранителя сохранить в виде DLL и динамически ее загружать при необходимости. Т.о. будет маленький и шустрый файл самого хранителя экрана и довеска DLL для конфигурирования и прочего (там объем и скорость уже не критичны).
В наше время почти у каждого есть цифровая камера. Однако не все знают всех возможностей своего аппарата. Найдется мало желающих экспериментировать с настройками выдержки, чувствительности ISO и другими параметрами съемки, пользователи предпочитают делать цифровые фотографии в режиме – автоматической съемки.
2D – графика. Создаем панораму в редакторе PTGui Pro 8.
В наше время почти у каждого есть цифровая камера. Однако не все знают всех возможностей своего аппарата. Найдется мало желающих экспериментировать с настройками выдержки, чувствительности ISO и другими параметрами съемки, пользователи предпочитают делать цифровые фотографии в режиме – автоматической съемки.
Но почти в каждом современном фотоаппарате есть еще один режим, режим создания панорам. Этот режим позволяет избавится от некоторых ограничений фотоаппарата, такие как максимально допустимое разрешение снимка и максимальный угол обзора. Если же в вашем цифровике такого режима нет - не беда. Создать панораму можно и без специальной функции фотокамеры. Даже используя камеру мобильного телефона, можно получить широкоугольный снимок высокого разрешения. Все что нужно сделать – это выполнить несколько снимков в обычном режиме и установить специальную программу, с помощью которой кадры будут сшиваться в один снимок. Об одной из таких программ и пойдет речь в этом обзоре.
Свое название программа PTGui Pro получила в результате сокращения Graphical User Interface for Panorama Tools (Графический интерфейс для Panorama Tools).
Для создания панорамы, предлагается пройти несколько шагов с помощью мастера создания панорам Project Assistant. Наличие пошагового мастера в программе не означает, что PTGui Pro создаст панораму после нескольких щелчков мыши. Напротив, программа имеет огромное количество средств для настройки панорамы, в чем можно убедиться, включив режим Advanced. В этом режиме будет отображены дополнительные вкладки, каждая из которых содержит настройки для того или иного инструмента, например, для обрезки изображения, компенсации искажений, вызванных конструктивными особенностями объектива фотокамеры, для выбора способа проецирования панорамы и пр.
Шаг первый – загрузка изображений для будущей панорамы. Нажимаем кнопку Load images и указываем на диске заранее подготовленные фотографии.
Открытые в программе снимки отобразятся в виде ленты.
Если щелкнуть по этой ленте, откроется дополнительное окно Source Images, в котором можно установить порядок размещения изображений.
Нажав кнопку Correct в этом окне, можно выполнить коррекцию изображения, искаженного в результате паразитной дисперсии света, проходящего через оптическую систему объектива, или вследствие других причин.
Шаг второй – выравнивание кадров относительно друг друга. После нажатия кнопки Align images программа запустит свой алгоритм и определит для каждого изображения свое место в панорамном снимке. После автоматического выравнивания на экране появится окно Panorama Editor, в котором можно изменять ориентацию отдельных частей панорамы или всей панорамы целиком.
Если составляющие элементы панорамы сделаны максимально аккуратно, то есть, из одной точки, и имеют небольшую площадь перекрытия, скорее всего, создание панорамы на этом может быть завершено, и файл можно сохранять, нажав кнопку Create Panorama.
Если же снимки были не совсем удачные, и программа неточно определила места их "сшивания", необходимо вручную выполнить процедуру соединения изображений. Для склейки изображений PTGui Pro использует набор контрольных точек. Эти контрольные точки представляют собой пары отметок на соединяемых изображениях, которые обозначают совпадающие детали на снимках. Чем точнее расположены контрольные точки и чем больше будет их число, тем правильнее будет составлен шов между изображениями.
Для управления контрольными точками фотографий следует перейти на вкладку Control Points. В двух окнах показаны объединяемые снимки, на которых видны пары контрольных точек. Все эти точки пронумерованы и выделены цветом. Ниже, под изображениями показана таблица, в которой представлена подробная информация о координатах правых и левых контрольных точек.
Алгоритм программы несовершенен, поэтому иногда контрольные точки могут определяться недостаточно верно. В этом случае нужно щелкнуть правой кнопкой мыши на проблемной точке и удалить неудачную отметку, выбрав команду Delete. После этого можно вручную проставить контрольные точки, щелкая по изображению. Парную контрольную точку программа создаст сама, останется лишь проследить за правильностью ее расположения и, в случае необходимости, передвинуть ее на правильную позицию.
PTGui Pro может также сохранять результат соединения частей панорамы в файл Photoshop со слоями, что дает возможность редактировать изображение в популярном графическом редакторе. Изображение может также сохраняться в формате Tiff или Jpeg.
Панорамные снимки делают не только для того чтобы хранить память о местах, в которых побывал фотограф, они имеют и другое практическое применение. Круговые панорамы на 360 градусов могут использоваться разработчиками компьютерных игр для имитации естественного окружения. При помощи PTGui Pro можно получить интерактивную панораму в формате QuickTime VR (*.mov). Запустив такой файл, пользователь сможет совершить виртуальный осмотр местности из той точки, откуда производилась съемка панорамы. Панорамы QuickTime VR можно внедрять в веб-страницы. Для конвертирования панорамы в формат QuickTime VR нужно выполнить команду Utilities > Convert to QTVR.
Для 3D-дизайнеров программа PTGui Pro предлагает создание панорамных изображений в формате HDR, то есть с широким динамическим диапазоном. Использование технологии HDR при создании панорам может быть реализовано двумя методами коррекции изображения - True HDR и Exposure Fusion. Первый вариант позволяет создавать HDR-панораму на основе группы фотографий, сделанных с разной выдержкой, а также из HDR-изображений.
Второй вариант следует использовать в тех случаях, когда HDR-панорама не является конечной целью и необходимо лишь получить изображение с правильной экспозицией. В некоторых случаях, подобрать правильную выдержку довольно сложно. В основном это связано с тем, что на момент съемки освещение объектов неудобно для фотографа. В этом случае можно сделать несколько одинаковых снимков с разной выдержкой. Важно, чтобы они были сделаны с одной точки. Объединив информацию из всех этих снимков в формат HDR, можно получить изображение с более выгодным освещением. Затем выполняется преобразование диапазона яркостей HDRI к диапазону яркостей, отображаемых монитором (tone mapping), и на выходе мы имеем улучшенное изображение. Именно это и можно сделать в режиме Exposure Fusion.
Улучшить конечное изображение можно также, поэкспериментировав с настройками алгоритма PTGui Pro. Вызвать окно настроек можно, выполнив команду Tools > Options. Среди параметров, при помощи которых можно управлять тонкой настройкой программы: количество контрольных точек на паре сшиваемых изображений, настройки чувствительности при определении одинаковых фрагментов на частях панорамы и т.д.
Для создания одной панорамы требуется три, четыре и более снимков. А если панорам несколько то снимков получается очень много. Объединение кадров панорамы в один снимок требует много времени. Чтобы упростить задачу, в PTGui Pro предусмотрена пакетная обработка файлов.
Для того чтобы обработать сразу несколько панорамных изображений, необходимо сохранить проекты, которые должны быть обработаны, в формате программы (*.pts). После этого необходимо запустить утилиту Batch Stitcher, которая устанавливается вместе с PTGui Pro и доступна из меню "Пуск", составить в ней список заданий и запустить их выполнение.
Вы можете подумать, а для чего вообще нужна эта программа, ведь есть Photoshop, с прекрасным инструментом Photomerge? Однако его применение далеко не всегда позволяет получить идеальное изображение. Часто, особенно при склеивании ночных панорам, можно получить неприятное сообщение о том, что слои не могут быть корректно выровнены относительно друг друга. И тут PTGui Pro может стать хорошей альтернативой средствам популярного графического редактора.
С одной стороны, PTGui Pro достаточно проста в использовании, с другой – содержит множество настроек для коррекции снимков вручную, благодаря чему можно гибко управлять результатом.
Ниже приведены несколько панорам, которые были созданы при помощи программы.
Триал-версию PTGui Pro для Windows и Mac OS X можно скачать с официального сайта.
Жесткие диски (винчестеры), как электромеханические устройства, являются одним из самых ненадежных компонентов современного компьютера. Несмотря на то, что в большинстве случаев срок службы последних соизмерим, и даже превосходит время их эксплуатации до момента морального устаревания и замены более новыми моделями, все же отдельные экземпляры выходят из строя в течение первых месяцев эксплуатации. Выход жесткого диска из строя - самое худшее, что может случиться с вашим компьютером, так как при этом часто необратимо теряются накопленные на нем данные. Если резервная копия по какой-то причине отсутствует, то суммарный ущерб от поломки заметно превышает номинальную стоимость современных винчестеров.
Многие фирмы, пользуясь ситуацией, предлагают свои услуги по восстановлению информации с вышедшего из строя накопителя. Очевидно, это обходится недешево и целесообразно только тогда, когда на диске находилось что-то действительно ценное. В противном случае легче просто смириться с потерей.
Ремонт жестких дисков требует специального оборудования и практически невозможен в домашних условиях. Так, например, для вскрытия контейнера необходима особо чистая от пыли комната. Казалось бы, положение безнадежно и нечего даже помышлять о восстановлении поломанного диска в домашних условиях. Но, к счастью, не все поломки настолько серьезны, и во многих случаях можно обойтись для ремонта подручными (а иногда чисто программными) средствами.
Один из самых частых отказов винчестеров фирмы western digital (а также и некоторых других) выглядит следующим образом: жесткий диск не опознается bios, а головки при этом отчетливо стучат. Скорее всего, по какой-то причине не работает блок термокалибровки, и устройство не может обеспечить нужный зазор между головкой и рабочей поверхностью "блина". Обычно это происходит при отклонении от нормального температурного режима эксплуатации, например, в зимнее время, когда жесткие диски в плохо отапливаемых помещениях "выстывают" за ночь (при температуре 18...210С жесткий диск часто может исправно функционировать и с испорченным механизмом термокалибровки). Попробуйте дать поработать винчестеру в течение нескольких часов, чтобы он прогрелся, при этом рано или поздно винчестер попадает в необходимый диапазон температур и работоспособность (возможно, временно) восстанавливается. Разумеется, первым делом нужно скопировать всю информацию, поскольку работоспособность такого диска уже не гарантируется. То же можно рекомендовать и в отношении устаревших моделей без термокалибровки; часто они оказываются зависимыми от температурного режима, и с ростом износа винчестера эта зависимость проявляется все сильнее.
Вторым по распространенности отказом является выход из строя модуля диагностики при полной исправности остальных компонентов. Как это ни покажется парадоксальным, но полностью рабочий винчестер не проходит диагностику. При этом в регистре ошибок (порт ox1f1 для первого жесткого диска) могут содержаться значения, приведенные ниже:
Диагностические ошибки
Бит Содержимое Источник ошибки
7 0 Ошибка master диска
1 Ошибка slave диска
2-0 011 Ошибка секторного буфера
100 Ошибка контрогльной суммы, не устранимая избыточным кодированием
101 Ошибка микроконтроллера
Разные biosы могут различно реагировать на такую ситуацию, но все варианты сводятся к одному - жесткий диск не определяется и не "чувствуется". Однако на уровне портов ввода/вывода устройство функционирует отлично. Заметим, что существуют такие материнские платы (особенно среди новых моделей), которые, обнаружив ошибку микроконтроллера винчестера, просто отключают питание жесткого диска. Несложно написать для испорченного таким образом винчестера драйвер, который обеспечит работу с диском через высокоуровневый интерфейс int 0x13. Например, следующая процедура обеспечивает посекторное чтение и запись через порты ввода/вывода для первого жесткого диска в chs режиме.
lba mode для упрощения понимания не поддерживается. Необходимую техническую информацию обычно можно найти на сайте производителя вашего жесткого диска.
Этот фрагмент может служить вполне работоспособным ядром для драйвера 16-ти разрядного режима. Для упрощения понимания не включена задержка после каждого обращения к порту. В зависимости от соотношений скорости вашего процессора и контроллера диска эта задержка может и не потребоваться (в противном случае рекомендуется читать регистр статуса ox1f7, дожидаясь готовности контроллера). При этом не следует спешить с заменой такого жесткого диска на новый, с подобной неисправностью можно успешно работать не год и не два. Последнее, правда, лишь при условии, что все используемое программное обеспечение не будет конфликтовать с нестандартным драйвером. Писать драйвер, скорее всего, придется вам самому, поскольку не известно ни одной коммерческой разработки в этом направлении, а все любительские разработки выполнены в основном "под себя". Так, например, драйвер от kpnc hddfix3a поддерживает только винчестеры primary master до пятисот мегабайт и не работает в среде windows 95 (разработан на год раньше ее появления).
Более легкий, но не всегда осуществимый путь - запретить тестирование жестких дисков biosом или, по крайней мере, игнорировать результаты такового. Как это осуществить, можно прочесть в руководстве на материнскую плату (или обратиться за помощью к службе технической поддержки фирмы-производителя, поскольку в руководствах пользователя такие тонкости нередко опускают). Например, попробуйте установить "halt on" в "never" или перезаписать flach bios, модифицировав его так, чтобы тот не выполнял подобную проверку. Если Вам повезет, жесткий диск заработает! Однако иногда все же происходят и аппаратные отказы. Например, у винчестеров фирм samsung и conner отмечены случаи отказа модуля трансляции мультисекторного чтения/записи. Если это не будет обнаружено внутренним тестом устройства, то такой жесткий диск вызовет зависание операционной системы на стадии ее загрузки. Для предотвращения этого достаточно добавить в config.sys ключ multi-track=off и отключить аналогичные опции в blose. При этом, проиграв в скорости, все же можно заставить жесткий диск сносно работать. Понятно, что эксплуатировать восстановленный таким образом диск длительное время нерационально по причине потери быстродействия. Лучше приобрести новый, на который и скопировать всю информацию. С другой стороны, такой жесткий диск все же остается полностью рабочим и успешно может служить, например, в качестве резервного.
На том же connere эпизодически выходит из строя блок управления позиционированием головок, так что последние уже не могут удержаться на дорожке и при обращении к следующему сектору немного "уползают". При этом считывание на выходе дает ошибочную информацию, а запись необратимо затирает соседние сектора. Бороться с этим можно позиционированием головки перед каждой операцией записи/чтения, обрабатывая за один проход не более сектора. Понятно, что для этого необходимо вновь садиться за написание собственного драйвера. К счастью, он достаточно простой (можно использовать аппаратное прерывание от жесткого диска int 0x76 irq14, вставив в тело обработчика команду сброса контроллера. В данном случае подразумевается, что контроллер используемого жесткого диска проводит рекалибровку головки во время операции сброса. Некоторые модели этого не делают. В этом случае придется прибегнуть к операции позиционирования головки (функция ОхС дискового сервиса 0x13). Первые модели от вторых можно отличить временем, требуемым на сброс контроллера. Понятно, что электроника "сбрасывается" мгновенно, а позиционирование головки требует хоть и не большого, но все же заметного времени. Современные модели с поддержкой кэширования этого часто не делают или "откладывают" операции с головкой до первого к ней обращения. Разумеется, в этом случае кэширование придется выключить. Большинство bios позволяет это делать без труда, и нет нужды программировать контроллер самостоятельно. В другом случае вышедший из строя блок позиционирования (трансляции) подводит головки вовсе не к тому сектору, который запрашивался. Например, головки могли физически сместиться с оси, "уползая" в сторону. Разумеется, этот дефект можно скорректировать программно, достаточно проанализировать ситуацию и логику искажения трансляции. Многие модели позиционируют головку, используя разметку диска, что страхует от подобных поломок (к сожалению, сейчас от такого подхода большинство фирм отказались, выигрывая в скорости).
Конечно, все описанные программные подходы в действительности не устраняют неисправность, а только позволяют скопировать с казалось бы уже нерабочего винчестера ценные и еще не сохраненные данные. При этом ни к чему писать универсальный драйвер для win32 и защищенного режима. Вполне можно ограничиться dos-режимом. Для копирования файлов последнего должно оказаться вполне достаточно, конечно за исключением тех случаев, когда диск был отформатирован под ntsf или другую, не поддерживаемую ms-dos, систему. К счастью, для многих из них есть драйверы, которые позволяют "видеть" подобные разделы даже из "голой" ms-dos. В крайнем случае, можно ограничиться посекторным копированием на винчестер точно такой же топологии. При этом совершенно не имеет значения используемая файловая система и установленная операционная система.
Посекторно скопировать диск на винчестер с иной топологией трудно, но возможно. Дело в том, что многие современные контроллеры жестких дисков позволяют пользователю менять трансляцию произвольным образом. Для этого необходимо приобрести винчестер, поддерживающий lba-режим (а какой из современных жестких дисков его не поддерживает?). При этом он может быть даже большего объема, нежели исходный, но это никак не помешает копированию. Другой вопрос, что без переразбиения скопированный таким образом диск не "почувствует" дополнительных дорожек и следует запустить norton disk doctor, который устранит эту проблему.
Достаточно часто нарушается вычисление зон предком-пенсации. Дело в том, что плотность записи на разных цилиндрах не одинакова, так как линейная скорость растет от центра диска к периферии. Разумеется, гораздо легче постепенно уплотнять записи, нежели искать некий усредненный компромисс. На всех существующих моделях плотность записи изменяется скачкообразно и на последних моделях программно доступна через соответствующие регистры контроллера. При этом значения, выставленные в bios, практически любой жесткий диск (с интерфейсом ide) просто игнорирует. Предыдущие модели не имели с этим проблем, и только винчестеры, выпущенные в течение последних двух лет, склонны к подобным поломкам. Скорее, даже не к поломкам, а к сбоям, в результате которых искажается хранимая где-то в недрах жесткого диска информация. Если контроллер позволяет ее программно корректировать, то считайте, что ваш жесткий диск спасен. Конечно, придется пройти сквозь мучительные попытки угадать оригинальные значения, однако это можно делать и автоматическим перебором до тех пор, пока винчестер не начнет без ошибок читать очередную зону. Помните, что любая запись на диск способна нарушить низкоуровневую разметку винчестера, после чего последний восстановлению не подлежит и его останется только выкинуть. Производите только чтение секторов!
Если же контроллер не позволяет программно управлять предкомпенсацией, то еще не все потеряно. Попробуйте перед каждым обращением делать сброс контроллера, а точнее, его рекалибровку (команда ixh). В некоторых случаях это срабатывает, поскольку с целью оптимизации скорости обмена предкомпенсацией обычно управляет не один блок. И, кроме того, иногда контроллер кэша не учитывает предкомпенсацию, а его сброс реализует последнюю аппаратно. К сожалению, это по большей части догадки и результаты экспериментов автора, так как техническая документация фирм-производителей по этому поводу не отличается полнотой, а местами содержит противоречия. Можно испытать и другой способ - попробовать перезаписать микрокод контроллера (команда 92h). Конечно, это доступно только для специалистов очень высокого класса, но ведь доступно! Заметим, что не все контроллеры поддерживают такую операцию. С другой стороны, это и хорошо, так как уменьшает вероятность сбоя и не дает некорректно работающим программам (вирусам в том числе) испортить дорогое устройство. Жесткие диски от samsung обладают еще одной неприятной особенностью - часто при подключении шлейфа "на лету", при включенном питании, они перестают работать. Внешне это выглядит так: индикатор обращения к диску постоянно горит, но диск даже не определяется biosom, или определяется, но все равно не работает. Близкое рассмотрение показывает, что на шине пропадает сигнал готовности устройства. В остальном контроллер остается неповрежденным. Разумеется, если не обращать внимание на отсутствие сигнала готовности, то с устройством можно общаться, делая вручную необходимые задержки (поскольку физическую готовность устройства уже узнать не представляется возможным, приходится делать задержки с изрядным запасом времени). При этом, к сожалению, придется отказаться от dma-mode (а уж тем более ultra-dma) и ограничиться pio 1 (с небольшим риском - pio 2) режимом. Конечно, писать соответствующий драйвер вам придется опять самостоятельно. Разумеется, скорость обмена в режиме pio 1 по сегодняшним меркам совершенно неудовлетворительна и не годится ни для чего другого, кроме как копирования информации со старого на новый винчестер, но некоторые "нечистоплотные" продавцы компьютерной техники как-то ухитряются устанавливать подобные экземпляры на продаваемые машины. Будьте осторожны! Учитывая, что написание подобных драйверов для win32 - трудоемкое занятие, большинство ограничивается поддержкой одной лишь ms-dos, и вовсе не факт, что компьютер, демонстрирующий загрузку win95, содержит исправный, а не реанимированный подобным образом жесткий диск.
У жестких дисков фирмы samsung при подключении "налету" может появляться другой неприятный дефект - при запросах на чтение контроллер периодически "повисает" и не завершает операцию. В результате "замирает" вся операционная система (впрочем, windows nt с этим справляется, но, вероятно, не всегда). На первый взгляд может показаться, что с этого винчестера несложно скопировать ценные файлы, но при попытке выполнить это выясняется, что диск "зависает" все чаще и чаще и копирование растягивается до бесконечности. Однако если выполнить сброс контроллера, то можно будет повторить операцию. Это можно сделать аппарат -но, подпаяв одну кнопку на линию сброса и статуса. Последнее нужно для указания на ошибочную ситуацию, чтобы операционная система повторила незавершенную операцию. Если этого не сделать, то часть секторов не будет реально прочитана (записана). Или можно выполнять сброс автоматически, например, по таймеру. Чтобы не сталкиваться с подобной ситуацией, никогда не следует подсоединять/отсоединять винчестер при включенном питании. Очень часто это приводит к подобным ошибкам, хотя производители других фирм, по-видимому, как-то от этого все же защищаются, ибо аналогичной ситуации у них практически не встречается. Все же не стоит искушать судьбу... От аппаратных ошибок теперь перейдем к дефектам поверхности. Заметим сразу, что последнее встречается гораздо чаще и проявляется намного коварнее. Обычно это ситуация, в которой мало что можно предпринять. Но достичь главной цели - спасти как можно больше уцелевших данных - довольно часто удается. Возьмем такую типичную ситуацию как ошибка чтения сектора. Маловероятно, чтобы сектор был разрушен целиком. Чаще всего "сыплется" только какая-то его часть, а все остальные данные остаются неискаженными. Существуют контроллеры двух типов. Первые, обнаружив расхождение контрольной суммы считанного сектора, все же оставляют прочитанные данные в буфере и позволяют их извлечь оттуда, проигнорировав ошибку чтения. Вторые либо очищают буфер, либо просто не сбрасывают внутренний кэш, в результате чего все равно прочитать буфер невозможно. На практике обычно встречаются последние. При этом сброс кэша можно инициировать серией запросов без считывания полученных данных. Кэш при этом переполняется, и наиболее старые данные будут вытолкнуты в буфер. Остается их только прочесть. Конечно,-это крайне медленно, но, к сожалению, универсальной команды сброса кэша не существует. Разные разработчики реализуют это по-своему (впрочем, иногда это можно найти в документации на чипы, используемые в контроллере). western digital сообщает в техническом руководстве что при длинном чтении сектора без повтора контроль сектора не выполняется и он будет-таки целиком помещен в буфер. Кстати, так и должно быть по стандарту. Увы, остальные фирмы от него часто отклоняются по разным соображениям. Остается определить, какие же из прочитанных данных достоверные, а какие нет (если этого не видно "визуально" - например, в случае текстового или графического файлов)? Разумеется, в подобных рамках задача кажется неразрешимой, но это не совсем так. Дело в том, что можно произвести не только короткое, но и длинное чтение (ox22h req ploin long with retry), для чего можно использовать следующую процедуру. При этом кроме собственно данных читаются также и корректирующие коды. Автоматическая коррекция не выполняется (хотя некоторые контроллеры это реализуют аппаратно и не могут отключить автокоррекцию; в документации этот момент, кстати, не уточняется). Как правило, используются корректирующие коды Рида-Соломона, хотя последнее не обязательно. Математические законы позволяют не только определить место возникновения сбоя, но и даже восстановить несколько бит. При больших разрушениях можно определить только место сбоя, но достоверно восстановить информацию не удается.
Модуляция при записи такова, что все биты, стоящие справа от сбойного, уже не достоверны. Точнее, не все, а только в пределах одного пакета. Обычно за один раз записывается от 3 до 9 бит (необходимо уточнить у конкретного производителя) и содержимое остальных пакетов, как правило, остается достоверным. Самое интересное, что зачастую сбойный пакет можно восстановить методом перебора! При этом можно даже рассчитать, сколько вариантов должно получиться. Учитывая хорошую степень "рассеяния" корректирующих кодов можно сказать, что не очень много. И таким образом можно восстановить казалось бы безнадежно испорченные сектора, а вместе с ними и файлы, расположенные "поверх" последних.
Выше были перечислены наиболее типичные случаи отказов жестких дисков, которые поддавались чисто программному восстановлению если уж не винчестера, то хотя бы хранимых на нем данных. Разумеется, что иногда жесткий диск выходит из строя полностью (например, при неправильно подключенном питании, скачках напряжения) от вибрации или ударов, а то и просто из-за откровенного заводского брака. Есть один старый проверенный способ - найти жесткий диск такой же точно модели и заменить электронную плату. К сожалению, последнее из-за ряда конструктивных особенностей все реже и реже бывает возможно, а уж дефекты поверхности этот способ и вовсе бессилен вылечить. Поэтому, берегите свой жесткий диск и почаще проводите резервное копирование. Помните, что самое дорогое это не компьютер, а хранимая на нем информация!
Изменяя аргумент iAngle, можно вращать начальную точку - центр. А изменяя iSector можно выводить текст как по окружности, так и по дуге (она задается в градусах). Наверняка многие видели такой эффектик. Какой-нибудь текст крутится вокруг центра и меняется его радиус - расстояние от центра до букв. И тут можно такое же сделать. Для этого надо вызывать эту процедуру по таймеру, где перед вызовом изменять iAngle и iR (переменные завести). Только перед каждым рисованием, надо в этой функции очищать уже нарисованное, чтобы не оставалось старого. А если это непосредственно на канве делается медленно и мигает, но надо рисовать на битмапе и оттуда изображение копировать.
Вопрос создания непрямоугольных окон часто интересует начинающих программистов и время от времени обсуждается на форумах разработчиков в среде Delphi. А вообще, нужно ли это кому-нибудь? Ответ - да! Это уже было нужно таким известным фирмам, как Symantec (Norton Utilities, Norton CrashGuard), Microsoft (Приложение "
Часы" в Windows NT4 может принимать круглую форму, Deluxe CD Player из MS Plus! 98 имеет вид прямоугольника со скругленными краями). У Borland Jbuilder 2 в окне начальной загрузки стрела крана "выскочила" за пределы прямоугольника. Программы для видеокарт TV Capture фирмы AverMedia имитируют пульт управления. Окно переводчика Magic Goody принимает вид гуся, разгуливающего по экрану.
Список можно продолжить, а вывод такой: окно "хитрой" формы – это "изюминка" оформления Вашей программы, нечто запоминающееся, дополнительный плюс в борьбе за потенциального покупателя. Главное в этом – не переборщить. Вряд ли будет удобно работать с текстовым редактором в треугольном окне. Окна произвольной формы неплохо смотрятся при начальной загрузке (Splash) и, возможно, в качестве окна "О программе … ".
Как это делается? Средствами Delphi – достаточно просто. Приведенные ниже примеры можно также перевести в C++ Builder или Visual C++.
При создании окна непрямоугольной формы используются API функции
Переопределение функции WMNCHitTest позволит перетаскивать окно, захватив его мышкой.
До сих пор в примерах мы рассматривали регионы с абсолютными значениями линейных величин. Пример непрямоугольного окна, которое масштабирует свою форму в зависимости от его размера. Искодный код, приведенный ниже, создает окно в виде бабочки, причем бабочка исполльзует максимально высоту и ширину исходной формы.
Если грамотно разложить фигуру на элементарные составляющие, то Вам вполне по силам создать окно абсолютно любой формы. Это похоже на детскую игру "конструктор", только Ваши "кубики" намного разнообразнее.
Для завершения проекта необходимо создать фоновую картинку, которая подчеркнет границы нового окна. И обязательно установить свойство формы Scaled = False, иначе фоновая картинка и форма могут "разъехаться" при использовании нестандартных видеорежимов или стилей оформления Windows.
В заключение следует сказать, что существуют готовые компоненты и библиотеки компонент для решения подобных задач, например, CoolForm, TPlasmaForm. Однако при использовании компонент от сторонних производителей могут возникнуть проблемы лицензионности их использования и проблемы перехода на новую версию компилятора. А приведенные в данной статье примеры компилируются без изменений в исходном коде на Borland Delphi 3.0 - 7.0 и, вероятно, будут совместимы с последующими версиями.
Для программирования расширенных хранимых процедур Microsoft предоставляет ODS (Open Data Service) API набор макросов и функций, используемых для построения серверных приложений позволяющих расширить функциональность MS SQL Server 2000.
Расширенные хранимые процедуры - это обычные функции написанные на С/C++ с применением ODS API и WIN32 API, оформленные в виде библиотеки динамической компоновки (dll) и призванные, как я уже говорил, расширять функциональность SQL сервера. ODS API предоставляет разработчику богатый набор функций позволяющих передавать данные клиенту, полученные от любых внешних источников данных (data source) в виде обычных наборов записей (record set). Так же, extended stored procedure может возвращать значения через переданный ей параметр (OUTPUT parametr).
Как работают расширенные хранимые процедуры.
* Когда клиентское приложение вызывает расширенную хранимую процедуру, запрос передаётся в TDS формате через сетевую библиотеку Net-Libraries и Open Data Service ядру MS SQL SERVER.
* SQL Sever находит dll библиотеку ассоциированную с именем расширенной хранимой процедуры и загружает её в свой контекст, если она не была загружена туда ранее, и вызывает расширенную хранимую процедуру, реализованную как функцию внутри dll.
* Расширенная хранимая процедура выполняет на сервере необходимые ей действия и передаёт набор результатов клиентскому приложению, используя сервис предоставляемый ODS API.
Особенности расширенных хранимых процедур.
* Расширенные хранимые процедуры - это функции выполняющиеся в адресном пространстве MS SQL Server и в контексте безопасности учётной записи под которой запущена служба MS SQL Server;
* После того, как dll библиотека с расширенными хранимыми процедурами была загружена в память, она остаётся там до тех пор, пока SQL Server не будет остановлен, или пока администратор не выгрузит её принудительно, используя команду :
DBCC DLL_name (FREE).
* Расширенная хранимая процедура запускается на выполнение так же, как и обычная хранимая процедура:
EXECUTE xp_extendedProcName @param1, @param2 OUTPUT
@param1 входной параметр
@param2 входной/выходной параметр
Внимание!
Так как расширенные хранимые процедуры выполняются в адресном пространстве процесса службы MS SQL Server, любые критические ошибки, возникающие в их работе, могут вывести из строя ядро сервера, поэтому рекомендуется тщательно протестировать Вашу DLL перед установкой на рабочий сервер.
Создание расширенных хранимых процедур.
Расширенная хранимая процедура эта функция имеющая следующий прототип:
Параметр pSrvProc указатель на SRVPROC структуру, которая является описателем (handle) каждого конкретного клиентского подключения. Поля этой структуры недокументированны и содеражат информацию, которую библиотека ODS использует для управления коммуникацией и данными между серверным приложением (Open Data Services server application) и клиентом. В любом случае, Вам не потребуется обращаться к этой структуре и тем более нельзя модифицоравать её. Этот параметр требуется указывать при вызове любой функции ODS API, поэтому в дальнейшем я небуду останавливаться на его описании.
Использование префикса xp_ необязательно, однако существует соглашение начинать имя расширенной хранимой процедуры именно так, чтобы подчеркнуть отличие от обычной хранимой процедуры, имена которых, как Вы знаете, принято начинать с префикса sp_.
Так же следует помнить, что имена расширенных хранимых процедур чувствительны к регистру. Не забывайте об этом, когда будете вызвать расширенную хранимую процедуру, иначе вместо ожидаемого результата, Вы получите сообщение об ошибке.
Если Вам необходимо написать код инициализации/деинициализации dll, используйте для этого стандартную функцию DllMain(). Если у Вас нет такой необходимости, и вы не хотите писать DLLMain(), то компилятор соберёт свою версию функции DLLMain(), которая ничего не делает, а просто возвращает TRUE. Все функции, вызываемые из dll (т.е. расширенные хранимые процедуры) должны быть объявлены, как экспортируемые. Если Вы пишете на MS Visual C++ используйте директиву __declspec(dllexport). Если Ваш компилятор не поддерживает эту директиву, опишите экспортируемую функцию в секции EXPORTS в DEF файле.
Итак, для создания проекта, нам понадобятся следующие файлы:
* Srv.h заголовочный файл, содержит описание функций и макросов ODS API;
* Opends60.lib файл импорта библиотеки Opends60.dll, которая и реализует весь сервис предоставляемый ODS API.
Microsoft настоятельно рекомендует, чтобы все DLL библиотеки реализующие расширенные хранимые процедуры экспортировали функцию:
Когда MS SQL Server загружает DLL c extended stored procedure, он первым делом вызывает эту функцию, чтобы получить информацию о версии используемой библиотеки.
Для написания своей первой extended stored procedure, Вам понадобится установить на свой компьютер:
- MS SQL Server 2000 любой редакции (у меня стоит Personal Edition). В процесе инсталляции обязательно выберите опцию source sample
- MS Visual C++ (я использовал версию 7.0 ), но точно знаю подойдёт и 6.0
Установка SQL Server -a нужна для тестирования и отладки Вашей DLL. Возможна и отладка по сети, но я этого никогда не делал, и поэтому установил всё на свой локальный диск. В поставку Microsoft Visual C++ 7.0 редакции Interprise Edition входит мастер Extended Stored Procedure DLL Wizard. В принципе, ничего сверх естественного он не делает, а только генерирует заготовку шаблон расширенной хранимой процедуры. Если Вам нравятся мастера, можете использовать его. Я же предпочитаю делать всё ручками, и поэтому не буду рассматривать этот случай.
Теперь к делу:
- Запустите Visual C++ и создайте новый проект - Win32 Dynamic Link Library.
- Включите в проект заголовочный файл - #include <srv.h>;
- Зайдите в меню Tools => Options и добавьте пути поиска include и library файлов. Если , при установке MS SQL Server, Вы ничего не меняли, то задайте:
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsInclude для заголовочных файлов;
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsLib для библиотечных файлов.
- Укажите имя библиотечного файла opends60.lib в опциях линкера.
На этом подготовительный этап закончен, можно приступать к написанию своей первой extended stored procedure.
Постановка задачи.
Прежде чем приступать к программированию, необходимо чётко представлять с чего начать, какой должен быть конечный результат, и каким способом его добиться. Итак, вот нам техническое задание:
Разработать расширенную хранимую процедуру для MS SQL Server 2000, которая получает полный список пользователей зарегистрированных в домене, и возвращает его клиенту в виде стандартного набора записей (record set). В качестве первого входного параметра функция получает имя сервера содержащего базу данных каталога (Active Directory), т.е имя контролера домена. Если этот параметр равен NULL, тогда необходимо передать клиенту список локальных групп. Второй параметр будет использоваться extended stored procedure для возварата значения результата успешной/неуспешной работы (OUTPUT параметр). Если, расширенная хранимая процедура выполнена успешно, тогда необходимо передать количество записей возвращённых в клиентский record set , если в процессе работы не удалось получить требуемую информацию, значение второго параметра необходимо установить в -1, как признак неуспешного завершения.
.
А вот шаблон расширенной хранимой процедуры, который нам предстоит наполнить содержанием:
Работа с входными параметрами
В этой главе я не хочу рассеивать Ваше внимание на посторонних вещах, а хочу сосредоточить его на работе с переданными в расширенную хранимую процедуру параметрами. Поэтуму мы несколько упростим наше техническое задание и разработаем тольку ту его часть, которая работает с входными параметрами. Но сначал не много теории
Первое действие, которое должна выполнить наша exteneded stored procedure , - получить параметры, которые были переданы ей при вызове. Следуя приведённому выше алгоритму нам необходимо выполнить следующие действия:
- Определить кол-во переданных параметров;
- Убедится, что переданные параметры имеют верный тип данных;
- Убедиться, что указанный OUTPUT параметр имеет достаточную длину, для сохранения в нём значения возвращаемого нашей extended stored procedure.
- Получить переданные параметры;
- Установить значения выходного параметра как результат успешного/неуспешного завершения работы extended stored procedure .
Теперь рассмотрим подробно каждый пункт:
Определение количества переданных в расширенную хранимую процедуру параметров
Для получения количества переданных параметров необходимо использовать функцию:
.
При успешном завершении функция возвращает количество переданных в расширенную хранимую процедуру параметров. Если extended stored procedure была вызвана без параметров - srv_rpcparams ввернёт -1. Параметры могут быть переданы по имени или по позиции (unnamed). В любом случае, нельзя смешивать эти два способа. Попытка передачи в функцию входных параметров по имени и по позиции одновременно - приведёт к возникновению ошибки, и srv_rpcparams вернёт 0 .
[pagebreak]
Определение типа данных и длины переданых параметров
Для получения информации о типе и длине переданных параметров Microsoft рекомендует использовать функцию srv_paramifo. Эта универсальная функция заменяет вызовы srv_paramtype, srv_paramlen, srv_parammaxlen, которые теперь считаются устаревшими. Вот её прототип:
.
.
.
.
.
.
.
.
.
.
pByte - указатель на переменную получающую информацию о типе входного параметра;
pbType задаёт порядковый номер параметра. Номер первого параметра начинается с 1.
pcbMaxLen - указатель на переменную, в которую функция заносит максимальное значение длины параметра. Это значение обусловлено конкретным типом данных переданного параметра, его мы и будем использовать, чтобы убедиться втом, что OUTPUT параметр имеет достаточную длину для сохранения передаваемых данных.
pcbActualLen указатель на реальную длину параметра переданного в расширенную хранимую процедуру при вызове. Если передаваемый параметр имеет нулевую длину, а флаг pfNull устанавлен в FALSE то (* pcbActualLen) ==0.
pbData - указатель на буфер, память для которого должна быть выделена перед вызовом srv_paraminfo. В этом буфере функция размещает полученные от extended stored procedure входные параметры. Размер буфера в байтах равен значению pcbMaxLen. Если этот параметр установлен в NULL, данные в буфер не записываются, но функция корректно возвращает значения *pbType, *pcbMaxLen, *pcbActualLen, *pfNull. Поэтому вызывать srv_paraminfo нужно дважды: сначала с pbData=NULL, потом, выделив необходимый размер памяти под буфер равный pcbActualLen, вызвать srv_paraminfo второй раз, передав в pbData указатель на выделенный блок памяти.
pfNull указатель на NULL-флаг. srv_paraminfo устанавливает его в TRUE, если значение входного параметра равно NULL.
Проверка, является ли второй параметр OUTPUT параметром.
Функция srv_paramstatus() предназначена для определения статуса переданного параметра:
.
.
.
.
.
n - номер параметра переданного в расширенную хранимую процедуру при вызове. Напомню: параметры всегда нумеруются с 1.
Для возврата значения, srv_paramstatus использует нулевой бит. Если он установлен в 1 переданный параметр является OUTPUT параметром, если в 0 обычным параметром, переданным по значению. Если, exteneded stored procedure была вызвана без параметров, функция вернёт -1.
Установка значения выходного параметра.
Выходному параметру, переданному в расширеную хранимую можно передать значение используя функцию srv_paramsetoutput. Эта новая функция заменяет вызов функции srv_paramset, которая теперь считается устаревашай, т.к. не поддерживает новые типы данных введённые в ODS API и данные нулевой длины.
.
.
.
.
.
.
.
.
n - порядковый номер параметра, которому будет присвоено новое значение. Это должен быть OUTPUT параметр.
pbData указатель на буфер с данными, которые будут посланы клиенту для установки значения выходного параметра.
cbLen длина буфера посылаемых данных. Если тип данных переданного OUTPUT параметра определяет данные постоянной длины и не разрешает хранение значения NULL (например SRVBIT или SRVINT1), то функция игнорирует параметр cbLen. Значение cbLen=0 указывает на данные нулевой длины, при этом парметр fNull должен быть установлен в FALSE.
fNull установите этот его в TRUE, если возвращаемому параметру необходимо присвоить значение NULL, при этом значение cbLen должно быть равно 0, иначе функция завершится с ошибкой. Во всех остальных случаях fNull=FALSE.
В случае успешного завершения функция возвращает SUCCEED. Если возвращаемое значение равно FAIL, значит вызов был неудачным. Всё просто и понятно
Теперь мы достаточно знаем, для того чтобы написать свою первую расширенную хранимую процедуру, которая будет возвращать значение через переданный ей параметр.Пусть, по сложившейся традиции, это будет строка Hello world! Отладочну версию примера можно скачать здесь.
. Не рассмотренными остались функции srv_sendmsg и srv_senddone. Функция srv_sendmsg используется для посылки сообщений клиенту. Вот её прототип:
msgtype определяет тип посылаемого клиенту сообщения. Константа SRV_MSG_INFO обозначает информационное сообщение, а SRV_MSG_ERROR сообщение об ошибке;
msgnum номер сообщения;
class - степень тяжести возникшей ошибки. Информационные сообщения имеют значение степени тяжести меньшее или равное 10;
state номер состояния ошибки для текущего сообщения. Этот параметр предоставляет информацию о контексте возникшей ошибки. Допустимые значения лежат в диапазоне от 0 до 127;
rpcname в настоящее время не используется;
rpcnamelen - в настоящее время не используется;
linenum здесь можно указать номер строки исходного кода. По этому значению, в последствие будет легко установить в каком месте возникла ошибка. Если Вы не хотите использовать эту возможность, тогда установите linenum в 0;
message указатель на строку посылаемую клиенту;
msglen определяет длину в байтах строки сообщения. Если это строка заканчивается нулевым символом, то значение этого параметра можно установить равным SRV_NULLTERM.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
В процессе работы расширенная хранимая процедура должна регулярно сообщать клиентскому приложению свой статус, т.е. посылать сообщения о выполненных действиях. Для этого и предназначена функция srv_senddone:
status - статус флаг. Значение этого параметра можно задавать использую логические операторы AND и OR для комбинирования констант приведённых в таблице:
Status flag Описание
SRV_DONE_FINAL Текущий набор результатов является окончательным;
SRV_DONE_MORE Текущий набор результатов не является окончательным следует ожидать очердную порцию данных;
SRV_DONE_COUNT Параметр count содержит верное значение
SRV_DONE_ERROR Используется для уведомления о возникновении ошибок и немедленном завершении.
into зарезервирован, необходимо установить в 0.
count количество результирующих наборов данных посылаемых клиенту. Если флаг status установлен в SRV_DONE_COUNT, то count должен содержать правильное количество посылаемый клиенту наборв записей.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
Установка расширенных хранимых процедур на MS SQL Server 2000
1.Скопируйте dll библиотеку с расширенной хранимой процедурой в каталог binn на машине с установленным MS SQL Server. У меня этот путь следующий: C:Program FilesMicrosoft SQL ServerMSSQLBinn;
2.Зарегистрирйте расширенную хранимую процедуру на серверt выполнив следующий скрипт:
Заключение
На этом первая часть моей статьи закончена. Теперь я уверен Вы готовы справиться с нашим техническим заданием на все 100%. В следующей статье Вы узнаете:
- Типы данных определённые в ODS API;
- Особенности отладки расширенных хранимых процдур;
- Как формировать recordset-ы и передавать их клиентскому приложению;
- Чстично мы рассмотрим функции Active Directory Network Manegment API необходимые для получения списка доменных пользователей;
- Создадим готовый проект (реализуем наше техническое задание)
Надеюсь - до скорой встречи!
Проблемы соединения волоконных световодов приобрели особую актуальность при разработке технологии их промышленного применения. Выбор способа сращивания зависит от условий применения волоконной оптики.
Очевидно, что значительные преимущества при использовании волоконно-оптических технологий в телекоммуникационной отрасли, связанные с улучшением целого ряда технико-экономических показателей (возрастанием скорости передачи информации, увеличением длины регенерационного участка, уменьшением массогабаритных характеристик кабелей, экономией цветных металлов и др.), предопределят в будущем широкое внедрение волоконной оптики при построении линий связи различных уровней. Однако необходимо было разработать методики сращивания волоконных световодов, обеспечивающие высокие качественные и вместе с тем достаточно технологичные и доступные показатели, чтобы сделать возможным применение этих световодов не только в стационарных, но и в полевых условиях.
Строительная длина волоконно-оптического кабеля на практике устанавливается, исходя из ряда факторов. Прокладка больших длин кабеля неудобна вследствие необходимости сматывания с барабана и манипуляций с кабелем как во время прокладки в полевых условиях (при пересечении других подземных коммуникаций), так и в городских условиях (при прокладке в кабельную канализацию). Прокладывая кабель с помощью кабелеукладочной техники, также возникают неудобства, связанные с манипуляциями большими длинами, если для погрузочно-разгрузочных работ приходится использовать специализированную технику. Особенно остро стоит проблема манипуляции строительными длинами с большой удельной массой при прокладке глубоководных морских кабелей и кабелей для прибрежной зоны. Из-за необходимости инсталляции кабелей максимально возможной длины для их транспортировки по суше используются спаренные железнодорожные платформы, на которых кабели выкладываются в форме "8", а не на кабельные барабаны. Таким образом кабель транспортируется по суше до погрузки на судно.
Для соединения оптических волокон разработаны два способа соединений: разъемные и неразъемные. Неразъемные соединения оптических волокон осуществляются методом сварки, методом склеивания, а также с помощью механических соединителей. Для создания разъемных соединений оптических волокон используются оптические коннекторы.
Соединения оптических волокон с помощью сварки
Соединение оптических волокон с помощью сварки является сегодня наиболее распространенным методом получения неразъемных соединений. Благодаря в достаточной мере совершенной технологии этот метод позволяет получать качественные соединения с низкими показателями вносимых потерь (порядка 0,1-0,15 дБ), что обуславливает его применение на линиях связи, где этот показатель входит в приоритетные - магистральные, зоновые и другие - высокоскоростные ВОЛС.
Сваривание оптических волокон предусматривает оплавление концов волоконных световодов путем помещения их в поле мощного источника тепловой энергии, как, например, поле электрического разряда, пламя газовой горелки, зона мощного лазерного излучения.
Каждый из перечисленных методов имеет свои достоинства и недостатки. Достоинством метода сварки с помощью лазера можно считать возможность получения чистых соединений из-за отсутствия в них сторонних примесей, и, как следствие, достаточно малых вносимых потерь (0,1 дБ и менее). Как правило, в качестве источника лазерного излучения высокой мощности (до 5 Вт) используются газовые лазеры на СО2.
К достоинствам метода сварки с помощью газовой горелки следует также отнести возможность получения соединений оптических волокон, отличающихся высокой прочностью мест сростков. В качестве источника пламени используют смесь пропана с кислородом или соединение кислорода, хлора и водорода. Этот метод распространен по большей части для сварки многомодовых оптических волокон.
Основным достоинством сварки в поле электрического разряда является быстрота и технологичность. Этот метод в настоящее время приобрел наибольшую популярность для сварки одномодовых световодов.
Аппараты для сварки оптических волокон можно классифицировать следующим образом: по способу юстировки свариваемых концов оптических волокон (в зависимости от геометрических размеров сердцевин или от потерь мощности светового сигнала, распространяющегося через место сварки); по способу проведения операций (ручные или автоматические); по типу устройства контроля (микроскоп, монитор на жидких кристаллах); по количеству оптических волокон, которые могут быть сварены одновременно (одно- и многоволоконные).
При сварке оптических волокон в поле электрического разряда можно выделить такие технологические этапы:
* подготовка торцевых поверхностей соединяемых оптических волокон;
* надевание защитной термоусаживаемой гильзы на одно из соединяемых волокон;
* установка подготовленных концов оптических волокон в направляющие системы сварочного аппарата;
* юстировка свариваемых оптических волокон;
* предварительное оплавление торцов оптических волокон (fire cleaning) с целью ликвидации микронеровностей, возникающих в
* процессе скалывания;
* непосредственное сваривание оптических волокон;
* предварительная оценка качества сварки;
* защита места сварки с помощью термоусаживаемой гильзы;
* окончательная оценка качества сварки с помощью рефлектометра.
Существует два способа юстировки. Первый базируется на выравнивании сердцевин свариваемых оптических волокон по их геометрическим размерам (Profile Alignment System PAS) с помощью боковой подсветки концов свариваемых волокон.
Второй способ основан на выравнивании сердцевин оптических волокон по принципу минимизации потерь тестового светового сигнала, распространяющегося через место сварки.
Что касается активной юстировки, то известно три метода.
Первый заключается в использовании оптического излучателя и приемника на противоположных концах оптических волокон, подлежащих сварке. Информация от приемника передается персоналу, производящему сварку.
Второй метод сводится к использованию оптического передатчика на дальнем конце и детектора в точке соединения. Тестовый оптический сигнал выводится из соединяемого оптического волокна на небольшом (примерно 0,5 м) расстоянии от места сварки на изгибе и детектируется приемником, оборудованным измерителем оптической мощности.
Третий метод реализует LID (Local Injection and Detection) - процедуру юстировки, ограниченную исключительно местом соединения. В основу этого метода положено введение тестового оптического сигнала в сердцевину одного из соединяемых оптических волокон и поиск его в сердцевине второго соединяемого волокна путем изгиба.
Метод LID является наиболее эффективным, поскольку, в отличие от метода PAS, качество сварного соединения в большей мере зависит от сварочного аппарата, а не от индивидуального мастерства персонала. В современных сварочных аппаратах для управления процессами юстировки и сварки используются микропроцессоры, с помощью которых возможна оптимизация процесса сварки для получения минимальных (менее 0,1 дБ) потерь в местах соединений оптических волокон.
В процессе оплавления оптические волокна подаются одновременно для предотвращения укорачивания одного из них в месте сварки. Операции оплавления и сваривания, как правило, выполняются автоматически. В современных автоматических сварочных аппаратах для снятия механического напряжения в точке соединения оптических волокон предусмотрен режим прогревания места стыка по окончании процесса сварки. Такой режим называется "режимом релаксации".
Цикл плавления (длительность подачи и сила тока как для предварительного оплавления, так и для сварки и релаксации) для оптических волокон различных производителей и типов различны.
Некоторые сварочные аппараты, кроме рассмотренных выше способов контроля качества места сварки, используют еще и тест на растяжение во избежание нарушения соединения во время манипуляций при выкладке сростков в кассету, а также в дальнейшем, в процессе эксплуатации. Соединенное оптическое волокно прочно закреплено в направляющих платформах (которые используются при юстировке). Под контролем микропроцессора по завершении этапа сварки эти направляющие платформы расходятся в противоположные стороны, образуя строго нормированное продольное усилие на растяжение, приложенное к месту стыка. Считается, что стык, прошедший такое тестирование, более надежен и выполнен более качественно. При невозможности получения стыка, способного пройти этот тест, но удовлетворяющего по параметрам передачи, эту опцию можно отключить.
Особо следует отметить сварку ленточных элементов (ленточных волоконно-оптических кабелей, отличающихся большим количеством оптических волокон). Эту операцию можно проводить, только применяя полностью автоматический сварочный аппарат, с помощью которого можно соединить до 12 оптических волокон приблизительно за 3 минуты, причем средний уровень потерь составит около 0,1-0,15 дБ. Однако для сваривания ленточных элементов необходим опытный, хорошо подготовленный персонал.
Во время сварки оптические волокна размещаются с соответствующим смещением от оси электродов, что обеспечивает равномерное нагревание. До начала процесса сваривания и по его завершении проверяется смещение оптических волокон, состояние торцевых поверхностей, а также деформация.
При сваривании ленточных элементов необходимо, кроме основных процессов, рассмотренных ранее, провести еще три технологические операции: устранить расхождения торцов соединяемых оптических волокон, плавление всех волокон выполнить одновременно с одинаковой температурой, в процессе предварительной оценки измерить уровень вносимых потерь рефлектометром. Если оказалось, что результаты не отвечают требованиям, процесс сварки повторяют.
Как показывает практика, предварительная оценка качества сварных соединений оптических волокон, базирующаяся на методе РАС, может содержать погрешность в диапазоне 5-1000%, поэтому окончательный вывод о качестве сварного соединения стоит делать после измерений рефлектометром.
По мере совершенствования качества сварочного оборудования и технологии сварки возрастают возможности получения сварных соединений оптических волокон высокого качества. Потери на сварных соединениях зависят от нескольких факторов: опыта персонала, геометрических погрешностей свариваемых оптических волокон, а также от материалов, из которых изготовлены волокна. Особенно часто проблемы возникают при сварке оптических волокон различных производителей. Дело в том, что оптические волокна различных производителей изготавливаются с использованием принципиально отличающихся друг от друга технологических процессов. В результате материал оптических волокон - кварцевое стекло - не является идентичным в волокнах различного происхождения, несмотря на то, что параметры оптических волокон, указанные в спецификациях фирм-производителей, отличаются незначительно.
Факторами, определяющими свойства стекла, являются технология изготовления и качество материалов. Многочисленные исследования показали, что тысячные доли процента примесей в кварцевом стекле оказывают большее влияние, чем добавки в десятки процентов тех же компонентов к многокомпонентным стеклам.
Для сварки наибольшее влияние имеют следующие характеристики: плотность, коэффициент теплового расширения, показатель преломления, вязкость и механические характеристики. Эти параметры определяют оптические потери в местах сращивания и должны приниматься во внимание при использовании оптических волокон, произведенных по различным технологиям, в пределах одного элементарного кабельного участка ВОЛС. Особое внимание следует уделять идентификации оптических волокон в кабеле по типу, производителю и технологии изготовления.
Более совершенные аппараты для сварки оптических волокон содержат программы, оптимизирующие процесс сварки для оптических волокон различных типов и различных производителей, однако на практике нередки ситуации, когда, используя стандартные программы, невозможно получить качественную сварку. В этих случаях необходимо самостоятельно корректировать параметры процесса (время и ток, подаваемый на электроды) для достижения оптимальных результатов.
[pagebreak]
Наиболее часто сварка оптических волокон различных производителей производится при оконцовке оптических волокон пигтейлами, а также при ремонтно-восстановительных работах, если эксплуатационный запас кабеля израсходован, и приобретение полностью идентичного кабеля невозможно (к примеру, по причине снятия с производства оптического волокна такого типа, который использовался первоначально) или экономически нецелесообразно.
В общем виде величина потерь в местах сварных соединений может быть представлена как суммарная величина: Dобщ = Dор + Dдм + Dую + Dнм + Dрпп, где: Dобщ - суммарная величина потерь в сварке; Dор - потери из-за осевого рассогласования модовых полей равного диаметра; Dдм - потери из-за разницы диаметров модовых полей; Dую - потери от погрешности угловой юстировки осей оптических волокон; Dнм - потери, обусловленные не-круглостью модовых полей; Dрпп - потери из-за разницы показателей преломления.
Изучение параметров и характеристик различных одномодовых оптических волокон показывает, что разброс величины диаметра модового поля для l = 1310.1330 нм или l = 1500...1550 нм может составлять от 10,5 до 21,7% (9,2 0,5 мкм). Такое рассогласование приводит к появлению потерь от 0,05 дБ до 0,25 дБ (с положительным знаком, когда излучение проходит из волокна с большим диаметром в волокно с меньшим диаметром, и отрицательным - в противоположном направлении). Эти потери будут иметь место, даже если аппарат расположит соосно два волокна с разными диаметрами сердцевин, у которых эксцентриситет пренебрежительно мал. Обычно разброс величины модового поля оптического волокна не превышает 14%, таким образом, величина этой составляющей - не более 0,1 дБ.
Составляющая Dую практически не компенсируется современным сварочным оборудованием. Установлено, что углы между осями сердцевин 0,5°; 1°; 1,5°; 2° вызывают приращение потерь соответственно в 0,08; 0,34; 0,77 и 1,5 дБ. Таким образом, благодаря надлежащей подготовке торцов соединяемых оптических волокон при скалывании можно уменьшить потери - необходимо обеспечить наименьший (не более 0,5°) угол между плоскостями торцов оптических волокон. В этом случае величина потерь не превысит 0,08 дБ.
Составляющая Dнм учитывает влияние некруглости модового поля. По приблизительным оценкам она равна 0,05 дБ.
При соединении сваркой оптических волокон, имеющих неконцентричность модового поля, часто возникает нарушение юстировки сердцевин вследствие действия сил поверхностного натяжения. Это нарушение можно минимизировать следующими способами:
* сокращение времени плавления за счет неполного сваривания оптических волокон или же сокращение длины свободного конца оптического волокна в сварочном устройстве, чтобы концы оптических волокон в процессе сварки могли перемещаться на очень малое расстояние;
* использование компенсационных программ, таких как управление смещением сердцевины с помощью метода умышленного смещения осей.
Такой режим получил название RTC (Real Time Control). В этом режиме после юстировки сердцевин свариваемых оптических волокон и проведения процедуры предварительного оплавления происходит компенсация поперечного смещения сердцевин в сторону, противоположную производной расхождения.
Сварка оптических волокон осуществляется посредством чередования коротких импульсов тока высокой интенсивности с импульсами тока низкой интенсивности (релаксационными импульсами). При этом после сваривания в электрическом поле импульса высокой интенсивности в поле релаксационного импульса происходит перемещение оптических волокон под действием поверхностного натяжения. Количество чередующихся импульсов зависит от смещения сердцевин оптических волокон, которое постоянно контролируется сварочным аппаратом; как правило, количество импульсов не превышает 2-3.
Весьма существенное влияние на общую величину потерь, если свариваются оптические волокна с разными показателями преломления (N) сердцевины, может оказать составляющая Dрпп. Эта составляющая учитывает потери мощности оптического сигнала в результате несоблюдения условия полного внутреннего отражения на месте стыка двух оптических волокон, у которых показатели преломления сердцевин имеют различия. В этом случае часть оптического сигнала проникает через оболочку волокна и рассеивается. Ситуация усугубляется многократным отражением луча от границы "сердцевина/оболочка", каждое из которых (отражений) служит источником потери мощности. На практике нередки случаи, когда даже многократные повторные сварки не позволяют добиться малой величины потерь.
Наибольший вклад в суммарную величину потерь вносят потери от погрешности угловой юстировки осей оптических волокон и потери из-за разницы показателей преломления.
Международная электротехническая комиссия предлагает в качестве типичной характеристики сварного соединения оптических волокон, полученного в полевых условиях, величину вносимых потерь, равную 0,2 дБ (IEC 1073-1). При современном развитии технологии сварки оптических волокон этот показатель вполне достижим даже тем персоналом, который не обладает значительным опытом в этой области.
Соединение оптических волокон методом склеивания
Практически одновременно с методом сварки был разработан метод склеивания оптических волокон. Для получения клеевых соединений используют совмещение и фиксацию оптических волокон: в капилляре, в трубке с прямоугольным сечением, с помощью V-образной канавки и с помощью трех стержней в качестве направляющих. Оптические волокна соединяются поодиночке.
Технология получения таких соединений состоит из следующих этапов:
* подготовка оптических волокон к соединению (очистка, снятие буферных покрытий, скалывание);
* ввод оптического волокна в капилляр;
* наполнение иммерсионной жидкостью, гелем или клеем;
* регулирование соединения, юстировка оптических волокон;
* нанесение адгезивного вещества;
* цементирование адгезивного вещества с помощью ультрафиолетового излучения.
Клей, используемый для оптических волокон, должен иметь коэффициент преломления, близкий к коэффициенту преломления волокон. Он должен обеспечивать фиксированное положение соединенных оптических волокон, защищать место сращивания от воздействий окружающей среды, гарантировать прочность сростка при воздействии нагрузок в осевом направлении. К достоинствам этого метода следует отнести оперативность и отсутствие деформации сердцевин соединяемых оптических волокон. Это способствует тому, что в области стыка - малые потери, обеспечиваются хорошие механические свойства и т.п. Однако ограниченный срок службы и нестабильность во времени, а также весьма высокая чувствительность к повышению температуры и воздействию влажности являются факторами, сдерживающими распространение этого метода получения неразъемных соединений. В настоящее время он уступил свои позиции методу соединения оптических волокон с помощью механических соединителей.
Механические соединители оптических волокон
Механические соединители оптических волокон разрабатывались как более дешевый и быстрый способ сращивания оптических волокон. Применение аппарата для сварки оптических волокон сопряжено с необходимостью соблюдения ряда условий: для работы используется помещение, параметры которого (температурный диапазон, влажность, давление, вибрации и проч.) соответствуют требованиям производителей сварочного оборудования; также необходима организация питания от сети переменного тока с достаточно жестко регламентированными параметрами. При стоимости комплекта оборудования для сварки оптических волокон, составляющей десятки тысяч долларов США, амортизационные отчисления, а также техническое обслуживание и ремонт являются довольно дорогостоящими.
Достаточно высокие требования предъявляются также к персоналу, производящему работы по сварке оптических волокон. Часто этими же лицами производится наладка и обслуживание аппаратов для сварки оптических волокон (очистка направляющих поверхностей и зажимов, замена электродов и проч.), для чего требуются специалисты с высоким уровнем квалификации.
Всех этих сложностей можно избежать, применяя механические соединители оптических волокон. Конструкция оптических соединителей относительно проста. Основными узлами являются направляющие для двух оптических волокон и устройство фиксации волокон. Внутреннее пространство заполняется тиксотропным гелем для защиты открытых участков оптических волокон от воздействия влаги. Одновременно гель обладает иммерсионными свойствами - его показатель преломления близок к показателю преломления сердцевины волокна.
Процедура монтажа оптических соединителей является частью процедуры монтажа промежуточного или оконечного устройства - кабельной муфты, бокса или стойки. Размеры и форма оптических соединителей позволяют устанавливать их в кассету муфты или бокса аналогично сросткам оптических волокон, полученных путем сварки.
Процедура монтажа включает в себя следующие технологические операции:
* разделка кабелей;
* очистка оптических волокон от гидрофобного геля (при его наличии);
* снятие буферных покрытий соединяемых оптических волокон на участках длиной, рекомендуемой производителями оптических соединителей конкретного типа;
* скалывание оптических волокон;
* проверка качества скола волокон;
* введение соединяемых волокон в отверстия с направляющими;
* позиционирование волокон в соединителе для достижения оптимальных параметров соединения;
* фиксация оптических волокон в соединителе;
* тестовые измерения соединения.
Особое место среди оптических механических соединителей занимает RMS (Rotary Mechanical Splice) как наиболее сложный среди аналогов. Процесс его монтажа наиболее трудоемок, однако он позволяет достичь наименьших потерь при соединении одномодовых волокон. В отличие от остальных соединителей, где величина потерь главным образом зависит от качества скола торцевых поверхностей оптических волокон, этот соединитель позволяет юстировать волокна простым вращением вокруг своей оси стеклянных втулок, удерживающих подготовленные оптические волокна, и добиваться наилучших результатов.
Следует отметить, что применение механических соединителей является наиболее быстрым способом соединения оптических волокон. При этом вносимое затухание практически не отличается от затухания, создаваемого сварным соединением. Достаточно устойчивое функционирование механических соединителей в процессе эксплуатации позволяет уже сегодня рекомендовать их для широкого внедрения на телекоммуникационных сетях с невысокими требованиями к качеству соединений, а также в случаях, когда использование аппарата для сварки оптических волокон технологически затруднено или вообще невозможно. В дальнейшем статистика технической эксплуатации, а также совершенствование материалов компонентов механических соединителей, вероятно, определит их более широкое применение для строительства телекоммуникационных волоконно-оптических линий различных уровней.
Обращает на себя внимание тот факт, что механические соединители оптических волокон условно допускают однократное использование, однако на практике встречаются ситуации их многократного применения. Производители гарантируют качество соединения оптических волокон при повторном монтаже соединителя не более 2-3 раз, однако при повторном наполнении внутреннего пространства иммерсионным гелем (в тех конструкциях, где это предусмотрено) такие соединители использовались многократно без ущерба для качества стыков. Некоторыми производителями механических соединителей разработаны механизмы фиксации, предусматривающие использование специального ключа для открытия фиксатора.
Сегодня использование механических соединителей наиболее удобно при проведении аварийного ремонта волоконно-оптическихлиний для технологической операции организации временной вставки.
Процесс загрузки компьютера казалось бы изучен нами до мелочей: кнопка - BIOS - операционная система - логин... А ты задумывался когда-нибудь о том что же на самом деле происходит в это время внутри твоего компьютера? Можешь по шагам рассказать как работает компьютер? Уверен, что нет. Поэтому сегодня проведем короткий ликбез - расскажем о том, как же на самом деле загружается компьютер. Эта статья рассматривает работу Windows XP, в остальных системах процесс, естественно, несколько отличается.
Включается тумблер питания. Блок питания проводит самодиагностику. Когда все электрические параметры в норме БП посылает сигнал Power Good процессору. Время между включением питания и уходом сигнала обычно 0.1-0.5 секунд.
Таймер микропроцессора получает сигнал Power Good. С получением этого сигнала таймер перестает посылать сигнал Reset процессору, позволяя тому включиться.
CPU начинает выполнять код ROM BIOS. Процессор загружает ROM BIOS начиная с адреса FFFF:0000. По этому адресу прописан только переход на адрес настоящего кода BIOS ROM.
Система выполняет начальный тест железа. Каждая ошибка, встречающаяся на этом этапе сообщается определенными звуковыми кодами (в прошлом биканьем, сейчас уже вероятно более современно - голосом), так как видео система еще не инициализирована.
BIOS ищет адаптеры, которые могут потребовать загрузки своего BIOS-а. Самым типичным случаем в этом случае является видео карта. Загрузочная процедура сканирует память с адреса C000:0000 по C780:0000 для поиска видео ROM. Таким образом загружаются системы всех адаптеров.
ROM BIOS проверяет выключение это или перезагрузка. Процедура два байта по адресу 0000:0472. Любое значение отличное от 1234h является свидетельством "холодного" старта.
Если это включение ROM BIOS запускает полный POST (Power On Self Test). Если это перезагрузка, то из POST процедуры исключается проверка памяти. Процедуру POST можно разделить на три компоненты:
* Видео тест инициализирует видео адаптер, тестирует карту и видео память, показывает конфигурацию или возникшие ошибки.
* Идентификация BIOS-а показывает версию прошивки, производителя и дату.
* Тест памяти проверяет чипы памяти и подсчитывает размер установленной памяти.
Ошибки, которые могут возникнуть в ходе POST проверки можно разделить на смертельные и не очень :). Во втором случае они показываются на экране, но позволяют продолжить процесс загрузки. Ясно, что в первом случае процесс загрузки останавливается, что обычно сопровождается серией бип-кодов.
BIOS читает конфигурационную информацию из CMOS. Небольшая область памяти (64 байт) питается от батарейки на материнской платы. Самое главное для загрузки в ней - порядок, в котором должны опрашиваться приводы, какой из них должен быть первым - дисковод, CD-ROM или винчестер.
Если первым является жесткий диск, BIOS проверяет самый первый сектор диска на наличие Master Boot Record (MBR). Для дисковода проверяется Boot Record в первом секторе. Master Boot Record - первый сектор на цилиндре 0, 0 головке, 512 байт размером. Если она находится, то загружается в память по адресу 0000:7C00, потом проверяется на правильную сигнатуру - два последних байта должны быть 55AAh. Отсутствие MBR или этих проверочных байт останавливает процесс загрузки и выдает предупреждение. Сама MBR состоит из двух частей - системного загрузчика (partition loader или Boot loader), программы, которая получает управление при загрузке с этого жесткого диска; таблицы разделов (партиций), которая содержит информацию о логических дисках, имеющихся на жестком диске.
Правильная MBR запись записывается в память и управление передается ее коду. Процесс установки нескольких операционных систем на один компьютер обычно заменяет оригинальный лоадер на свою программу, которая позволяет выбрать с какого диска производить остальную загрузку.
Дальше Boot Loader проверяет таблицу партиций в поисках активной. Загрузчик дальше ищет загрузочную запись (Boot Record) на самом первом секторе раздела. В данном случае Boot Record это еще 512 байт - таблица с описанием раздела (количество байт в секторе, количество секторов в кластере и т.п.) и переход на первый файл операционной системы (IO.SYS в DOS).
Операционная система.
Управление передается операционной системы. Как же она работает, как проходит процесс загрузки?
Boot Record проверяется на правильность и если код признается правильным то код загрузочного сектора исполняется как программа. Загрузка Windows XP контролируется файлом NTLDR, находящемся в корневой директории системного раздела. NTLDR работает в четыре приема:
1. Начальная фаза загрузки
2. Выбор системы
3. Определение железа
4. Выбор конфигурации
В начальной фазе NTLDR переключает процессор в защищенный режим. Затем загружает соответствующий драйвер файловой системы для работы с файлами любой файловой системы, поддерживаемой XP. Если кто забыл, то наша любимая ОСь может работать с FAT-16, FAT-32 и NTFS.
Если в корневой директории есть BOOT.INI, то его содержание загружается в память. Если в нем есть записи более чем об одной операционной системе, NTLDR останавливает работу - показывает меню с выбором и ожидает ввода от пользователя определенный период времени. Если такого файла нет, то NTLDR продолжает загрузку с первой партиции первого диска, обычно это C:\.
Если в процессе выбора пользователь выбрал Windows NT, 2000 или XP, то проверяется нажатие F8 и показ соответствующего меню с опциями загрузки. После каждой удачной загрузки XP создает копию текущей комбинации драйверов и системных настроек известную как Last Known Good Configuration. Этот коллекцию можно использовать для загрузки в случае если некое новое устройство внесло разлад в работу операционной системы.
Если выбранная операционная система XP, то NTLDR находит и загружает DOS-овскую программу NTDETECT.COM для определения железа, установленного в компьютере. NTDETECT.COM строит список компонентов, который потом используется в ключе HARDWARE ветки HKEY_LOCAL_MACHINE реестра.
Если компьютер имеет более одного профиля оборудования программа останавливается с меню выбора конфигурации.
После выбора конфигурации NTLDR начинает загрузку ядра XP (NTOSKRNK.EXE). В процессе загрузки ядра (но перед инициализацией) NTLDR остается главным в управлении компьютером. Экран очищается и внизу показывается анимация из белых прямоугольников. Кроме ядра загружается и Hardware Abstraction Layer (HAL.DLL), дабы ядро могло абстрагироваться от железа. Оба файла находятся в директории System32.
NTLDR загружает драйвера устройств, помеченные как загрузочные. Загрузив их NTLDR передает управление компьютером дальше. Каждый драйвер имеет ключ в HKEY_LOCAL_MACHINE\SYSTEM\Services. Если значение Start равно SERVICE_BOOT_START, то устройство считается загрузочным. Для кажого такого устройства на экране печатается точка.
NTOSKRNL в процессе загрузки проходит через две фазы - так называемую фазу 0 и фазу 1. Первая фаза инициализирует лишь ту часть микроядра и исполнительные подсистемы, которая требуется для работы основных служб и продолжения загрузки. На этом этапе на экране показывается графический экран со статус баром. XP дизейблит прерывания в процессе фазы 0 и включает их только перед фазой 1. Вызывается HAL для подготовки контроллера прерываний. Инициализируются Memory Manager, Object Manager, Security Reference Monitor и Process Manager. Фаза 1 начинается когда HAL подготавливает систему для обработки прерываний устройств. Если на компьютере установлено более одного процессор они инициализируются. Все исполнительные подсистемы реинициализируются в следующем порядке:
Инициализация Менеджера ввода/Вывода начинает процесс загрузки всех системных драйверов. С того момента где остановился NTLDR загружаются драйвера по приоритету. Сбой в загрузке драйвера может заставить XP перезагрузиться и попытаться восстановить Last Known Good Configuration.
Последняя задача фазы 1 инициализации ядра - запуск Session Manager Subsystem (SMSS). Подсистема ответственна за создание пользовательского окружения, обеспечивающего интерфейс NT. SMSS работает в пользовательском режиме, но в отличии от других приложений SMSS считается доверенной частью операционной системы и "родным" приложением (использует только исполнительные функции), что позволяет ей запустить графическую подсистему и login.
SMSS загружает win32k.sys - графическую подсистему. Драйвер переключает компьютер в графический режим, SMSS стартует все сервисы, которые должны автоматически запускаться при старте. Если все устройства и сервисы стартовали удачно процесс загрузки считается удачным и создается Last Known Good Configuration.
Процесс загрузки не считается завершенным до тех пор, пока пользователь не залогинился в систему. Процесс инициализируется файлом WINLOGON.EXE, запускаемым как сервис и поддерживается Local Security Authority (LSASS.EXE), который и показывает диалог входа в систему. Это диалоговое окно показывается примерно тогда, когда Services Subsystem стартует сетевую службу.
Проблема защиты от потери данных во все времена волновала пользователей компьютеров, а владельцы ноутбуков должны быть осторожны вдвойне. Портативные ПК намного проще украсть и физически повредить.
В Windows XP Professional процедура резервного копирования данных на редкость проста. Сначала щелкните на пункте меню Start (Пуск) - All Programs (Программы) - Accessories (Стандартные) - SystemTools (Служебные) - Backup (Архивация данных).
Затем следуйте указаниям «мастера» Backup, который поможет выбрать файлы для копирования, а также указать накопитель, где необходимо создать файлы, содержащие резервную копию данных.
Кнопка Advanced (Расширенный режим) в одном из завершающих окон «мастера» обеспечивает доступ к расширенным функциям резервного копирования.
Здесь можно выбрать следующие режимы: нормальный или копирования (в обоих режимах каждый раз сохраняются все отмеченные файлы), инкрементный или дифференциальный (в обоих случаях копируются файлы, измененные со времени предыдущей процедуры) либо ежедневный (копирование всех файлов, созданных за день).
В режимах копирования и дифференциальном подвергшиеся копированию файлы не помечаются как прошедшие эту процедуру. «Мастер» позволяет указать и другие параметры, например, составить ежедневное расписание автоматического копирования.