In many cases we are talking about organizations using software that requires not just an obsolete internet explorer version, but an ancient one. There have been many years to assess and fix this problem, and just because companies stuck their heads in the sand and expected it would always be someone else's problem. I have little pity for the companies, but I feel deeply for the IT employees that will have to deal with the fallout from poor decision making from management.
Buying or developing technologies that rely on weird proprietary quirks of free versions of software isn't very sane. There's not even a business model in place you can rely on to continue to want to support you since it's free.
That brings up an interesting point though, a special NPAPI plugin that aimed to provide perfect compatibility with older IE versions for a small per-seat license fee could do really well...
Management required that I use VBScript and ActiveX controls, but I had to use JavaScript in cases when VBScript was too slow. Each new version of Internet Explorer would break compatibility and require a rewrite. For example using and programming for IE 4 would break when IE 5 came out and even the AcitveX controls would not load properly. We had to switch from some ActiveX controls Kodak made to use Lead Tools instead to load TIF images of the employee pictures. Then IE 6 came out and broke that and required a new version of Lead Tools and other stuff.
There were people with Macs, OS/2, and Linux that could not use the ASP made websites because they couldn't run ActiveX and VBScript. So I suggested to management that we replace the ActiveX objects with Java objects and use JavaScript instead of VBScript and we could then make it so that the Non-Windows systems could access the Intranet web apps. Management hated that idea and ordered me to never use Java because it wasn't made by Microsoft and they didn't understand it.
But yeah each new IE version broke compatibility in the way management wanted me to develop web apps. I can see why companies want to stay with an older IE version and older Windows, because of the time and money it takes to upgrade the websites to the newer IE versions.
> Buying or developing technologies that rely on weird proprietary quirks of free versions of software isn't very sane. There's not even a business model in place you can rely on to continue to want to support you since it's free.
It's all very well saying this now, but I wouldn't be surprised if at the time these technologies were seen as JavaScript is now. I remember Adobe Air was when it came out...
Javascript has a standard (or more accurately, current javascript is the implementation of a version of the standard). It's a much safer bet that either there will be backwards compatible implementations later or that you will have other options. To my knowlesde, IE's feature set was always "what's supported by the current release".
It's sort of like having a codebase which you can't change which makes use of a bunch of weird proprietary C extensions from some old compiler, and the compiler itself not only has the capability to introduce bugs and security flaws, but has a track-record of doing so. You know it's a ticking time bomb now, and you should have seen it in the beginning (although so many didn't :/ )
Even back in 1997 JavaScript worked differently based on what OS and web browser you had.
I had open sourced this script to detect the OS and web browser so that it would run JavaScript code using if statements for each platform to solve compatibility problems. It should still work today but the ActiveX detection is broken because of the way JavaScript changed.
I understand there were plenty of non-standard features, but keeping to standard features should have been possible, and JS didn't change that much between browser versions (and where it did fixed could be implemented, as your detection script would have helped with).
It took quite a while for some standard JS features to be added[1], but a mostly stable subset was possible (as evidenced by the sites that worked in all the major browsers of the time). The real problem was companies not wanting to devote the time to doing this and taking the shortcut of using the non-standard IE features MS had included at the expense of browser interoperability (which would have provided some protection against using features that would be dropped).
The problem with Internet Explorer at the time I worked with it is that it had a version of JavaScript called JScript that ran in the background that had differences with the JavaScript used in Netscape and other web browsers. https://en.wikipedia.org/wiki/JScript
In my experience I had to write JavaScript code that detected the OS the web browser type and even the processor so that I could use if statements to run the correct JavaScript code for each platform that worked.
I've been out of it for a decade due to a disability, but I see that Microsoft has updated JScript and has used some form of JavaScript in Windows 8 Apps as well. I never really liked Metro/Modern UI and Windows 10 kind of changed it to Universal Apps.
I like that they have made improvements to JavaScript like Node etc and even run JavaScript in the OS and the backend as well as the frontend.
Yeah, I'm familiar with jscript, and have used it in the past. You should check out the "Comparison to Javascript"[1] section of that article. JScript was just MS's way to get around Sun and the trademark issue. In a lot of ways, it's the same as Google and Dalvik compared to Java. Same language, different name to get around legal issues.
Now, I know MS's version of javascript (JScript) had it's own quirks and issues (such as no trailing comma allowed in objects and array syntax), but it shouldn't have been too hard with a minimum of testing to make sure it worked on both IE and Netscape and/or Firebird (before it was renamed to Firefox). The problem is that many didn't both at all, and didn't even attempt to figure out which bits that they used were standard parts of Javascript or the ECMAScript standard and what were MS extensions.
That said, there was a major benefit to people forging ahead with MS specific extensions. The wide acceptance and update of XMLHttpRequest was spurred by MS's introduction of that type of call through custom ActiveX objects[2].
Buying or developing technologies that rely on weird proprietary quirks of free versions of software isn't very sane. There's not even a business model in place you can rely on to continue to want to support you since it's free.
That brings up an interesting point though, a special NPAPI plugin that aimed to provide perfect compatibility with older IE versions for a small per-seat license fee could do really well...