好久没写点什么了，

这里发个课题，可以讨论一下，

我有个驱动程序，同时也有个应用层模块，

当然了，这个驱动SYS是一个保护模块，应用层模块DLL是个控制模块，

DLL控制SYS。

既然涉及到控制，同时就肯定涉及到通信，

既然涉及到通信，就涉及到通信安全的问题，

这里我们不讨论被别人干了的情况，只讨论我们自己的情况。

首先，模块化就是为了更新方便，

而既然是更新就包括SYS的更新和DLL的更新，

最好的情况下，当然就是同时更新，

但是有些比较差的情况是，DLL可以及时更新，但是SYS却不能及时更新，因为SYS不是任意时间都可以卸载的，

而且卸载时也要考虑当前是否可能有资源被占用的问题，

所以最好的情况就是，当电脑重新启动之前不卸载SYS，

那么，问题就来了，新的DLL，和旧的SYS同时存在，那么交互的时候怎么办，

如果新的DLL内存空间里面多了一个什么东西的话，那么SYS就可能解析出错，

结果就是轻者导致功能无效，重者直接BSOD，

这怎么办。

我和我老大讨论了一会，我老大给出一个结论是，给每个DLL和SYS通信的信息，增加一个版本号，

这样SYS做解析之前，先判断版本号，然后再解析。

这，你怎么看。

我说一下我的想法阿，其实我认为这完全是多余的，

首先，如果DLL升级加载成功，DLL再升级加载SYS，然后和SYS沟通，那么很必然DLL如果升级加载SYS失败了，DLL自己也会知道这个情况，

那么这时候有两种可能，

1：如果升级加载SYS成功了，那么DLL自然可以和自己加载的SYS正确沟通，正确交互，那么自然后续都没有问题，

2：如果升级加载SYS失败了，那么DLL肯定会知道自己对SYS的升级加载操作是失败的，这时，即便自己发给驱动的消息里面携带一个版本号，那么驱动识别版本号是自己不认识的，这时也无法正确执行消息，所以这条信息本身就是多余的。而，这时候，难道还指望新的DLL用老的版本号来发送一条消息么，这不是吃饱了撑的么，我们不是有老的DLL就在本地么，直接用老的DLL就行了阿。

实际上不管成功还是失败，我们都是可以有比较好的办法来解决这个问题。

实际上我老大想到这点，是因为，我老大是做云控的，云控发消息到本地的话，确实需要携带一个版本号（或者本地上发一个版本号告诉云控说我要哪个版本的消息），如果不这样的话，那么云控每一次升级，都会丢掉很多很多量。

一个关于消息结构体的讨论