aboutsummaryrefslogtreecommitdiff
path: root/README.win32
blob: 7a9e801fa5a3ffb4140e0440ef1a1b412786145f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
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_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_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_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.


See the INSTALL file (towards the end) for instructions on how to build
sg3_utils on Windows operating systems. Some man pages have examples which
use linux device names which hopefully will not confuse Windows users.


Details
=======
The ported utilities listed above, all use SCSI command functions declared in
sg_cmds_basic.h and sg_cmds_extra.h . 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 four 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_win32.c

The sg_pt_win32.c file uses the Windows SCSI Pass Through (SPT) mechanism.
It does not currently use the ASPI32 interface which requires a dll from
Adaptec. The sg_scan utility is a special version for Windows and it attempts
to show the various allowable device names, grouping various names for the
same device on one line. Here is an example of sg_scan's output:

# sg_scan
SCSI0:0,0,0       C:    PD0      IC25N040ATCS05-0        CS4O  *
SCSI1:0,0,0       D:    CDROM0   HITACHI DVD-ROM GD-S200 0034
SCSI2:0,0,0       I: +  PD5      QUANTUM LPS525S         3110
SCSI2:0,6,0             TAPE0    SONY    SDT-7000        0192
                  E:             Generic USB SD Reader   1.00  pdt=0
                        PD1      Generic USB SD Reader   1.00

So the following device names all refer to the same (ATA) disk:
"SCSI0:0,0,0", "C:" and "PD0". Recent version of windows will only allow the
"SCSI0:0,0,0" to be used if there isn't another device name available.
The right hand section of each line is the SCSI INQUIRY command response
strings (which are constructed by Windows is some cases rather than the
device). The "*" at the end of the first line flags that the INQUIRY
response is not quite properly structured (according to SCSI-2) which is
usually indicative of an ATA disk.

If no class driver name (e.g. "PD0", "CDROM0" or "TAPE0") is available
then the SCSI "peripheral device type" (pdt) is placed at the end of the
line. Common pdt values are 0 for disks, 1 for tapes and 5 for cd/dvd
drives. The "+" after the "I:" indicates that other volume names
(letters) map to that device. This occurs when a disk has two or more
partitions that windows recognizes. The longer "PhysicalDrive" name,
shown in Windows documentation, may be used but "PD" is obviously
quicker to type.

Finally sg_scan does not manage to put all device names for USB and
IEEE 1394 devices on one line. The last two lines of output are actually
the same device.

Several utilities have conditional compilation sections based on
the SG3_UTILS_MINGW define. For those who want to try native C compilers
on Windows setting the SG3_UTILS_MINGW define may help.

Build environments
==================
This package has various Makefiles so that these utilities can be built
in either a cygwin and MinGW environment, called Makefile.win32 and
Makefile.mingw respectively. The executables produced are console
applications that can be executed in either a cygwin, MSYS or "cmd" shell.
See the INSTALL file for more details.

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
11th March 2009