我个人从2018年初开始，直到现在，一直在完善一个基于Windows平台的驱动库，
这个库的主要功能是，为R0层各种API提供了一个使用起来更简易的接口，类似于为R0层函数提供了一个适配层，供开发者使用。
整体结构如图吧，即，开发者在编写驱动的时候，通常是要使用微软 DDK、WDK 接口来开发驱动的，但是这些接口通常不是那么很好用的，
我整理出一套驱动接口，更简单，更好用，且集成了若干功能。大致就是这样。
经过两年半的开发，我的库已经异常庞大，虽然只是业余时间做的，但是它依旧花了我两年半的时间，它依旧庞大。
问题由此开始。
由于我的库是R0层的库，基于驱动实现的，目前我希望在R3做一套同样的库，
因为没事编译驱动，多费劲啊，如果我底层已经支持好，上层直接写个应用程序多容易啊，
所以我希望弄一套R3层的库，目前的想法是，接口与R0库接口完全一致，
底层实现R3如果能做，就由R3提供，R3如果做不了，那么让内置的R0模块来实现。
好了，需求也有了，
开始写代码吧，
写代码的时候，傻眼了。
主要怪我两年前没有做好整体的框架设计，目前想改很难。
如果两年前，我知道有今天的话，我绝对会把我的库结构重新设计一下。
目前我的库是整体的一块，但是如果我能想到有今天的话，我应该给我的库也设计成如下这样，
这样的话，最大的好处就是，我的库中，接口层可以完全不变，
适配器曾可以大部分不变，改变的是系统交互层。
而目前是R0的接口，如果我要把整套框架移植到R3上的话，就可以变成这样了
接口层可以完全不变，适配器层大部分不变，系统交互层改变。
这不就是跨平台支持的精髓么，
哎，由于两年前我没有考虑到这些，
导致现在接口和底层实现紧耦合，最终导致的结果就是，我现在只能对照R0的接口，再实现一套R3的接口。
未来维护起来也相当之烦。
否则就只能是推倒重来，或者将现在的R0接口作为平台适配层接口，再在上面包一层和R3一样的接口。
不管怎么想，都是个大工程，哎，失败了。