Кросс-платформенная разработка - Delphi 2011: Как создать межплатформенную библиотеку с использованием Windows?

Как вы уже знаете, скорее всего, следующая версия Delphi будет кросс-платформенная. Кроме того, вот некоторые опросы по этому вопросу.

В то время как писать кросс-компилятор сейчас не очень интересен, портирование библиотеки, которая была/связана с Windows на нескольких платформах, конечно же.

Вы можете думать, например, в VCL (стандартная библиотека Delphi). Хотя он был разработан только для Windows, он имеет ценность в нем и, конечно же, есть огромные кодовые базы, которые зависят от него.

Вопрос: Какой из них лучше всего подходит для межплатформенной платформы приложений/библиотек, обеспечивающей плавный путь перехода/обновления (насколько это возможно, конечно)?

Я подчеркиваю это снова, нам неинтересно, что это лучший способ сделать кросс-платформенное развитие только (были вопросы по этой теме). Мы также заинтересованы в еще одном требовании: старое управление базой/установкой кода.

PS: Опыты и/или методологии из аналогичных ситуаций с другими языками (например, C/С++), которые рассматриваются как стандартные методы, приветствуются.

Спасибо заранее.

ОТВЕТЫ

Ответ 1

Перспектива разработчика визуальных компонентов:

Добавьте уровни функциональности к вашему коду, чтобы иметь возможность добавлять другую платформу без изменения "Ядра" компонента. У компилятора, надеюсь, будет переключатель платформы. (Желательно более одного, работающих совместно друг с другом, например, Windows/ARM, Windows/386, OSX/Cacao/386, Linux/Gnome/386).

Структура Layout может выглядеть примерно так.

  • ComponentJ.pas
  • Linux\ComponentJ.pas
  • Linux\Гном\ComponentJ.pas
  • Linux\KDE\ComponentJ.pas
  • OSX\ComponentJ.pas
  • 386\ComponentJ.pas
  • ARM\ComponentJ.pas

Как разработчик приложения:

Я начну с перемещения всех вызовов WIN API в своем коде в группу библиотек в каталоге Windows, чтобы иметь возможность IFDEF на уровне библиотеки и перевести его на другую платформу, которую я хотел бы поддержать, как только компилятор становится доступным, но только когда я сталкиваюсь с ними.) Это также добавит возможность добавления адаптеров для новых платформ. В любом случае это хорошая практика для удаления возможных зависимостей в центральное место.

Ответ 2

IMHO вы не можете построить xplatform Delphi и обеспечить плавный переход для текущих приложений VCL. Это не сработает. VCL был (к счастью, потому что он позволял отличные приложения), разработанный с учетом Windows, и попытка создать совместимую библиотеку, работающую на другой платформе, означала бы более длительные циклы разработки и множество компромиссов. Результатом станет библиотека, которую никто не хотел бы использовать. Посмотрите, что случилось с VCL.NET: это был неправильный выбор. И он работал над той же ОС!

Мы знаем, что для таргетинга на платформу, отличную от Windows, с родными приложениями требуется встроенная библиотека графического интерфейса. Мы не заботимся о создании графического интерфейса с нуля, для нашего приложения это путь, нам не нужны графические интерфейсы Windows со всеми их стандартами в другой ОС с использованием разных стандартов - мы должны иметь возможность кодировать полностью родные GUI для целевой ОС. Другие приложения могут пережить перенос графического интерфейса, но в конечном итоге вы не получаете реального инструмента xplatform - вы получаете инструмент, который может компилироваться для других платформ, но привносит одну платформенную парадигму другим, и это также не приветствуется "родных" разработчиков на других платформах. Если вы разработчик Linux или Mac, почему вы должны научиться работать с библиотекой, которая наследует ваше наследование Windows на вашей платформе? Вы почувствуете боль в заднице. Если Embarcadero хочет продать XDelphi за пределами реальной базы разработчиков, он должен предложить гораздо больше, чем новый CLX.

Ответ 3

Я потянусь от какого-то древнего опыта в создании кросс-кода, скомпилированного между окнами и dos (Delphi 1/Turbo Pascal 7). Эмпирическое правило состояло в том, чтобы разделить код на несколько единиц. Попробуйте код БЕЗ использования окон, сообщений или любых визуальных компонентов. Если вы обнаружите, что вам нужно позвонить одному из них, тогда поместите этот вызов в другой блок и напишите прокси (абстрактный класс, который вы опускаете от работы хорошо), чтобы отправлять вызовы. Когда выпущена перекрестная совместимая версия, все, что вам нужно сделать, это код другой стороны прокси для новой цели.

Если вы разрабатываете систему на основе форм, тогда старайтесь придерживаться как можно большего числа стандартных компонентов. НИКОГДА не выполняйте какие-либо "бизнес-правила" непосредственно в событии, вместо этого размещайте их в другом устройстве и вызывайте в другой блок для выполнения логики.

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

Ответ 4

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

Ответ 5

Компромисс не следует делать слишком много, чтобы VCL совместим с Linux и Mac. Windows - корень VCL. Я предпочту новый и очень чистый графический интерфейс, хотя без обратной совместимости. Сделать VCL толще и толще - это не очень хорошая идея!

Ответ 6

  • сделать кросс-платформенный компилятор Pascal
  • сделать кросс-платформенный RTL
  • введите QT сверху

Хорошо, посмотрите freepascal и lazarus

Ответ 7

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

Я думаю, что Embar должен пойти на КПК, IPhone, Andriod, поскольку рабочий стол Windows уже есть  98% рынка.

Mac стоит дорого, а Linux вообще не стоит. Не стоит использовать Mac и Linux. Не стоит  инвестиции.

Ответ 8

Ну, в стороне от сказанного - спасибо всем - я думаю, что нам нужны дополнительные вещи:

  • нам нужны инструменты для выполнения необходимых преобразований
  • нам нужна инструментальная система, которая поможет нам в программировании против (в некоторой форме) шаблона MVC

Ответ 9

Просто выберите последний 4.6 QT и добавьте хорошую интеграцию между Pascal и библиотекой QT. Они сделали это раньше (в времена Kylix). В наши дни QT такой мощный.

Я считаю, что QT еще лучше, чем VCL, и по крайней мере в 10 раз чаще обновляется и фиксируется.

Итак, план прост:

  • сделать кросс-платформенный компилятор Pascal
  • сделать кросс-платформенный RTL
  • введите QT сверху

и у вас будут первоклассные приложения для поиска на всех платформах.

Ответ 10

Мое мнение:

  • Сделать кросс-платформенный компилятор (OS x/Linux/встроенные решения? /symbian?). Возможно, добавьте возможность компилировать/преобразовывать код pascal в переносимый код c/С++ для сборки на встроенных платформах.
  • RTL необходимо разделить на межплатформенный и нативный (как для JCL).
  • Добавить новые базовые компоненты для кросс-платформенной совместимости и собственных компонентов для каждой поддерживаемой платформы (QT для ex)
  • Добавьте утилиты перевода для создания/преобразования между компонентами платформы, например: для преобразования чистой формы Windows в форму mac os x cocoa.
  • Все иерархии компонентов Windows должны быть обновлены только для поддержки x64 с максимальной обратной совместимостью. Все межплатформенные компоненты должны быть в параллельной иерархии.
  • Следующая версия кросс-платформенного решения может быть реорганизована и может включать утилиту миграции/конвертации. Благодаря минимальной кодовой базе кросс-платформенных решений иерархия и классы для кросс-платформы могут сильно изменяться с версии на версию для достижения наилучшей архитектуры.

Извините за мой английский - не родной язык (русский есть)!

Ответ 11

  • Составить компиляторы C/С++/Delphi, ориентированные на OSX/Linux
  • Составить компилятор C/С++, который может быть увеличен
  • Создать новый VCL-Presentation Foundation (VGScene/WPF) он не должен быть обратно совместимым! Delphi IDE должна быть написанный с помощью такого VCL-PF
  • Библиотека компонентов должна оставаться такой, какая есть (но с улучшенной привязкой данных)
  • Предоставлять только 64-битную версию VCL для Win64

Это проблема?