Вторым. Первым -- определённые соглашения о вызове и загрузке.Сообщение от valker
Иначе две программы из банка не подружишь. Если они в ассемблере,
конечно немного проще. Лишь немного. Потому как любой программный продукт имеет срок жизни до тех пор пока он
сопровождается и поддерживается. Что невозможно без динамической компоновки практически. На FreeBSD до 5.0 посмотрите -- у них на всё make world. У нас world на дискетку
не поместится...
Позарез как нужна ДИНАМИЧЕСКАЯ КОМПОНОВКА. Ибо те
же драйвера cmos, hdd, модема -- у всех свои и несовместимые.
Несовместимые по интерфейсу. Функции одни и те же практически.
Нужен некий стандарт как на "дизайн интерфейса", не знаю как
это назвать, вроде соглашения о передаче параметров, техники
собственно вызова и т.п. Нужен унифицированный способ
динамической загрузки и статической компоновки расширений.
И наконец нужен какой-то способ идентификации интерфейсов,
что-то вроде COM и виндов.
Да. Но возможно и немного наоборот, когда выбирается1. Конфигурация компьютера (ZX48; ZX128; S256;...),
2. Модель памяти (SOLID; CODE_IN_LOW_MEMORY_DATA_IN_BANK; CODE_AND_DATA_IN_BANK;...),
3. Доступные внешние устройства (DOESNT_USE_EXTERNAL; FDD; HDD_SCRP; HDD_NEMO; KEMP_MOUSE;...),
4. Зависимости от системных библиотек (DOESNT_USE_SYSTEM; ...),
5. Режимы работы прерываний (INT_MUST_BE_DISABLED; INT_CAN_BE_ANY; HAVE_ISR;...).
Список, естественно, примерный.
Каждая единица (модуль, процедура, библиотека), снабжается метками, указывающими на границы применимости.
Например:
ZX48 SOLID DOESNT_USE_EXTERNAL DOESNT_USE_SYSTEM INT_CAN_BE_ANY - Процедура удовлетворяет требованиям ZX-Spectrum 48, при этом не требует ни внешних устройств, не использует процедуры из ПЗУ, не зависит от режима прерываний.
Это позволит тщательнее подходить к вопросу совместимости различных модулей, и выбору "платформы" для программы.
IMHO...
версия процедуры применимой в указанных условиях.
Или выбирается ошибка.