我太强大了

始于上周四晚上，一个刚购买了Audio CD Burner的丹麦客户因为刻录出了问题，而给他退了单。发现是04年我们购买的刻录组件（MACDB）的bug，对于时间稍长的音轨刻录就会出问题。

当天晚上以及其后的连续几天晚上都通宵，设法解决该问题。由于该组件我们购买的是不含源码的版本，而现在卖家已经零维护了（联系都联系不上了），网上又找不到盗版破解版源码版，几乎束手无策。然后决定改用03年购买的同一个卖家的另外一套刻录组件（CueBurner），却在更改完成之后的测试中发现在vista系统下刻录的稳定性比之前用的控件相差很远……

昨天下午睡觉做梦中，满脑子都是改这个东西的代码……

后来想想，还是放弃了CueBurner方案，集中精力再在MACDB上想想办法。昨晚，在奥运闭幕式时，我去大便了。而在大便时，突然想明白了MACDB出错的原因：是因为65535！也就是当一个音频文件的帧数大于65535时，传进去组件后，居然就如同将一个32位整数赋值给一个16位整数那样，被“截断”了。

当然，想明白这一层，至此意义还不大。于是想能不能反编译组件代码看看是哪个变量弄错了类型。下载了Dcu2Pas工具，将MACDB组件反编译成pas文件（这些pas是无法被编译的）。当然，凭借我这点汇编基础要想看懂反编译出来的代码，几乎是不可能的。也因此几乎放弃了这一途径。

半夜，床上躺了一个小时却睡不着，于是起床继续看反编译出来的那些pas文件，以及做一些无用的尝试。这些pas文件虽然无法被编译，执行代码也几乎看不懂，却带来一个好处：我能看到所有类的声明，包括私有成员。

在半夜两点多的某一刻，灵感来了！

能了解到所有类的定义，很重要！
当然，之前所领悟的65535也突然变得有意义起来！

其实，在将音频文件传入组件后，它的长度必定是存在某个变量（成员）里，虽然我不明白为什么会被“截断”，但是我可以找到这个成员所在位置，即使它是私有的，我也可以通过指针直接访问其内存对它进行修改！找到后，我只要在其基础上，再加上65535的n倍（n为“真实长度”整除“被截断后的值”）即可。

先取得组件本身的指针，然后通过偏移找到其某一个私有成员的地址，再……

抑制住内心的激动，和忐忑（因为尚未验证确实可行），修改了实验性的代码，测试！成功了！哇咔咔咔咔，我太强大了！

可惜半夜里，找不到人分享喜悦，只好叫醒老婆 ，当然，老婆得知后也很高兴。毕竟，困扰了4天的一个问题，几乎快要放弃的一个难题。

呵呵，解决方法当然并不算高深，但是，经过那么多曲折才找到的，即使是间草屋，也是柳暗花明啊！