关于Dialer在win7/vista下上网卡在不同USB口来顺插拔导致的dial-up属性意外修改的问题的解决

如标题所述的问题，其实来来回回修改了好几天了。最直接的解决办法当然是在切换USB口的时候修改phk文件了，但是在win7/vista/xp下这个文件的路径都不相同，有的在all users的application data下，有的在current users的application data下，所以修改无效，这是第一次。想到既然在切换USB口时发生了这一切，而初次切换时，安装程序都会自动跑一次，那么让安装程序跑起来的时候帮助删一下dial-up，再由dialer自己来建，新dial-up属性就应该是正常的了。这个方案忽略了安装程序只“初次”切换的时候会跑起来，如果两个USB口都切换了多次，它就不会删除了，所又一次失败了。。。

问题的直接原因是切换USB口后，modem属性中port与Device都改变了，比如说COM5与VIA Telecom USB Modem改为COM10与VIA Telecom USB Modem #2。而PHK文件相应配置却没有改变(同样的dialp-up，两者不一致了)，这种情况下，windows会把某些属性(可能与这两个属性是相关的，比如Enable modem compression等)显示为默认值(而不是PHK文件中所配置的)。这样要解决它，就是在切换USB口时，取得modem此时的真实port与device，然后把PHK文件中的相关配置改了。然而获取port号时出现了一个问题：当dialer被service程序自动运行时(手动运行不会出现后面的情况)，即使使用RasEnumDevices函数成功枚举到相关modem，再用SetupDiGetClassDevs,SetupDiEnumDeviceInfo等函数枚举相同的modem居然失败了。这样，通过setup函数得到相关port的属性的愿望自然落空了。

出现这种情况时，我的思路一直在努力钻研相关API的用法上打转。虽然也考虑了一下自动运行与手动打开dialer的差异，却没有深究。其实仔细想一下两种情况的差异，就能想到：自动运行service程序检测到windows刚刚辨认到设备之后(可能尚未完全稳定，一些初始化工作可能还没做)，马上调用 dialer运行起来的，而手动的话，通常都是设备早已被windows检测到了。而上段所说的两个函数族(ras,setup)在枚举设备时可能的确存在时间上的差异。于是解决办法就出来了，当ras函数枚举到设备后，用setup函数再去枚举，如果失败，停一秒，再重新枚举一次，如此循环。果然，如果是自运行的话，两者的时间通常要相关5到6秒。

这个过程告诉我们，当某种情况下出现问题时，找到一种不出问题的情况，分析两种情况的差异，答案往往就在这差异中。