过几天在写……嘿嘿，这两天不在家。

先开头。用了VC++.NET 2008写DLL文件，本来是不想动这个东西的，毕竟不熟练；不过最近发现汇编更不熟练，导致全用汇编代码实现出了大乱子，过些天有时间回头再搞搞看看。

基本思路是用VB.NET 2008写主程序，通过WM_COPYDATA消息来交换数据；

主程序负责以下内容：

1、远线程注入

2、远线程初始化DLL运行所需要的参数

3、远线程调用钩子函数挂接钩子

4、重载主窗体消息函数接受WM_COPYDATA消息并处理

5、分析封包并显示相应内容

6、远线程卸载钩子

7、远线程卸载DLL

DLL负责一下内容：

1、提供钩子挂接函数

2、提供钩子函数

3、提供卸载钩子函数

4、将封包内容发送到主程序主窗体

毕竟VC++.NET用起来不上手，所以负责的内容少一些，都是用主程序远线程控制的，毕竟写了远线程运行的功能嘛：）

由此带来的一些问题就是这个DLL的功能只能由远线程调用，无法注入之后自行完成……如果想自行完成可以参看一些C语言的代码（在DLL“装载时就运行的那个函数”那里加一些代码……不属于本文范畴了，本来我也不是为了VC++.NET来写）

在实际写的过程中遇到了几个小问题，主要是VB.NET这方面的，可能是因为VC++.NET不上手所以使用起来更小心一些，没出现什么漏子……其 中解决起来最耗时的是重载消息处理函数处理WM_COPYDATA时LPARAM参数的获取，参考了一些C#代码，受到误导……并不是说C#代码不正确， 而是直接转VB.NET之后有一个不安全指针的问题，VB.NET是不允许的，所以在使用M.GETLPARAM函数时经常出现“外部程序发生错误”的提 示，很模糊。不过经过多次验证（远线程测试DLL的函数，另请教了一位达人），其他代码都没有问题的情况下，决定仔细研究一下这个自动的数据交换，发现问 题并不是出在共享内存读写等过程，而是LPARAM达到本进程之后的处理上，在M.GETLPARAM函数处出现的问题是由于传入的TYPE类型封装传递的过程中有不符造成的，于是采用了自己读LPDATA的方法，而不是交给M.GETLPARAM来一起处理，至此问题解决。

过几天回来了先贴上远线程调用API的代码，是在上一篇远线程调用ASM的基础上实现的。

然后修改一下VC++.NET的代码，优化一下效率（可能思路还是把一些工作交给主程序完成，让DLL代码更少），然后贴出来。