Windows NT File System Internals：A Developer's Guide 精美完整版（附随书源码）要这本书的看这里

    做驱动程序开发，好书是一定少不了的，今天也来给驱动开发论坛做下贡献，把我的珍藏级好书奉献给所有热爱驱动程序开发的朋友们，没有广告，没有密码，没有次数，没有速度限制，不过下载后请一定爱惜哟。
    书名:<<Windows NT File System Internals：A Developer's Guide 精美完整版（附随书源码）>>，迄今为止唯一的一本专门讲述文件系统驱动程序的著作，共12M多，分4个压缩包。
    站点:阿荣小站:[url] http://www.ronggang.533.net[/url]->"其它作品"->"更多作品"->"程序开发"栏中，有需要的朋友前去下载吧，请用网际快车等下载工具下载，直接另存是不能成功的，下载速度爆快。我会慢慢把我珍藏的其它好书放上去的，欢迎朋友们经常来逛逛。
    从此以后，希望网上不会再有找本书电子版的贴子了。
    喜欢本书的，不要只顾下载，请顶一下!

虽说不能下载，但哥们还是顶!

正在下载，谢谢！

fzx_qd朋友，是否是用网际快车下载呢?硬盘上空间是否足够?我刚才又试了一下，4个链接下载非常正常!速度爆快，没有出现连不上的情况呀。我选用是非常稳定的服务器，不会出现下不了的情况吧!本人主要是想给驱动论坛的朋友们做件好事，如果下载不了，就有违我的初衷了，你可以再试试。谢谢你的回复!我会奉献更多的好书，请有空常来逛逛!

噫，那就奇怪了，我点那个更多作品后，IE连接到http://qtzp.htm/，但连不上啊！不知为什么！

我连网页都打不开，更别说下载了。

另外，你的这个完整版跟网上的那个PDF版有何不同？难道这个完整版是你自己扫描的？

啊，连qtzp.htm都打不开，那我没办法了，我每次都能打开的。你可以晚些再试试看，应该没问题，533.net的服务器还是比较稳定的哟。这个电子版是我从国外一家网站上收集来的，我们公司就有这本书，我对比了一下，非常完整，扫描得也很不错，应该是可以满足收藏的需要了，楼上说的其它版本我没有下过，不知道是不是这个版本，没法比较。另我也将原书配套光盘一并打包，提供下载，所以应该是完整版了。各位不要怀疑，纯粹是无偿提供，提供给需要的朋友，闲人免下!

虽然不能下载，但是还是顶一下。
当初费了好大的劲找这本书的电子版，
就是那个pdf的版本。
遗憾的是那个版本好像是扫描的那种，
有几章有一些错误，个别还有几页缺损，看着很郁闷。
不知道你这个是不是同样的版本，
如果能够更加完美一点就好了！：）

各位还是打不开，我郁闷，试试这两个网址呢:
http://ronggang.html.533.net/或http://ronggang.533.net

我一打开上面的网址，IE就永远是如下的画面：

首页应该如下图，是不是没有安装flash插件，完全可以理解你急迫的心情，我也是真心想帮大家，来，这个网址应该没问题，祝好运!
http://ronggang.html.533.net/qtzp.htm

我下完后和站上的版本比较了一下，是同一个版本。
楼主不知能否做点好事，将其中的缺损的几页描下来？
196页损坏
缺67,152,153页
其它地方记不住了，有知道的说一下。

这回可以下了，但是如果是一样的版本的话，
就像楼上所说，楼主有书的话帮忙把缺的那几页描出来吧，
我只看到第四章，记得有缺损的部分，
回头检查一下发出来，大家也都动员一下，
找找哪些需要补全：）

呵呵，也好，差那些页报上来，我来给大家做做好事!

我记得好像是后面几章有几页有一半没有，那几页好像很关键的。

我花了五分钟，把我打印的翻了一遍，要补的页如下：
67,152,153，196页
460,356,357,358,

还是有不少热心人呀，明天就会有好消息，敬请期待!

152页:
stored in the UserApcContext field. Some examples of asynchronous system services are directory control, read, write, and lock operations. Note that create/open requests are always processed synchronously, and therefore the AllocationSize field and the AsynchronousParameters form part of the Overlay union structure.

For I/O operations that involve transferring data, the caller supplies a data buffer. This buffer might serve as an input buffer, an output buffer, or both. In any case, the I/O Manager initializes the UserBuffer field with the caller-supplied buffer pointer before invoking IoCallDriver(). Upon IRP completion, if there is any data that needs to be copied back to the caller's buffer, the I/O Manager performs this function as part of postprocessing done on the IRP. If your driver does not specify either direct I/O or buffered I/O as the preferred method of user buffer manipulation, the I/O Manager will assume that you will handle the user-supplied buffer yourself and will therefore not allocate an MDL, or supply your driver with a system address. Your driver can subsequently use the buffer pointer in the UserBuffer field directly.[15]

Tail
An IRP has a Tail structure defined as follows:
union { struct { KDEVICE_QUEUE_ENTRY DeviceQueueEntry; PETHREAD Thread; PCHAR AuxiliaryBuffer; LIST_ENTRY ListEntry; struct _IO_STACK_LOCATION *CurrentStackLocation; PFILE_OBJECT OriginalFileObject; } Overlay; KAPC Apc; ULONG CompletionKey; } Tail;


This structure consists of fields that are manipulated and accessed directly only by the NT I/O Manager. It is not recommended that your driver try to directly access the contents of these fields.

The DeviceQueueEntry field is used to queue IRPs for a specific lower-level driver. Most lower-level drivers allow the NT I/O Manager to maintain a list of pending I/O Request Packets. The I/O Manager uses the DeviceQueueEntry field to queue the packet for the target device object, if the device object is found to be busy when IoStartPacket() is invoked by the device driver dispatch


153页:
routine. The DDK describes the IoStartPacket(), IoStartNextPacket(), and IoStartNextPacketByKey() support routines, which manipulate this field. Kernel-mode drivers should not try to directly access or manipulate the contents of the DeviceQueueEntry field.

Before dispatching an IRP, the I/O Manager initializes the Thread field to point to the thread in whose context the dispatch will occur. This field is subsequently used by both lower-level drivers and file system drivers.

Consider the situation when a hard error occurs. File systems use the IoRaiseInformationalHardError() call to place a pop-up message box on the system console to notify the user of the error situation. This call is blocking and it displays the error by delivering a special kernel APC to the target thread. The problem is that the thread in whose context the message box is displayed is blocked until a user physically dismisses the error message from the system console. If, however, no thread is specified in the argument list to the IoRaiseInformationalHardError() routine, the error message is delivered in the context of a special (single) system worker thread.

Typically, if an error occurs, a kernel-mode driver will examine the Overlay.Thread field to determine if the thread is a system worker thread. If it is, then the driver will send in a NULL Thread argument to IoRaiseInformationalHardError(), because blocking system worker threads for an indefinite amount of time is clearly unacceptable.

Another instance when the Thread field assumes importance is in the handling of removable media. If a user-induced error occurs when reading/writing removable media, the lower level device driver uses the IoSetHardErrorOrVerifyDevice() routine to indicate that something unexpected has occurred and that higher-level drivers should either report an error to the user or verify that the media in the drive is correct. In response to this call, the I/O Manager simply stores the device object to be verified in the DeviceToVerify field for the thread object pointed to by the Overlay.Thread field in the IRP. The higher-level (file system) driver subsequently invokes IoGetDeviceToVerify(), supplying the thread object pointer obtained from the Overlay.Irp field, and the I/O Manager, in response, hands back the stored device object pointer.

Note that the IoAllocateIrp() I/O Manager service routine does not set the Thread object in the returned IRP. This is the responsibility of the caller of this routine.

The AuxiliaryBuffer exists supposedly to pass additional information to a kernel-mode driver that is not contained elsewhere in the IRP. However, at this point, none of the I/O Manager routines use this field to pass information to a kernel-mode driver.[16]

我刚从网上收集到Chapter 4(The NT I/O Manager)的全部内容，比较完整，包括了原书的117-193页，需要的可以在我的站上去下来看。其它的页67，196，460，356，357，358我有空会上传上来，但我看了一下，原书的pdf版，丢失较多，限于本人精力有限，恐难全部扫描，还请谅解。

找不到

本人已经利用业余时间，将67，196，460页扫描上载，有需要的可以去我的小站下载，356，357，358原书中就不存在，各位不要以为是掉了页。