Gonz,

Let me jump here for a second.

One thing that people have to realize is that Windows ain't DOS! With DOS the OS jumped when the application said so. In Windows, it's the other way around. Since Windows (via the HAL) segregates the application from the hard, and due to the proliferation of Windows compatible hardware and drivers, it's impossible to test all combinations of these with one piece of software. Add to this the changes in the underlying OS, and it becomes an impossible task to certify that any piece of software is "bug" free.

What I'm getting at here is that in some cases, application "bugs" aren't the fault of the application, but rather the environment. Unfortunately, they manifest themselves in such a way that it "appears" to be a part of the application, when, in reality, it's not.

I'll give you two examples of this. Drivers? Sure, all you have to do is look at the HP (and Lexmark) printer driver problems that manifested themselves in VFP 6.0. The problem wasn't 6.0, but rather drivers that weren't written to the published specs. When the errors that resulted were reported it "appeared" to be a VFP problem.

The second was the C5 errors that occurred with SDI forms when 6.0 was first released. Was it a problem with VFP 6.0? Perhaps to some degree it was, but the solution to it did not involve changing 6.0 as much as it did add a Windows component (DCOM).

Will cases like this continue? I don't have a doubt that they will. Combine changing technology, environment and drivers that aren't written to spec, and I don't see how they can be avoided.

Just my take.