softwarer Есть приложение, поддерживающее информацию, которая может быть представлена в виде иерархии каталогов и файлов в них
Приложение свое собственное или чужое?
Если свое собственное, то можно пойти по пути PhysicsFS - это Си библиотечка (под виндой ее можно собрать как обычную dll) которая виртуально сливает несколько архивов в одну общую файловую систему на чтение и дает один каталог (с подкаталогами) на запись. Очень удобная в использовании. Идеальна для файловых операций в макроязыках.

Ну а если программа чужая - то ой. Тогда действительно прийдется делать свой драйвер файловой системы и встраивать его в ОС... что есть не очень-то просто...

softwarerМм... прочитав эти слова и кроме того, сказанное в http://icculus.org/physfs/ , я не совсем понял, как это относится к моей задаче. Точнее, у меня сложилось впечатление, что эта библиотека решает задачу, обратную моей - представляет информацию из реальных источников в виде "виртуальной файловой системы", которую я могу читать внутри своей программы через специальное API.Ну да. Обычно от VFS это и требуется...
А обратная задача ..... эээээ...... НАФИГА?!
Если приложение сохраняет свои данные в какие-то внешние файлы, то эти внешние файлы либо обычные файлы чтобы юзера могли с ними работать вне приложения, либо какие-то запакованые/зашифрованые форматы чтобы юзера с ними не могли работать вне приложения.

softwarerМне же нужно примерно то же, что по ссылке maXmo - возможность экспортировать из своей программы "файлы", с которыми пользователь может работать через Explorer, с помощью bat-файлов и любым другим образом, который придет ему в голову.maXmo давал ссылку на программу которая решает задачу: "уже есть много реальных файлов в некоей файловой системе и надо облегчить юзерам доступ до этих файлов". А у тебя как я понял этих реальных файлов еще нету, твое приложение их еще только будет создавать.
Опиши задачу подробнее, что-то она у меня не стыкуется...

softwarerЯ хочу, чтобы юзера могли работать вне приложения с тем, что приложение не сохранило как внешние файлы.

Представь себе... ну например, performance counters. Вот только мне лень запускать приложение, выбирать в нем нужные счетчики и смотреть картинку. Вместо этого я иду в X:\Performance Counters\ и открываю там файл processor.jpg - и вижу картинку загрузки процессора за последние десять минут.Ага. Понял. Это действительно можно решить через создание драйвера новой ФС. Но на мой взгляд, это излишне сложный путь.

Есть и другой путь, более простой в реализации и более удобный для дальнейшей жизни :)
Садишь в своей программе слушателя на какой-либо tcp порт и твоя программа превращается в сервер. Потом делаешь клиентскую библиотечку и на ее основе утилитки, которые и обеспечит все запросы к внутренним данным программы. В плюсах - юзера смогут при соотвествющих настройках сети получить отчеты о внутреннем состоянии приложения откуда угодно.
Я ходил по этому пути. Вполне просто и легко.

Можно пойти по пути COM-сервера, тогда достаточно будет сделать формальное описание интерфейсов своего com-сервера и можно будет: Но будут сложности с доступом из интернета.

softwarer White OwlmaXmo давал ссылку на программу которая решает задачу: "уже есть много реальных файлов в некоей файловой системе и надо облегчить юзерам доступ до этих файлов". А у тебя как я понял этих реальных файлов еще нету, твое приложение их еще только будет создавать.
Ну и какая разница? Эта программа с тем же успехом могла бы не запрашивать файлы снаружи, а генерить их рэндомом - нужная мне технология оттого не меняется.Разница в том, что FTP протокол уже существует . FTPDrive это по существу костыль. Он делает конвертацию на лету из одного протокола в другой. А у тебя пока еще нету того протокола к которому надо делать такой конвертор.
Конечно, можно сделать свою файловую систему, но при этом, ты сознательно ограничишь доступ к приложению только тем компом на котором эта FS установлена.... Ты готов делать версии драйверов своей VFS для `98, XP, Win2003, Vista?

softwarer White OwlЕсть и другой путь, более простой в реализации и более удобный для дальнейшей жизни :) Садишь в своей программе слушателя на какой-либо tcp порт и твоя программа превращается в сервер. ......
Ага. И пользователь, который хочет в Explorer-е кликнуть на этот файл и увидеть картинку, или там например в bat-файле написать "если время последнего изменения в последние полчаса то тра-ля-ля", с восторгом пойдет создавать tcp-соединение....Зачем же создавать собственное соединение? Из батника он позовет утилитку с параметрами и она в stdout или errorlevel положит значение. А из эксплорера юзер ткнет в ярлык программы которая то-же самое значение отрисует графически, а при нужде сможет и повиснуть на десктопе и постоянно обновлять картинку.

softwarerНо повторное предложение вызывает вопрос: ты таки читаешь, что нужно, или говоришь о чем-то своем?Читаю и понимаю что нужно, но не понимаю зачем это нужно. На мой взгляд, в этой постановке задачи ты ограничиваешь себе возможности . В конце концов, если так сильно хочется виртуальный драйв, то можно будет сделать его и позже на основе клиент-серверного протокола который я предлагаю, тогда этот виртуальный драйв можно будет запускать даже на удаленном юзерском компе. А не только на той же самой машине что и супер-программа.

FTP сервер softwarerДА, ИМЕННО ТАКОЙ КОСТЫЛЬ МНЕ И НУЖЕН.а может применить уже упомянутый FTPDrive, а в своей программе сделать костыль в виде FTP-сервера?
Заодно и доступ с других компов будет возможен.вот, действительно. Половина задачи уже решена :)

softwarer2. Жаль, что ты не на миг не задумался о том, что "суперпрограмма" может и сама по себе быть клиентом некоего сервера. И предложение делать ее еще и сервером для "клиентов второго уровня" вызывает.. некоторое веселье.Об этом сразу надо было бы говорить, я бы со своей идеей не вылезал бы...