Board.KolibriOS.org

k@sTIg@r wrote:Посмотри на некоторые приложения колибри такие как сетап, настройка сети и т.д. Уже есть libGUI но никто не спешит переводить их под эту библиотеку. Зато на форуме присутствует много людей которые с удовольствием это сделали будь визуальная среда разработки, т.к. асма боятся как огня.

Я сильно сомневаюсь, что это действительно полезно. Визуальные среды, как я уже говорил, любят пихать кучу своего кода, который далеко не всегда необходим. Вот именно то, что с появлением подобных сред куча народу бросится на написание новых приложений и "улучшение" существующих, которое запросто может привести к разбуханию всего чего можно и нельзя (как по размеру, так и по количеству действий).

diamond
TLS в Колибри пока нет, а bound import можно сделать, хотя сейчас в этом нет необходимости. Кстати он использует "ненужное" поле TimeDateStamp.

Импорт с привязкой (Bound import) – это вид импорта, при котором предполагается, что для определенной версии модуля, содержащего импортируемый символ, адрес символа уже известен к моменту компиляции.
Это относится, главным образом, к системным библиотекам, которые загружаются в память всегда с одного и того же адреса для данной версии библиотеки. В таком случае в таблицу импорта модуля, импортирующего такой символ, можно заранее, еще до загрузки модуля, записать предполагаемый адрес символа.
При этом для обеспечения контроля версии модуля, к которому привязан данный, при осуществлении привязки создается дополнительная таблица информации о привязанных модулях, на которую ссылается поле ForwarderChain. В поле TimeDateStamp помещается отметка времени модуля, содержащего символ (это значение поля TimeDateStamp из PE-заголовка этого модуля).
Существует так называемый “новый стиль” привязки; в этом случае TimeDateStamp= -1, а таблица информации о привязках доступна через элемент IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT каталога PEHeaders.OptionalHeader.DataDirectory.

Serge wrote:Кстати он использует "ненужное" поле TimeDateStamp.

...у динамических библиотек...

...сделайте возможность подключения PE DLL в пользовательских приложениях, это ведь не очень сложно.

Если DLL должны не просто динамически присоединяться, но еще и совместно использоваться после загрузки, то это довольно сложно.

Хочу высказать свое мнение. PE-формат - это свалка информации и если вы подсядите на него, то вас затянет по полной. Не понятно, почему за обсуждением PE никто не обратил внимание на упомянутый и также весьма распространенный ELF.EXE. В этом случае ELF.OBJ можно использовать в качестве RTL.

Phantom-84

Я об этом уже писал.
Во-первых не все компиляторы поддерживают elf. В Win мне удалось скомпилировать elf.exe Ваткомом но в очень усечённом и несколько странноватом виде. Сделать elf c динамической линковкой или расшареный видимо можно только в *никсах.
Во-вторых позиционно-независимый код в elf занимает больше места и работает медленнее потому что процессоры отслеживают пары вызовов call/ret, а конструкции
call $+5
pop ebx
сбивают внутренний стек возвратов. Наконец в ia-32 регистров и так кот наплакал а здесь теряется ещё один. Мусора при желании в elf можно найти не меньше чем в PE и это скорее зависит от компоновщика. ld даёт компактные PE файлы если его правильно настроить. Количество секций в elf.so приближается к двадцати, больше чем в pe. Единственное преимущество elf.so перед pe.dll то что загруженные секции кода в одном процессе можно отобразить на любой адрес в другом процессе, но это и не так важно для системных библиотек. Если они загружаются в общую память то конфликта адресов не будет, а небольшие частные библиотеки можно и не расшаривать.
Наконец загрузка elf.so сложнее чем pe.dll, это играет не последнюю роль.

Понятно, что компиляторы под Windows в первую очередь ориентированы на PE. Но кто мешает компилировать под никсами? Использование регистра ebx - это скорее заморочка компилятора. В самом формате такого нет. Там главное, чтобы адреса не были короткими, т.е. если к примеру я сохраняю в стеке адрес, то мне в исходном коде нужно использовать не короткую инструкцию push const (2 байта), а длинную (5 байт). К тому же я говорил не о формате ELF.DSO, а о формате ELF.OBJ, т.е. чистом объектнике.

Phantom-84

Для большинства основная система пока что Win. Это приходится учитывать. Заморочка с ebx это неизбежная оптимизация иначе на каждое обращение к данным придется добавлять пару call/pop а это два лишних обращения к памяти и разболтанный стек. В целом это скорее проблема не компиляторов а генерации pic для процессоров ia32. В long mode данные адресуются относительно rip так что там изначально позиционно-независимый код, а значит пропадает последнее преимущество elf.so перед pe.dll
Обычно компиляция идёт по принципу один файл - один объектник. А в больших проектах много файлов и в один obj их собрать проблематично. Наконец в первую очередь выбирался формат для ДЛЛ с учетом автоматической линковки при загрузке приложения, а здесь pe имеет преимущества перед elf.so в простоте. На мой взгляд гибкая структура elf привела к тому что его слишком перегрузили разными секциями и парсить их стало сложно. Что касается преимущества позиционно-независимого кода elf.so то в Колибри его нет.

Возобновляю тему...

[url]svn://kolibrios.org/kernel/branches/kolibri_pe[/url]
Планируется постепенная и очень серьёзная переделка ядра

- единый ABI для Asm и C кода
- новый менеджер страничной памяти
- улучшенный менеджер виртуальной памяти
- разделяемые память и dll
- перенос части ядра в user-mode
- новый загрузчик приложений с поддержкой PE
- планировщик
- новая организация процессов и потоков
- гибридное микроядро
- SMP
- загрузка GRUB-ом
- перевод ядра в PE DLL
- раздельная компиляция fasm/mingw и сборка ядра ld
- Колибри 64

Звучит как логическое продолжение Колибри. Мне как юзеру и недалёкому программисту важна:
1. совместимость с уже написанными прогами
2. синхронизация с trunk

Leency

Совместимость будет, но не 100%. Захват IRQ из приложений, COFF obj и тому подобные вещи останутся за бортом.

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

Код ядра работающий в pl0 сильно уменьшится. В режиме ядра останется только управление памятью, синхронизация, планировщик/процессы/потоки/IPC, обработка прерываний.

Драйверы/cервисы останутся в общей памяти ядра но перейдут в pl_1 с iopl_0, так что всеми любимая синхронизация cli/sti накроется gpf.
Это не так "микроядерно" как сервисы в user-mode, но быстрее и избавляет от большинства проблем с доступом к данным из разных адресных пространств.

Значительная часть ядра в том числе загрузчик приложений и нынешний int 0x40 перейдёт в pl_3 в виде api.dll. При этом код ядра и api.dll будет собираться в одну DLL.

Первые пункты вплоть до планировщика можно реализовать относительно быстро. БОльшая часть этого кода уже готова. Остальное - перспективный план на будущее.

Serge
Отличные новости! Хочу поучаствовать в работе!
Недавно разобрался с APIC (IPI и таймер), думал внедрять по маленьку в ядро SMP, попутно встал вопрос с планировщиком. Модернезировать текущий для работ с несколькими процами, это так сказать работа "на от**ись", нужно уже приоритеты/балансировку вводить. IPC тоже требует разработки, без тех же спинлоков (мьютексы/барьеры/семофоры реализуются через спинлоки) на уровне ядра в SMP не обойтись...
Кроме того часть кода ядра просто стоит переписать более оптимально и с использованием соременных средств (mmx/sse/etc, смешно уже тянуть направленность на старые машины, и требывать небывалой производительности, это думаю все понимают) Да и просто часть кода ядра (в основном касаемый сис.функций), должен быть на свом месте - в либах...
В общем фронт работ большой, думаю нужно по этому поводу более детально пообщатся. Или в PM или на мыло или тут (как модератор, всех предупреждаю : за флейм буду карать, давайте по существу)

P.S. про Колибри 64, смотрел с месяц назад код Menuet64 (да простит меня Вилли), в общем ничего сложного в нем нет, ибо ядро как было IA32 так им и осталось (compatible long mode))), изменений минимум, проделать тоже самое с Колибри думаю не составит труда...

Ghost

Отлично.

ИМХО общаться лучше здесь, пусть вся разработка будет открытой, а пустой треп надо удалять сразу. Отдельные узкоспециальные вопросы можно обсуждать в личке.

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

P.S. Отправил на мыло тест smp для trunk.

to All
Будет ли отделение blue screen кода от ядра? Будет ли поддержка обработки ini файлов при загрузке? Будет ли рам диск? Как он будет сделан? Он будет жестко прошит или будет формироваться при обработки ini файла?

Судьба blue screen туманна. Ядро будет грузиться GRUB-ом а опции прописываться в ini и командной строке ядра. Рам диск сохранится. В каком виде - можно обсудить. GRUB способен загрузить и нынешний kolibri.img как модуль (даже с дискеты если он туда поместится в gzip виде), и отдельные программы чтобы загрузчик ядра сам собрал из них рам диск. Я думаю что помещать на рам диск весь дистибутив не надо. Только самые необходимые файлы.