V语言在Windows平台创建32位DLL时的函数名修饰问题

问题背景

在使用V语言(vlang)开发Windows平台的32位动态链接库(DLL)时，开发者发现当使用MSVC编译器时，导出的函数名称会被自动修饰。例如，原本声明为func的函数会被修饰为_func@0或_func@8等形式。这种名称修饰行为在Windows平台的32位开发中很常见，但有时开发者希望保持原始的函数名称不被修饰。

问题表现

当开发者使用以下V代码创建32位DLL：

@[export: 'func']
@[callconv: 'stdcall']
fn func() {
    // 函数实现
}

并使用MSVC编译器编译为32位DLL后，生成的导出函数名会被修饰为_func@0。这与开发者期望的原始函数名func不符。

技术原理

在Windows平台的32位开发中，MSVC编译器默认会对函数名进行修饰，这是由以下几个因素决定的：

1. 调用约定(Calling Convention)：当使用stdcall调用约定时，编译器会自动添加下划线前缀和参数大小后缀
2. 名称修饰(Name Mangling)：这是C/C++编译器的常见行为，用于支持函数重载等特性
3. ABI兼容性：修饰后的名称包含了调用约定和参数信息，有助于确保二进制兼容性

解决方案

要解决这个问题，可以通过以下方法之一：

1. 使用模块定义文件(.def)：创建一个模块定义文件明确指定导出的函数名称
2. 修改链接器参数：在链接阶段添加/DEF选项指定导出定义
3. 使用extern "C"语法：虽然V语言不直接支持，但可以通过C互操作特性实现类似效果

对于V语言项目，最直接的解决方案是让编译器生成临时的.def文件，并在链接阶段通过/DEF选项指定该文件。这样可以确保导出的函数名保持原始形式。

实现建议

在V语言的编译器实现中，可以：

1. 自动检测32位DLL编译目标
2. 为每个@[export]函数生成对应的导出定义
3. 创建临时.def文件
4. 在MSVC链接阶段添加/DEF选项

这种方法既保持了开发者的原始意图，又兼容了Windows平台的ABI要求。

注意事项

开发者需要注意：

1. 32位和64位Windows平台的名称修饰规则不同
2. 不同的调用约定(stdcall/cdecl等)会影响名称修饰方式
3. 动态链接库的导入/导出机制在不同平台上有差异

通过理解这些底层机制，开发者可以更好地控制函数导出行为，确保DLL的兼容性和可用性。