Hi Jamey & others,
SCSI miniports work just great under Windows 9X/ME. Only IDE driver under
Windows 9X/ME comes as full port driver (PDR). 99% of other storage
solutions are written and shipped to customers as SCSI miniports (MPDs).
Windows ME keeps the bugs (like broken file attributes when locking the
volume, attempts to alter the serial IDs of the removable media that’s
write-protected etc) for at least 5 years (from early beta version of
Windows 95). That’s why I do not think anybody in Microsoft will be brave
enough to change Windows ME storage driver model and drop SCSI miniport
support. And Windows ME will be with us (at least with some millions of us)
for next 2 years or so.
Why SCSI miniports will cause problems in future version of Windows? The
one I’ve written was designed for NT 4.0 and works recompiled under 2000
and XP w/o any source code modification. What should happen to them? Of
course there are other storage solutions under Windows 2000 and XP (like
full SCSI port drivers and STORPORT miniports) but SCSIPORT.SYS is still
there and I do not think MS will throw it away in post-XP Windowses. Of
somebody in MS told you they will?
I think SCSI miniport is the best choice when you need to design fast &
compareably low-cost (the ability to keep same source tree for Windows NT,
2K & XP and at least 90% of the source wil be the same for Windows 9X and
ME as well, rest 10% will go for very different file I/O and possibly
network stuff) virtual storage solution.
Surely fully deserialized storage drivers (like Windows 9X/ME port driver
that registers itself w/o DCB_dmd_serialize flag set and Windows 2K and XP
port drivers) can (theoretically!!! it depends of the task…) show much
better performance but their implementation will require a lot more time.
No good samples, no documentation, no support from MS, less people to ask
and so on. In the same time SCSI miniports are well documented and there
are tons of software written in this way - hundreds of people can answer
stupid questions like “Why should I set AutoRequestSense to TRUE to make my
driver work under Windows 2000?”
So the question is a usual “time or money?”. “Do you want get ready driver
in a month or do you want to wait for at least half a year before you’ll
see something working and not showing blue screens after every megabyte of
the data written to the disk?” In other words “Tiny low(but OK!)-performace
well debugged driver that costs 5K in one month VS huge high(do we really
need this???)-perfomance multi-K lines of code monster that driver verifier
refuses to verify for 30K and 6 monthes”. Most of the mangers beeing asked
with this question(s) will definitely select first solution. It’s good for
you (and me!) to discuss the things that require some time to implement in
software but most of the managers want the things to be done in “fast and
dirty” way. The model of the Universe you (and me!) belong to just does not
work for the most of the developers who have management above them and they
are not you (and me!) who are top management for themself. You (and me!)
are generals in their 10 men armies and most of the other developers are
privates in their 1000+ armies.
VERY different. You (and me!) pay with own money for own mistakes and own
job and most of the programmers get theis salaries from their companies and
pay for their mistakes with their company’s money. VERY different again…
Finally. There are no “Swiss-army knife” solutions. The performance and
“coolnest” of the solution can be affected with the time (at least!) this
solution can require to be implemented.
And SCSI miniports are not so bad -)
Regards,
Anton Kolomyeytsev
CoolDev.Com - Toolkits for Network & Storage Kernel Software Developers
“KoolSockets” & “KoolStorage” - TDI Client, Kernel Sockets, iSCSI port
www.CoolDev.Com xxxxx@CoolDev.Com xxxxx@CoolDev.Com
BTW: This will not work reliably under 9x and it will surly cause
problems in the future under NT/2000. These drivers, miniports, are not
designed for this type of stuff.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com