Win7下send的buf加密之后长度不能变化吗？有这方面经验的请移步进来

Win7下send的buf加密以后长度不能变化吗？有这方面经验的请移步进来
我的环境是win7 64位，用的delphi2010，以前在xp下用delphi7，hook了send recv，用各种加密函数都是没有问题的，近期改用64位win7+delphi2010，截取send数据以后，对其buf进行了加密处理再发出(数据长度变化了)，服务端可以正常接收到数据处理然后再发出，但此后client端就再也不收回包和发送数据了，有对此方面有经验的大大可以指点一下吗？ buf数据长度不变的情况下，发送接收是没问题的，但凡只要涉及到长度变化就出问题，自己处理的函数发送包长度已经做过对应。
------解决方案--------------------
如果是你Hook其它程序的数据包，如果长度发生变化是有问题的，有的协议是根据长度来检测的。
------解决方案--------------------
是不是新版的字符串是默认unicode方式了
------解决方案--------------------
有可能是Unicode的问题，建议用AnsiChar 或 AnsiString 试试
------解决方案--------------------
跟64位应该没有关系，delphi7只能编译出win32的程序，在win64下是以wow64环境运行的，并且你win32的程序只能hook win32的进程，既然大家都市win32环境，那么问题就跟64位没关系了。想想是不是其他的原因。
------解决方案--------------------
不是字符串宽度的问题了

那可能是加密算法的乘法溢出在32、64位下的结果不一样了
不要使用integer，而是使用确定的int32(自定义)或int64
------解决方案--------------------

引用:

引用:不是字符串宽度的问题了

那可能是加密算法的乘法溢出在32、64位下的结果不一样了
不要使用integer，而是使用确定的int32(自定义)或int64

结果是一样的，肯定没有错误，已经做过详细的调试了。

这几天翻阅资料，应该是win7下的一种特权保护机制在做怪

普通的加密运算，会涉及特权保护机制？
------解决方案--------------------
肯定是用了strlen之类的函数来判断大小吧 
这个函数遇到0就会报数 也就是断了  
------解决方案--------------------
程序是管理员身份，并用32位兼容模式 ，试试看下，有没有问题。
------解决方案--------------------
我有类似的问题，不过没楼主场景那么复杂，在xp下一个socket通信程序没有问题，放到win7/win8上，就会在完成一次塔发送接受通讯后，报sokcet错误消息