Всё очень просто: обычно мы работаем с файлом посредством функций API, а здесь ты работаешь с файлом, как с участком памяти. Когда оно реально в файл сбросится - тебя не должно волновать (самое позднее в момент закрытия файла). Естесственно, при открытии файла можно его не блокировать от доступа из других процессов, а также задавать режим работы (чтение и/или запись). Как долго данные будут находиться в памяти - тоже неизвестно, так что насчёт быстродействия ничего не могу сказать.
В общем и целом, это аналог файла подгрузки (pagefile.sys) в винде.

hook.dll первых версий был на FileMapping сделан. Использовать эту технологию смысла не имеет, поскольку никакой синхронизации доступа на запись там нет и соответсвующих событий тоже. В компиляторах С++ от Microsoft эта фишка была некогда встроена в препроцессор и разрешалась на уровне соответсвующих pragm. В общем цивилизованный обмен данными надо делать на pipe.

Это случаем не то, что Dilma использует в Hiasm'e, для чтения IC в редакоре

------------ Дoбавленo:



Я пытался, но он сволочь не работает в трее -- данные не передаются, боюсь, что в фоне тоже не будет, надо проверить.

А все же может закончить PIPE модули, хотя, они уже работают, правда, в однй сторону -- от клиента к серверу

------------ Дoбавленo:


Да и нужен ли двухсторонний обмен, не проще ли поставить второй сервер в обратную строну

Типа: посмотри в столе соседа, в своем всегда успеешь

Читай Рихтера
Это самый низкоуровневый способ межпроцессного обмена данными в винде
Следовательно - самый быстрый
Грубо говоря, все остальное сделано на нем, и на мьютексах
Как делать синхронизацию на мьютексе, опять - читай Рихтера (у нас он для этого совсем не приспособлен)

У нас могла бы быть дополнительная польза: такой элемент мог бы делать кадр (Stream) с супер-большого файла (int64)
И все любители 100 гиговых файлов - пусть пользуются. Типа: хай гнида подавится....

Вот я и просил прояснить тему
Бум читать мат часть.

Вот это я, как раз, и читал. Все руки не доходят сделать, да и реализация не совсем еще сформировалась

Оригинальное предложение по теме

------------ Дoбавленo:

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

Ну так читай же
Если две алгоритмические ветки от РАЗНЫХ потоков проходят через одноименные мьютексы, то они совершенно спокойно могут работать с какими-то данными не опасаясь конфликта.
Он сделан для этого, это его основное назначение (у нас не применяемое).
Грубо говоря, если один поток работает УЖЕ справа от первого мьютекса, то второй будет спать (во втором мьютексе) до окончания работы (справа от первого мьютекса) первого потока

Эти разные потоки могут находится и в разных процессах.
Вот и все, собственно


Самому уже пора для остальных прояснять

я уже расказывал про технику редактирования скриптов в среде. К FileMapping она никакого отношения не имеет и ни к каким системным фукциям тоже.


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

Это врядли - он базовый
На нем все построенно.

Да собственно, чего может быть фундаментальней - это физически один и тот же кусок памяти, к которому имеют доступ разные процессы
Просто НЕТ никаких вызовов API для проведения обмена....

Такое не пропьешь

Ну не все же. Просто, я тихонько начинаю копать следующий слой...
------------ Дoбавленo:


Вот, что пишет Рихтер по этому вопросу (то, о чем говорил Galkov)

Вот то, что самый низкоуровневый метод не всегда самый удобный, это, конечно - правда

Но тут думаю, есть несколько моментов:

иногда, все-таки, может оказаться и удобней, всякое бывает: хочу очень просто, но быстро...

он ни в коей мере не должен выступать как какая-то замена, предположим - MailSlot-у

и такой элемент может прикрыть вопрос работы (через стандартный наш Stream) с очень большими файлами
Это я к тому, что такой элемент, без претензий на решение всех проблем, может оказаться очень полезен
Вот и все, ничего особенного

Единственное, что тревожит, что проекции физических и виртуальных файлов, хотя и используют одни и те же функции, но по сути немного разные вещи и преследуют разные цели. Короче говоря, для работы с физическими файлами и их проекциями нужен один компонент, а для работы с виртуальными проекциями для обмена данными -- другой
------------ Дoбавленo:


Вот то, что это самый быстрый метод обмена данными, то это -- точно, тк как работает напрямую со страницами памяти

Не говори ерунды
Это не "немного разные вещи", это одно и то же.
Настолько одно и то же, что программист этого может не заметить: открывает файл, и не проверяет результат (ленивый потому-что) - а получает INVALID_HANDLE (не зная этого), подставляет дальше, и все работает (в т.ч. и из разных процессов)
Посмотри, там примеры на это счет должны быть

Есть два св-ва: имя файла, и имя проекции (имя объекта ядра доступное из любого процесса).
Если имя пустое (или просто - такого файла не существует) - значит только память.
Если файл существует, то не только память, но и +синхронизируется с содержанием диска.
Вот и вся разница.
И нет тут никакой проблемы.

Galkov, я не это имел в виду, и что INVALID_HANDLE создает виртуальный файл в памяти тоже знаю. Я хочу попытаться сделать мух отдельно от котлет -- для работы с физическими файлами один компонент, для работы по передаче данных между процессами -- клиент/сервер с виртуальным файлом (у Рихтера, кстати, это отдельные примеры).

Если ты сделаешь компонент для работы с "физическими файлами", то он БУДЕТ работать с памятью при подстановке имени не существующего файла.
Просто будет, и все.
Какой еще компонент ты после этого делать собрался, и, интересно - зачем

Чего ты людям (или себе) голову морочишь, не пойму...

Конечно будет, если мы не отследим INVALID_HANDLE, а передадим его дальше в создание проекции. Тут вопрос другого плана, как синхронизировать приложения при изменении данных

------------ Дoбавленo:


Ну еще выдержка из книги в подтверждение слов Galkov'a



------------ Дoбавленo:


Все же я остановлюсь на этом методе, очень интересная тема. Не важно что получится -- один компонент или несколько, важно что бы работало, особенно интересно, что бы работало из сервисов не затрагивая оконные сообщения.