Jimski Replied to my Post which discourages the use of undocumented API's.  Among other things he mentions that if you test it thoroughly enough , You can get away with it and it will be just like you use regular API's.

I do not agree that testing it makes it OK. Once you publish code that uses undocumented API's you take the risk of your code breaking unexpectadly, because of API changes (This is something I havn't thought about but is a damn good reason not to practice this habit. Thanks to Frans Bouma for contributing this comment to Jimski's Post.) that MS would make to the undeliying system.

Another thing he mentions is that there are a multitude of tools that use this undocumented functionality which we couldn't live without.

I would ,however, agree that it's fine to create tools such as Refelector or others that use this functionality, since they are flexible enough to provide quick updates and changes according to API changes. They are also used for pretty advanced stuff, by people who don't mind if they break once in a while. This is not the case for commercial apps who will be used by 'regular' users.

Also, Today, for business applications, the need to use undocumented API's is growing very small. Since we are using a much more detailed framework, designed much better, we get so much functionality , that, coupled with COM Interop and IJW, shoudl provide pretty much anything you'll ever need. Leaving these bounds seems almost irresponsible..

Jim Talks of "pioneers" that use these Undocumented features. In my view, a pioneer is not necessarily  one who uses what is hidden, but rather, one who uses what is out in the open to create wondeful things other epople hadn't thought about.  Now ,that's a trick I'd like to see.