Okay, I know the basic steps in opening a program:
1) You ask the OS to load the program (double-clicking on it, in Windows).
2) OS loads it into memory.
3) OS sends a trigger to the CPU to start executing instructions at a certain memory address.
What I want to know is how step 3 is done. How does the OS trigger the CPU? Does it just alter IP, and the CPU is always executing instructions anyway?
Yeah, the CPU is always executing instructions.
This is no easy topic. You have several processes running "at the same time". The kernel has to do the flipping, that is, assigning the CPU to one or another.
Imagine you have an operator (the OS), machinary (the CPU) and stuff to be processed (a queue or "ready processes"). There are many processes, and they have to be processed. Each process will be a certain amount of time (named "quantum") with the CPU, then the OS will kick it out and let the next process in the queue to come in.
When a program is ran (double click or whatever), it goes into the "ready processes queue". When the process which is at the CPU is waiting for an I/O operation or its quantum has expired, the CPU picks another one from the queue depending on some stuff (priority, for example).
Processes that are taken away from the CPU 'cause they are waiting for a I/O operation (y'know, if your process is waiting for the disk to be located at the correct sector, for example, it would be a waste of CPU to keep it waiting, so it is better to kick it out and let another process come in) are stored in another queue called "Blocked queue". When the I/O operation ends, the processes go from the "Blocked queue" to the "Ready queue" again, and so on.
The process swapping in the CPU needs several things: 1.- To store all the registers and flags and more stuff from the exiting process somewhere in memory, 2.- To restore all the registers and flags and more stuff from the entering process from somewhere in memory, 3.- Changing the IP to where it was and go.
The OS also runs in the CPU. The main goal is having the CPU always working.
Okay, got it - and even if you are in a non-multithreading OS (like DOS, for instance), the CPU is *always* executing instructions, right? Let's forget multithreading for a moment, and move to that - the CPU never stops executing, right? And if you want it to start executing somewhere else, you change IP, right?
What do you think the interrupts are for? The CPU is always working. You interrupt it and tell it to do something else. Its extremely complex. If you want to learn how a CPU actually works you may start out with a 8085/86 and then come up to 386. They might sound primitive but they are the 'basics' =P
Yeah.
On MSDOS (monoprocess OS) there is just one process. Like TBBQ says, I/O and stuff are accessed thru' MSDOS entry point which is gotten thru interrupts.
8086 CPUs had two working modes: real mode and "executive" or "privileged" mode. Programs run in real mode. When they execute an int, the computer changes to "privileged" mode and the OS takes care of the call, does its stuff (from allocating memory to reading a byte from a file), retrieves the info to the program and then goes back to real mode, letting the program keep executing.
There is a "interrupts vector" which contains just pointers. That way, when you do a "int 21h", the CPU looks in the postion 21h of this vector and jumps to the address that is stored there.
When an INT is called, all registers and a return address are stored in the stack. When the INT routine ends, registers are restored and IP pointed back to the return address.
TSRs are a different story. People think (wrong!!) that they are executing in the background. This is not true. MSDOS doesn't allow multiprogramming. A TSR is just a program that "terminates and stays resident", that is, it is kept on memory and its memory space is somewhat "protected" (I say "somewhat" 'cause MSDOS won't overwrite it when running another EXE, but the EXE itself can write wherever it wants to). A special interruption is set so when the user runs that interruption, the computer jumps to the TSR entry point, does whatever it needs to do, and returns to the calling program.
For example, when using the mouse. A mouse driver installs a small program that reads from the mouse port, and places a pointer to its entry point in "int 33h", so whenever you call "int 33h" the computer jumps to where the mouse driver is in memory and runs from there, then it comes back to your program.
TSRs kinda allow you to add features to DOS =P. I remember a virus which was called "dancing letters" or something. It was a very simple TSR. It used to scan the whole screen and toggle the case of each character on the screen whenever there was a key press =P. So, text like: My name would become mY NAME.
Yes, I've already read about interrupt vectors and what they are.
And, essentially, a TSR is just replacement code in an already existant interrupt. For instance, under msdos, you could alter the int 16h interrupts to fit your fancy, for instance, you could alter the code for a certain function of it so that when you press a key, the PC Speaker plays some notes.
That's my understanding of it.....seems to jive with what you said.
um...not exactly, you *can* reprogram the interrupts but TSRs are meant primarily to extend the IVT.
But yes your understanding is good.
Quote:um...not exactly, you *can* reprogram the interrupts but TSRs are meant primarily to extend the IVT.
But yes your understanding is good.
Wikipedia is silent about what an IVT is, so you'll have to expla...Interrupt Vector Table?
Yeah IVT = Interrupt Vector Table. The table which Nath was talking about all along. It stores pointers aso... =P.