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

Сделал я один проект (большой) ещё в 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 перевсети?