First, the learning process
Write the program F.C:
Compile it, pass it normally, and then connect it with an error:
The error message displayed is:
The c0s module does not define the symbol ' _main '.
Then this error message may be related to file c0s.obj . So what causes compilation errors?
Now that the program has been compiled into an obj file, can we connect it with the link.exe we used to use before ? The result is yes:
To view f.exewith debug:
The program is from 06fb:0 to 06fb:001c, altogether 29 a byte. But the code for the entire program has 541 bytes:
Execute the last ret instruction and return to b800 :
View the previous instruction for this address:
The previous instruction was found to be push DS, not a jump instruction, and the f.exe did not return correctly .
The offset address of the known f function is 0.
Write the program M.C:
Compile the connection to m.c , this time the connection does not have an error.
Using debug to view m.exe, the code is found at 1FA :
The program is from 06fb:01fa to 06fb:0216, altogether a byte. But the code for the entire program is 4.19KB:
The program returns 06FB:011D to see the code before the address:
found that the previous instruction is call 01FA, that is, jump to the main program in the code snippet, so the return of the program is correct.
Observe the assembly code of two programs found:
(1 ) f.exe 0 , in debug direct with u command to see, and m.exe 1fa , in debug u main code in the function.
(2)f.exe has not been called, so the function return is wrong,M.exe is called, so the function return is correct.
By knowing: the command address that calls the main function is 06fb:011a, and the instructions returned by the entire m.exe program are:
We found that the instruction and the program returned by the call to the main function were not the statements we wrote, but were provided during the compilation or connection process.
No main function, TC c0s.obj Span style= "font-family: the song Body;" The main There is no definition, and there is no c0s.exe TC or part of it with m.exe
Together to generate an exe file for the connection . and the instructions and procedures that are invoked on the main function should be provided by C0s.obj. So we're going to do research on c0s.obj , we can connect it with Link.exe, and then use debug to see the assembly code. found that although the link prompted the error, but still generated the c0s.exe file:
Using debug view c0s.exe and m.exe found that the code of a program is very similar, then m.exe the main function is called in, what is called in C0s.exe?
As you can see, the C0s.exe should point to the main function segment because the main function is not found, so it points to the next statement. There are also different program segment addresses for call in these two programs.
So C programming must write the main function is because the C0s.obj connection to invoke the main function to perform its function, if we write the main function of other functions, the code in C0s.obj will not be recognized. such as F.exe although can be connected by link.exe, but not be called, but directly execute the contents of it, resulting in a return error. And the book says that the role of C0s.obj is: In the program to start running, related initialization, and then call the main function, return to the relevant resource release, environment recovery, etc., and then return the program. So if we rewrite c0s.obj so that it calls not the main function but other functions, programming can not write the main function.
Write C0s.txt:
Compile the obj file with MASM, overwriting the original c0s.obj file.
F.C the connection, this time the connection was successful.
To view F.exe with debug:
found that the contents of our rewritten c0s.obj appear in the program, the F function has an offset address of 0012 and is returned correctly. F.exe can be run correctly.
Write a new program F.C:
Here the implementation of the principle is the same as the last one, the difference is that the main function is replaced by the F function, because we rewrite the c0s.obj, so the same can be done. But why did the former use the malloc function to open up 20 bytes of space, while the latter was directly assigned 0? I think it should be 200:0 safe space, so it can be used directly, but if in a more complex program or space is more tense, you have to open up space, it is more secure.
Ii. problems to be solved
(1) The role of the C0s.obj file: In the program began to run, the relevant initialization, and then call the main function, return to the relevant resource release, environment recovery, etc., and then return the program.
(2) Can I replace the main function with other functions?
Answer: Yes, but modify the C0s.obj file.
Iii. Unresolved issues
(1) Link.exe is the file that integrates all the compiling needs of c0s.obj, emu.obj, etc.?
(2) If you do not modify C0s.obj, which files do I need to compile the F.C successfully?
Iv. Learning Impressions
When we solve complex problems, we need to break it down into a small problem to solve. This study is a book that raises questions to help us understand and think, but when it comes to solving problems, there is no one to help us divide and raise questions. Therefore, in peacetime study, we should urge ourselves to develop a good habit of thinking.
Why C program must write the main function