We have a legacy driver for NT to communicate with a piece of custom
hardware. This hardware doesn't seem to fall into any of Microsoft's
existing classes (at least I don't think so, but you've probably heard that
line before).

It attaches via a SCSI-2 interface, and meets the minimum requirements under
SCSI-2 as a 'Processor' device. It allows the computer to interface with a
large amount of individual I/O points used in a full-scope control room
simulator (app. 1500 analog outputs, 7500 digital outputs, 4500 digital
inputs, and 300 analog inputs, all scanned at 20 Hz).

Our legacy driver, (originally written for NT 3.51) has served us pretty
well through the various OS upgrades. I developed a new '.inf' file a few
years back to provide client-side installation on Windows 2000. The same
..inf and .sys files work under Windows XP (pro & home). But they do *not*
seem to work on Windows 2003 Standard edition. Why not?? The OS complains
about error starting the driver yet it works under XP and 2000.

Anyway, I'm trying to write a new driver using the latest DDK and WDM models
(I wrote the original as well). Or should I wait for WDF? But I can't find
nearly the amount of information on SCSI device drivers that I had back in
the NT days. Most new things are USB & 1394 it seems. I do have the SCSI
specs down pat and work quite closely with the device firmware programmer,
so I have that going for me (as well as a SCSI bus analyzer etc...) But
searching for a good text on the subject of SCSI drivers under WDM hasn't
been successful (have "Programming the Microsoft WIndows Driver Model" and
"The Windows 2000 Device Driver Book", but they barely acknowledge that SCSI
exists).

I've started by using a storage/class sample from the DDK. But since 'SCSI
Processor' devices support a lot fewer features than either CDROM, disk
drives, or tape, there's a lot of code that needs to be thrown away. And
cutting out code without breaking things is a bit tricky. Anyone have a
better starting point for a simple SCSI device that still fits the WDM
model?

Also, since this device is external, and has it's own power, can I just
reply success to all the power management requests (the device doesn't have
any sort of power-down mode)?

Sorry for the long ramble, but this is a small outfit and I feel lost in the
wilderness a bit. I get to do the low-level drivers because I'm the one
that works with the hardware folks and understand bit-bashing.

Mike Fochtman

The first thing I would do is run the chkinf tool (found in the DDK) to
check for problems with your inf file. The next thing to do is look at
setupapi.log to learn more about what failed. Next, run verifier,
flipping on all its most stringest checks except simulating low
resources. Finally, look at how you respond to each IRP, particularly
the last one that arrives.

I am assuming you have a processor class driver. As far as pnp & power
irps make sure you handle ones you don't know correctly: you DO NOT
touch the status of the IRP and you DO NOT complete it; you pass it
down without touching anything. And you must use PoStartNextPowerIrp &
PoCallDriver for each power IRP. Hope that helps.

Mike Fochtman wrote:
storage source tree in the ddk. Disk/Cdrom/Tape sample clients are
provided. Disk is too complex as it is a bus driver for disk partition
PDOs in addition to being a function driver for the scsi disk target.
I'd start with CDROM and just rip out all the CDROM hardware idiocy
code. You should be able to rather readily get it down to a simple
driver that queries your scsi target, then add in the read/write or
ioctl or whatever it is that you do to communicate with your hardware.
The advantage of classpnp is that it handles all of the basic PnP code
for you.

Too bad classpnp is really rather undocumented, huh? But you do have
three functional source examples, so that is something.

I don't think WDF currently has anything to offer in the scsi class
driver space.

I think it is also possible to pretty much avoid a driver entirely and
communicate with the PDO using scsi passthrough from user mode.
--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

"Mark Roddy" <markr@hollistech.com> wrote in message
news:eRPeSWCtFHA.3328@TK2MSFTNGP11.phx.gbl...
Thanks for the reply Mark...

Yes, I had started with the storage/class/Cdrom sample. But for things like
building the SRB and CDB, it often passes back into classpnp library. And
as you say, that is not too well documented.

I'm still puzzled as to why the legacy driver, that works in 2K and XP fails
in 2003. Did something change there that no longer supports some legacy??
Guess I'll have to fire up windbg to find out. But recompiling the old
driver now to get a debug-build is a bit tricky, would have to get an NT
3.51 DDK (and that doesn't seem very easy).

I had considered just going direct with SCSI_PASS_THROUGH and
SCSI_PASS_THROUGH_DIRECT, but it seems those specific ioctl() codes and the
struct's needed (SRB and CDB) are only defined in DDK header files. So I'd
have to somehow include those in my deliverables since clients won't have
them by default??

If I could somehow 'wrap' all those calls in a DLL that I supply to
customers, I guess they could change their application code from
"CreateFile() / ReadFile() / WriteFile() / CloseFile()" to call unique
methods in my DLL. Guess that's worth considering.

Mike Fochtman

"heinz" <heinz_baer@my-deja.com> wrote in message
news:1126149024.234191.275970@g47g2000cwa.googlegr oups.com...
The chkinf tool reports no errors, other than the lack of a catalog file at
this point. I'll check the setupapi.log. I'm not sure the verifier will
help much since the driver is failing in the DriverEntry point (legacy
doesn't have an AddDevice() method).

Yes, this helps. I was wondering exactly how to handle Po IRP's when my
device (being externally powered) doesn't really know anything about power
management.

Thanks,

Mike Fochtman

Mike Fochtman wrote:

I agree - but the advantage of getting all the PNP stuff for free seems
compelling.


binaries work on any of these releases. You were living on borrowed time.

scsi.h can be included in a user mode application/dll. The scsi
passthrough sample app in the ddk (<ddkroot>\src\storage\tools\spti)
unfortunately uses 'inheritance by cut'n'paste' to get the CDB
definitions but you don' have to do that.

That's the way I would go unless there is a compelling need for a kernel
mode class driver. Much easier to debug the user mode failure.


--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

IIRC MS's people warned against using the Processor device class for SCSI.
This is reserved for something.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Mike Fochtman" <mike@fochtman.org> wrote in message
news:%23u2Ue55sFHA.4076@TK2MSFTNGP11.phx.gbl...

"Mike Fochtman" <mike@fochtman.org> wrote in message
news:uwi3ZbGtFHA.2880@TK2MSFTNGP12.phx.gbl...

I'd also try compiling with the W2K3SP1 DDK. If your legacy source code
compiles and runs then you'll have to ship two binaries (one for current
OSes and the older one for designated new technologies) but it might solve
your problem for you.

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eiPbhqLtFHA.1132@TK2MSFTNGP10.phx.gbl...
Yes, years ago I found that the SCSI-Scanner generic driver provided by MS
*assumed* that any SCSI processor class device was an image scanner. It
would allocate any SCSI Processor device and prevent my driver from loading.
But I worked around this with the Tag registry key to control load order so
my driver could allocate the device *before* the generic scanner.

Doesn't seem to be much of a problem in XP or 2000 since scanners now are
almost always USB or 1394. Nothing in MS documentation that discussed it
back then, and even less documentation about SCSI functional drivers now.
:-(

Mike Fochtman

Right, this is an ancient issue that does not extend past NT 4. And
even in NT 4 is not a big deal.