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

Question

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

Хотя написание кросс-компилятора сейчас нас не очень интересует, портирование библиотеки, которая была / связана с Windows на несколько платформ, безусловно, делает это.

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

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

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

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

Заранее спасибо.

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

• 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 на уровне библиотеки и перевести его на другую платформу, которую я хотел бы поддержать, как только компилятор становится доступным, но только тогда, когда я с ним сталкиваюсь.) Это также добавит возможность добавлять адаптеры для новых платформ. В любом случае хорошей практикой является удаление возможных зависимостей в центральное место.

Answer 4

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

Answer 5

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

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

Mac - это дорого, а Linux - совершенно бесплатно. Нет смысла переходить на Mac и Linux. Не стоит инвестиции.

Answer 6

1. сделать кроссплатформенный компилятор Pascal
2. сделать кроссплатформенный RTL
3. положить QT сверху

Ну, посмотрите на freepascal и lazarus

Answer 7

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

Answer 8

Мое мнение:

1. Сделать кроссплатформенный компилятор (OS x / Linux / встраиваемые решения? / Symbian?). Возможно, добавьте возможность компилировать / преобразовывать паскаль-код в переносимый код на языке c / c ++ для последующей сборки на встроенных платформах.
2. RTL должны быть разделены на кроссплатформенный уровень и собственный уровень (как для JCL).
3. Добавление новых основных компонентов для кроссплатформенной совместимости и собственных компонентов для каждой поддерживаемой платформы (QT для ex)
4. Добавьте утилиты перевода для создания / преобразования между компонентами платформы, например: для преобразования чистой формы Windows в форму Mac OS X Cocoa.
5. Все иерархии окон компонентов должны быть обновлены только для поддержки x64 с максимальной обратной совместимостью. Все кроссплатформенные компоненты должны быть в параллельной иерархии.
6. Следующая версия кроссплатформенного решения может быть реорганизована и может включать утилиту миграции / преобразования. Из-за минимальной кодовой базы кроссплатформенных решений иерархия и классы для кроссплатформенности могут сильно изменяться от версии к версии для достижения лучшей архитектуры.

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

Answer 9

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

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

Answer 10

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

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

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

1. сделать кроссплатформенный компилятор Pascal
2. сделать кроссплатформенный RTL
3. положить QT сверху

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