Вообще-то, в BlackBox существует несколько способов создать конечное приложение:

1) Скопировать файл BlackBox.exe, переименовав его во что-то свое. Скопировать те файлы, которые нужны для работы вашего приложения. (Какие? см. выше, но там список с некоторым запасом. У подсистемы Dev особый статус. Когда ББ был коммерческим, ее распространять запррещалось. Сейчас - GNU, но все же... Если ваше приложение использует Dev, то это квалифицируется как наибольшая зависимость его от среды, со всеми вытекающими...) Подправить файл System/Rsrc/Menus, дабы меню были свои. Затем подправить модуль System/Mod/Config, в котором определена единственная процедура Setup - она вызывается при запуске. Оттуда можно убрать команду открытия окна Лога и привесить что-то свое. Чтобы выполнить что-то до запуска графического интерфейса, надо создать аналогичный модуль Startup. Ну, там ,например, можно изменить название главного окна приложения (чтобы оно отличалось от имени exe): Dialog.appName := "My Advanced Application". С русским названием следует быть осторожным - у нас возникли проблемы с сохранением настроек (HostRegistry использует для этого ветку как раз с именем oberon/appName). Но это мелочи, если понадобиться, можно русифицировать, не такое исправляли
Приложение так и остается в виде множества модулей. Преимущества? Для большого пакета - легкость обновления и расширений, что, собственно, и является коньком Оберонов. Что делать, если не хочется такой "лапши"?
2) Все то же самое, но отобранные кодовые файлы компонуются в EXE. То есть, вся среда BB пересобирается под нужды вашего приложения. См. документацию DevLinker. Проще пареной репы. Я лично не сторонник статической компоновки всех модулей, но использую Linker для пересборки exe-шника с другими значками.
В этом случае все ресурсные файлы остаются лежать открыто.
3) В дополнение ко всему предыдущему - упаковать часть или все файлы (это могут быть и кодовые, и ресурсы) в exe-шник DevPacker-ом, создав в нем виртуальную файловую систему. В полном смысле этого слова. Возможны интересные фишки, когда в exe-шник зашиваются файлы по адресу, например, Z:\myfile, и они будут доступны под этим адресом из программы, даже если на машине такого диска нет вообще. То есть, файлы виртуальной системы перекрывают собой реальные, а если в ВФС файл не найден, то потом уже он ищется в реальной ФС. КОдовые файлы, в отличие от скомпонованных статически, будут все равно подгружаться динамически, но уже из ВФС (имхо, применение этому найти трудно).

Если ваша программа использует GUI, то нужно нести (открыто ли, линкованно ли, пакованно ли) Form, если используете тексты, то Text, и т.п. И интерфейс будет работать в MDI-варианте.

Совершенно другой вариант: отвязаться от всех или части стандартных подсистем ББ и написать именно то, что нужно. Через WinAPI, например. Ядро можно пересобрать как угодно! Можно сделать классический экзешник для безоконного (или оконного, зашив туда вызовы к WinAPI и цикл сообщений) приложения очень маленького размера. Можно собрать exe только из своих файлов, не включая даже Kernel! Тогда не будет работать сборка мусора, динамическое выделение памяти, динамический контроль типов и т.п., но для небольших сверхбыстрых приложений это может оказаться тем, что надо. Память все равно можно выделять через вызовы к ОС и небезопасные указатели SYSTEM.ADDR.

И это еще не все... Где искать информацию? Начать с Руководства пользователя-Подсистема Dev. Далее - DevLinker и DevPacker. И, на закуску, Особенности платформы (Platform-Specific Issues).

Но легко сделать не-MDI интерфейс сейчас нельзя. У нас есть задумка сделать вариант подсистемы Host (эта, так сказать, OS Abstraction Layer в BlackBox), которая создает не MDI, а свободные окна, по типу Дельфы. Это, имхо, не очень сложно. (Создание главного окна и цикл сообщений там стоит в HostMenus)