> This does not sound like a filter driver (a “filter” modifies the behavior
of an existing driver. What you describe sounds like a new FSD, not a
modification layer over an existing FSD.) Is it possible you could
implement this as a shell extension (that is, do you ONLY need it to work
with Explorer?)
Are you saying that if I can get away with a limitation of NO access from a DOS
box, I’d be able to do this with a shell extension? If so, what type of
“handler” would the extension be? Would it actually be a shell namespace
extension (the MSDN Lib seems to indicate that this wouldn’t work for a device
with real files)?
If not, you’ll most likely need an FSD. The FSD model between Windows 9x
and Windows 2000 differ considerably (although I’m sure that with sufficient
time and development resources you could MAKE them appear the same.) There
are LOTS of reasons for this, but let’s just leave it at “the two OS
platforms are VERY different.”
I see that OSR sells a FSD kit for NT/Win2K. Do they also sell a kit for Win9X,
or are you stuck using the MS IFS DDK for Win9X?
For the sake of discussion, for the device we’re talking about, what would be a
rough estimate of the time required to write an FSD with and without the OSR kit
(assuming the developer was an experienced DDK-level developer)? The device is
accessed with commands like WriteFile, ReadFile, DeleteFile, MoveFile,
CreateDirectory, …, and does not provide any type of block interface.
Thanks for the help,
-Chris
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com