-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Burg
Sent: Sunday, January 09, 2005 5:29 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Modification of SPTI requests
Hello all,
I will be reacting to several e-mails at once as I’m using
the digest mode of the reflector.
I also would like to thank everyone who joined this discussion!
Anton Kolomyeytsev wrote:
> The whole idea of making MRW support as filter driver is… well…
> questionable ))
Ok, but so far it is the more realistic solution I see.
Microsoft not only did not implement it in its new OSes after
MRW was created, but did not, and will certainly not, create
a patch for its already released OSes. We cannot expect all
user mode applications to integrate MRW remapping, especially
not MS user applications (such as Windows Explorer to take a
very needed software for the end-user).
Would there be a viable solution different from a filter
driver, I would study it, but sorry, I don’t see any.
> If this particular “other ISV”
> would finally “go South” with his morbid requirements I
don’t see how
> guys from Nero would protect themself from the conflicts
with the MRW
> software coming from other ISVs.
This is what motivated us to bring the issue here.
> I’d like to see
> optical media defect management as part of the OS and not as never
> ending story of custom add-ons. Sounds like another UDF
reincarnation
> ))
Ideally, defect management would be kept at device level,
like in DVD-RAM.
But
that is only my personnal feeling.
Mike Berhan wrote:
> What user mode application do you need to “fake” to
understand MRW discs?
> Should that vendor, instead, update their software to deal
with this
> issue instead of you? Have you contacted them to update
their software?
Windows Explorer is a good example of user-mode application
which is not
MRW-
aware. But in general, optical device manufacturers want to
be able to provide an add-on with they MRW drives so legacy
drives can read the media they generate. Because you don’t
know in advance who will read the disc, where it will be
read, and what will be accessing the disc on this computer,
you need a generic solution.
MRW remapping for legacy drives is a kind of ‘hardware’ patch
done in software.
You can’t ask device manufacturers to update the firmware of
the thousand different models they created. You can’t ask
software vendors to update all the applications accessing a
disc. A filter driver looks to me to be the most reasonnable choice.
> Your solution might cause some user mode apps to work
again, but break
> others, including some by us. When we send a CDB down to a device
> using SPTI, we expect that CDB to be sent to the device.
Our software
understands
> the capabilities of the various devices and knows which
CDBs to send.
Just
> a thought.
Well, your application will see a MRW read capable device.
Will this mean it is broken? On the contrary, I think it
would mean it is working, both your user mode application and
our filter driver. We’re patching a lack in the hardware, and
as long as this patch succeed so you don’t see in your user
mode application the difference between real hardware and
software emulated capability, it’s fine.
> I’m speaking specifically for devices that process CDBs
(not something
that
> will emulate the processing of CDBs). If a filter driver
alters the
> behavior of a SPTI request, for example alter some of the CDB bits,
> then
my
> SPTI app is not seeing the “true” response of the device.
Seeing the
> true reaction and response to my CDB is important to me.
Here is the
> specific app that expects the CDB to get unaltered to the device.
>
> http://www.bustrace.com/busprobe/cdbexerciser/send.htm
Sorry, you see the ‘true’ response of the emulated device. If
you want to
by-
pass the kernel mode patch, you can’t do that in user-mode.
By I doubt that your user-mode cdb exerciser is intended to
by-pass kernel-mode fix for devices, I mean, you provide a
way to either train to create other user-mode software (fine,
you see what they will see) or we have a hardware engineer
who wants to train his hardware with an software patch for
his lack of MRW support (I assume such engineer will be aware
of what he installed on his test system).
> This can become a bigger problem. Let’s say his filter
driver alters
> an SPTI request and I really need the original CDB to get to the
> device. If
I
> want to work around this, then I could write a filter
driver below him
> to get down closer to the device. What if another filter gets down
> even
lower
> than me and messes with the CDB. Anyway, it can get messy and I’d
> rather not create another driver to simply send down a CDB.
Looks like you do not want MRW read feature then. Why an
engineer who does not want MRW emulation would not simply
de-install the emulation driver?
> Although I do not have all the details of this issue, it would seem
> that it is the user mode apps’ responsibility to add MRW
support
> (if he can get that vendor to do so).
Sorry, I don’t think we can get MS to do it.
Peter Wieland wrote:
> The OP should make the device behave consistently across all SCSI
> interfaces. If it works one way with read/write and
another with SPTI
> read/write CDBs that are the same as what DISK would have
sent down,
> then that’s going to be really bizarre.
I share this point of view.
–
About user mode app trying to detect a driver doing a
emulation: if somehow you can detect that the answer you get
are emulated and not real, it means you found a flaw in our
software. Our target is to be totally transparent so you
really think you are speaking to a MRW read capable device.
> How do you resolve a case where a software vendor has written their
> SPTI
app
> and it works great in all their test cases and with their customers,
against
> MRW discs or any type of disc. Then, another vendor comes
out with a
filter
> driver that is altering a command’s behavior and thereby
breaking the
> app that was previously working.
If the first vendor software was working on natively MRW read
capable devices, it has to be working as well on the MRW
emulated devices, or the emulation is somewhat broken
(because not behaving identically to native devices).
> At a minimum, at least for the techies, perhaps add an option to
> enable/disable that feature so the customer can alter the
behavior if
> it breaks something.
This looks far too technical for the average user. I don’t
want him to mess-up with something that low-level. I’d prefer
him to contact our support and let us know of the issue, or
even to de-install our software, rather that to put his
finger on something he doesn’t know.
Best regards,
David Burg
David Burg
Software Development,
InCD and Low Level Drivers Project Leader
Nero AG phone: +49 (0)7248 911 862 (room line)
Internal VoIP
-363
Im Stoeckmaedle 18 fax: +49 (0)7248 911 888
76307 Karlsbad email: xxxxx@nero.com
Germany http://www.nero.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com