Serge> но очень вероятно что он не загрузится в Win
Serge> адрес приложений в Колибри 0x0000 а в Win 0x400000
Ну вроде сам то формат легально поддержичает эти фичи. Если винда не работает с ними, то это её проблема :-).
..bw
Колибри PE
andrew_programmer
MS COFF остаётся, а вообще coff легко линкуется в PE DLL
MS COFF остаётся, а вообще coff легко линкуется в PE DLL
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.
2. Если сделать загрузку PE-файлов как бинарников Колибри, сразу же возникнет путаница Колибри-бинарников и Windows-бинарников. И посыплются куча вопросов "а чего оно не запускается" и хотелок "ну PE-екзешники вы же загружать умеете, как насчёт загрузки Windows-программ?" А уж как расстроятся линуксоиды...
3. Сравните формат PE и "формат" MENUETxx. Посчитайте размер заголовков, количество лишних/ненужных/неиспользуемых полей/областей и только потом продолжайте предлагать подобные идеи. Напоминаю, что Колибри позиционируется как маленькая и быстрая ось.
4. Колибри позиционируется также как система, большая часть которой написана на ассемблере. Нафига в ассемблерных программах (которых большинство и, я надеюсь, останется большинство) вообще какие-то обёртки для всех API? Банальный "int 0x40" короче и быстрее.
5. Желающим видеть программы, валидные одновременно и в Колибри, и в Windows: все системные программы и все файловые менеджеры написаны на ассемблере и напрямую используют системные вызовы. Выкиньте их - и что останется? Портированные вещи типа doom и dosbox? Знаете ли, их Windows-версии всегда будут работать лучше Колибри-версий, запущенных под Windows. А свои программы в любом случае можно писать так, чтобы их можно было скомпилировать и как Kolibri-программу, и как Windows-программу (@rcher тому пример).
6. tcc как раз-таки генерирует формат MENUET01.
Ушёл к умным, знающим и культурным людям.
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
Наверное поэтому разговор о DLL шёл несколько лет без всях результатов. Интересующиеся вопросом могут посмотреть тему. Своих форматов для DLL так никто и не разработал. Тем более что ещё нужны инструменты для работы с новым форматом.
2. Хотелки будут всегда. Их количество определяется числом новичков узнавших о системе и больше связано с распространением новостей о системе чем с её возможностями и внутренним устройством.
3,4 Да PE и ELF содержат много дополнительной и "ненужной" на первый взгляд информации. Но когда начинаешь делать загрузку по произвольному адресу и с защитой памяти эта ненужная информация становится просто необходимой. Для примера: сейчас код ядра вообще никак не защищён от затирания. Достаточно ф.70.0 считать 128Кб по адресу 0х80010000 чтобы затереть всё ядро. И сделать такую защиту практически невозможно потому что код ядра перемешан с данными - следствие "компактного и не отягощённого всякими ненужными полями" raw формата ядра. Что касается размера файлов то чем больше модуль тем меньше процент накладных расходов, а упаковка вообще сводит их к минимуму.
Никто не предлагал делать обёртки системных вызовов для асм-программ. Речь шла о едином API для ЯВУ. Впрочем никто и не запрещает такими обёртками пользоваться. Кому как нравится.
Похоже что в конечном счёте все упирается в вопрос о "чистоте системы". Для Вилле это был принципиально - в МеОС всё должно быть написан на асме. В Колибри если я не ошибаюсь так вопрос никогда не стоял.
P.S. Две цитаты:
Vlad G. Maslakov 21 май 2005 16:26
mike.dld 21 май 2005 16:56А что, если попробовать интегрировать возможность реализации DLL в ядро? Тогда к DLL обращаться через IPC будет не сложно, но проблема в передаче параметров. После реализации открываются большие перспективы для MeOS как модульной системы (а не так, что все ядро одним файлом).
Приблизительно так и должно быть. И в любом случае так будет. Но не сейчас. Я могу свободно представить себе, насколько возрастёт потенциал ядра с введением DLL, но делается всё не в один день.
Начинаем разбирать описание формата PE.Serge wrote:Да PE и ELF содержат много дополнительной и "ненужной" на первый взгляд информации. Но когда начинаешь делать загрузку по произвольному адресу и с защитой памяти эта ненужная информация становится просто необходимой.
В начале файла идёт DOS-заголовок и DOS-заглушка. Абсолютно ненужные и неиспользуемые. Уже получаем минимум 0x40 (а обычно в пару раз больше) лишних байт.
Далее,
Code: Select all
typedef struct _IMAGE_NT_HEADERS {
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;
Code: Select all
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;
Ну, допустим, кто-то выделил абсолютно все переменные в блоки iglobal/uglobal, отделил начало данных от конца кода и сделал все страницы кода доступными только на чтение. Тогда функцией 70.0 можно считать 64 Кб по адресу 0x80000000 - и всё равно можно давить Reset, потому что вместо важных системных данных появляется каша. И формат ядра тут ни при чём. Такая защита от плохих приложений делается по-другому, проверками указателей, независимо от атрибутов страниц.Для примера: сейчас код ядра вообще никак не защищён от затирания. Достаточно ф.70.0 считать 128Кб по адресу 0х80010000 чтобы затереть всё ядро. И сделать такую защиту практически невозможно потому что код ядра перемешан с данными - следствие "компактного и не отягощённого всякими ненужными полями" raw формата ядра.
А мне почему-то показалось, что постSerge wrote:Никто не предлагал делать обёртки системных вызовов для асм-программ. Речь шла о едином API для ЯВУ.
именно это и предлагает. И чистота системы тут ни при чём.k@sTIg@r wrote:Если я правильно понимаю, то теперь можно будет реализвать dll в которой будут обертки для системных вызовов колибри. Реализовать такую же для винды. И полноценно пускать и там и там?
Ушёл к умным, знающим и культурным людям.
diamond
И того получается две сотни лишних байтов. И разумеется мы никак не можем себе этого позволить.
Я не утверждал что ненужных нам полей там вообще нет. Но их процент невелик. Для примера килобайтный заголовок bochsdbg.exe 2.3.5 составляет 0,045% от всего файла. Это приемлимо или нет ?
Для ac97snd это 1.02%. Упакованный win-екзешник весит 23 543 байта а колибри 23 478 байт. И того разница в 65 байт или 0.28% от окончательного размера бинарника.
Такие вопросы должны решаться ещё при проектировании системы в том числе и о проверках параметров. Только никто этих проверок не делает и я в том числе. Большинство вызовов записывающих данные по указателю могут записать их куда угодно.
Но сделать эффективную защиту от пререзаписи расшаренной 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 представляется очень полезной.
И того получается две сотни лишних байтов. И разумеется мы никак не можем себе этого позволить.
Я не утверждал что ненужных нам полей там вообще нет. Но их процент невелик. Для примера килобайтный заголовок bochsdbg.exe 2.3.5 составляет 0,045% от всего файла. Это приемлимо или нет ?
Для ac97snd это 1.02%. Упакованный win-екзешник весит 23 543 байта а колибри 23 478 байт. И того разница в 65 байт или 0.28% от окончательного размера бинарника.
Разумеется ты прав. Ничто не защитит данные ядра от затирания самим ядром. Но это врождёный недостаток ядра вообще и к сожалению не последний.Такая защита от плохих приложений делается по-другому, проверками указателей, независимо от атрибутов страниц.
Такие вопросы должны решаться ещё при проектировании системы в том числе и о проверках параметров. Только никто этих проверок не делает и я в том числе. Большинство вызовов записывающих данные по указателю могут записать их куда угодно.
Но сделать эффективную защиту от пререзаписи расшаренной 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 представляется очень полезной.
diamond, я не подразумевал перевести все программы в формат PE и подсадить их на "sys.dll". Я всего лишь спрашивал, реально ли такое провернуть. Извини может я не правильно выразился.
Я полностью поддерживаю идею с поддержкой PE. А также единой библиотеки для ЯВУ.
1. Она ни кому не мешает
2. Она ни кого не заставляет переходить с формата MENUETxx или COFF на PE.
3. Никто никого не заставляет потом PE-файлы пихать в дистрибутив, так что лишнее место никто не зохавает.
4. Упрощает разработку софта под колибри, а собственно и к-во разаработчиков.
Единственный минус, который повлияет на ядро/дистрибутив - это увиличится размер ядра.
Но и тут есть выход, я думаю без проблем влепить опцию которая будет компилить ядро без поддержки PE.
Я полностью поддерживаю идею с поддержкой PE. А также единой библиотеки для ЯВУ.
1. Она ни кому не мешает
2. Она ни кого не заставляет переходить с формата MENUETxx или COFF на PE.
3. Никто никого не заставляет потом PE-файлы пихать в дистрибутив, так что лишнее место никто не зохавает.
4. Упрощает разработку софта под колибри, а собственно и к-во разаработчиков.
Единственный минус, который повлияет на ядро/дистрибутив - это увиличится размер ядра.
Но и тут есть выход, я думаю без проблем влепить опцию которая будет компилить ядро без поддержки PE.
Скажем так: я за поддержку загрузки PE как таковую, я против признания PE основным форматом - именно потому, что там много лишних полей (действительно лишних! таблицу секций с атрибутами я лишней не считаю!), которые будут давать заметный вклад в маленькие программы, но действительно пренебрежимо малы в ЯВУшных монстрах.
Тогда я обеими руками за.Serge wrote:Что касается "sys.dll" то повторю ещё раз: я предлагаю сделать библиотеку с единым API системных вызовов для программ на С и Паскале (если получится) IMHO такая интерфейсная библиотека избавит от необходимости каждому изобретать свои версии draw_window, ksys_draw_window, kos_draw_window и т.п. и дополнительно проводить проверку параметров о которой забыли разработчики ядра, а так же фиксить некоторые особенности системы.
Вот тут ты не прав. Какая разница, что использует menuetlibc - статически линкуемый код или динамическую библиотеку? На исходный текст программ это не влияет. А для привлечения разработчиков нужны всякие визуальные среды... Но при этом возникает другой вопрос: а нужно ли нам привлекать таких разработчиков?k@sTIg@r wrote:4. Упрощает разработку софта под колибри, а собственно и к-во разработчиков.
Нет уж, выкидывать полезные фичи только из соображений экономии места - не наш метод.k@sTIg@r wrote:Единственный минус, который повлияет на ядро/дистрибутив - это увиличится размер ядра.
Но и тут есть выход, я думаю без проблем влепить опцию которая будет компилить ядро без поддержки PE.
Ушёл к умным, знающим и культурным людям.
Так никто и не предлагаетdiamond wrote:я против признания PE основным форматом
Ты имеешь ввиду что-то вроде Builder'a с палитрой компонентов?diamond wrote:А для привлечения разработчиков нужны всякие визуальные среды... Но при этом возникает другой вопрос: а нужно ли нам привлекать таких разработчиков?
Если да, то тут ты тоже немного не прав. Для меня удобная среда это которая предлагает удобные средства для написания кода. Что-то вроде eclips'a и т.п. Аналогов под колибри нет.
Я не спорю, я не разбирался как компилить для колибри на ЯВУ, может данный способ и не будет менне корявым чем теперешний. Так что дальше промолчу
ну тогда вообще замечательноdiamond wrote:Нет уж, выкидывать полезные фичи только из соображений экономии места - не наш метод.
Serge или кто-нибудь другой сделайте возможность подключения PE DLL в пользовательских приложениях, это ведь не очень сложно. Как я понял это еще не реализовано. Сам я пока боюсь лезть в код ядра.
..bw
..bw
...а попутно создаёт многомегабайтные продукты и отучает использовать мозг...Для меня удобная среда это которая предлагает удобные средства для написания кода
Serge
А загрузчик обрабатывает всякие тонкости PE-формата? Например, TLS callbacks или bound import?
А загрузчик обрабатывает всякие тонкости PE-формата? Например, TLS callbacks или bound import?
Ты не понял. Я про всякие backfill'ы. Ctrl+LMB на имени функции выкидывает меня туда где эта ф-ция обьявлена. Тоже самое про переменные. При простом наводе на функцию показывает ее обьявление (какие параметры сколько и в каком порядке) и если есть то ее шапка /** ...*/.diamond wrote:...а попутно создаёт многомегабайтные продукты и отучает использовать мозг...
И куча куча других мелких полезностей которые нифига не отключают мозг, а просто освобождают его от избыточной инфы. А также экономит время на открытие другого файла и поиска в нем необходимой тебе ф-ции/переменной или других данных. Особенно при использовании не свих хидеров. Ну и собсно кнопочки компиляции/билда/запуска и т.д. которые опять же ускоряют процедуру написания кода.
k@sTIg@r
Я вполне допускаю существование программистов, которым от сред типа Visual Studio и Delphi действительно нужны только продвинутые средства редактирования кода. Но я также уверен в существовании программистов, которым нравится именно написание программ в стиле "набросал мышкой кнопочек на форму, подредактировал их свойства и выложил как готовый продукт"...
Я вполне допускаю существование программистов, которым от сред типа Visual Studio и Delphi действительно нужны только продвинутые средства редактирования кода. Но я также уверен в существовании программистов, которым нравится именно написание программ в стиле "набросал мышкой кнопочек на форму, подредактировал их свойства и выложил как готовый продукт"...
Ушёл к умным, знающим и культурным людям.
diamond
Конечно такие есть. Я тоже таким был. Точнее я с такого начинал познание ПК. Потом мне пространства начало не хватать, сильно уж ограниченое программирование. Потом забил и пошел дальше.
Но все равно до сих пор я признаю такой вид программирования. Иногда приходится писать мелкие программки. На WinAPI дольше, куда проще пихнуть пару editbox'ов и копочек и написать их обработчики.
Да и некоторые программы получаются хорошими, пусть тяжеловатыми. Но зато быстро и удобно.
Посмотри на некоторые приложения колибри такие как сетап, настройка сети и т.д. Уже есть libGUI но никто не спешит переводить их под эту библиотеку. Зато на форуме присутствует много людей которые с удовольствием это сделали будь визуальная среда разработки, т.к. асма боятся как огня. Так что не стоит не дооценивать "такой способ разработки".
Разговор переходит в оффтоп...
Конечно такие есть. Я тоже таким был. Точнее я с такого начинал познание ПК. Потом мне пространства начало не хватать, сильно уж ограниченое программирование. Потом забил и пошел дальше.
Но все равно до сих пор я признаю такой вид программирования. Иногда приходится писать мелкие программки. На WinAPI дольше, куда проще пихнуть пару editbox'ов и копочек и написать их обработчики.
Да и некоторые программы получаются хорошими, пусть тяжеловатыми. Но зато быстро и удобно.
Посмотри на некоторые приложения колибри такие как сетап, настройка сети и т.д. Уже есть libGUI но никто не спешит переводить их под эту библиотеку. Зато на форуме присутствует много людей которые с удовольствием это сделали будь визуальная среда разработки, т.к. асма боятся как огня. Так что не стоит не дооценивать "такой способ разработки".
Разговор переходит в оффтоп...
Who is online
Users browsing this forum: No registered users and 3 guests