Формат EXE/DLL для новой ОС

[Vitamin]

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

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

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

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

[lvd]

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

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

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

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

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

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

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

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

а ты пробовал компилять большой проект в аласме на 128к? сколько раз к диску обращается?

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

[Vitamin]

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

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

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

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

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

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

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

типа того %)

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

if (disk == ramdisk) speed *= 5;
%)

[Alex/AT]

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

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

[Corpsegrinder]

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]

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

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

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

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

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

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

[acidrain]

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

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

[Vitamin]

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

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

[acidrain]

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

[GriV]

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

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

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