Загрузка библиотек

Mon Nov 25, 2013 4:40 pm

> По количеству компиляторов.

Можно увидеть исходные данных статистического исследования на основании которого было сделано это заключение? Я напр. не знаю ни одного компилятора, который бы умел создавать PE, но не умел COFF.

> Откуда взялось противопоставление времени компиляции и времени запуска? Какое отношение формат имеет ко времени компиляции?

Формат влияет на время запуска, так файл существующего формата (первые N байт в начале плоского файла) можно запустить быстрее, чем PE/ELF. И вопрос как раз был почему ты отдаёшь приоритет времени компиляции в ущерб времени запуска?

CleverMouse: читайте теорию до просветления, пока не поймёте, в чём отличие PE от COFF и какой из них приспособлен для компиляции нетривиальных проектов в один исполняемый файл. До тех пор вы забанены.

Mon Nov 25, 2013 5:26 pm

CleverMouse
Если основным форматом сделать PE, ассемблерщики будут поминать нас тихими, незлобивыми словами. Как им путь к экзешнику и командную строку получать ?

Mon Nov 25, 2013 5:30 pm

Пусть загрузчик запихнёт два указателя в стек перед вызовом entry point, если так уж не хочется писать API загрузчика.

Mon Nov 25, 2013 5:33 pm

Есть решение проще. Записать в регистры. Странно, что Вилле не додумался и мы до сих пор не использовали.

Mon Nov 25, 2013 6:32 pm

Serge wrote:Есть решение проще. Записать в регистры. Странно, что Вилле не додумался и мы до сих пор не использовали.

О! Вот это идея! Тогда получится, что точка входа -- это как бы процедура с параметрами? Элегантно.

Раз уж PE, как понимаю, избежать не удастся, есть два предложения:

Наряду с обычными PE позволять начинать файл сразу c PE-секции -- 'PE', 0, 0, чтобы можно без DOS-заглушки. Сэкономит минимум 64 байта, а со стандартыми заглушками -- 128 байт и больше.
Придумать константу IMAGE_SUBSYSTEM_KOLIBRI, либо в поля MajorVersion.MinorVersion писать что-то свое (0.7 или 0.8), чтобы Windows выдавала, что эти файлы не являются приложениями Win32.

Mon Nov 25, 2013 7:18 pm

Кстати да, будут загружать PE экзешники под windows со всеми вытекающими. И получать отсутствующие длл. И наоборот само собой.

Mon Nov 25, 2013 7:48 pm

Fanatic wrote:Наряду с обычными PE позволять начинать файл сразу c PE-секции -- 'PE', 0, 0, чтобы можно без DOS-заглушки. Сэкономит минимум 64 байта, а со стандартыми заглушками -- 128 байт и больше.

Это рюшечки. PE-заголовок можно сокращать, но сначала нужно сделать наконец поддержку PE - потом уже будет видно, какие поля загрузчик действительно использует, а какие просто занимают место.

Fri Apr 25, 2014 7:31 pm

Serge wrote:1. PE упрощает разработку драйверов на HLL. Создать обычным путём COFF драйвер из многофайлового проекта на Си очень проблематично.
2. Сгенерированный HLL компилятором COFF раздут из-за отладочной информации.
3. Ассемблерные PE и COFF драйвера примерно одинакового размера но COFF сложнее в загрузке.
4. PE загружается явно, с передачей командной строки.
4. Есть намерение в перспективе полностью перейти от COFF к PE.

Резюмируя всё, у COFF нет преимуществ перед PE нет, зато есть серьёзные недостатки. COFF - формат объектного файла, для исполняемого он плох.

Fri Apr 25, 2014 9:24 pm

Ассемблерные PE и COFF драйвера примерно одинакового размера но COFF сложнее в загрузке.

Ну PE, конечно, легче грузить http://websvn.kolibrios.org/blame.php?r ... 21#line-51

Только забыли положить рядом Си-шный исходник. А то не каждый сразу поймёт, что там за L20, L30, ... и что там за "магические" смещения такие.
Ладно бы там ещё http://websvn.kolibrios.org/filedetails ... c&peg=4421 такое с полпинка не напишешь.

И я не хочу сказать, что си — это плохо, но не нужно извращаться, а надо нормально прилинковывать.
Если уж что-то на asm сделать трудно, то почему бы и на си тогда не сделать.

Fri Apr 25, 2014 10:10 pm

Тогда надо сравнивать с этим http://websvn.kolibrios.org/filedetails ... 1#line-701 Писалось с нуля по документации.
Я делал оба загрузчика и на асме и на Си, так что могу сравнивать. И количество найденых ошибок в загрузчиках тоже можно сравнить.

Wed Oct 19, 2016 7:58 pm

Скопировал из чата:

//DG « Ср окт 19, 2016 7:03 pm » CleverMouse, как предполагается пользоваться kolibri.dll из \os? Есть какой-нибудь мануал?
CleverMouse « Ср окт 19, 2016 7:08 pm » //DG: предполагается, что она будет грузиться автоматически ядром
//DG « Ср окт 19, 2016 7:15 pm » Ок, а стандартные GetProcAddress есть или их надо тащить свои с программой? Это же PE DLL?
//DG « Ср окт 19, 2016 7:17 pm » И сейчас оно не грузится автоматом, верно? Мне нужен аллокатор, думаю прикрутить вместо kolibri.asm другой файл для формирования .obj; Динамические файлы obj шарятся между процессами как обычно?
//DG « Ср окт 19, 2016 7:19 pm » 68.19 грузит .obj бибилиотеки?
0CodErr « Ср окт 19, 2016 7:20 pm » Ну вообще, если мы планируем сохранять обратную совместимость, то должна быть возможность грузить библиотеки с помощью SysFn68.19 и получать указатель на таблицу экспорта DLL
0CodErr « Ср окт 19, 2016 7:20 pm » //DG: да, 68.19 грузит .obj
//DG « Ср окт 19, 2016 9:23 pm » Если перелицевать \os под .obj тот же функуионал останется, только ее станет возможным грузить через 19ф. Пожалуй, возьму этот аллокатор. Теперь осталось изучить ваш процесс сборки (кто-нибудь может меня ткнуть носом в документ?)
CleverMouse « Ср окт 19, 2016 9:24 pm » //DG: прямо сейчас загрузить транковым ядром kolibri.dll как есть вообще нельзя
CleverMouse « Ср окт 19, 2016 9:24 pm » когда-нибудь будет можно
//DG « Ср окт 19, 2016 9:24 pm » "получать указатель на таблицу экспорта DLL" Мне казалось, что у obj она всегда вначале... Где этот формат описан?
//DG « Ср окт 19, 2016 9:25 pm » CleverMouse: а какие там ограничения? Просто ядро не грузит еще ПЕшки или есть какие-то подводные камни, если я буду под .obj переделывать?
CleverMouse « Ср окт 19, 2016 9:30 pm » просто ядро не грузит PE, подводных камней вроде нет
0CodErr « Ср окт 19, 2016 9:31 pm » CleverMouse: а это что делает? http://websvn.kolibrios.org/filedetails ... peload.inc
CleverMouse « Ср окт 19, 2016 9:32 pm » 0CodErr: это для драйверов
0CodErr « Ср окт 19, 2016 9:32 pm » CleverMouse: хм, странно, PE ведь же тоже.
0CodErr « Ср окт 19, 2016 9:34 pm » CleverMouse: а что насчёт обратной совместимости при загрузке SysFn68.19 в будущем
CleverMouse « Ср окт 19, 2016 9:38 pm » 0CodErr: PE DLL не нужно грузить функцией ядра. PE DLL нужно грузить вызовом одной из функций userspace-компонента kolibri.dll
0CodErr « Ср окт 19, 2016 9:41 pm » CleverMouse: ну, хорошо, вот смотри, в той же винде можно делать loadlibrary+getprocaddress. В Колибри так нельзя будет?
CleverMouse « Ср окт 19, 2016 9:42 pm » 0CodErr: так и будет, только loadlibrary/dlopen - это не вызов ядра, а функция в userspace
0CodErr « Ср окт 19, 2016 9:43 pm » CleverMouse: а, ну понятно. То есть, 68.19 для PE работать не будет?
CleverMouse « Ср окт 19, 2016 9:44 pm » 0CodErr: нет, не будет
0CodErr « Ср окт 19, 2016 9:45 pm » CleverMouse: а останется ли поддержка MSCOFF библиотек?
CleverMouse « Ср окт 19, 2016 9:47 pm » 0CodErr: на переходный период - да, только шаринг страниц между разными процессами перестанет иметь место для COFF, его неудобно поддерживать для COFF и PE сразу

Wed Nov 01, 2017 1:04 am

Girls and guys,

AFAIK from forums and chat logs a patch by CleverMouse implements all we need for PE. It is also a non-breaking change for existing applications. I rebased the patch to current svn trunk, checked and attached it.

Is there any reason to not merge? Anything to discuss? We could finish transition to PE this year.

Thu Nov 02, 2017 6:00 pm

"Non-breaking change" - не совсем верно: для приложений изменения действительно прозрачны, но патч ломает разделение физической памяти под копиями COFF-библиотек в разных процессах.
"all we need for PE" - совсем неверно: то, что есть, должно работать, но некоторых важных вещей нет. В порядке убывания важности:
* вызов DllMain при загрузке/выгрузке DLL
* static TLS (__declspec(thread) в msvc / __thread в gcc / _Thread_local в стандарте C11)
* возврат из главной функции процесса должен приводить к завершению всех потоков процесса, а не только главного. Конфликтует с текущей реализацией консоли, поэтому окно консоли надо выносить в отдельный процесс - заодно позволит сделать консоль, разделяемую между несколькими процессами
* биндилка импортов для автосборки

Wed Sep 19, 2018 5:34 pm

Интересный вопрос насчёт иконок в StrippedPE.
Директория ресурсов, как я понял, предусмотрена.
Если хранить иконки там, то чтобы их оттуда достать(чтобы отобразить где-то) придётся сначала распаковать файл.
Так как приложения у нас в данный момент не имеют расширения, то может получиться, что пред нами не приложение, а файл с какими-то данными(не важно), размером эдак 100Мб.
В той теме http://board.kolibrios.org/viewtopic.php?f=26&t=3621 я пытался кое-что придумать, но видимо никому больше это не нужно.

Просто интересно, как планируется работа с ресурсами, в частности с иконками.

Sun Apr 26, 2020 5:10 pm

Q for masters: how can OS share DLL between processes if in different ones the DLL may be loaded in different base addresses (and relocated, so that code of DLL in address space of App1 differs from code of DLL in App2's address space).

I get the result on Windows: if some conditions are met, HMODULE of the same DLL in different apps may be different. Does it mean that Windows does not share DLL between apps or may sometimes have several instances of it loaded?

Загрузка библиотек

Who is online