What's wrong with additional APIs? The browse folder API isn't COM based anyway.
It would be much better to use the API provided to create a namespace for the Unix filesystem. The Control Panel and Network Neighborhood are good examples of this. Quite a few third party apps create a virtual namespace for things like CVS so I don't see why we can't work in the existing API to do this with the Unix fs.
It's been a LONG while since I messed with shell extensions. However, if my memory serves me right, you cannot pass virtual namespaces to "CreateFile" and friends. The only one who knows how to work with virtual namespaces is explorer.
I wouldn't be so sure about that. On win98, in "MS-DOS Prompt" I can type
edit \server\myhome\file.txt
And it opens it just fine.
Similarly, I can type
dir "\server\shared files"
I'm sure the DOS utilities just use long file name APIs and those "simply work". It should be the same for win32 apps.
This is networking stuff, though. Now as far as virtual namespaces go, I have no idea.
This involved some {guid} stuff in the name, but I sure doubt that CreateFile would dig that.
Maybe the unix stuff can go under \__unix\something ?
Cheers, Kuba