| 这也是今天把M2跑到Win11引起我重视的问题。 首先需要明确一件事情，M2内的所有对象地址，都是以Integer进行转换的。 注意到什么了吗？Integer？ 没错，即使你把编译环境切换成Win64，得到的那也只是个披着64位的壳子的32位M2，因为M2内部依然是用32位进行转换。 有发现问题吗？ 如果这个对象位于4G内存之内倒是可以了，位于4G内存开外可就要出大问题了。 如果对象位于4G内存开外，直接使用Integer取地址会导致数值缺失一部分，无法正确寻找对象。 举个例子 （假定左侧为高位，右侧为低位） 已知一个32位数据结构能存储的最大值是 FFFFFFFF 那么如果一个位于内存地址 0000000E FFFFFFFF 的对象 这中转换会导致什么？ 如你所见，前面的0000000E在转换时由于32位只能存下低位的8个F，被切掉了 转换出来的只有FFFFFFFF 那么当后续代码去把这个数值转换成对象的时候，由于0000000E缺失，本该访问0000000E FFFFFFFF，变成了访问FFFFFFFF，这任哪个能看懂内存地址的都知道，地址都tm变了，还正确访问个屁。 看看惨痛的教训  总之，如果想升级到真64位，肯定需要改动的位置：TCmdPack（把相关的Integer改为Int64，不区分是32位版还是64位版，不然导致的结果就是32位服务端只能对应32位客户端，64位服务端只能对应64位客户端）、EDCode内负责操作TCmdPack的函数、RunGate内由重复定义的结构，需要删掉。 TCmdPack还得保证修改完的大小是3的倍数（这个是代码里面写的，你也可以把相关的计算规则全都换掉，不然就按照这个规矩来，同时记得要改DEFBLOCKSIZE为SizeOf(TCmdPack) div 3 * 4，而且有些地方是直接使用的原值16，而不是使用DEFBLOCKSIZE这个常量，改的时候要额外注意一下），然后就涉及到，改完之后，所有涉及到TCmdPack里面原32位数的操作，都会变成64位操作，至于有些取高低字节和高低字的，可能也会因此需要进行修改，这也不小而且相当繁琐的工程，具体需要多长时间我也不知道，因为我也改失败了。 总之，上面这些就是我目前得出的结论，如果后续还有什么发现，或者成功升级到64位，会继续发出来。 |
声明：本文系互联网搜索而收集整理，不以盈利性为目的，文字、图文资料源于互联网且共享于互联网。
如有侵权，请联系 yao4fvip#qq.com （#改@） 删除。
如有侵权，请联系 yao4fvip#qq.com （#改@） 删除。
