Folkert,
I'm not entirely sure what the other poster meant by that "not true" remark either, but I think it was in response to something that
the original poster, Martin, had said about SPTI "not being very good". If so, then I agree with you, that's not true at all. SPTI
is, in fact, a great interface. As you know, it is the "native language", if you will, for communicating with SCSI devices on NT
and beyond. It is architected into Windows, and is the recommended way of designing new applications that send custom commands to
SCSI devices (including SATA, Fibre Channel, iSCSI, USB, 1394, etc.).
But ... it's non-trivial to work with. It has some quirks that are only discovered after many hours of programming. The
applications that use it must be run from an Admin account. It does not support asynchronous completion. It's not well-documented.
So there are actually some downsides that can cost developers that are new to the topic a *lot* of time.
ASPI is simply a different interface spec for sending SCSI commands. It has been around for much longer, and is much simpler to
use. And there are a *lot* of applications still out there in the field that use ASPI.
So is ASPI dead? Absolutely not. What people seem to have a hard time understanding is that the "interface" is not the same thing
as a particular "implementation" of that interface. These are two very different things, and once you make that distinction, it
becomes clear that some vendor's "implementations" are indeed dead. And as new applications are written, developers may
increasingly choose not to use the ASPI spec for that very reason. But that does not necessarily make the ASPI interface spec
itself dead, right?
For example, the most pervasive implementation of ASPI comes from Adaptec. But it has some problems, and there are some support
issues, etc. So as a result of that, many vendors, including my company, have written alternative *implementations* of the ASPI
spec.
Rob's product is similar, although it sounds more like his product uses his own custom interface, not ASPI. That's fine, too, if
that's what the customer wants. And it probably works great, because Rob has been around for awhile, and knows his stuff. But if
the customer already has an app that has been written to the ASPI spec, and simply wants to convert it so that it now uses SPTI,
then what the customer really needs is an ASPI Emulation Layer, not a new custom interface.
The NexiTech ASPI Emulation driver converts ASPI to SPTI, solves the Admin-only problem, works with more devices than most other
ASPI implementations (iSCSI / SCSI / SATA / FC / USB / 1394), and is easy to license. Source code is available. There is even a
VxD-based Win9X version.
I've had customers tell me that they went out and did their homework and got quotes from driver experts on what it would take to
build something like this from scratch. They typically say something on the order of 500 hours. I'm also one such driver expert,
and I agree completely. It could take at least that long, maybe longer, for someone to start from scratch and roll their own and
get something that is production quality software. You do the math. If it's a "make" vs. "buy" decision, it can certainly be a lot
more affordable to just license a library from someone like Rob or me, rather than creating it yourself.
Thanks,
Don
Don Matthews
President
NexiTech, Inc.
719-687-3225
***@nexitech.com
www.nexitech.com
Post by Folkert RienstraNot true what, topposter?
Post by The MoojitSPTI should do everything you need. Mr. Turk's library will save
you much time, SPTI is not straight forward.
The Moojit
Post by Martin VorbrodtIs there no other alternative? Your library? Other libraries? What does your
library use? What about future support? Will ASPI run on Vista? XP-64?
From what I read, SPTI isn't very good... doesn't it require administrative
privilages to be used? It is a part of the DDK, not SDK right?
About your library... do you have a web page? More information on it?
Licencing? My company might be interested ( more info to
Martin
Post by Rob TurkPost by Martin VorbrodtWhat then? Is there an equivalent replacement? SCSI Pass-Through maybe? How
else can I do SCSI on Windows then?
Martin
There's always SPTI, the Windows native SCSI passthrough mechanism. It's
documented in the Windows SDK. I've written C libraries to access SCSI
devices on Windows (both through ASPI and SPTI, but also Solaris, AIX,
Linux, MacOS-X with the same API), if you're interested in purchasing a
license you can send me an e-mail off-list.
Rob