是否可以“拦截”第 3 方库的“WriteFile”操作答案

【问题标题】：Is it possible to "intercept" a 3rd party library's "WriteFile" operation是否可以“拦截”第 3 方库的“WriteFile”操作
【发布时间】：2010-05-27 16:39:37
【问题描述】：

这可能是一个很长的问题，但我想我还是会问。我正在使用文档管理系统的 API。它们提供了一种“WriteFile”方法来将给定的文档保存到磁盘。但是，该库没有办法简单地将文档读入内存。看来，我唯一的选择是写入磁盘，然后再次读回。我想知道是否有更好的方法来解决这个明显的限制。

该方法采用一个字符串作为结果文件路径。方法签名：

void ImageInfo.WriteFile(string Filename);

【问题讨论】：

你向他们的 WriteFile API 传递了什么？文件名，还是打开的文件？
@psmears：正是我要问的。
所以您的目标是避免从磁盘读取文件？出于性能原因？

标签： c# writefile

【解决方案1】：

理论上，可以使用称为Import Address Table Hooking 的东西拦截任何进程的WriteFile win32 API 调用，无论是.NET、C++ 等，这实际上是Windows 软件测试中的一个有价值的工具。

基本上，您可以覆盖导入地址表中的 WriteFile,kernel32.dll 条目以指向您的方法，然后拦截尝试写入的字节。

在上面的层中可能还有其他方法，例如在 .NET 中，您可以更改 3rd 方应用程序 dll 的 ILASM 代码。或者拥有一些您自己的 .NET dll 版本来替换一些标准 .NET 类。

实际上，这可能并不值得，例如如果 API 没有明确地将文件刷新到磁盘，那么您的后续读取可能最终来自操作系统文件缓存，并且不会是那么大的性能问题。您可以通过在调用 WriteFile 之前创建文件并保持打开状态来实现这一点（只是猜测）。

当然，我想您已经对其进行了分析和测量。

【讨论】：

【解决方案2】：

您需要一个可以调用托管代码回调的 Windows API 挂钩库。 Easyhook 就是这样一个库。请注意，完成后您可能会发现您没有获得任何东西，文件系统缓存已经提供了对文件数据的直接内存访问。

【讨论】：

【解决方案3】：

听起来 API 不提供读取部分，因为它们无法提供比 .NET 框架中已有的更好（性能更高）的方式。

【讨论】：