art_zh
А что это за зверь и с чем его едят ?
И как быть с многопоточными приложениями ?
Имхо потоку проще установить его системным вызовом.
Длина командной строки и пути к файлу при запуске
Serge
Кольцевой буфер, в который приложение сможет записывать параметры mcall 47, mcall 4 и некоторых других системных вызовов, не требующих срочного исполнения и возврата результата.
Ядро будет прогонять всю очередь GUI-запросов за один вызов int40.
Но если уж вводим новый заголовок чтобы упростить кому-то жизнь - тогда не забывай и об ассемблерщиках.
Кольцевой буфер, в который приложение сможет записывать параметры mcall 47, mcall 4 и некоторых других системных вызовов, не требующих срочного исполнения и возврата результата.
Ядро будет прогонять всю очередь GUI-запросов за один вызов int40.
имхо твою TLS-структуру тоже проще запросить системным вызовом.Имхо потоку проще установить его системным вызовом.
Но если уж вводим новый заголовок чтобы упростить кому-то жизнь - тогда не забывай и об ассемблерщиках.
art_zh
Если приложение всё равно будет делать вызов 0х40, то что мешает передавать указатель в этом вызове ? Иначе как ты собираешься расшарить один глобальный буфер между несколькими потоками ?
TLS можно создавать системным вызовом, но это несколько муторно и чревато проблемами. Например процесс загружает DLL, та неявно для процесса создаёт несколько потоков, процесс создаёт TLS, ядро в панике.
Если приложение всё равно будет делать вызов 0х40, то что мешает передавать указатель в этом вызове ? Иначе как ты собираешься расшарить один глобальный буфер между несколькими потоками ?
TLS можно создавать системным вызовом, но это несколько муторно и чревато проблемами. Например процесс загружает DLL, та неявно для процесса создаёт несколько потоков, процесс создаёт TLS, ядро в панике.
Serge
имхо так асм-код будет проще.
Конкретную реализацию потом обсудим.
А сейчас - тебе что, так трудно зарезервировать одно поле DD для GUI-указателя?
имхо так асм-код будет проще.
Конкретную реализацию потом обсудим.
А сейчас - тебе что, так трудно зарезервировать одно поле DD для GUI-указателя?
Если честно, да. Я ужал заголовок в 48 байт, оставив самое необходимое.А сейчас - тебе что, так трудно зарезервировать одно поле DD для GUI-указателя?
Хочется всё же описание хоть какой реализации, а пока я плохо представляю как такой единственный буфер будет работать в многооконном окружении.
Ну вот, прямой вопрос - конкретный ответSerge wrote:Если честно, да. Я ужал заголовок в 48 байт, оставив самое необходимое.
Ладно, буфер действительно лучше будет на сисфункцию повесить, чтоб оставить совместимость со старым заголовком.
compress it a bit moreSerge wrote:Я ужал заголовок в 48 байт,
Code: Select all
header:
db 'KOLIBRI',0 ; +0 8byte checksum for the entire file would be much better use
dw _code-header ; +8 size of this header = app entry point = number of supported features
dw _data/4096 ;+10 data section in 4KB units to support execution-disable(XD,NX)
; = end of code = max 256MB code; max 256MB data
;+12 import section offset relative to data, if present, could be 4KB aligned to set read-only
dd _import-_data ; could be 2bytes instead, want more than 64KB of data - allocate
;+16 in 4KB units (why does ring3 programmer need precise size of "end of disk image" ? )
dw (_unInit-_data)/4096 ; variable inside import can tell precise size
dw 100h ;+18 size of uninitialized data; naturally, in 4KB units
dw 100h ;+20 size of stack in 4KB units, or you got less than 4KB chunks ?
; you want more than 256MB stack - make it initial stack
; you can put all these on stack as variables to be poped
; sometimes you need these inside variables, sometimes can get away with registers only
dd 0 ;+22 address of tls info structure kernel-defined
dd 0 ;+26 exec_path kernel-defined
dd 0 ;+30 cmdline kernel-defined
dd 0 ;+34 env kernel-defined
_code:
xor eax, eax
align 4096
_data:
db 0
_import:
db 0
align 4096
_unInit:
rb 0
ilya
Тебя сейчас с потрохами съедят за трату байт на выравнивании.
Я трамбовал заголовок не ради небольшого размера, а для выравнивания на 16 байт.
Тебя сейчас с потрохами съедят за трату байт на выравнивании.
Я трамбовал заголовок не ради небольшого размера, а для выравнивания на 16 байт.
you can still have this as DWORD(simply change the variable) - no bytes lost but if it's 4KB aligned - please enforce restriction.
Can't understand that, any alignment is meaningless unless you deal with SSE on modern computers.а для выравнивания на 16 байт
ilya
А зачем задавать смещения относительно _data, лишние вычисления ведь.
А зачем задавать смещения относительно _data, лишние вычисления ведь.
Так он же сказал, что все тут лохи, вот и разводит лохов.Serge wrote:ilya
А зачем задавать смещения относительно _data, лишние вычисления ведь.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Ты хотел меньший размер заголовка, я правда не знаю зачем
Я знаю почему я ограничиваю различные размеры. Гадайте...
лохи не те кто противоречят мне а кто отстаёт от остальных в поддержки технологий выгодных для пользователя - для меня включительно
Я знаю почему я ограничиваю различные размеры. Гадайте...
лохи не те кто противоречят мне а кто отстаёт от остальных в поддержки технологий выгодных для пользователя - для меня включительно
Serge
Заглохло?
Заглохло?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Займусь немного позже. Надо допилить драйверы.
Два вопроса:Serge wrote:Вот такой пример для наглядностиCode: Select all
STACK_SIZE equ 4096 include 'proc32.inc' org 0 db 'KOLIBRI',0 ;+00 banner + revision 0-255 dd start ;+08 application entry dd ecode ;+12 end of code and constant data dd import ;+16 import section, if present dd eimport ;+20 end of import section dd edata ;+24 end of initialized data, end of disk image dd emem ;+28 end of uninitialized data dd STACKSIZE ;+32 size of stack dd 0 ;+36 address of tls info structure kernel-defined dd 0 ;+38 exec_path kernel-defined dd 0 ;+40 cmdline kernel-defined dd 0 ;+44 env kernel-defined
- Где экспорты? Для библиотек потом еще один формат изобретать? Уж переделывать -- так сразу комплексно, не?
- Зачем указывать начало и конец секций? На уровне формата в файле предполагаются дырки, заполненные чем угодно? Мне кажется, что секции должны быть пригнаны друг к другу плотно, но с учетом выравнивания, которое можно задать и отдельно.
Code: Select all
magic db 'KOLIBRI', 0 ; sign, version
alignment db 4 ; power of 2: 3 = 8 bytes, 4 = 16 bytes
reserved db 3 dup 0
imagebase dd 0 ; image base, for better flexibility
entrypoint dd 0 ; entry point, for better flexibility
code dd 0 ; size of code section
import dd 0 ; size of import section, 0 = section is not present
export dd 0 ; size of export section, 0 = application
data_ dd 0 ; size of initialized data section
mem dd 0 ; size of uninitialized memory for application, as the same in MENUET01
stack_ dd 0 ; size of stack
cmdline dd -1 ; command line, kernel-defined; -1 = prompt for params
execpath dd ? ; exec path, kernel-defined
env dd ? ; environment variables, kernel-defined
tls dd ? ; address of thread local storage (TLS), kernel-defined
- Выравнивание задается полем alignment, степенью двойки.
- Есть поля imagebase и entrypoint для лучшей совместимости с неродными компиляторами.
- Есть экспорты. Для библиотеки в поле export пишется размер секции, а у приложений оно равно нулю. По этому признаку можно отличить библиотеку от приложения, поэтому дополнительных флагов не требуется.
- Для секций заданы только размеры. Подразумевается, что секции идут друг за другом сплошняком с учетом выравнивания.
- В поле cmdline может стоять -1, что означает: "Мне нужны входные параметры". Пока флаг никак не используется, а в будущих версиях можно добавить автоматический запрос параметров для таких программ. Получится некий аналог консольных приложений, и тоже без дополнительных полей.
Last edited by Freeman on Sat Nov 23, 2013 10:28 pm, edited 1 time in total.
Who is online
Users browsing this forum: No registered users and 2 guests