Sign in to follow this  

Where does the Buck Stop?

Recommended Posts

I'm a little confused about how C++ programs are actually run. Let's say I compile a Hello World app and run it. It's binary code which is run by... the hardware? the OS? It links to the C++ runtime library it was built against, which is also binary code. How does this all happen? Ultimately the instruction to draw "Hello World!" on the screen has to reach hardware. How is it passed to hardware? OS must be involved somewhere, otherwise all programs would run on all OS's. Same for runtime libraries. What gives? I appreciate any help you can give me in understanding this concept.

Share this post

Link to post
Share on other sites
I remember when I looked into C++. The thing I first read was involving the preprocessor.

This is also an interesting ideal. But I was told: "Upon compilation, C++ becomes Binary. Binary is the natural language a CPU understands, and therefore the Binary is given to the CPU to be executed."

That is all I was informed on, either! The OS MUST be involved somewhere. I think at some point, the binary is obtained through the OS' understanding of C++. Do not quote me, and if you wish, ignore me. I just thought maybe I would give my opinion. Sorry. :(

Share this post

Link to post
Share on other sites
Step1: The Hello World program is compiler into binary.
Step2: You dbl click the program to run it
Step3: The OS loads the entire program at a certain spot in RAM.
Step4: Now the hardware starts reading from RAM from the first byte from where the program was loaded.
Step5: The instructions (encoded with the binary numbers) are read into the processor.
Step6: Processor executes each instruction and commands the hards to do the things you asked of it.

There are basically 20 other small steps in between each of those, but I think those are the most important ones.

Basically the OS is involved when you make a call to an OS function from your program. I think you're confused as to what "linking" means. It means that you have two seperate blocks of binary code, that should be one. So they can't work by themselves, but when you combine (link) them, they work fine. For example when I say cout << "...", I'm calling the cout function, but that function can't be called unless it has a body which is defined in another piece of binary code (a library). Also, the function cannot be called without me saying "cout" and I can't call the function without it being defined. So the two pieces must be linked together. The compiler finds the lib where cout is defined, and it basically loads the binary code of the cout definition into RAM. So when the final program runs, both the call (which is in your program) and the definition of the function (which is in a lib) are loaded into RAM and are known. Calls that output something into the command prompt, probably use Kernel32.lib somewhere. Meaning that cout calls a function somewhere in it's definition that is pre-defined by the OS programmers. Think of it this way, the guys that made the OS, created the functions that allow the people programming for that OS do something to it (like print output), so they defined them in the Kernel32.lib and they gave you the names of those functions (found in Win32 API) so you can use them in your programs. When you call those functions, they call the Kernel (core of the OS), which performs specific function (like copying files or writes pixels to screen). You should look into OS design and the way a microprocessor works if you really want to go deep into this stuff. Hope that was helpful.

Share this post

Link to post
Share on other sites
Von Neumann architecture.

A CPU reads from memory, then does something, such as write to memory or activate some signals. It does this over and over billions of times per second.

OS is just a convenience layer. While there is typically some separation between applications and kernel, this is for other reasons - code is still code and runs in the same way.

How is it passed to hardware?

Signals, toggled by CPU, which tell some other piece of hardware to do something. In case of graphics card, they set the pixels in another piece of memory, which are converted into signal sent to monitor.

Of course, how CPU signals depends on individual chipset. So rather than doing that, OS appeared. OS says: "To draw text on screen, call function draw(text), and I will translate that into proper signals". That is the very reason for existence of an OS - which is not required to use a CPU.

That magic part draw(text) is provided by chipset manufacturers in form of drivers. While all drivers look the same to application, they do completely different things and work with completely different hardware.

It's a process of abstraction. You are provided an interface. Same as a car. It has a steering wheel which is same for all - yet each car has different engine, but turning wheel to left means car will go left, no matter which model.

C++ (and other languages) is just one such interface. Standard library is another. Run-time library another. OS, drivers, all just interfaces. They exist in hardware as well (PCI-e, SATA, USB, Firewire). All standardized interfaces, which define how one thing talks to another.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this