Переработка проекта для обеспечения переносимости между WIndows и Linux

1 (или winelib), ИМХО. У тебя есть тексты => ты можешь поправить все несовместимости.

У меня есть подобная проблема но программа с графикой написана на Net.
Я пока ничего не решил, смотрю GTK+ и коды Inkscape.
Imho, от паскаля лучше отказаться.

Java вариант рассмотри.

Для меня java отпадает, не люблю ее, да и падение производительности
которое уже было при переходе на Net не ликвидируется.

Пока склоняюсь к выбору какого-то нативного варианта.

>Java вариант рассмотри.

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

имхо нужно попробовать вынести логику/движок в библиотеку (одновременно избавившись от платформенозависимого кода в нём) и посмотреть насколько это будет трудно. если эта операция не слишком трудоёмка - то попробовать скомпилировать в fpc движок а интерфейс прикрутить например через питон %)

в твоём случае, однозначно fpc+Lazarus;
ибо
1) надо получить переносимость проекта между платформами
2) с минимумом затрат
3) существенны требования к платформе (работа под полным эмулятором не катит)
4) лучше сохранять совместимость с оригинальной платформой до самой критичной точки (к моменту когда на Delphi уже не пашет, на fpc должна быть stable beta)

Если кроме этой задачи на рабочих станциях ничего нет,
то может пройдет такой примерно вариант реализации :

- DOS+extender, с VESA режимом.
- Linux+Framebuffer.

В винде можно попробовать старые борландовские
компиляторы, которые есть фри.
Насчет Linux я здесь недавно видел myOS проект,
на фреймбуфере и графические либы от Mesa.
там, кстати, на паскале есть какое-то программирование.

API для рисования свое написать

>имхо нужно попробовать вынести логику/движок в библиотеку

Уже :) Вобщем сделано примерно так: есть головной модуль - графическая оболочка, которая обеспечивает рисование схем, анимацию, управление. К ней в виде dll цепляются расчётные модули - разные в зависимости от типа моделируемой системы. В этих самых dll платформозависимого кода как такового немного. А вот в головном модуле - дофига и более, а он то как-раз самый сложный. Так что операция достаточно трудоёмка. Кроме того как быть с общим менеджером памяти, который испоотзуется для dll ?

>API для рисования свое написать

В программе есть собственная векторная графическая подсистема. Для отрисовки непосредственно используется GDI и местами GDI+. Вообще есть мысль не переносить комплекс целиком - оставить как есть, вычленить из него отдельно графическую подсистему, переработать её и сделать отдельную программу-плеер для работы на рабочих станциях. Можно сделать её вообще отдельно - картинки могут сохраняться в XML.

> картинки могут сохраняться в XML.

лучше в SVG, вьюверы можно разные использовать - тот же Inkscape
например

вариант 5) разделить логику и gui - логика на С++ и GUI на Java/python

> Для отрисовки непосредственно используется GDI и местами GDI+.

Может начать с малого, GDI -> OpenGL, т.е. отвязывать постепенно и параллельно дробить код на либы (векторный движек вынести в dll, может и в несколько).

Как правильно уже сказали -- максимально разделить логику и интерфейс пользователя.

> Кроме того как быть с общим менеджером памяти, который испоотзуется для dll?

Вычленить абстрактный интерфейс (в духе "дай мне функцию A из модуля B::C"), и сделать две раелизации.

Тем более, что идеологически libdl от виндового API работы с DLL-ями мало отличается.

Pascal, конечно, зло, но тут, ИМХО, без вариантов. Я бы выбрал вариант нумер 2 -- дёшево и сердито.

fpc + winelib