Windows 2000 Quick Fixes by Jim Boyce Unconfirmed error reports are from readers. They have not yet been approved or disproved by the author or editor and represent solely the opinion of the reader. If you have technical questions or error reports, you can send them to booktech@oreilly.com. Please specify the printing date of your copy. This page was last updated August 15, 2001. Here's a key to the markup: [page-number]: serious technical mistake {page-number}: minor technical mistake : important language/formatting problem (page-number): language change or minor formatting problem ?page-number?: reader question or request for clarification UNCONFIRMED errors and comments from readers: (39-40) Section 2.1 gives a terrific explanation of how to show various lists using the Device Manager and the "View" menu option. Figure 2-1 specifically shows the IRQ listing. What I would like to suggest is a section here which explains some of the peculiarities of the NT/2000 IRQ assignments. In particular, why do IRQs greater than 15 exist when 15 is the highest physical IRQ in the box? Those of us who have been using PCs since the DOS days will be well familiar with the physical IRQs. I've used NT for many years and eventually came to the conclusion that these higher IRQs are somehow being software-mapped by the OS into one or more of the lower physical IRQs. But I have yet to find a good written description anywhere of what, exactly, is going on here. And again, from the DOS days, the old-timers in the crowd will be aware that IRQ2 is used to chain the two 8 port interrupt controller chips together and is hence unavailable. The more recent folks wouldn't know that and probably will be wondering where IRQ2 went. I have also been fuzzy myself over the years as to whether IRQ 9 is available, chained to 2, or what. I have seen all sorts of unclear descriptions here over the years. This would be another good thing to discuss. [239-240] Section 12.2; I think this book's explanation of how private and public keys work when encrypting (vice signing) is backwards. For example, the second paragraph in the section reads: "In order to view an encrypted message that you send, the recipient must have a copy of your digital ID with your public key. Similarly, for you to read an encrypted message from someone else, you need his digital ID." However, my understanding is that if I send an encrypted message, I encrypt it using the RECIPIENT'S public key. When he gets it, he decrypts it using his corresponding private key. If my understanding is correct, this paragraph should read something along the following lines: "In order to view an encrypted message that you send, the recipient decrypts it using his own private key, because you encrypted it using his public key (for how you got his public key, read the next paragraph). Similarly, for you to read an encrypted message from someone else (who encrypted it using your public key), you will decrypt it using your own private key." Thus the logic of the encrypted-but-not-signed email process is that the sender should not need his own digital ID but should need only the recipient's digital ID (containing the recipient's public key). But my wife and I ran an experiment, with each of us using Netscape Communitor 4.77's Messenger email component. I sent my wife (who does not have her own digital ID) a signed but not encrypted email, so she would get my public key, which her Netscape saved. She could read my email with no problem, but could not send me an encrypted email in return, even though in principle she should be able to do so because she had my public key. So as a practical matter, the book's section 1.2 apparently is correct in stating that (even for a one-way encrypted but not signed email), recipient and sender each must have a copy of the other's digital ID. I guess that this requirement is because Verisign (the only provider with which I have any experience) wants to encourage everyone to have everyone else's public key, so the process is set up (either in the certificate itself or in the software that makes it work, I know not which) to require both parties to acquire digital IDs. I have no problem with that mutuality condition, but at least in my understanding it's not part of the underlying process. Given my understanding, I did not find any problems with the book's explanation of signed (vice encrypted) email, in section 12.1, pages 237-239 (although I can't testify about the details for either Outlook Express or Outlook because I've never used either one). But for completeness, I'll note that the role of public and private keys with signed email is differs from their role in encrypted email. As explained above, the sender encrypts email using the recipient's public key, and the recipient decrypts the email using the recipient's private key. But the sender signs email using the sender-signer's private key, and the the recipient reads the signature using the sender-signer's public key (contained in the digital ID that is sent along with the signed email).