|
发表于 2017-11-27 18:29:59
|
显示全部楼层
山西省晋中市
#在这里快速回复# 本帖最后由 镇坛道德标杆 于 2017-11-14 01:21 编辑 经常想写一些支持库,虽然我也有“支持库洁癖”,但是是针对别人的库呀→_→ 但是一直都被告知支持库一定要用 VC6.0 写,否则 vc98 无法 link,也就无法静编成功。。。 开玩笑,对于我们这种普通玩家来说,VC6.0 怎么写代码?2017 年了还用它简直是噩梦操作啊。。。 最近琢磨了一下,成功用 VS2017 封装 zlib 制作出了可以用 vc98 link 成功静编的支持库,制作的时候如丝般顺滑。。。 这里分享一下整个工程,并且配图分析。 开箱即用篇 工程解压后就只有如图所示这些: .vs —— 一些配置文件,非常重要; JBzlib —— 工程源码、库、头文件等; JBzlib.sln —— 解决方案,安装好 vs2017 双击运行直接可以编译。 先不急着打开解决方案,先打开 JBzlib 文件夹: elib —— 实际上就是易的安装目录下的 sdk 文件夹中的 elib,也就是官方提供的支持库开发 SDK,其实可以直接 include 的,但是为了打包我直接复制到工程里,这个是我自己电脑上的,5.4.1版本的 SDK,新版的貌似增加和改变了一些东西,更换的时候注意; zlib-1.2.8 —— zlib 1.2.8 的头文件(其实包括源文件也打包了),同样正常情况下是直接 include 的,但是为了打包我直接复制到工程里; zlibstat.lib —— zlib 的静态链接库; *.h、*.cpp、*.def —— 这些就是支持库的源文件和头文件等了; 其它 —— vs 工程的文件; 好了现在打开刚才的 JBzlib.sln,注意在此之前一定要安装好 vs2017(安装的时候不要省空间,跟 c/c++ 有关的全打勾,包括单个组件也打勾,硬盘不值钱。): JBzlib.h 里的 guid 一定不要自己随便编,用 guidgen.exe 来生成(只要你安装了 vs2017,电脑上就一定有 guidgen.exe,搜索一下,或者易的安装目录下也有): JBzlib.cpp 中是主要部分,包括支持库的常量、数据类型、导出命令以及命令的参数都在这里,注意 __E_STATIC_LIB 这个宏(都有汉字说明,别瞎改一般不会错): JBzlib.def 这个导出文件一定要有,改个名字复制进去啥都不用管: 自带了 6 种配置: fne、fne_bak —— 后者是前者的备份,用来编译生成 *.fne 动态支持库,但是无法静编; static_lib、static_lib_bak —— 后者是前者的备份,用来编译生成和 *.fne 对应的 *_static.lib 静态库,从而可以静编 debug、release —— 创建项目自带的,不用管; 原理半解读篇 上面的部分顾名思义,给开箱即用的朋友用的,下面是解读原理,为什么说是半解读呢?因为也是个半吊子,很多都是玄学,凑合看下。 (注意:均以 vs2017 为例) 新建一个动态链接库项目: 然后按照打包的工程进行一些文件的复制粘贴改名啥的库的导入啥的,能看到这里的应该这点不成问题吧? 然后打开项目属性页,右上角配置管理器,新建 fne 和 static_lib 的 win32 平台的空配置: 然后按照打包的工程的 fne 和 static_lib 配置一项一项地对应着修改配置,不要问为什么,老夫也不知道为什么,它就这样就可以编译成功,不要问为什么,不要问。。。 注意 fne 和 static_lib 的有一个地方都要改一下,跟你的项目名对应,其它的不要动。。。不要动。。。 原理很简单,vs 提供了这种平台工具集,相当于一种降级,就可以让 vc98 成功 link 了。 但是,不要用你所希望使用的链接器无法链接的数据类型和函数,尽可能简单,当然如果你的易用的是 vs2015 甚至 vs2017 的链接器,就会好很多。 为什么要打这么多字配这么多图来分享,因为我希望抛砖引玉,能吸引到有能力的朋友来制作支持库,毕竟"用 VC6.0 做个支持库吧" 这种"厚颜无耻"的请求我都不好意思说出口,但是用 vs2017 的话就不一样了,至少是个先进的 IDE,对吧?希望大伙一起给易这潭死水增添一点活力,不要整天觉得别的语言鄙视自己,丰富类库,真正把快速开发、简单易用这些做到,还是可能有活路的。 (写到这里,想了想干脆建了个群用来交流,547525064,专注交流支持库制作,我自己是个 vc 苦手,希望来几个大佬日常指导~ 哦对了对了,忘了说分享的这个支持库具体的用处了: 网页_gzip解压(),都用过吧,这个就是那个用处。 很多人可能跟我一样,用易写请求的时候,为了不多带一个.dll,都不进行压缩也不接收压缩。 但是做爬虫或者请求频繁的时候这样效率很低,用了 gzip 就不一样了,毕竟网络传输和本地解压相比,是很费很费很费时间和资源的。 解压速度方面,调试模式支持库比调试模式的 zlibwapi.dll 调用慢不少,但是编译后速度还是一致的,很可观。 支持库公开的为数不多的命令全是指针操作(没研究怎么让命令可以是自定义数据,而且指针的比较灵活,因为我觉得 gzip 不可预估长度,是更适合流式解压的。 修改了一下 zy 的 zlib 模块的代码,写了个 网页_gzip解压(),测试不多,有 BUG 反馈或者自行修改。 这是一个非常非常干净的 XP,什么运行库都没有,也可以运行: 源码和工程下载: 易源码: 网页_gzip解压.zip (386.04 KB, 下载次数: 30, 售价: 2 枚 精币) 工程源码,sha1值 fc3de6fc46200d16ef393a72a52a4fb0f23eb561: |
|