Не секрет, что одним из ключевых факторов успеха на рынке ПО всегда была и остается длительность цикла разработки: выигрывает тот, кто успевает сделать конкурентоспособный продукт раньше других. Известно также, что определяется эта длительность в основном доступностью и функциональностью соответствующего инструментария. Для рынка встраиваемых ОС и ОС реального времени (ОСРВ) этот вопрос всегда стоял особенно остро, поскольку в данном случае ОС в целевой системе обычно скрыта от конечного пользователя, а следовательно, и не обязана быть дружественной; при этом вносить в нее дружественность только для создания штатной среды разработки было бы слишком накладно. В результате средства разработки для многих встраиваемых ОС и ОСРВ сосредоточились под более дружественными платформными ОС типа Windows и Unix, к тому же обладающими более выраженной, чем у специализированных ОС, системой стандартизации интерфейсов прикладного программирования (API), что значительно упрощало перенос приложений, а значит, делало средства разработки доступными сразу на ряде платформ.
Казалось бы, такое разделение функций между ОС (этот подход получил название кросс-разработки) вполне разумно. И тем не менее, несмотря на кажущуюся красоту решения, оно имеет по крайней мере три существенных недостатка.
Во-первых, разработчик в этом случае обязан ориентироваться как минимум сразу в двух ОС. Учитывая, что ОСРВ и встраиваемые ОС обычно имеют нестандартные интерфейс пользователя и API, а работа с ними часто требует глубокого знания аппаратных средств, перечень требуемых от разработчика знаний и навыков оказывается достаточно велик. Такого специалиста гораздо сложнее найти (и соответственно заменить), да и обойдется он весьма недешево.
Во-вторых, коль скоро инструментальная ЭВМ (host) и целевая ЭВМ (target) разнесены, перед испытанием новой версии целевого программного модуля его необходимо переносить после компиляции с инструментальной ЭВМ на целевую. Это может существенно удлинить цикл отладки.
В-третьих, разработчикам, хоть раз сталкивавшимся с отладкой целевых приложений, на собственном (обычно печальном) опыте известно: при тестировании приложения эксперимент должен быть как можно более «чистым», т. е. тестирование и отладку следует проводить в условиях, максимально приближенных к рабочим. В противном случае всегда остается опасность чего-то не учесть, а следовательно, опять же потерять драгоценное время, фактически подарив его конкуренту. Отсутствие же в целевой ОС штатных средств разработки, а значит, и штатного отладчика вынуждает использовать чужеродные отладочные модули, обеспечивающие интерфейс с удаленным отладчиком, работающим на инструментальной ЭВМ, — а такой эксперимент уже никак нельзя назвать «чистым».
Концепция, реализованная в QNX Realtime Platform, в противовес традиционному подходу к разработке приложений для ОСРВ на удивление проста и изящна. Нестандартность API и неудобство, а то и полное отсутствие пользовательского окружения не позволяют большинству ОСРВ иметь свои штатные средства разработки, вынуждая их пользоваться кросс-средствами. Но если в ОСРВ внести удобное пользовательское окружение и расширить API до некоего общепринятого стандарта, разумеется, сохранив при этом специфичные элементы функциональности, то появляется возможность переноса в данную ОСРВ программного обеспечения из других ОС, и в первую очередь популярных средств разработки. Таким образом достигаются сразу две цели. Во-первых, разработка перемещается в ту же ОС, где будет выполняться и целевая система (self-hosted development), и кросс-разработка со всеми ее недостатками теряет всяческую актуальность. Во-вторых, данная ОСРВ автоматически становится платформной ОС, поскольку стандартный API позволяет переносить в нее практически любое ПО, а наличие ядра реального времени дает ей ряд неоспоримых преимуществ, особенно для приложений, требующих высокоскоростной обработки данных, — например для задач мультимедиа.
Следует заметить, что такой подход для QSSL не является новым: реализованная в QNX Realtime Platform концепция логически продолжает идеи, воплощенные компанией в предыдущих проектах — небезызвестных ОСРВ QNX2 и QNX4. Сама по себе QNX4 уже была достаточно близка к идее платформной ОСРВ: она обладала достаточно дружественным интерфейсом пользователя, содержала штатную среду разработки, а ее API отвечал ряду стандартов семейства POSIX. Последнее обстоятельство позволило перенести в QNX4 ряд программных продуктов из других Unix-систем; однако поддержка весьма ограниченного числа стандартов привела к тому, что многие приложения отказывались компилироваться под QNX4 без серьезных доработок, в результате чего у разработчиков возник явный недостаток инструментария. В дополнение ко всему становлению QNX4 как платформной ОС мешала ее жесткая привязка к аппаратному обеспечению — из аппаратных платформ поддерживались только ПК на базе процессоров Intel x86.
Основной целью проекта QNX Realtime Platform, базирующегося на последней разработке QSSL — ОСРВ QNX/Neutrino (ее иногда называют QNX6), было обеспечение разработчиков встраиваемых систем и систем реального времени мощной программной платформой, которая одновременно являлась бы ОСРВ, была бы встраиваемой, масштабируемой и легко расширяемой, имела в своем распоряжении штатные средства разработки и была доступна большинству пользователей.
Встраиваемый веб-браузер Voyager поддерживает Macromedia Flash
