few questions,
you take a pre-compiled program and you link and compile it, linking is to the DLL's right?
then you got an executable file or a DLL or whatever you'd like.
if you open it up with a debugger, it is put in assembly and/or ASCII.
if you would open it up with a text editor, then you'd see all these strange ASCII marks crumbled together.
A pre-compiled program consists of 'binary' data - basically, just a stream of numbers, because, for convenience purposes, computers are designed to group 8 bits into bytes - and each byte can therefore represent a number between 0 and 255.
If you load that data into an editor, how the editor displays them is up to the designer of the editor. You can use decimal numbers, hexadecimal or whatever is convenient for you. The thing about computer data is that it is just binary numbers, what they mean is all due to context. The number 169 could represent the copyright symbol (if the file is a text file), or it could represent the command 'load the next value into the accumulator register' (if this is machine code intended to run on a 6502 CPU). The trick is to ensure that your editor (or decoder) is the right type of editor for the data.
So, if I have a set of bytes that read: 169, 255, 141, 4, 0, 240
Written like that it's meaningless to most people. A text editor would render that data as gibberish. A hex editor would render it as A9 FF 8D 04 00 E0 (neater, but still meaningless). A disassembler (which decodes CPU instructions - in this case, this is for a 6502 CPU) would render it as:
LDA #$FF
STA #$0400
RTS
This is a human readable representation of a series of CPU instructions.
An 'assembler' is a program that performs the translation from human readable CPU instructions and converts them into 'machine code' - the stream of numbers that the CPU will pull from memory. E.g. it will convert the line 'LDA #$FF' into the numbers 169, 255.
A compiler takes a human-readable program, which is not directly representative of what the CPU will do, and converts it into some form of binary code (usually machine code). E.g. a compiler will take the line 'B=A *10; Print B' and produce a series of CPU instructions. This is not necessarily the whole conversion into a working program, the instruction sequence corresponding to 'print' may be contained in another file. The job of the linker is to take your compiled program, the compiled program corresponding to the 'print' command, and link them together - into a single working program.
now, the OS, or the kernel or whatever (i'll read the article later ModelWorks, thanks), takes this code, uploads it to memory and then it is being injected generally to the CPU.
first, why is it scrambled when you open it up with the text editor? why isn't it shown like 8B C0 03 D1 and so on? that is just a general question,
When you run a program, the job of the OS is to load the CPU instructions into RAM, so that the CPU can access them. Then instruct the CPU to start executing the instructions.
Seeing as you mentioned DLLs, I'll explain them. We talked about the 'linker' merging multiple compiled (translated) program fragments into a single program. But imagine you've got an app, or an OS, that has hundreds of individual programs. It's a waste of disk space, for every single app to have its own copy of the 'print' (and 1000 other commands) command merged in. The programs get big and bloated, slow to load, need more memory, etc.
So MS invented the DLL. Programs could be left 'unlinked' (or incompletely linked) by the linker. Instead, the OS would have it's own built in linker, which would activate when an incompletely linked program was loaded. The DLL would contain frequently used program fragments, which would be used by multiple programs. When one of the programs is loaded, the fragments from the DLL would be loaded in and merged in RAM.
The display is scrambled because you've used the wrong editor. You've used an editor that assumes that a file is text, and renders the data as if it were text. If you used an editor that assumed the file is hex, then it would show in hex, etc.
second, this is a great confusion,
the code you see on the display is actually electrical signals which in this way or\\or the other represents different byte streams which in regards represents different symbols/instructions and so on.
now as i see it, the display is of course only for the user, the HW doesn't need it, it is just like an out side source for checking out what is happening within the CPU HDD and memory.
so it's like in a water facility which operates and you take samples every now or then or constantly monitoring the quality or characteristics of the monitored medium,
water represents the current or byte stream.
That's right. The code represents electrical signals. The code '8D' would actually mean that the wires connecting RAM to the CPU labelled D7, D3, D2 and D0 were 'on' and D6, D5, D4 and D1 were 'off'. You could write 8D in binary (10001101) to accurately represent the state of the signals. But it's a lot more difficult for humans to read and write the latter.
On the very earliest computers, the programs were indeed entered in binary (either through flipping switches on the front panel, or by punching holes in a card - so that in a card reader the holes would trigger switches that sent signals to the CPU).
maybe before getting to these sub levels of even the ISA or micro-code itself, it is important to figure out the electrical aspects of the technology, and sorry if it takes this subject a little bit east from it's original meaning or label of the thread.
so what is happening inside?
there are many questions here,
you get this signal that is probably divided to different parts of the CPU (CPU as general term), now what goes then,
if any of you can try and describe what happens inside, where it starts, where it goes,
maybe that can clear up the confusion as it is quite a complex matter which is hard to pull out a simple question or a route to follow on the quest to understanding profoundly, so profoundly that you can actually feel like you hold it in the palm of you'r hand.
One of the problems is that modern CPUs are so astonishingly complex that there may be only one or two people (maybe none at all) who actually know how the whole thing works. They are designed by huge teams, each working on a module - or working out ways in which to connect the modules.
But you are right, each operation has a circuit associated with it, and the instruction signals, activate and deactivate the relevant circuits.
In many ways, it's helpful to go back to much earlier computers to see how they work. The 6502 CPU was sufficiently simple that 2 guys designed it by hand, drawing the entire schematic out on a big sheet of paper, on a kitchen table. (Apparently, the name 6502 came from the fact that the schematic had 6502 transistors in it).