Thanks Charles; The day has been win one, lose one. I suppose that is progress. After a year and a half of searching, reading and googleing, I finally found someone who could tell me what happens inside of a computer in the microseconds between pushing the On button and the beginning of BIOS being read. There is about 10 pages of stuff that occurs and was not a trivial question. Now I know how my computer comes alive from payment of the electrical bill to blinking at, me waiting to go. No logic gaps. So that is one for the home team. On Mon, 2007-08-20 at 20:59 -0400, Charles MacDonald wrote: > William Case wrote: > > > > > That solves that part. Will look at the goobly-gook of elf again. (It's > > not really goobly-gook. It is more like Greek to me.) > > Bill - your quest is causing you to travel through many levels of > abstraction, most of which exist maily to prevent the "head hurt" of > thinking about them. > > The ELF loader gets a program file in the elf format and decides what > part of it needs to be in memory, what addresses need to be re-located > to fit the program in "this" particular computer today- since the > "virtual" memory addreses may be different from last time. > > The virtual memory is mapped onto physical memory and swapspace > dynamicaly. some part of the "process" can end up sitting in many > differnt Physical memory addresses if it get swaped in and out. > > As I said in the other post, most of the variables end up on the stack > or the heap, which grow and shring dynamicaly as the program runs. > > Each function you write ends up in a table like > > _main > _foo1 > _addUpTheBill > _WCaseSort > > The program in C is always called MAIN, and the compiler adds in some > libaray code that inintialis the program and then calls main. (GUI > programs may have another libary that calls some other special program > name. All the functions have an address which the loader fixes up. the > linker sets this all up with Linking the different compiled c modules > and Libararys that make up the complete program. > > The perfilled variables are also in the file and get loaded into memory, > space that is intened to hold non-prefilled variables is also assigned. > Everything can of course get swapped out at any time. > > Normaly the ELF loader will provide some space for Maloc to use, but the > C libaray can use system functions ot get more. or even give some back. > > > The stack is just there and may be limited in size. Your explanation is more than I have gotten before but is still loaded with questions which I will not ask. I am simply going to put them in reserve and come back to them latter. I am going to stand by what I wrote to Ross Jordon. Some adjustments may be required as to sequencing and terminology, but in the main that's how C programming works and it is not outside the bounds of understanding. Programming must have a simple clear repetitive structure and as such can be visualized and diagrammed. By doing so, one can grasp what is happening through the use of one big gooey symbol. To me it is like playing Bridge. There are those who memorize thousands of rules to cover every possible bidding and playing eventuality, when in fact one only has to know 4 facts. They are: 1) there are only 52 cards in the deck, 2) there are only 4 suits, 3) there are 40 points in a suite, and; 4) you can talk during the bidding, but you must remain quiet during the play. Everything else logically flows from those facts. Similarly, for computers, and particularly programming, there are two sets of common rules. 1) the computer obeys the rules of basic Newtonian physics with an emphasis on the sub-set of rules called electronics. 2) programming obeys the rules of grade school arithmetic with minor excursions into something more exotic. With that said I am going to put the question of organization of a C program into my imponderables file, relax and tomorrow move on to data structures in C. -- Regards Bill