> -- Иван Кузьмицкий писал(а):
> достаточно просто не класть в комплект соответствующие модули и ресурсы.
В WinAOS вообще нет подсистем. И не страдают.

emb и dir встраиваемые части
mgr программерская
host платформозависимая
std утилитарная
app базовая

Конечно, если намеренно говорить "А можно ли использовать app отдельно?" всегда будет за что потыкать. Это зависимость, запрещать зависимости теперь чтоли?
Можно использовать emb без mgr, можно не использовать ни emb, ни dir, ни mgr, и при этом останется возможность написать своё приложение для JU.
> -- Иван Кузьмицкий писал(а):
> файл JUhost\Mod\Analyzer перенёс в Ju\Mod\HostAnalyzer, читаемость не уменьшиласьЭто субъективно.
> -- Иван Кузьмицкий писал(а):
> В доке ББ предлагается коллекцииЯ уже разбирал это определение в рассылке ББ в споре про O3, в определении никак не ограничивается состав компонентов, если у меня компонент в виде двух подсистем, никто этого не регулирует и не предопределяет законы по размещению модулей.

Картинка должна быть такой

Тогда понятно, что существуют вполне очевидные пользовательские службы, которые имеют разные цели. Объединение JUapp и JUstd будет нарушать схему, в которой появляется JUsuperApp, которое использует только стандартные модули JU, дополняя сущности app новыми.> -- Иван Кузьмицкий писал(а):
> все подсистемы JU сейчас компилируются единым списком из JUstd, а это говорит о том, что чисто логически JU - единая подсистема, а не агрегат из шести раздельных подсистем.Это наследие кровавого монолитного прошлого, удобнее компилировать из одного списка, и, это не единая подсистема.