关于Windows加载DLL时导入地址数组位于text segment的两大疑问

1. 加载器如何处理只读text段中的导入地址数组写入？ #

先纠正一个常见误解：现代Windows程序的导入地址表（IAT，也就是你提到的导入地址数组）一般放在可写的数据段（比如.idata或合并后的.data段），而非text段。但如果确实遇到IAT被放在只读text段的场景（比如旧版编译选项生成的程序），Windows加载器会按以下流程操作：

• 调用VirtualProtect API，把目标内存区域的权限临时改成PAGE_READWRITE（可读可写）；
• 将解析好的DLL函数地址写入数组；
• 再次调用VirtualProtect，将内存权限恢复为原来的PAGE_EXECUTE_READ（只读可执行）。

这种临时修改权限的操作是加载器的标准流程，写完即恢复，保证text段的安全属性。

2. Windows为何不采用Linux式PIC保证text段进程间共享？ #

Windows其实完全支持位置无关代码（PIC），但它的加载模型和设计目标与Linux存在差异，因此IAT机制成为主流实现，而非依赖纯PIC：

• 历史与性能考量：早期Windows设计时，硬件算力有限，PIC所需的相对寻址指令会带来额外开销，不如直接写入绝对地址的IAT高效。同时Windows加载器默认会将DLL加载到其首选基地址，仅当基地址冲突时才会触发重定位——这种模型下text段本来就可以在多进程间共享。
• 导入机制灵活性：IAT天生支持延迟加载特性，即程序实际调用某个DLL函数时才触发加载器解析地址，这对优化启动速度、实现按需加载非常友好，而PIC实现延迟加载的复杂度要高很多。
• 现代共享逻辑：如今IAT都放在数据段，text段保持只读可执行属性，完全可以被多个进程共享。只有当DLL必须重定位时，才会修改text段中的重定位项，此时会触发写时复制，该进程的text段会被复制一份，但这属于少数异常场景，并非常态。

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