OberonCore

Если коротко, то загружать целиком файл в цельный массив можно только в том случае, если его размер ограничен небольшим числом согласно задаче. В таком случае можно взять статический массив. В ином случае, нужно использовать что-то иное вне зависимости от того, есть в языке динамические массивы или нет. Как выглядит "гениальное" решение загружать весь файл в цельный массив можете лицезреть в большинстве редакторов при попытке открыть большой файл.

Универсального решения нет и всё зависит от задачи. Иногда достаточно окна - небольшого буфера, в который загружется нужный кусок, иногда - связный список таких окон для последовательного доступа. Если нужен моментальный произвольный доступ, то из таких окон строится "расстановка", он же hash array. Если нужна бОльшая гибкость - то дерево.

Спасибо за советы, думаю, что они пригодятся.

Реализуйте Files.File над памятью!
Или возьмите готовый!
Тут viewtopic.php?f=23&t=4214

Когда я их писал, я ещё не смотрел на WEB API для считывания содержимого файла, что важно для Вашей задачи. Выяснилось, что в нём не предусмотрено порционное чтение, а только всего файла целиком в динамический массив. Это делает мои советы бессмысленными для WEB.
Тем не менее, с файлом всё равно удобней работать не меся байты напрямую, а используя абстракцию файла.

Почему бы не создать пакет для работы с файлами, как они на диск отображаются? Блоками!))
А блоки связывать в один список. Разумно было бы размер блока сделать в несколько килобайт, чтобы снизить накладные расходы.
Получится "квази-динамический массив" пригодный для практического применения)))

Ну так реализации Files.File в памяти так и устроены.

Либо я ещё из ума не выжил, либо в психушке сидят только те, кого спалили))

Идея, имхо, просто просится в реализацию именно таким способом))

Да, только файлы бывают и по 5 Гб и больше, а память адресовать можно только 2 Гб. Files.File может работать с такими большими файлами?

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

Здесь нельзя путать понятия "аппаратная адресация" и "логическая адресация". Если абстракция не течёт -- то о таких мелочах программист не будет думать от слова "вообще". Хотя, если программист захочет САМ, то конечно, он может при таком желании покопаться в кишках этого механизма. Но ни один грамотный специалист в добром здравии не захочет этого делать.

Тип LONGINTEGER -- 8 байт 2^64=18446744073709551616 (18 * 1024^6)(16 эксабайт или 8 эксабайт в обе стороны при индексном позиционировании от центра) , NTFS позволяет файлы 8 эксабайт, Ext4 -- 16 терабайт. Так что, гигабайты уже кажутся смешными и проблема вычислительной мощности опять упирается в проблему ввода/вывода)) Компонентный Паскаль со всеми проверками и огребаниями памяти от мусора всё-равно будет быстрее чем дисковый ввод вывод))

Изначальное желание Ивана было загружать файл в память целиком. Для таких методов работы в общем случае возникает множество проблем, в том числе указанная Вами. Для Оберон-07 скорее всего нет готовой реализации Files.File, но при создании такой нужно заложить возможность работы с большими файлами.

Если говорить про Блэкбокс, то это возможно после небольшой модификации ББ.
Демонстрационная версия лежит в отдельной ветке в Центре
http://blackboxframework.org/unstable/master64

Тема посвящена вот такой задачке:
https://models.molpit.org/model/71
Работа с аудиофайлом в JavaScript.

АЧХ звукового файла?
Спектр сигнала может быть?

Ну да, фурье спектр сигнала, но почему-то в Интернете часто это называют АЧХ, хотя АЧХ скорее для аудиколонок и наушников применяется. Пожалуй я стал жертвой собственного заблуждения, так что исправлю сейчас. Спасибо за замечание