Introduction ============ The win32 port of sg3_utils contains those utilities that are _not_ specific to Linux. One utility for listing available devices, sg_scan, has a Windows-specific version for this port. The dd variants from the sg3_utils package (e.g. sg_dd) rely on too many Linux idiosyncracies to be easily ported. A new package called 'ddpt' contains a utility with similar functionality to sg_dd and is available for Windows. Two build environments are caterered for: cygwin (see www.cygwin.com) and MinGW ("Minimalist GNU for Windows", see www.mingw.org). Both are based in the gcc compiler (although other C compilers should have little problem with the source code). Cygwin is a more sophisticated, commercial product that results in executables that depend on cygwin1.dll . No licensing is required since sg3_utils is open source (with either BSD or GPL licenses) but users will need to fetch that dll. On the other hand MinGW (and its companion MSYS shell) builds freestanding console executables. The Unix library support is not as advanced with MinGW which has led to some timing functions being compiled out when sg3_utils is built for MinGW. Supported Utilities =================== Here is a list of utilities that have been ported: sg_format sg_get_config sg_get_lba_status sg_ident sg_inq [dropped ATA IDENTIFY DEVICE capability] sg_logs sg_luns sg_modes sg_persist sg_opcodes sg_prevent sg_raw sg_rdac sg_read_block_limits sg_read_buffer sg_read_long sg_readcap sg_reassign sg_requests sg_rmsn sg_rtpg sg_safte sg_sat_identify sg_sat_phy_event sg_sat_set_features sg_scan [this is Windows specific] sg_senddiag sg_ses sg_start sg_stpg sg_sync sg_turs sg_unmap sg_verify sg_vpd sg_wr_mode sg_write_buffer sg_write_long sg_write_same Most utility names are indicative of the main SCSI command that they execute. Some utilities are slightly higher level, for example sg_ses fetches SCSI Enclosure Services (SES) status pages and can send control pages. Each utility has a man page (placed in section 8). There is summary of the mapping between utility names and the SCSI commands they execute in the COVERAGE file. An overview of sg3_utils can be found at: http://sg.danny.cz/sg/sg3_utils.html . A copy of the "sg3_utils.html" file is in the "doc" subdirectory. Some man pages have examples which use linux device names which hopefully will not confuse Windows users. Two pass-through variants ========================= The sg_pt_win32.c file uses the Windows SCSI Pass Through interface. That is often shortened to SPT or SPTI. There are two DeviceIoControl() ioctl variants provided: IOCTL_SCSI_PASS_THROUGH and IOCTL_SCSI_PASS_THROUGH_DIRECT. The former involves double handling of data (and perhaps an upper limit on the data length associated with one SCSI command; MS documentation mentions 16 KB). The "direct" variant passes a pointer from the user space and to be faster looks and more versatile. However the "direct" variant has potentially (unquantified) alignment requirements and may not be (well) implemented by the hardware driver. In practice some users have reported errors (e.g. 1117: a non-descript IO error) when the direct variant is used. Hence the non-direct variant is the default. The default size limit on the data buffer is set at 16 KB but if the user asks for more the data buffer will be extended. The OS or the hardware drivers may reject the extended data buffer but we tried. The package can be built using the direct variant with: ./configure --enable-win32-spt-direct rather than: ./configure prior to the 'make' call. Details ======= Most of the ported utilities listed above use SCSI command functions declared in sg_cmds_*.h headers . Those SCSI command functions are implemented in the corresponding ".c" files. The ".c" files pass SCSI commands to the host operating system via an interface declared in sg_pt.h . There are currently five implementations of that interface depending on the host operating system: - sg_pt_linux.c - sg_pt_freebsd.c - sg_pt_osf1.c [Tru64] - sg_pt_solaris.c - sg_pt_win32.c The ASPI32 interface which requires a dll from Adaptec is not supported. The sg_scan utility is a special version for Windows and it attempts to show the various available storage device names, one per line. Here is an example of sg_scan's output: # sg_scan PD0 [C] FUJITSU MHY2160BH 0000 PD1 [DF] WD 2500BEV External 1.05 WD-WXE90 CDROM0 [E] MATSHITA DVD/CDRW UJDA775 CB03 Here is an example with added bus type: # sg_scan -b PD0 [C] FUJITSU MHY2160BH 0000 PD1 [DF] WD 2500BEV External 1.05 WD-WXE90 CDROM0 [E] MATSHITA DVD/CDRW UJDA775 CB03 Here is an example with added SCSI adapter scan: # sg_scan -b -s PD0 [C] ST380011A 8.01 PD1 SEAGATE ST373455SS 2189 PD2 ATA ST3160812AS D PD3 SEAGATE ST336754SS 0003 CDROM0 [F] HL-DT-ST DVDRAM GSA-4163B A103 TAPE0 SONY SDT-7000 0192 SCSI0:0,0,0 claimed=1 pdt=0h dubious ST380011 A 8.01 SCSI1:0,0,0 claimed=1 pdt=5h HL-DT-ST DVDRAM GSA-4163B A103 SCSI2:0,6,0 claimed=1 pdt=1h SONY SDT-7000 0192 SCSI5:0,17,0 claimed=1 pdt=0h SEAGATE ST373455SS 2189 SCSI5:0,19,0 claimed=1 pdt=0h ATA ST3160812AS D SCSI5:0,21,0 claimed=1 pdt=0h SEAGATE ST336754SS 0003 SCSI5:0,112,0 claimed=0 pdt=10h LSI PSEUDO DEVICE 2.34 The storage devices scanned are PhysicalDrive (shorted form PD used), CDROM (which includes DVD and BD drives) and TAPE. There is also an optional SCSI adapter scan with device names of the form SCSI::: . These only come into play for devices that are not claimed by one of the storage class drivers. The "LSI PSEUDO DEVICE" device above is an example of an unclaimed device. The SCSI adapter scan does not show USB and IEEE 1394 connected devices. Volume names (e.g. "C:") that match a storage device (or perhaps a partition within that device) are shown in brackets. Notice there can be zero, one or more volume names for each storage device. Up to four volume names are listed in brackets, if there are more a "+" is added after the fourth. Several utilities have conditional compilation sections based on the SG_LIB_MINGW define. For those who want to try native C compilers on Windows setting the SG_LIB_MINGW define may help. Build environments ================== This package uses autotools infrastructure with the now common "./configure ; make ; make install" sequence needed to build and install from the source found in the tarball. Two Windows environments for building Unix code are supported: cygwin and MinGW. If the "./configure" sequence fails try using the ./autogen.sh prior to that sequence. The executables produced are console applications that can be executed in either a cygwin, MSYS or "cmd" shell. Various build options are available by giving command line options to "./configure", see the INSTALL file for generic information about the build infrastructure. Binary and Text files ===================== A problem has been reported with binary output being written in a MinGW environment (or executables build by MinGW). Windows has a concept of text and binary files which is not found in Unix. Recent versions of MinGW default to opening files in text mode. This can lead to binary output (such as when the '--raw' option is given) having 0xa (i.e. LF) translated to 0xd,0xa (i.e. CR,LF). sg3_utils version 1.26 attempts to fix this problem by changing what it knows to be binary output files to "binary mode" with the setmode() Windows command. Doug Gilbert 10th April 2010