What is and OS written in, what kind of code, and what are the GUI installers written in? Is it the same? Sorry for sounding so stupid, but it would be great if someone could help me out here.

Operating systems tend to be written in assembly (or in a higher level language and "translated down" from there.) Some of the HobbyOS's let you know. (I think Minuet is written fully in Assembly) I'm not exactly sure what the installers are written in, but I assume that it is much the same as the OS. Maybe Assembly with additional Libraries? Now I want to know too.

Thanks dude, now I am gonna go find out what assembly is, heha.

Mostly a combination of Assembly and C (the Linux kernel, in fact, was written mostly in C).

That will be assembler, or assembly language or possibly machine code. Not assembly, please, thats what you do at school in the "big hall"

The kernel is written in C? Wait, so, the computer, I mean, the hardware, can interpret C? Or there an interpreter to directly turn it to binary or, assembly? hmmmm...... this shows how stupid I am concerning this stuff...

You write code directly in Assembler, Assembler is converted directly to binary which is the only thing the CPU understands. Each assembler command has a direct binary equivalent, so you are spelling the program out step by step.

When you write in C or Pascal etc you are writing higher level commands which do not have direct machine code equivalents. This code must be interpreted into assembler and one C statement often represents huge chunks of assembler.

So in assembler to add two numbers you would need to say , move data from memory location X to register A, move data from memory location Y to B, add A to B, move result from A to memory location Z.

In C you say variableA + variableB. The command is read by the compiler which then substitutes the chunk of assembler in the binary.

You might think of source code not as a program in its own right but as a set of instructions which tell the compiler how to put together the chunks of predefined machine code into a binary that you will actualy run.

Which prompts the question, what is a compiler written in? I love the sense of humor of *nix programmers. One of my favorite command names is "yacc" or "yet another compiler compiler".

A compiler is written with the compiler. Sounds recursive and in a sense all inter-related. The development of this generation of compilers are by using high-level languages, particularly C. Most high-level language compilers are also written using C and assembly (mostly).

I think the original compiler ever written was using a combination of machine code and assembly code.

If you want to really get deeper into this I suggest reading Linkers and Loaders. Great book, goes into the theory of compilers, libraries, linkers and loaders and such stuff.

Another useful link:
http://cs.wwc.edu/~aabyan/464/Book/

However, writing a compiler is a complex thing. Maybe there are less than 100 programmers in the world who write compilers.

Just a note, nobody (with around one or two exceptions) writes operating system entirely in assembly anymore. It is very efficient, but you end up spending far too much time making the whole thing work and in the end all that time spent is not worth the extra efficiency. The standard for operating systems these days is C/C++. However, commonly accessed bits and pieces (the boot loader being a good example) are written in assembly. It is possible to have a mix. As for writing compilers? Those are written entirely in assembly to compile as quickly as possible (and because C/C++ wouldn't be able to get down to actually manually manipulating bits the way a compiler would need to).

That's an insanely low estimate. Just look at the number of free and commercial compilers out there for various languages. You could probably find more than 100 different compilers without too much trouble, and I'm sure many of them have more than one developer. In fact, I suspect Microsoft alone employs more than 100 people to work on its various compilers. Yeah, compiler building is hard, but it's not that hard.

Actually, compiler construction is taught at every University and even some advanced trade-schools. Although the programs are intricate, the topic has been discussed ad nauseum and very powerful tools exist to get you over the "rough spots."

It might well be said that while the compilers do an intricate job, they are not, themselves, terribly intricate programs. (Detailed, yes. Intricate, no.) And one of the objectives of the tool-sets is, specifically, to enable that to be the case. One of the "tricks" that is used extensively is the notion of, well, "reading a map." You can navigate anywhere if you know how to read a map and follow it. The procedure of "reading a map and following it" is fairly easy to explain/program, and it remains fairly simple whether the map being followed is simple or complex. So compilers make a lot of use of "maps" (grammars).

As to the background of all these topics ...

(1) The computer (CPU) executes binary code, typically consisting of millions and millions of instructions. (Some languages use what is called "p-code," where the "instructions" basically correspond to short subroutine-calls.)

(2) Compilers are normally used to generate all those instructions. A compiler is a program that takes source-code as input and produces (on a good day...) instructions as output. The language is designed to be practical for people to use, and a single statement might generate dozens or hundreds of CPU instructions. For this reason they're called "high-level" languages.

(3) At the opposite extreme, "assemblers" process a language in which there is a very close, nearly one-to-one correspondence between the statements in the language and the instructions recognized by the CPU. Although stand-alone assemblers exist and are used, languages such as C and C++ include a built-in assembler and support the insertion of assembler-code sequences (intermixed with C/C++ code).

(4) Compilers aren't built "from scratch" any more, because there's just no need to do it (again). Long ago, someone bootstrapped a small, hand-written mini-compiler that supported exactly enough language to allow the mini-compiler to be written in itself .. to compile itself. Once that was done, additions to the compiler could be made in the language itself, expanding the mini-compiler until it was a complete compiler.

(4a) These days, when someone invents a new CPU chip or version of a chip, programmers use cross-compilers. These are compilers that generate instruction-files intended for a type of CPU different from the one on which the compiler is running. The binary file is then uploaded to the new machine. A native, optimized compiler can be prepared for the new architecture in a matter of days.

Thank you guys for all the info, it is greatly appreciated

Writing a compiler = Not that hard
Writing a good compiler = Unimaginably hard

Since the first Unix implementation, OS code is mostly C/C++

Qt(KDE) uses C++
GTK(GNOME) uses C
NeXT OS and Mac OS X uses Objective C (C++ variant)

Writting an OS in assembler is deprecated and IMO insane. Maybe for some specific parts to enhance performance (ie: the boot loader).