WinXp下的Cdrom

各位兄弟，我读IFSXp中的Class代码，觉得它可以实现光盘的写操作。但为什么有谣传说WinXp的Cdrom写有关的部分是OEM别人的代码哪？不知那位兄弟对此有研究，一起讨论讨论！

你看哪部分的代码，请详细说说。

多谢大侠回复。我读的是IFSXp中的Class下边的Cdrom和ClassPnp的代码。

各位兄弟，我读IFSXp中的Class代码，觉得它可以实现光盘的写操作。但为什么有谣传说WinXp的Cdrom写有关的部分是OEM别人的代码哪？不知那位兄弟对此有研究，一起讨论讨论！

IFSXp中的Class我没有看过，但是2000 DDK中的哪个是对CDROM的，不能用来写，需要第三方的软件，如Easy CD等

AllenZh首先感谢您的讨论。
是的，win2k中的CDRom确实是不能用来写的。但在Xp中，Cdrom多了MMC设备的支持，个人觉得它可以实现光盘的写操作。微软为什么不直接启用这个工能哪？
而且在实际跟踪时，IRP_MJ_WRITE没有经过CDRom和ClassPnp处理，就很奇怪了！难道它有另外的Filter来处理？但Cdrom上只有一个filter RedBook，难道是它吗？

[编辑 -  4/19/04 by  phenix_xiaomei]

有可能是redhook
另外，write对应不同CDB命令（或者更详细的说是MMC的Write 10等命令，注意可能不只一个），这是否一定要进入IRP_MJ_WIRTE呢？不一定吧，至少可以Passthrow到下层驱动

在Cdrom的CdromStartIo中，就是将IRP_MJ_WIRTE或者IRP_MJ_READ转化成SRB(含有CDB结构)并调用IoCallDriver。
PassThrough是另一种执行SCSI指令的方式。它确实绕过了Class这一层。
我感到奇怪的就是微软既然在Class中实现了write，为什么不象Disk或者Tape一样直接进行光盘的读写，而要用filter采用passthough的方式？

自己顶下。希望还有人来探讨一下。

在Cdrom的CdromStartIo中，就是将IRP_MJ_WIRTE或者IRP_MJ_READ转化成SRB(含有CDB结构)并调用IoCallDriver。
PassThrough是另一种执行SCSI指令的方式。它确实绕过了Class这一层。
我感到奇怪的就是微软既然在Class中实现了write，为什么不象Disk或者Tape一样直接进行光盘的读写，而要用filter采用passthough的方式？

这的确是这样的，MS没有考虑这样我想是因为大多数都是CDROM不是CD-RW的，另外不同的CD-RW提供商需要提供不同的驱动，以便完成某些特殊处理，其实CD-RW的驱动是个Filter，它是需要CDROM来工作的，从MS的体系加构上来看，MS这样设计是没有违背其架构的。

另外，使用Filter也不一定必须为Passthrogh方式。

微软的cdfs本身不支持写功能，所以微软不需要在光驱驱动里面加写支持。但是随着udf和刻录机的普及这个功能还是需要的，所以他会在以后的操作系统里面加上得。但是这种功能是要靠文件系统来支持的，所以说微软的文件系统方面要是没有大的改动得话，光驱写功能就算是实现了，也没多大意义。

微软的cdfs本身不支持写功能，所以微软不需要在光驱驱动里面加写支持。但是随着udf和刻录机的普及这个功能还是需要的，所以他会在以后的操作系统里面加上得。但是这种功能是要靠文件系统来支持的，所以说微软的文件系统方面要是没有大的改动得话，光驱写功能就算是实现了，也没多大意义。

同意。
现在所讨论的前提是文件系统支持了写。其实，文件系统所作的事情我想无非是两个功能：1、路径解析成物理扇区。2、对象访问的控制。真正要完成写功能的还是在设备驱动上的。

 

引用：
--------------------------------------------------------------------------------
微软的cdfs本身不支持写功能，所以微软不需要在光驱驱动里面加写支持。但是随着udf和刻录机的普及这个功能还是需要的，所以他会在以后的操作系统里面加上得。但是这种功能是要靠文件系统来支持的，所以说微软的文件系统方面要是没有大的改动得话，光驱写功能就算是实现了，也没多大意义。
--------------------------------------------------------------------------------


同意。
现在所讨论的前提是文件系统支持了写。其实，文件系统所作的事情我想无非是两个功能：1、路径解析成物理扇区。2、对象访问的控制。真正要完成写功能的还是在设备驱动上的。

cdfs是不大可能加写功能的，这是由于它的文件组织形式来决定的，和具体实现是无关的。当然我们是可以加入自行的加入的，我自己以前就想那么干。意义不太大，因为cdfs本身并不是为随机写数据设计的。
当然如果你已经搞定了文件系统这一层的话，你所说的就是正确的。

phenix_xiaomei兄，有没有IFS可以下载？我也想看看IFS的例子

本网站就有的！

[编辑 -  5/12/04 by  phenix_xiaomei]

但是下不下来

MS为什么不在CdRom Class里面做write，可能还有一个原因：MS没办法做到兼容。

回顾一下C/DVD刻录市场，可以发现有很多格式/标准，而且很多公司的产品互相之间还有一些区别。比如，某个cdb在panasonic的机器上可以用，但在acer的上面就会当机；对某些scsi的cd-rom如果发cdb12的inquiry，就会当机，等等。所以，很多刻录软件都有一个长长的列表，里面记录了每个刻录机的一些信息，比如哪些命令不能用，等待的时间等等。

如果把这个列表做到kernel里面，当windows发行的时候，市场上已经有了很多这个列表里面没有的机器，对这些机器的写操作就可能会失败，这可和MS标榜的“兼容性”不相符。

这些是一个做刻录软件的朋友说的，想想也很有道理哦

[编辑 -  5/14/04 by  rayyang2000]

rayyang2000兄说的有道理，兼容性问题也很关键的因素

嗯！有道理。
但是刻录机、刻录软件，大家都严格的遵守MMC，应该问题不大。Longhorn中就会集成这个功能了。

在xp的CDRom和ClassPnp中，已经对IRP_MJ_WRITE解析成了SCSI指令。可UDF文件系统中却又没能提供对IRP_MJ_WRITE的支持，所以觉得很奇怪。设备驱动走在了文件系统的前面。而Explorer中的写的功能又是由其他方法来实现了(据说是ASPI的方式，由Roxio提供)。真是觉得杂乱无比。

那可不一定哦。我去年就碰到一个srb里面的一个bit，在mmc2/mmc3/mmc4里面都没有解释，spc/scsi里面也没有。后来还是别人帮我从一个非常早的inf spec里面找到解释。