Scout, coding .exe's in hex isn't impossible if you understand their weird formatting. It's just not recommended, because the headers are so bizarre. My personal opinion is that they were either high on something when they came up with the format or using way too many 512 KB HDDs.
Now, onto the questions:
From what I can tell, your primary confusion is how OSes work. First, you have to recognize that the primary purpose of the OS is to manage the hardware and get it to work together properly. To do this, the OS controls and works with the hardware CPU. However, as you know, programs written in machine code (which is what C and other similar languages compile to) are not terribly portable across different chips. This is why most computers use x86 processors. The standard assembly language allows multiple OSes to be run on the processor. Things like graphics chips and wireless adapters though, are not as standardized. To control these peripherals (in computer OSes), things called Drivers are used which act as add-ons to the OS. The OS talks to the drivers and sends requests to them. The drivers then control the physical hardware, including all of the device specific stuff that the OS doesn't know how to use, and report back when they've finished whatever they were asked to do.
That's an overview of the lowest level of the OS. It simply controls the hardware. When you think about it though, controlling the hardware is difficult and it gives programs a lot of power. What if you don't want to write for every possible computer system out there or you don't trust other people' software with absolute control over your system? That brings us to the next level of the OS which is hardware abstraction. The main point of hardware abstraction is that you can write a program for a Windows computer and as long as the other computer is running the same version of Windows (or Linux, Mac OS X, etc), the program will probably work. The OS provides what is called an Application Program Interface (API) to programs where it gives them access to OS functions (as TI-OS does) to do certain common things like print text on the screen. This means that the OS takes care of the system specific stuff like talking to the screen driver so the program just has to do printf("Hello World") or whatever the syntax is in that language (which is then compiled to a series of system calls). The other consequence is that the OS retains absolute control over the system. Since applications aren't directly talking to the hardware, the OS can shut them down without too much effort if it needs to (threading offers another way to do this by simply terminating execution of the thread using the OS thread handler. I'd be happy to explain threading if you'd like).
On top of the API lies the user interface, which is essentially what you see when you interact with it.
That's a quick and *very* simplified description of how OSes generally work. It's really much more complicated once you get into the "how's" of the matter.
As for the console, it's part of the OS. Somewhere on your hard drive, there's a bunch of code to talk with the screen and display a console. It's the OSes' job to manage all of that so that you don't have to write a thousand lines of code just to print Hello world. The bulk of a computer OS is generally written in C or C++ and compiled to machine code for the target processor type. The OS just contains those hundred lines of C or whatever ridiculous amount of code it takes to print the stuff on the screen and calls that code whenever your hello world program tells it that it needs to print the string (which the OS knows should be printed inside of a console).
Interpreted languages like C# (actually CIL, since C#, Visual BASIC, Visual C, etc all compile to the same machine code) and Java are really big and very different kettle of fish, though. What the interpreter does is look at the file, parse the code into machine code for the processor that's running the interpreter, execute that code and then go onto parsing the next piece of the code. There are ways of doing this in order to make it more efficient, but they're kind of painful to explain in any detail.
Hope that helps
We've generally settled at calling what they call "programming in hex" hEx as a descriptive (and slightly mocking) term. 
