A couple of years back I worked as a programmer maintaining and extending a Windows application whose development had started in 1993. Besides teaching me to ha

A couple of years back I worked as a programmer maintaining and extending a Windows application whose development had started in 1993. Besides teaching me to hate the Win32 API with vigor, that job and the application taught me - and motivated me to learn - a lot about C. About halfway through my time at that company, I came across this book, and I really liked it. Those were interestings times. ;-) We used OpenWatcom, whose debugger sucks really hard - basically, the moment your program crashes, you cannot inspect any of its state with the debugger, which pretty defeats the purpose of a debugger. The profiler sucked even harder. It was a PC-sampling profiler, and once the number of samples exceeded some magical value, it crashed, taking the program down with it. The compiler itself never gave me any problems, though, and it came with good documentation. It was also one of the few C compilers left that could target DOS. (Don't laugh, more recently I had to write a small program for DOS to set the serial port on a machine attached to an industrial control system to specific parameters.) Sorry for rambling, but this brought up some pleasant memories... :) I think the title is a bit strongly worded, but other than that it is a really good book. When writing large-ish applications in C, one has to develop strategies for dealing with some of C's problems, and even if you disagree with some of the author's suggestions (or, as somebody else pointed out, find them obsolete because of C's ongoing evolution), it gets you thinking about those issues. EDIT: Whether C is the right language for writing large-ish applications is a different issue, but in the early nineties, it was a relatively prudent choice, and if a program is popular/useful enough, someone has got to do the maintenance.