Entry point of instructions to a computer

[Renfield]

What does an assembler do to have a program's instructions read by a computer?  Likesay if I were to understand how an assembler is programmed.  Now, I have an inkling that it has to do with the .EXE file, but could anyone describe how this works (generally) or point me to a source where I might research for myself?  If it varies per hardware then I'd like to know for the case of an x86, Windows architecture.

[askm]

When in the course of human events that these questions

arise, the next course of action, if possible, is to visit your

closest campus of an institution of higher learning, which

would shelve many volumes in its library of computer science.

The best thing perhaps is no requirement of electricity

to read pages in books.

What I am saying is, though Im not ready for this quiz,

the answers are there. Assume there are incorrect

as well as correct answers depending on what, when, who ...

May you be well informed.

[KeepingRealBusy]

Renfield,

You have just opened Pandora's Box and a whole swarm of angry rabid bats has attacked you. You will either die from the rabies, or self inoculate and survive, but forever changed. You will be forced to spend your remaining days wandering "in a maze of twisty dark tunnels, and every direction looks the same".

Welcome.

Dave.

[Renfield]

How 'bout lending a torch and some bread-crumbs?

[KeepingRealBusy]

It seems we've all played this game, but it's been many years.

Dave.

[KeepingRealBusy]

Renfield,

There are many points at which an assembler and or a compiler with a built in assembler have been used to build the machine you are using, from writing the BIOS code to allow the machine to start up, to writing the code for the OS itself, to writing the install program which executes (via the BIOS) from a floppy or CD and allows you (or someone before you, i.e. the manufacturer) to install this OS on a harddrive (not actually required because there are CD based OS's used to initialize the machine - see above), to writing the drivers that interface the hardware to the OS, to writing the editor which looks at compiler code or asm code, to writing the assembler or compiler itself.

What I think you are looking for is this next step, where the editor reads and edits your code and saves it as a file, and you then use an assembler to assemble this file into an object file. Then you need a linker (another program) that can link this object with other objects, or libraries of objects, and create an executable program. This linking step is required because one of the libraries you link with is a system DLL (Dynamically Linked Library) which, when called, does nothing more than cause a special fault that the OS interprets as a call to one of the system functions (defined and documented as an API (Application Program Interface). This allows you to get indirect access to the screen to write on, the keyboard for input, the disk for reading and writing files, etc. When you execute this executable file, the system loads the executable file into memory with a loader and then starts executing the program.

Which one of these areas interests you?

Dave.

[Renfield]

Dave, I appreciate you taking the time to reply to this ridiculously basic matter.

I'm just really rather curious as to what it takes to get my Windows computer to read, let's say, a line of code.  I'd like to know what goes on during "assembly" beyond the translation of opcodes into their machine-language equivalents - what prepares the instructions to be executed by the OS.  Is it any more than filling in the required format specs for an EXE?  I don't expect anyone to write a textbook trying to hone in on what I want specifically, but I don't personally know where to look on the web to research for myself.  I've read the entries on Wikipedia for "object code" and "executable" but is there a perhaps still basic but more technical introduction?

[Tedd]

'Assembly' is limited to just the stage of converting the mnemonics into object-code (opcodes.) After that, the assembler's job is finished.
The next step will be the linker, which converts the object-code into the required exe format.
And that's the end of the compilation process.

It's down to the OS to decide how it loads and executes an exe (any exe - they should all fit the standard format, so it doesn't matter whether it was produced asm or C or anything else.) You tell the OS you want to load an exe (usually by clicking on it) and so the OS loads the exe into memory, checks it's the correct format, etc.. Then it creates the internal structures required for a new process, and unpacks the image data from the exe ready for the new process. Once that's all done, the process is ready to be executed. Since many processes will be running at the same time, they need to take turns - when it's the turn of this new process, it gets scheduled and is able to run.

[Renfield]

You've narrowed it down for me, Tedd.  Thank you.  In my newbishness I had disregarded the linker as something that was only necessary if one had multiple object files or libraries, and not something that had an integral part in the "loading" process itself.  I'll be able to start learning by looking at this topic now.

[fattypotato]

This may also shed some light?

http://support.microsoft.com/kb/65122

[KeepingRealBusy]

Fatty,

Thank you for the excellent reference.

Dave.