Board.KolibriOS.org

Official KolibriOS board
It is currently Wed Oct 23, 2019 4:14 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 124 posts ]  Go to page Previous 1 2 3 4 59 Next
Author Message
PostPosted: Wed Oct 24, 2007 6:32 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
Serge> но очень вероятно что он не загрузится в Win
Serge> адрес приложений в Колибри 0x0000 а в Win 0x400000
Ну вроде сам то формат легально поддержичает эти фичи. Если винда не работает с ними, то это её проблема :-).

..bw


Top
   
PostPosted: Wed Oct 24, 2007 6:47 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
andrew_programmer

MS COFF остаётся, а вообще coff легко линкуется в PE DLL


Top
   
PostPosted: Wed Oct 24, 2007 7:21 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
1. DLL - это аббревиатура от Dynamic Linking Library и не подразумевает никакого формата файла.
2. Если сделать загрузку PE-файлов как бинарников Колибри, сразу же возникнет путаница Колибри-бинарников и Windows-бинарников. И посыплются куча вопросов "а чего оно не запускается" и хотелок "ну PE-екзешники вы же загружать умеете, как насчёт загрузки Windows-программ?" А уж как расстроятся линуксоиды...
3. Сравните формат PE и "формат" MENUETxx. Посчитайте размер заголовков, количество лишних/ненужных/неиспользуемых полей/областей и только потом продолжайте предлагать подобные идеи. Напоминаю, что Колибри позиционируется как маленькая и быстрая ось.
4. Колибри позиционируется также как система, большая часть которой написана на ассемблере. Нафига в ассемблерных программах (которых большинство и, я надеюсь, останется большинство) вообще какие-то обёртки для всех API? Банальный "int 0x40" короче и быстрее.
5. Желающим видеть программы, валидные одновременно и в Колибри, и в Windows: все системные программы и все файловые менеджеры написаны на ассемблере и напрямую используют системные вызовы. Выкиньте их - и что останется? Портированные вещи типа doom и dosbox? Знаете ли, их Windows-версии всегда будут работать лучше Колибри-версий, запущенных под Windows. А свои программы в любом случае можно писать так, чтобы их можно было скомпилировать и как Kolibri-программу, и как Windows-программу (@rcher тому пример).
6. tcc как раз-таки генерирует формат MENUET01.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Thu Oct 25, 2007 12:03 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
1. Да DLL это только буквы и с форматом никак не связаны.
Наверное поэтому разговор о DLL шёл несколько лет без всях результатов. Интересующиеся вопросом могут посмотреть тему. Своих форматов для DLL так никто и не разработал. Тем более что ещё нужны инструменты для работы с новым форматом.

2. Хотелки будут всегда. Их количество определяется числом новичков узнавших о системе и больше связано с распространением новостей о системе чем с её возможностями и внутренним устройством.

3,4 Да PE и ELF содержат много дополнительной и "ненужной" на первый взгляд информации. Но когда начинаешь делать загрузку по произвольному адресу и с защитой памяти эта ненужная информация становится просто необходимой. Для примера: сейчас код ядра вообще никак не защищён от затирания. Достаточно ф.70.0 считать 128Кб по адресу 0х80010000 чтобы затереть всё ядро. И сделать такую защиту практически невозможно потому что код ядра перемешан с данными - следствие "компактного и не отягощённого всякими ненужными полями" raw формата ядра. Что касается размера файлов то чем больше модуль тем меньше процент накладных расходов, а упаковка вообще сводит их к минимуму.

Никто не предлагал делать обёртки системных вызовов для асм-программ. Речь шла о едином API для ЯВУ. Впрочем никто и не запрещает такими обёртками пользоваться. Кому как нравится.

Похоже что в конечном счёте все упирается в вопрос о "чистоте системы". Для Вилле это был принципиально - в МеОС всё должно быть написан на асме. В Колибри если я не ошибаюсь так вопрос никогда не стоял.


P.S. Две цитаты:

Vlad G. Maslakov 21 май 2005 16:26
Quote:
А что, если попробовать интегрировать возможность реализации DLL в ядро? Тогда к DLL обращаться через IPC будет не сложно, но проблема в передаче параметров. После реализации открываются большие перспективы для MeOS как модульной системы (а не так, что все ядро одним файлом).

mike.dld 21 май 2005 16:56
Quote:
Приблизительно так и должно быть. И в любом случае так будет. Но не сейчас. Я могу свободно представить себе, насколько возрастёт потенциал ядра с введением DLL, но делается всё не в один день.


Top
   
PostPosted: Thu Oct 25, 2007 12:22 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Serge wrote:
Да PE и ELF содержат много дополнительной и "ненужной" на первый взгляд информации. Но когда начинаешь делать загрузку по произвольному адресу и с защитой памяти эта ненужная информация становится просто необходимой.

Начинаем разбирать описание формата PE.
В начале файла идёт DOS-заголовок и DOS-заглушка. Абсолютно ненужные и неиспользуемые. Уже получаем минимум 0x40 (а обычно в пару раз больше) лишних байт.
Далее,
Code:
typedef struct _IMAGE_NT_HEADERS {
    DWORD Signature;
    IMAGE_FILE_HEADER FileHeader;
    IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;

Ну сигнатура - это понятно. А вот дальше
Code:
typedef struct _IMAGE_FILE_HEADER {
    WORD    Machine;
    WORD    NumberOfSections;
    DWORD   TimeDateStamp;
    DWORD   PointerToSymbolTable;
    DWORD   NumberOfSymbols;
    WORD    SizeOfOptionalHeader;
    WORD    Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;

Из 20 байт 12 (TimeDateStamp, PointerToSymbolTable, NumberOfSymbols) ненужны и не используются! Продолжать?
Quote:
Для примера: сейчас код ядра вообще никак не защищён от затирания. Достаточно ф.70.0 считать 128Кб по адресу 0х80010000 чтобы затереть всё ядро. И сделать такую защиту практически невозможно потому что код ядра перемешан с данными - следствие "компактного и не отягощённого всякими ненужными полями" raw формата ядра.

Ну, допустим, кто-то выделил абсолютно все переменные в блоки iglobal/uglobal, отделил начало данных от конца кода и сделал все страницы кода доступными только на чтение. Тогда функцией 70.0 можно считать 64 Кб по адресу 0x80000000 - и всё равно можно давить Reset, потому что вместо важных системных данных появляется каша. И формат ядра тут ни при чём. Такая защита от плохих приложений делается по-другому, проверками указателей, независимо от атрибутов страниц.
Serge wrote:
Никто не предлагал делать обёртки системных вызовов для асм-программ. Речь шла о едином API для ЯВУ.

А мне почему-то показалось, что пост
k@sTIg@r wrote:
Если я правильно понимаю, то теперь можно будет реализвать dll в которой будут обертки для системных вызовов колибри. Реализовать такую же для винды. И полноценно пускать и там и там?

именно это и предлагает. И чистота системы тут ни при чём.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Thu Oct 25, 2007 2:26 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond

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

Я не утверждал что ненужных нам полей там вообще нет. Но их процент невелик. Для примера килобайтный заголовок bochsdbg.exe 2.3.5 составляет 0,045% от всего файла. Это приемлимо или нет ?
Для ac97snd это 1.02%. Упакованный win-екзешник весит 23 543 байта а колибри 23 478 байт. И того разница в 65 байт или 0.28% от окончательного размера бинарника.
Quote:
Такая защита от плохих приложений делается по-другому, проверками указателей, независимо от атрибутов страниц.
Разумеется ты прав. Ничто не защитит данные ядра от затирания самим ядром. Но это врождёный недостаток ядра вообще и к сожалению не последний.
Такие вопросы должны решаться ещё при проектировании системы в том числе и о проверках параметров. Только никто этих проверок не делает и я в том числе. Большинство вызовов записывающих данные по указателю могут записать их куда угодно.
Но сделать эффективную защиту от пререзаписи расшаренной DLL можно а для этого нужны таблицы секций и их атрибуты то есть те самые "лишние" поля. Если у тебя или ещё у кого-нибудь есть время на разработку такого формата с релокациями, динамическим связыванием и прочими современными наворотами то у меня его нет и нет желания его разрабатывать. PE я выбрал потому что он проще и доступней. Скомпилировать расшаренную .so мне удалось только в Linux, позиционно независимый код выглядит довольно громоздким а его загрузка не самым простым процессом. Тем кто интересуется вопросом рекомендую поискать в сети книгу "Linkers and loaders". Вообще загрузчик PE побочный продукт другой работы и написан на С. Просто появилась возможность встроить его в Колибри и я решил её использовать. Весь код находится в файле peload.inc и остальным ядром пока не используется. Если большинство считает что нам PE длл и екзешники не нужны, или кто-нибудь придумает новый компактный и замечательный формат, файл можно безболезнено удалить.

Если кому-то хочется сделать DLL с эмуляцией вызовов Колибри под Win и наоборот, то флаг в руки. В чём вообще проблема? Будет ещё один эмулятор.

Что касается "sys.dll" то повторю ещё раз: я предлагаю сделать библиотеку с единым API системных вызовов для программ на С и Паскале (если получится) IMHO такая интерфейсная библиотека избавит от необходимости каждому изобретать свои версии draw_window, ksys_draw_window, kos_draw_window и т.п. и дополнительно проводить проверку параметров о которой забыли разработчики ядра, а так же фиксить некоторые особенности системы. Сам я на асме больше кодить не буду так что простоту вызовов int 0x40 оценить не смогу а вот длл с API представляется очень полезной.


Top
   
PostPosted: Thu Oct 25, 2007 10:43 am 
Offline

Joined: Wed Feb 21, 2007 3:03 pm
Posts: 188
diamond, я не подразумевал перевести все программы в формат PE и подсадить их на "sys.dll". Я всего лишь спрашивал, реально ли такое провернуть. Извини может я не правильно выразился.

Я полностью поддерживаю идею с поддержкой PE. А также единой библиотеки для ЯВУ.
1. Она ни кому не мешает
2. Она ни кого не заставляет переходить с формата MENUETxx или COFF на PE.
3. Никто никого не заставляет потом PE-файлы пихать в дистрибутив, так что лишнее место никто не зохавает.
4. Упрощает разработку софта под колибри, а собственно и к-во разаработчиков.
Единственный минус, который повлияет на ядро/дистрибутив - это увиличится размер ядра.
Но и тут есть выход, я думаю без проблем влепить опцию которая будет компилить ядро без поддержки PE.


Top
   
PostPosted: Thu Oct 25, 2007 11:25 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Скажем так: я за поддержку загрузки PE как таковую, я против признания PE основным форматом - именно потому, что там много лишних полей (действительно лишних! таблицу секций с атрибутами я лишней не считаю!), которые будут давать заметный вклад в маленькие программы, но действительно пренебрежимо малы в ЯВУшных монстрах.
Serge wrote:
Что касается "sys.dll" то повторю ещё раз: я предлагаю сделать библиотеку с единым API системных вызовов для программ на С и Паскале (если получится) IMHO такая интерфейсная библиотека избавит от необходимости каждому изобретать свои версии draw_window, ksys_draw_window, kos_draw_window и т.п. и дополнительно проводить проверку параметров о которой забыли разработчики ядра, а так же фиксить некоторые особенности системы.

Тогда я обеими руками за.
k@sTIg@r wrote:
4. Упрощает разработку софта под колибри, а собственно и к-во разработчиков.

Вот тут ты не прав. Какая разница, что использует menuetlibc - статически линкуемый код или динамическую библиотеку? На исходный текст программ это не влияет. А для привлечения разработчиков нужны всякие визуальные среды... Но при этом возникает другой вопрос: а нужно ли нам привлекать таких разработчиков?
k@sTIg@r wrote:
Единственный минус, который повлияет на ядро/дистрибутив - это увиличится размер ядра.
Но и тут есть выход, я думаю без проблем влепить опцию которая будет компилить ядро без поддержки PE.

Нет уж, выкидывать полезные фичи только из соображений экономии места - не наш метод.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Thu Oct 25, 2007 12:23 pm 
Offline

Joined: Wed Feb 21, 2007 3:03 pm
Posts: 188
diamond wrote:
я против признания PE основным форматом

Так никто и не предлагает :)
diamond wrote:
А для привлечения разработчиков нужны всякие визуальные среды... Но при этом возникает другой вопрос: а нужно ли нам привлекать таких разработчиков?

Ты имеешь ввиду что-то вроде Builder'a с палитрой компонентов?
Если да, то тут ты тоже немного не прав. Для меня удобная среда это которая предлагает удобные средства для написания кода. Что-то вроде eclips'a и т.п. Аналогов под колибри нет.
Я не спорю, я не разбирался как компилить для колибри на ЯВУ, может данный способ и не будет менне корявым чем теперешний. Так что дальше промолчу :)
diamond wrote:
Нет уж, выкидывать полезные фичи только из соображений экономии места - не наш метод.

ну тогда вообще замечательно :)


Top
   
PostPosted: Thu Oct 25, 2007 12:26 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
Serge или кто-нибудь другой сделайте возможность подключения PE DLL в пользовательских приложениях, это ведь не очень сложно. Как я понял это еще не реализовано. Сам я пока боюсь лезть в код ядра.

..bw


Top
   
PostPosted: Thu Oct 25, 2007 12:32 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Quote:
Для меня удобная среда это которая предлагает удобные средства для написания кода

...а попутно создаёт многомегабайтные продукты и отучает использовать мозг...


Top
   
PostPosted: Thu Oct 25, 2007 12:45 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Serge
А загрузчик обрабатывает всякие тонкости PE-формата? Например, TLS callbacks или bound import?


Top
   
PostPosted: Thu Oct 25, 2007 1:09 pm 
Offline

Joined: Wed Feb 21, 2007 3:03 pm
Posts: 188
diamond wrote:
...а попутно создаёт многомегабайтные продукты и отучает использовать мозг...


Ты не понял. Я про всякие backfill'ы. Ctrl+LMB на имени функции выкидывает меня туда где эта ф-ция обьявлена. Тоже самое про переменные. При простом наводе на функцию показывает ее обьявление (какие параметры сколько и в каком порядке) и если есть то ее шапка /** ...*/.
И куча куча других мелких полезностей которые нифига не отключают мозг, а просто освобождают его от избыточной инфы. А также экономит время на открытие другого файла и поиска в нем необходимой тебе ф-ции/переменной или других данных. Особенно при использовании не свих хидеров. Ну и собсно кнопочки компиляции/билда/запуска и т.д. которые опять же ускоряют процедуру написания кода.


Top
   
PostPosted: Thu Oct 25, 2007 1:26 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
k@sTIg@r
Я вполне допускаю существование программистов, которым от сред типа Visual Studio и Delphi действительно нужны только продвинутые средства редактирования кода. Но я также уверен в существовании программистов, которым нравится именно написание программ в стиле "набросал мышкой кнопочек на форму, подредактировал их свойства и выложил как готовый продукт"...

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Thu Oct 25, 2007 1:46 pm 
Offline

Joined: Wed Feb 21, 2007 3:03 pm
Posts: 188
diamond
Конечно такие есть. Я тоже таким был. Точнее я с такого начинал познание ПК. Потом мне пространства начало не хватать, сильно уж ограниченое программирование. Потом забил и пошел дальше.
Но все равно до сих пор я признаю такой вид программирования. Иногда приходится писать мелкие программки. На WinAPI дольше, куда проще пихнуть пару editbox'ов и копочек и написать их обработчики.
Да и некоторые программы получаются хорошими, пусть тяжеловатыми. Но зато быстро и удобно.
Посмотри на некоторые приложения колибри такие как сетап, настройка сети и т.д. Уже есть libGUI но никто не спешит переводить их под эту библиотеку. Зато на форуме присутствует много людей которые с удовольствием это сделали будь визуальная среда разработки, т.к. асма боятся как огня. Так что не стоит не дооценивать "такой способ разработки".
Разговор переходит в оффтоп...


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 124 posts ]  Go to page Previous 1 2 3 4 59 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited