Elysian Shadows

Yo yo wadup dawgz. Rebx in da hizouse! I want to see what really happens when I include files in my programs that let me access parts of my operating system, so I go digging around and I find that all the real meat of what happens is hidden away in A bunch of dll files. What am I spose to do? Am I to forever believe in magic?

Microsoft's software is proprietary so you won't be able to view their code. You can always read the documentation http://msdn.microsoft.com/en-us/dn308572 to find out more about their libraries etc.

Yo yo my main man Rebx! I be in the same pit as you dawg, I feel, I feel yo pain. I be spitting out the same lyrics to my other homedawgs on other forums and eventually found out that like our homeboy Allanis says, you can visit the msdn, but most people aren't fans of the msdn. It's complicated shit to navigate my man!

But you gotta believe in Bill Gates, that man is a player! and you know that he would make sure there be real code and real shit in there!

These awesome series of tutorials covers windows.h, they ain't bustas, they be real rappers from the ghetto my man, and can teach you how to use windows.h functions and access parts of yo operating system.
http://www.youtube.com/watch?v=eOLbs6nl ... 288CE7A0D9
http://www.youtube.com/watch?v=RT_MGEcnHg4
http://www.youtube.com/watch?v=QHrSQ1M30Dk

Although it's videos, and some people around these parts don't like videos, so if you're one of those people that would prefer the real thang Charles Petzold's "Programming Windows", Fifth Edition, is the place to start for all your in-depth windows programming needs.
http://www.amazon.com/Programming-Windo ... 157231995X


Peace! Keep LEAN_AND_MEAN my man,
-SomeGangsterUsername

Your words have not fallen on blind eyes, ol' buddy ol' pal. However, I can see I did not get my question across clearly enough. In terms of programming using the windows api, I've almost done it all, from making a message loop to device drivers. What I want to learn is how #including a header, that seemingly only defines things, opens up the operating system to my program, almost as if the functions of the operation system were open the entire time. It's like magic. So when I went inside the files to see how it's done, all that I can see are function declarations with the actual work in dll files.

From my understanding of how my computer is working; my machine first runs the operating system code which has direct access to all hardware components, which on top of this my software code runs. The OS has openings for which I can write code to access hardware and functions within the OS, and this is where my question comes in. Is there some globally defined name in the process space of all programs running on my machine from which my programs use to access hardware/OS functions that #includes like windows.h latch onto, or is it that somewhere in the code of #includes like windows.h something is done which then opens the access to hardware/OS functions?

I am thinking that it is the former, since for the latter to be the case something would have to be defined from the #includes from my program's side of things which then opens up access to the OS, which to me seems implausible/impossible. For all I know now, #including windows.h casts a magic spell which unseals the door to the Dwarven mountain of power and knowledge. I would gladly look for myself how it is done, but my only way of peering into the vastness of the hidden information of the .dll files is to reverse engineer. Unless I'm missing something.

Sounds like you have some reading to do!

A more specific (and useful IMO) MSDN link: http://msdn.microsoft.com/en-us/library/1ez7dh12.aspx
Also: http://en.wikipedia.org/wiki/Dynamic-link_library

Jeeeeeeeeesus. Let's get started, sunshine.

Rebornxeno wrote:Is there some globally defined name in the process space of all programs running on my machine from which my programs use to access hardware/OS functions that #includes like windows.h latch onto, or is it that somewhere in the code of #includes like windows.h something is done which then opens the access to hardware/OS functions?

First of all, you need to understand the concept of a header file. A header file doesn't "do" shit. 99% of the time, with the sole exceptions being inlining and macros, a header file doesn't even contain any executable code. All it contains are the definitions of data structures and the declarations of functions. The only data this gives the compiler is how to allocate/access structures, and how many/what kinds of arguments the functions take.

The compiler doesn't even know where the fuck these magical functions are, either. They are basically empty symbols until the linking phase. That's when the linker looks at all of these unresolved, magical symbols, and fills them in with their actual addresses from other compilation units (ie your Windows system .DLLs).

So it is absolutely, certainly not in the #includes alone. It is the combination of the includes and the .DLLs. Basically the header files serve as an index or table of contents for the compiler to know what the fuck is in the .DLLS, then the linker is what makes your function calls jump off into magical OS-land.

I can't help but wonder if you are referring to kernel/user space.

kernel space has complete access to memory and other such hardware resources. The memory can't be accessed by processes of the users, preventing user programs to read or write to other user programs etc.

User space is unable to access the kernel space directly, you request for resources from kernel space via system calls.

You can switch between the user/kernel mode using hardware instructions.

If this is indeed what you are speaking of, then refer to: http://www.win.tue.nl/~aeb/linux/lk/lk-3.html

Falco Girgis wrote:First of all, you need to understand the concept of a header file. A header file doesn't "do" shit. 99% of the time, with the sole exceptions being inlining and macros, a header file doesn't even contain any executable code. All it contains are the definitions of data structures and the declarations of functions. The only data this gives the compiler is how to allocate/access structures, and how many/what kinds of arguments the functions take.

I don't want to sound pedantic, but I feel the obligation to point out that header files *should* not contain executable code, but there is nothing in the c/++ language preventing it. The fact that they only contain declarations is a convention followed by every sane developer.

But yes, basically this:

Allanis wrote:User space is unable to access the kernel space directly, you request for resources from kernel space via system calls.

The dll's only contain the machine code (definitions) for the system calls, which are declared on the system headers.

I was not speaking of the libraries. I was trying to get a better understanding of the OP's question.

Well...you could write your own simplistic OS. So then when you're given the "meat & taters" of something like Windows or even Linux, you wouldn't know what you were looking at anyways

Linux, Unix, Windows, OS-X, everything you're familiar with is all monolithic kernel. So there's not much you're gonna find out. If you want to know more about scheduling, memory management, concurrency, and all of the other mundane things that an OS does, look into something old like CP-M (the precursor to MS-DOS) which is freely available.

qpHalcy0n wrote:Well...you could write your own simplistic OS. So then when you're given the "meat & taters" of something like Windows or even Linux, you wouldn't know what you were looking at anyways

Linux, Unix, Windows, OS-X, everything you're familiar with is all monolithic kernel. So there's not much you're gonna find out. If you want to know more about scheduling, memory management, concurrency, and all of the other mundane things that an OS does, look into something old like CP-M (the precursor to MS-DOS) which is freely available.

Very true.

bbguimaraes wrote:

Falco Girgis wrote:First of all, you need to understand the concept of a header file. A header file doesn't "do" shit. 99% of the time, with the sole exceptions being inlining and macros, a header file doesn't even contain any executable code. All it contains are the definitions of data structures and the declarations of functions. The only data this gives the compiler is how to allocate/access structures, and how many/what kinds of arguments the functions take.

I don't want to sound pedantic, but I feel the obligation to point out that header files *should* not contain executable code, but there is nothing in the c/++ language preventing it. The fact that they only contain declarations is a convention followed by every sane developer.

This is just not true. While it is certainly a good practice and is valid quite a bit of the time, there are very important exceptions...

Inlined functions and macros are very important language features that need to be utilized. If you are actually putting simple get/set accessors in a .cpp file, you are DRASTICALLY decreasing the performance of the C++ language for no reason. I would go so far as to call this poor design or a newbie mistake, as this overhead is completely optimized away by making these functions inline.

You are also forgetting about templates, which are a very important language feature requiring executable code to be accessible from every translation unit.

The cute little "separation of interface and implementation" rules are quite a bit more fuzzy in actuality.