В нулевых - CMS и сейчас живет и прекрасно себя чувствует на z/VM (которая и есть очередная версия VM/370). Это ни разу не легаси. Во-первых - надо понимать что изначально CMS умела работать на "железной машине". На паравиртуализацию ее перевели где-то в середине 70-х, когда связка VM/CP + CMS окончательно устоялась и издержки от полной виртуализации захотелось уменьшить. Так по дизайну это вполне классическая однопользовательская система "с полным доступом к железу". Во-вторых - там что интересно - что при всей технологической примитивности подхода он отличался офигенной гибкостью - там основным способом общения кода друг с другом это - "команды" - именованные обработчики с блоком параметров. Фактически процедура с динамической привязкой - если команда зарегистрирована - то вызываеься (либо подгружаясь с диска, либо если в памяти - напрямую) соответствующая программа. Обработчики ("фильтры команд") могут более сложную логику осуществить - обычно поискать файл с кодом на диске и подгрузить (или если это скрипт - напустить интерпритатор скрипта). В принципе не намного дольше обычного вызова процедуры. Если кому-то очень надо он может получить физический адрес и вызывать просто как процедуру (это геморрой - но на деле там где нужен перформанс снижал и без того небольной оверхед в разы). Кстати - там это общий подход - с файлами тоже самое - обычно файлы не открывали и не закрывали, а просто говорили читать/писать такую-то запись из файла с именем таким-то. Открытие файла просто оптимизация ускоряющая эту операцию Кроме этого - обычно более или менее сложные программы (типа (XEDIT) регистрировали тн подкоманды - команды, привязанные к обработчикам внутри программы. ХEDIT так например экспортировал практически весь свой внутренний интерфейс - в результате чего скрипты и макросы к нему можно было писать на чем угодно - хоть на асме, хоть на REXX (собственно на деле скриптовых языка в 80-е там было три - бейсикоподобные EXEC и EXEC2 и REXX, который на нынешние деньги назывался бы PL/I-Script, мешать их может в произвольных сочетаниях, равно как и кодом на других языках), хоть на Алголе-68 (без всяких шуток - функции сжатия-распаковки текстовых файлов на лету у нас так и реализовали - благо компилятор поддерживал) Опять же можно зафиксировать программу как "расширение ядра" - тогда она постоянно сидит в пространстве ядра и ее подкоманды и она сама доступны моментально - мелочь но в некоторых важных частных случаях опять же резко снижает оверхед. На уровне пользователя это было незаметно - там просто очень гибкая, офигенно быстрая и удобная система (опять же стаднартной практикой было оборачивать программы в "пусковые" скрипты, которые разбираются с параметрами etc - А-68 емнимп запускался примерно 150-строчным скриптом на EXEC2 - у него были фанаты напиравшие на то что "пусть безобразно и нечитаемо, зато на 20% быстрее"). Собственно большая часть подсистем (типа работы с сетью etc) там так и сделана - именно как расширения. Продолжение возможно следует.