Peter Wieland [MSFT] Software Developer at MS says, “So there are
two ways to send a SCSI request. One for kernel-mode components
(IRP_MJ_SCSI) and one for user-mode components
(IOCTL_SCSI_PASS_THROUGH[_DIRECT]).”
He goes on to say, “If you want to convert a pass-through command
to a IRP_MJ_SCSI command it’s pretty straight-forward to make an
SRB and send it down.”
What does he mean exactly? I have an application that sends scsi
commands to DVD devices in user mode via
IOCTL_SCSI_PASS_THROUGH_DIRECT (CDBs).
Would it be an advantage for me to send SRBs instead?
Does he mean I can do it from user mode?
Or that it would be easy for me to implement using a IRP_MJ_SCSI
to send SRBs?
I’m only interested if it would mean improved dependability &
stability. I’ve read more than one device driver developer’s
unfavorable comments about MS’s SPTI i.e.
IOCTL_SCSI_PASS_THROUGH[_DIRECT] and
particularly cdrom.sys, the default driver for CD/DVD devices.
bilm
wrote in message news:xxxxx@ntdev…
> Why not use IMAPI?
>
>
IMAPI is MS’s interface to the low level scsi commands documented
in T10’s MMC v.6 & Mt Fuji Group v.7 found at
http://www.t10.org/drafts.htm#MMC_Family
and
ftp://ftp.avc-pioneer.com/Mtfuji_7/Spec/
I use these same commands in my app. It gives me much more
flexibility. And gives me the ability to change and improve read,
write and all the supporting routines for speed and accuracy.
Also IMAPI does not have a good history for dependability.
Even version 2. I don’t know what transport IMAPI uses.
I’d guess it has to use the SPTI just like me but I could be
wrong.
bilm
wrote in message news:xxxxx@ntdev…
> Why not use IMAPI?
>
>
Just wanted to add that I’ve worked with this subset of scsi
commands called the MMC (multi media commands) for a few
years now and about every 6 months or so there are changes
and additions to them. I know from past history that MS is very
slow about keeping up with these changes; sometimes even years
behind the times.
By using my own library of these commands, I can easily update
it to the latest changes.
bilm
Thanks for that. I didn’t understand that this library written for the purpose just such as yours is so inadequate that bypassing it is a more effective solution.
So to answer the question, no you can’t send an SRB from user mode. The only way to do that would be to write a driver and have the driver send the SRB on behalf of the application. But in the optical drive case I doubt there would be an advantage of using an SRB provided you have compensated for issues surrounding the use of pass through.
I don’t see how you could create a SRB in user land. It requires access to
information only available in kernel mode. Sending a CDB with SPTI is the
only available method from user land. In a driver you could send a full SRB
to the driver that owns the hardware (disk/CD/DVD/Blue Ray).
I guess you or your company are too cheap to buy the final specifications
for SCSI and MMC. They have restricted access to the latest specifications
on T10 when the ANSI/IEEEE? versions are published.
“bilm” wrote in message news:xxxxx@ntdev…
wrote in message news:xxxxx@ntdev…
> Why not use IMAPI?
>
>
IMAPI is MS’s interface to the low level scsi commands documented
in T10’s MMC v.6 & Mt Fuji Group v.7 found at
http://www.t10.org/drafts.htm#MMC_Family
and
ftp://ftp.avc-pioneer.com/Mtfuji_7/Spec/
I use these same commands in my app. It gives me much more
flexibility. And gives me the ability to change and improve read,
write and all the supporting routines for speed and accuracy.
Also IMAPI does not have a good history for dependability.
Even version 2. I don’t know what transport IMAPI uses.
I’d guess it has to use the SPTI just like me but I could be
wrong.
bilm
“David Craig” wrote in message
news:xxxxx@ntdev…
>I don’t see how you could create a SRB in user land. It
>requires access to information only available in kernel mode.
>Sending a CDB with SPTI is the only available method from user
>land. In a driver you could send a full SRB to the driver that
>owns the hardware (disk/CD/DVD/Blue Ray).
I was afraid of that. Disappointing.
>
> I guess you or your company are too cheap to buy the final
> specifications for SCSI and MMC.
Getting the ANSI/INCITS is not a matter of price.
Bill McFerrin, the MMC Technical Editor for the T10 committee,
publishes the standards of ANSI/INCITS for these devices.
Myself and others who program to these devices have never found
their finalized versions over the past 10 years to differ from
INCITS in the technical specs.
In addition, McFerrin draws from other relevant material provided
by NV Philips, Sony Corporation, DVD Forum, DV Copy Control
Association, Blu-ray Disc Founders, OSTA and others to define
terms and to clarify, illustrate and elaborate on the raw
technical data from INCITS. This is a great advantage to those of
us who aren’t engineers and makes the MMC far more valuable than
the INCITS pubs which use to be expensive and only recently went
to PDFs at $35 a pop.
The SFF Committee publishes a standard, called INF, for the Mt.
Fuji Group. It’s also free. These standards are directly from the
Mt. Fuji group and have proven equally reliable. The group’s
technical editors are engineers from Pioneer, Panasonic, and
Toshiba. Here again McFerrin uses material from this pub
particularly material not found in INCITS and it’s a significant
amount.
I’ve only run across a few people over the years who use the
INCITS pubs, the rest use the MMC & Mt Fuji. Even MS uses them.
You can find them referenced in their multi media headers e.g
ntddmmc.h, ntddcdvd.h and scsi.h.
( Unfortunately MS continues to base their CDROM & DVD IOCTLs and
structures (above) on MMC3 which was finalized in 2002. We are
now up to MMC6. The changes since MMC3 render them, to say the
least, undependable. )
> They have restricted access to the latest specifications on T10
> when the ANSI/IEEEE? versions are published.
You can download the latest T10 MMC easily as a temporary guest.
bilm
>
> “bilm” wrote in message news:xxxxx@ntdev…
>
> wrote in message news:xxxxx@ntdev…
>> Why not use IMAPI?
>>
>>
> IMAPI is MS’s interface to the low level scsi commands
> documented
> in T10’s MMC v.6 & Mt Fuji Group v.7 found at
> http://www.t10.org/drafts.htm#MMC_Family
> and
> ftp://ftp.avc-pioneer.com/Mtfuji_7/Spec/
>
> I use these same commands in my app. It gives me much more
> flexibility. And gives me the ability to change and improve
> read,
> write and all the supporting routines for speed and accuracy.
>
> Also IMAPI does not have a good history for dependability.
> Even version 2. I don’t know what transport IMAPI uses.
> I’d guess it has to use the SPTI just like me but I could be
> wrong.
>
> bilm
>
>
>
>
>
wrote in message news:xxxxx@ntdev…
> Thanks for that. I didn’t understand that this library written
> for the purpose just such as yours is so > inadequate that
> bypassing it is a more effective solution.
>
In fairness to IMAPI v.2, I see where MS has updated it to the
latest specs unlike their CDROM & DVD IOCTLs & associated
structures which are way out of date and unreliable.
In real-world, I’m still reading lots of complaining posts from
Win7 users about the CD/DVD native support i.e. IMAPI2. Many of
them add that their 3rd party burner like Nero, Roxio or Sonic
does the job fine. If you have Vista or Win7 have you tried
burning to a DVD-R or DVD-RW?
IMAPI2 is COM based and ties the programmer to the windows OS
when they may want to port it to a linux or MAC.
> So to answer the question, no you can’t send an SRB from user
> mode. The only way to do that >would be to write a driver and
> have the driver send the SRB on behalf of the application. But
> in the >optical drive case I doubt there would be an advantage
> of using an SRB provided you have >compensated for issues
> surrounding the use of pass through.
>
I’m interested in “compensated for issues surrounding the use of
pass through”. Could you elaborate?
bilm
> If you have Vista or Win7 have you tried burning to a DVD-R or DVD-RW?
Works fine. I would be surprised if a DVD vendor would release firmware in the last few years that is not compatible with Windows burning since otherwise support calls would be through the roof. Other software working when the Windows internal doesn’t is a very strange result to me.
I’m interested in “compensated for issues surrounding the
use of pass through”. Could you elaborate?
These issues can be found in the kb articles on the microsoft site. The most basic advice is never to use the DIRECT variety as they have been a source of many blue screens over the years. The problem with direct is it has a user mode pointer buried inside and countless in box and 3rd party drivers blow up dealing with that wrong. Off the record Microsoft once told us that their position is using DIRECT is a bug and all such code should be rewritten not to use direct.
wrote in message news:xxxxx@ntdev…
>> If you have Vista or Win7 have you tried burning to a DVD-R or
>> DVD-RW?
>
> Works fine. I would be surprised if a DVD vendor would release
> firmware in the last few years that is not compatible with
> Windows burning since otherwise support calls would be through
> the roof. Other software working when the Windows internal
> doesn’t is a very strange result to me.
>
>> I’m interested in “compensated for issues surrounding the
>> use of pass through”. Could you elaborate?
>
> These issues can be found in the kb articles on the Microsoft
> site. The most basic advice is never to use the DIRECT variety
> as they have been a source of many blue screens over the years.
> The problem with direct is it has a user mode pointer buried
> inside and countless in box and 3rd party drivers blow up
> dealing with that wrong. Off the record Microsoft once told us
> that their position is using DIRECT is a bug and all such code
> should be rewritten not to use direct.
>
Thank you for this tip. I’d never heard of it. I use the direct
method so I’ll keep it in mind.
bilm