Assasin, А где работа с большими файлами

Не, не! SharedStream забирать "низя" Это просто, я один такой "тупой" и "ленивый", что не разобрался в нем!

А этим кто-то пользуется? Впрочем да, этого я вообще не учел. Я хотел составить простую в понимании модель IPC для хиасмера, а для работы с большими файлами можно оставить оригинальный SharedStream, только назвав его как-нибудь иначе. Типа VirtualStream.

Кхм... Прошу прощения И "типа" все сразу поймут как им пользоваться?

Нет, я лишь предположил, как можно решить проблему открытия больших файлов, при этом реализовав и упрощенную модель IPC для хиасма.

Тогда уж лучше FileMapping (и че я его так сразу не назвал ???)

[offtop]
Хорошая мысля приходит опосля [/offtop]
Кстати, если развивать предложенную мною модель IPC, можно туда же еще добавить простейший интерфейс функций (на основе компонента Event): добавляем компонент IPC_Event со свойством "имя события" и единственной точкой: onEvent (событие происходит, когда другой процесс его вызовет). И еще один компонент: IPC_CallEvent с аналогичным свойством и точкой (только слева - чтобы вызывать событие).
Кстати, вот и перфикс готов для новой группы компонентов: IPC_XXX.

И этот форум окончательно попадёт в чёрный список распространителей вирусов.

Assasin, кончай фигней страдать.

Тебе предложили ОДИН элемент, про функционирование которого и написать то больше нечего, кроме того, что я уже написал.
Ты же говоришь, что слово "окно" недоступно для твоего понимания, и предлагаешь "продвинутую технологию" в которой уже не меньше двух элементов.
И которая обладает своими ограничениями.

Кстати, сколько типов "переменных" ты предлагаешь ???
На каждый тип своего клиента делать ???
А если размер типа заранее неизвестен (типа dtAnsiString) ???
И наконец, кто сказал, что файл состоит из каких-то "переменных", прости господи...

И вот именно это ты считаешь более простым, чем "когда уже все есть" (в DataToFile[Ex]).
Так что ли

Вообще с "большими файлами" проблема только на уровне реализации в 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-битными целыми. Это немного трудоёмко, но реализуемо.

Netspirit, а скажи мне как гинеколог гинекологу: ты коды SharedStream смотрел

Нет, не смотрел. А что?

Там нет проблемы с терабайтными файлами.

Окно - да, 2Гига максимум. И мы пользуемся (в смысле - можем пользоваться) нашим любимым стримом для чтения/записи/добавления. В "окно".
А Offset имеет 56 бит мантисы. Это 32 квадробайта.
------------ Дoбавленo в 12.50:
Т.е., все уже есть, по большому счету-то.
Надо не добавлять, а просто выкинуть лишние (субъективные) заморочки.
И все.

А вот количество выделяемых страниц памяти я не стал бы убирать, от этого очень сильно зависит быстродействие всего процесса

То-есть, по факту Что и предлагаю сделать для обычных стримов и не париться по поводу размера файла.

Как я понял, в системе суть SharedStream - не работа с большими файлами, а некоторый BufferedFileStream. При необходимости BufferedFileStream можно и у нас реализовать аналогично FileStream.