Internet Explorer 8

[GrahamH]

If that's the case Graham, then the sooner they practise what they preach the better. Will now have a look at the link you mentioned.

The overriding lesson I used to preach to trainee programmers was KISS - Keep It Simple Stupid. There is no such thing as a complex computer instruction but things can get hairy when they are put together wrongly. That factor is magnified when an instruction is actually a macro which executes a subroutine which the programmer (or is it simply coder these days?) doesn't fully understand.

It all calls for a thorough specification and highly structured testing which checks that the developed code does what is specified. Basically no more or less than we expect from manufacturers of things like cars and aircraft.

Another good reason not to go for IE8 in XP

Having installed IE8 on the Vista laptop again, in order to test out the fix, I've left it in place but I haven't used that machine to access the Internet much so far, so wouldn't like to comment on how good (or not) it is.

Given the problems I've experienced, though, I'm not inclined to install it on any of our XP machines. IE7 is running perfectly well and giving us what we need - with Opera & Sea Monkey installed as alternatives if we require them.

Graham

[Nick29]

Another good reason not to go for IE8 in XP

Why ?  Graham is using Vista.   I don't see your logic ?

IE8 & XP SP3 in use here - no problems at all.

[Koromo]

Graham

I'm pleased for you that Microsoft has sorted your problem.
There is nothing more infuriating than not knowing why something has stopped working.

Cheers
Koromo

[GrahamH]

Another good reason not to go for IE8 in XP

Why ?  Graham is using Vista.   I don't see your logic ?

IE8 & XP SP3 in use here - no problems at all.

Agreed that the particular problem which I and my customer suffered occurred using Vista. I also agree that many installations of IE8 (probably the vast majority, I haven't counted) are trouble free in both Vista and XP.

However, there still remain a number of problems (including the one I suffered and those which a Google search highlights, connected with IE8 running under XP) which are there because IE8 has not been throughly tested.

On that basis the law of "if it ain't broke don't fix it" comes in. The logic is that if IE7 is providing all that is required and implementation of IE8 carries a risk of malfunction then that is a good reason for not implementing it.

Graham

[Nick29]

IE8 has functions that IE7 didn't have, which are not earth-shattering, but which are still good to have.  I wouldn't want to roll back to IE7.

I still think that the problems that Vista users have had with IE8 are due to changes brought about by Microsoft to stop "psuedo hard drives" on flash memory sticks from propagating viruses when they auto-run.  This will apparently be fully implemented in Windows 7, due out later this year, but my guess is that many of the roots for this new change were already laid down in Vista.

If the problems in IE8 were down to the actual program coding, then a simple registry change wouldn't fix them.

[GrahamH]

IE8 has functions that IE7 didn't have, which are not earth-shattering, but which are still good to have.  I wouldn't want to roll back to IE7.

Computer hardware and software are simply tools. As with anything else, a function is only good to have if one has a need for it. People in general don't rush out to buy a new screwdriver (for instance) just because the latest on the market has a bit of extra oomph; they do so if they identify that it would be useful.

I would not argue with your desire not to roll back to IE7 but neither would I argue with someone who does not wish to implement IE8 because they do not need the new functionality.

I still think that the problems that Vista users have had with IE8 are due to changes brought about by Microsoft to stop "psuedo hard drives" on flash memory sticks from propagating viruses when they auto-run.  This will apparently be fully implemented in Windows 7, due out later this year, but my guess is that many of the roots for this new change were already laid down in Vista.

When "my" problem first occurred I wasn't sure whether it was the result of a deliberate act by Microsoft or a coding bug. It soon became clear that it was the latter though. If it was the result of a deliberate act then Microsoft would have had documentation detailing the "roots" and should have been able to direct my request to the appropriate team and supply an answer to the problem quickly.

If the problems in IE8 were down to the actual program coding, then a simple registry change wouldn't fix them.

The problem in the IE8 coding is that the program simply stops (with no explanation) if the particular registry entry has a value which is not expected. The registry change amended the value to one which the coding is capable of handling and thus enabled it to work.

It is a general principle of programming (at least it was when I was developing & maintaining software) that a program should never end abnormally without providing a feedback message to the user. The fact that IE8 did so proves that there is a coding error. As I said yesterday, Microsoft have agreed that is the case.

Graham

[Redroger]

Why don't we just apply the KISS principle and keep it simple; seems to be a human trait though we build on a foundation, and then add something to it, and build it into an ever more complex edifice, since this is often easier (in the short term) than starting out afresh.

[GrahamH]

Why don't we just apply the KISS principle and keep it simple; seems to be a human trait though we build on a foundation, and then add something to it, and build it into an ever more complex edifice, since this is often easier (in the short term) than starting out afresh.

Absolutely. All too often short term savings lead to previously stable systems becoming akin to upside down pyramids - which have to be replaced when they fall over and smash to pieces anyway.

No system changes should be made without reference to both the original overall specification and any changes which have taken place subsequently. Too often only the small area being changed is considered with no thought for any effect on the rest of the system.

Graham

[Redroger]

The edifice which I had most to do with during my working career was railway conditions of employment, and rates of pay. Suffice it to say as an illustration that the pay of workshop staff in the 1960s and 70s was based on the following: The rate of pay in 1925, known as the base rate plus the amount of each pay rise added separately and individually when awarded plus for staff in motive power depots a repair bonus based on 27 1/2% of the base rate. You can therefore imagine what a fitters pay card looked like, around 50 entries to determine his rate of pay before bonus. Luckily decimalisation simplified this sector; however in the early 1990s I was headhunted to a vacancy as a chief clerk in charge of rostering train crew, primarily drivers on the basis that I was the only person on the railway management side who had any knowledge of a form of rostering and payment known as contract mileage; a clear case of hire the roster expert and teach him about computers, rather than hire a computer expert and teach him about rosters. This mileage agreement had originally implemented in 1914 (I think), my experience of it was 1958-1964, the vacancy arose in 1993 nearly 80 years after the first agreement  and over 30 after my experience with it. Staff benefitting from the arrangement worked a 3 or 4 day week and were paid megabucks.