Доброго времени суток, все!

Сделал я один проект (большой) ещё в 9ых, с BDE ещё. Сам потом на плюсы с жабой перебрался. А этот проЭкт потихоньку поддерживал. Ну и доподдерживался. Хотят (вполне логично) чтоб под win64 фунциклировало. Наверняка менее затратно, в смысле времени, мне будет купить то, во что делфи превратила шарашка со звучным названием эмбаркадеро, разобраться чё там вместо ВDE заюзать. Но по ощущениям, это мне как привязать себе деревянную ногу (может я неправ). Само то по себе новое изучить я всегда за, но была бы у него перспектива. Другой вариант – конвертнуть в c++/java/ещё чего. В C# нехотелось бы, как бы потом кроссплатформенность не приспичила бы. Объёмная, по любому работа. Но нужно выбирать в куда конвертить (и чем, кстати?), в смысле частично как то же автоматизируется сей процесс?
Пишу сюда, т.к. тема флеймовая. Писать на форумы по конкретным языкам смысла нет – там всегда будет хорош тот язык, на какой форум пишишь , эт понятно. А так то я открыт для нового. И гуи приложения не обязаны будут 1:1 походить на старые.

Здравствуйте, AltCtrlDel, Вы писали:

Оставляй на дельфях, они за 2011 год выросли по продажам на 54% Кроссплатформа там уже есть, но лучше ее пока не трогать и подождать Delphi XE3.

ACD>C#
Даже сам создатель delphi перешёл на c#.
Winforms больше чем что-либо похожи на VCL.
ACD>как бы потом кроссплатформенность не приспичила бы
А если в денежном выражении — какой % заказов ожидается для не-windows десктопов? Что-то мне подсказывает, что кроссплатформенность в случае desktop-приложения — это просто такая мантра.

Здравствуйте, Osaka, Вы писали:

O>А если в денежном выражении — какой % заказов ожидается для не-windows десктопов? Что-то мне подсказывает, что кроссплатформенность в случае desktop-приложения — это просто такая мантра.

Там не сколько заказы, сколько предприятие владеет этой прогой и использует у себя же. Надумает экономить или погода повлияет, и пересадят работников на linux. Не обязательно, но такое возможно.
Да и есть некоторая общая тенденция по уходу с винд. Раньше то привыкли пиратскими пользоваться, даже и на предприятиях. А теперь шишь. Ну и линух почеловечнее стал.

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Здравствуйте, Osaka, Вы писали:

O>>А если в денежном выражении — какой % заказов ожидается для не-windows десктопов? Что-то мне подсказывает, что кроссплатформенность в случае desktop-приложения — это просто такая мантра.

ACD>Там не сколько заказы, сколько предприятие владеет этой прогой и использует у себя же. Надумает экономить или погода повлияет, и пересадят работников на linux. Не обязательно, но такое возможно.
ACD>Да и есть некоторая общая тенденция по уходу с винд. Раньше то привыкли пиратскими пользоваться, даже и на предприятиях. А теперь шишь. Ну и линух почеловечнее стал.

Хочешь кроссплатфроменность переписыва на Java.
Во всех остальных случаях переходи на XE2.

Здравствуйте, hattab, Вы писали:

H>Оставляй на дельфях, они за 2011 год выросли по продажам на 54% Кроссплатформа там уже есть, но лучше ее пока не трогать и подождать Delphi XE3.

Если ты в теме, позволь спросить, а как там с совместимостью компонент? Раньше все юзали RxLib, потом она погибла, её сменила jvLib, (не совсем совместимая). Намучался, помнится, когда на d 2007 переносил. А теперь с этим как? Раньше то с каждой новой версией дельфы, как было? Все неродные компоненты переделывай или ищи свежие.

Здравствуйте, AltCtrlDel, Вы писали:

ACD> Если ты в теме, позволь спросить, а как там с совместимостью компонент? Раньше все юзали RxLib, потом она погибла, её сменила jvLib, (не совсем совместимая). Намучался, помнится, когда на d 2007 переносил. А теперь с этим как?

Если планируешь кроссплатформу по любому переписывать придется, под FireMonkey (это кроссплатформенный гуй) компонентов еще нет, да и сыровата она пока. А вообще, в связи с юникодом изменился формат строк, но если с ними раньше работали без выкрутасов то при переносе проблем не будет. Я недавно собирал в XE2 свой давний (Delphi 5-7) компонентик для графиков — собралось без проблем.

ACD> Раньше то с каждой новой версией дельфы, как было? Все неродные компоненты переделывай или ищи свежие.

Если без исходников то именно так, иначе хватало перекомпиляции.

Здравствуйте, AltCtrlDel, Вы писали:

О чем проект?

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Доброго времени суток, все!

ACD>Сделал я один проект (большой) ещё в 9ых, с BDE ещё. Сам потом на плюсы с жабой перебрался. А этот проЭкт потихоньку поддерживал. Ну и доподдерживался. Хотят (вполне логично) чтоб под win64 фунциклировало. Наверняка менее затратно, в смысле времени, мне будет купить то, во что делфи превратила шарашка со звучным названием эмбаркадеро, разобраться чё там вместо ВDE заюзать. Но по ощущениям, это мне как привязать себе деревянную ногу (может я неправ). Само то по себе новое изучить я всегда за, но была бы у него перспектива. Другой вариант – конвертнуть в c++/java/ещё чего. В C# нехотелось бы, как бы потом кроссплатформенность не приспичила бы. Объёмная, по любому работа. Но нужно выбирать в куда конвертить (и чем, кстати?), в смысле частично как то же автоматизируется сей процесс?
ACD>Пишу сюда, т.к. тема флеймовая. Писать на форумы по конкретным языкам смысла нет – там всегда будет хорош тот язык, на какой форум пишишь , эт понятно. А так то я открыт для нового. И гуи приложения не обязаны будут 1:1 походить на старые.

Прежде всего, никакого авто-конвертирования не получится. Имхо, выхода два:

— оставить все на дельфях. Новые версии особо не нужны, что компилировалось 5-7 версией обычно нормально работает в win64. Под линухом тоже часто нормально пашет под вайном, и много контор так юзает софт, как-то выкручиваются. Проблемы будут в BDE (скорее всего, в жизни не проверял, ведь там как минимум вроде много чего ещё 16-разрядного). Чем заменить — нужно думать конкретно, в зависимости что было изначально: парадокс или DBF-таблички или SQL-сервера.

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

Решать вам.

НС>О чем проект?

АСУ ТП

ACD>> Раньше то с каждой новой версией дельфы, как было? Все неродные компоненты переделывай или ищи свежие.
H>Если без исходников то именно так, иначе хватало перекомпиляции.

Без исходников неродные я не использую. Но править, помню, приходилось D1-D2-D3 там RxLib были с условной компиляцией внутри под разные версии и разные файлы проектов к ним.
Потом сразу поставил 2007 и пришлось от RxLib уходить.

Свои компоненты тоже правил. Изменений немного, но когда пакеты большие (типо RxLib), то замучаешся.

PSV>Проблемы будут в BDE (скорее всего, в жизни не проверял, ведь там как минимум вроде много чего ещё 16-разрядного). Чем заменить — нужно думать конкретно, в зависимости что было изначально: парадокс или DBF-таблички или SQL-сервера.

Oracle там.

PSV>- если передел функционала серьёзный, есть прицел на будущее, на другие клиенты и т.д. — лучше переделать с нуля на той же жабе, тем более, есть есть уже свои наработки на ней.
PSV>Решать вам.

Да, уж ...

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Доброго времени суток, все!

ACD>Наверняка менее затратно, в смысле времени, мне будет купить то, во что делфи превратила шарашка со звучным названием эмбаркадеро, разобраться чё там вместо ВDE заюзать. Но по ощущениям, это мне как привязать себе деревянную ногу (может я неправ).
Была подобная проблема. Тогда я и открыл для себя FreePascal+Lazarus. Главная проблема у тебя, IMHO, BDE! Lazarus предоставляет нативные компоненты доступа к большинству СУБД. Вроде как есть компонент TDBF. Я еще в середине 90-х свалил со всяких DBF и парадоксов, так что мне было попроще. Далее: FreePascal+Lazarus имеют как 32-х так и 64-х разрядные версии. Многоплатформенные. Предоставляет широкий набор строк. В смысле кодировок. В Lazarus есть инструмент конвертации дельфевых проектов (не пользовался). Более подробно можно узнать, поспрошать на их сайте.

ACD>Само то по себе новое изучить я всегда за, но была бы у него перспектива. Другой вариант – конвертнуть в c++/java/ещё чего.
c++/java — это не конвертнуть. Это переписать с нуля. Да и многоплатформенность для С++ — сомнительно как-то. А java известный тормоз(не кидайте в меня какашками).

ACD>В C# не хотелось бы, как бы потом кроссплатформенность не приспичила бы.
Если в проекте нет ничего круто навороченного (низкоуровневое, платформозависимое), то думаю MONO потянет проект практически без переделок.

Здравствуйте, FWP, Вы писали:

FWP>Да и многоплатформенность для С++ — сомнительно как-то.

С Qt или WxWidgets не сомнительно.
Для WxWidgets кстати есть wxForms

FWP>c++/java — это не конвертнуть. Это переписать с нуля.

Есть какие то конверторы. Не автоматы, конечно.

ACD>>В C# не хотелось бы, как бы потом кроссплатформенность не приспичила бы.
FWP>Если в проекте нет ничего круто навороченного (низкоуровневое, платформозависимое), то думаю MONO потянет проект практически без переделок.

Там работа с СOM-портами (реально теперь с преобразователями COM-USB), вывод в Excel.
Ну с Excel при кросплатформенности по любому трабл. опен/стар офис даже не пробовал. И, подозреваю, с ним через .net никак.

Здравствуйте, AltCtrlDel, Вы писали:

FWP>>c++/java — это не конвертнуть. Это переписать с нуля.

ACD>Есть какие то конверторы. Не автоматы, конечно.

ACD>>>В C# не хотелось бы, как бы потом кроссплатформенность не приспичила бы.
FWP>>Если в проекте нет ничего круто навороченного (низкоуровневое, платформозависимое), то думаю MONO потянет проект практически без переделок.

ACD>Там работа с СOM-портами (реально теперь с преобразователями COM-USB), вывод в Excel.
ACD>Ну с Excel при кросплатформенности по любому трабл. опен/стар офис даже не пробовал. И, подозреваю, с ним через .net никак.

Java на клиенте. Можно JavaFX + jni кросс-платф для serial. Можно HTML5/GWT + невидимый Java-апплет с jni. Сервер- на чем больше нравится, например Java или Python. Работать будет в 3 осн браузерах, на венде, маке и линухе. Но вот браузеры пока часто 32-разрядные, даже и не знаю, зачем тебе 64 так необходимо.

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

Возьми свою имеющеюся версию, сваргань на скорую руку тестовый проектик да погоняй под win64 и если надо, то и под вайном в линухе запусти. Накидай туда твои используемые компоненты, проверь специфичные вещи вроде того же COM c USB, возможно придётся напрямую работать с API (хотя скорее оно так и есть). Имхо тест сильно не нагнёт и оправдан. С экселем и прочим офисом — пока нет кроссплатформы — лучше не дёргаться, потом разобраться с Open/Libre, найти что-то для работы с ними для дельфей имхо получится.

Чем заменить BDE — конкретно сказать трудно. Я давно не слежу за тем, что творится вокруг дельфи. Вспоминается:

— ZeosLib. Лично я ее юзал для MySQL, правил какие-то баги, уже не помню. Но вроде этой штукой не мало народу пользовалось.

— Можно глянуть сюда, и полазить там по сайту.

— Можно посмотреть на библиотеки для freepascal-я. Сейчас вроде много чего полезного крутится вокруг него, частенько код адаптирован и для Delphi (но не для всех версий).

Раньше много чего было под оракл, имхо, подобрать что-то получится. Есть смысл сохранить интерфейс либы для проекта а-ля BDE (и такого было не мало). Может будет и какой-то конвертор. В крайнем случае невелика проблема заменить в исходниках имена классов на первом этапе. Если DFM-ресурсы в бинарном виде — можно и свою утилитку забабахать.

Если взяться за лазарус/фрипаскаль, имхо переделок будет больше из-за уже задействованных в проекте компонентов и пр. Кстати, во фрипаскале для 64 были какие-то проблемы при использовании исключений, как сейчас — надо проверять, возможно давно пофиксили.

Имхо, так будет проще.

Здравствуйте, ArtemGorikov, Вы писали:

AG>Java на клиенте. Можно JavaFX + jni кросс-платф для serial. Можно HTML5/GWT + невидимый Java-апплет с jni. Сервер- на чем больше нравится, например Java или Python. Работать будет в 3 осн браузерах, на венде, маке и линухе. Но вот браузеры пока часто 32-разрядные, даже и не знаю, зачем тебе 64 так необходимо.

Да, можно морду на хтмыле делать, благо щас для жабы фреймвёков под это как грязи. Но это далеко от вопроса, это значит сделать всё заново. 64 разряда в браузере мне не надо. Мне и в оси 64 не надо, заказчику надо потому что компы нынче с такими виндами продают.

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Доброго времени суток, все!

Хотят (вполне логично) чтоб под win64 фунциклировало.

Не совсем понятно с логичностью. Большинство 32-х битного софта вполне себе функционирует под 64-битной виндой. И самое интересное, что этого 64-х битного софта — мало. Он, конечно, есть, но переход на 64 бита для десктопной софтины должен иметь смысл, кроме "просто, чтобы было64 бита". Скорости работы это существенно не добавит. Добавит возможность работать с большим обемом памяти. А Вашей программе не хватает гигабайтного адресного пространства? Если да — то затранты на перевод имеют смысл. Если хватает — то переносить не нужно, т.к. проблем и "подводных граблей" на таком переходе найдете немало (не считая простых трудозатрат).


По поводу Linux — думать о переносимости "просто так", без конкретной задачи от заказчика, конечно можно. Но, вдруг, они вместо линукса захотят всех на iPad перевсети?

Здравствуйте, AltCtrlDel, Вы писали:

НС>>О чем проект?

ACD>АСУ ТП

Ох. Тогда даже и не знаю. Наверное лучше всего джава будет.

Здравствуйте, FWP, Вы писали:

ACD>>В C# не хотелось бы, как бы потом кроссплатформенность не приспичила бы.
FWP>Если в проекте нет ничего круто навороченного (низкоуровневое, платформозависимое), то думаю MONO потянет проект практически без переделок.

Только С UI вопросы. Придется сразу на GTK# ориентироваться.

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Да, можно морду на хтмыле делать, благо щас для жабы фреймвёков под это как грязи.

Не советую. Натрахаешься по самое нехочу.

Здравствуйте, aloch, Вы писали:

a> По поводу Linux — думать о переносимости "просто так", без конкретной задачи от заказчика, конечно можно. Но, вдруг, они вместо линукса захотят всех на iPad перевсети?

Дельфя, как раз таки, умеет iOS Mac OS, кстати, тоже. Вот линукс пока не умеет, но обещают.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, AltCtrlDel, Вы писали:

ACD>>Да, можно морду на хтмыле делать, благо щас для жабы фреймвёков под это как грязи.

НС>Не советую. Натрахаешься по самое нехочу.
Нет. GWT избавит от 99.99% html-го/javascript гемора. Насчет грязи- не в курсе. Мне известно GWT, JavaFX- Java, Silverlight- C#, Flex- ActionScript, при этом у только у Java есть кросс-платформа и есть JNI.

Здравствуйте, ArtemGorikov, Вы писали:

НС>>Не советую. Натрахаешься по самое нехочу.
AG>Нет.

Да.

AG> GWT избавит от 99.99% html-го/javascript гемора.

Но не избавит от их глюков и тормозов. Для АСУТП, где типичным является отображение больших схем с кучей мигалок и глюкалок, это может и вовсе стать showstopper'ом.

AG> Насчет грязи- не в курсе. Мне известно GWT, JavaFX- Java, Silverlight- C#, Flex- ActionScript, при этом у только у Java есть кросс-платформа и есть JNI.

А у шарпа есть Моно и P/Invoke.

Здравствуйте, hattab, Вы писали:

H>Кроссплатформа там уже есть, но лучше ее пока не трогать и подождать Delphi XE3.

С XE2 проблемы? Или в XE3 что-то очень хорошее ожидается?

AG>Нет. GWT избавит от 99.99% html-го/javascript гемора. Насчет грязи- не в курсе. Мне известно GWT, JavaFX- Java

SmartClient/SmartGWT, Apache Click, ZK Web Library — это жава. А ещё есть толстые клиенты на jscript+генераторы кода, типа qooxdoo. Там всё представление крутится в браузере, ему только данные подливать через json[P[P]]. для конкретно этого проекта я такое использовать не буду, а вообще хочу попробовать. При этом на сервере остаётся база, бизнес-логика, это можно даже и на сях.

A> Хотят (вполне логично) чтоб под win64 фунциклировало.
A>Не совсем понятно с логичностью. Большинство 32-х битного софта вполне себе функционирует под 64-битной виндой.

Там BDE и Oracle 8. Всё это не идёт под 64. Новый оракл покупать не хотят — дорого очень. Так что переделки в любом случае немалые.

Здравствуйте, AltCtrlDel, Вы писали:

AG>>Нет. GWT избавит от 99.99% html-го/javascript гемора. Насчет грязи- не в курсе. Мне известно GWT, JavaFX- Java

ACD> SmartClient/SmartGWT, Apache Click, ZK Web Library — это жава. А ещё есть толстые клиенты на jscript+генераторы кода, типа qooxdoo. Там всё представление крутится в браузере, ему только данные подливать через json[P[P]]. для конкретно этого проекта я такое использовать не буду, а вообще хочу попробовать. При этом на сервере остаётся база, бизнес-логика, это можно даже и на сях.
Это какая-то экзотика. "ему только данные подливать через json" — очень, очень оптимистичный взгляд
Использовать на сервере C++ imho непрактично- ловить утечки и падения, изобретать свой велосипед с масштабированием. Если, конечно, в железе ограничения нет. Лучше Java или Python. Причем у Python есть Tornado- классная штука. Или поиграться с FreePascal, если получится отрезать бизнес-логику без глобальных изменений кода.

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Доброго времени суток, все!

ACD>Сделал я один проект (большой) ещё в 9ых, с BDE ещё. Сам потом на плюсы с жабой перебрался. А этот проЭкт потихоньку поддерживал. Ну и доподдерживался. Хотят (вполне логично) чтоб под win64 фунциклировало. Наверняка менее затратно, в смысле времени, мне будет купить то, во что делфи превратила шарашка со звучным названием эмбаркадеро, разобраться чё там вместо ВDE заюзать. Но по ощущениям, это мне как привязать себе деревянную ногу (может я неправ). Само то по себе новое изучить я всегда за, но была бы у него перспектива. Другой вариант – конвертнуть в c++/java/ещё чего. В C# нехотелось бы, как бы потом кроссплатформенность не приспичила бы. Объёмная, по любому работа. Но нужно выбирать в куда конвертить (и чем, кстати?), в смысле частично как то же автоматизируется сей процесс?
ACD>Пишу сюда, т.к. тема флеймовая. Писать на форумы по конкретным языкам смысла нет – там всегда будет хорош тот язык, на какой форум пишишь , эт понятно. А так то я открыт для нового. И гуи приложения не обязаны будут 1:1 походить на старые.

BDE -> ADO

AG>Использовать на сервере C++ imho непрактично- ловить утечки и падения, изобретать свой велосипед с масштабированием.

Многие так думают. Но под десктоп то на сях пишут, и ничего. Просто раньше редко у кого был свой веб-сервер, арендовали у хостеров. И те, естественно, нативный код к себе не пускали. А сейчас школота дома сервера держит, обычное дело. Вот с тех времён и остались фреймвёки для создания веб-интерфейса почти только на скриптах и на жаве. Поэтому делать представление веб-приложения на сях — это изобретать велосипеды, да. Всё остальное можно, в умелых руках никакой падучести. апачи то с нжинксами на чём написаны? Аха.

AG> Если, конечно, в железе ограничения нет. Лучше Java или Python.

Нет. Только не Python. У меня к нему аллергия.

Здравствуйте, Alex912, Вы писали:

A> H>Кроссплатформа там уже есть, но лучше ее пока не трогать и подождать Delphi XE3.

A> С XE2 проблемы? Или в XE3 что-то очень хорошее ожидается?

С XE2 проблемы. FireMonkey сырая — жуть. Андроид обещали в скором времени, возможно к XE3 успеют

ACD>Сделал я один проект (большой) ещё в 9ых, с BDE ещё. Сам потом на плюсы с жабой перебрался. А этот проЭкт потихоньку поддерживал. Ну и доподдерживался. Хотят (вполне логично) чтоб под win64 фунциклировало. Наверняка менее затратно, в смысле времени, мне будет купить то, во что делфи превратила шарашка со звучным названием эмбаркадеро, разобраться чё там вместо ВDE заюзать. Но по ощущениям, это мне как привязать себе деревянную ногу (может я неправ). Само то по себе новое изучить я всегда за, но была бы у него перспектива. Другой вариант – конвертнуть в c++/java/ещё чего. В C# нехотелось бы, как бы потом кроссплатформенность не приспичила бы. Объёмная, по любому работа. Но нужно выбирать в куда конвертить (и чем, кстати?), в смысле частично как то же автоматизируется сей процесс?
ACD>Пишу сюда, т.к. тема флеймовая. Писать на форумы по конкретным языкам смысла нет – там всегда будет хорош тот язык, на какой форум пишишь , эт понятно. А так то я открыт для нового. И гуи приложения не обязаны будут 1:1 походить на старые.

А чем Free Pascal с Lazarus наперевес не нравится?

Здравствуйте, AltCtrlDel, Вы писали:

AG>>Использовать на сервере C++ imho непрактично- ловить утечки и падения, изобретать свой велосипед с масштабированием.

ACD>Многие так думают. Но под десктоп то на сях пишут, и ничего. Просто раньше редко у кого был свой веб-сервер, арендовали у хостеров. И те, естественно, нативный код к себе не пускали. А сейчас школота дома сервера держит, обычное дело. Вот с тех времён и остались фреймвёки для

Под виндо- десктоп, еще и на C++ — это или из разряда экзотики в наше время. Новое часто или веб, или Java Web Start (JNLP), с требованием только винды.

EOH>А чем Free Pascal с Lazarus наперевес не нравится?

Я, в последнии годы, от Delphi то был далёк, не точно от его бесплатных заменителей. Просто не в курсАх, насколько оно совместимо, неглючно и т.п.

AltCtrlDel was thinking very hard :

> Свои компоненты тоже правил. Изменений немного, но когда пакеты
> большие (типо RxLib), то замучаешся.

как ни странно, но RxLib живой — http://sourceforge.net/projects/rxlib/

Здравствуйте, AltCtrlDel, Вы писали:

ACD>Я, в последнии годы, от Delphi то был далёк, не точно от его бесплатных заменителей. Просто не в курсАх, насколько оно совместимо, неглючно и т.п.

Где-то начиная с версии 0.9.28 и 0.9.30 оно стало достаточно неглючным и в разработке и в работе, по крайней мере, пробовать что-то сделать на Lazarus вполне можно.

Насчет же совместимости, там совместимость с Delphi далеко не 100%, могут потребоваться заметные переделки. Сам язык FreePascal достаточно хорошо совместим с языком Delphi, есть некоторые специальные опции компилятора для некоторых вещей в плане освместимости. Тут проблем быть не должно.

Но вот визуальная и системная библиотека LCL совместимы где-то так условно на 70%, очень многие вещи делаются иначе. Например, функции печати, есть некоторые отличия в мультипоточной работе. Для вызова программ можно использовать CreateProcess, но лучше класс TProcess и т.д. Или например, все строки с визуальных компонент, типа TEdit идут в utf8, но в системные RTL передавать надо системной кодировке, поэтому даже для вызова FileExist надо писать что-то вроде FileExists(UTF8ToSyS(FileName)) — если в именах файлов используются национальные символы.

То есть, повозиться с портированием придется основательно.

M>в системные RTL передавать надо системной кодировке, поэтому даже для вызова FileExist надо писать что-то вроде FileExists(UTF8ToSyS(FileName))

недайтохобох! И никакой поддержки COM/ActiveX наверняка. Нет уж. Кросплатформенность, сейчас не первая необходимость. Пока воздержусь от этого фрипаскаля.

Здравствуйте, AltCtrlDel, Вы писали:

M>>в системные RTL передавать надо системной кодировке, поэтому даже для вызова FileExist надо писать что-то вроде FileExists(UTF8ToSyS(FileName))

ACD>недайтохобох!

Ну не так страшно как кажется, просто надо внимательнее быть с кодировками. Одни проблемы убраны, другие появились.

ACD> И никакой поддержки COM/ActiveX наверняка.

Да вполне поддерживается COM/ActiveX. Естественно, если их использовать явно, никакой кроссплатформенности, кроме как в винде 32/64 (и то есть нюансы) не будет.

Я бы попробовал какой-то небольшой, но характерный кусочек проекта реализовать таки на Lazarus/Freepascal и посмотреть что получается. Все-таки, в Delphi XE2 эта FireMonkey совсем не то, что VCL, а в Lazarus, хотя и далеко не 100% совместимость, но очень большая.

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

I>как ни странно, но RxLib живой — http://sourceforge.net/projects/rxlib/

Последняя версия под 6-ой делф — это называется живой?

M>Да вполне поддерживается COM/ActiveX.

В языке поддерживается? Не просто библиотекой? Т.е. через disp-интерфейс можно вызывать неизвестные на этапе компиляции проперти/методы и подобное?

Здравствуйте, AltCtrlDel, Вы писали:

ACD> I>как ни странно, но RxLib живой — http://sourceforge.net/projects/rxlib/

ACD> Последняя версия под 6-ой делф — это называется живой?

Там даже в названии архива указано D6-2010. А вообще, гуглится на раз. Поддерживаемые версии 2005-XE2.

Здравствуйте, AltCtrlDel, Вы писали:

ACD> M>Да вполне поддерживается COM/ActiveX.

ACD> В языке поддерживается? Не просто библиотекой? Т.е. через disp-интерфейс можно вызывать неизвестные на этапе компиляции проперти/методы и подобное?

Да. Диспетчеризация поддерживается на уровне компилятора.