27

When a program is compiled it is converted to machine code which can be "understood" by the machine. How does this machine code interact with the operating system in order to do things like getting input from the keyboard ? To me, it seems that the machine code should run at a lower level than the operating system and therefore, I can't understand how the OS can act as an intermediary between the compiled application and the hardware.

PS : I just started C ++ programming and I am trying to understand how cin and cout work

mahela007
  • 1,399
  • 4
  • 19
  • 29
  • 1
    The compiled application simply makes function calls to DLLs (the operating system, such as kernel32.dll in Windows) which contain functions of other machine code. That other machine code is written specifically to work with the hardware so you don't have to. – Seth Carnegie Oct 10 '12 at 03:03
  • 1
    Slightly tangential and not really an answer to your question, but maybe if you're interested in boundaries between the language and the OS this will give you a bit of awe/fear/disgust at some of the many many steps in the process you wonder about... :-/ http://stackoverflow.com/a/2444508/211160 – HostileFork says dont trust SE Oct 10 '12 at 03:12

2 Answers2

30

This is a very good question (better than you know), and there is a lot to learn. A LOT.

I'll try to keep it short. The operating system acts as a level of abstraction between software and hardware:

   Software
       .
      /|\    
       |   communicates with
      \|/
       '
Operating System
       .
      /|\    
       |   communicates with
      \|/
       '
   Hardware

The OS communicates with the hardware through programs called drivers (widely used term), and the OS communicates with software through procedures called system calls (not-so-widely used term).

Essentially, when you make a system call, you are leaving your program and entering code of the operating system. System calls are the only way programmers are allowed to communicate with resources.

Now I would stop there, but you also said:

To me, it seems that the machine code should run at a lower level than the operating system and therefore, I can't understand how the OS can act as an intermediary between the compiled application and the hardware.

This is tricky, but simple once you understand some basics.

First, all code is just machine code running on the CPU. No code is higher or lower than other code (with the exception of some commands that can only be run in a privileged kernel mode). So the question is, how can the OS possibly be in control even though it is relinquishing control of the CPU to the user?

When code is running on a CPU, there is a concept called an interrupt. This is a signal sent to the CPU that causes the currently running code to stop and get switched out with another piece of code, called an interrupt handler.

Examples of interrupts include the keyboard, the mouse, and most importantly, the clock.

The clock interrupt is raised on a regular basis causes the operating system's clock interrupt handler to run. Within this clock interrupt handler is the operating system's code that examines what code is currently running determines what code needs to run next. This can be either more operating system code or more user code.

Because the clock is always ticking, and because the operating system always gets this periodic chance to run on the CPU, it is able to orchestrate everything within the computer, even though it runs using the same set of CPU commands as any normal program.

riwalk
  • 14,033
  • 6
  • 51
  • 68
  • 2
    the CPU can also run in multiple modes (kernel and user), with OS code being run in the higher-privileged kernel mode. – OrangeDog Oct 10 '12 at 08:44
  • Thanks.. that was a very good answer. Just to be clear, would it be correct to say that a system call is like an interrupt which stops execution of the application code and switches is out with (i.e starts execution of ) the OS code ? – mahela007 Oct 10 '12 at 10:15
  • @mahela007 there isn't always necessarily an interrupt. As OrangeDog mentioned, an interrupt is one method of telling the kernel to go into kernel mode. However, these are slightly different than hardware interrupts. It's called a kernel trap, which is a software interrupt. See here: http://en.wikipedia.org/wiki/System_call#Typical_implementations and http://en.wikipedia.org/wiki/Trap_%28computing%29 – Geoff Montee Oct 10 '12 at 10:57
  • Great explanation. But can you please clarify one thing. If both the user code and OS code is taking turns then who is stopping the user code to directly access the hardware? – Rahul Bansal Dec 26 '13 at 11:31
  • @RahulBansal, OrangeDog explained it in his comment. A CPU can run in multiple modes, with different permissions. – riwalk Dec 26 '13 at 21:49
5

The operating system provides system calls that programs can call to get access to lower level services.

Note that system calls are different from the system() function that you have probably used to execute external programs.

System calls are used to do things like access files, communicate over the network, request heap memory, etc.

Geoff Montee
  • 2,587
  • 13
  • 14