Вообще с "большими файлами" проблема только на уровне реализации в HiAsm: на уровне ОС нет никакой необходимости использовать отображение файла в память, чтобы работать с ними. Речь вообще идёт только об размерности свойств Position и Size.

В HiAsm вижу такие варианты:
- в данный момент свойства Position и Size позволяют работать с файлами до 4 Гб. Теоретически. На практике в наших компонентах не удастся установить позицию методами doPosition дальше 2 Гб: на самом деле позиция задается в виде смещения от начала файла, а смещение может быть и отрицательным, поэтому доступен только положительный диапазон Integer. Решается небольшой доработкой этих методов: для позиции больше 2 Гб позиция устанавливается в 2 захода методом TStream.Seek: на 2 Гб от spBegin, затем на остальное от spCurrent. Другой нюанс: нужно добавить работу с беззнаковым целым в Math (а может и не надо) и парочку методов в Converter (UIntToStr, StrToUInt).
И тем не менее, даже в нашем случае МОЖНО читать и писать данные в файлы больше 4 Гб: при чтении и записи система сама увеличивает позицию, не будет работать только Position и Size. Опять же, если добавить метод doSkip (на основе TStream.Seek(spCurrent)), можно будет смещать позицию в несколько заходов на любую глубину файла.

- написать аналог FileStream для больших файлов, а для свойств Position и Size использовать поле TData.rdata. Единственная проблема - возможная потеря точности при математических вычислениях с этими числами. Вероятно, можно доработать Math для целочисленных операций с типом double (ака Real)

- увеличить поле TData.idata до Int64, написать аналог KOL-овского FileStream, оперирующего Int64 (в новой KOL уже реализован). Правда, тогда нужно будет доделывать и остальные компоненты, типа Math, для поддержки операций с 64-битными целыми. Это немного трудоёмко, но реализуемо.