And oh, what a sad story it is....
The book is out of print. Exactly why is a long story that I won't bore you with here. In a nutshell, it was released before the days of Amazon.com, and as such, it wilted on the bookshelves alongside billions of other books.
So what about today?
PDH.DLL is a helper DLL provided by Microsoft for reading the NT performance data. There is not Windows 9X/Me equivalent. PDH has gone through several iterations. Early versions had their share of crashes, etc... I wrote two columns, one from the VB perspective, and the other from the C++ point of view.
This DLL used to come with the Win32 SDK (or more recently, the platform SDK). On more recent Systems (that is, Win2K and XP, it's part of the system itself.) If you've only installed Visual C++ or Visual Basic (i.e., Developer Studio), and are running an older system, you may not have this DLL on the system. In my NT 4 SDK installation, I find PDH.DLL under:
\MSTOOLS\BIN\WINNT\PDH.DLL
Under a more recent SDK (from NT 5, beta 1), I find it under:
\MSSDK\BIN\WINNT\PDH.DLL
This is a Microsoft component, and I can't redistribute it by itself.
The first version of PEDUMP was for my 1994 MSJ article on the PE format. This version of PEDUMP was superceded by a version that appears in my book, Windows 95 System Programming Secrets.
Since publishing the book, I have improved PEDUMP. You can get this newer version on the downloads page.
An even newer (and much slicker) version of APISPY32 is included in my PE Format Article rewrite. MSDN magazine gets first crack at it, so you'll have to wait till they publish the article. Sorry!
Originally, APISpy32 was written as an MSJ article. This version of APISPY32 worked with NT 3.5, and a Windows 95 beta. Subsequently, a version that worked with the final Win95 and NT 3.51/NT 4 was published in my book, Windows 95 System Programming Secrets. The sources and executable were included as part of the book.
Subsequently, Microsoft started doing something in PE files that broke APISPY32. Specifically, It faults on programs that have the Import Address Table merged in with the code section. You can get a newer version of this program on the downloads page that doesn't have this problem. I have successfully tested this version on Windows 2000 and XP.
I am aware that APISPY32 doesn't track calls made from DLL programs. This was an exercise left for the reader. It's not harder to do. Think about it!
A major functional overhaul to APISPY32 isn't planned. BoundsChecker and other API spy tools already do a much better job of API spying. Here's one such tool.
Not anytime soon. Any writing that I want to get out of my system, I can do in my column for MSDN Magazine.
Windows NT/2000 Native API Reference by Gary Nebbett
Undocumented Windows 2000 Secrets: A Programmer's Cookbook by Sven B. Schreiber
by David Solomon and Mark Russinovich, for Microsoft Press. It's called "Inside Windows 2000, Third Edition". It's a revision to Custer's original "Inside Windows NT". However, the book has been substantially overhauled and contains quite a lot of meaty new material.
Also, there are many great articles and downloads at www.sysinternals.com.
In the general case, you can't. I've written a couple of columns and articles that hook APIs in one fashion or another. However, if you want a technique that:
then no, I'm not aware of any way to do this. Sure, you may kludge something together that works for your scenario, but I bet it doesn't satisfy the criteria above.
To be completely honest, global API hooking is something that I focus on. However, I still get a lot of email about it, asking for specific help. Thus, I wrote my definitive, last word, "Here's everything I know" column. Check it out in the December 1996 MSJ. Since then, Yariv Kaplan has written even more on the subject of API spying/interception at www.internals.com.
In general, the answer is no.
Truth be told, I've never written a device driver. Not for Windows 3.X. Not for Windows 95. Not for Windows NT.
Why not? I've never needed to. While I write lots of system level programs, I've never had the need to resort to a device driver. The less drivers floating about in a system, the better. When the time comes that I need to write a device driver, I will.
So rather than claim to know anything about device driver development, I'll state up front that I don't.
In general, the answer is No. However, I'm not the person to ask. Since MSDN published the code, you'll have to talk to them about any legal issues.
You can write your own program using the ideas and fragments of code that I've written. However, you cannot take my code, tweak 1 or two items, and sell it as your own program. And for the record, I have caught companies (BIG companies) doing just this.