Win32 может улучшить качество и надежность разработки ПО

Переход от Windows З.х к Windows 95 представляет собой своеобразный вызов разработчикам, для которых открываются пять путей повышения ценности своих программ. Приложения следующего поколения должны будут пользоваться преимуществами API Win32, эффективно использовать OLE 2.0, придерживаться нового стиля пользовательского интерфейса, описанного в Windows UI Style Guide 4.0, распознавать надлежащие события протокола "plug-and-play" и поддерживать возможности оболочки Windows 95 (благодаря которой функциональность рабочего пространства существенно увеличилась по сравнению с Windows З.х).

Windows 95 представлена как 32-разрядная модернизация Windows З.х, однако использование API Win32 означает больше, чем простую перекомпиляцию под несегментированное 32-разрядное адресное пространство. Несомненно, одно это уже было бы важным преимуществом, значительно упрощающим оптимизацию кода и облегчающим работу с большими структурами данных (которые используются, например, в мультимедиа-приложениях).

Разработка с использованием Windows 95

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

ИЗБЕГАЙТЕ ВОДОВОРОТОВ В ПОТОКАХ

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

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

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

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

СДЕЛАЙТЕ ПРАВИЛОМ НАДЕЖНЫЙ КОД

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

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

Авторам компиляторов придется, однако, позаботиться об интеграции структурированной обработки исключений Win32 с обработкой исключений на языке C++.

Очистка объектов C++ после исключения Win32 требует внимания к потоку управления при работе Win32.

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

Мы не в состоянии подробно рассматривать здесь протокол OLE (Object Linking and Embedding  -  связь и встраивание объектов) 2.0, однако лишь немногие разработчики захотят работать с OLE 2.0 на низком уровне первичного API. Они предпочтут более высокие уровни абстракции, обеспечиваемые готовыми компонентами или библиотеками классов.

Например, ожидающаяся версия 4.0 библиотеки Microsoft Foundation Classes позволит создавать приложения-контейнеры OLE, а также населяющие их управляющие элементы OLE. Это принципиально важно для поддержания конкурентного статуса мелких разработчиков, которые иначе оказались бы заперты в "программном гетто" в роли изготовителей добавочных продуктов к комплектам ПО крупных фирм, таких, как Microsoft Office и Lotus SmartSuite.

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

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

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

ЕСТЬ ЗОЛОТО В ЭТИХ API

Наконец разработчики должны изучить возможности, предоставляемые расширениями API Windows 95, такими, как Telephony API, в котором сделан особый упор на динамическую информированность приложении о меняющихся возможностях связи пользователя мобильной системы. Под Windows 95 программы могут динамически загружать и выгружать драйверы виртуальных устройств, так что приложение может использовать события протокола "Plug-and-Play", чтобы менять назначение устройств, обеспечивая интеллектуальное обращение с коммуникациями пользователя.

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

ПИТЕР КОФИ

Инструментальные средства третьих фирм, например 32-разрядная система программирования Delphi фирмы Borland International, будут обеспечивать доступ к таким технологиям Windwos 95, как управляющие элементы ОСХ

В переходе на продвинутый API разработчикам помогут SDK и инструментальные средства (такие, как Visual C++ 2.2) корпорации Microsoft