资讯详情

VC6.0编译PcShare远控源码:环境搭建与排错实战

📅 2026/10/11 2:14:38 | 华诺云谱 👁 阅读
VC6.0编译PcShare远控源码:环境搭建与排错实战
简介PcShare2005 是一份经典远程控制软件的完整源代码面向具备 C 基础、希望研究远控原理与 Windows 网络编程的开发者及安全学习者。源码基于 VC6.0 环境编写无需修改即可直接编译通过适合用来剖析早期远控在桌面共享、文件传输、键盘鼠标监控、注册表管理等方面的实现思路。资源包共 403 个文件以 121 个 h 头文件与 98 个 cpp 源文件为主体另含 60 个 ico、30 个 bmp 及 cur、gif 等界面图标素材以及 dsw、dsp 工程文件、rc 资源脚本和 lib 静态库压缩包约 1006KB工程结构完整。目前已有 949 人学习下载可作为 C 项目实践、逆向分析与安全研究的参考样本帮助读者理解远控软件的模块划分、通信机制与资源组织方式。1. 老代码的“复活”为什么 VC6.0 编译通过是道硬门槛手里拿到一份十几年前的远控源码第一反应往往是兴奋第二反应就是头疼。尤其是看到工程文件后缀是.dsp和.dsw的时候心里基本就有数了——这玩意儿是给 VC6.0 准备的。很多人觉得把老代码拖进 VS2019 或者 VS2022点一下“重定向项目”再点个“生成”就能跑起来。现实情况是编译错误能刷满整个输出窗口从afxwin.h找不到到error C2065: “IDC_BUTTON1”: 未声明的标识符再到链接器报一堆LNK2001和LNK1120。折腾一整天连个窗口都弹不出来。PcShare 这套源码在圈子里被叫做“经典远控”不是因为它功能有多强大而是因为它结构完整、代码风格原始保留了早期 Windows 网络编程和 MFC 框架的典型写法。它的价值在于你能从里面看到一套完整的 C/S 架构是怎么用纯 Win32 API 和 MFC 搭起来的包括 Socket 通信、心跳维持、屏幕捕获、进程管理、注册表操作这些模块。对于想理解远控底层原理、或者需要维护类似老系统的工程师来说这是一份很好的参考材料。但前提是你得先让它编译通过。VC6.0 直接编译通过这句话听起来简单实际上涉及三个层面的问题第一你的开发环境是不是真的 VC6.0而不是“兼容模式”第二工程依赖的库和头文件路径有没有配对第三代码里那些在当年合法、在今天看来是“未定义行为”的写法编译器会不会放行。这篇文章就是围绕这三个层面把从环境搭建到编译排错的完整路径拆开讲清楚。适合手里有这套源码、想把它跑起来看看效果或者想基于它做二次开发的人。如果你只是想找个现成的工具用那这篇文章可能不太适合你因为接下来要讲的都是怎么跟编译器和链接器打交道。2. 把 VC6.0 环境搭对不是装个 IDE 就完事2.1 为什么高版本 VS 编译老远控源码容易翻车很多人第一反应是用 Visual Studio 2019 或 2022 打开.dsw文件然后让 IDE 自动升级项目。这个操作在编译普通 C 项目时可能没问题但用在 PcShare 这类老远控源码上基本是自找麻烦。原因有三个第一MFC 版本不兼容。VC6.0 用的是 MFC 4.2而 VS2019 用的是 MFC 14.x。这两个版本之间大量 API 的签名变了消息映射宏的展开方式也变了。比如ON_MESSAGE宏在 VC6.0 里展开后是一个AFX_MSGMAP_ENTRY结构体数组到了高版本 VS 里这个结构体的字段顺序和类型都调整过。你强行编译链接器就会报一堆LNK2001: 无法解析的外部符号因为它在找新版本的 MFC 库函数而你的代码是按老版本写的。第二字符集默认值不同。VC6.0 默认使用多字节字符集MBCS而 VS2019 默认使用 Unicode。PcShare 源码里大量使用了char*和CStringA如果你不手动把项目属性里的“字符集”改成“使用多字节字符集”编译器会把CString解析成CStringW然后所有字符串操作都会报类型不匹配的错误。这个坑很隐蔽因为错误信息不会直接告诉你“字符集不对”而是报error C2664: “void ATL::CStringTBaseType,StringTraits::Format(const wchar_t *,...)”: 无法将参数 1 从“const char [10]”转换为“const wchar_t *”。第三安全开发生命周期SDL检查。VS2019 默认开启/sdl和/GS会把strcpy、sprintf、gets这些函数标记为不安全直接报编译错误。PcShare 源码里这类函数遍地都是你不可能一个个去改成strcpy_s那工作量太大。正确的做法是在项目属性里关闭 SDL 检查并把“警告等级”降到/W1甚至/W0。所以如果你真的想“直接编译通过”最省事的路径就是老老实实装一个 VC6.0。别想着用高版本 VS 去兼容那是一条越走越窄的路。2.2 VC6.0 安装与 SP6 补丁的必做步骤VC6.0 原版安装盘在现在的 Windows 10 或 Windows 11 上直接运行大概率会卡在“安装程序正在更新系统设置”那一步然后蓝屏或者无限重启。这不是源码的问题是安装程序本身太老跟新系统的驱动模型冲突。解决办法是在安装之前先把setup.exe的兼容性模式改成“Windows XP (Service Pack 3)”并勾选“以管理员身份运行”。如果还是卡住就进安全模式安装装完再重启。安装过程中有一个关键选项在“安装类型”那一步一定要选“自定义”然后把“Visual C 6.0”和“MFC”两个组件勾上。默认的“典型”安装不会装 MFC 的静态库和头文件后面编译 PcShare 的时候会报fatal error C1083: Cannot open include file: afxwin.h: No such file or directory。装完 VC6.0 之后必须打 SP6 补丁。SP6 修复了 VC6.0 原版里几百个编译器 bug其中就包括对for循环变量作用域的处理。PcShare 源码里有些循环写法依赖了 VC6.0 原版的“非标准”行为不打 SP6 反而可能编译不过。SP6 补丁的安装包在网上还能找到安装时同样要改兼容性模式。装完 SP6 之后还要做一件事把 VC6.0 的include和lib路径里的 Windows SDK 版本确认一下。VC6.0 自带的是 Platform SDK 2000 左右的版本如果你系统里装了更新的 SDKVC6.0 可能会优先去新 SDK 里找头文件导致windows.h里某些宏定义跟 MFC 4.2 冲突。最稳妥的做法是在 VC6.0 的“工具”-“选项”-“目录”里把include和lib路径里非 VC6.0 自带的路径全部删掉只保留 VC6.0 安装目录下的VC98\Include、VC98\MFC\Include和VC98\Lib、VC98\MFC\Lib。2.3 工程文件加载与依赖库路径配置PcShare 源码包里通常包含两个工程一个是服务端被控端一个是客户端主控端。服务端工程一般叫Server.dsp客户端叫Client.dsp还有一个公共库工程叫Common.dsp或者Share.dsp。用 VC6.0 打开.dsw工作区文件时它会自动加载所有关联的.dsp工程。加载之后第一件事是检查“工程”-“设置”-“链接”选项卡里的“对象/库模块”列表。PcShare 通常依赖这几个库ws2_32.libSocket 通信、winmm.lib多媒体定时器、gdi32.lib图形绘制、user32.lib窗口和消息。如果列表里缺了ws2_32.lib链接时会报LNK2001: unresolved external symbol _WSAStartup8和_socket12这类错误。第二件事是检查“C/C”选项卡里的“预处理器定义”。PcShare 源码里通常需要定义WIN32、_WINDOWS、_AFXDLL如果用的是 MFC 动态库或者_AFX_NO_DLL如果用的是静态库。如果这里定义错了会出现error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version这种错误。解决办法是要么把 MFC 改成“使用 MFC 作为共享 DLL”要么把运行时库改成“多线程调试 DLL”并定义_AFXDLL。第三件事是检查“常规”选项卡里的“输出文件”路径。默认情况下VC6.0 会把.exe生成到工程目录下的Debug或Release文件夹里。如果路径里有中文或空格链接器可能会报LNK1104: cannot open file Debug\Server.exe。建议把输出路径改成纯英文、无空格的短路径比如D:\build\server.exe。3. 编译排错实战从报错到生成 EXE 的完整路径3.1 头文件缺失与宏定义冲突的排查方法编译 PcShare 时最常见的第一个错误是fatal error C1083: Cannot open include file: xxx.h: No such file or directory。这个xxx.h通常不是系统头文件而是源码包里自带的某个头文件。比如PcShare.h、Common.h、SocketEx.h这类。出现这个错误说明 VC6.0 的“附加包含路径”里没有把源码包里的include目录加进去。解决办法在“工程”-“设置”-“C/C”-“预处理器”-“附加包含路径”里填入源码包中所有包含.h文件的目录多个目录之间用分号隔开。比如..\Common;..\Include;.\。注意路径要用相对路径不要用绝对路径否则换一台机器就编译不过了。如果加了路径还是报找不到那就检查一下文件名大小写。VC6.0 在 Windows 上默认不区分大小写但如果你把源码包从 Linux 系统里拷贝过来或者从某个压缩包里解压时选了“区分大小写”就可能出现#include SocketEx.h但实际文件名是socketex.h的情况。这种问题在 VC6.0 里不会报“大小写不匹配”而是直接报找不到文件。解决办法是把所有头文件名统一改成小写或者把#include里的文件名改成跟实际文件一致。另一个常见错误是error C2011: xxx : struct type redefinition。这通常是因为某个头文件被重复包含了而且没有加#ifndef守卫。PcShare 源码里有些老头文件确实没写守卫比如Common.h里直接定义了一堆结构体然后在Server.cpp和Client.cpp里各包含了一次。解决办法是在报重复定义的头文件开头加上#ifndef COMMON_H #define COMMON_H // 原有的结构体定义和函数声明 #endif如果不想改源码也可以在包含这个头文件之前手动定义一下守卫宏#define COMMON_H #include Common.h但这种方法只适合临时排错长期维护还是加上守卫比较稳妥。3.2 链接错误 LNK2001 与 LNK1120 的定位技巧当编译阶段通过进入链接阶段时最常见的错误是LNK2001: unresolved external symbol和LNK1120: N unresolved externals。这两个错误是成对出现的LNK1120告诉你一共有多少个未解析的符号LNK2001告诉你具体是哪个符号没找到。PcShare 源码里最容易缺的符号是_WSAStartup8、_socket12、_inet_addr4、_htons4这几个。它们都属于 Winsock 库。如果你在“对象/库模块”里加了ws2_32.lib还是报这个错那就检查一下ws2_32.lib的路径对不对。VC6.0 自带的ws2_32.lib在VC98\Lib目录下如果你系统里装了更新的 Windows SDK链接器可能会去新 SDK 的Lib目录里找而新 SDK 的ws2_32.lib是给高版本 VS 用的跟 VC6.0 的链接器不兼容。解决办法是在“工具”-“选项”-“目录”-“库文件”里把VC98\Lib移到最上面。另一个容易缺的符号是_timeGetTime0它属于winmm.lib。PcShare 里用timeGetTime来做心跳计时如果你没加winmm.lib就会报这个错。加库的方法跟上面一样在“对象/库模块”里加上winmm.lib就行。如果报的是_main或_WinMain16找不到那说明你建工程的时候选错了类型。PcShare 的服务端和客户端都是基于 MFC 的窗口程序应该选“Win32 Application”或者“MFC AppWizard (exe)”而不是“Win32 Console Application”。如果选成了控制台程序链接器会去找main函数而你的代码里只有WinMain自然就报错了。解决办法是重新建一个 MFC 工程把源码文件加进去或者手动在“链接”选项卡里的“工程选项”里加上/subsystem:windows。3.3 字符集与运行时库的匹配设置字符集问题在前面提过这里展开讲一下具体怎么设置。在 VC6.0 里字符集不是在项目属性里改的而是在“工程”-“设置”-“C/C”-“预处理器”里通过定义或不定义_UNICODE和_MBCS来控制的。PcShare 源码默认是多字节字符集所以你应该确保_MBCS被定义而_UNICODE没有被定义。如果这两个宏都没定义VC6.0 会默认使用单字节字符集这跟多字节字符集在大部分情况下是兼容的但CString的某些行为会不一样。最稳妥的做法是显式定义_MBCS。运行时库的匹配也很关键。在“工程”-“设置”-“C/C”-“代码生成”-“使用运行时库”里有四个选项Single-Threaded、Multithreaded、Multithreaded DLL、Debug Multithreaded、Debug Multithreaded DLL。PcShare 通常用的是Multithreaded DLLRelease 模式或Debug Multithreaded DLLDebug 模式。如果你选成了Single-Threaded链接时会报LNK2001: unresolved external symbol _beginthreadex之类的错误因为beginthreadex只在多线程运行时库里才有。另外如果你用的是 MFC 动态库_AFXDLL那么运行时库必须选Multithreaded DLL或Debug Multithreaded DLL。如果 MFC 用的是静态库运行时库可以选Multithreaded或Debug Multithreaded。这两者必须匹配否则会出现LNK2005: _malloc already defined in LIBCMTD.lib这种重复定义错误。3.4 生成 EXE 后的依赖检查与首次运行当链接器终于不再报错生成出Server.exe和Client.exe之后别急着双击运行。先做两件事第一用dumpbin /dependents Server.exe检查一下依赖的 DLL。VC6.0 编译出来的 MFC 程序如果用的是动态 MFC 库会依赖mfc42.dll、msvcrt.dll、ws2_32.dll这几个。在 Windows 10 或 Windows 11 上mfc42.dll可能没有预装你需要手动把它放到C:\Windows\SysWOW64目录下64 位系统或者C:\Windows\System32目录下32 位系统。mfc42.dll可以从 VC6.0 安装目录下的VC98\MFC\Lib里找到或者从网上单独下载。第二检查防火墙设置。PcShare 的服务端会监听一个端口通常是 8000 或 8080客户端会去连接这个端口。Windows 防火墙默认会拦截这种入站连接导致客户端连不上服务端。解决办法是在“Windows 安全中心”-“防火墙和网络保护”-“允许应用通过防火墙”里把Server.exe和Client.exe都加进去并勾选“专用”和“公用”两个网络类型。首次运行时建议先运行服务端再运行客户端。服务端启动后应该能看到一个窗口显示“监听中”或类似的提示。客户端启动后在连接设置里填入127.0.0.1和对应的端口号点“连接”。如果连接成功客户端会显示服务端的屏幕画面或者文件列表。如果连接失败先检查服务端是否真的在监听可以用netstat -an | findstr 8000看一下端口状态再检查防火墙是否放行。4. 避坑指南老远控源码编译的五个血泪教训4.1 坑一VC6.0 在 Win10/Win11 上安装卡死现象运行setup.exe后进度条卡在“安装程序正在更新系统设置”不动或者直接蓝屏重启。原因VC6.0 的安装程序使用了 16 位安装引擎跟 Windows 10/11 的 64 位内核不兼容。另外安装程序会尝试替换系统里的oleaut32.dll和comcat.dll这两个文件在新系统里已经被保护替换会触发系统文件保护机制。解决不要直接运行setup.exe。先把安装盘里的所有文件拷贝到硬盘上一个纯英文、无空格的目录里比如D:\VC6\。然后右键setup.exe属性 - 兼容性 - 勾选“以兼容模式运行这个程序”选“Windows XP (Service Pack 3)”再勾选“以管理员身份运行”。如果还是卡死就重启电脑按 F8 进入安全模式在安全模式下安装。装完 VC6.0 后不要重启直接安装 SP6 补丁同样用兼容模式。SP6 装完后再重启这样基本能避免卡死和蓝屏。4.2 坑二编译报错 “Cannot open include file: afxwin.h”现象编译时第一个错误就是fatal error C1083: Cannot open include file: afxwin.h: No such file or directory。原因VC6.0 安装时没有勾选 MFC 组件或者安装完后“工具”-“选项”-“目录”里的include路径被其他 SDK 覆盖了。解决先确认 VC6.0 安装目录下有没有VC98\MFC\Include\afxwin.h这个文件。如果没有说明 MFC 组件没装需要重新运行 VC6.0 安装程序选“自定义”把 MFC 勾上。如果有这个文件那就打开“工具”-“选项”-“目录”在“显示目录”下拉框里选“Include files”然后把VC98\MFC\Include和VC98\Include这两条路径移到最上面。如果列表里有其他 SDK 的路径比如C:\Program Files (x86)\Windows Kits\10\Include\...把它们全部删掉或者移到最下面。4.3 坑三链接报错 “unresolved external symbol _WSAStartup8”现象编译通过链接时报LNK2001: unresolved external symbol _WSAStartup8和LNK1120: 1 unresolved externals。原因没有在工程设置里加入ws2_32.lib或者加入的ws2_32.lib路径不对。解决在“工程”-“设置”-“链接”-“对象/库模块”里手动输入ws2_32.lib注意不要加引号也不要加路径直接写文件名。然后检查“工具”-“选项”-“目录”-“库文件”里VC98\Lib是否在列表里并且排在最上面。如果还是报错就在“工程”-“设置”-“链接”-“工程选项”里手动加上/NODEFAULTLIB:libc.lib和/NODEFAULTLIB:libcmt.lib强制链接器使用ws2_32.lib里的符号。4.4 坑四程序运行后闪退没有任何提示现象双击Server.exe或Client.exe窗口一闪就没了任务管理器里也看不到进程。原因程序在初始化阶段就崩溃了通常是 MFC 动态库没找到或者某个全局对象的构造函数里访问了空指针。解决先用dumpbin /dependents Server.exe检查依赖的 DLL 是否都在。如果缺mfc42.dll就把它从 VC6.0 安装目录里拷贝到C:\Windows\SysWOW64下。如果 DLL 都全那就用 VC6.0 自带的调试器运行。在 VC6.0 里打开工程按 F5 进入调试模式程序崩溃时调试器会停在出错的那一行。如果停在AfxWinInit或者CWinApp::InitInstance里那通常是InitInstance里某个new操作失败了或者某个Create调用返回了FALSE但代码没检查。检查InitInstance里的每一行特别是AfxSocketInit()和CoInitialize()的返回值。4.5 坑五客户端连不上服务端但端口显示在监听现象服务端启动后netstat -an显示端口在LISTENING但客户端连接时提示“连接超时”或“目标主机积极拒绝”。原因Windows 防火墙拦截了入站连接或者服务端绑定的 IP 地址是127.0.0.1而不是0.0.0.0。解决先检查服务端代码里bind的时候用的地址。如果是inet_addr(127.0.0.1)那只有本机能连局域网其他机器连不上。改成INADDR_ANY或者inet_addr(0.0.0.0)。然后检查防火墙在“Windows 安全中心”-“防火墙和网络保护”-“允许应用通过防火墙”里把Server.exe加进去并勾选“专用”和“公用”。如果还是不行临时关闭防火墙测试一下确认是防火墙问题后再把规则加回去。5. 从能编译到能调试老远控源码的二次开发切入点5.1 用 VC6.0 调试器跟踪 Socket 通信流程编译通过只是第一步真正要让这套源码为你所用得能调试。VC6.0 自带的调试器虽然界面老旧但功能足够跟踪 Socket 通信。在Server.cpp里找到OnAccept或者Accept调用的地方按 F9 下断点。然后运行服务端用客户端去连接。当断点命中时按 F10 单步执行观察accept返回的SOCKET句柄值以及后续recv收到的数据内容。如果想看recv收到的原始字节可以在recv调用之后把buf和len添加到 Watch 窗口。VC6.0 的 Watch 窗口支持直接输入buf查看字符数组但如果是二进制数据需要输入buf,10来查看前 10 个字节。对于结构体数据可以输入*(Packet*)buf来按协议格式解析。调试时注意一点VC6.0 的调试器对多线程支持不太好。如果服务端用了多个线程处理不同客户端的连接断点可能会在多个线程之间跳来跳去。解决办法是在“调试”-“线程”窗口里右键点击不需要调试的线程选“冻结”。只保留你要跟踪的那个线程处于活动状态。5.2 修改心跳间隔与重连逻辑的参数位置PcShare 的心跳机制通常是在客户端定时发送一个短包给服务端服务端收到后回复一个确认包。如果客户端连续几次没收到确认就认为连接断开触发重连。这个逻辑的参数一般在Client.cpp或者Common.h里定义。常见的心跳参数有三个HEARTBEAT_INTERVAL发送间隔单位毫秒、HEARTBEAT_TIMEOUT超时时间单位毫秒、MAX_RETRY最大重试次数。在源码里搜索这几个宏找到定义的地方。比如#define HEARTBEAT_INTERVAL 5000 // 每 5 秒发一次心跳 #define HEARTBEAT_TIMEOUT 15000 // 15 秒没收到确认就认为断线 #define MAX_RETRY 3 // 最多重试 3 次如果你想加快断线检测速度可以把HEARTBEAT_INTERVAL改成2000HEARTBEAT_TIMEOUT改成6000。但注意不要改得太小否则在网络抖动的时候会频繁误判断线。我一般会把HEARTBEAT_INTERVAL设为3000HEARTBEAT_TIMEOUT设为9000这样既能较快检测断线又不会因为偶尔的延迟就触发重连。重连逻辑通常在OnClose或者OnError回调里。找到Reconnect()函数看看它是不是用了Sleep(5000)这种硬编码的等待。如果是可以改成指数退避第一次等 1 秒第二次等 2 秒第三次等 4 秒最多等 30 秒。这样在网络恢复后能更快重连上。5.3 屏幕捕获模块的兼容性调整PcShare 的屏幕捕获模块通常用的是 GDI 的BitBlt或者StretchBlt。在 Windows 10/11 上如果程序没有 DPI 感知捕获出来的屏幕画面会被系统缩放导致图像模糊或者坐标偏移。解决办法是在InitInstance里加上SetProcessDPIAware()调用BOOL CServerApp::InitInstance() { // 让程序感知高 DPI避免屏幕捕获被系统缩放 SetProcessDPIAware(); // 原有的初始化代码... }另外如果捕获的是多显示器环境GetSystemMetrics(SM_CXVIRTUALSCREEN)和GetSystemMetrics(SM_CYVIRTUALSCREEN)可以获取虚拟桌面的总宽高。但BitBlt只能捕获主显示器的内容要捕获所有显示器需要用CreateDC(DISPLAY, NULL, NULL, NULL)创建一个覆盖整个虚拟桌面的 DC然后分块捕获。这部分代码 PcShare 原版可能没有需要自己补。还有一个坑在 Windows 10 的某些版本上BitBlt从桌面 DC 捕获的内容可能是全黑的因为桌面合成引擎DWM把桌面渲染到了另一个表面。解决办法是改用PrintWindow或者Windows.Graphics.CaptureAPI。但后者需要 WinRT在 VC6.0 里用不了。所以如果遇到全黑画面可以试试在BitBlt之前加上SetForegroundWindow(GetDesktopWindow())或者用GetDC(NULL)代替GetWindowDC(GetDesktopWindow())。5.4 用日志输出替代 MessageBox 调试老代码里最常见的调试方式就是弹MessageBox。但在远控场景下服务端弹一个框客户端那边可能就卡住了而且如果服务端在远程机器上运行你根本看不到弹框。所以把MessageBox改成写日志文件是二次开发的第一步。在Common.h里加一个简单的日志函数void WriteLog(const char* format, ...) { FILE* fp fopen(debug.log, a); // 追加模式打开日志文件 if (fp NULL) return; va_list args; va_start(args, format); vfprintf(fp, format, args); // 按格式化字符串写入 va_end(args); fprintf(fp, \n); // 每条日志换行 fclose(fp); }然后在需要调试的地方把MessageBox(连接成功, 提示, MB_OK)改成WriteLog(连接成功: %s:%d, ip, port)。这样日志会追加到debug.log文件里你可以随时用记事本打开查看。注意日志文件不要写太大可以在程序启动时检查文件大小超过 1MB 就清空重写。如果不想改源码也可以用OutputDebugString配合 DebugView 工具。OutputDebugString是 Windows API把字符串输出到调试器。在 VC6.0 里按 F5 调试时输出会显示在“输出”窗口的“调试”标签页里。如果程序不是从 VC6.0 启动的可以用 Sysinternals 的 DebugView 工具捕获。但OutputDebugString只支持字符串不支持格式化用起来不如WriteLog方便。5.5 源码版本管理与编译产物归档最后说一个容易被忽视但很重要的点源码版本管理。PcShare 这类老源码你改着改着就可能改乱了想回退到“能编译通过”的那个状态都找不到。所以在第一次编译通过之后立刻把整个源码目录打包备份命名为PcShare_VC6_CompileOK_日期.zip。然后每做一次修改都提交到一个本地 Git 仓库里。VC6.0 的工程文件.dsp、.dsw是文本格式可以直接用 Git 管理。但编译产物.obj、.exe、.pdb不要提交在.gitignore里排除掉# .gitignore 内容 Debug/ Release/ *.obj *.exe *.pdb *.ilk *.ncb *.opt *.plg每次修改代码后先编译确认能生成 EXE再提交。提交信息写清楚改了什么比如“修改心跳间隔为 3000ms”或者“修复屏幕捕获全黑问题”。这样万一改崩了可以随时git checkout回到上一个能编译的版本。另外编译产物也要归档。把Server.exe、Client.exe和它们依赖的mfc42.dll、msvcrt.dll放在一个单独的文件夹里命名为Build_日期_版本号。这样以后要测试不同版本的代码直接运行对应文件夹里的 EXE 就行不用每次都重新编译。我自己的习惯是每完成一个功能模块的修改就编译一次把 EXE 拷到Build目录下用版本号区分。比如Build_20250101_v1、Build_20250102_v2。这样即使源码改乱了至少还有能运行的 EXE 可以对照。这个习惯帮我省了很多后悔药希望也能帮到你。本文还有配套的精品资源点击获取
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑