>Ed,
>
>You are undoubtedly correct as it applies to you.
>
>On the other hand, you have invested *FAR* more time and energy into learning the myriad of intricacies of the countless related (and not so related) components of Win9x, WinNT, IE, networking. . . need I go on <g>.
>

Hey, if you just give up all that sleep nonsense, you'll have plenty of time to play with system internals! < g,d&r >

>For those of us with much more limited knowledge and far fewer connections at MS, the KISS principle is much more helpful.
>

We differ in opinion here - I'd rather have MS put interrim fixes out, and then supply 'complete' SPs on a less frequent basis, especially where the interrim fix applies to a very small part of the product community. there's something to be said for KISS, especially from the MS perspective - they don't have to ask nearly as many questions to figure out what you have if you have just a few levels of SP to deal with.

There's a larger problem here, though; many problems aren't a result of what's in the product as much as what state the operating system and applications are in on the target system. I've got a lot of stuff that I've written (not in VFP) that's affected by the state of MS Office, operating system and support .DLLs, ActiveX controls not put there by my app that can break things or make an installation get very strange, very quickly. Whenever an app has lots of dependencies on system .DLLs and add-ons, things can and will be broken by third party stuff. I can't tell you how many problems I've waded through where the basic installation software put stuff in place, but another app with a sloppy install put an older version in place, or messed up the registry, or updated an ActiveX control with a newer one without hecking to see if something else needed to have the old version (which is incredibly difficult to do, BTW.) A good example of this is where a VFP app has a form containing an ActiveX control added at design time and compiled; the form is now tied tightly to the specific version of the ActiveX control, so if someone comes along with a newer, superset control, the VFP app breaks (as would anything else that used compile-time binding of the control.)

>If all of MS' users had to have your knowledge they would have somewhere around a dozen customers.
>

That many??? *g* Thanks, but there are probably a lot more people out there with as much or more background in system internals than I've got; they just have lives and don't use VFP very much!

-snip-