ОСНОВНЫЕ ПРИНЦИПЫ ПОРТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Под портированием понимают адаптацию некоторой программы или её частей, другими словами перенос из одной среды в другую, с максимальным сохранением пользовательских свойств. Проблема переносимости программных продуктов между различными программно-аппаратными платформами, появилась достаточно давно. Первые предпосылки были в начале семидесятых годов, когда возник вопрос о переносимости ОС UNIX на новые аппаратные платформы. Время шло и вместе с ним росла сложность программных продуктов, а, следовательно, усложнялся процесс их переноса. А ведь для многих компаний это был ключевой вопрос, так как возможность быстрого портирования предоставляла шанс закрепиться на мировом рынке. Однако не все производители уделяют этому столь большое внимание. Причиной может являться небольшая аудитория пользователей, недостаток средств или финансирования и т.д. Помимо этого, переносимое программное обеспечение имеет свои недостатки, например, потеря производительности работы программы на новой аппаратной платформе, большой объём работ, жесткая привязка к аппаратуре при более сложной организации целевой платформы.

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

1. Изучение особенностей строения, работы аппаратного обеспечения и операционных систем.
2. Выбор средств реализации.
3. Выбор метода переноса программного продукта.

Как уже упоминалось выше, первое с чего необходимо начать процесс портирования (после определения целей и ответа на главный вопрос, имеет ли это смысл?) это изучение соответствующей литературы, для более детального понимания строения и особенностей той или иной операционной системы и аппаратной платформы. Следует отметить, что большое количество “подводных камней”, кроется именно в операционных системах. Ведь в общем случае, необходимо учитывать общие свойства ОС, такие как: коллизии между включаемыми файлами, разные форматы объектных файлов, различие в обработке сигналов (при условии, что семантика сигналов одинакова). Так же необходимо учесть, что могут быть различны соглашения об именах файлов и, возможно, самое главное - это корректность написанной документации (или вовсе ее отсутствие). При возникновении коллизии между включаемыми файлами, можно попробовать обойти эту проблему, путем написания собственных библиотек, соответствующих стандарту целевой операционной системы, с соблюдением корректности работы всех исходных алгоритмов. При различных форматах объектных файлов, необходимо подобрать такую программу-компоновщик, которая создаст “корректные” объектные файлы для целевой операционной системы. Из-за использования иной программы-компоновщика, могут возникать различные ошибки, связанные с несовместимостью, требующие изменения исходных текстов или входных параметров. При различиях в алгоритмах обработки сигналов (при условии одинаковой семантической составляющей) необходимо воспользоваться средствами конечной операционной системы и внести соответствующие изменения в алгоритмы работы программы, после получения сигнала, так как в противных случаях, могут возникать различные ошибки, в дальнейшей работе.

При использовании языков высокого уровня С/С++, в качестве основных языков, для осуществления процесса портирования, необходимо отдать должное внимание генерации кода, осуществляемое компилятором. К этому моменту необходимо подходить с особым вниманием и стараться обходить такие ситуации. Часто для решения таких проблем используют макроподстановки. Очень важным свойством в различных операционных системах, является количество символов, которые распознаются в именах внешних объектов и функций. Нельзя забывать, что корректная переносимость должна включать в себя, уникальность первых 6 (8) символов имен функций или объектов. При этом не стоит забывать, что имена должны быть корректны – иметь некий смысл. При этом могут возникать ситуации, когда конечные системы будут использовать большее или меньшее количество первых символов уникальности имён. Именно с помощью макроподстановок, можно решить данную проблему, то есть отображать истинные имена объектов и функций в сокращенном виде, которые будут уменьшаться в требуемую длину символов. Так же нельзя забывать о разном представлении чисел, в различных операционных системах, так как диапазон целого числа типа int в стандартах не указан (сказано про то, что он должен быть от -32767 до 32767), аналогично имеет смысл производить замену float на double (при этом округление чисел с плавающей точкой на разных системах происходит по-разному).

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

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

1. Повторное использование бинарных файлов. Упростить процесс портирования можно если старая и новая версии системы будут схожи на бинарном уровне, иными слова новая система поддерживает двоичный интерфейс приложений (ABI). Следовательно, появляется возможность использовать двоичные файлы старой системы. Но и тут имеются “подводные камни”. Форматы файлов на старой и новой системе могут существенно отличаться (т.к. формат файла связан непосредственно с аппаратной частью). Тоже самое можно сказать про наборы библиотек и функций. Полного различия быть не может, но частые разнообразные пересечения и конфликты имеют место быть. Очень часто, данные упрощения применимы если у старой и новой системы один производитель.
2. Переиспользование исходных текстов на языках высокого уровня. Альтернативной заменой способа, описанного выше, является повторное использование исходных текстов, то есть применение одного и того же исходного текста для сборки приложений. Для корректного осуществления данного метода, необходимо использовать трансляторы с одинаковым набором библиотек, но трансляторы для различных систем, разрабатываются различными производителями и могут иметь существенные отличия, которые, естественно, необходимо учитывать. Часть этой проблемы облегчается следованием международным стандартам, но не все трансляторы, по той или иной причине, в полной мере поддерживают эти стандарты.
3. Виртуализация. Возможность запускать приложения на виртуальной машине (виртуальная машина - программная и/или аппаратная система, имитирующая некоторое аппаратное обеспечение, некоторой платформы) в основном зависит от возможностей самой машины. Но и тут имеются свои трудности. Например, программы, работающие с аппаратурой напрямую, могут не иметь доступа к устройствам виртуальной машины. Вторым недостатком является ресурсоемкость. Это связано с тем, что по мимо виртуальной машины, так же следует предоставить необходимый набор ресурсов для программного продукта.
4. Эмуляция. В ряде определенных случаев операционная система может обеспечить бинарную совместимость с другой системой, за счет дополнительных средств. В наше время существуют специальные программы (эмуляторы), позволяющие загружать файлы операционных систем, при помощи использования транслятора. Транслятор загружает файлы необходимого формата и преобразует вызовы функций, осуществляемые внутри файла в соответствующие вызовы текущей операционной системы. К недостаткам, данного способа, можно отнести неполноту реализации. Например, если программное обеспечение использует недокументированные возможности программного продукта, то при попытке запуска, скорее всего возникнут ошибки. Вторым недостатком является невысокая производительность. Эта проблема решается путём низкоуровневого взаимодействия с системой. Но из этого могут вытекать ошибки, связанные с жёсткой привязкой к аппаратуре.

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

Список литературы:

1. Методы обеспечения переносимости ПО. [Электронный ресурс].        URL: http://citforum.ru/SE/testing/portability/ (дата обращения: 10.04.2016)
2. Написание переносимых программ [Электронный ресурс]. URL: http://givi.olnd.ru/wclr/15_portable.html (дата обращения: 7.04.2016)
3. Переносимость программного обеспечения GNU [Электронный ресурс]. URL: http://www.osp.ru/os/1993/02/178447/ (дата обращения: 7.04.2016)