哪个大侠有 inside the windows95 File System的书，给小弟扫描两页如何？

inside the windows95 File System
只需要 142~143 页的介绍  ifsmgr_setpathhook 的
部分，哪个大侠可否麻烦一下扫描了给我发过来呢？
horsedo@sina.com
40分奉上加感谢！

horsedo，实在抱歉，这两天紧急出差在外，把你的事情耽误了，
再次抱歉！！！

什么呀，这可是我从书上一行一行打出来的。

horsedo
还不另开贴子？给来100分？

在那里买的，现在还能买到吗

电子文档我没有，这本书我有。

什么呀，这可是我从书上一行一行打出来的。

老兄可否也给我一份，我出一百分
actionlxg@sina.com.cn

我也想要一本，谢谢　aresljc@163.net

我有哦

还没仔细看，先给分吧
大侠可否把整本书得电子版都给我发过来
我再给  100   分
先谢谢了，   我得EMAIL：  horsedo@sina.com
 :D :D :D

The path check routine can look for a specific signature at the beginning of the string pointed to by ESI,This string can be a prefix which is stripped off from the remainder, or it may convert the prefix into some other string or character and store it to a PathElement structure in the buffer pointed to by EDI. The prefix string may also just be copied to a PathElement. There is considerable flexibility here: from one extreme, the string may be completely parsed into PathElement before returning; to the other extreme, the entire path might be passed back and no parsing is done, only the provider ID is set. If any of the string is passed back to IFSMgr_ParsePath to complete parsing, then that portion must follow the convention that elements are delimited by / or \\ characters.

In any case, when IFSMgr_ParsePath returns., ir_ppath will contain a ParsePath structure comprised of the PathElements, some or perhaps all of which were extracted by the path check routine. This canonicalized path is really private to the FSD that has \"claimed \" it . The path becomes claimed because IFSMgr_ParsePath modifies the contents of the ifsreq structure to earmark it for a specific FSD . It does this by clearing ifs_psr, to indicate that there is no associated shell resource and by setting ifs_proid to the FSD\'s provider ID. The net effect is that instead of calling a volume-based function based on default parsing behavior, thje volume-based functions that correspond to the specified provider ID are used.

Input  Decription
===========================================================
ESI            Pointer to Unicode pathname
EDI            Destination buffer to hold PathElements
Output  Decription
===========================================================
       EAX     Length(pe_length)of last PathElement
               consumed and store to buffer at EDI
       EBX     Pointer to a Unicode string of the last
               PathElement consumed by the FSD
       EDX     Provider ID of the FSD that claimed the path.
       ESI     Pointer to Unicode pathname, next char to    
               parse
       EDI     Pointer to buffer holding zero or more
               consumed PathElements
      Carry flag  Return clear-request is hooked. else jump
               to previous path check routine.


[编辑 -  7/12/02 by  fracker]

是你要的玩艺吗？

   If the path check routine does not \"claim\" the path , then it needs to jump to the previous path check routine with all registers preserved. The last path check routine in the chain is supplied by IFSMgr; it just sets the carry flag and returns. This tells the parser to use default handling.
  
   The input to and outputs from the path check function are summarized in Table 7-3. As you can see it is entirely register-based, so it needs to be written in inline assembly code. We also see from the input arguments that by the time the path check function is called, the ir_data member of ifsreq has been translated into a Unicode string (ESI);however, the PathElements (EDI)have not been created yet.

This service has abeen provided for FSDs to check for special path prefixes and process then separately. The FSD can register a routine with the IFS manager that is called every time a path is parsed. If this is a prefix the FSD wants to process, it can claim it and IFS manger will then call FSD directly on the path-based operation.

IFSMgr_SetPathHook has the following function prototype:
  void * IFSMgr_SetPathHook( void * PathcheckFunc );
This Service installs a path check routine and returns previous path check routine, The service is available at Device Init or Init Complete time. The Path check routine is called by IFSMgr_ParsePath if the input path does not contain leading \\,/, or d: characters. What does a path check routine do ? Here is what Microsoft has to say in DOS/Win32 Installable File System Specification, p.90:

Hooking a Path
The last hook function that we\'ll take a look at , IFSMgr_SetPathHook, is closely tied to IFSMgr_ParsePath ( and IFSMgr_FSDParsePath ). Recall that IFSMGR_ParsePath is called for the value-based FSD fuctions that receive a to set up the ifsreq member ir_data). In other words, in preparation for calling FS_OpenFile, FS_FileAttributes, etc.,a call intoIFSMgr_ParsePath is needed to set up the ifsreq packet. By parsing the path string, this service fills in the ifs_psr member of the ifsreq packet, as well as the ParsePath structure required for ir_ppath.

我有哦