This message is from the T13 list server.
> Re: Fwd: why not H = C = D ModeSense6 for just the header > Pat, I don't understand your confusion Thanks you for your interest, sorry I was unclear, kind of everyone here to let me try again. > about determining if a device is an ATAPI or SCSI > device. If a device is on an ATA bus and responds > to Identify Packet Device then we know it is ATAPI. I agree the very idea of distinguishing ATAPI from SCSI bothers me. What can ATAPI be except some subset of SCSI passed over IDE. But I can see somehow in reality ATAPI has grown to be not quite the same thing as SCSI, though lately SFF has been changing to grow less pointlessly unlike SCSI. Maybe seeing ATAPI only as SCSI over IDE indeed is the Win NT/2K/XP algorithm? Maybe there a device "is ATAPI" only if Atapi.sys talks to it? In Win 95/98/ME by contrast, I've heard we have an "ATAPI bit" which drivers in the stack can set & clear at will, according to such undocumented heuristics as the choice of supported mode pages and supported ops. Untrue? > Perhaps I am misunderstanding your scenario. We have to answer completely & precisely both halves of the whole question: when do we know a device is ATAPI, when do we know a device is not ATAPI. I'm told in Win ME/2K/XP, Windows/Inf/UsbStor.inf limits generic Scsi over Usb to bInterfaceSubClass in x 02 05 06. Suppose a device reports not bInterfaceSubClass x06 "SCSI transparent command set" meaning Microsoft SCSI, but instead bInterfaceSubClass x02 "SFF-8020i, MMC-2 (ATAPI)" meaning PDT x05, or bInterfaceSubClass x05 "SFF-8070i" meaning like a Compaq LS-120. The way people have been speaking here, to follow SFF rather than ANSI is to be ATAPI. So maybe Windows thinks of those devices as ATAPI also. No? I just checked recently. Some of the more pernicious binary incompatibilities remain, though they now appear expressed as a binary incompatibility within ANSI, e.g. mmc4r01f "Table 447 – Mode Parameters Header" vs. spc3r11 "Table 215 — Mode parameter header(10)". > Microsoft's ATAPI driver converts all Mode > Sense(6)/Mode Select(6) command (including SCSI > pass through ones) Why all? Anybody know? > to Mode Sense(10)/Mode Select(10) commands for all > ATAPI devices except tape devices (which follows > the QIC157 streaming tape command set). Ah, fun. This is to say, everything connected via Atapi.sys is ATAPI, excluding only PDT x01? > The KB article Q813908, sited earlier, is not > relevant to this discussion. Agreed. I wish I knew better how to keep each titled thread focused on its own subject, without then discouraging informative free association. > KB article Q813908 ... doesn't comment on a > protocol problem KB 813908 says that Win 2K thru SP3 applies an astonishingly creative translation to ATAPI from Microsoft SCSI. If there were no conflict between the T10 SCSI and SFF ATAPI standards, no translation would be required, so the binary code only translation couldn't astonish me. > or the H=C=D behavior that was mentioned earlier. What's fun about KB 813908 is that it is a counterexample to the oft-voiced theory that H = C = D just plain works. > > Win 95/98/ME Last I checked Microsoft still supports Win back thru Win 98SE or so. Until Microsoft drops support, we lesser players can't either. > ... Thanks for talking, Pat LaVarre
