Archived

This topic is now archived and is closed to further replies.

Compiler Theory

This topic is 5019 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I understand that a compiler *converts* a source code file into object code, which is then linked to startup and library code; this entire linkage forms executable code and thus the executable.... (1) Where do startup and library code come from? (2) What purposes do they serve? (3) Is this Compile >> Link >> Executable process the same regardless of platform? Source code, though destined for the compiler, can still be opened with text editors and IDE''s. (4) What about startup, object, lirbary and executable code? (5) Obviously executable code can''t be opened with text editors, but why?

Share this post


Link to post
Share on other sites
When source is compiled, it forms object file (binary). It''s on the edge of impossible for a human to read binary code without studying for decades . Once the object files are all linked together, an executable is formed from the code that can be run, but is also in binary format. (THIS IS VERY SIMPLE, THERE IS MUCH MORE TO IT)

Share this post


Link to post
Share on other sites
1) These are generalyl supplied witht he compiler. You''ll notice lots of .LIB files listed in MSVC''s Linker settings if you have Visual Studio.

2) They provide precompiled object files that can be included into your project in the link step.

3) Until binary code generation, more or less. At that point, you''re dealing with optimizations and stuff, which is seriously platform dependent.

4, 5) Nerothos has a decent explanation. You can open them and glean specific bits of info, like strings that are embedded in the thing, though.

Share this post


Link to post
Share on other sites
binary code, what you get after compiling source code, is basically a sequence of numeric instructions that the processor on your machine was design to recognize and act accordingly.

The main reason why this process is mostly a one way street, is that information is lost while compiling - names get changed into memory addresses, optimizations may completely muck whatever sequence was in the original source code, etc.

That said, there are decompilers out there that do try to read binary files and produce code that will compile back into those binary files, but without any names and without a guarantee that what you get was the original source code - like using babel fish to translate an english phrase to russian and back, only worse.

Share this post


Link to post
Share on other sites