windows - 为什么可执行二进制文件中有一些错误消息

Question

在回答关于如何将 const 字符串数据存储在可执行文件中的另一个问题时，出现了一个问题：为什么运行时错误消息存储在可执行文件中而不是由操作系统生成？

!This program cannot be run in DOS mode.
看起来很合理，不能指望 DOS 检测到较新的 Windows 应用程序并生成适当的错误消息。当您的程序处于无法与操作系统函数可靠通信的状态时，也可能会发生有关堆栈帧损坏的其他一些问题

但有些是没有意义的：
- Attempt to use MSIL code from this assembly during native code initialization...etc..
如果我试图调用 .Net 程序集（我没有 - 这是纯 C++ 代码），.Net 或 OS 运行时肯定可以自己生成错误消息。

并且文件系统错误消息也在exe中。当然，我希望操作系统在运行时生成这些错误 - 如果应用程序在非英语版本的 Windows 上运行，我不希望系统错误反映该语言而不是我用来编译它的语言吗？

只是一个周五下午的问题，但Raymond Chen 的网站上似乎没有任何相关内容

Answer 1

The examples I know of are stubs that are placed specifically because there isn't a good way for the OS or some runtime to produce the error. Also, they are fundamental problems with the implementation, not the types of errors a user should ever see.

The DOS one is a perfect example. There's no way for DOS to recognize a Windows program and produce a reasonable error, so the stub code is included in Windows programs.

Your MSIL one is very similar. How can the runtime produce this error if the runtime isn't actually loaded (because the program is still initializing)?

Another example I can think of are "Pure virtual function called" in C++ programs. The abstract base class vtables are filled with stubs that emit this message. I suppose they could be stubs that make an OS call to produce the same message, but that seems like overkill for something that's never supposed to happen.

There's a similar problem if you try to call into the floating point library from a native C or C++ program that isn't actually linked against the floating point library. This is essentially a floating-point implementation detail of the language runtime library (in cooperation with the compiler and the linker). It's not an OS-level issue (in the sense that something like "file not found" is).

Answer 2

这样您就可以全球化您的应用程序。

例如，即使它运行在法语操作系统上，Ivan 也可以用俄语显示错误消息。

Answer 3

我猜这是 CRT 引入的代码，尝试编译一个不与默认库链接的测试应用程序并使用 mainCRTstartup 作为入口点，那么唯一的字符串应该是 DOS 存根中的错误消息。