Does exe file after linking consist of machine language only?

Question

I have a question in study C language.

If we compile an advanced language that writes the source code, it becomes an .obj file, and if we link those files, it becomes an exe file, what language is each obj file and exe file composed of? Assembly? Machine language? I'm curious.

I think the exe file is machine language, because our hardware understand the exe file to start program.

Answer 1

In addition to plain text (as mentioned by gregspears in a comment) there are also often lists of initialisation values which get copied at startup into global initiliased variables, i.e. for initialising them. Same for explicitly initialised local static variables. The mentioned plaintext is a special case of these, accompanied by integer values, float values etc.

These are only values, not part of "set ..." instructions, the code copying them at startup is elsewhere, basically a loop.

So in short: No.

Answer 2

It depends on the OS, and more exactly on its loader. The loader defines a contract by which it reads the executable file and:

• optionaly read descriptor tables to know which parts of the file are to be marked as executable an/or read/only
• optionaly allocates additional memory
• optionaly read a loader descriptor to dynamicaly link the new executable to dynamically linked library (which are to be first loaded if they are not already)
• optionaly resolves internal addresses meaning store start point of memory segments to allow the different parts of the program to know of each other
• initializes a stack pointer to what will be the top of the stack
• initializes the program pointer to the start of executable code

From that point on, all the directly executable code is expected to contain plain native machine codes. But that machine code could be used to dynamically interpret full source code or an intermediary portable byte code. For example, the is the way Python compilers work: they embed into a single executable the native Python byte code interpretor and the byte code for the Python modules.

That being said, I can remember the good old .COM format which was the standard format in CP/M and was supported by MS/DOS for compatibility:

• the content of the file was loaded in memory in one single segment
• the segment registers (Intel 8086 real mode) were all initialized to that segment
• some parts of the first 256 bytes were rewritten to contain the program environment and the address of the environment of the parent program (and other things I can no longer remember...)
• the stack pointer was initialized to the top of the segment
• the program counter was initialized to the value 256 (hexa 0x100), relative to the segment of course

No tables, no additional allocation, no dynamic linking... Yet the program had to contain its initialized data, be it textual or binary.