Problem with computer

[Noreen]

I always turn off my computer at night but use "hibernate" during the day.

[Rik]

Odd, I hibernate in the winter.

[Noreen]

I could do with hibernating now! When my niece and her family visited us while I was away, the baby had a cold and now I've got it. It's in my throat and I keep coughing all night.

[Rik]

Sorry to hear that. 

[Noreen]

 

[Sebby]

Glad you got it sorted eventually, Noreen.  Aren't computers great! 

You're right, but I can't help but feel (however unhelpful this comment may be) that Vista in general is to blame. I've seen this kind of thing numerous times with Vista.

[greenfedora]

Well my problem is definitely something in the 7 updates Microsoft released recently.

I reinstalled those updates (taken out during my system restore to recover the PC yesterday) and it started failing with the 0x000000F4 again.

I'm now going to try and figure out which particular update is causing the problem.

Clearly at least one of those updates was designed after a particularly long liquid lunch. It is beyond me how Microsoft have the barefaced effrontery to call Vista an 'Operating System' when 'operating' is one of the things I've found it particularly bad at doing.

[Rik]

I know your frustration, Gordon. MS can be a pain, and their error messages are less than useful.

[JB]

Following the observations here, I updated my computers. I used auto update for all but the two that were reported here as giving a problem to some folk. I downloaded and installed those two manually.

So far, touch wood, all seems OK.

WinXP by the way.

[Rik]

There's no pattern is there.

[bobleslie]

There is no pattern.

Indeed, it is many years (so many I can't even guess the last time) since I had a screw-up with Windows Update.

I have a feeling it may have been with Windows Me. 

[Rik]

One of the problems we had when I did TS for Adobe was that the number of variables in a Windows box was huge, and the manufacturers drivers for graphics cards and printers didn't always play by the rules. It's very hard for mS to do any exhaustive testing of software/OS simply because there isn't any standard environment to test in.

[bobleslie]

Quite. Most problems are driver related, which are the responsibility of the hardware suppliers, but it's usually MS that gets the kicking.

[greenfedora]

Quite. Most problems are driver related, which are the responsibility of the hardware suppliers, but it's usually MS that gets the kicking.

I don't see who else could be responsible though. If I have a driver and some hardware working perfectly fine together, I can see no good reason why a Windows update should stop them working.

[Rik]

Quite. Most problems are driver related, which are the responsibility of the hardware suppliers, but it's usually MS that gets the kicking.

These days, of course, the number of drivers have increased, eg network, wireless, USB etc. It's a nightmare to try and test across a reasonable spectrum of hardware combinations.

[Rik]

I don't see who else could be responsible though. If I have a driver and some hardware working perfectly fine together, I can see no good reason why a Windows update should stop them working.

Too often, Gordon, hardware manufacturers cut corners to gain performance, eg bypassing the Windows API in favour of direct addressing, say, which is fine until the OS changes something (quite legitimately) and the driver breaks.

[bobleslie]

I don't see who else could be responsible though. If I have a driver and some hardware working perfectly fine together, I can see no good reason why a Windows update should stop them working.

It's up to the hardware supplier to test for no conflicts/problems with its drivers for each iteration of the OS. That includes updates.

MS provides these facilities for suppliers and they should use them.

[Rik]

Sadly, of course, they don't.

[greenfedora]

Too often, Gordon, hardware manufacturers cut corners to gain performance, eg bypassing the Windows API in favour of direct addressing, say, which is fine until the OS changes something (quite legitimately) and the driver breaks.

What about backwards compatibility Rik?

The concept seems obsolete now as far as MS is concerned but back when I worked on (mainframe) OS's in the 80's we had to ensure backwards compatibility almost to the dawn of time, just on the off-chance that someone might dust off a ticker tape or card reader and plug it in.

[greenfedora]

It's up to the hardware supplier to test for no conflicts/problems with its drivers for each iteration of the OS. That includes updates.

Whilst I accept that such is now the case, I would dispute that that's the way it should be. The OS is the 'service' component, providing the interface between hardware and software, and I would suggest it should defer to hardware and software suppliers who, after all, provide the stuff that does the productive work on computers.

[bobleslie]

Exactly, Rik. Instead they go bleating about how that awful MS thingy has broken their driver/hardware.

Serious hardware suppliers work closely with MS not only to test their hardware but also to produce correctly programmed drivers which minimise the chances of conflicts through Windows Update or new versions of the OS.

[Rik]

What about backwards compatibility Rik?

The concept seems obsolete now as far as MS is concerned but back when I worked on (mainframe) OS's in the 80's we had to ensure backwards compatibility almost to the dawn of time, just on the off-chance that someone might dust off a ticker tape or card reader and plug it in.

Windows is backwards compatible, generally, Gordon, if the program was written to use MS API calls correctly. The problem starts when software developers cut corners to achieve a result. If MS had maintained absolute backwards compatibility, we'd still be using 16-bit apps.

[bobleslie]

Whilst I accept that such is now the case, I would dispute that that's the way it should be. The OS is the 'service' component, providing the interface between hardware and software, and I would suggest it should defer to hardware and software suppliers who, after all, provide the stuff that does the productive work on computers.

It's logistically impossible for MS to test every single permutation of hardware that is ever likely to be used on a Windows OS.

There is (we are told) a copy of Windows on 95% of the world's computers. If hardware suppliers want to tap into that market they had better provide working drivers and update them rapidly if they break. Otherwise the customer is likely to junk it and go to a more serious supplier.

[greenfedora]

Guys,

What I'm saying is this.

OS providers will issue a specification with which hardware (and software) suppliers must comply. If the suppliers fail to comply with that, then I agree they are at fault.

If the OS provider moves the specification on, then they issue a new specification to suppliers, but they should continue to support the old specification too. The OS supplier should ensure that new versions of its OS work correctly with any drivers that follow a specification it has issued.

Now I will grant you that there may come a time when support can be dropped for very old specifications that really are rarely used, but the time to do that is when users decide - by virtue of their moving away from the older stuff en mass - that the OS can drop support for it.

[Rik]

If the OS provider moves the specification on, then they issue a new specification to suppliers, but they should continue to support the old specification too. The OS supplier should ensure that new versions of its OS work correctly with any drivers that follow a specification it has issued.

I agree with you, Gordon, but MS don't move the official goalposts, they just change the way an API call is handled by Windows. If the developers used that API call, it's a transparent change. If, otoh, they decided to use direct addressing, a favourite trick with video drivers, for example, then things can break.