Because I know that Window's "Zip" utility seemed to "project" into Windows Explorer. I don't know if that's a Windows Explorer plugin, or if its this file system.
That was a feature of windows explorer not the filesystem. It worked by copying the file to a temporary location. That's why if you tried to launch an exe from a zip file it would fail to find any DLLs packed with it.
Windows Explorer since very early (95-era) has supported complex "Shell Objects" and a COM-based Provider model for showing and interacting with "folder-like things" in Windows Explorer (and some other file-system APIs and tools that support it). In addition to "Zip" folders, it's what the old school Control Panel used for a long time, and Windows WebDAV support, and a lot of other things over the decades.
This new API seems a very different approach than the classic Shell Object provider model. It is directly rooted to the filesystem as opposed to the wider "object space" that Windows tracks, and it includes more things like concerns for converting virtual objects into physical NTFS files (and back).
7 comments
[ 4.6 ms ] story [ 28.5 ms ] threadBecause I know that Window's "Zip" utility seemed to "project" into Windows Explorer. I don't know if that's a Windows Explorer plugin, or if its this file system.
This should make features like that much better.
This new API seems a very different approach than the classic Shell Object provider model. It is directly rooted to the filesystem as opposed to the wider "object space" that Windows tracks, and it includes more things like concerns for converting virtual objects into physical NTFS files (and back).
https://docs.microsoft.com/en-us/windows/desktop/api/project...
"Minimum supported client: Windows 10, version 1809 [desktop apps only]"