EDB结构的研究，以及火山C++等其他语言如何调用和现代化

目前火山或其他语言是无法用EDB的，当然也没有用EDB的必要，小型数据库ADO，远程服务mysql。但是很多水友是 从易语言到火山的，对于EDB很熟悉，对sql语句根本不会，正好疫情时无聊，复习了下编译原理，用易写词法分析器，到做e2cpp玩，再加上精易的支持库改造计划，反正做都做了就稍微完善了下核心库，本来也想做个支持库的，奈何VC6对我来说就是地狱级折磨，就想着没事的时候封封库，以后想完善e2cpp也方便。
其中EDB是闭源不好复现，之前写过动态调用易语言支持库实现其他语言调用EDB，但是支持库只有32位。所以稍微研究了下结构，从逆向代码看，EDB应该不是B+树结构，所以不是特别快也能理解，既然做了就想着在向下兼容的前提下再优化一下edb，吴总使用的古代API和调用MFC都是浪费性能并且导致移植x64困难，像openfile、COleDateTime::GetTickCount()，这些就给换了，因为代码是从C++翻译的，有些结构体和指针的处理累的脑袋疼，直接扣汇编代码可能会很方便，速度可能会更快，但是水友可能就有点看不懂了，优化完以后可以大于两G。
读写也改为内存文件映射+临界区。速度快很多，大文件处理也简单，也不占内存，多线程操作也不蹦。本来是想让EDB现代话一点，可以通过sql语句操作，可以设置编码，实现起来比较简单，固定储存长度unicode可访问的长度是ansi的两倍，换gbk啥的就只能访问一半，或者直接添加宽字符类型。可是这样核心库的edb就打不开优化后的了，所以先没做调整，保证兼容，换cpp的话有重载和模板，通用型和可变参比较好实现，易的话只能是支持库，没指针，结构体也难用。
速度测试了一下，比核心库快25%。带字节集型的差距会更大,在40%左右,C++没有想象中差距那么大，可能是我写库的时候又在外面嵌套了一层中文再call过去的原因，但也是维度碾压。
结构就是这么个结构，加空记录就是记录数位置+1记录数，再在文件后面+所有字段需求数据长度的长度。
写就是在指定记录偏移的指定字段偏移位置写数据类型长度的数据。注释还是比较全的，有兴趣水友自己封装吧。