Время ожидания 32-разрядных приложений кончилось. Теперь их может разрабатывать каждый при помощи программных средств разработчика.


СОКЕТЫ
ПЕРЕНЕСЕНИЕ ДЛЯ НАЧИНАЮЩИХ
РАЗДЕЛЯЙ И ВЛАСТВУЙ
ОСНОВНЫЕ РАЗЛИЧИЯ
ИНСТРУМЕНТЫ ТОРГОВЛИ
ВЫТЕСНЯЮЩИЕ ПРОТОКОЛЫ 101
КОГДА ОДИН РАЗМЕР ПОДХОДИТ НЕ ВСЕМ
Различия в DLL

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

С "взрывоопасным" ростом Internet и World Wide Web межсистемные коммуникации приобретают все большее значение. В этой статье даются некоторые рекомендации по созданию и перенесению программ для быстрейшего налаживания таких коммуникаций. Мы рассмотрим также некоторые программные средства разработчика (SDK) для создания коммуникационных продуктов.

СОКЕТЫ

Windows Socket API - это интерфейс программирования для программного обеспечения TCP/IP. Так как большая часть программного обеспечения TCP/IP для Windows поддерживает Winsock API, написание клиент-серверного приложения в соответствии с этой спецификацией дает возможность использовать это приложение с различными стеками TCP/IP. Большинство описанных в этой статье продуктов представляют собой совместимые с Winsock 1.1 средства разработчика, они включают все необходимые инструменты для разработки коммуникационных программ.

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

Компиляция для Windows исходного кода из среды Unix влечет за собой предупреждения о несовпадении как знаковых, так и типов данных без знака (+, - или 0). Вместо проверки на наличие ошибок посредством сравнения возвращаемого значения с -1 или определения того, что значение отрицательно, приложение Win32 использует постоянную invalid_socket, как определено в файле-заголовке winsock.h. (Win32 - это интерфейс прикладного программирования для 32-разрядного расширенного режима, полностью поддерживаемый Windows NT.)

Интерфейс сокетов Windows работает как с однопоточными (Windows 3.1 и Windows for Workgroups), так и с многопоточными (Windows 95 и Windows NT) версиями Windows. Ответственность за синхронизацию доступа к сокету и выполнения нитей лежит на приложении.

ПЕРЕНЕСЕНИЕ ДЛЯ НАЧИНАЮЩИХ

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

Кодировочные параметры Windows NT и Windows 95 также отличаются друг от друга. Некоторые операции и коды, поддерживаемые в Windows NT, не поддерживаются Windows 95 - во всяком случае предоставляемая Microsoft документация не содержит на это указаний. Кроме того, Win32 несколько отличается от Win32s, включащих подмножество полного множества параметров Win32.

Первым шагом к переносу приложения должен стать пересмотр деклараций оконных процедур. Различия между основными оконными процедурами в 16- и 32-разрядных средах видны из Рис. 1.

ОКОННЫЕ ПРОЦЕДУРЫ

Процедура главного окна в 16-разрядной среде
LONG FAR PASCAL MainWndProc
(HWND hWin, unsigned message, WORD wParam, LONG IParam)
{
 switch (message)
 {
  case WM_COMMAND:
  id=wParam:
  hWnd=LOWORD (IParam);
  cmd=HIWORD(IParam);
 }
}
Процедура главного окна в 32-разрядной среде
LONG WINAPI MainWndProc
(HWND hWin, UINT message, UINT wParam, LONG IParam)
{
 switch (message)
 {
  case WM_COMMAND:
  id=LOWORD(wParam):
  hWnd=(HWND)(UINT)(IParam);
  cmd=HIWORD(wParam);
 }
}

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

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

ИЗМЕНЕНИЕ ИСХОДНОГО КОДА

Если какая-либо последовательность 16-разрядного кода выглядит следующим образом:
case WM_COMMAND:
        id=wParam;
        hwndChild=LOWORD(IParam);
        cmd=HIWORD(IParam);
то результирующий код будет иметь такой вид:
case WM_COMMAND:
        id=LOWORD(wParam);
        hwndChild=(HWND)(UINT)(IParam);
#ifdef WIN32
                cmd=HIWORD(wParam);
        #else
                cmd=HIWORD(IParam);
        #endif

Рисунок 2.
Если wParam является 32-разрядным вызовом, то дескрипторы окна в этом случае будут иными. Наиболее эффективный способ преобразовать код - это сделать его переносимым, чтобы он мог функционировать как в 16-разрядной, так и в 32-разрядной среде.

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

Динамически компонуемые библиотеки являются важной частью любого кода для Windows (см. врезку "Различия в DLL"). Следуя подходу Unicode, разработчики должны создать одну версию библиотек и исполняемых программ, поддерживающих как двухбайтные наборы символов, так и европейские языки, при переносе на Windows NT. Unicode - это подмножество набора символов ASCII, использующего два байта для каждого символа, что достаточно для кодирования алфавита большинства языков.

Разработчик может компилировать приложение с использованием типов символов Unicode, определив Unicode до операторов include для файлов-заголовков (эти "указания" определяют среду для конкретной компиляции).

В 32-разрядном программировании абсолютно необходимо правильно применять типы данных: если одни типы данных стали 32-разрядными, то другие при этом остались 16-разрядными. В результате такие типы данных, как hwnd и word, не являются взаимозаменяемыми.

При переносе в 32-разрядную среду и Windows NT, и Win-dows 95 поддерживают имена файлов длиной до 256 символов вместо привычного формата 8.3, принятого в MS-DOS. Таким образом, размер буфера имен файлов должен быть увеличен с учетом возросшей длины имени.

Наконец, в 32-разрядной среде использовать файлы .ini не рекомендуется. Поэтому вызовы API должны быть заменены на код с доступом к регистрационной базе данных в Win32.

РАЗДЕЛЯЙ И ВЛАСТВУЙ

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

Наилучшим способом представляется использование thunk. Данный слой процедур принимает 16-разрядные запросы API, преобразует их в 32-разрядные, выдает запросы и реализует условия возврата к 16-разрядной семантике. Thunk - весьма удобные инструменты, но если поставщих ПСР полностью перенес поставляемый пакет, то такие ухищрения ни к чему.

Несмотря на то что в Windows 95 работает подавляющее большинство унаследованных от DOS, Windows и Windows for Workgroups программ, использование 32-разрядных приложений имеет свои преимущества. Одним из таких преимуществ является производительность. Практически все приложения, разработанные или перенесенные для работы с 32-разрядным процессором и шиной, обладают гораздо большей производительностью, вне зависимости от типа приложения. Хотя производительность не увеличивается вдвое, ее рост заметен даже простому пользователю.

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

ОСНОВНЫЕ РАЗЛИЧИЯ

Компания Distinct, поставщик программных средств разработчика TCP/IP для Windows, перенесла все свои продукты в 32-разрядную среду Windows 95. Представители компании заявляют, что в большинстве случаев разработчику достаточно только перекомпилировать код при использовании 32-разрядных SDK от Distinct.

Distinct TCP/IP SDK-32 включает Remote Utilities Library, простой протокол передачи почты (SMTP), протокол почтового офиса (POP), ftp, протокол передачи новостей по сети (NNTP), вызов удаленных процедур/внешнее представление данных (RPC/XDR), эмуляцию терминала VT220 и telnet. Каждый из этих протоколов предоставляет по крайней мере одну специфическую функцию для сетевых коммуникационных приложений.

Возможности библиотеки удаленных утилит включают rcp, rexec, rlogin и rsh. Каждая из них обеспечивает некоторый способ управления файлами между локальным или удаленным хостом и локальным или удаленным пользователем. При использовании rcp попытка скопировать файл на себя приводит к порче файла.

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

Библиотека SMTP-32 - это 32-разрядная версия SMTP. Она предоставляет разработчикам API для создания служб доставки почты от почтовых клиентов через почтовые серверы другим серверам или клиентам сети.

Библиотека Distinct POP-32 - это API для почтового сервера, он позволяет клиентам извлекать почту из персональных почтовых ящиков.

FTP-32 - API для стандартного сервиса ftp, доступного на большинстве хостов на базе TCP/IP. В отличие от большей части функций или соединений Remote Utilities Library, ftp-серверы требуют введения пароля - как правило, это полный адрес электронной почты сервера.

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

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

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

NEWT-SDK 5.0 компании NetManage реализует коммуникации по локальным сетям, беспроводным, коммутируемым и ISDN-соединениям. Данный комплект разработчика для 32-разрядных приложений Windows включает примеры приложений, файлы-заголовки, библиотеки и динамически компонуемые библиотеки для всех API. В силу совместимости с Winsock 1.1 все элементы управления и DLL пригодны для стеков NetManage, Microsoft, а также других поставщиков.

NEWT-SDK поставляется, кроме того, с NEWTTrace Desktop Packet Analyzer. Этот анализатор пакетов TCP/IP, поддерживающий Ethernet, Token Ring и последовательные протоколы (SLIP, PPP, ISDN), собирает данные, которыми обмениваются ПК пользователей, не прерывая работы приложений. Он обеспечивает полное декодирование пакетов TCP/IP и отображает при желании несколько пакетов одновременно (для сравнения).

ИНСТРУМЕНТЫ ТОРГОВЛИ

Комплект инструментов PowerTCP Toolkit компании Dart Communications имеет много общего с продуктами Distinct и Net Manage за одним важным исключением - данные средства разработчика работают также с языком программирования Delphi. Продукты Distinct, NetManage и PowerTCP предназначены, вообще говоря, для Microsoft и Borland C/C++ или Visual Basic; PowerTCP включает также версии для FoxPro, Access и PowerBuilder.

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

Для пользователей, рассматривающих Visual Basic как начало и конец всему среди языков программирования, Sax Software может стать хорошей стартовой точкой. Если другие поставщики только поддерживают версии своих SDK для Visual Basic, то Sax концентрируется исключительно на SDR для Visual Basic.

Стандартное издание Sax Basic Engine включает редактор и отладчик, но при этом пользователь работает скорее с макроязыком, чем с полнофункциональным высокоуровневым профессиональным языком разработки.

FTP Software предлагает OnNet 32 SDK 4.0 для сред Windows наряду с PC/TCP SDK 3.2 для DOS. SDK предлагает 32-разрядное ядро драйвера виртуального устройства, 32-разрядные Windows Sockets API и 32-разрядные библиотеки.

OnNet SDK не столь мощен, как пакеты Distinct и NetManage, но он имеет набор работающих примерных программ и отладочных инструментов, например анализатор IP Trace Packet. Среди других средств Interdrive 95 (высокопроизводительный клиент сетевой файловой системы Windows 95) и Interdrive NT, многонитевый клиент NFS для ядра Win-dows NT. KEYview 4.2 предоставляет утилиту просмотра и конвертации для Windows 95. Поддержка OLE 2.0 дает пользователям возможность буксировать текст и картинки из KEYview в другие OLE-совместимые приложения.

Коммуникационные функции OnNet SDR включают Mail OnNet, эмуляцию терминала, ftp-приложения для сервера и клиента.

ВЫТЕСНЯЮЩИЕ ПРОТОКОЛЫ 101

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

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


Джон Брайан - автор статей о персональных системах и цифровых коммуникациях. С ним можно связаться через Internet по адресу: jbryan@mcimail.com.

КОГДА ОДИН РАЗМЕР ПОДХОДИТ НЕ ВСЕМ

Различия в DLL

Основные отличия между 16- и 32-разрядными динамически компонуемыми библиотеками заключаются в процедуре их инициализации и завершения: в том, например, как часто они вызываются, какие данные передаются и какая часть кода должна быть написана на ассемблере.

В Windows 3.x инициализация и завершение осуществляются двумя разными функциями, при этом функция завершения должна носить имя wep. В Win32 DLL инициализация и завершение обрабатываются одной и той же функцией.

Реализация выполнения нитей в Win32 и Win32s также сопряжена с некоторыми изменениями в функционировании DLL. Каждый раз при первом доступе нити к DLL или при отделении нити или процесса вызывается функция инициализации (или завершения). Среда Windows 3.x не поддерживает нити, поэтому процессы инициализации и завершения вызываются только однажды за время жизни DLL.

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

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

Поделитесь материалом с коллегами и друзьями