Для облегчения портирования приложений с VCL на KOL можно использовать написанный мною адаптер VCL2KOL (это пока ещё демо-версия и её необходимо дорабатывать). Мною ставилась задача лишь показать возможность создания подобных библиотек.
Исходники скачать можно здесь: http://chess4net.ru/Upload/VCL2KOL.zip

There is also KOL Convertor http://krazz.net/retnyg/kolconv.htm

Хочу подчеркнуть, что VCL2KOL - это не конвертор, а адаптер, VCL2KOL.dpr - это демонстрационный проект на основе адаптера.
Т.е. если вы измените в настройках проекта VCL2KOL.dpr

SearchPath=.\KOL;.\VCLHlp;$(DELPHI)\source\rtl\sys
на
SearchPath=

то VCL2KOL.dpr будет компилироваться как обычное VCL приложение.

да, прикольный адаптер. Только работы довольно много получается. Тут уже работал один человек на похожим проектом - вставляем в uses один модуль и он  подставляет вместо VCL компонентов обертки реализующие KOL компоненты.
сделал он немного, но то что сделал вроде работает. Я не следил за его работой пристально.

это был BaryVetal, но что-то я не нашел нифига в инете, зато нашел в своих закромах.
он диплом вроде писал по этому адаптеру - чтобы можно было одним мановением бац - и уменьшить объем ехе-шника.

выложить?

Да, выложи,
Пожалуйста.:)

вот, качать здесь
http://slil.ru/28523966

не знаю насколько это последняя версия, может намыльте самому автору?
barilkovetal на майл.ру

Большое Спасибо:)

Во время исследования VCL и написания VCL2KOL, я обратил внимание, что exe-шник растёт в размерах при добавлении в код модуля Variants, либо тех модулей, которые его за собой тянут.
Как известно считывание форм в Delphi основано на чтении информации из DFM-файлов при помощи механизма потокового считывания и использования RTTI (см. TReader), т.е. априори, когда программа компилируется, smart-linking не может распознать классы VCL-контролов, код которых заведомо можно исключить. Следовательно EXE-шник "пухнет".

В KOL совершенно иной подход к созданию визуальных контролов - они создаются статически (в плане компиляции) и лишний код не прилинковывается.

Я думаю, что для уменьшения кода самой VCL необходимо провести сл. операцию со стороны среды Delphi:

DFM -> <код для создания формы> -> вставка <кода для создания формы> в программу на Delphi.

При этом необходимо исключить из системных классов весь механизм из потокового считывания DFM.

Кто-нибудь сталкивался с подобной проблематикой?

О, еще помнят люди мой труд :)

Четно говоря я свою программу потерял, так что спасибо Barloggg ;)

Гладя сейчас на эту программу, хочу сказать, что я бы сейчас написал ее по другому...


> Я думаю, что для уменьшения кода самой VCL необходимо провести
> сл. операцию со стороны среды Delphi:DFM -> <код для создания
> формы> -> вставка <кода для создания формы> в программу
> на Delphi.При этом необходимо исключить из системных классов
> весь механизм из потокового считывания DFM.


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

Разработчики Delphi изначально пошли, как мне кажется, немного не тем путем... Они используют технологию "умное связывание" smart linking кажется так называется. Так вот основная идея была такая, что давайте в код включим все, т.к. возможно из другой программы будут работать с нашей например через механизм OLE, и пусть наша программа не использует почти все что в нее запихано - это может пригодиться другой, которая будет работать с нашей...

Это конечно здорово, но программ, которые так работают очень мало. Было бы не плохо по возможности указывать опцию включать smart linking или нет.

А вообще, если бы я писал программу сейчас, я бы потпытался разбирать родительские классы используемых классов (не только контролов) VCL и выбрасывать все переменные, процедуры и функции которые фактически нашей программой не используются, ну например, если в контролах не задействовано свойство Tag, то можно проанализировать все классы которые используют Tag и выбросить все связанное с Tag. После этого скопировать переработанные модули в др. папку переименовать и использовать в нашем проекте. После этого однозначно будет результат. И фактически мы ничего не теряем в фунциональности. Хотя опять же как ни крути, но DFM разбирать надо и переделывать создание контролов в run time.

На данный момент я пересмотрел свое мнение, по поводу, использования в реальных программах библиотек типа KOL. Т.к. эта необходимость в настоящее время отпала в виду компьютерных мощностей, размеров HDD  и памяти. Что программист выигрывает от их использования? Ну предположим, суммарно в папке с проектом будет не 10 а 1 Мб и работать будет чуть быстрее и что? Эту разницу особе не заметишь на современном компьютере. А вот удобство разработки страдает и не поможет тут KOL и MCK... Т.к. не сможешь юзать ничего из VCL, а следовательно всякие Fast Report, TMS-компоненты и DevExpress и т.д. уже не сможешь использовать...

Нет, мне кажется, это совсем не smart linking. Smart linking как раз используется KOL, когда не подсоединяется код, который реально не нужен. По крайней мере, я так понял, что такое smart-linking, на начальном периоде создания KOL. И теперь на просторах русскоязычного и-нета уже бесполезно пытаться найти оригинальное определение, все ссылки на меня. В англоязычном я нашел что-то:
http://blogs.embarcadero.com/abauer/2009/05/29/38888
The Oracle at Delphi, Better smart-linking through class construction, цитата:
...Long time Turbo Pascal and Delphi programmers have always taken for granted the smart-linker and its ability to ensure that only the code that was "touched" is what is actually linked into your final application.

Если только это не перевод с русского, и автор опять же воспринял мое понимание smart-linking'а. Вполне возможно, что в оригинале под smart-link понималось именно динамическое связывание через Variant'ы.

Кстати, нашел пару намеков, что smart-linking действительно можно отключать в опциях Delphi (dcc). Никто не в курсе, о чем речь? (Может, я не в ту версию Delphi смотрю).

BaryVetaL


> На данный момент я пересмотрел свое мнение, по поводу, использования
> в реальных программах библиотек типа KOL. Т.к. эта необходимость
> в настоящее время отпала в виду компьютерных мощностей,
> размеров HDD  и памяти. Что программист выигрывает от их
> использования? Ну предположим, суммарно в папке с проектом
> будет не 10 а 1 Мб и работать будет чуть быстрее и что?
> Эту разницу особе не заметишь на современном компьютере.
>  А вот удобство разработки страдает и не поможет тут KOL
> и MCK... Т.к. не сможешь юзать ничего из VCL, а следовательно
> всякие Fast Report, TMS-компоненты и DevExpress и т.д. уже
> не сможешь использовать...


Дело даже не в Delphi + VCL, а в FPC, Lazarus (LCL) и программировании для мобильных устройств. Там действительно ещё требуется компактность исполняемых файлов. Т.к. реально сейчас ни один Паскаль-компилятор, кроме FPC (в FPC кстати есть возможность отключения опции smart-linking), не предлагает возможности компиляции программ под ARM-процессоры и нету альтернативы LCL (Lazarus Component Classes), то мой выбар пал на KOL (точнее порт этой библиотеки, выполненный Юрием Сидоровым). Но портирование VCL проектов на KOL вызывает определённые сложности, в особенности при работе с графикой. Здесь ещё надо взять в расчёт время, которое тратится на переписывание кода, отладку и регресс-тестирование. Времени уходит много а заказчики ждать не любят. Адаптер VCL2KOL появлился именно под влиянием идеи уменьшения времени адаптации кода VCL (LCL) к KOL-условиям.

По поводу оптимизации генерируемого бинарного когда я думаю, что имеет смысл "повозиться" с open source(ным) FPC и реализовать идеи наподобие http://blogs.embarcadero.com/abauer/2009/05/29/38888 в нём. По крайней мере это буде быстрее и полезнее для a) своих целей, b) Возможно целей сообщества Паскалистов.

SmartLink-ом в Delphi изначально назывался механизм, который позволяет исключить из бинарника заведомо неиспользуемый код. DCU-файлы содержат все скомпилированные процедуры. ОбычныйLink подразумевает включение его целиком в Exe.

SmartLink реально работающая тема как в Delphi так и в FPC. Насколько мне известно, и в Delphi и в FPC регулируется ключом.

Но есть одна проблемка. Как определить, какой код, точно не потребуется при работе? Поскольку VCL и LCL сейчас полностью опираются на RTTI, получается, что любой published-член считается используемым в проекте, даже если явных ссылок ни в pas ни в dfm файлах нет. Теоретически, например, приложение может прочитать имя свойства из файла, и обратиться к нему через RTTI, что собственно и делает например сама Delphi в Design-time.

Чтобы увидеть smartlinking во всей красе, нужно отключить RTTI. Мне видется это примерно так:

1. Убираем у класса TPersistent ключик {M+} , чтобы все published члены стали public.
2. Модифициеруем TComponent (ну и все, что с этим придется) так, чтобы вместо восстановления из потока, вызывался специальный внешний метод, который ...
3. Генерится из dfm-файлов, и включается в основной исходник через include