简介：这份资源面向具备C++基础、希望在通达信公式中实现一机一码授权验证的开发者，围绕通达信DLL插件开发展开。包内共13个文件，以6个cpp源文件与4个h头文件为核心，另含Visual Studio项目文件、工程过滤器及一份通达信DLL函数编程规范文档，压缩包约88KB。源码覆盖插件功能测试、自定义函数注册、计算功能实现、磁盘信息获取以及MD5加密等模块，可帮助读者理解如何将唯一标识码生成逻辑嵌入通达信公式并完成调用。目前已有2427人学习下载。通过这份资料，读者可掌握DLL项目的创建与配置思路，理清函数注册与公式集成的关键环节，并借鉴MD5与磁盘信息结合生成机器码的实现方式，为激活验证、许可证管理等场景提供可参考的代码骨架与排错方向。
1. 通达信 DLL 编程：把公式里的“黑匣子”变成一机一码的授权入口
如果你写过通达信公式，大概率遇到过这种尴尬：辛辛苦苦调出来的指标逻辑，一旦以公式源码形式发给别人，就等于把底牌全亮了。公式加密？那玩意儿在懂行的人手里跟纸糊的没区别。真正让策略开发者睡得着觉的做法，是把核心计算逻辑从公式语言里抽出来，塞进一个编译好的 DLL，公式端只留一个函数调用入口。通达信 DLL 编程解决的正是这个问题——它允许你用 C/C++ 写一个动态链接库，导出特定签名的函数，然后在通达信公式里像调用普通函数一样调用它。更进一步，你可以在 DLL 里嵌入机器码校验逻辑，实现“一机一码”：同一份 DLL，换台机器就跑不出正确结果。这篇文章面向的是手里有策略、想做成可分发产品的通达信用户，以及想搞明白 DLL 调用机制、避免踩坑的公式开发者。
2. 通达信 DLL 调用机制：从公式引擎到动态库的完整链路
2.1 通达信公式引擎如何加载和调用 DLL
通达信公式系统本身是一个解释器，它支持一类特殊的函数调用语法，格式大致是"DLLNAME@FUNCTIONNAME"(参数1, 参数2, ...)。当公式引擎解析到这种形式的调用时，它会去通达信安装目录下的T0002\dlls文件夹里查找对应的 DLL 文件，然后通过 Windows 的LoadLibrary和GetProcAddress拿到导出函数的地址，最后按照约定的调用约定把参数压栈、执行、取返回值。
这里有几个关键点决定了你能不能跑通。第一，DLL 必须放在正确的目录下，通达信不同版本对路径的敏感度不一样，常见做法是放在T0002\dlls下，但有些版本会去T0002根目录找，这个后面避坑章节会细说。第二，导出函数的名称必须和公式里写的一模一样，大小写敏感。第三，调用约定必须是__stdcall，这是通达信公式引擎的硬性要求，用__cdecl编译出来的 DLL 加载时会直接失败，而且失败提示往往很模糊，只告诉你“DLL 加载失败”，不会告诉你具体原因。
从数据流的角度看，公式引擎传给 DLL 的参数是一组浮点数数组，DLL 计算完再把结果写回一个输出数组。通达信对参数个数和类型有固定约定，不是随便写个int add(int a, int b)就能用的。你需要按照它规定的函数签名来导出，通常是类似void __stdcall FuncName(float* pfIn, float* pfOut, int nInLen, int nOutLen)这样的形式。具体签名取决于你用的通达信版本和 DLL 编程接口规范，但核心思想是一致的：输入输出都是浮点数组，长度由引擎控制。
2.2 一机一码的底层逻辑：机器指纹采集与校验
一机一码的核心思路不复杂：在 DLL 初始化或者每次被调用时，采集当前机器的唯一标识，然后跟预先绑定的授权码做比对，比对不通过就返回错误结果或者直接让输出全为零。难点在于“机器唯一标识”的选取和“校验时机”的设计。
机器指纹的常见来源包括：硬盘物理序列号、主板序列号、CPU 序列号、网卡 MAC 地址、Windows 安装 ID 等。但通达信 DLL 运行在用户态，不是所有硬件信息都能直接读取。我一般会组合使用几个相对稳定且容易获取的标识：用GetVolumeInformation拿系统盘的卷序列号，用GetAdaptersInfo拿第一块网卡的 MAC 地址，再拼上GetComputerName拿到的计算机名，做一个哈希。这样即使某一项变了，整体指纹大概率还能保持稳定。注意，不要用GetSystemMetrics或者屏幕分辨率这种会变的量，否则用户换个显示器你的授权就废了。
校验时机有两种选择。一种是在DllMain的DLL_PROCESS_ATTACH里做，优点是只执行一次，效率高；缺点是如果校验失败，你很难优雅地通知公式引擎，因为DllMain里能做的事情有限，弹窗或者写日志都可能引发加载器锁死。另一种是在导出函数内部做，每次调用都校验一遍，效率略低但可控性强，校验失败可以直接把输出数组填零或者填一个特定值，公式端看到的就是“指标失效”。我倾向于第二种，虽然多几次系统调用，但稳定性好得多。
2.3 最小可运行 DLL 的编译与部署
下面是一个最小化的通达信 DLL 示例，功能很简单：把输入数组的每个元素乘以 2 后输出。虽然简单，但它包含了通达信 DLL 的所有必要元素：正确的导出签名、__stdcall调用约定、extern "C"防止名称修饰。
// tdx_demo.cpp // 编译命令（MinGW）：g++ -shared -o tdx_demo.dll tdx_demo.cpp -Wl,--out-implib,libtdx_demo.a // 编译命令（MSVC）：cl /LD tdx_demo.cpp /Fe:tdx_demo.dll #include <windows.h> #include <cstring> // 导出函数必须用 extern "C" 避免 C++ 名称修饰 // 调用约定必须是 __stdcall extern "C" __declspec(dllexport) void __stdcall TDX_DEMO(float* pfIn, float* pfOut, int nInLen, int nOutLen) { // 参数说明： // pfIn - 输入浮点数组指针，由通达信公式引擎传入 // pfOut - 输出浮点数组指针，DLL 计算结果写回这里 // nInLen - 输入数组长度 // nOutLen- 输出数组长度 // 简单逻辑：每个输入值乘以 2 for (int i = 0; i < nInLen && i < nOutLen; i++) { pfOut[i] = pfIn[i] * 2.0f; } } // DLL 入口点，通达信加载时会调用 BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: // 可以在这里做初始化，但不建议做耗时操作 break; case DLL_PROCESS_DETACH: break; } return TRUE; }编译出tdx_demo.dll后，把它放到通达信的T0002\dlls目录下。然后在通达信公式编辑器里写这样一行测试公式：
TDX_DEMO: "tdx_demo@TDX_DEMO"(CLOSE, CLOSE);这里CLOSE是输入，第二个CLOSE是输出占位。实际使用时，通达信会把CLOSE序列传给pfIn，然后从pfOut取结果画线。如果一切正常，你应该看到一条和收盘价走势相同但数值翻倍的曲线。如果没出来，先检查 DLL 是否放对位置，再用dumpbin /exports tdx_demo.dll确认导出函数名是否正确。
3. 一机一码实战：机器指纹采集、授权码生成与校验嵌入
3.1 机器指纹的采集代码与稳定性取舍
采集机器指纹的代码不复杂，但选哪些项、怎么组合，直接决定了授权系统的可用性。下面这段代码采集了卷序列号、MAC 地址和计算机名，然后拼成一个字符串做哈希。
// machine_id.cpp #include <windows.h> #include <iphlpapi.h> #include <cstdio> #include <cstring> #pragma comment(lib, "iphlpapi.lib") // 获取系统盘卷序列号 DWORD GetVolumeSerial() { DWORD serial = 0; GetVolumeInformationA("C:\\", NULL, 0, &serial, NULL, NULL, NULL, 0); return serial; } // 获取第一块网卡的 MAC 地址（取前 6 字节） void GetMacAddress(unsigned char* mac) { ULONG bufLen = 0; GetAdaptersInfo(NULL, &bufLen); PIP_ADAPTER_INFO pAdapterInfo = (PIP_ADAPTER_INFO)malloc(bufLen); if (GetAdaptersInfo(pAdapterInfo, &bufLen) == ERROR_SUCCESS) { memcpy(mac, pAdapterInfo->Address, 6); } free(pAdapterInfo); } // 生成机器指纹字符串 void GetMachineId(char* outBuf, int bufSize) { DWORD volSerial = GetVolumeSerial(); unsigned char mac[6] = { 0 }; GetMacAddress(mac); char computerName[256] = { 0 }; DWORD nameSize = sizeof(computerName); GetComputerNameA(computerName, &nameSize); // 拼接：卷序列号- MAC地址-计算机名 sprintf_s(outBuf, bufSize, "%08X-%02X%02X%02X%02X%02X%02X-%s", volSerial, mac[0], mac[1], mac[2], mac[3], mac[4], mac[5], computerName); }这段代码里，卷序列号在重装系统后会变，MAC 地址在换网卡后会变，计算机名用户可以随便改。所以单独任何一项都不够稳定。我的做法是：把这三项拼起来做一个简单哈希（比如 FNV-1a），得到一个固定长度的指纹值。然后授权码就是对这个指纹值做一次可逆加密或者签名。用户换机器时，指纹变了，授权码对不上，DLL 就拒绝工作。
注意：不要用
GetSystemMetrics或者屏幕分辨率这种会变的量，否则用户换个显示器你的授权就废了。
3.2 授权码的生成与嵌入：离线绑定与在线验证的取舍
授权码的生成有两种模式：离线绑定和在线验证。离线绑定是用户把机器指纹发给你，你算出一个授权码发回去，用户把授权码写进一个配置文件或者注册表，DLL 读取后比对。在线验证是 DLL 每次启动时向你的服务器发请求，服务器返回是否授权。前者实现简单，不依赖网络，但授权码一旦泄露就等于失效；后者安全性更高，但需要维护服务器，而且用户断网时体验差。
对于通达信 DLL 这个场景，我一般推荐离线绑定加定期在线校验的混合模式。具体做法是：DLL 首次运行时采集指纹，生成一个本地授权文件（比如加密后的注册表项），同时把指纹和授权状态发到服务器备案。之后每次启动，DLL 先检查本地授权文件是否存在且有效，如果有效就直接放行，同时异步向服务器发一个心跳。如果本地文件被删除或者指纹不匹配，再走在线验证流程。这样既保证了离线可用，又能在服务器端做黑名单管理。
授权码本身可以用一个简单的对称加密算法生成，比如对指纹字符串做一个 XOR 再加一个固定密钥，然后 Base64 编码。虽然安全性不高，但对付普通用户足够了。真要防破解，得上非对称加密和代码混淆，那是另一个层面的工程。
3.3 在 DLL 中嵌入校验逻辑：时机、失败处理与反调试
把校验逻辑嵌入 DLL 时，有几个细节决定了用户体验和安全性。首先是校验时机，前面说过，我倾向于在导出函数内部做，而不是DllMain。但每次调用都做完整校验太慢，可以做一个静态标志位，第一次调用时校验，之后直接读标志位。
// 在导出函数内部做校验的示例 static bool g_bAuthorized = false; static bool g_bChecked = false; extern "C" __declspec(dllexport) void __stdcall TDX_STRATEGY(float* pfIn, float* pfOut, int nInLen, int nOutLen) { if (!g_bChecked) { char machineId[512] = { 0 }; GetMachineId(machineId, sizeof(machineId)); char expectedCode[512] = { 0 }; // 从注册表或配置文件读取授权码 ReadLicenseFromRegistry(expectedCode, sizeof(expectedCode)); // 比对 g_bAuthorized = VerifyLicense(machineId, expectedCode); g_bChecked = true; } if (!g_bAuthorized) { // 未授权：输出全零，公式端表现为指标失效 for (int i = 0; i < nOutLen; i++) { pfOut[i] = 0.0f; } return; } // 正常计算逻辑 for (int i = 0; i < nInLen && i < nOutLen; i++) { pfOut[i] = pfIn[i] * 2.0f; } }失败处理上，输出全零是最温和的方式，用户看到的是指标不显示，但不会导致通达信崩溃。比输出全零更激进的是直接ExitProcess，但这会让通达信整个挂掉，用户体验极差，不建议。反调试方面，可以在校验前加一个IsDebuggerPresent检查，如果发现被调试就直接返回错误结果。但这只能防住新手，真懂逆向的人有一百种方法绕过。
4. 避坑与排查：DLL 加载失败、公式报错、授权误判的常见原因
4.1 DLL 加载失败：路径、位数与依赖项
现象：公式里写了 DLL 调用，但通达信提示“DLL 加载失败”或者干脆没反应。
原因通常有三个。第一，DLL 放错了目录。通达信不同版本对 DLL 搜索路径的处理不一样，有的版本只认T0002\dlls，有的版本会去T0002根目录找，还有的版本会去系统PATH里找。最稳妥的做法是把 DLL 同时放到T0002\dlls和通达信主程序目录下。第二，位数不匹配。32 位通达信只能加载 32 位 DLL，64 位通达信只能加载 64 位 DLL。用 MinGW 编译时默认是 64 位，需要加-m32参数。第三，DLL 依赖了其他运行库，比如 MSVCR120.dll，而用户机器上没装。解决办法是静态链接运行库，MinGW 加-static-libgcc -static-libstdc++，MSVC 用/MT而不是/MD。
4.2 公式报错：参数个数、类型与返回值约定
现象：DLL 加载成功了，但公式计算时报错，或者结果明显不对。
原因可能是参数个数不匹配。通达信公式里调用 DLL 时，输入参数和输出参数的个数必须和 DLL 导出函数的签名一致。比如你的函数签名是(float* pfIn, float* pfOut, int nInLen, int nOutLen)，公式里就要提供对应数量的输入和输出占位。常见错误是公式里只写了一个参数，但 DLL 期望两个。另外，通达信传给 DLL 的浮点数组长度是固定的，通常是 0 到 某个最大值，你的代码里必须用nInLen和nOutLen来控制循环边界，不能硬编码数组长度，否则会越界访问导致崩溃。
4.3 授权误判：指纹漂移与注册表读写权限
现象：用户明明没有换机器，但 DLL 突然提示未授权，指标不显示了。
原因可能是机器指纹发生了漂移。比如用户插了一个 USB 网卡，导致GetAdaptersInfo返回的第一块网卡变了；或者用户改了计算机名；或者系统盘卷序列号因为某些磁盘操作变了。解决办法是在指纹采集时多采集几项，然后做模糊匹配——比如三项里有两项匹配就算通过。另一个常见原因是注册表读写权限。如果你的授权码存在HKEY_LOCAL_MACHINE下，普通用户没有写权限，DLL 读取时可能失败。建议存在HKEY_CURRENT_USER下，或者直接用一个加密文件放在用户目录。
4.4 性能问题：频繁校验与内存泄漏
现象：用了 DLL 之后，通达信变得很卡，或者运行一段时间后崩溃。
原因可能是每次调用导出函数都做了完整的指纹采集和校验。指纹采集涉及系统调用，频繁执行会拖慢公式计算。解决办法是用静态标志位，只在第一次调用时校验。另一个原因是内存泄漏。比如在GetMacAddress里malloc了pAdapterInfo但没有free，每次调用都泄漏一点，时间长了就崩。检查所有malloc/new是否都有对应的free/delete，尤其是在提前return的分支里。
5. 进阶技巧：用注册表做授权状态缓存与版本兼容处理
授权状态缓存是提升用户体验的关键。每次启动都重新校验指纹，不仅慢，而且一旦指纹采集出问题就会误判。我的做法是在第一次校验通过后，把机器指纹的哈希值和授权码的哈希值一起写进注册表HKEY_CURRENT_USER\Software\YourProduct下，同时记录一个时间戳。之后每次启动，先读注册表，如果指纹哈希匹配且时间戳在有效期内（比如 7 天），就直接放行，不再重新采集指纹。只有注册表被清空或者指纹不匹配时，才走完整校验流程。
// 注册表缓存授权状态的示例 bool ReadCacheFromRegistry(char* cachedHash, int bufSize, DWORD* lastCheckTime) { HKEY hKey; if (RegOpenKeyExA(HKEY_CURRENT_USER, "Software\\YourProduct", 0, KEY_READ, &hKey) != ERROR_SUCCESS) return false; DWORD type = 0; DWORD size = bufSize; RegQueryValueExA(hKey, "MachineHash", NULL, &type, (LPBYTE)cachedHash, &size); size = sizeof(DWORD); RegQueryValueExA(hKey, "LastCheck", NULL, &type, (LPBYTE)lastCheckTime, &size); RegCloseKey(hKey); return true; } void WriteCacheToRegistry(const char* machineHash) { HKEY hKey; RegCreateKeyExA(HKEY_CURRENT_USER, "Software\\YourProduct", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_WRITE, NULL, &hKey, NULL); DWORD now = GetTickCount(); RegSetValueExA(hKey, "MachineHash", 0, REG_SZ, (const BYTE*)machineHash, strlen(machineHash) + 1); RegSetValueExA(hKey, "LastCheck", 0, REG_DWORD, (const BYTE*)&now, sizeof(now)); RegCloseKey(hKey); }版本兼容处理是另一个容易翻车的地方。通达信本身有多个版本，不同版本对 DLL 的调用约定可能有细微差别。比如某些老版本要求导出函数返回int而不是void，某些新版本对输出数组的长度定义不一样。我的习惯是在 DLL 里加一个版本检测函数，公式端先调用这个函数获取 DLL 支持的接口版本，再决定用哪套调用方式。虽然麻烦一点，但能避免用户升级通达信后整个策略失效。
从那以后我每次编译完 DLL，都会先在虚拟机里装一个干净的通达信，把 DLL 放进去跑一遍完整流程，确认加载、计算、授权校验都没问题，再发给用户。这个习惯帮我省掉了至少三次“用户说不能用但我本地好好的”的尴尬。希望帮到你。
本文还有配套的精品资源，点击获取
