141–150 of 176 posts
Looking back it's really strange that nowhere in our CS/Soft Eng. curriculum is it covered exactly what is meant by the term "abstraction" when it comes to how a computer works. That it's all, after all, shuffling of electrons (underlying MOSFET chemistry notwithstanding) and signals is the missing link. There's other books out there, and Ben Eater's website, that indepth show how to construct processor, gates, store…
Earlier quoted context omitted.
Don't oversell it. Speaking as someone who has done VLSI layout of a 32-bit processor in my student days, Petzold's book is a solid popularization but it doesn't cover a tenth of what a computer engineering degree does.
Fair point. I'm speaking about a computer science degree.
My computer science degree included courses on microprocessors, circuit design, logic, system architecture, etc. and I think that most rigorous CS programs would also include these.
"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. .
"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.
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 )
I majored in electronics (more than a decade ago) but always worked in software development. Does it still make sense to purchase it? I am eager to buy it, just need the push. :)
Buy it. I finished my Electrical and Computer Engineering undergrad in 2008 and have been a software dev ever since. You won't learn anything new if you had computer architecture and digital logic classes. But it's an excellent refresher. And so well written that it reads more like light fiction than a technical deep dive.
I majored in electronics (more than a decade ago) but always worked in software development. Does it still make sense to purchase it? I am eager to buy it, just need the push. :)
(Assuming the second edition is as good as the first) yes. This is the kind of book you can read on a plane ride from New York to San Francisco without taking notes or opening up your computer, and still get a lot out of. It's captivating but conversational and well written.
Earlier quoted context omitted.
"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.
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…
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.
"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. .
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
Earlier quoted context omitted.
"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.
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…
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/