4 ms·

"Programming Windows" exposed the simplicity behind the Windows architecture. If you had even a smattering of C experience, Petzold could get you writing Windo

"Programming Windows" exposed the simplicity behind the Windows architecture. If you had even a smattering of C experience, Petzold could get you writing Windows applications the same day you opened his book. He triggered an explosion of software development. There are excellent books for novice Linux programmers, but unfortunately, nothing compared to Petzold's clear and direct presentation. .

shadowfox 4y ago
> There are excellent books for novice Linux programmers Do you have any suggestions in this regard?
- crispyalmond 4y ago
  Unsure of novice, but I have this book[0] which is pretty great. [0] https://man7.org/tlpi/ https://man7.org/tlpi/
pacaro 4y ago
Absolutely! My first software job back in 94, on my first day I was given a battered copy of Petzold and told to read and do the exercises up to chapter 7. It was an extremely effective boot camp for a novice windows programmer
- Narishma 4y ago
  I don't remember there being exercises in those books.
  - pacaro 4y ago
    You may well be correct, the instructions might just have been to code along with the book, I know that part of the exercise was definitely to ensure that I could use the tools. It was 28 years ago, I'm fuzzy on the details :)
Stratoscope 4y ago
This brings back fond memories. Charles thanked me in the Acknowledgements section of the first edition of Programming Windows as "the indefatigable Michael Geary." 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.
copperx 4y ago
"Simplicity of the Windows architecture"? I wish I had read his book, because I read many other bad books and Win32 always felt so complicated.
- l33t2328 4y ago
  Win32 _is_ hilariously complicated(albeit as powerful as anything else with perhaps more steps upfront). 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 )
  - hexomancer 4y ago
    It's funny that you chose fork to make your point because in my opinion window's version is vastly superior. 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.
  - robocat 4y ago
    fork() looks zen, but causes fiendish complications. Microsoft Research wrote a well referenced rebuttal to your opinion (2019): https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... 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/ https://lwn.net/Articles/785430/
blub 4y ago
If I remember correctly, Programming Windows had a desktop app focus, whereas Jeffrey Richter’s book(s) had a system focus. Then .NET happened and almost anybody could program Windows apps, assuming Microsoft didn’t keep deprecating frameworks and languages all the time. 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.

shadowfox 4y ago

> There are excellent books for novice Linux programmers Do you have any suggestions in this regard?

crispyalmond 4y ago
Unsure of novice, but I have this book[0] which is pretty great. [0] https://man7.org/tlpi/ https://man7.org/tlpi/

pacaro 4y ago

Absolutely! My first software job back in 94, on my first day I was given a battered copy of Petzold and told to read and do the exercises up to chapter 7. It was an extremely effective boot camp for a novice windows programmer

Narishma 4y ago
I don't remember there being exercises in those books.
- pacaro 4y ago
  You may well be correct, the instructions might just have been to code along with the book, I know that part of the exercise was definitely to ensure that I could use the tools. It was 28 years ago, I'm fuzzy on the details :)

Stratoscope 4y ago

This brings back fond memories. Charles thanked me in the Acknowledgements section of the first edition of Programming Windows as "the indefatigable Michael Geary." 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.

copperx 4y ago

"Simplicity of the Windows architecture"? I wish I had read his book, because I read many other bad books and Win32 always felt so complicated.

l33t2328 4y ago
Win32 _is_ hilariously complicated(albeit as powerful as anything else with perhaps more steps upfront). 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 )
- hexomancer 4y ago
  It's funny that you chose fork to make your point because in my opinion window's version is vastly superior. 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.
- robocat 4y ago
  fork() looks zen, but causes fiendish complications. Microsoft Research wrote a well referenced rebuttal to your opinion (2019): https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... 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/ https://lwn.net/Articles/785430/

blub 4y ago

If I remember correctly, Programming Windows had a desktop app focus, whereas Jeffrey Richter’s book(s) had a system focus. Then .NET happened and almost anybody could program Windows apps, assuming Microsoft didn’t keep deprecating frameworks and languages all the time. 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.