1--陈年旧账
07年的年初，当时我正忙于公司的内部项目。对于之前一直应于项目“外战”的我来说，对于内部项目实际驾驭起来很游刃有余，得心应手。所以那个时候我开始对于自己之前做过的项目进行回顾和反思，让我首先面对的确是就是一个陈年旧账的项目。
我是2000年入公司的，入司后就是从事windows编程的工作。我从使用delphi的RAD工具进入windows程序设计的。当时公司的主打产品是呼叫中心，其实产品架构就是当时非常流行的三层模式。在我做了不到3个月的业务界面开发后，因工作需要我转入了中间业务层的开发，当时采用的就是MIDAS的架构。主要负责client端发送来的业务消息，中间件可连接各类异构数据库，进行处理然后返回客户端结果。我接手做该项目时，整个架构已经形成了一个产品，并且已经有遵循的开发规范，我只需要按部就班的按照约定实现业务代码即可。那个时候对于我来说，收获代码编写的技巧，增加开发经验就已经是不错的选择。所以对于这个中间件的架构和源码并未作深入的研究，到03年之前，该中间件的架构已经运用到了多个项目，那时候它所依附的服务器都是winodws NT并且运行稳定。
然而到了03年，在已经通用的windows2000 server的版本上出现让这个中间件软件出现了消息“丢包”的情况，并且十分的严重。查看消息日志，只见消息接收但未见消息处理的过程。该软件在windows98，NT上运行很正常。当查看源码，并未看出什么端倪。于是乎便判断是硬件网卡的原因，当时求助于硬件商的帮助，通过800电话寻求技术支持，客服通过邮件发了一个所谓的网卡辅助程序给我。这个程序就是点击自动运行，程序界面做了动画效果，类似于一个盒子打开、关闭的效果图。这个程序运行后，中间件服务软件就正常了。为此我还自以为是的找到了主要原因，但是在05年，该中间件被用到非呼叫中心的业务上，像水利厅的大型水库水文数据采集的项目中，丢包问题还是存在。那个时候我突然意识到，当年自己的解决方案是回避不是真正的解决。好在有那个辅助软件，确保项目的顺利实施。
事隔多年后，我重新把这段代码拿出来。虽然那个时候，我已经不做DELPHI的开发项目，但是我想找出问题的答案。于是乎，我把中间件架构源码通读了一遍，甚至我还把delphi的vcl源码也读了一遍。07读架构级的代码时已经能够凸显驾驭的本领，没有早些年那么吃力。每段代码给予我的思考，远远超过了我写代码的时间。也就那个时候，让我对于windows编程，还有delphi的框架有了一个重新的认识。回过头再一看，就从windows编程说起，从最基础的开始，而这个问题就出现在这个最为基础的细节上