Reputation: 316
I have been using Pismo File Mount for many years, and I have always wondered how it actually works.
Let's say, I am currently working on an application that creates a package format similar to the ZIP format. For ease of access, I want to create a shell extension that works similar to how Pismo File Mount works. For those who have not used Pismo File Mount before, this is how it works:
There's a catch. I do not want to use the Pismo File Mount API, perhaps for various reasons like commercial or legal ones.
The question is, how does Pismo File Mount integrate itself into Windows Explorer programmatically, in terms of the Windows API and C++?
Upvotes: 4
Views: 2012
Reputation: 1119
I wrote Pismo File Mount, and the ZIP reader included in the PFM Audit Package.
There is no consise or realistically postable answer to the question. To do what PFM does, in C/C++, to Windows API's (kernel and user), it would take 10's of thousands of lines of difficult code and a large time investment.
PFM is built as a file system driver (kernel module), with user mode support DLL's and executables. The driver uses a protocol to talk with user mode formatting code that (for example) decodes the ZIP file format and serves the contents through the kernel mode driver to client applications.
Upvotes: 3
Reputation: 46080
There exist two ways:
Shell namespace extension. The folder created by the shell namespace extension is not an actual filesystem folder and accessibility of the files in such folder is usually limited to Explorer itself and applications aware of shell extensions and the ways to work with them.
Filesystem filter driver which creates a virtual directory on the existing disk. Such directory is seen by all applications as a real directory, where those applications can read and write files and subdirectories. All filesystem operations go through such driver.
Pismo File Mount works via the filter driver, AFAIK.
Our CallbackFilter product provides a way to create virtual directories and files. It includes a driver and calls your user-mode code for actual operations. But filter approach is a bit complicated -- a virtual disk created with a filesystem driver (eg. with our Callback File System product) is easier to implement and manage due to differences in architectures of the filter driver stack and filesystem drivers.
Upvotes: 2
Reputation: 180135
Sounds like a fairly ordinary shell extension. Explorer has a powerful extension mechanism which allows it to list non-file objects such as Printers and the contents of a zip file. The particular details (columns and rows) are provided by a DLL.
You can observe this by zipping up a set of images; the ordinary thumbnail view probably won't work as that part of Explorer is usually not copied.
Upvotes: 1