Comments 165
Вижу много боли по делу. Вопрос: вы рассматривали вариант delphi+wine? При кажущейся чужеродности, это вполне могла быть опция. Хотя у вашего подхода явным плюсом является нативный интерфейс получившегося.
Тестировали. Медленнее и не держало direct2d версию. Старая с gdi рендером работала
Нет. Надо было проверять на конкретном дистрибутиве линукс. Но можно попробовать.
2. а так же есть возможность и запустить. Нужно лишь установить один из X-серверов под Windows и прописать его в переменные окружения
в файл .bashrc достаточно добавить
export DISPLAY=localhost:0
Линуксовая версия живёт в виртуалка, большие проекты тяжело сравнить. Небольшие примерно процентов на 20 медленнее но не все. В виндовой версии используется обсчет графики в отдельных потоках, поэтому если ядер много то лучше работает. Gtk так не умеет. Под винду используем delphi 10.3.3 так удобнее сейчас. Лазарус тоже пробовал. Заказчиков на линукс версию не особо много, но точто им надо (видеокадры системы регулирования для аэс) сейчас завелось.
А вы пробовали последние версии Delphi которые в Architect редакции умеют в линукс из коробки, а в комплекте с CrossVcl могут собирать простые программы вообще без изменений?
Долго они её модерировали только. Сейчас сидим на 10.3.3. Возможно обновимся. Программа не очень простая. Fmx не охота было пользовать, написано было много. А так вроде заработало все с не особо большими корректировками.
К сожалению, не под любой Linux так можно компилить.
Там поддерживается совсем небольшой набор различных дистрибутивов: Supported Target Platforms
Легко. Делаете модуль с формой и в винде он работает. Чтобы окна были в той же группе что и главное application.handle := тоже самое в головном модуле
необходимо в so-библиотеке… определить инициализацию Application в секции initialization и завершение в finalization
{$IFDEF FPC}
initialization
Application.Initialize;
finalization
Application.Terminate;
end.
{$ENDIF}
Удивил момент что надо инициировать Application в каждой библиотеке. В Delphi/VCL, насколько я помню, Application глобальный singleton объект и повторная инициализация смысла не имеет.
nicky7
Вы нашли способ использования форм из dll (не bpl)?
bpl это расширенная версия dll с точки зрения интерфейса — к стандартным функциям добавлены дополнительные под нужды среды/vcl
PS: Очень впечатлён! Мне казалось что портирование сколько-то сложного проекта задача просто непосильная.
Портировать задача посильная, но вообще всё сильно зависит от используемых библиотек.
procedure TApplication.Initialize;
begin
if InitProc <> nil then TProcedure(InitProc);
end;В простом проекте это пустышка — InitProc nil.
Только всякие платформозависимые модули добавляют обработчик — ComObj, ComServ, OleAuto и почему-то DBTables. Хотя и в нём всё сводится к тому-же CoInitialize. Оно и понятно — кто раньше застолбил потоковую модель использования COM, того и тапки.
С последним обстоятельством был связан очень неприятный баг — у нас клиент-серверное приложение работающее по DCOM с потоковой моделью FreeThread. На некоторых компах клиент (точнее винда) при попытке коннекта выдавал ошибку о несовпадении потоковой модели COM клиента и сервера. Оказалось драйверы принтера некоторой корпорации (не буду показывать пальцем, та у которой статьи почему чернила дороже чем кровь) при загрузке переинициализировали потоковую модель в SingleThread. Да MS явно в доке пишет что такое недопустимо, но что делать если хочется… Пришлось алаверды в dpr дописывать код принудительной переинициализации COM
bpl это расширенная версия dll с точки зрения интерфейса — к стандартным функциям добавлены дополнительные под нужды среды/vcl
Самые интересные расширения в ней — это то, что глобальные переменные типа Application начинают искаться в одном для всех связанных bpl модуле. Кроме Application ещё System.Classes.ApplicationHandleException и System.Classes.ApplicationShowException. Также в некотором смысле переменными являются ссылки на классы. То есть, если ловить исключение между dll, которые не bpl, как
on Occurrence: Exception doТо оно не поймается, ведь оно не тот Exception. И даже не тот TObject.
Сейчас на нашем гос предприятии сильно принуждают на русские линуксы переходить. Проблем не меренно. Так что общая тенденция ипортозамещения ПО будет только усиливаться.
Собственно вопрос (возможно детский):
А как через границу с dll ссылки на объекты вообще передаются? Может статью напишите по правильному и современному подключению плагинов с формами, объектами, колбеками…
Если компилятор одинаковый и для головного модуля и плагинов то при одинаковой настройке выравнивания структур выделяемые им в памяти области тоже одинаковые. Поэтому я делаю базовый абстрактный класс в модуле общем для exe и dll, а потом в dll его наследую. У dll наружу торчит функция createobject(name: pchar) которая внутри создаёт класс и возвращает наружу его указатель. А дальше в exe я обращаюсь к функциям абстрактного класса, по этому указателю. Это один из использованных способов. Это надо отдельно будет написать.
В линуксе что надо сделать описано.
«Идущие следом» были бы очень благода.
Ну статью могу послать. Если подскажете куда именно. Изменений то в компонентах только в tee chart pro за который фирма 500 баксов заплатила. А разработчикам лазарус эти особенности недурно было бы в справку внести.
После прочтения я пожимаю автору руку и говорю «Браво!».
Но вот только «Delphi закапывать рановато» слишком пафосно. К сожалению уже поздно пить боржоми… Закапывать то, что уже закопано — действительно не надо. А закопан Delphi потому, что сейчас его уже никто в здравом умен не выберет для нового проекта. И то, что он уже закопан лично у меня вызывает грусть и сожаления.
Вопрос мегаспорный. Это скорее выбор инструмента под задачу и под человека. По сути если писать подобный нашему софт с требованиями скорости работы, кроссплатформенности и нативной интеграции с некоторыми внешними библиотека и на фортрана то выбор невелик — c++ и qt и как не странно Free Pascal с реализацией некоторых критических мест на си. На одной из прошлых моих работ мою систему 3 года переписывали на java и на редкость криво это сделали, хотя я им qt тогда советовал, на что мне ответили что сложно типа на qt. С другой стороны я знаю программы на qt которые разработчики не могут на линукс перетащить почему-то таким же образом. По поводу выбора инструментов под задачи разработки сапр вообще можно подискутировать.
Вообще очень впечатлен вашим кругозором, который и позволил выбрать столь эффективный способ решения проблемы. Своим вопросом пытаюсь вашим кругозором воспользоваться. Если бы начинали свой проект сегодня, то выбрали бы C++ и QT?
Три месяца для такого проекта это просто ничто. Когда спрашивали Петухова (если не ошибаюсь, в комментах к вводной статье про SimInTech) когда будет линукс-версия, то он ничего толком не отвечал, работаем мол. Готовился уже годами ждать и надеяться что поспеете хоть к 16-му Эльбрусу. А оно вон как обернулось! Осталась только одна печаль — стоимость. Для АЭС конечно нормально, а для мелочи всякой и домашнего использования мда… SciLab+Xcos, а то и Jigrein наш удел :)
Для домашнего использования мы бесплатно ключ выписывает. Для мелких задач тоже — делаете заявку и мне в почту кидаете или на официальную. Если бы с нуля делал именно сейчас для gui наверное был бы qt. Но не факт, потому что них коммерческая политика лицензирования не особо дешёвая, да и говорят переход с версии на версию небезударный. Я знаю точно что я бы НЕ использовал — java. На прошлой работе часть моей системы на неё переписали и вышло сильно хуже исходной версии на delphi, да ещё и jni вызовы не быстрые…
Во-вторых, что касается выбора инструментальной среды. Мы сейчас тоже реализуем крупный проект, перед началом которого проводили выбор среды разработки. Поскольку изначально одним из условий ставилось обеспечение кроссплатформенности, то многие из популярных сред отпали «на старте». Java в корне не понравился своей производительностью и прожорливостью к ресурсам. У C# проблемы с кроссплатформенностью, что бы там не говорили его адепты. В итоге осталось два реальных варианта. Qt и C++ или Lazarus + FreePascal.
Так вот, в итоге мы выбрали именно Lazarus + FreePascal, поскольку оказалось, что вести большой проект небольшой командой разработчиков (у нас тоже 3 человека) на Lazarus + FreePascal намного проще и быстрее, чем на связке Qt и C++. Причём мы даже сделали два средних проекта на Qt и C++, которые только убедили нас в этом. Сборка проекта происходит намного дольше, управление файлами существенно сложнее, «плясок с бубном» при сборке под разные платформы заметно больше.
В конечном итоге основной проект был запущен на Lazarus + FreePascal и имеющиеся на сегодня результаты показывают, что это был правильный выбор. Правда, мы не используем параллельно сборку на Delphi и Lazarus, что заметно упрощает нам жизнь. Часть когда когда-то была написана именно на Delphi, потом был небольшой период совместного использования кода, но сейчас уже практически всё отвязали от поддержки Delphi. В основном потому, что нам оно не требуется, а без проверки сборки в Delphi смысла прописывать условную компиляцию особого нет, только лишняя трата времени.
У языка Ada, несомненно, есть определённые достоинства, но они не перевешивают имеющихся в нём минусов.
Но, когда появилась и начала активно развиваться концепция объектно-ориентированного программирования, которую органично вписали во многие существовавшие на тот момент языка, например в C или Pascal, либо создав новые, изначально объектно ориентированные языки, такие как Java, разработчики Ada пошли своим путём. Да, в языке Ada изначально было понятие пакетов, которое позволяло реализовывать часть механизмов из концепции ООП. Но делалось это более громоздкими способами с точки зрения синтаксиса и удобства написания и восприятия программ. Например, та же точечная нотация при работе с объектами, насколько я знаю, появилась только в стандарте Ada 2005. А до этого момента использовалась так называемая «процедурная нотация».
Или то же нововведение в синтаксис, которое должно помогать компилятору ловить ошибки с перекрываемыми функциями и процедурами, когда для перекрываемых функция необходимо в начале указывать ключевое слово overriding, а для всех новых процедур и функций not overriding. В итоге получился механизм, который либо бесполезен, поскольку данные ключевые слова не являются обязательными, либо создаёт дополнительные заморочки разработчику, если он решает активировать в компиляторе эту возможность и вынужден будет многократно писать not overriding, поскольку новые функции в большой объектной иерархии добавляются постоянно и их часто больше, чем перекрываемых.
Кроме того, удобство использования того или иного языка определяются не только самим языком, но и наличием удобных и эффективных интегрированных сред разработки, которые включают в себя как инструментальные средства, так и развитые программные библиотеки. А и с тем, и с другим, у Ады, увы, всегда были проблемы, которые изначально во многом были обусловлены той сферой применения, под которую она разрабатывалась.
Кстати, появление проекта Qt Ada, о котором вы упомянули в самом начале, это как раз попытка решить данную проблему путём скрещивания библиотеки и среды разработки Qt с компилятором Ada. Но одним только GUI разработка больших прикладных систем не ограничивается. Нужна ещё масса других библиотек для работы с СУБД, графикой, документами в стандартных форматах, тот же PDF, например.
Кстати, тот же Object Pascal, к сожалению, постепенно умирает как раз по причине того, что под него всё сложнее найти качественные библиотеки, соответствующие новым стандартам или поддерживающие последние редакции форматов тех или иных файлов данных. Особенно когда речь заходить о Free Pascal, а не о платной среде Delphi от Embacadero. Под последнюю ещё можно что-то найти из платных решений, но многие из этих решений не работают с Free Pascal или реализуют там не полный функционал, либо реализуют его менее качественно (много ошибок из-за менее тщательной отладки). Что в общем-то понятно и объяснимо. Если люди на этом зарабатывают, то основные усилия будут вкладываться туда, где больше платят. А сообщество Free Pascal деньги платить не любит.
В итоге получился механизм, который либо бесполезен, поскольку данные ключевые слова не являются обязательными, либо создаёт дополнительные заморочки разработчику, если он решает активировать в компиляторе эту возможность и вынужден будет многократно писать not overriding, поскольку новые функции в большой объектной иерархии добавляются постоянно и их часто больше, чем перекрываемых.
Этот механизм активируется вместе с указанием версии стандарта, то есть, условно всегда. И нет, разработчик не становится обязан. Может быть, pragma Restriction есть, которая бы обязала, или ключ принуждения к стилю, но я такого не видел.
та же точечная нотация при работе с объектами, насколько я знаю, появилась только в стандарте Ada 2005
И это было 15 лет назад.
Для некоторых проектов мне нужна супер переносимость, и я получаю её, используя AdaMagic, сертифицированный транслятор в Си. У него стандарт 95. Какой-то большой трагедии не усмотрел. Чисто инерция после Delphi.
Нужна ещё масса других библиотек для работы с СУБД, графикой, документами в стандартных форматах, тот же PDF, например.
То есть, не хватает некоего COM, который позволял хорошо жить на Windows самым разным языкам программирования. Или обновления p2ada, чтоб апгрейдить больше паскалевских библиотек до адских. Ясно.
Я в своей практике, бывало, садился и полные привязки делал. Но, бывало, муторно, и привязывал только те внешние функции, которыми собрался пользоваться. Например, чтоб из AWS порулить ipset в ядре, привязал самый минимум. И сверх этого так больше ничего и не понадобилось.
Рассматривали, но есть ограничения: 1. Программа инженерная и заточена на работу на локальной рабочей станции. 2. Переделывать придётся ВСЁ. 3. Совместимость со всеми старыми наработками критична.
Жаль, что путь миграции с Delphi на Ada не проторен. Приходится увиливать на гораздо менее продвинутый Free Pascal.
Ничего этого не предлагают ни Visual C++ ни С# ни Qt C++ ни тем более AdaQt.
Ничего этого не предлагают
Qt в сочетании с Адой или C++ — это как минимум нативный код и высокая скорость функционирования приложения.
ненативных контролов Qt
Столбовая дорога современного Delphi, FireMonkey, в конечном итоге тоже такого типа получилась.
Свои компоненты невозможно интегрировать в панель редактора форм
Да, в этом плане Delphi IDE блистает.
Столбовая дорога современного Delphi, FireMonkey, в конечном итоге тоже такого типа получилась.
Поэтому и не использую активно FireMonkey несмотря на ее некоторые плюшки.
А вот насчет плюшек — самая главная плюшка это кроссплатформенность, за это можно смириться с некоторой ограниченностью относительно VCL. Хотя на мой взгляд, текущая версия fmx в 10.4.1 достигла коммерческой зрелости.
Есть еще Dear ImGui. На нем удобно делать приложения вроде вашего.
сейчас его уже никто в здравом уме не выберет для нового проекта
Запятые неправильно поставлены.
сейчас его уже не выбирают для нового проекта
сейчас уже никто не в здравом уме
С вами не согласятся многие, в их числе и я. Прошло много времени с момента пика популярности Delphi, утекло много воды, однако до сих пор он является одним из самых удобных инструментов для создания быстрых нативных десктопных приложений. Не говоря уже о том, что он развивается сейчас достаточно сильно. Можете зайти на офф. сайт Эмбаркадеро и посмотреть новости и блог.
десктопных приложений
И где сейчас рынок этих приложений?
Мой вариант ответа: примерно там же где и Delphi....
CAD, CAE, спец софт всякий, PDM ы, офисные пакеты и т.п.
Вы забываете, что мир не только вебом полон. И всё через него, а тем более удобно и производительно не сделаешь.
Я, мы и многие другие занимаются написанием десктопного софта:
CRM, работа с графикой, и прочее.
Не говоря уже о том, что Delphi позволяет создавать и сайты (TMS, uniGUI) и речь тут именно про сайты целиком, а не только бэкенд, создавать мобильные приложения (FMX, FGX) и создавать софт под линукс или полностью кроссплатформенный софт. А в ближайшее время ожидается сборка под WebASM, что ещё сильнее продвинет Делфи в веб-разработке.
У Delphi есть проблема с большими проектами, IDE постоянно вылетает, жутко тормозит и постоянно проблемы с переходами к определению функции. У Lazarus такие же проблемы?
У меня delphi 10.3.3 не вылетает вроде. Code typhon может но редко крайне и это чаще происходило из за заваливания вообще всей операционки сначала.
У нас просто проект немного больше, полная сборка комплекса занимает несколько минут. Если правильно помню, то когда последний раз смотрел было 15М+ строк
А небольшое проект 15 Mb может билдиться несколько минут, если плохо структурирован.
У нас был период, время компиляции проекта порядка 400 тыс строк резко выросло с 1 минуты до 3. После того, как из него вычистили несколько десятков циклических зависимостей, время упало до 30 сек.
У нас текстовый редактор а-ля Ворд — 1.5 миллиона строк, система электронного документооборота — 1.5 миллиона строк. Так что 15 М строк вовсе не особо колоссальное, я думаю любая банковская система или ERP — что-то в этом районе и будет (плюс минус 5 миллионов :) )
Также из практики могу предположить, что имеет место быть слабое объектно-ориентированное программирование или не грамотно построенная иерархия классов, из-за чего приходится писать много похожего или вообще дублирующегося кода.
Мне приходилось работать с подобным «большим проектом», в котором было сразу четыре фреймворка для работы с классами, которые были написаны в разное время и с разным пониманием того, что там должно быть. При этом на 90% код этих фреймворков, а также иерархий классов, которые от них строились, повторялись, но каждый для своей ветки.
Кстати, если попробовать собрать проект их 15 млн. строк на чём нибудь типа Qt в паре практически с любым компилятором C++, то такая сборка будет занимать не несколько минут, а несколько часов.
Не пробовали создавать свои компоненты-обёртки?
Два пакета — под Delphi и CodeTyphon Studio — и меньше директив условной компиляции.
А их мало которые различаются. Честно говоря тупо лень было и так быстрее получилось. Проблемы основные были с выбором библиотеки 2д графики под линукс и забавными приколами с памятью и многопоточностью.
Просто мы тоже достаточно долго выбирали библиотеку для графической части, но пока так ни на чём и не остановились. Либо не устраивает функционал, либо скорость работы, либо и то, и другое одновременно. :(
В конечном итоге 3D сделали через OpenGL, частично использовав GLScene, частично написав свой код, поскольку другого кроссплатформенного варианта для этих целей просто нет. А вот с реализацией 2D возникли некоторые проблемы, особенно в части использования прозрачности. Поэтому пока вывод 2D через OpenGL отложили и сделали первый вариант просто через Canvas, но отказавшись от использования прозрачности.
Проблема была в том, что на платах AMD и NVidia реализация OpenGL при работе с 2D графикой отличаются. В итоге при построении сложных изображений приходится уходить на уровень самых базовых примитивов: отрезок и треугольник. Но когда начинаешь строить ломанную линию из отдельных сегментов, используя при этом прозрачность, то при толщине в несколько пикселов концы отрезков перекрываются и в этом месте прозрачность отображается не так, как требуется.
Под Windows используется direct2d. Под Linux — надстройка над cairo (gdk). Просто они функционально похожи оказались сильно и оказалось просто сделать прокладку. Речь о 2д графике — отрисовке схем и видеокадров.
Вопрос с прозрачностью у меня тоже возник, поэтому и делал на линуксе через orca2d а не через обычный canvas.
Зарплата устраивает. Переписывать на другом стеке это минимум 5 лет работы и долботни будет больше намного, да и текущие средства разработки под наши задачи устраивают. Необходимо обеспечивать совместимость проектов между версиями по и непрерывную поддержку. Программа достаточно сложная и писалась не один год, а главное она вполне боевая и продаваемая.
устаревшими технологиями
Такое сказать может только тот у кого «Delphi» это Delphi 7. Хоть чуточку поинтересуйтесь на досуге, что из себя представляет современная версия.
Тем более что автор не раз указал, что использует версию 10.3.3 которая вышла в конце 2019.
Мало того, что я в курсе, у меня вот прям сейчас стоит на компе свежая версия. И я пытался перенести свою старую программу с седьмой версии на текущую, но потом забил, потому что это боль и всё не так работает. Хотя, в моей программе самые банальные контролы VCL и разные окошки. И дело совсем не в том, что нужно переписывать участки кода под юникод и всякие такие нюансы, а в том, что интерфейс кособочит и как это исправить, чёрт знает. Ну и сама иде — скорее пародия на вижуал студию, уж простите.
иде — скорее пародия на вижуал студию
Охх… насколько я помню то был человек который вложил тонну работы в делфи и его редактор, а потом он оказался в МС и работал над визуал студио и повторил свой редактор. Так что все наоборот, это не делфи похож на визуал, а визуал херовый клон делфи. Кстати как там визуал? Фризить и тупить он уже перестал?
И дело совсем не в том, что нужно переписывать участки кода под юникод и всякие такие нюансы, а в том, что интерфейс кособочит и как это исправить, чёрт знает.так вам программист нужен
Тоже занимался таким, но все было куда проще — нужно было только выдрать бизнес логику и дать к ней доступ через вебсокеты. Кодовая база чуть больше мегабайта, но большая часть модуль вообще не требовали изменений, а обратная совместимость с Delphi не требовалась. Все необходимые флаги были выставлены в lpr файле, либо передавались fpc.
Мощная статья, я бы так не смог. Скорее смотрел бы в сторону https://www.crossvcl.com/ .
А потом закончилось время just for fun и начались серые и скучные рабочие будни и семейные дела, которые уже не позволяют сидеть всю ночь над любимым проектом. Так иногда хочется вернуться во времена, когда я был жаден до любой информации и полон энтузиазма.
Спасибо!
Насколько я понял, несмотря на все IFDEF, исходники для Lazarus и исходники в Delphi — это теперь разные исходники, а DFM вообще пришлось допилить вручную после переноса, и делать это придется каждый раз при исправлениях в DFM.
Не возникло мысли полностью перейти на Lazarus, в т.ч. и на винде?
Или в этом случае есть какие-то существенные минусы?
Нет. Исходники у меня сейчас одни на всё. 2 файла форм пришлось откорректировать руками после конвертации (замена компонентов), но они редко меняются и это не трудоемко.
Везде свои косяки есть. Лазарус иногда может криво переколбасить код если новый обработчик события через редактор компонента делать.
Можно подробнее. Чем именно Лазарус лучше при написании и рефакторинге?
А вот где можно линукс-версию найти? :)
приходится держать virtualbox+win7 только из-за SiT…
Тоже VCL, тоже своя схемная графика с выводом через GDI+ и Direct 2D.
Но у нас более 1млн строк, более 2 тыс модулей в одном проекте, а во всех проектах порядка 4 млн,
около 20 пакетов компонентов сторонних разработчиков.
плюс использование новых возможностей языка последних 12 лет.
Плюс ActixeX, с ним, конечно, придется распрощаться.
Поэтому возможность использования Лазаря под сомнением.
Смотрели скорее на возможность перевода на FMX, crossvcl + пакеты типа www.tmssoftware.com/site/tmsfmxpack.asp
Сделали пробное портирование на FMX. Конечно, очень трудозатратно.
Свой абстрактный слой для вывода графики в разные графические движки уже есть.
Такой подход как у вас, с дефайнами, по моему опыту, годится только для кода, который больше не планируется развивать.
После обвязки дефайнами трудоемкость модификации увеличивается в разы, и так же падает мотивация что-то менять в этом коде.
Либо выносить все вызовы в абстрации, а платформо-зависимую часть в отдельные модули. А это уже не месяц работы.
Так что для себя я рассматриваю только перевод на всего проекта на другую платформу.
Но трудоемкость этого, если оптимистично, то 10 человеко — лет.
Наши заказчики электроэнергетики, году так в 18 многие спрашивали про Linux версию, в связи с правительственными приказами,
но оплачивать разработку и внедрение желанием не горят.
По разговорам с коллегами, у которых есть Linux-версия серверной части их SCADA, использует ее только 1 их заказчик, а заказчиков у них сотни.
Автору огромное спасибо!
Интересный опыт и полезный разбор проблем.
PChar тоже не подарок — повсеместно раньше использовался как аналог PByte (возможно его и не было те времена). А это всё низкоуровневое общение с памятью и куча проблем со старыми/сторонними компонентами
Я делал такое в дельфи. Сначала был переход на widechar вместе новой версией делтфи — там строки стали двухбайтные по умолчанию.
Самому Delphi (новому) без разницы в каком формате модули, UTF или не UTF. Данное замечание касалось только Лазаруса.
Спасибо! Я с Дельфи не работал лет 20 и наивно надеялся, что нынче проект тех времён довольно легко откроется и скомпилируется, или хотя бы есть автоматические инструменты миграции… конечно же, и RAD Studio, и Lazarus обругали меня нехорошими словами, а уж BDE+MS SQL выдали вообще нечего совсем нецензурное. Так что очень рад любым советам)
BDE в новых Delphi давно отстутствует.
Но некие энтузиасты еще извращаются и ставят его:
https://it-blackcat.blogspot.com/2019/12/walking-dead-bde-in-delphi-10-3-3-rio.html
Честно говоря, если вы не глубоко разбираетесь в тонкостях языка и всех компонентах вашего проекта, то лучше и не соваться в эти миграции. Т.к. проблемы конечно будут и нужно уметь их решать и переписывать те части проекта, которые того требуют. Иногда это довольно существенные изменения, поэтому, конечно, лучше мигрировать проект чаще (например, наш путь был Delphi 7 — CodeGear Delphi 2007 — Delphi XE — Delphi XE 3 — Delphi XE 7 — Delphi 10.1 — Delphi 10.3 — Delphi 10.4.1), т.е. мы мигрировали все проекты (с общей кодовой базой) на новые версии примерно через год после выпуска каждой из этих версий, иногда чуть раньше, пропуская некоторые версии, которые казались нам нестабильными или совсем уж бесполезными с точки зрения конкретно наших проектов).
У этой конторы есть инструмент Duster: gdksoftware.com/services/delphi-upgrades-and-updates
Ещё вроде бы Oxygene пытается расти за счёт того, что переваривает код на Delphi. Oxygene наиболее известен как Delphi Prism для .NET, а самая популярная цель у него JVM, но и натив тоже есть. Правда, с трассирующей сборкой мусора, кроме макос. На макосе родной ARC, остальные платформы, к сожалению, обделены. Беда какая-то с ARC в Паскалях.
В общем случае да, но есть нюансы. В Windows 10 insider build 17035 появилась возможность установить UTF-8 как 1-байтовую кодировку по умолчанию (Beta: Use Unicode UTF-8 for worldwide language support). В этом случае обязательно нужно перекодировать исходники *.pas в UTF-8, иначе словите глюков. Вот тут обсуждали: https://en.delphipraxis.net/topic/2556-test-your-product-with-utf-8-beta-setting/
Ужас какой. Я вообще не слежу ни за какими Insider Build'ами, т.к. глюков и в официальных Windows-релизах хватает.
Я надеюсь, что никто в здравом уме (по крайней мере среди наших пользователей) ни за что и никогда не будет пользоваться данной опцией.
Исходя из вашего опыта использования Code Typhoon, как там обстоят дела с лицензиями у различных компонентов? Их там очень много, но все ли идут с лицензией, например, на статическую линковку и использование в коммерческом ПО без ограничений?
Учились мы на ней в универе, сначала МВТУ 3.5, затем 3.7. На мой взгляд, достаточно простая, легкая (в смысле размера на диске) и ничего лишнего. А чего не хватало — решалось блоками кодов.
ИМХО, если начинать новый кроссплаформенный проект, то лучше сразу в Лазаре с использованием родных компонентов. Это поможет избежать кучи директив условной компиляции. Старый проект, конечно, да — придется пилить с кучей тестов
Можно тут обсуждение посмотреть:
www.sql.ru/forum/1263410-a/lazarus-dzheneriki
www.sql.ru/forum/1332221-a/generics-a-sobstvenno-kak-sravnit-elementy-t
Вроде бы это надо многим, и если этих многих собрать в одном месте, можно вместе начать что-то решать в этом направлении. Но как же их собрать?
Такое в норме, в понимании, делает государство в лице своих научных институтов. А ещё у нас ведь импортозамещение. Вот только в науку финансирование импортозамещения не идёт. Там ИИ и блокчейны, инновации, а подмести в своём дворе — это же не инновационно. Поддержка импортозамещения идёт только частникам. А чтоб частник в науку вкладывался, он должен быть монополистом, и тогда у него есть средства, и его наукоёмкая деятельность критична для сохранения монополии. Но монополисты все на Западе. Так и остаётся проект на уровне идеи.
Вообще денег в государстве хватает, только их надо давать по адресу.
У нас как бы капитализм сейчас.
При капитализме придумали вкладываться в инфраструктуру, а потом Кейнс обосновал, почему государство должно так делать, апеллируя к понятию общественного блага.
Но если государство забыло о своём существовании, то много частников могли бы собраться.
Ну я просто в курсе как именно люди работают над например программами cfd расчётов во ВНИИЭФ. Они деньги получают не за лицензии, а за НИР и продавать от себя разработку другим фирмам не могут. Поэтому у нас то, что было внутри НИИ сделано за их пределы как правило не выходит. А чтобы продать кому то лицензию или исходник надо организовывать независимое юридическое лицо. Такие конторки есть как правило при Вузах, мы сами некоторые работы так проводили, но там половину забирает себе вуз и мало остаётся, поэтому для нормальной коммерциализации надо или свою или дружественную фирму иметь. Это весьма большая проблема нашей экономики, из за которой собственно мозги утекают и разработки загибаются.
Задача государства — идентифицировать дефицитные общественные блага и восполнять их. С этим в IT некоторые затруднения, и не только у нашего государства.
Задача государства — идентифицировать дефицитные общественные блага и восполнять их. С этим в IT некоторые затруднения, и не только у нашего государства.
Согласен с вами на все сто процентов. Меня не покидают похожие мысли.
Возможно, в деталях я вижу другие блага, но в общем, они очень похожи.
Например, я все время думаю, почему в нашем государстве не уделяют внимание разработке собственных средств производства в ИТ?
Ведь любая среда разработки (IDE) + язык программирования — это средства производства в ИТ. Они первичны, а уже на основе IDE+ЯП пишутся платформы, на основе платформ пишется ПО или конфигурация.
Это как в машиностроении, без станков вы не произведете ни одного механизма, а производители станков, они же владельцы средств производства, все на Западе.
Почему наше государство не работает над созданием собственных средств производства в ИТ? Я бы с удовольствием в этом поучаствовал.
Та система (ПК SimInTech) которой мы занимается и особенности портирования которой были описаны в статье развивается давно, является платформообразующей в области расчётов динамики систем и активно используется организациями атомной отрасли и ВПК и деньги мы получаем от них за лицензии, доработки и техническую поддержку программного комплекса.
Было бы конечно просто замечательно если бы на разработки подобного рода выделялось прямое постоянное государственное финансирование, так как это позволило бы вести разработку с полностью открытым исходным кодом, но это во всём мире не так — над ядром Linux в основном работают сотрудники крупных корпораций, которые пишут доработки под свои нужды для своих изделий.
В общем короче: кто хочет делать — сначала делает и внедряет, а потом если это оказывается нужным, то это рано или поздно заметят и купят в той или иной форме.
Из примеров успешной отечественной разработки в области языков программирования и сред разработки можно упомянуть наверное Kotlin + среда разработки IntelliJ IDEA, который был выкуплен Google-м и от которого они зарплату и получают собственно
Так вот и обидно, что зарплату получают от Гугля, а не например от Ростех или Роснано. Нам (России), что не нужны собственные среды разработки и языки программирования?
Когда мы поймем, наконец, что без собственных ИТ-средств производситва мы так и будем на задворках этой индустрии находиться, а уровень нашей цифровизации будет на 100% зависеть от западного дяди Сэма. Или может государство думает, что мы такие богатые, что частным образом поднимем отечественный ИТ с колен? Так не бывает. Государство должно понять, что нам просто жизненно необходимы собственные средства разработки для Эльбрусов, АстраЛинукс и т.д… и государство должно вкладывать в это деньги, а не частный капитал.
Вы затронули очень важную для меня тему разработки кроссплатформенного нативного софта. Ну не могу я без боли смотреть на потуги web-разработчиков и старания джавщиков, которые пишут на третьем-четвертом уровне надстройки над нативом. У меня просто не поднимаются руки писать софт для интерпрайз на web-платфоме.
Может конечно это мои «тараканы», но я все равно считаю, что более мене серьезный софт для бизнеса (B2B) должен быть нативным, не зависимо от ОСи или архитектуры CPU.
- Service Workers во множестве запускать из одной вкладки — моветон, так что нужны зелёные потоки, работающие в одном реальном потоке браузера.
- Обработка исключений в WebAssembly сделана сейчас из рук вон плохо. Исключение сдирает весь стек Wasm, так что ничего ценного (читай: RAII) там хранить нельзя, и это ещё один повод делать зелёные потоки.
- Текущие трансляторы в Wasm в гораздо большей степени следуют спецификации Wasm, чем пытаются быть конгруэнтными desktop. И вообще с ними больше шансов потерять в производительности даже по сравнению с JS, чем выиграть. Например, ВКонтакте и другие сайты грузят только модули, которые нужны, по мере необходимости, и кешируемые независимо, а EmScripten заточен под большие статически собранные модули, обновляемые, загружаемые и компилируемые целиком. С SDL2 под EmScripten экспериментировал, так там нет ожидания события, а есть только опрос. Если вкрутить опрос в быстрый таймер, нагрузка 100% CPU на перерисовку вне зависимости от того, делаю ли я что-то в UI. Если вкрутить опрос в небыстрый таймер, получается слайд-шоу. SDL2 по-любому где-то ставит свои обработчики на клавиатуру и мышь, но не даёт подкопаться к ним, делать работу только когда она появляется. Да любой Ангуляр лучше работает, чем SDL2 под EmScripten.
- Asincify в EmScripten не поддерживается, а и раньше был как-то криво сделан, что вызывало раздутие кода до 10 раз. Предположительно, кривизна связана с тем, что EmScripten следует спецификации Wasm, то есть, принимает аргументы и размещает локальные переменные средствами Wasm. Такой контекст тяжело сохранять и воссоздавать, а ещё продолжать с любой точки останова.
- Emterpreter же способен реализовать потоки, переживающие возврат управления браузеру, но супер тормозной. Я убеждён, что можно реализовать промежуточный вариант, не супер тормозной, но и не раздувающий код в 10 раз. В идеале можно было бы просто взять Continuation Passing C, но…
- AdaMagic реализует адские исключения либо через setjmp/longjmp, либо через исключения C++, и оба способа не поддерживаются в CPC.
- CPC преобразует только код, размеченный особым соглашением о вызове, о котором AdaMagic не знает, а надо, наоборот, преобразовать всё, кроме редких исключений.
- CPC реализует асинхронизацию корректно, но очень не оптимально. Одна функция разбивается на несколько по всем возможным линиям разреза. В прологе преобразованных кусочков загрузка локальных переменных и освобождение памяти, в эпилоге выделение памяти и выгрузка локальных переменных. Это невероятное давление на менеджер памяти.
- Кроме того, в Wasm косвенные вызовы расходуют место в таблице косвенно вызываемых функций, а CPC в силу своего принципа работы производит их в изобилии. Представляется возможным сделать преобразование вида while case, чтоб одну исходную функцию преобразовывать в одну преобразованную.
- Динамически загружаемый модули в EmScripten есть, но с учётом всех особенностей ведут они себя совершенно неконгруэнтно desktop. Загрузка динамическая, которой на desktop нет, и надо ещё смотреть, как, например, таблицы косвенно вызываемых функций распределяются при подгрузке модулей, там наверняка ещё проблемы вскроются.
В общем, все проблемы, какие есть, представляются решаемыми. И если поверх веб сделать среду исполнения, похожую на desktop, то можно будет писать программы так, чтобы на desktop они могли развернуться по-полной, а в веб просто работали в более стеснённых условиях.
Подготовить веб — первое, что я хочу сделать для Objective PE.
И если поверх веб сделать среду исполнения, похожую на desktop, то можно будет писать программы так, чтобы на desktop они могли развернуться по-полной, а в веб просто работали в более стеснённых условиях
Зачем надо переделывать кривой web и ставить на нем новую надстройку?
Почему бы просто не отказаться от web, а сделать новую платформу вместо web, которая будет поддерживать как кривые стандарты weba для совместимости, так и новые нативные стандарты для разработки desktop приложений нового поколения?
На Astra Linux SE (Smolensk) запускали своё ПО? Работает ли ПО, созданное на Delphi, в этой ОС? Пробовали вести разработку на Lazarus в самой Astra Linux SE?
У нас сейчас стоит схожая задача — сделать наше ПО, разрабатываемое на Delphi, кросс-платформенным. Причём, скажем так, приоритетная не-Windows ОС — именно Astra Linux SE. Я начал читать их «РУКОВОДЯЩИЕ УКАЗАНИЯ ПО КОНСТРУИРОВАНИЮ» и приуныл. С первого взгляда похоже, что необходимое требование — разработка с использованием Qt. Lazarus, вроде, поддерживает Qt. Но как оно всё работает в реальности на разных ОС? Можете что-то прояснить?
На Astra Linux я ставил и code typhon и компилировал программу, причём на версии smolensk у меня заводился код который я собирал на alt Linux 9. Также проверяли и на более новой версии Orel. Библиотека gui была использована штатная, то есть. Gtk2 с которой Лазарус работает по умолчанию. Все там завелось. Были проблемы с фортрановскими so, т.к. там требовалась определённая версия фортрана 77 для компиляции, чтобы ошибка не возникала.
На странице CrossVcl написано:
CrossVCL doesn't work properly on some Linux distros. Here is known list:
— AstroLinux Smolensk 1.6 because of non-standard version of GTK+ (Works fine on AstroLinux CE)
2. Со своей тестовой машиной можно, вероятно, много чего вытворять, а вот с клиентской — не факт. И учитывая, что речь идёт об Astra SE, лично я бы рассчитывал на минимальную возможность маневрирования. В любом случае, саму Астру нам ещё не приобрели, поэтому ничего конкретного утверждать не могу. Вот и собираю информацию пока.
Однажды встал вопрос использования и под Linux. Пробы показали что вполне приемлемо работает через wine, за исключением чисто виндовых зависимостей, которые были не критичны и от которых я просто отказался, и сейчас даже и не помню что это было, ибо сейчас и на windows эти функции не нужны.
Единственно, не помню как там у меня с печатью обстоит, вроде не было нужды печатать из Linux.
В качестве Linux использовались различные разновидности Ubuntu, Lubuntu 12.4, 16.4, какие-то разновидности линукса с Asus EEE PC и тому подобное.
Так же был написан на том же Delphi7 информационный киоск, работает как на винде так и на линухе. Т.к. работает в режиме фулл-скрин — операционка вообще без разницы.
Был еще один затык на киосках с линуксом — т.к. программа стартует так сказать из автозагрузки, то получается что гуй и программа уже запустились, а сеть — еще нет. Можно было позадуряться с зависимостями запуска, но я просто влепил паузу, в конфиг, и если это линух — то паузу включаю, а если винда — то пауза не нужна.
Особенности портирования сложного модульного ПО написанного на Delphi под ОС Linux