Error

武汉-Error<errorcpp@qq.com> 16:37:38
嗯

讨论一个VC的问题 
武汉-Error<errorcpp@qq.com> 16:37:51
夸进程的 WM_DATACOPY
武汉-Error<errorcpp@qq.com> 16:38:00
的内存管理
武汉-Error<errorcpp@qq.com> 16:38:07
谁先发言？

南昌-贝贝(1125591)  16:38:29
进程内没必要用这个
湖南-VC(215735031)  16:39:03
不知道把clicpsrv服务关掉，这个还会不会调用成功
武汉-Error<errorcpp@qq.com>  16:39:03
 那内存是那个牛管理的
南昌-贝贝(1125591)  16:39:20
共享内存啊
武汉-不语(86990476)  16:39:22

武汉-Error<errorcpp@qq.com>  16:39:30
如果偶没记错
武汉-Error<errorcpp@qq.com>  16:39:54
网狐的代码 是 在把栈上的一块内存的地址
武汉-Error<errorcpp@qq.com>  16:40:08
当作copydata结构体的指针域
湖南-VC(215735031)  16:40:16
error再搞网狐？
武汉-Error<errorcpp@qq.com>  16:40:17
sendmessage
武汉-Error<errorcpp@qq.com>  16:40:19
出去的
武汉-Error<errorcpp@qq.com>  16:40:31
这样就说明
武汉-Error<errorcpp@qq.com>  16:40:43
系统 应该接管了这块内存
武汉-Error<errorcpp@qq.com>  16:40:55
谁知道这其中是怎么管理的
湖南-VC(215735031)  16:41:04

武汉-Error<errorcpp@qq.com>  16:41:07
是的，看了好久了。
最近开始看客户端了
武汉-Error<errorcpp@qq.com>  16:41:34
 其实我只关系生命周期
武汉-Error<errorcpp@qq.com>  16:41:46
无所不能的贝贝神
武汉-Error<errorcpp@qq.com>  16:41:48

南昌-贝贝(1125591)  16:42:13
就是共享内存呀
中山-疯子(510776002)  16:42:03
贝神学的太快了
武汉-Error<errorcpp@qq.com>  16:42:42
嗯 假设他就是共享内存
那是谁申请 谁释放的呢？
南昌-贝贝(1125591)  16:42:57
发送者申请,发送者释放
武汉-Error<errorcpp@qq.com>  16:43:56
嗯，假设是发送至申请 发送者释放
那人家那里放的是一个指针地址，接受的时候咋成了共享内存了

偶去看看接收代码
南昌-贝贝(1125591)  16:44:57
进程使用的内存都是由系统在物理存储里面调拨的....然后映射到这个进程的...系统多映射一个进程,有什么不可以的咧?
中山-疯子(510776002)  16:44:55
仙路尽头谁为峰，一见贝神道成空
武汉-Error<errorcpp@qq.com>  16:45:57
那就是说，发送的结构体 和 接受的结构体 的那个指针域
武汉-Error<errorcpp@qq.com>  16:46:06
可能不是一个值
武汉-Error<errorcpp@qq.com>  16:46:09
对吧？
南昌-贝贝(1125591)  16:46:18
什么东东
南昌-贝贝(1125591)  16:46:20
听不懂
湖南-VC(215735031)  16:46:43
A进程里发的数据的内存地址 跟B接收的内存地址
南昌-贝贝(1125591)  16:46:52
发送的时候把这个结构体中指针指向的内存块(指定大小),映射到目标进程 
中山-疯子(510776002)  16:47:10
对了，问下如何追踪到WM_COPYDATA的处理函数，这个问题难了我好久，一直没有解决
武汉-Error<errorcpp@qq.com>  16:48:11
嗯，贝贝说的原理。偶懂了，偶现在想确认下这个现象，，，

比较懒，没写测试就直接问了，，，
见谅，，，


武汉-Error<errorcpp@qq.com>  16:48:20
typedef struct tagCOPYDATASTRUCT { 
    ULONG_PTR dwData; 
    DWORD     cbData; 
    PVOID     lpData; 
} COPYDATASTRUCT, *PCOPYDATASTRUCT; 


这个结构体的   dwData
中山-疯子(510776002)  16:48:21
应为是在另一个进程中，不知怎么办
湖南-VC(215735031)  16:48:41
恩，你测试的时候顺便测试下我那个疑问哈
南昌-贝贝(1125591)  16:48:47
dwData 就是传一个数字
武汉-Error<errorcpp@qq.com>  16:48:46
在发送进程的值  和 在另一进程中 收到的值
武汉-Error<errorcpp@qq.com>  16:48:52
是不相同的
武汉-Error<errorcpp@qq.com>  16:49:13
湖南 是和我考虑的一个问题吧？
湖南-VC(215735031)  16:49:28
是的，
湖南-VC(215735031)  16:49:42
不过你观察的是它们通信的过程
武汉-Error<errorcpp@qq.com>  16:49:51
嗯，我看的是现象
湖南-VC(215735031)  16:50:00
我还顺带观察下这个过程是不是由剪贴板服务维护的
中山-疯子(510776002)  16:50:01
就是另一个进程处理WM_COPYDATA的函数
武汉-Error<errorcpp@qq.com>  16:50:21
还有资源释放的过程
湖南-VC(215735031)  16:50:33
如果这个服务关掉了，还有没有。
武汉-Error<errorcpp@qq.com>  16:50:38
按照贝贝说的来理解，我就懂了一点了
湖南-VC(215735031)  16:51:15
说到底，还是WINDOWS的内存划分不清晰啊。
湖南-VC(215735031)  16:51:27
共享内存，内存地址是多少
湖南-VC(215735031)  16:51:57
kernel32.dll 类似这种东东，系统都把它们映射到进程的 0x800以上
武汉-Error<errorcpp@qq.com>  16:52:06
send的时候OS只是映射了一下
当被映射的内存释放以后，自然数据就失效了

不过这还有一个没解决的问题，数据失效了，映射又由谁清理
湖南-VC(215735031)  16:52:23
按贝贝说的说法，剪贴板内容也应该映射到某个地址。
南昌-贝贝(1125591)  16:52:24
kernel32.dll 类似这种东东，系统都把它们映射到进程的 0x800以上
谁说的
湖南-VC(215735031)  16:52:36
默认情况
南昌-贝贝(1125591)  16:52:50
0x80000000 以上就错
武汉-Error<errorcpp@qq.com>  16:52:56
敢在贝爷面前玩小聪明
南昌-贝贝(1125591)  16:53:07
剪贴版不一定是共享内存
武汉-Error<errorcpp@qq.com>  16:53:22
贝贝 偶的问题还没回答完毕呢

映射我理解了
湖南-VC(215735031)  16:53:32
你理解什么了。
武汉-Error<errorcpp@qq.com>  16:53:36
但是这个映射最终还是要被 取消

这一部咋弄
湖南-VC(215735031)  16:53:47
贝贝刚都说了， 
武汉-Error<errorcpp@qq.com>  16:54:03
就是OS没有拷贝send的数据，只是把两个进程的地址映射了下
武汉-Error<errorcpp@qq.com>  16:54:26
偶不关系那个过程，我值关注数据传递的结果
湖南-VC(215735031)  16:54:36
每一个进程都可以访问剪贴板的数据，
湖南-VC(215735031)  16:54:50
你A进程发送的数据肯定也是进了剪贴板的
武汉-Error<errorcpp@qq.com>  16:55:02
现在的结果：
1.没有传递
2.是地址映射
3.系统完成的映射
4.我不知道神马时候映射被取消
湖南-VC(215735031)  16:55:32
大哥，我们的疑问其实一样
武汉-Error<errorcpp@qq.com>  16:55:56
否则我大量 发送DATACOPY 这样两个进程的数据不是全部被映射了，，，

所以，偶要知道这个映射啥时候取消
湖南-VC(215735031)  16:56:15

湖南-VC(215735031)  16:56:22
A B 是进程 C是剪贴板
南昌-贝贝(1125591)  16:56:31
我也不知道怎么解释,可能我说的不准确,是因为我要表达的是

如果你在记事本中复制一个字符串那是共享内存(服务里面的)
如果你的程序会接收处理剪贴版消息,那会有另一种行为...大多数人都应该见过,在WORD中复制表格.在词本中粘贴是纯文字 ,在QQ上粘贴是图像
南昌-贝贝(1125591)  16:56:41
如果单纯共享一次.那怎么做得到
湖南-VC(215735031)  16:57:17
我记得在VC中使用WM_COPYDATA 要显示的指定
武汉-Error<errorcpp@qq.com>  16:57:21
 还是没有解释 4.映射（共享）啥时候取消嘛
湖南-VC(215735031)  16:57:45
这可能说明了， 
南昌-贝贝(1125591)  16:57:47
我知道水神主要的疑问就是 WM_COPYDATA 何时取消映射
  只需要回答你(PostMessage->WM_COPYDATA是永不会成功的)
武汉-Error<errorcpp@qq.com>  16:58:20
send返回的时候么

列个是同步的？
武汉-Error<errorcpp@qq.com>  16:58:29
ok我的问题差不多解决了
湖南-VC(215735031)  16:58:31
估计每个进程访问到的剪贴板内存都是系统分配的一个”映像“
武汉-Error<errorcpp@qq.com>  16:58:52
VC的 和 ole对象神马相关 还有com模型，，，这个话题老大了，，，
南昌-贝贝(1125591)  16:59:13
COM我也是笨蛋,  太久远了
湖南-VC(215735031)  16:59:49
我的疑问是，系统给每个进程都留了一个后门，可以访问一块共同的内存？
武汉-Error<errorcpp@qq.com>  17:00:04
ole模型好像是这样
湖南-VC(215735031)  17:00:23
还是进程需要访问“剪贴板”的时候，显示的给它映射一个
中山-疯子(510776002)  17:00:34
追踪WM_COPYDATA
武汉-Error<errorcpp@qq.com>  17:01:05
 中山-疯子(510776002)  17:00:34
追踪WM_COPYDATA

自己打log
湖南-VC(215735031)  17:01:11
如果是后门，水神你那个A发起，B收到的就是同一个地址才对
武汉-Error<errorcpp@qq.com>  17:01:13
或者用windbg
武汉-Error<errorcpp@qq.com>  17:01:26
是映射
武汉-Error<errorcpp@qq.com>  17:01:31
不同的进程
武汉-Error<errorcpp@qq.com>  17:01:39
地址空间不同
湖南-VC(215735031)  17:01:43
如果是谁用到，给谁映射，那A发起的被映射到系统，再被映射到B进程
武汉-Error<errorcpp@qq.com>  17:01:49
是的
武汉-Error<errorcpp@qq.com>  17:01:54
谁send
武汉-Error<errorcpp@qq.com>  17:01:59
岁映射
湖南-VC(215735031)  17:02:18
我现在不好写测试， 你A发起的， 剪贴板能看到不
武汉-Error<errorcpp@qq.com>  17:02:34
不然生命周期不好控制

以上是贝神语录心得

我现在也没环境测试，，，