Формат EXE/DLL для новой ОС [Архив] - Speccy

Alex/AT

01.04.2005, 10:09

Описание:

ZE/ZL (ZX Executable/ZX Library) structure (as defined for version 1.00):

02 'ZE' or 'ZL' signature
02 ZX Executable version (0112h means 1.12)
04 File length
02 Number of segments (A)
04*A Segment descriptors
02 Number of imported functions (B)
??*B Imported function descriptors
02 Number of code modifications (C)
??*C Code modifications
?? Segment data (sequential, by descriptors)
------------- ZL extensions begin
02 Number of exported functions (D)
??*D Exported function descriptors

Segment descriptor:

02 Segment length
01 Flags
0: 0 = code segment, 1 = data segment
1: for code: 0 = near segment (must be placed in the same page with
previous segment), 1 = far segment (may be placed anywhere)
for data: 0 = static segment (must be swapped to certain location),
1 = dynamic segment (may be located anywhere)
2: for code: 0 = frequent ISCs (active participant of intersegment
calls), 1 = rare ISCs (rarely called by intersegment call)
for data: 0 = swappable segment (may be swapped), 1 = must be
placed with previous segment)
3: 0 = normal segment, 1 = shared memory segment (in common RAM)
4: 0 = normal segment, 1 = empty segment (filled with 0s, no real
data in ZE image present)
5-6: alignment (00 = 1 byte; 01 = 16 bytes; 10 = 256 bytes; 11 =
4096 bytes)
7: reserved

Code modification:

01 Modification type
0: internal call/data access
1: intersegment call
2: intersegment data access
3: intersegment pagination (swap)
4: internal high byte
5: internal low byte
6: intersegment high byte
7: intersegment low byte
8: imported function (intersegment)
9: imported data (intersegment)
10: imported pagination (intersegment)
11: imported high byte (intersegment)
12: imported low byte (intersegment)
13: system call
14: system variable
15: two addresses difference
16: two addresses difference high byte
17: two addresses difference low byte
18-255: reserved

Modification 0:

02 Segment index
02 Internal address (+0/1: added to segment start)

Modification 1:

02 Segment index
02 Internal address (+0/1: replaced by call pointer,
+2/3: added with segment start)

Modification 2:

02 Segment index
02 Internal address (+0/1: added to segment start)
02 Target segment index

Modification 3:

02 Segment index
02 Internal address (+0/1: replaced by page number)
02 Target segment index

Modification 4:

02 Segment index
02 Internal address (+0: added to high result byte)
02 Target internal address

Modification 5:

02 Segment index
02 Internal address (+0: added to low result byte)
02 Target internal address

Modification 6:

02 Segment index
02 Internal address (+0: added to high result byte)
02 Target segment index
02 Target offset

Modification 7:

02 Segment index
02 Internal address (+0: added to low result byte)
02 Target segment index
02 Target offset

Modification 8:

02 Segment index
02 Internal address (+0/1: replaced by segment index (call ptr),
+2/3: added to offset or replaced by 2xNOP)
02 Imported function index

Modification 9:

02 Segment index
02 Internal address (+0/1: added to target address)
02 Imported function index

Modification 10:

02 Segment index
02 Internal address (+0/1: replaced by page number)
02 Imported function index

Modification 11:

02 Segment index
02 Internal address (+0: added to high byte of the target address)
02 Imported function index

Modification 12:

02 Segment index
02 Internal address (+0: added to low byte of the target address)
02 Imported function index

Modification 13:

02 Segment index
02 Internal address (+0/1: replaced by segment index (call ptr),
+2/3: added to offset or replaced by 2xNOP)
02 System call index

Modification 14:

02 Segment index
02 Internal address (+0/1: added to target address)
02 System variable index

Не сделано: Import/Export.

Изменения: учел кое-какие пожелания из ответов ниже.

acidrain

01.04.2005, 10:27

так, для информации =)

частично перевел, но простите - не все =( - времени не хватило =)

random

01.04.2005, 11:11

предлагаю делать Exported Function и в обычных EXE. Простейший пример start, autostart.

lvd

01.04.2005, 14:14

так, для информации =)

частично перевел, но простите - не все =( - времени не хватило =)

Стасик, разве ты не понял ещё? Тут пцшно-линухово-виндозный заговор, искусно организованный засланцами с пц =) Так что амижные идеи в спекооси не пройдут =))))

Alex/AT

01.04.2005, 14:21

предлагаю делать Exported Function и в обычных EXE. Простейший пример start, autostart.
Да, вполне реально. EXE тоже сможет экспортить функции, которые, к тому же, могут быть подключены дочерними DLL. Обязательно учту при дальнейшем описании.

Так что амижные идеи в спекооси не пройдут =))))
Блин. Тут не то что амижные, тут вообще никакие не пройдут. Ибо адресное пространство у спека - всего лишь 16 бит... Вот поэтому приходится изголяться. А в доках по ханкам меня порадовала надпись "Неизвестная структура" =)

Vitamin

01.04.2005, 20:16

Стасик, разве ты не понял ещё? Тут пцшно-линухово-виндозный заговор, искусно организованный засланцами с пц =) Так что амижные идеи в спекооси не пройдут =))))
мля... вдарились в винду- подпихиваем линух. стали глядеть в сторону линукса- тоже не так, подавай амигу. а у многих она есть? я лично видел ее всего один раз в работе так что абсолютно ничего не знаю насчет принципов работы.

а насчет доки. довольно интересно. Hunks == Chunks? ;) они же секции в файлах PE-формата? всетаки надо стараться чтобы количестви лишней информации в бинарниках стремилось к минимуму- поэтому нет особого смысла в символьных названиях секций (насколько я понял, они присутствуют). если рассматривать то, что я до этого предлагал (модульную структуру), то можно также сказать, что она состоит из четырех ханков- таблица релокации, таблица символьных имен экспортируемых точек, таблица символьных имен импортируемых точек, код. в исполняемом файле можно оставить только первую и последнюю точки. для динамических библиотек еще нужна таблица экспортируемых точек, чтобы искать адреса во время исполнения. плюс к тому, структура таблицы релокации позволяет корректировать не только 16, но и 8-битные адреса (ld a,.metka:ld h,'font etc).

lvd

02.04.2005, 00:03

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

Принципы работы такие же, как у любого компа - процессор + периферия =)

А вообще ничто не мешает взять winUAE и с некоторой помощью других амижников разобраться до любого уровня =)

а насчет доки. довольно интересно. Hunks == Chunks? ;)

Неа! =)

всетаки надо стараться чтобы количестви лишней информации в бинарниках стремилось к минимуму- поэтому нет особого смысла в символьных названиях секций (насколько я понял, они присутствуют).

Они присутствуют, если это объектник. А если 'эхешник', то отсутствуют. Формат файлов остаётся таким же.

плюс к тому, структура таблицы релокации позволяет корректировать не только 16, но и 8-битные адреса (ld a,.metka:ld h,'font etc).

add a,a
add a,a
ld l,a
ld h,'font/8
add hl,hl
add hl,hl
add hl,hl

org #какой_попало

;some stuff

ld h,'megatable

;more stuff

org ($+255)&#FF00
megatable
db #xx,#yy,... ;256 bytes

ld h,'megatable

; stuff

inc h

;stuff

dec h
;etc.

;stuff

ld a,'microtable-'megatable
add a,h
ld h,a

Всё подобное, как я понимаю, пойдёт на север? =)

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

Vitamin

02.04.2005, 01:11

Принципы работы такие же, как у любого компа - процессор + периферия =)

ну да. и че гнать на закос под винду или юних- не понимаю. что есть, то и изучаем.

А вообще ничто не мешает взять winUAE и с некоторой помощью других амижников разобраться до любого уровня =)

каких других? у нас в городе ни одной амиги насколько я знаю нету.

Неа! =)

а похоже- как по названию, так и по смыслу %)

add a,a
add a,a
ld l,a
ld h,'font/8
add hl,hl
add hl,hl
add hl,hl

ld h,'font
srl h
srl h
srl h

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

org #какой_попало

;some stuff

ld h,'megatable

;more stuff

org ($+255)&#FF00
megatable
db #xx,#yy,... ;256 bytes

если орг по круглому адресу- нет проблем. а гарантировать такое для приложений- вполне реально

ld h,'megatable

; stuff

inc h

;stuff

dec h
;etc.

;stuff

ld a,'microtable-'megatable
add a,h
ld h,a

Всё подобное, как я понимаю, пойдёт на север? =)

__extern "diff",diff

ldh_ a,diff
;ldl_ a,diff

;somewhere in other module
__public "diff",constant,microtable-megatable
;__public "diff",constant,'microtable-'megatable

...если честно, я вообще с трудом представляю, что в результате того, что вы задумали, выйдет. Сможет ли там существовать приложение уровня аласма, например? С какой скоростью оно будет работать?...
сказывается разница менталитета. для спектрумиста ассемблер- это неразлучная парочка компилятор+редактор. и для полной шведской семьи +отладчик %)
кто мешает сделать компилятор через командную строку? он тебе может через системные функции или библиотеки в нижней памяти что угодно компилить.

GriV

02.04.2005, 13:16

что если вы собираетесь писать чтото новое (в частности ОСь) то вообще говоря прям счаз оно даст одни сплошные минусы:
- Скорость работы приложений отнесённая к чистой производительности процессора будет ниже
- Всё, что невозможно реализовать аппаратно будет реализовываться программно (читай - всё будет реализовано программно)
- Всё потенциальные и реальные плюсы будут для этой системы существовать только после достаточно продолжительного периода времени, когда будет написано много приложений, драйверов и произведена достаточная отладка

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

Alex/AT

02.04.2005, 14:53

Обновил спецификацию - учел кое-какие пожелания...

Исходя из этого мне непонятно, как вообще можно горить "это будет потреблять много ресурсов", если с самого начала все программные ресурсы будут отдаваться на откуп того, что в других системах реализовано аппаратно?
Вообще - да, сам в написании ос вижу много минусов для реальных приложений. Но для работы с текстами + в это время слушания музыки + в это время обсчета чего-нибудь вполне пойдет. Плюс - хорошая практика низкоуровнего программирования в условиях полного зада...

acidrain

02.04.2005, 19:03

Стасик, разве ты не понял ещё? Тут пцшно-линухово-виндозный заговор, искусно организованный засланцами с пц =) Так что амижные идеи в спекооси не пройдут =))))
Надежда, Вадик, умерает последней! =) ;)

acidrain

02.04.2005, 19:05

Цитата:
Сообщение от lvd
А вообще ничто не мешает взять winUAE и с некоторой помощью других амижников разобраться до любого уровня =)

каких других? у нас в городе ни одной амиги насколько я знаю нету.
А кроме Таганрога есть еще крд мск и прочие города России. если есть нужда - поможем всей тольпой =)

GriV

02.04.2005, 20:02

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

Для таких систем, где нужна полная производительность системы вводится монопольный режим. В этом режиме система сносит все свои блоки в верхнюю память, оставляет лишь самые необходимые трапы. однако в таком случае все положительные моменты, реализуемые системой будут грубо говоря "затыканы" монопольным режимом.
Вот основные трапы, которые нужны для программ в монопольном режиме:
- Загрузка/выгрузка данных на носитель
- Переключение банков памяти
- Получение информации о памяти
- Восстановление системы

GriV

02.04.2005, 20:15

2Alex/AT> однако та информация, которую ты привёл в начале треда мне абсолютно ничего не говорит. Лучше бы ты привёл полноценное описание и прикрепил это чтобы каждый мог посмотреть. Одни условные обозначения (типа segment adress) мало о чём говорят...

lvd

03.04.2005, 00:57

каких других? у нас в городе ни одной амиги насколько я знаю нету.

Для винуае амижники под рукой не необходимы (в отличие от случая, когда с дискет надо оживить реальную амигу - тут все клоны вг93 в пц отдыхают =).

если орг по круглому адресу- нет проблем. а гарантировать такое для приложений- вполне реально

Вопрос был в том, если вы уж городите релоцируемые ехешники, то в них блоки с выравниванием по хотя бы 256 байт будут?

__extern "diff",diff
ldh_ a,diff
;ldl_ a,diff

;somewhere in other module
__public "diff",constant,microtable-megatable
;__public "diff",constant,'microtable-'megatable

Ууу...

сказывается разница менталитета. для спектрумиста ассемблер- это неразлучная парочка компилятор+редактор. и для полной шведской семьи +отладчик %)

Раз так, то заявляю, что у меня для спектрума, для амиги и для пц менталитет разный (всего 3 варианта). =) А у тебя? :)

кто мешает сделать компилятор через командную строку? он тебе может через системные функции или библиотеки в нижней памяти что угодно компилить.

Никто не мешает, вопрос в том, кому он нужен. Аласм и то, несмотря на интегрированность с редактором, довольно-таки коматозен. Что будет, если каждый раз надо будет прибить редактор, записать на диск текст, загрузить с диска компайлер (==командная строчка?), откомпилировать с диска на диск, линкануть, не дай бог, с диска на диск, загрузить результат с диска в память, убедиться, что повисло наглухо, 5 минут терпеть загрузку оси, и всё с начала... Нее, лучше уж аласм! =)

Vitamin

03.04.2005, 12:50

Для винуае амижники под рукой не необходимы (в отличие от случая, когда с дискет надо оживить реальную амигу - тут все клоны вг93 в пц отдыхают =).

неюзабельно по причине отсутствия
-опыта
-времени
-эмулятора %)

Вопрос был в том, если вы уж городите релоцируемые ехешники, то в них блоки с выравниванием по хотя бы 256 байт будут?

ну стартовый адрес образа процесса если выровнен по границе, от него можно и плясать дальше

Ууу...

тада расскажи как эта проблема решается в предложенной структуре. авось каку идею хорошую можно будет слямзить %)

Раз так, то заявляю, что у меня для спектрума, для амиги и для пц менталитет разный (всего 3 варианта). =) А у тебя? :)

у меня 3 менталитета- для спека, для винды и для линуха %) хотя последние два довольно тесно склеены (причем результат близок к первому). во загнул! %)

Никто не мешает, вопрос в том, кому он нужен. Аласм и то, несмотря на интегрированность с редактором, довольно-таки коматозен. Что будет, если каждый раз надо будет прибить редактор, записать на диск текст, загрузить с диска компайлер (==командная строчка?), откомпилировать с диска на диск, линкануть, не дай бог, с диска на диск, загрузить результат с диска в память, убедиться, что повисло наглухо, 5 минут терпеть загрузку оси, и всё с начала... Нее, лучше уж аласм! =)
зачем прибивать редактор? многозадачная система вообщето может позволить запуск нескольких процессов. туда же и зависание. от бесконечных циклов спасет опять же многозадачность, от порчи памяти только не убережет....

Alex/AT

03.04.2005, 13:44

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

1. Оно опирается на структуру памяти, приведенную мной в разделе "менеджер памяти".

2. Вся память кода и данных делится на т.н. сегменты. Предельный размер сегмента кода в "стандартной" архитектуре - 16 кб (страница), данных - для статических сегментов данных (возможно, вместе с кодом) - до 16кб минус код при размещенни вместе с кодом, до 8 кб - при произвольном размещении, для динамических сегментов данных - до 8 кб. При повышенных возможностях архитектуры (замена #8000-#BFFF) эти лимиты возрастают.

3. Сегмент представляет из себя просто блок в памяти. Блоки кода и связанные блоки данных располагаются между #C000-#FFFF, статические несвязанные данные и динамические данные - в свап-области.

4. "Связанность" сегментов - это нахождение сегментов в одной странице (есть флаг, позволяющий указать именно такое расположение).

5. Несвязанные сегменты кода для вызовов между ними требуют использования процедуры ISC (Intersegment call). Она выглядит как CALL #xxxx; DW #yyyy, где xxxx - это процедура переключения страницы, yyyy - адрес в странице.

6. Несвязанные статические и динамические сегменты данных требуют их размещения в области свопа. Статические сегменты попадают в область свопа по строго определенному адрему, динамические - по произвольному. Для этого существует функция свопинга.

7. Segment index - системный номер сегмента (в файле - номер сегмента ZE/ZL). Internal address/Offset - смещение от начала сегмента.

8. Кроме всего прочего, существует набор системных вызовов (обсуждался ранее) и переменных, адресуемых по номерам (вместо номера подставляется реальный адрес).

Думаю, это прояснит некоторые моменты.

lvd

05.04.2005, 14:41

неюзабельно по причине отсутствия
-опыта
-времени
-эмулятора %)
Ну - а я что говорю? -
http://zx.pk.ru/showpost.php?p=9265&postcount=5
:p

тада расскажи как эта проблема решается в предложенной структуре. авось каку идею хорошую можно будет слямзить %)

В какой ещё предложенной структуре? В формате hunk'ов? Там эта проблема решается очень просто - применением 680x0 процессора =)

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

Да - зачем прибивать? А если всё в памяти сидит, то причём тут командная строка? Или у тебя IPC такое - через командную строку? =)
Далее. В памяти сидит редактор, ассемблер, линкер, куча сорцов. Ассемблер компилит в объектники - тоже в память. Объектники линкуются в ехешник - тоже в память. При этом тексты остаются ещё в памяти. Так? =) Или своп на диск? Если второе, то тогда чем эта ось лучше аласма получается? %)

random

05.04.2005, 15:39

два слова:
рам диск.

Vitamin

05.04.2005, 21:28

В какой ещё предложенной структуре? В формате hunk'ов? Там эта проблема решается очень просто - применением 680x0 процессора =)

мда... и после таких заявлений еще возникают фразы о заговоре %)
если уж на то пошло, то лучше сразу по x86 писать и не зарабатывать себе геморрой, благо свобода доступа больше

Да - зачем прибивать? А если всё в памяти сидит, то причём тут командная строка? Или у тебя IPC такое - через командную строку? =)
Далее. В памяти сидит редактор, ассемблер, линкер, куча сорцов. Ассемблер компилит в объектники - тоже в память. Объектники линкуются в ехешник - тоже в память. При этом тексты остаются ещё в памяти. Так? =) Или своп на диск? Если второе, то тогда чем эта ось лучше аласма получается? %)
ты сам так и сказал- прибивать.
а ты собираешься все держать в памяти? редактор-компилятор-отладчик?
первое и последнее вполне могут одновременно сосуществовать в памяти, а компилятор- это прикладная утилита однократного действия.
а насчет рамдиска (см. след. пост)- реальный способ. все утилы обращаются к системе через операции с файлами, а где эти файлы расположены- их абсолютно не касается. вот ты ругаешься на многократность обращений к диску. да, неприятно. а ты пробовал компилять большой проект в аласме на 128к? сколько раз к диску обращается? ;)

lvd

08.04.2005, 09:19

мда... и после таких заявлений еще возникают фразы о заговоре %)

Вообще-то это констатация фактов =)
На 680x0, ввиду его архитектуры, теряют смысл таблички, выровненные по 256 байт.

если уж на то пошло, то лучше сразу по x86 писать и не зарабатывать себе геморрой, благо свобода доступа больше

Ну - кому геморрой амига и амигаос, а кому - х86 и пц, а также размахивание кем-то горой книжек по линуху с криками 'даёшь форк на спеке!', 'даёшь маппинг файлов на память!' etc. =)=)=)

ты сам так и сказал- прибивать.

Прибивать==грузить заново с диска (2random - рамдиск конечно хорошо, но зачем грузить из рамдиска, когда можно просто НЕ прибивать? =).

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

Это как же так? День сидишь редактируешь, потом на вечер оставил компиляться, весь следующий день сидишь отлаживаешь? =)

а ты пробовал компилять большой проект в аласме на 128к? сколько раз к диску обращается? ;)
Нет. Потому что не мазохист =). Но к диску он обращается исключительно за сорцами и инкбинами, в твоём же случае ещё и за эхешниками лазить будет, и на диск свопить промежуточные результаты (линкер), и грузить эхешники обратно в память для запуска (релоцируемый код).

Vitamin

09.04.2005, 00:06

Вообще-то это констатация фактов =)
На 680x0, ввиду его архитектуры, теряют смысл таблички, выровненные по 256 байт.

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

Ну - кому геморрой амига и амигаос, а кому - х86 и пц, а также размахивание кем-то горой книжек по линуху с криками 'даёшь форк на спеке!', 'даёшь маппинг файлов на память!' etc. =)=)=)

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

Прибивать==грузить заново с диска (2random - рамдиск конечно хорошо, но зачем грузить из рамдиска, когда можно просто НЕ прибивать? =).

ну я за то и говорю- редактор остается в памяти == не прибивается.
как вариант- передача параметров так, чтоб он файл из памяти компилял в память ну или чтото подобное

Это как же так? День сидишь редактируешь, потом на вечер оставил компиляться, весь следующий день сидишь отлаживаешь? =)

типа того %)

Нет. Потому что не мазохист =). Но к диску он обращается исключительно за сорцами и инкбинами, в твоём же случае ещё и за эхешниками лазить будет, и на диск свопить промежуточные результаты (линкер), и грузить эхешники обратно в память для запуска (релоцируемый код).
if (disk == ramdisk) speed *= 5;
%)

Alex/AT

09.04.2005, 07:52

Товарищи, про рамдиск - это бред... полнейший. Ибо придем к обсуждавшемуся уже разок где-то в тредах про ОС "TRDOS+все-все-все". ОС и надо создавать ради того, чтобы отойти от структуры "свап на диск + 32к памяти". Я понимаю, почему это так предлагается - вроде как привычно. Но смею заметить, что тем, у кого есть память на RAM-диск, простое кеширование физического диска, допустим, для компилятора, даст результаты не хуже, чем сам RAM-диск.

P.S. Если такая пьянка - может и правда нуегонафиг. Добавить кеширование в TRDOS, и свапиться на диск...

Corpsegrinder

20.04.2005, 11:51

2LVD: нет реальных предложений по теме - не пиши, это опять из оперы: "нафиг спек, даёшь пц/амигу и проч.". Есть реальные предложения, хорошо, объясни непонимающим пцюзерам как амижные технологии можно без особенностей амижного порца юзать на спеке. А вообще людям интересно вот они и делают. Чего знают из других платформ, до которых имеют доступ, то и применяют, примеривают, так сказать подходы к Спеку. Жалко чтоли, пущай?

Что касается рам-диска, зачем он будет нужен, если память можно будет использовать и без него, если в ОС будет возможность межпорцессного взаимодействия помимо записи на диск? Но это тогда когда это уже будет, пока этого ничего нет, идёт просто обсуждение как это можно было бы реализовать на Спеке. Понятное дело ОС может корректным образом реагировать и на KAY-евский рам-диск и на рам-диск рил командера, но это, ещё раз повторюсь не тема данной ветки, я прав?

По теме:
Тема вроде бы о формате DLL/EXE...
проскакивала тут мысль о том, что можно в exe/dll хранить символические названия вызовов и прочего, для облегчения программирования. Я думаю именно в запускаемых модулях этого делать нет необходимости, лучше, если коэффициент (размер полезного кода)/(размер загружаемого модуля) будет максимальный, а описания вызовов будут описываться в отдельном файле вроде lib или tlb (для COM-объектов). В этих файлах можно сопоставлять текстовые описания либо с номером дескриптора в DLL/exe, либо даже со смещением относительно начала кодового блока - у кого на что фантазии хватит. Вон в MS VB как сделано, он грузит в память все TLB-шки всех ком-объектов, которые собирается использовать, а потом компилит эти слова в соответствующие вызовы. Или в MFC можно сделать Import from Type Library, в результате - класс-оболочка для вызова кода ком-объекта через его интерфейсы. Такую приблуду моно и для аласма написать, которая будет генерить исходник с кучей EQU-шек вроде этого:

; Imported interfaces/calls from blablabla.dll

; Calls
[метка из lib/tlb] EQU [соответствующее значение]

; Static varialbles
[метка из lib/tlb] EQU [соответствующее значение]

; DLL internal enums (например принятые в коде DLL соглашения по обозначению каких-то данных какими-то значениями)
[метка из lib/tlb] EQU [соответствующее значение]

lvd

20.04.2005, 13:40

2LVD: нет реальных предложений по теме - не пиши, это опять из оперы: "нафиг спек, даёшь пц/амигу и проч.". Есть реальные предложения, хорошо, объясни непонимающим пцюзерам как амижные технологии можно без особенностей амижного порца юзать на спеке.

Я собственно всеми силами пытаюсь. Даже доки выкладывал - но их очевидно никто не читал.

А вообще людям интересно вот они и делают. Чего знают из других платформ, до которых имеют доступ, то и применяют, примеривают, так сказать подходы к Спеку. Жалко чтоли, пущай?

Да нет, не жалко, но пардон, как назвать предложение сделать форк и маппинг файлов на память на спеке? =)

Что касается рам-диска, зачем он будет нужен, если память можно будет использовать и без него, если в ОС будет возможность межпорцессного взаимодействия помимо записи на диск?

А в амигаоси почему-то рамдиск есть. Вот дураки, зачем-то сделали, когда IPC есть!? =)

acidrain

22.04.2005, 12:48

А в амигаоси почему-то рамдиск есть. Вот дураки, зачем-то сделали, когда IPC есть!? =)

Вадик, не распинайся - им не понять, как удобно жить с рам диском, как на амиге. Не хотят много кайфа на спеке - их дело. мы себе могем и сами его забацать ;) Или еще проще наслаждаться амигой 8)

Vitamin

22.04.2005, 17:52

Да нет, не жалко, но пардон, как назвать предложение сделать форк и маппинг файлов на память на спеке? =)

именно так и назвать: "предложение сделать форк и маппинг файлов". почему-то предложение "сделать многозадачность" не вызывает нареканий, а вот что создание новых процессов именно почкованием- вызывает. странная логика по меньшей мере... эдак можно докатиться и до вопроса "как назвать предложение программировать под спек если в сотовике и то процессор мощнее?" =)

acidrain

23.04.2005, 11:09

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

GriV

23.04.2005, 18:12

Вадик, не распинайся - им не понять, как удобно жить с рам диском, как на амиге. Не хотят много кайфа на спеке - их дело. мы себе могем и сами его забацать ;) Или еще проще наслаждаться амигой 8)

Дело вовсе не в рамдиске, который конечно же имеет свои плюсы и недостатки.
Дело в том, что подменять системную память и системный кэш несколько странно...
А вообще, рамдиск это по сути кусок памяти организованный системой как внещний носитель. При едином подходе системы к любым носителям не будет проблем с общением ли рамдиском, ли ROMдиском и т.д.
Проблема будет только в драйвере...

P.S. Так споришь за RAMдиск, как будто отсутсие рамдиска вызовет stack overflow и general protection fault :D

lvd

26.04.2005, 12:05

именно так и назвать: "предложение сделать форк и маппинг файлов". почему-то предложение "сделать многозадачность" не вызывает нареканий, а вот что создание новых процессов именно почкованием- вызывает. странная логика по меньшей мере...

Вызывает нарекание маппинг файлов на память - который в случае отсутствия MMU сводится к обычному 'загрузил-поюзал-отписал', что прекрасно и прога сама сделает, и значит этот мапинг как функция оси не нужен. Форк клонирует весь процесс - всю его память, все данные и даже вроде все открытые файлы/whatsoever. Опять же это происходит не без помощи MMU и copy-on-write. В случае остутствия мму ты просто ничего не склонируешь - потому что 'клон' уже по другим адресам будет валяться и все его внутренние ссылки ты не поправишь.

В то же время как multitasking совершенно для своего наличия не требует MMU. Хотя вот контроллер прерываний ОЧЕНЬ желателен, как показала практика =)

эдак можно докатиться и до вопроса "как назвать предложение программировать под спек если в сотовике и то процессор мощнее?" =)
Ага, а очко в сотовике лажовее =)

Vitamin

26.04.2005, 17:37

Вызывает нарекание маппинг файлов на память - который в случае отсутствия MMU сводится к обычному 'загрузил-поюзал-отписал', что прекрасно и прога сама сделает, и значит этот мапинг как функция оси не нужен. Форк клонирует весь процесс - всю его память, все данные и даже вроде все открытые файлы/whatsoever. Опять же это происходит не без помощи MMU и copy-on-write. В случае остутствия мму ты просто ничего не склонируешь - потому что 'клон' уже по другим адресам будет валяться и все его внутренние ссылки ты не поправишь.

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

В то же время как multitasking совершенно для своего наличия не требует MMU. Хотя вот контроллер прерываний ОЧЕНЬ желателен, как показала практика =)

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

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

GriV

26.04.2005, 18:11