Board.KolibriOS.org

Есть желание создать полноценный сабж и по мере возможностей поддерживать его в актуальном состоянии. Поскольку Дельфи не может компилировать в формат Колибри, придётся сделать поддержку PE. План следующий:

• создаётся Kolibri.pas, аналогичный Windows.pas на небезызвестной платформе - это делаю я
• создаётся загрузчик PE, позволяющий загружать любые PE-файлы (не только написанные на Дельфи) - это должен сделать кто-то из вас
• совместными усилиями создаётся PE-модуль, реализующий (хотя бы заглушками) некоторые критичные для Дельфи системные функции

Когда эта байда начнёт работать, можно/нужно интегрировать запуск PE-модулей в KFar и прочие приложения Колибри. Короче, сделать PE одним из официально поддерживаемых форматов исполнения и включить в официальный дистрибутив.

У меня личный интерес - превратить Колибри из теоретической в практическую legacy-платформу для Единой среды. Исходники Delphi SDK для Колибри будут распространяться по лицензии KOL (кто знает, какая у Кладова лицензия?).

Разобраться с примером запуска PE автора Pascal Pro не смог - такой я тупой.

>> кто знает, какая у Кладова лицензия?
Вроде GPL

Вот только зачем меня устраивал mpc от mike.dld, только доделать бы его..

Помойму одним Kolibri.pas не обойтись, дело в том что что system завязан на виндоусе. Так что тут либы system переписовать. Либо портировать три десятка функций.

Pavia wrote:Так что тут либы system переписовать. Либо портировать три десятка функций.

Ты меня учишь? System переписан у Кладова. Если PE будет, можно даже разные GetTlsValue и RtlUnwind поотключать и посмотреть, как будет.

Проще подправлять (релинковать) уже готовые, маленькие PE имиджи
чуток доработать DOSHACK, прописать сигнатуру в DOSHEADER и делов, а то загрузщик PE - это реальная волокита.. http://forum.sources.ru/index.php?showtopic=184453

N†OSKRNL, большое спасибо за твои system.pas и sysinit.pas!
Они мне очень пригодились!

Хочется узнать, как двигается проект?
Нашел утилиту PE2Kos - не работает. Написал свою на делфи.
Начал пробовать. Окно создается. Но хочется иметь возможность работы со строками и объектами - system.pas нужет.

Продолжаем тему.
Тут вопрос как лучше.
Дельфи использует регистр EBX на свое усмотрение, поэтому его нужно сохронять.
Как лучше через стэк За частую один регистр не используется может тогда использовать Сейчас колдую над GetMem и FreeMem, если удасться тогда строковые функци и деномическии можно будет добавить. Пока не использую дельфийский мэнеджер памяти.
Также взял kolibry.pas из ppro. Ищу ошибки и правлю также добовляю сохронение EBX и других регистров. EAX, ECX, EDX - не требуют сохронения.

Pavia
Пересылка из регистра в регистр всегда быстрее, чем пересылка между регистром и памятью. Другой вопрос, что не всегда удается это использовать, потому что обычно все регистры уже заняты.

павея, дельфи мемори менеджер, реализован довольно усложненно, из за чиво обьем проги возростает.. а так есть несколько версий (D2/D7) которые так или иначе упруццо в вендовые функции Heap/VirtualAlloc, HeapFree, etc... Поэтому здесь наверно стоит особо не извращаться, а просто сделать переходниг Win32api ->int 40h

Delphi активно юзает EBX для обращений к переменным,массивам в том числе и локальным... Ну а насчет "регистры Vs стек", здесь быстродействие падает не столь уж и существенно, и на мощных (от 200мгц) компах на это можно забить-достаточно глянуть, что в венде твориццо на stdcall вызовах..

В основном дельфи использует EBX как указатель на объект. Сделал везде через стэк.
Насчет мемори менеджера, пока думаю как лучше сделать. Пока черновой вариант, просто вызываю функции из ядра которые выделяют страницы. Через чур расточительно. Функции колибри ограниченны. Я думаю проще написать свои функции выделения и освобождения памяти. Вот только разберусь как функции колибри функционируют 68.12 и 68.13. А то не понятно, что делать если освободить блок по середке. Как его потом заново проинциировать. Новерно освобождать можно только с верхушки.

Пока займусь, работай с файлами, а после вернусь к мэнеджеру памяти.


Тут пытался добавить классы. Они там столько понаворатили, застрял где-то на ReallocMem. Зато с объектами можно работать.

Может кто хочет помочь?

Посмотри как сделанно в FP, может поможет. Я без проблем, вроде, сделал работу с памятью для FP. Когда занимался переносом RTL.

..bw

Всего пять лет каких-то прошло, фигня вопрос...

За это время я успел разочароваться в возможностях встроенного компоновщика Delphi, но потом, не помню уже, когда точно, нашлось обходное решение.

Алексей Хмельнов из Института динамики систем и теории управления Сибирского отделения РАН разработал декомпилятор dcu-файлов -- dcu32int. Мне давно хотелось с ним поиграться, но получилось только сейчас. Так родилась "Пифия" -- препроцессор int-файлов, генерируемых dcu32int, в asm-файлы синтаксиса FASM. Полученные ассемблерные исходники штатно собираются FASM-ом как из-под Windows, так и из-под самой "Колибри".

Опыта разработки под "Колибри" у меня никакого, поэтому добиться работоспособности тестовой программы мне не удалось, а библиотеку даже не тестировал. Возможно, пример неудачный подобрал, не знаю. Решил выложить что есть, вдруг снова на 5 лет пропаду?

Если тут есть фанаты Delphi, можете поиграться. Уже понятно, что под "Колибри" придется писать код специально, но путей разработки на Паскале под "Колибри" стало на один больше. Даже ООП должен сработать, а если немного поколдовать, то и VMT организовать можно. Время бы...

За это время я успел разочароваться

Delphi 6 не умеет собирать программы с Image Base = 0, а obj-файлы у него -- уже не обычный OMF

А версия 6 это принципиально? В Delphi 2.0(и, наверное, в третьей тоже, но не пробовал) получается нормальный omf, который потом можно сконвертировать в coff, а затем ld + objcopy --> kex.

0CodErr wrote:А версия 6 это принципиально?

Оказалось, что да. В обычной разработке я активно пользуюсь, как минимум, перегруженными функциями (overload). Без них никак, на них весь API построен. Попробовал было собрать свои исходники 3-й версией dcc, которую тут кто-то выкладывал, -- спотыкается как раз на overload.