Randy Brukardt wrote: > > If you're intending to claim that Microsoft doesn't document > > their API thoroughly, I think you'll find a lot of skepticism. > > You've apparently never tried to use their documentation to build > something substantial. Our experience building Claw is that the SDK > documentation is full of errors and (especially) omissions. You simply > cannot build working code by reading that material: you still have to > write and test code on every platform that you intend to support. Having worked with Windows starting with version 1.06 to the present, I have to second Randy's comments. The documentation is adequate if you know exactly what you have to do and only need to know details such as parameter ordering and values. The SDK presents a microscopic view of Windows. It does not present the big picture of how Windows actually works. The key to engineering is the ability to predict. Without an overview -- a Principles of Operation -- it is impossible to predict behavior. You must resort to empirical trial and error measurements, and then try to construct your own model of behavior. This is tedious, time consuming, and error prone. At the end of the day you may succeed in getting the program to work, but you still may not know why it works or even if it should work. All too often the program will fail later for unknown and mysterious reasons, and you are back square one. Randy's example of control option behavior illustrates the problem precisely >> Mind you, I have 2 or 3 books open on the desk and 2 or >> 3 windows open on my computer whenever I do something >> I haven't done before in Windows -- they aren't the greatest >> at organizing their documents, but it's all there if you can >> figure out where to find it. > > And I bet that you have to use a voting algorithm to figure out how to > proceed, as at least one of them will be wrong almost all of the time. Without deep understand of behavior, you are forced into the cut-and-paste mentality. I don't know how many times I have seen people desperately looking for an Petzold example they can use as template for their solution. In many cases people copy the code so blindly they do not even know what all the calls do, just that it gives them the right answer. Would a formal standard correct the situation? Perhaps not. Posix just codified current Unix practice and tended to include all variations in the standard (i.e. both bcopy and memcpy). However an honest attempt to describe Windows behavior would have wonderful affect: we might even be able to write reliable Windows applications if really knew what we were doing. Of course if Windows did not do what was documented, then the vendor would have to fix it.... :-) David Koogler Boolean Solutions, Ltd.