传奇升级64位引擎需要注意的事情

这也是今天把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位，会继续发出来。