Если конкретная часть программного обеспечения предназначена для работы на одной платформе, а программист/компания/кто-то хочет перенести ее на другую, что именно делается? Я имею в виду, они просто переписывают ссылки, специфичные для Linux или Windows, на эквивалентные в другом? Или нужно полностью переписывать?
Просто пытаюсь понять, что делает его настолько дорогостоящим, что многие крупные поставщики не переносят свое программное обеспечение на Linux (в частности, думая об Adobe).
Спасибо
в этом смысл кросс-платформенного набора инструментов, такого как qt или gtk, они предоставляют независимый от платформы API, который делегирует полномочия на любую платформу, для которой скомпилирована программа.
некоторые компании не используют такой инструментарий и пишут свой собственный (по какой-то причине - вполне может быть связан с оптимизацией), что означает, что они не могут просто перекомпилировать свой код для другой ОС.
Существуют также доступные библиотеки, которые облегчают, по крайней мере в определенной области, перенос вызовов API Windows в Linux. См. библиотеку переноса с Windows на Linux.
По моему опыту, есть три основные причины, по которым невыгодно брать большую существующую программу на одной платформе и портировать ее на другую:
он (не обязательно преднамеренно) широко использовал какую-то библиотеку или API (часто графический интерфейс, но есть и множество других вещей), которые, как оказалось, не существуют на другой платформе.
он по незнанию стал пронизан зависимостью от нестандартных функций или странностей компилятора или других инструментов
это было написано кем-то, кто не знал, что вам приходится использовать какую-то странную функцию, чтобы заставить вещи работать на другой платформе (например, библиотеку Linux, которая не снабжена правильными __declspec директивами, которые вы нужна хорошая Windows DLL).
Написать кроссплатформенное приложение намного проще, если вы считаете это целью дизайна с самого начала, и у меня есть три конкретных рекомендации:
Используйте Boost — множество полезных вещей, которые вы обычно можете получить из API-интерфейсов и библиотек для конкретных платформ, но с помощью Boost вы получаете кроссплатформенность.
Выполняйте все свои действия по программированию с графическим интерфейсом, используя кроссплатформенную библиотеку. Мой фаворит в эти дни — Qt, но есть и другие достойные.
Создавайте и тестируйте каждый день на обеих платформах, никогда не позволяйте коду развить зависимость только от одной платформы и обнаружить это слишком поздно.
Существует множество причин, по которым может быть очень сложно перенести приложение на другую платформу, чаще всего это связано с тем, что некоторые интерфейсы, которые приложение использует для связи с системой, недоступны, и их либо приходится реализовывать самостоятельно, портировать библиотеку, от которой зависит ваше приложение, или перепишите приложение, чтобы оно использовало альтернативные функции. Сегодня большинство языков легко переносимы между аппаратными архитектурами и операционными системами, но проблема заключается в библиотеках, системных вызовах и, возможно, других интерфейсах, предоставляемых ОС (или платформой). Чтобы быть более конкретным:
Компиляторы могут различаться по своей конфигурации и стандартным функциям, которые они предоставляют. В Windows самым популярным компилятором для C/C++ является Visual Studio, а в unix — gcc и llvm (в сочетании со стандартной библиотекой glibc или BSD libc). Они ожидают разные флаги, разные формы объявления, создают разные форматы файлов исполняемых файлов и разделяемых библиотек. Несмотря на то, что в C и C++ есть стандартные библиотеки, они по-разному реализованы на разных платформах. Есть некоторые системы, целью которых является сделать компиляцию переносимой, например, Autotools, CMake и SCons.
Помимо стандартных библиотек есть дополнительные функции, которые предоставляет ОС. В Windows они покрываются API-интерфейсом win32, в системах unix они являются частью стандарта POSIX с различными специфическими расширениями GNU, BSD и Linux, а также есть простые системные вызовы (интерфейс самого низкого уровня между приложениями и операционной системой). . Функции POSIX доступны в Windows через такие системы, как cygwin и mingw, функция Win32 API доступна в Unix через Wine. Проблема в том, что эти реализации не полные, и часто есть небольшие (но важные) отличия.
Связь с десктопной системой (чтобы сделать графический интерфейс) осуществляется иначе. В Linux это может быть система X Window (вместе с библиотеками freedesktop) или Wayland, в то время как у Windows есть свои собственные системы. Существуют библиотеки графического интерфейса, которые пытаются предоставить для них абстрактный интерфейс, например Qt, GTK, wxWidgets, EFL.
Другие услуги, предоставляемые ОС, такие как сетевое взаимодействие, могут быть реализованы по-разному. В Windows многие приложения используют библиотеки .NET, поддержка которых в системах unix ограничена. Некоторые приложения Unix полагаются на специфичные для Linux функции, такие как systemd, /proc, KMS, контрольные группы, пространства имен. Это ограничивает переносимость даже между unix-системами (Linux, BSD-системы, Mac OS X, ...). Даже библиотеки .NET не очень совместимы между разными версиями и могут быть недоступны в более старых версиях Windows или во встроенных системах. Android и iOS имеют совершенно разные интерфейсы.
Веб-приложения, как правило, являются наиболее переносимыми, но HTML5 является действующим стандартом, и многие интерфейсы могут быть еще недоступны в некоторых браузерах/веб-движках. Это требует использования полифиллов, но обычно гораздо менее болезненно, чем ситуация с «нативными» приложениями.
Из-за всех этих ограничений перенос может быть довольно сложной задачей, и иногда проще создать новое приложение с нуля, либо специально для другой платформы, используя кросс-платформенные библиотеки/платформы абстракции (такие как Qt или Java), или как веб-приложение (потенциально входящее в состав чего-то вроде Electron). Это хорошая идея использовать их с самого начала, но многие программисты предпочитают этого не делать, потому что приложения имеют тенденцию выглядеть и вести себя иначе, чем «родные» приложения на платформе, и они также могут быть медленнее и более ограниченными в способах взаимодействия. с ОС.
Перенос части программного обеспечения, которое не было заранее сделано независимым от платформы, может быть огромной задачей. Часто код глубоко укоренен в непереносимых API, будь то сторонние или просто библиотеки ОС. Если сторонний поставщик не предоставляет API для платформы, на которую вы переносите, вы в значительной степени вынуждены полностью переписать эту функциональность или найти другого стороннего поставщика, который является переносимым. Это только может быть ужасно дорого.
Наконец, перенос программного обеспечения также означает его поддержку на другой платформе, что означает наем некоторых специалистов и обучение поддержки ответам на более сложные запросы.
В конце концов, такой процесс может быть очень дорогостоящим из-за очень небольших дополнительных продаж. К сожалению, решение простое: сосредоточьтесь на новой функциональности на вашей текущей платформе, за которую, как вы знаете, будут платить ваши клиенты.
Если программное обеспечение было написано для одной ОС, вероятно, потребуется серьезная переделка. Первый шаг — переместить абсолютно весь специфичный для платформы код в единую область кодовой базы; в этой области должно быть мало или совсем не должно быть материалов, специфичных для приложения. Затем перепишите эту изолированную часть кода для новой целевой ОС.
Конечно, это замалчивает некоторые чрезвычайно важные последствия. Например, если ваша первая версия нацелена на Win32 API, то любой код графического интерфейса будет сильно привязан к Windows, и, чтобы сохранить любую надежду на сохранение вашего здравомыслия, вам нужно будет переместить весь этот код в кроссплатформенную среду графического интерфейса, такую как Qt. или ГТК.
В Mono вы можете написать программу C# Winforms, которая работает на обеих платформах. Но чтобы сделать это возможным, команде Mono пришлось написать собственную библиотеку Winforms, которая по существу дублирует все функции Winforms. Так что бесплатного обеда до сих пор нет.
Большинство программ в той или иной степени переносимы. В случае с приложением C в области будет много #ifdefs, помимо изменений пути и т. д.
Редко версии одного и того же программного обеспечения для Windows/Linux не имеют общей кодовой базы - на самом деле это означает, что они имеют только общее имя. Всегда сложнее поддерживать больше кодовых баз, но я думаю, что реальная проблема с переносом приложений имеет мало общего с технической стороной и во многом с бизнес-стороной. У Linux гораздо меньше пользователей, чем у Windows/OSX, большинство из них ожидают, что все будет бесплатным, как пиво, или просто ненавидят коммерческое ПО по каким-то религиозным мотивам.
Если подумать, большинство программ с открытым исходным кодом являются мультиплатформенными, независимо от того, какой язык использовался для их реализации. Это говорит само за себя...
P.S. Отказ от ответственности - я ярый сторонник бесплатного программного обеспечения с открытым исходным кодом, я не хочу никого оскорблять - я просто делюсь своим взглядом на эту тему.
