Migrating the programmer
 

Hi.
At the time being, I'm still basically a windows programmer: I know the Windows' windowing system, the GDI, how messages are handled in the message queue, the difference between console and gui apps, etc.

Now, I got myself the Suse 9.2 linux distro, and I wanna become as familiar with linux as i am with windows.

So, what I'm looking for is some kind of a document that "migrates" me (hence, the subject) from windows to linux. It should give me an overview of the linux system: how do linux processes receive messages, how are X11 window events handled, etc, but also some basic OS issues that are not neccessarily specific to programming.
So, what I do NOT need is something like the KDev manual, or some collection of get-the-job-done tutorials. I wanna understand the system, have an overview, a blueprint, of it in my mind.

[ if this topic sounds familiar to you: yes, i've already posted the same question some time ago. but i apparently misexpressed myself and, as a result, didnt get much useful feedback, so here's another attempt ]

Thank you in advance for your help

first, make a list of what you want to know, there are multiple windowing systems, then the toolkits (you really should go thru a toolkit for GUI application programming), seeing desktops these days, pick your favorite one (each one pretty much has its own dependencies, and different api for its applications) .... KDE, GNOME, GNUStep (each with its own toolkit), then toolkits: QT (KDE), GTK (GNOME), AppKit (GNUStep), FLTK, XT, Motif, (yes, I'm forgetting a few)

sound systems, etc.

from a language point of view, the 3 main desktops use

KDE - C++
GNOME - C
GNUStep - objective-C

http://www.sbin.org/?page=doc (has good docs for XLib (X11 programing), glibc manual, etc)

(window events are selected, by a application, when it happens, X sends the event, and it gets thrown into a que, the application then reads the que 1 event at a time, and does what it wants with them ..... but this is if you use X/XLib programing, if you go thru a toolkit it handles window system specifics for you)

but its better if you ask specifics, usually you don't need to know every bit, and there are many redundant libraries out there, so having a blueprint (or trying to make one) would be a big task (maybe just read the glibc manual, that might bring specific questions)

and what you mean by "messages"?

Well, I'm interested in the following:

Since I have KDE, I guess i'll best start with that, as far as windowing is concerned.
If I wanna use a toolkit, depends on how much it does for me. If it only does what the DefWindowProc does on Windows, then I'll probable get QT, but I dont want anything like MFC. The reason I never used MFC is that it does little more than fully abstract the C-style windowing system to C++-style classes, giving you less control while you can still screw up as much.

I'm also interested in the "portable executable" file format (or whatever it is called on Linux), the object and library files and that.

By the term messages, I mean what they are in Windows: events. An application has to run through a loop over and over again, receiving and dispatching messages, until it receives WM_QUIT, which is probably equivalent to SIGTERM: So, are there any more system "messages/events" like this on linux, and how does the program receive them? Does it also run through a message loop or is the thread simply interrupted by the system in the middle of anything and jumped into some handler proc?

I would also like to know something about the booting process of Linux: like when are which scripts executed, what it the syntax of them (some of those i've seen looked like c++)?

And, well, as I said, the "blueprint" doesnt need to be very sharp. I dont wanna know every dust particle under the couch. I just wanna know what there is and how it works in general, but still not just what it does but also how it operates. So what is most important to me are the latter topics. There are certainly many good documents about x11 prog'ing and i might already find what i need in that aspect on the link you posted (so i'll go there right after i posted this).

So thanks for your help.

The different distros handle things like init scripts differently. You'll find most of the minor details vary from distro to distro.
My suggestion is to get a Linux distro and just start poking around. It isn't like C++ is any different when it is written for Linux. Download a few projects and compile them to get a feel for how that works. Experience and personal testing is likely the best solution for this (as is the case with many Linux problems).

ok, screw messages, throw them at windows. personally i never got to involved in windows programing, it was soo complicated that i said "ah, f c/c++" and started using assembly (owe, windows was a big pain, certainly its not for programing programs)

anyways, i think the closest you can get to "messages" in a POSIX style environment is signals, each signal has a default handler that glibc (the "standard" C library) takes care of, you can however make your own (warning: only make your own if you need to, usually you only need to if your program wants to ask the user if they want to quit to save data), some signals you cant assign handlers to (these kind the kernel will handle, there is one that forces a process to terminate, it wont even let the process clean up, it will just free its memory, and essentially forget it ever existed (meaning the program stops dead in its tracks, only send this to programs that don't respond to the other "kill" signals))

as for the event loop: you have to make your own, however, the desktop environments come with libraries to handle the event loop itself, so you just add things to it, then tell it to run, and thats how application programing works under them, for daemons/programs (system one, CLI only ...) you have to make the main loop yourself, same goes if you don't use those event loop makers they came with.

there are other ways of IPC (inter process communication) at the system level, shared memory for one. Read glibc manual for more info on the system level things.
and ""portable executable" file format", never heard of it.

libraries, like .dll in windows, only programs share the same library (call them .so, (shared object file)

edit: also, in UNIX-like system (as we have here), the "main" function has 3 arguments
1) int - number of arguments
2) char ** - arguments
3) char ** - environment varibales

Thanks. That already gave me a good start.

Linux is intentionally a very Unix(R)-like operating system. Recent versions of Windows(R) since WindowsNT also incorporate many concepts of Unix(R) and its ancestry. I recommend The Design of the Unix Operating System by Maurice J. Bach, ISBN 0-13-201799-7, as a reference to the sorts of interprocess communications used in Linux. I would point to operating-system resources of signals, semaphores, mutexes, and other synchronization methods. Information may be passed between processes conveniently using files and file-like objects called pipes.
A process may fork to spawn a child process. The parent and child processes then may communicate using synchronization objects and pipes. I have used these when writing software to interact with real-time data in both Linux and Windows. There are some advantages to using these messages instead of the message pump method in Windows. Mainly, this method does not rely on of central message handler which may not be very responsive. Instead of a message pump, it is more a data pump. It also does not need to decode messages, because the synchronization object activates the target process. Well, actually, the synchronization methods interface with the process scheduler in the operating system by moving the process from the waiting-for-signal queue to the ready-to run queue. Then the scheduler runs whatever process has highest priority from the ready-to-run queue.
The basic philosophy in Unix is that nearly everything is treated as a file. Programs get their inputs from files and write output to files. Every program explicitly has input file stdin and output files stdout and stderr available. If additional files are needed, they are typically specified as parameters on the command line.
In Linux, the usual philosophy in the graphical user interface is to just get an idea what the user wants to do, then make the corresponding processes runnable with the data from the user interface. This is less tightly coupled than the Windows philosophy of actually invoking action directly within the user interface. It may be less responsive, but is less prone to faults involving message handling.