还是因为那个8点半前要启动近百套报盘程序的问题，差不多两周前表示自己会抽空给解决掉，一次性启动，直到昨天才差不多能够抽点时间出来开始想怎么解决的问题。

这个问题的复杂点在于除了启动exe外，还需要鼠标点击界面上的登录并输入用户名密码，然后选择通道进行启动，一个程序可能会有多个通道。其次，它是用vc ++写的，但是笔者并没有c++的开发经验，所以即使拿到直接的dll也没有用。

所以，一开始考虑通过windows远程桌面登录，并在登录的时候自动启动程序，于是baidu/bing了下，确实有，类似如下：

https://zhidao.baidu.com/question/215168970.html

https://zhidao.baidu.com/question/215168970.html?qbl=relate_question_0&word=%D4%B6%B3%CC%D7%C0%C3%E6%D4%CB%D0%D0%D6%B8%B6%A8%B3%CC%D0%F2

于是发现，到windows 10的时候，这个程序的tab选项消失了，于是msdn继续搜，可知rdp本身就是一个配置文件而已，具体就不详细说了，有需要的可参考如下：

https://social.technet.microsoft.com/Forums/en-US/8498aa46-309b-47f2-9f31-fa66c3c905f0/program-tab-missing-from-windows-10-remote-desktop-connection-and-the-history-brought-from-windows-8?forum=win10itprovirt

反正各种改，包括改组策略里面的值（组策略实时生效http://blog.sina.com.cn/s/blog_44e5d6d10100znkk.html），等等各种测试，差不多折腾了1个小时左右，发现通过rdp登录自动启动exe方式不怎么靠谱和稳定、而且windows 7 64位之后和之前相差的太多，果断换方案，在目标服务器上丢一个代理，远程通过http进行控制。

于是随即就改了方案，通过java加载配置文件中的exe路径去启动，然后报盘程序在被启动之后主动socket连接到监控程序，监控程序接下去反向控制所有的报盘程序。差不多一个下午，服务端就整个框架和大部分代码结构就完成了。

从这个问题引申出的（包括昨天下午我们公司在讨论有些客户测试出来的安全性问题时）一个重要现象在于，很多中小型公司或者部门，通常解决问题的方式是打地鼠式或者说头痛医头、脚痛医脚、拿来就用（跟大公司里面的刚好是两个极端），在真正行动前并没有花一些时间去思考一下真正的问题源头和当前采用方案的不稳定性而不是稳定性在哪里，结果导致很多问题持续几个月都没有解决干净、而是每次出现靠人工去检查和修复错误的数据。这些问题，程序员修复的时候似乎都是打地鼠，有一个洞那就堵上，洞什么原因出现的反而不去关心，更不要说根治，或许这跟公司的领导层背景有一定的关系，因为根治一个问题通常需要一次性花费比堵漏洞多10倍的精力，并且其副作用很可能是以后就清闲了，而在绝大部分公司清闲的程序员被认为是不努力的。

一个远程启动windows c++程序引发的技术决策现象