Access via SPTI

Access via the SCSI Port

As was already mentioned above (see the Access via SPTI section), you can, independent of the physical interface of the disk drive (be it SCSI or IDE), communicate directly with it via the unified SCSI interface. In other words, the driver for a specific device (CD-ROM drives, in particular) is absolutely abstracted from specific features of the bus interface implementation of that specific device. This means that even if drives working via infrared ports appear tomorrow, the CDROM.SYS driver won t know anything about it, and will control such devices via an SCSI port.

Even if there are no SCSI controllers installed on your computer, a couple of usable SCSI can be found anyway. Of course, these ports are virtual rather than physical. However, from the software point of view, they look as if they are physical. Try to use the CreateFile function to open the \\.\SCSI0 : device and it will be opened successfully, thus confirming the existence of virtual SCSI ports (do not forget that the string must be terminated by a column). By sending specific IOCTL commands to SCSI ports, you can control any physical or virtual device connected to that port. In fact, there is another abstraction level between the virtual SCSI port and the physical interface bus, the level occupied by SCSI miniport, which, actually, abstracts the SCSI port driver from specific physical equipment (see Access via SCSI miniport for more details).

Naturally, before sending IOCTL commands to the SCSI port, it would be nice to know what equipment is connected to that port. There are numerous methods for solving this problem. These methods range from the IOCTL_SCSI_GET_INQUIRY_DATA command sent to the device (see the source code of the Windows NT DDK demo example located in the NTDDK\src\storage\class\spti directory), after which the device, along with other information, will report its name (something like PHILIPS CDRW2412A), to the object table viewed , which you will carry out here. Windows NT DDK contains the objdir.exe utility, which, as its name suggests, allows the contents of the device object tree object to be displayed in the form of a directory. Devices available to open using the CreateFile function are stored in a directory with the name \DosDevices\ . Looking at the name, you might think that it contains the names of devices available from under MS-DOS that Windows NT must emulate to ensure backward compatibility. In reality, however, this directory is used actively by the Win32 subsystem of the Windows NT operating system. Any time the CreateFile function accesses a specific logical device (for example, when it tries to open the C:\MYDIR\myfile.txt file), the Win32 subsystem looks in the \DosDevices\ directory to find out to which internal device this logical device is connected. Internal devices are visible only under Native-NT, while they are senseless for all of its subsystems other than Win32. In particular, disk C: under Native-NT has the name of \Device\HarddiskVolume1 , while the fully qualified path to the myfile.txt file looks as follows : \Device\HarddiskVolume1\MYDIR\myfile.txt . However, try to feed this string to the CreateFile functions, since it probably won t understand what do you want from it.

Thus, the \DosDevices\ directory serves as a kind of connecting link between the Win32 subsystem and the Windows NT kernel. Now, return to our problem and consider, to which native device the SCSI logical device is connected. Start objdir with the \DosDevices command-line option and redirect its output to the file ( objdir \DosDevices MORE as alternative). Along with lots of other information, you will find the following strings (if you don t have DDK, use the Soft-Ice debugger, where it is necessary to give the objdir \?? command to achieve a similar result. Note the two question marks in the command line, since the \DosDevices directory isn t actually a directory but, rather, a symbolic link to the \?? directory, or its shortcut).

Listing 4.15: The relationship between logical SCSI devices and native-NT devices

 Scsi0:   SymbolicLink - \Device\Ide\IdePort0  Scsi1:   SymbolicLink - \Device\Ide\IdePort1  Scsi2:   SymbolicLink - \Device\Scsi\axsakil 

 

As it turns out, SCSI0: and SCSI1 devices represent nothing other than symbolic links to IDE ports with numbers 0 and 1, respectively. The IdePort0 and IdePort1 devices, though, are not IDE ports in a physical sense. These are virtual SCSI ports created by the ATAPI.SYS driver in the course of its initialization. The same driver creates the symbolic links \DosDevices\SCSI0: and \DosDevices\SCSI1: , as well as the shortcuts \Device\ScsiPort0 and \Device\ScsiPort1 , unavailable for the Win32 subsystem and intended for internal use at the driver level. Naturally, ATAPI.SYS is not limited to the creation of all of the devices listed above, but also serves them by providing higher-layer drivers with a unified interface for interacting with the installed equipment.

As concerns the SCSI2: device, it is not connected to any physical bus, and the virtual CD-ROM drive is connected to its corresponding SCSI port. This virtual drive is created by the Alcohol 120% program, or, to be more precise, by its driver ” AXSAKI.SYS! Higher-level drivers (in particular, CDROM.SYS), won t suspect anything. Instead, they will work with the virtual disk as if it were a physical one. This is not surprising, since the SCSI port concept ensures the independence of higher-level drivers from specific hardware, with which they operate . This is why NT allows such an easy implementation of various physical device emulators!

By the way, after disassembling the Alcohol 120% program, you might reveal some dirty and obscene words used as variable names or labels.

SCSI devices can be managed from the application level via the STPI interface. However, instead of the drive letter, it is necessary to specify the name of the SCSI port, to which this drive is connected. The main advantage of such a method of controlling devices lies in that you don t necessarily need administrative privileges to communicate with the drive. Normal user privileges are more than sufficient. Besides, direct operation with the SCSI port is somewhat faster than accessing the device via a long chain of higher-level drivers and the numerous filters wrapping them.

However, all attempts at passing an SRB block via the SCSI port inevitable end with an error. For example, the following code refuses to work. Why?

Listing 4.16: An example of incorrect operation with a virtual SCSI port

 // Getting the SCSI port descriptor  hCD=CreateFile ( "\\.\SCSI1", GENERIC_WRITEGENERIC_READ,  FILE_SHARE_READFILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);  // Forming the SRB block  // Sending the SRB block directly to the SCSI port  status = DeviceIoControl (hCD, IOCTL_SCSI_PASS_THROUGH_DIRECT, &srb,                        sizeof (SCSI_PASS_THROUGH), &srb, 0, &returned, FALSE); 

 

Newsletters are swarming with questions relating to this problem. Some users report that this code operates correctly, while the majority complains that it doesn t. The answer can be found in the DDK (if you read it carefully , of course). Here it is: 9.2 SCSI Port I/O Control Codes: If a class driver for the target type of device exists, the request must be sent to that class driver. Thus, an application can send this request directly to the system port driver for a target logical unit only if there is no class driver for the type of device connected to that LU. In less technical language, direct control over the SCSI port from the application level is possible only for those devices that have no class driver installed. For instance, suppose that you have connected some non-standard hardware to your computer. In this case, it is possible to control this hardware directly via the SCSI port, since this hardware has no class driver! However, CD-ROM drives, which you are discussing here, are a different matter. They always have a class driver installed and, therefore, the operating system does everything possible to prevent direct communication with such hardware via the SCSI port, since this is the only reliable way of avoiding conflicts.

Fig. 4.5: The I/O Subsystem architecture in NT

Does this mean that direct access to CD-ROM drives via the SCSI port is impossible ? Well, only partially. Attempts to access the SCSI port directly are actually blocked by the operating system. However, the same operating system provides you with the ability to control the device via an SCSI miniport. What is a miniport? This is exactly what you will consider now.