不然你要我怎么样

原文地址：http://peter.skarpetis.com/wiki/index.php/Usbprint.sys

Usbprint.sys

From PsWiki

This article describes how to send data to usb printers under Windows. It was imported from an entry on my blog.

Introduction

So its Thursday morning at work and I decide that since the Mac OS X version of our software can print directly to USB printers bypassing the operating system, its about time we added that functionality to the Linux and Windows versions.

Start on the Linux version

A quick scan through the /usr/src/linux/drivers/usb/devio.c source file reveals all about the usbdevfs file system and the ioctls required. Browse through the USB spec, a few calls to open() and ioctl(), and urb here, an urb there and I’m all done. Piece of cake.

Start on the Windows version

Shudder… Past experiences with Windows and anything to do with low level access to devices has taught me that I am in for the long haul. Each time I try to do something like this it always take 3 – 4 days or excruciating effort and unbearable pain. Oh well, I strap myself to my trusty Aeron chair and away I go. Now from the MSDN documentation I manage to surmise that as soon as a USB printer is plugged in, the “plug and pray” subsystem loads up the usbprint.sys device driver and passes control over to it. In turn usbprint.sys creates a device node, initialises it and then sets up a device interface so user space programs can access it using the usual device semantics. Great I think. I’ll just call CreateFile() to open the device and then use WriteFile() to send data to it. Couldn’t be easier. “clickety clack”, the code just flies from my fingers. CreateFile(name….). hmm.. what’s the name of the device. If it was Linux it would be /dev/usblp0 or something like that. Now what is it for Windows. A scan through the MSDN documentation reveals nothing. A search of google produces lots of hits to people asking the same question, but no answers. “Oh, oh this is going to be bad I think”. If there are no answers out there it means it is a closely guarded Microsoft secret and I am going to have to do some deep digging myself.

A more methodical scan of the MSDN docs and Google at least hints to what calls I need to make. In essence you do the following.

· Call SetupDiGetClassDevs(interface_guid, 0, 0, DIGCF_PRESENT | DIGCF_DEVICEINTERFACE) to get a list of devices.

· Call SetupDiEnumDeviceInterfaces() to get a list of available device interfaces.

· Call SetupDiGetDeviceInterfaceDetail() to fetch information for the actual device interface we are going to use.

· Use the DevicePath member of the PSP_DEVICE_INTERFACE_DETAIL_DATA structure returned by the SetupDiGetDeviceInterfaceDetail() call as the devicename/filename in the CreateFile() call.

· Call WriteFile() repeatedly to send data to the device.

· Call CloseHandle() to close the device

So in order to be able to find the name of the device, I need to find the GUID of the interface that usbprint.sys creates when it adds the devicenode to the system. Search… search… search… nothing. Search some more, nothing. Look through the Windows SDK and DDK include files with grep. Still nothing. Oh well up comes trusty old regedit, everything windows does is in the registry, and I start to wade through the myriad of nodes and entries for the GUID. After a few hours of despair I find it. The magic number is 0×28d78fad, 0×5a12, 0×11D1, 0xae, 0×5b, 0×00, 0×00, 0xf8, 0×03, 0xa8, 0xc2. You’d think Microsoft would have included it in one of the .h files (devguid.h or usbprint.h) just like they did the interface GUID for keyboards, mice, hid usb devices, usbcam devices etc. etc. etc. Oh well at least I can now call open CreateFile and Write to the printer.

So here we go:

HANDLE usbHandle = CreateFile(interfacename, GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);

WriteFile(usbhandle, buf, numbytes, &byteswrtten);

The WriteFile call fails and GetLastError() returns 1, ie. the operation is not supported.

More searching, reading, nothing turns up. It keeps failing. I remember that the DDK includes source code for the local portmonitor so I take a look to see how it calls CreateFile for the local port interface. I modify mine to be the same and try again.

HANDLE usbHandle = CreateFile(interfacename, GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, NULL);

WriteFile(usbhandle, buf, numbytes, &byteswrtten);

Success, the printer starts outputting my job. What is different above? Well replacing OPEN_EXISTING with OPEN_ALWAYS seems to have forced the driver to start the device so that the WriteFile interface is available. Previously OPEN_EXISTING would not try and create a file so the device would not start. At least that is what I think.

4 days later and I am all done.

So here is a quick snippet of some of my code to help others out there that might have the same problem. You will need both the windows SDK and DDK installed and configured correctly for this code to compile. You will also need to link your executable with the setupapi library. Below I have included the code as both an attachment and inline. It is not meant to compile out of the box. It is only there as a guide.

usbprint.c or usbprint.c

项目进入国庆前的Pre-Alpha阶段，主要的工作都集中在了FW身上，所以这周除了偶尔support一下FW，基本无事可做。

终于找了Ubuntu来研究，以打发时间。这真是一个比Windows设计理念好很多的系统。很少的资源占用，很漂亮的UI，软件的自动安装和自动升级，优秀的扩展性，再加上完全免费。。。我觉得非常适合笔记本用户安装。

奥运结束了，堵车也恢复了，我觉得甚至比奥运前都要堵，这莫非就叫反弹？大家奥运期间都憋坏了么，上班的车程只需15分钟，现在堵车就要堵30分钟，要知道这可是五环外！唯一的办法只能早点上班，晚点下班。。。

手机破碎的触摸屏坚持了半年，终于彻底挂了。头脑发热的拿去楼下的小店修理，最终结果是：触摸屏修好了，滚轮又挂掉了。。。不过外观终于变得美丽了，也避免每个人见到我手机都问：哇，你手机怎么了~不管怎么说比维修前好用了。。。

老妈寄了无敌美味的小煎兔来，哟西！咀嚼时特有的绵香味让我沉醉~~~~~~不过很久不吃川菜让我变得难以接受大料之类的调料，所以小煎兔后，再吃个梨，嗖得斯呐！

国庆快来吧！

一个摄影师，从1979年3月31日起，整18年中用pala每天拍一张。

死后，他的朋友把他的作品公布了出来：http://photooftheday.hughcrawford.com/

我生日那天他拍的照片：