CODEWITHSUNDEEP
windowsexecutable
Martin Beckett
Martin Beckett

Reputation: 96119

Why are some error messages in executable binary

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

Upvotes: 0

Views: 195

Answers (3)

Adrian McCarthy
Adrian McCarthy

Reputation: 47956

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).

Upvotes: 1

Anders
Anders

Reputation: 101549

I'm guessing this is code pulled in by the CRT, try compiling a test application that does not link with the default libraries and use mainCRTstartup as the entry point, then the only string should be the error message in the DOS stub.

Upvotes: 0

Tony Hopkinson
Tony Hopkinson

Reputation: 20320

It's so you can globalise your application.

E.g Ivan can have the error messages in Russian even though it's running on a French OS.

Upvotes: 0

Related Questions