Answering another question about how const string data was stored in an executable a question occured: Why are run time error messages stored in the executable rather than generated by the OS?
!This program cannot be run in DOS mode.
Seems reasonable, DOS can’t be expected to detect a newer Windows app and generate an appropriate error message. Some others about stack frame corrupted might also occur when your program is in a state where it can’t reliably communicate with an OS function
But some make no sense:
- Attempt to use MSIL code from this assembly during native code initialization...etc..
If I was trying to call a .Net assembly (which I don’t – this is pure C++ code) surely the .Net or OS runtime could manage to generate the error message itself.
And the file system error messages are also in the exe. Surely I want these errors to be generated by the OS at run time – if the app is being run on a non-english version of Windows don’t I want system errors to reflect that language rather than the one I used to compile it?
Just a Friday afternoon sort of question but there doesn’t seem to be anything about it on Raymond Chen’s site
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).