There are excellent books for novice Linux programmers, but unfortunately, nothing compared to Petzold's clear and direct presentation.
.
I had spent many hours on BIX and CompuServe and maybe GEnie helping other Windows programmers get their start.
So I like to think that in a small way I contributed to Charles' success in educating a generation of Windows programmers.
Remember, friends, always pass it forward.
Consider creating a child process in GNU/Linux:
fork();
Vs in win32’s asinine API:
CreateProcess( NULL, // No module name (use command line) argv[1], // Command line NULL, // Process handle not inheritable NULL, // Thread handle not inheritable FALSE, // Set handle inheritance to FALSE 0, // No creation flags NULL, // Use parent's environment block NULL, // Use parent's starting directory &si, // Pointer to STARTUPINFO structure &pi ) // Pointer to PROCESS_INFORMATION structure )
First of all the name CreateProcess is obviously much more readable than fork. When I want to create a process, I usually want to run some function in the new thread which the windows version takes as arguments, alternatively fork copies the entire god damn process (what?) and I have to choose what to do based on the return value. The only reason the performance of fork is not abysmal is because the underlying operating system has to implement some sort of copy on write optimization but that just makes the performance characteristics of the program less transparent.
A few of the points made:
* Fork is no longer simple. Fork’s semantics have infected the design of each new API that creates process state. The POSIX specification now lists 25 special cases in how the parent’s state is copied to the child [63]: file locks, timers, asynchronous IO operations, tracing, etc. In addition, numerous system call flags control fork’s behaviour with respect to memory mappings (Linux madvise() flags MADV_DONTFORK/DOFORK/WIPEONFORK, etc.), file descriptors (O_CLOEXEC, FD_CLOEXEC) and threads (pthread_atfork()). Any non-trivial OS facility must document its behaviour across a fork, and user-mode libraries must be prepared for their state to be forked at any time. The simplicity and orthogonality of fork is now a myth.
* Fork doesn’t compose
* Fork isn’t thread-safe
* Fork is insecure
* Fork is slow
* Fork doesn’t scale
Etcetera e.g. O_CLOEXEC, FD_CLOEXEC, EFD_CLOEXEC, EPOLL_CLOEXEC, F_DUPFD_CLOEXEC, IN_CLOEXEC, MFD_CLOEXEC, SFD_CLOEXEC, SOCK_CLOEXEC, TFD_CLOEXEC, DRM_CLOEXEC, FAN_CLOEXEC, UDMABUF_FLAGS_CLOEXEC
Edit: Good discussion both pro and against the paper here: https://lwn.net/Articles/785430/
And in the end it turned out that it’s not worth programming windows any more. Just use Qt, Java or the awful web technology of the day and you’ll probably be better off than with whatever MS is recommending.
Do you have any suggestions in this regard?