简介GMSSL2.0的Windows服务端工程基于VS2015与VC6.0双版本构建面向需要为Android客户端提供国密通信测试服务的开发人员。工程包含客户端与服务端完整代码支持SM2等算法可在Windows上编译生成服务端程序与Android端配合使用用于验证国密SSL握手与数据加解密流程。资源共43个文件以C源代码.cpp/.h、预编译动态库.dll和静态库.lib为核心sln/dsp工程文件可分别在VS2015与VC6.0中打开编译pfx与crt证书文件用于配置服务端身份认证txt与htm文档包含编译说明与升级记录整体压缩包仅2.36MB结构紧凑目录层次清晰。已有264人学习参考适合正在开发GMSSL应用或进行国密算法联调的工程师可直接基于示例代码修改证书与配置快速搭建Windows端服务环境工程同时保留旧版VC6工程入口便于在老旧开发环境中维护减少重复造轮子的时间。1. 老server接GMSSL2.0VS2015与VC6.0之间夹着一整层C99前阵子接了一个维护了十几年的业务服务端代码库里还躺着一整套VC6.0的 .dsp 工程文件需求是把GMSSL2.0国密库接进去用SM2做报文的签名验签。我一开始按惯性操作把GMSSL2.0源码往VC6.0工作区里拖想直接编进老server结果头文件先翻车stdint.h找不到、long long不认几十个源文件报错刷满了输出窗。换成VS2015重新走CMake生成工程后一次编过再用LoadLibrary把GMSSL2.0的DLL接到老进程里问题迎刃而解。这篇把这里的判断依据和踩坑记录摊开讲适合手里有老Windows服务端、想低成本升级SM2能力的人。VC6.0不是一台慢车它是和GMSSL2.0完全不同的两个时代的产物硬接不是补丁的事是架构的事。2. 为什么VC6.0当不了宿主工程载体、语言标准、构建工具链三层同时卡住先说结论VC6.0并不是“慢一点的老工具”而是编译器语言标准停留在一个完全不同的年代。GMSSL2.0这套源码按C99起步写大量依赖现代标准库和编译语法VC6.0的C编译器连long long都不是原生产物。硬要在同一个进程里编译它不是打补丁能解决的我前后试过两次每次都是浪费一整天。2.1 工程载体就不在同一个轨道.dsp文件装不下CMake产物我手头的server工程文件是 .dsw .dsp 的组合GMSSL2.0源码包则是CMakeLists.txt。CMake的Visual Studio 6生成器多年前就被移除了你没法“cmake一下”就得到VC6.0能用的.dsp。要在VC6.0里编译GMSSL2.0唯一路径是像90年代那样手工新建一个.dsp然后把库的几十个C文件一个个拖进去再逐个配置include目录、宏定义、运行库选项。这个手工工程量在一个封装层上会被放大很多倍因为GMSSL2.0不是单文件小工具光算法和内部buffer管理就有大量编译单元任何一个文件漏配出来的库行为都可能不对。VS2015这边就是另一回事用cmake -G Visual Studio 14 2015就能自动生成.sln/.vcxproj编译依赖、预处理宏、代码生成选项都由CMake配置好不需要手工记账。同一套源码在两个环境下对应的工程维护成本完全不是一个量级。我把两份工程摆在一起做了一个直观对比对比项VC6.0VS2015工程载体.dsw / .dsp.sln / .vcxprojCMake生成Visual Studio 6生成器已移除原生支持Visual Studio 14 2015头文件标准无stdint.h自带完整现代标准头整数类型只能用__int64手写long long原生支持源码修改量需要打大量兼容补丁基本不用改适合场景老业务逻辑维护承载新算法库这张表基本决定了后续所有动作老server的.dsp我尽量不去动GMSSL2.0则必须在VS2015下单独编成DLL。DLL边界可以缓冲掉两种编译器之间几乎所有不兼容。2.2 C99是GMSSL2.0的地板也是VC6.0的天花板继续说语法断层。GMSSL2.0的源码我翻过一圈发现它对编译器的最低要求就是C99以上。这类代码在VC6.0上会撞上四个典型雷区第一雷是头文件。源码里#include stdint.hVC6.0没有这个头文件要开发者自己拿一个pstdint.h补上而且GMSSL2.0内部还用了intptr_t、uint64_t、INT64_C之类宏补丁头未必全部补得齐。就算补出来类型宽度和平台对齐也可能和VS2015环境不一样属于隐患。第二雷是类型关键字。long long在VC6.0里不是合法类型只能写成__int64而代码里所有64位运算变量都用long long声明。手动把所有long long替换成__int64等于把几万行代码改了一版“方言版”后续上游维护完全没法对齐。这种改动是给团队买后悔药我第一个版本试到这步就收手了。第三雷是函数定义和声明语法。C99允许在for循环里直接声明变量允许在表达式里做变量声明VC6.0的C编译器对这些支持的边界很模糊编译会挑出一批C2059、C2065这类语法错。还有inline关键字C99把它当标准VC6.0默认不认如果编译器开关开不对inline直接变未知标识符。第四雷是标准库函数命名。snprintf在VC6.0里叫_snprintf而且空字符结尾行为跟标准不完全一致GMSSL2.0代码里只要有snprintf精度控制移植过后打印长度就可能差一个字符这种差异最难调表面看不出来运行时才炸。最后一类不叫语法叫“工程预期”。GMSSL2.0在CMake里会按平台选编译器特性比如对齐处理、字节序判断这些在VC6.0上得不到预期值编译能过也未必跑对。所以准确说VC6.0与GMSSL2.0的差距不是一个两个错而是三条同时断工程载体断、语法断、平台宏断。2.3 被拉回去前先查三处源码判断该不该花力气遇到这类“老环境接新库”的需求我一般会先做一个三分钟体检再决定动不动手。体检不是盲翻代码而是盯住三个点grep -R #include stdint.h . --include*.c --include*.h | head -20 grep -R long long . --include*.c | head -20第一处搜stdint.h。命中越多说明库对现代头文件的依赖越重VC6.0不可能原生满足。第二处搜long long。只要大面积出现VC6.0的编译器基本就没戏。第三处看CMakeLists.txt里有没有类似CMAKE_C_STANDARD 99的设置。如果设置了等于源码作者明确声明了编译器的语言标准底线。这三处看完心里就有数了。命中两处以上我会直接放弃“把源码拉进VC6.0工程”这条路线转向“VS2015编DLL 老进程LoadLibrary”的架构。另外还要看一眼server进程位数老服务端程序绝大多数是32位后续CMake生成工程时必须指定Win32这个位数问题最容易在最后一步翻车。3. 把GMSSL2.0变成VS2015的独立DLL一次编过并接到老server确认VC6.0当不了宿主之后剩下的事情就顺了在VS2015环境下把GMSSL2.0编成一个独立DLL对外只暴露两三个C函数老server通过LoadLibrary调用。整条链路的核心思想是“改动最小化”老工程的.dsp不重构老代码不硬改把冲突物理隔离在DLL边界之外。3.1 先让CMake生成一份干净的VS2015工程构建机需要装好VS2015含C编译器和Windows SDK和CMake。进到GMSSL2.0源码根目录执行cmake -S . -B build-vs2015 -G Visual Studio 14 2015 -A Win32 -DCMAKE_INSTALL_PREFIXD:/deps/gmssl2 cmake --build build-vs2015 --config Release --target install-A Win32指定生成32位动态库因为我的server是32位进程如果server已经是x64把Win32改成x64两边必须严丝合缝。--target install会把头文件、import lib、DLL一并整理到D:/deps/gmssl2目录后面就把这个目录当SDK用。编译完成后检查include、lib、bin三个目录。bin里应该有动态库文件lib里是导入库。CMake默认到底编静态库还是动态库要看CMakeLists里的BUILD_SHARED_LIBS开关我这次明确关掉静态库只留DLL减少老进程里出现重复符号的风险。注意VS2015对应的CMake生成器名称是Visual Studio 14 2015不是“vs2015”写错的话CMake会直接拒绝执行。CMake构建时的运行库选项直接影响DLL能不能被老进程加载。默认Release用/MD没问题如果构建机器装了其它依赖干扰可以在CMake里强制指定set(CMAKE_C_FLAGS_RELEASE /MD /O2 CACHE STRING FORCE) set(CMAKE_C_FLAGS_DEBUG /MDd /Od CACHE STRING FORCE)之所以强调这个是因为后面server调用侧如果走了静态链接CRT设置不一致会冒出一堆LNK2038而走LoadLibrary路线时DLL自己把CRT依赖管好即可老进程侧不用感知。3.2 在DLL里包一层干净的C接口别把openssl头文件暴露给老工程GMSSL2.0内部是OpenSSL兼容接口但如果直接在server代码里include openssl头文件老工程会撞上宏、类型命名的旧冲突我第一版就这么翻过车。正确做法是在GMSSL2.0周边再包一个薄薄的“服务DLL”对外只暴露几个标准C函数/* gmssl_svc.c —— 导出接口 */ #ifdef __cplusplus extern C { #endif __declspec(dllexport) int __cdecl sm2_svc_init(void); __declspec(dllexport) int __cdecl sm2_svc_sign(const char *pem_path, const unsigned char *msg, size_t msg_len, unsigned char *sig, size_t *sig_len); #ifdef __cplusplus } #endif加上extern C是防止工程以后被改写成C时导出名被mangle__cdecl与VC6.0侧函数指针声明保持一致。这个DLL是独立的VS2015工程链接GMSSL2.0的import lib但不把openssl的头文件目录暴露给调用方。老server永远只看到HMODULE和那两三个函数指针不需要知道GMSSL2.0内部长什么样。提示导出函数加__cdeclserver侧函数指针声明也必须用__cdecl调用约定不一致会导致栈错乱运行起来非常难排查。实际签名实现#include openssl/evp.h #include openssl/sm2.h #include openssl/pem.h #include openssl/rand.h int __cdecl sm2_svc_sign(const char *pem_path, const unsigned char *msg, size_t msg_len, unsigned char *sig, size_t *sig_len) { EVP_PKEY *pkey NULL; EVP_MD_CTX *mctx NULL; FILE *fp NULL; int ok 0; if (pem_path NULL || msg NULL || sig NULL || sig_len NULL) return 0; fp fopen(pem_path, rb); if (fp NULL) return 0; pkey PEM_read_PrivateKey(fp, NULL, NULL, NULL); fclose(fp); if (pkey NULL) return 0; mctx EVP_MD_CTX_new(); if (mctx NULL) { EVP_PKEY_free(pkey); return 0; } /* SM2签名必须显式绑定SM3摘要 */ if (RAND_poll() ! 1) goto fail; if (EVP_DigestSignInit(mctx, NULL, EVP_sm3(), NULL, pkey) 0) goto fail; if (EVP_DigestSign(mctx, sig, sig_len, msg, msg_len) 0) goto fail; ok 1; fail: EVP_MD_CTX_free(mctx); EVP_PKEY_free(pkey); return ok; }这里有几件事要说清楚SM2签名走SM3摘要EVP_DigestSignInit里必须显式传EVP_sm3()不传的话内部默认摘要可能对不上。RAND_poll放在每次签名里不算最优更好的做法是让sm2_svc_init在server启动阶段调一次预热伪随机数发生器。私钥每次签名都从PEM读虽然慢一点但避免了并发下共享EVP_PKEY带来的黑匣子问题线上先求稳性能后面用缓存优化。3.3 老server侧用LoadLibrary接DLLVC6.0工程改动最小server侧是VC6.0的老工程工程文件我不去动它的dsp结构只新增一个sm2_client.c用LoadLibrary加载这个DLL#include windows.h typedef int (__cdecl *sm2_sign_fn)(const char *pem_path, const unsigned char *msg, size_t msg_len, unsigned char *sig, size_t *sig_len); int call_sm2_sign(const char *pem_path, const unsigned char *msg, size_t msg_len, unsigned char *sig, size_t *sig_len) { static HMODULE h NULL; static sm2_sign_fn fn NULL; if (h NULL) { h LoadLibraryA(gmssl_svc.dll); if (h NULL) return -1; fn (sm2_sign_fn)GetProcAddress(h, sm2_svc_sign); if (fn NULL) return -2; } return fn(pem_path, msg, msg_len, sig, sig_len); }这段在VC6.0下能直接编译因为只用了LoadLibrary和GetProcAddress两个老掉牙的API。函数指针强制转换是MSVC传统写法介意的话可以走union转换老工程里保持一致风格即可。这样GMSSL2.0编译特性、头文件依赖、线程模型全被DLL边界隔离掉老server唯一的变化是新增一个.c文件和一个LoadLibrary调用回滚也方便。高并发下再优化一步把静态的HMODULE和函数指针改成进程启动时初始化一次之后所有线程共享函数指针验签线程只读函数指针不碰GMSSL2.0内部上下文DLL内部再对自己的密钥缓存加锁整体就稳了。4. 编译与对接避坑五条能用上的排查记录这套流程我前后折腾了一周多回头看最花时间的不是配置而是几个“过了编译却跑不起来”的坑。每条都在真实环境里踩过按“现象→原因→解决”记下来排错顺序我建议固定成位数、CRT依赖、宏冲突、RNG。4.1 第一坑VC6.0硬编GMSSL2.0源码报错刷满输出窗现象把GMSSL2.0源码拖进VC6.0的工作区之后一编译就是几百条错误集中在stdint.h找不到、long long不合法、snprintf未声明这几类。原因GMSSL2.0按C99标准写VC6.0的C编译器停留在C89时代而且缺少现代标准库头文件。这不是配置改一改能绕过的是语言层和库层同时不兼容。解决不要在VC6.0里继续编译。哪怕网上有pstdint.h补丁也只能消掉头文件部分错误语法层和编译器特性层的坑依然在。错误聚类超过三类以上时基本可以判定这条路走不通。4.2 第二坑DLL在部署机上加载失败GetLastError126现象开发机运行正常拷贝到业务服务器后LoadLibraryA返回NULLGetLastError是126表示找不到指定的模块。原因GMSSL2.0的DLL是用VS2015编的依赖新版C运行库部署机上没装对应的运行库或者DLL没有放在server.exe同目录导致依赖搜索不到。解决把gmssl_svc.dll以及它依赖的GMSSL2.0 DLL、CRT DLL全部放到server.exe同目录。最省事的手段是在DLL工程里把运行库设置成/MT把C运行时直接烤进DLL部署机就不用再操心运行库代价是DLL体积变大但对老系统部署是值得的。4.3 第三坑VS2015工程内部链接时报LNK2038运行库不匹配现象把GMSSL2.0静态库直接链进某个VS2015中间件工程链接器报LNK2038检测到_ITERATOR_DEBUG_LEVEL或RuntimeLibrary不匹配。原因GMSSL2.0用Release/MD编调用工程用Debug/MTd或两个工程的运行库选项对不上。这个坑主要出现在VS2015工程内部对接时VC6.0老工程反而碰不到因为它根本不走静态链接。解决把GMSSL2.0和调用它的VS2015工程放进同一个编译配置体系里Debug对Debug、Release对Release/MT与/MD全对齐。如果调用方是VC6.0老进程就不要走静态库链直接用DLL方案既绕开LNK2038也绕开老编译器不认识新obj的问题。4.4 第四坑LoadLibrary成功但GetProcAddress返回NULL现象LoadLibraryA返回非空GetProcAddress却拿不到sm2_svc_sign地址函数指针为NULL。原因位数不匹配。server是32位进程DLL是x64或者反过来。x64的DLL在32位进程里LoadLibrary多数会直接失败但有些场景下错误被吞掉拖到GetProcAddress才暴露。解决确认CMake的-A参数跟server位数一致。老server多半是Win32CMake用-A Win32重新生成一次别图省事把x64的lib拷到32位机器上冒充。在部署机上可以用dumpbin /headers看一下DLL的机器头判断位数。4.5 第五坑压测时SM2签名偶发失败返回0或半截签名现象单个线程调用签名一切正常一旦模拟交易并发压测到一百多的并发量就出现偶发失败返回0或者签名长度不对重启后又恢复。原因多线程并发调用SM2时私钥上下文被多个线程同时访问另外Windows下伪随机数发生器如果没在进程早期初始化并发下会出现随机数状态错乱。表现是间歇性出现是最典型的“玄学bug”。解决在DLL里导出一个init接口server启动时调一次RAND_poll()密钥PEM只在DLL内部加载放进一个由CRITICAL_SECTION保护的单例缓存给签名线程加锁访问。把锁粒度放在EVP_DigestSign调用外层两个线程不会同时操作同一个EVP_PKEY。调整后并发两百多线程压测签名成功率回到100%。这几条坑单独看都简单但它们串起来就是“编译过了不等于能跑能跑了不等于能并发”的完整链路我后来排问题都是按这个顺序走很少再走回头路。5. 最终收口VS2015编DLLVC6.0只留调用层另备三条退路最终落地方案一句话GMSSL2.0永远不在VC6.0编译器里编译它在VS2015下编成一个独立DLLVC6.0老server通过LoadLibrary只做调用所有国密实现都藏在DLL边界后面老工程改动最小回滚最安全。如果你们环境确实特殊必须在VC6.0进程里完成SM2还有三条退路按推荐顺序排方案前提风险老版本GmSSL v1手工建dsp能找到适配老编译器的老源码功能落后新协议不兼容维护成本高VS2015编DLL LoadLibrary调用构建机装VS2015部署机补CRT低推荐独立GMSSL2.0签名服务有旁边的部署环境可放新进程多了网络故障点但完全解耦最后给一个能直接抄的技巧在DLL里把SM2私钥做成“单例EVP_PKEY CRITICAL_SECTION锁”的缓存不要每次签名都从PEM读太高频时会成为瓶颈但锁粒度必须放在EVP_DigestSign调用外层防止两个线程同时操作同一个EVP_PKEY。我第一版图省事没加锁压测到一百八十并发时连续翻车加锁后同样场景一秒没卡过。另外RAND_poll的调用固定在init接口里做不要在DllMain里做在DllMain里初始化OpenSSL的RNG是我踩过的坑轻则加载缓慢重则直接起不来进程。从那以后我每次接手老工程前都会先做一遍“编译器标准、构建系统、运行库、位数”四个开关的体检再决定是直接链接还是写胶水DLL。这套体检准则从那次之后几乎没再让底层库接入翻过车希望帮到你。本文还有配套的精品资源点击获取