情况说明
- 公司用的一套PB（PowerBuilder）程序，每天通过FTP上传一份字符文件的报表。这个老旧系统没有源代码，只有运行程序各个组件。
- 这个程序看似无法摆脱，还要用它到正式退休为止
- 程序原来运行在XP 32bit，有安装程序和运行目录，10年以上未做更改，看似在win7，10（62位或32位）其它功能也算正常，只是ftp传输时报错。
排查过程
通过某个进程查看软件，依次查找在win7平台下使用到的系统组件（system32）dll文件。
本文只在win7 32位和64位下进行了测试，但根据查出的原因和后序现象，应该可以在win10，64，32位可以使用。
- 发现使用了socketnet，等系统组件，是通过PB的某个network控件去调用的。曾经试图替换这些控件，但结果是不可行。因为系统并没有多大问题。这个过程中偶然发现，
WIn7以后，系统默认禁止打开10000以下的TCP端口进行数据传输
而这好像是无法突破的，大约也是后来才知道 - 在十分无奈的情况下，我用PB的反编译了FTP功能DLL，名叫network相关的。然后阅读了相关功能代码，了解了一下FTP传输的过程，在打开FTP IP ：21端口进行用户登陆以后，传输客户方也就是本地会打开一个新的本地端口，把要上传的文件字节流放上次，等待对方来取。而这个端口号是PB组件，通过操作系统底层组件调用，分配过来空闲端口。
- 这个端口在xp时代是10000以下的数字。在PB中这个字段的数据类型为16位整数好像范围-32768 到 +32767。在win7以上的平台下，FTP传输，有时能能功，有时不能成功。成了一个概率总是，原因在于这个端口号有时候会超出范围。
解析原因
通过使用进程追踪和反编译工具，大概定位了故障出现的原因，在win7下，FTP照样要去打开本地端口提供文件上传。而这个端是随机的而且有时是比较大的数值，一但超过PB整数32768这个最大取值。就会出错。
提出方案
根据故障现像我有两个解决办法，
- 在二进制文件中我定拉到了这个值所在的位置，可以手工将它指定在一个全格数值。如8888.也许这会造成一个问题，端口占用，但这种情况不太会出现。但是做为程序员，我不满足于此
- 给这个值的类型进行重新定义，为了找到类型的位置，我在PB平台下写了一个最简单的程序，只时行了一次变量定义，然后编译成dll文件，然后修改变量定义，再次生成dll文件，对比两个文件。发现有两个地方存在差异，也就是类型定义造成的差异。我是将有符号整型，变成了无符号整型。或者是增加到了32位整数类型。具体已经不太记得清楚了。在这样做的情况下。将原有的dll文件，类型定义位置，修改成新的合格类型。做为新dll文件，替换原来旧的。并运行程序里的FTP上传功能，不再报错。
实施测试
因为方案2在可行性上存在问题，而且原有的程序存在一定机率也会成功。所以当我按照更改dll方案，联系上级接收方进行第一次在线测试的时候，发现传输依然失败。
而1的方案没在测试选项中，这次联合测试最终失败了。
不久后我应该是修改了32位整数类型，反正最终才绕过了win7等高版本平台的限制，并且也在64位win7环境下进行了传输测试，每次都是成功的。在这个过程中也使用端口查看程序，看到了FTP新建端口的打开和关闭。
最终实验才算完结，然而并没有再次进行上传测试。
因为毕竟对于新的系统环境，并不能排除其它模块还会出现哪些问题。而上传可能是其中一个被发现的而已。
所以迁移工作并没有进行下去，也没有推广开。只是个别单位有人做了使用，发现结果还行，这也是最让作者开心的一件事了。