Проблемы KOL на 2022 год.
Leoparrd (24.10.22 13:13)
Кладов сам не понимет какую гениальную и грандиозную вещь он создал, раз решил на нее плюнуть. Его можно понять, без поддержки сложно это все тянуть.
К самой KOL и MCK претензий нет, чего не скажешь о дополнениях.
Почти во всех них, нет поддержки юникода.
Ну это в общем-то не проблема, только время на переделку занимает.
Но вот с 64 битными приложениями проблема и большая.
Ассемблерные вставки это проблема номер один.
Если с push или pop понятно то вот с конструкциями call DWord PTR [] проблема.
Нужен специалист по передке.
Потом Obj включения. Их надо переделывать в 64 битные
Впрочем их не так много.
Может найдется кто, кто может это сделать?
Гость (26.10.22 09:34) [1]
> Кладов сам не понимет какую гениальную и грандиозную вещь
> он создал
Солидарен.
Dimaxx © (27.10.22 13:54) [2]
Директива PAS_VERSION и ребилд. Асм отпадет сам собой.
Leoparrd (27.10.22 22:19) [3]
Директива PAS_VERSION и ребилд. Асм отпадет сам собой.
Это там, где эта директива есть.
Вы совершаете ту же ошибку что и с юникодом.
В дополнительных компонентах директив таковых нет.
Dimaxx © (28.10.22 11:53) [4]
Добавьте эту директиву в свой проект и ее действие распространится на все остальное. Емнип, асм используется только в самом КОЛе, в компонентах его нет. Вам же КОЛ на 64 битах нужен? Вот и будет он на 64 битах и весь паскалевский. В FPC же КОЛ как-то работает без асма и не жужжит. И как раз с директивой PAS_VERSION. Для использования юникода также есть директива. В сторонних компонентах, если поддержки юникода нет, то да, придется лопатить, чтобы ее прикрутить. В чем ошибка?
AndreyRus © (28.10.22 18:55) [5]
Есть большая проблема при правке кода - рассинхронизация версий ASM и PAS. Это большая проблема.
Leoparrd (28.10.22 22:27) [6]
Вам же КОЛ на 64 битах нужен?
Нет. То что есть и так прекрасно работает. Дело в дополнительных модулях в которых ассемблер без переключения на паскаль.
Dimaxx © (31.10.22 11:40) [7]
> Дело в дополнительных модулях в которых ассемблер без переключения
> на паскаль.
В каких, например? В самописных - вопросы к автору. В самом КОЛе все закрывается директивой - работа PAS_VERSION на FPC в 64-битах тому пример: весь асм отключен.
> рассинхронизация версий ASM и PAS
Что вы подразумеваете под рассинхроном? Ошибку в pas (asm) версии каком-либо месте исправили, а ее asm (pas) реализацию нет? Напомню, асм-версии в КОЛе самописные - это не паскалевский код, превращенный дельфей в асм и просто закинутый в КОЛ вместо паскаля, это не имеет смысла. Если асм-версия работает без ошибок - зачем ее править? Если pas-версия с ошибкой, то ее поправят. И наоборот. В итоге обе версии будут работать верно.
Leoparrd (31.10.22 15:30) [8]
Вот я и говорю. кто может поправить.
И еще надо переписать модули с obj на C++
есть еще такой модуль Err не компилируется на старших версиях делфи.
Очевидно конфликт с юникодом.
Dimaxx © (31.10.22 16:27) [9]
Несколько лет назад велась дискуссия о том, что асм из КОЛа надо выкидывать. Если бы не пара "НО". 1) кто будет лопатить? 2) нафик это надо?
КОЛ частично "заброшен", имеющийся вариант всех устраивает. асм проблемой не являлся. Серьезные баги, про которые тут писали, правил ув. DKOL и выкладывал исправленное сюда https://sourceforge.net/p/kolmck/code/HEAD/tree/
> И еще надо переписать модули с obj на C++
Какие модули? Причем тут С++? И зачем?
Leoparrd (31.10.22 18:19) [10]
Какие модули? Причем тут С++? И зачем?
Некоторые нужные модули используют компилированные с++ obj файлы
Вы этого не знали?
С 32 проблем нет.
Для 64 нужно эти модули переделать в KOL.
сами файлы есть. код модулей на паскале есть. надо только переделать в KOL
Многие дополнительные модули имеют asm вставки без пас версий.
Какие модули?
Да все связанные с графикой и компрессией.
JPEG PNG GIF BZ2 ZLIB
Все они используют сишные obj и asm вставки.
QAZ © (31.10.22 20:25) [11]
в свое время Кладов занимался полной херней по типу поддержки 9х винды (до последнего юзера ее пользующего) вместо поддержки новых, удивительно(!!!) что в принципе юникод появился в КОЛ и вообще не удивительно отсутствие х64....
"алфор" которым он страдает последние лет 10(но это не точно) он даже сам толком не может описать в мануалах
по итогу, мог сделать нормальную, законченную, нативную систему под винду, а не вышло нихрена, кол просрал, "алфор" мертворожденный гомункул
Leoparrd (31.10.22 21:10) [12]
К KOL претензий нет. Паскалевский код прекрасно компилируется.
KOL 64 работает на старших версиях Delphi без особых проблем.
Нужно только передать в KOL некоторые библиотеки и всё.
Простая подстановка 64 битных obj не работает.
В принципе можно перевести в паскаль сишный код.
Вот я и спрашиваю, может ли кто этим заняться.
Что касается "KOL просрал" я бы так не сказал. Сделан он был для своего времени. И проблема только в том, что проект не получил должной поддержки.
На KOL у меня написано масса вещей, но к сожалению только 32 разрядных. Некоторые лучше бы написать на 64. Но нет нужных готовых модулей. Видимо придется грохнуть кучу времени на них самому.
Dimaxx © (31.10.22 21:27) [13]
> Некоторые нужные модули используют компилированные с++ obj
> файлы
> Вы этого не знали?
> С 32 проблем нет.
> Для 64 нужно эти модули переделать в KOL.
> сами файлы есть. код модулей на паскале есть. надо только
> переделать в KOL
Вы же парой постов выше говорили, что вас и 32-битная устраивает. Зачем переделывать то, что работает? Меня устраивает то, что есть. Хотите 64 бита - берите сишные исходники и компильте в билдере, потом прикручивайте к врапперу на паскале.
Leoparrd (31.10.22 22:20) [14]
Вы же парой постов выше говорили, что вас и 32-битная устраивает
Я говорил? не пудрите мне мозги. Если бы я это говорил, я бы не писал про 64.
Ещё раз. Просто так не прикрутить. Пробовал.
Dimaxx © (01.11.22 00:52) [15]
> Я говорил? не пудрите мне мозги. Если бы я это говорил,
> я бы не писал про 64.
А это я значит выдумал?
> Leoparrd (28.10.22 22:27) [6]
>
> Вам же КОЛ на 64 битах нужен?
>
> Нет. То что есть и так прекрасно работает. Дело в дополнительных
> модулях в которых ассемблер без переключения на паскаль.
>
Leoparrd (01.11.22 01:10) [16]
А это я значит выдумал?
Конечно выдумал.
KOL и так прекрасно работает и на 32 и 64 битах.
Проблема в дополнительных модулях, которые писались для 32 бит.
Их надо переделать на 64. В чем собственно проблема?
Если можете это сделать, то приступайте.
Если нет, гуляйте мимо.
Dimaxx © (01.11.22 09:07) [17]
> Вам же КОЛ на 64 битах нужен?
> > Нет. То что есть и так прекрасно работает.
То есть вы даже за свои слова не отвечаете? Вопрос: нужен 64-битный КОЛ? Ответ: Нет. Вы уж определеитесь, что вам нужно.
> Если можете это сделать, то приступайте.
Это вам надо, мне нет - меня устраивает то, что есть. Вот и приступайте. Чего нет - я сам найду и переведу/адаптирую под свои надобности.
Лень гуглить? Ок, подскажу. Ищите paszlib/pasjpeg - валяются в инете давно. Реализации gif на паскале тоже есть. Нужна только загрузка jpeg - nanojpeg на паскале есть. Если все сразу, юзайте GDI+ для дельфи - там есть bmp/gif/jpeg/png/tiff чтение/запись и еще много чего. Чего-то нет или версии старые - берете сишные исходники и переводите на чистый паскаль. Что-то переводить вам по вашему запросу никто не обязан. Не умеете (и такое бывает) - юзайте то, что есть.
lord (01.11.22 11:34) [18]
Это вам надо, мне нет - меня устраивает то, что есть.
вам же ясно написали - гуляйте мимо.
Dimaxx © (01.11.22 11:44) [19]
> вам же ясно написали - гуляйте мимо.
Не говорите мне что делать и я не скажу куда вам идти.
lord (01.11.22 14:17) [20]
Не говорите мне что делать и я не скажу куда вам идти.
Вот именно. Вам адрес уже назвали. Потактичней и поделикатней.
Dimaxx © (01.11.22 15:02) [21]
Вам могу указать тот же адрес.
Vladimir Kladov © (28.11.22 08:13) [22]
Дело совсем не в том, что KOL какой-то особо гениальный, а Алфор - наоборот. По мне, так совсем иначе, но дело совсем не в этом.
Вот если бы до 2016 года КОЛ не было, а в 2016 он впервые появился - вы бы о нем вообще не знали. И он так же никому не был нужен. И сейчас КОЛ если кому и нужен, то только тем, кто про него уже знает, и на вас он кончится. Увы.
Новые люди не приходят. Они все ушли в мейнстрим: Go, Java, Python, и прочие Rubi. А что еще вы хотели? Всем нужна мультиплатформенность или хотя бы востребованность, чтобы было на что жить.
Мне очень обидно, что я не бросил КОЛ лет на 10 раньше, и не сделал Алфор тогда. Может быть, успели бы появиться последователи. Теперь уже поздно - поезд для одиночек-энтузиастов ушел. Сделай сейчас кто-то в одиночку супер-пупер новый язык - никто и не пошевельнется и не заинтересуется. Это же не гугль/ибм/микрософт/оракле. Значит, скоро (лет за 5-20-40) помрет. И нет смысла изучать, пробовать. Остался только ням-ням того, что втюхали Корпорации. Ну и нямкайте без меня дальше.
lord (03.12.22 03:14) [23]
Проблема в том, что Алфор страшно ограничен.
Нет многомерных массивов. Цикла While
и много прочего по мелочам.
И я не думаю что на нем можно было бы влезть в пикселы и работать с ними на уровне битов.
В общем всего того к чему я привык.
Что касается кроссплатформы, KOL прекрасно компилируется.
И под любую ось и даже под ARM
Go, Java, Python, и прочие Rubi это не языки программирования. Это скриптовые языки. Библиотеки к ним так и так пишут на Си
Я всего лишь хотел чтобы некоторые модули смогли компилироваться под 64 бита.
Все есть, только что и надо перевести это это в KOL
Вы прекрасный специалист. Однако не надо опускать руки. Писали бы для одиночек.
Сама KOL под 64 существует. Паскалевская версия, но адаптированная.
Она прекрасно ставится на новые версии Делфи, или как там сейчас их называют.
А вот проблема только с графикой и компрессорами. Там только 32 разрядные версии.
У меня есть несколько проектов, которые хотелось бы перевести в 64 бита.
И еще было неплохо исправить глюки в некоторых компонентах.
Если бы у меня было бы больше времени и возможно ума, я всё бы это сделал сам, но это займет много времени, и его не хватит на проекты.
И вы не правы по отношению к живучести всякой фигни вроде андройда и прочего. Импортозамещение потребует настоящих программистов а не скриптописателей.
Vladimir Kladov © (03.12.22 19:26) [24]
По первому абзацу - все неверно. И многомерные массивы есть - через классы. Я просто не стал их "встраивать" в компилятор. Гибкость - иногда вреднее, чем нужнее. И в пикселы можно влазить. А как бы еще можно было сделать поддержку текстур для Open GL.
KOL может и компилируется под разные платформы. Но в чем смысл его на этих платформах, если он заточен под WinApi. А на Android он тоже компилируется? Насчет Линукса - если без Wine - то как быть?
Новые Delphi мне не интересны. Ставил пару раз - и больше не буду. Очень громоздкий, долго ставится, долго сносится, слетает по непонятным причинам, зас***ет систему - требуется переустановка винды для очистки от мусора. Работа на ПК, не подключенном к сети - как бы помягче сказать - затруднена. Сам Delphi постоянно что-то там у себя меняет: революции 2 раза в год. FireMonkey - вообще какой-то шлак с помойки.
Я не понял насчет Андроида - я вообще слова про него и его живучесть не сказал. И насчет импортозамещения тоже ничего не понял. Настоящие программисты программируют на Фортране. Для Эльбруса. Хотя нет, там же в С++ компилятор - своих языков-то нет.
lord (04.12.22 00:03) [25]
KOL если полностью включить режим паскаля, компилируется и под линукс и под андройд, и под ARM
FireMonkey вообще не при чем.
Что касается андройда, я просто обобщил.
вы написали про Java и про прочую муть.
Я всего лишь сказал. что настоящие языки, это те что компилируются в исходный исполняемый код.
А то что вы перечислили это скриптовые языки, которые работают не в осях а виртуальных машинах. Вот андройд виртуальная машина и есть, для джавы.
Поэтому я и обобщил все это под андройд.
Про импортозамещение я сказал, что нужны настоящие программисты. То есть те которые пишут на компилируемых языках. и те, которые смогут заставить дышать эльбрус.
И потом, я же уже написал что у меня есть несколько почти готовых проектов, которые я просто бы хотел скомпилировать в KOL в 64 бита без всяких других языков. Да, в паскалевской версии они не такие маленькие, но не 2 мегабата.
меньше 100 K.
Но мене нужны модули с компрессорами и работы с графикой. вот и все.
Сам модифицированный KOL с названием KOL64 и МСK работают вполне нормально на новых версиях Делфи.
А модули эти, которые работают и в 32 и 64, существуют, но для VCL
Все что нужно, это чтобы они работали с KOL.
Вот когда у меня все заработает как надо и в 64 разрядах я посмотрю и ваш язык. Может действительно что получится. А пока надо разобраться с тем. что есть.
Vladimir Kladov © (04.12.22 07:17) [26]
По-моему, Вы, lord, не разобрались, где языки программирования, где платформы, и где библиотеки функций. KOL (проект на KOL) НЕ МОЖЕТ компилироваться никуда, кроме Windows. Ну, если только это не консольное приложение. Другое дело, что результат компиляции - бинарный файл - может быть выполнен в Линукс (даже и визуального, с формами). Через wine - это еще 20 лет назад работало. Для этого не требуется особая компиляция, достаточно обычного Delphi 3-7. Визуальная часть KOL работает через оконные сообщения Windows, без них KOL - уже не KOL, куда бы вы его не компилировали. Если новый Delphi умеет компилировать в dalvik и при этом транслирует с сообщения Windows на android-е - ну что ж, поздравляю - у вас на андроиде развернута виртуальная машина с эмулятором WinApi. О-о-очень экономненько так.
Алфор позволяет выбрать в качестве целевой платформы Delphi+KOL. Или Delphi+VCL. Или FreePascal+LCL. Или C#+WinForms. Или Java+Android. И при этом не требуется никаких изменений в исходном коде. У меня есть несколько больших и средних проектов на VCl. Так вот, я за пару месяцев перевел большой проект с VCL под Алфор и теперь он спокойно может запускаться и работать под Линукс (Free Pascal) или Виндовс (Delphi7(+KOL/+VCL) / Free Pascal / C# - на выбор).
Не знаю, чем вам так уперлась 64-битность кода, но 3 из перечисленных вариантов - 64-битные. Размер кода в случае большого проекта уже мало зависит от того, KOL там или не KOL. Там изначально было 3-6 Мбайт в exe-файле (в зависимости от опций проекта). После перехода на Алфор получаются те же 3 Мб в случае VCL, и 2 Мб - KOL. 64-битность спокойно получается при компиляции Free Pascal-ем (около 7 Мб) и C# (около 5Мб).
Или под 64-битностью Вы понимаете поддержку unicode? Так в случае компиляции во Free Pascal и C# она тоже есть.
А вообще, KOL изначально не для больших проектов. Я это всегда особо отмечал.
lord (05.12.22 11:49) [27]
{$I KOLDEF.INC}
{$IFDEF WIN64}
{$DEFINE PAS_ONLY}
{$DEFINE STREAM_LARGE64}
{$ENDIF}
{$IFDEF PAS_ONLY}
{$DEFINE PAS_VERSION}
{$ENDIF}
{$IFDEF EXTERNAL_KOLDEFS}
{$INCLUDE PROJECT_KOL_DEFS.INC}
{$ENDIF}
{$IFDEF EXTERNAL_DEFINES}
{$INCLUDE EXTERNAL_DEFINES.INC}
{$ENDIF EXTERNAL_DEFINES}
{$DEFINE GDI}
{$UNDEF LIN} {$UNDEF WIN} {$UNDEF GDI}
{$IFDEF LINUX}
{$DEFINE UNIX}
{$DEFINE LIN}
{$DEFINE PAS_VERSION}
{$DEFINE NOT_USE_RICHEDIT}
{$IFNDEF GTK}
{$IFNDEF XQT}
{$DEFINE GTK} // it is also possible to define GTK as a project option
{$ENDIF XQT} // even for Windows system
{$ENDIF GTK}
{$ELSE} // to exploit GTK under Win32 rather then native GDI
{$DEFINE WIN}
{$DEFINE GDI}
{$ENDIF}
{$IFDEF GTK} {$UNDEF GDI} {$DEFINE _X_}
{$DEFINE NOT_USE_RICHEDIT}
{$ENDIF}
//{$IFDEF Q_T} {$UNDEF GDI} {$DEFINE _X_} {$ENDIF}
{$IFDEF WIN} {$IFDEF GDI}
{$DEFINE WIN_GDI}
{$ENDIF GDI} {$ENDIF WIN}
{$INCLUDE delphidef.inc}
{$IFDEF WIN_GDI}
//test
{$ENDIF WIN_GDI}
{$IFDEF LIN}
//test
{$ENDIF LIN}
unit KOL;
{$IFDEF FPC}
{$MODE Delphi}
{$ENDIF}
lord (05.12.22 12:17) [28]
Это вот кусок из KOL64
Сколько раз говорить.
Мне нужен не KOL а чтобы модули с ним работали.
есть модуль PNG с 32 и 64 битами.
Вот он мне нужен. Чтобы просто он работал с KOL как тот, что есть сейчас под 32
Для других картинок так же.
И компремссоры.
Алфр как работает с графикой?
И вообще я не голословно говорю. я говорю о том что сделано и что реально с компилировано.
32 битные приложения на чистом паскале 42K 64 битные - 84K
Под линкус тоже работает все прекрасно.
Мне нужны картинки. Проблема в модулях OBJ они 32 разрядные.
А для 64 разрядных нужно переделать сам файл, который уже существует.
Вот все что мне нужно.
Мне нужно отвязать эти модули от VCL
Вот и все.
По поводу больших проектов громко сказано, но конечно не мелкие утилиты.
На 32 готово и работает.
Я не понимаю вашего упрямства. Ну не хотите вы мне помочь не надо.
Но не надо из меня строить идиота.
Я прекрасно знаю что такое платформа.
Мне достаточно винды.
И прекрасно знаю что KOL это огромная библиотека на языке паскаль.
А PNG GIF это библиотечные модули, которые работают конкретно с KOL
Что такое языки программирования я тоже знаю.
И Питон и то что вы перечислили это скриптовые языки. Это уже не программирование а кодерство.
И точно так же знаю что Андройд это виртуальная машина вклеенная в линукс.
И на все смартах стоит именно линукс с этой примочкой.
Vladimir Kladov © (06.12.22 07:24) [29]
Алфор работает с графикой нормально. Есть демо-приложение zoomer6 на Алфор, lite-версия выложена в директории Demo с исходниками. Для Алфор я переписал gif на высокий уровень, изрядно потеряв в быстродействии, но обеспечив быстрый переход на любую платформу. При желании и наличии времени, никто не запрещает для каждой интересующей платформы самую медленную часть переделать на нативный код.
Т.е. вам не интересен KOL, а нужны его возможности работы с графикой - так бы и сказали. И платформа нужна только Windows. Допускаю, что Windows будет еще некоторое время нужен, но уже сейчас в 11 версии потихоньку начинают зажимать 32-разрядные приложения. Подталкивают разработчиков в сторону 64. Лет через 5-10 будет поставлен окончательный крест на 32-битном Api. Конечно, не так радикально, как поступило яблоко, но все равно к тому идет. Подозреваю, что в Windows12 32-битность будет убита на уровне ОС.
Я все равно не принимаю Ваше упорство по поводу разделения ЯП на нормальные и скриптовые. ЯП - это ЯП, скриптовый он или нет. Для той же Джавы и Питона есть возможности компиляции в машинный код, но даже это им и не нужно, чтобы становитья ЯП. У меня есть разочаровывающий опыт: когда я для Алфор поддерживал направление Java/Desktop, программа число-строко-дробилка при компиляции в Java обгоняла почти вдвое самый быстрый вариант. Delphi/VCL отставал примерно в 1,5-2 раза, за ним впритык шел Delphi/KOL и немного приотставал C#. Затем в 2 раза хуже шарпа был Free Pascal (но с тех пор я оптимизировал работу со строкаму в utf-8, и теперь он практически на том же уровне). Хуже всех был хваленый C++ - из-за его неоптимальной работы с std::string. Но главное - это то, что Java уделал всех.
Да, Java на Android-е тот еще тормоз. Но, при желании, и наличии времени (и людей) всегда есть возможность поддержать и низкоуровневое программирование под конкретные процессоры. Алфор допускает низкоуровневые вставки.
lord (06.12.22 12:36) [30]
Как же с вами сложно.
KOL уже есть. И работает он и под винду и под линукс.
Для чего мне 64 битные приложения? Вы уже сами ответили на этот вопрос.
В данный момент меня интересуют модули прежде всего.
Что касается джавы то тут вы уже чушь написали.
Джава это интерпретатор в котором исходный код скомпилирован в байткод, который выполнятся на виртуальной машине. И он управляет библиотеками, которые написаны на самом С++.
Точно так же как и Direct X и Open GL
И он никак не может быть быстрее скомпилированного кода в полтора раза, и тем более в 2.
Языки программирования не влияют на скорость и на что-либо. Эти рассуждения на уровне что лучше, русский английский испанский и так далее.
Дело в компиляторе. А тормоза это классы и прочая муть.
Это если говорить про языки программирования.
У скриптовых языков скорость зависит от скорости работы самой виртуальной машины и не более того.
Знаете почему был получен прирост скорости?
Да очень просто, потому что виртуальные машины активно используют нити (программные потоки) и всякие штуки вроде MMX и прочего.
Точно так же используются разные алгоритмы.
Читать текст как бинарные данные из потока намного быстрее.
И вы сами написали модуль списка с нуль-терминаторами. Это тоже ускоряет обработку строк.
Вот скажем простой пример. Нужно считывать и обрабатывать текстовые данные в юникоде. Да еще в регистронезависимом режиме. Как это сделать быстрее? Да очень просто. Использовать таблицы.
Кстати про обработку строки в UTF-8
А нафига? UTF-8 нужен для хранения текста а не для работы с ним.
Поэтому он как и другие экзотические кодировки превращаются в UTF-16
Его за глаза и за уши, если язык не китайский.
Мой проект как раз и делает что занимается всем этим. И уж поверьте экспериментов по этому поводу было сотни на разных языках и на разных платформах. Особой разницы нет.
Все зависит от скорости процессора памяти и вообще от аппаратного обеспечения и алгоритмов. А от компилятора практически ничего. Но я сказал про компиляторы, а не интерпретаторы.
А такие заявки что мне KOL не нужен... это бред. Если я выбрал эту библиотеку, то вполне осознанно и очень давно.
Он хорош, но без внешних библиотек сильно ограничен, как и любая глобальная библиотека. составляющая ядро.
Просто было бы проще, если бы кто-то сделал то что вы сделали для 32 версии
В принципе все тоже самое, но с вставкой 64 битной версии.
Сами модули для VCL и OBJ есть.
Vladimir Kladov © (07.12.22 10:52) [31]
KOL никто и не закрывает. Более того, для меня он - одна из целевых платформ. 64-битностью для kol я заниматься не буду. Как минимум, по причине отсутствия бесплатного, легковесного (хотя бы сравнимого со старыми Delphi), нормально работающего (в том числе без доступа к сети/интернету) компилятора. Про новый Delphi я уже говорил.
Насчет Java вы не правы - это не интерпретатор. Сейчас основной принцип его работы - его код из байт-кода компилируется при первом обращении к функции. Далее выполняется честный машинный код. Почитайте про JIT.
lord (07.12.22 14:33) [32]
А причем тут компилятор? При чем тут новая версия Делфи?
Я только хочу переделать несколько модулей под KOL и все.
Там уже все есть, надо только сделать то. что вы уже когда-то сделали.
Модули работают как под 32 так и под 64 бита. Переключается ключами условной компиляции.
Так что компилятор и версия Делфи им до лампочки. в крайнем случае если это мешает задокументировать все что относится 64 битам и сделать чтобы заработала 32 разрядная версия. А потом мне только останется снять скобки и все.
Прежде всего мне нужен архивный компрессор. И PNG. В нем тоже компрессор, почти аналогичный модуль архивному компрессору. И для этого вполне достаточно даже 7 Делфи. Если заработает 32 битная часть, то заработает и 64 битная.
Что касается Java.
Если все так как вы написали, она теряет кроссплатформенность. И превращается в обычный клон С++.
А Новые Делфи компилируют под любую платформу.
И про FreePascal забывать не стоит забывать. Он давно это делает.
Так что вся соль Java именно в байткоде. а преимущество в мощной поддержке.
В любом случае JAVA актуальна лишь в качестве аплетов под Андройд.
И у меня проделана огромная работа над моими двумя проектами.
И переделывать весь код на другой язык и на что либо другого нет смысла.
на 32 все отлично работает. На 64 упирается в графические модули.
И даже в 32 разрядной версии есть глюк.
ListView если положить их два и более на форму. вступают в конфликт друг с другом. Особенно если задействовано событие отрисовки. Висит не только приложение но и вся система. Даже диспетчер не вызвать. только полная перезагрузка компа.
lord (07.12.22 20:37) [33]
что касается JIT
интерпретатор остался интерпретатором, только компилируемым.
Никакого преимущества перед другими языками не вижу. Это не технология, а как любят сейчас выражаться лафхак.
И она совершенно не нова.
На одном форуме есть аналогичная система на паскале.
Там интерпретируемый калькулятор.
Он для ускорения превращает саму заданную текстом функцию или вычисляющий скрипт в байткод.
Этот код выполняется.
И далее было написано расширение этого модуля.
Для построения графика используется та же самая штука что и JIT
Пользователь набирает сложную формулу или всякие скрипты вычисления с интегралами и прочим. Это превращается в паскалевский код, котрый компилируется в DLL компиляторм от самого Делфи. То есть этот компилятор лежит в папке с прогой и запускается через командную строку.
Ну а DLL пускается в дело и сама вычисляет и строит график.
Таким же способом на других форумах делались всякие проги для криптографии и прочих премудростей, например защиты от взлома.
так что в динамической интерпретации-компиляции нет ничего нового.
Насколько помню у вас на принципе поточной компиляции работает какой-то модуль. ну когда вы писали эмулятор спектрума, то его использовали.
На этом же принципе работают и аддоны и макросы в многих прогах.
Так что это не преимущество джавы, а хорошо забытая старая хитрость.
Митя (08.12.22 18:06) [34]
Давно хотел попросить Владимира Кладова создать поддержку юникода
lord (08.12.22 20:27) [35]
В KOL и MCK юникод есть.
Для включения юникода надо вставить в проект символ условной компиляции UNICODE_CTRLS
Все прекрасно работает.
Но юникода нет в дополнительных модулях. Их надо дописывать.
Митя (08.12.22 23:22) [36]
Ещё странный глюк заметил - иногда при сборке проекта с запуском, при закрытии главного окна приложения происходит какая-то ошибка в модуле KOL, access violation at 0x00404d93: read of adress 0x00000084.
От строки 28983
По строку 29003.
Если это закомментировать то всё норм. Этот глюк редкий но прочный - если вылез то надолго
Митя (08.12.22 23:38) [37]
О да! - сбылась мечта идиота - наконец в заголовке формы отображаются названия файлов с юникодами.
Теперь понимаю что нужны контроля наподобие TNT
lord (09.12.22 03:08) [38]
вообще то некоторые нужные функции в kol отсутсвуют. и приходится писать их самому. но это не критично. в дополнительных модулях некотрые таковые функции есть, но не поддерживают юникод. в некотрых местах есть код, не поддерживаемый даже 7-ой.
но и это не проблема.
что касается этой ошибки...
ну надо почаще делать перестройку проекта. особенно после добаваления на форму новых компонентов.
и еще некотрые проекты не стоит запускать под отладчиком, а только запускать из папки. например если есть перетаскивание.
и очень часто такая ошибка возникает при установке на форму компонентов старых версий.
их имена в uses становятся не туда куда надо.
а иногда стоит пересобрать проект вручную. то есть сделать новую форму, и заново поставить компоненты.
подобные приколы возникают если по ошибке воткнута vcl.
или вместо формы kol событие открыто в несущей форме.
или после некоректоного удаления компонента.
иногда случайно может быть стерт переключатель условной комиляции
так что надо просто быть очень внимательным.
и делать персборку. build
Митя (09.12.22 20:33) [39]
Пересборка не помогает - подозрение на винду с её реестром
lord (10.12.22 11:52) [40]
у вас какая версия делфи?
если 7ка то в принципе все должно работать без особых проблем. смотря что в проекте.
в крайнем случае нужно проверить на другом компе.
еще говорят глюки проявляются на 10 и 11 винде.
и еще, попробуйте запускать из папки, с правами админа и ставить совместимость.
конечно лучше бы завести знакомство с тем у кого большой опыт работы с этой библиотекой. но таковых крайне мало.
Митя (10.12.22 22:58) [41]
Дельфя 7 персонал
С открытой файловой системой.
Винда и хр и семёрка
Митя (10.12.22 23:00) [42]
В проекте приложение с вкладками на главном окне, есть окно настроек опций, окно о программе и окно настройки палитры главного окна, куча кнопок
Митя (10.12.22 23:05) [43]
А ну ещё рамки, текст.едиты, радиобатоны, чекбоксы, таймеров нет, ну и модули с кучей кода
lord (10.12.22 23:45) [44]
скорее всего что-то конфликтует. Это надо же опять смотреть весь проект.
лучше всего его пересобрать заново.
То есть сделать форму и расставлять компоненты. И проверять.
Потом добавлять события и каждое опять проверять.
Особое внимание уделить тому, чтобы компоненты при установке на форму прописывались в uses в нужном месте.
lord (11.12.22 00:30) [45]
потом еще надо учесть, что если включили юникод, надо ввести юникодовские типы.
widechar
widestring
Митя (11.12.22 10:09) [46]
Нет, в этом проекте юникод не используется.
Спасибо за подсказки - буду ковырять
ParanoiS © (22.12.22 16:39) [47]
увидел тут: КОЛ = косяк, тов.Кладов = плох, итп...
не увидел только истины: "программеры" = рукожопы.
Господа, КОЛ = офигенный инструмент (Кладов, тебе тоже отношу, чё ты забросил:) да ладно, понимАю... ), косяки там конечно есть (как и в любом пакете/программе, а уж ТАКОГО ВЕСА = сам Бог велел... Большому кораблю = большая торпеда:) не дай Бог конечно)
Ребята, НЕВОЗМОЖНО написАть много кода без косяков в коде/программе/пакете. Кладов хотя бы попробовал это СДЕЛАТЬ (получилось зашибись - to:Kladov), и ниибет. Если бы не он (и КОЛ, конечно) - не было бы массы полезного софта и исходников, на которых ,сука, ВЫ ВСЕ бл учились программить и добавлять хоть какое-то полезное свойство своим блевотным поделкам. Да тут на форуме дохера таких красавчиков, не читающих РТФМ.
Дак и вот - учитесь писАть, а не обсуждать и выёживаться. Берите Книгу о КОЛ, самУ библиотеку, РАСШИРЯЙТЕ, ДОПИСЫВАЙТЕ, ЭКСПЕРИМЕНТИРУЙТЕ, благо, Кладов и сделал её полностью фри. И НЕ НАДО звиздеть- глючит, хуючит... . Типа вы чё - круче его??!!:) а хуле, вперёд, напишите СВОЙ АЛФОР лучше чем он!!!! чё, слабо?:)
И - самое главное - изучайте. УЧИТЕСЬ, как завещал вождь, Без учёбы - ты уё ....
НАХ все эти беспонтовые базары. Я говорю - КОЛ = лучшее из всего, что было (и БУДЕТ) в ОбъектПас, тов.Кладов = ГЕНИЙ, и ВЫ все, кто нихуля не разобрались в себе, где, что и как писАть = ламеры. Бл, да вы конченные, если не признаёте собственных аццесс виолейшен. Да и х с вами. Мы-то реально программисты, не чета вашим параллельным извилинам, натягивающим уши. Чё вообще можно писАть на ВинАПИ+КОЛ = вам не снилось.
Модер, 1000+Сорри за мат, бесят просто...
Lord (23.12.22 15:43) [48]
А где ты нашел все что написал в том что написал я? Чот ты не по адресу.
Митя (27.12.22 21:39) [49]
И всё таки приложение вылетает при открывании файлов, в названии которых присутствуют некоторые символы юникода - как с этим бороться не приложу ума😩
Lord (27.12.22 23:12) [50]
Для того чтобы понять что происходит нужен конкретный код.
Или хотя бы перечислите модули что вы используете.
У меня все в полном порядке.
Митя (28.12.22 14:17) [51]
Нашёл - надо данный файла записывать в массив через поток а не функцией Assign(File,1); , как я привык. Теперь придётся поьренироваться
Lord (28.12.22 14:44) [52]
assign это вчерашний день. хотя если вы его используете то ищите юникодовскую версию, если она конечно существует.
Что касается файлов, то смотря какие файлы. если бинарные то через поток.
Если текстовые, то в KOL есть возможность загружать текст в строку. И записывать строку в файл.
Митя (28.12.22 16:10) [53]
Файлы бинарные - не стандартные изображения
Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i>
<u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)
Наверх 
Чтобы не потерять эту дискуссию, сделайте закладку