Windows平台编译EXE时生成导入库使其可作DLL的技术问询

多年来已有类似问题被提出，但答案往往完全相反。目前尚未找到针对以下问题的明确答案：
在Windows系统中，是否存在直接方法可在编译可执行文件A时生成导入库，让A能被其他进程当作DLL使用？该做法是否可取？A能否在作为EXE运行的同时被其他进程当作DLL调用？

背景：正在开发一款游戏，希望开放特定函数以支持模组开发，即便无模组时程序自身也会调用这些函数。虽知晓常规方案是生成独立DLL供程序与模组共用，但认为将这些操作存于主EXE更简洁，且内部函数调用速度快于DLL函数。

1. 是否存在直接方法生成导入库让EXE被当作DLL使用？ #

可以实现，但属于非常规操作。Windows的PE格式中，EXE和DLL的核心结构高度相似，仅头部Characteristics字段标记、入口点逻辑存在差异：

• 编译时，可通过编译器/链接器参数（比如MSVC中配合__declspec(dllexport)声明导出函数，再用链接器参数生成导入库），让EXE文件包含DLL必备的导出表，并生成对应的.lib导入库。
• 后续可手动修改PE头的类型标记，或通过特殊链接配置，让输出文件同时具备EXE的可执行性和DLL的导出能力。

2. 该做法是否可取？ #

强烈不推荐，核心原因如下：

• 兼容性与稳定性风险：Windows加载器对EXE和DLL的加载、初始化逻辑完全不同。EXE的入口点（WinMain/main）是为进程启动设计的，而DLL依赖DllMain处理模块加载事件，强行混用会触发初始化异常、内存布局冲突等问题。
• 调试与维护成本：这种非常规用法会大幅提升调试难度，后续编译器更新、Windows系统版本迭代都可能打破现有逻辑，维护成本极高。
• 性能优势无实际意义：现代Windows下DLL函数调用的性能开销几乎可以忽略，所谓“内部调用更快”仅存在于理论层面，游戏运行中完全感知不到差异，反而会因EXE的内存布局限制导致模组调用出现意外问题。

3. 能否在作为EXE运行的同时被其他进程当作DLL调用？ #

技术上有实现可能，但完全达不到预期效果：

• 当EXE作为独立进程运行时，它的内存空间是隔离的。其他进程用LoadLibrary加载该EXE文件，只会在自身进程空间中加载一份独立的EXE副本，无法调用正在运行的游戏进程内存中的函数——模组根本无法与运行中的游戏共享状态，完全偏离需求。
• 即便通过进程注入等手段强行调用运行中EXE的函数，属于非常规内存操作，容易触发系统防护机制（如DEP、ASLR），实现复杂度极高且稳定性无法保障。

替代方案建议 #

回归常规的独立DLL方案才是最优解：

• 将开放给模组的函数封装到单独DLL中，主EXE和模组都链接该DLL的导入库。
• 主EXE内部调用这些函数时，与普通函数调用几乎无差异，性能上完全不用担心。
• 该方案符合Windows设计规范，兼容性、稳定性、可维护性都有保障，模组开发也遵循常规流程，降低双方的成本。

内容的提问来源于stack exchange，提问作者INEEDANSWERS