>>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.
>
>But none of this is of interest to the user. The user has an application that does not work, what he wants is one that does, after all it's what he's paid for.
>
>I've been on the wrong end of such a problem. An application which wouldn't print correctly to one type of printer. After contacting the help desk for the application, I was told that as other printers worked, it must be a printer driver problem. On contacting the help desk for the printer, I was told that as other applications could print the same file without any problems, it must be an application problem. Both added the proviso, that it could be a Windows problem, which, of course MS denied.
>
>The above thinking on the problem leads to all concerned refusing to take responsibility for any problems. At the end of the day I ended up with an application that was of no use to me or my client, rightly or wrongly, it was the software company producing the application that were viewed as at fault & consequently have lost at least two customers.

Len,

Well, Fox's problem with the HP printers is kind of unique. The problem is caused by division by zero after the driver has reset the FPU so that it expects the software to handle the error, but does not reset it appropriately. I don't know of another language that doesn't treat this situation as an error.

From my POV, this is: First, bad design on the part of the driver's authors (the state of the environment should always be reset to the original state if change) and their failure to follow the specifications as outlined in the DDK. Second, it is also the developer's responsibility to assure that the data is valid. Clearly, anything involving division by zero is not valid. Fox (prior to SP3) was third for not being more fault tolerant.

My problem (and I think that it relates to your experience) is that to often, so-called "support professionals" are anything but. I prefer that my users contact me directly when problems arise. I'll give you two examples why:

1. A user received an out-of-disk error when attempting to add records in one of my applications (data was being stored on a network). The user contacted our support people, who then dumped it in my lap. I told them that the user's available space on the network needed increasing. After being told that the user had plenty space (and several emails back and forth), I finally convinced them (Net Admin) to allocate more space for the user (and naturally the problem disappeared). The bottom line was that if the support person realized the meaning of "out-of-disk", the user would've been back up and running more quickly.

2. A user of an application that automatically can log on and off different network servers finds that they can't (suddenly) use the application for a particular server. The user contacts the support department, who, again dumps it in my lap as a programming problem. The application works fine with other servers, but not one in particular. I tell them that the user's rights have probably been revoked. Again, emails flow back and forth. Finally, Net Admin checks and, sure enough, the user has no rights to the server. Once the rights are restored, the app works fine.