While I agree OS/2 is a better operating system than Windows, this book depressed me due to Gordon's wrongheaded-belief that a GPF should always be considered an indicator of a programming problem. Since Intel didn't give us a pointer fault, the GPF is the only proper way to implement dynamic linking. As they shipped, OS/2 from version 1.0 to 1.2 never did properly implement dynamic linking; and Windows inherits the wrong way from OS/2. Strangely, Ed Iacobucci (who was Gordon Letwin's counterpart at IBM) wrote an article that appeared in a magazine that described OS/2's dynamic linking as operating the way it should. The key difference is this: in real dynamic linking, CALL instructions that are supposed to invoke procedures in a DLL are constructed in the executable image such that when the processor executes the CALL, it causes a GPF [pointer fault]; then the GPF handler looks at the faulting instruction. If the pointer is a faulted pointer to a routine in a DLL, then snap the link [map the DLL into memory and then modify the faulting instruction to point to the entry point of the routine as described in the DLL's export table], and restart the instruction. Otherwise, it's a bug and you signal a condition which somehere generates an error message. In this scenario, programs start up much faster because the OS is not reading and linking every routine in the executable's import table. If you never use feature <X> in the program, and if feature <X> resides tottally in a separate DLL, then that DLL never gets mapped into RAM. MUCH, MUCH better execution, more robust operation, in particular, the machine wouldn't thrash at startup dur to all those programs in your startup folder. Due to Ed's article, I always assumed that there was a turf was between IBM and Microsoft on this and other salient technical points. MS won and was wrong. So, having said that, you might see why I'm not a big fan of Letwin's. Shew! Glad I got _that_ off my chest again. respectfully submitted, -doug quebbeman