how to get which msxml version used by IE

[balakrish...@gmail.com]

hi frnds

how to get which msxml version used by IE currently through
javascript, give me any sample code,

Thanks
Dinesh

[Alex Krawarik [MSFT]]

Unless *you* are instantiating a specific MSXML object, the version that IE
uses is always MSXML3.

<balakrish...@gmail.com> wrote in message
news:1167125500....@79g2000cws.googlegroups.com...

[Anthony Jones]

"Alex Krawarik [MSFT]" <ale...@online.microsoft.com> wrote in message
news:e%23GEzNfK...@TK2MSFTNGP03.phx.gbl...

> Unless *you* are instantiating a specific MSXML object, the version that
IE
> uses is always MSXML3.
>

In theory that ought to be true. In practice it sometimes isn't. Until SP2
of MSXML3 a number of applications that used MSXML would break when MSXML3
was installed in replace mode. Some misguided setups included the
restoration of MSXML 2.6 registry entries to put it effectively in
side-by-side mode. Hence the installation of such an app after IE6 had been
installed often left IE6 using MSXML 2.6 since it continued to use the older
CLSIDs.

[Alex Krawarik [MSFT]]

The MS06-061 update kill-bitted MSXML2.6 in the browser.

"Anthony Jones" <A...@yadayadayada.com> wrote in message
news:%23DfhdVP...@TK2MSFTNGP06.phx.gbl...

[VK]

balakrish...@gmail.com wrote:
> how to get which msxml version used by IE currently through
> javascript, give me any sample code,

That's the wrong question - because no one really should care of it .
The right question is: "does the current IE support the MSXML version
able to perform the needed transformations". So based on
methods/properties used in your transformation you define the lowest
required version (3 most of the time but can be higher or lower of
course) and then trying to instantiate ActiveX from the up-to-date
highest to the lowest.

See for instance
<http://groups.google.com/group/microsoft.public.xml/msg/e050e13f6ba7db3f>

[Alex Krawarik [MSFT]]

I am sorry, VK, but this is *absolutely* the wrong approach. Do not assume
that a "higher" version of MSXML is somehow better, because that is not true
in most cases. In fact MSXML3 or MSXML6 is what you will want to use for
most applications, regardless of what you are working on. You will never
want to use MSXML 5.0.

Please see our blog for guidance on what to use inside the browser, and to
understand the differences between the various native XML products:

http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in-internet-explorer.aspx

This is some of the most important reading you can do if you are developing
anything using MSXML in the browser.

Alex

"VK" <school...@yahoo.com> wrote in message
news:1168083903.4...@v33g2000cwv.googlegroups.com...

[VK]

Alex Krawarik [MSFT] wrote:
> I am sorry, VK, but this is *absolutely* the wrong approach. Do not assume
> that a "higher" version of MSXML is somehow better, because that is not true
> in most cases. In fact MSXML3 or MSXML6 is what you will want to use for
> most applications, regardless of what you are working on.

The first thing you want to ensure is that you are using the most
_secure_ version of MSXML out of available on the current machine. In
this respect MSXML3 is the last resort you should use only after having
tried all higher versions.
For really primitive cases (some plain-vanilla ajaxoid) you may try -
after anything else - Microsoft.XMLHTTP. Most of the time though MSXML3
is your last and worst fall-back point.

If you have any doubts about it, check it with the general Microsoft
opinion: install a fresh copy of IE6 build 2001-2003 and run Windows
Update service. What is among the crucial updates? Right, MSXML4
instead of MSXML3. Why? You don't really want to read the list of
exploits, it's just too scary. :-) :-|

> Please see our blog for guidance on what to use inside the browser, and to
> understand the differences between the various native XML products:
<http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in-internet-explorer.aspx>

I respect your freedom to express your point of you, but it is not
acceptable for the programming practice - this is the opinion I reserve
to hold.

The common approach, not only for MSXML is to try to get the best and
the most secure first and if failed then consecutively try to get
something less up to the fall-back minimum limit.

[Alex Krawarik [MSFT]]

> The first thing you want to ensure is that you are using the most
> _secure_ version of MSXML out of available on the current machine. In
> this respect MSXML3 is the last resort you should use only after having
> tried all higher versions.

We agree that using the most secure version of MSXML is desirable, however
you are unfortunately greatly misinformed as to what the capabilities of
each version of MSXML actually is, or when they can be used. Without going
into a large technical discussion, the Xml Core Team (thats me!) guidance is

MSXML3 is more secure than MSXML4 or MSXML5 for most scenarios, today.
Period.
You should never use MSXML5. Period.
You should avoid MSXML4. Period.
MSXML6 is the best option for new applications, going forward.

As such, please stop doling out bad advice.

> I respect your freedom to express your point of you, but it is not
> acceptable for the programming practice - this is the opinion I reserve
> to hold.

Now THATS funny! :)

[VK]

lex Krawarik [MSFT] wrote:
> We agree that using the most secure version of MSXML is desirable

Good. So we have a sound starting point.

As a side note: this is the first time ever I'm conducting a discussion
on one of Microsoft forums. I'm way beyond of "Misro$oft must
die" silliness, just always prefer to ask and discuss on more generic
technical groups. Well, everything has to be tried at least once in
ones life :-)

> however
> you are unfortunately greatly misinformed as to what the capabilities of
> each version of MSXML actually is, or when they can be used.

That's hardly as I was forced to deal with ActiveX/MSXML since 2001.
But OK.

> Without going
> into a large technical discussion, the Xml Core Team (thats me!) guidance is
>
> MSXML3 is more secure than MSXML4 or MSXML5 for most scenarios, today.
> Period.

It is very bad if you really think so. MSXML3 _with all up-to-date
vulnerability fixes_ is rather secure. MSXML3 as it is on older IE6
distribution packages is a big security risk.
Without knowing exactly how a particular MSXML3 was installed and what
updates were made you cannot just blindly state that "MSXML3 is more
secure than X".

> You should never use MSXML5. Period.
> You should avoid MSXML4. Period.

If one has a choice to use either MSXML4 or MSXML3 then choose MSXML4.
Period.
Also with several MSXML libraries installed MSXML3 may get unavailable
after updating MSXML4, so the choice will be eliminated by itself.

> MSXML6 is the best option for new applications, going forward.

That is correct.

> As such, please stop doling out bad advice.
>
> > I respect your freedom to express your point of you, but it is not
> > acceptable for the programming practice - this is the opinion I reserve
> > to hold.
>
> Now THATS funny! :)

It is, but not for the reason you think of. After reading the linked
blog and your advises, I thought first of the famous historical
anecdote about poor Queen Marie-Antoinette:
- You Majesty, your peasants have no bread.
- Poor they are! So let them eat cakes.

In application to the current case that would be something like:
- Dear M$, developers don't know what MSXML to use.
- Poor they are! So let them run the provided .exe file to determine
the current MSXML version.

In the suggested blog I truly enjoyed the expressed vision of the World
Wide Web as one huge ASP-based intranet with developers running around
with admin rights. There is some darling naiveness in that, just like
in Marie-Antoinette with her "so let them eat brioches".

As I went into the discussion any way, let me show how the things are
really being done in WWW. Consider it as a free tour outside of
Versailles (outside of One Microsoft Way ;-)

To eliminate the universal ProgID option, let's us imagine a case with
XPath, contextual fragments and stuff: so "Microsoft.XMLHTTP" doesn't
do the trick.

So say the objective is to write a cross-browser script doing run-time
instantiation of XSLT tools. In case if the needed XSLT tools cannot be
instantiated then warn user and suggest to navigate to an alt page. The
script will be run within the default (narrowed) security settings of
the Internet zone.

So the page is loaded, .js file parsed and started to execute.

Step 1
First check if this is a modern standard-compliant browser, then
explore all other options:

if (
(typeof window.XSLTProcessor == 'function') &&
(typeof document.implementation == 'object') &&
(typeof document.implementation.createDocument == 'function')) {
/*
* Oh... but it is better to be safe now than sorry later.
* The rest of the instantiation code in this branch is irrelevant
* to our subject.
*/
}
else if (typeof window.ActiveXObject == 'function') {
/*
* Hello, softish! :-)
*
* Of course ActiveXObject can be spoofed as well by some
* previous script like say window.ActiveXObject = new Function;
* But window.ActiveXObject check is so widely used that an
* absolute hate is guaranteed to anyone breaking it. Thus even
* the most "famous" spoofers like Safari or Opera did not dare
* so far to spoof window.ActiveXObject.
* So this the regular precaution assume that it is a browser
* supporting ActiveX and potentially able to instantiate MSXML
*
* proceed to Step 2
*/
}
else {
/*
* No needed tools found.
* Proceed to the fall-back options, whatever
* you have chosen.
*/
}

Step 2
On the previous step we successfully branched onto IE-specific block.
Now it's time to try to instantiate MSXML objects. There are two main
obstacles to be ready on this step:

1) current environment prohibits to instantiate _any_ ActiveX objects:
unsigned, signed by Microsoft, by Bill Gates personally, by Lord
himself - doesn't matter. That is an extreme but possible situation, if
say admin was promised to receive pink slip "if sh** like that happens
one more time".
So we have to be ready for a security exception raised on attempt to
instantiate an ActiveX object.

2) We don't know what ProgID to use w/o fail. 6? 4? 3?
On IE situation gets even more complicated because both JScript and
MSXML are not build into browser but they are rather independent DLLs.
It is also spiced up by the facts that during some major pandemics in
the past Microsoft destributed JScript and MSXML "updates" which are
merely previous versions of the relevant DLLs. Say for JScript 5.6
there was "security update" containing JScript 5.1
It could be also occasionally overridden by admin from Windows 2000
setup disk when re-installing scripting host or the whole system.
All that makes possible situations when say IE 6.0 SP1 on Windows 2000
is running JScript 5.1 instead of 5.6 with just-installed MSXML4
security update that made unavailable the default MSXML3. That is not a
mind game: that is just one of practical situations - and not even out
of the most complicated ones - in my support history.

So what shall we do with all these obstacles? Marie-Antoinette would
suggest "to eat cakes if you dont have any bread". So we would display
a message prompting our user to download the needed .exe tool, execute
it and submit the execution results via provided form. Other words
something silly like at <http://support.microsoft.com/kb/q296647/>

But on a commercial web-project one should avoid Marie-Antoinette's
destiny. So our task is to try to activate the needed objects without
any guarantee of a particular library available and even without
guarantee that we are allowed to instantiate any ActiveX objects. And
all this on the background, without asking user to help us and within
the standard Internet zone sandbox.

After some deep thinking :-) it becomes obvious that try-catch block is
our only option. Lucky it is supported in JScript 5.1 as well so we
don't have to worry about IE6 with overridden jscript.dll
The older versions of JScript (1.0 - 5.0) can be rather safely
disregarded as of the year 2007.

As we do agree that MSXML6 is up-to-date the best choice, we'll try
first this library. If no luck then we will try consecutively all other
libraries from top to bottom. Jumping from MSXML6 right onto MSXML3 is
not an option: as it was explained earlier it can be Windows 98
SE/Windows 2000 platform with MSXML4 update so MSXML3 unavailable. Thus
by going from 6 right to 3 you are cutting off without any reason some
part of potential users.

All this effectively brings us to code similar to
<http://groups.google.com/group/microsoft.public.xml/msg/e050e13f6ba7db3f>

The code itself can be further improved of course. Say IE for both
ActiveX disabled and no needed library found situations reports error
439 "Automation server cannot create object". Sometimes it is important
to know the exact reason of the failure so to give appropriate advises
or to redirect to an appropriate page.

In this case one may try to instantiate first some very generic object
and see if success:
try {
var XSLT = new ActiveXObject('Microsoft.XMLHTTP');
}
catch(e) {
if (e.number&0xFFFF)==429) {
// Most probably ActiveX is disabled
}
}
finally {
// Upon check above either instantiate XSLT
// with needed object or fall-back.
}

As I said this is only if you have different fall-back options for
narrowed security and for missing MSXML library. Otherwise do not
complicate your code with no need.

P.S. Here is it, Your Majesty. Our trip to the real world is finished,
I'm leaving you in front of the gates of Versailles :-)

[VK]

VK wrote:
> 439 "Automation server cannot create object".

Posting typo: 429 of course - after service part of the error number
removed.

> if (e.number&0xFFFF)==429)

Posting typo: opening parenthesis is missing, must be

if ((e.number&0xFFFF)==429)

Sorry, should use copy'n'paste instead of runtime typing.

[Alex Krawarik [MSFT]]

> It is very bad if you really think so. MSXML3 _with all up-to-date
> vulnerability fixes_ is rather secure. MSXML3 as it is on older IE6
> distribution packages is a big security risk.
> Without knowing exactly how a particular MSXML3 was installed and what
> updates were made you cannot just blindly state that "MSXML3 is more
> secure than X".

As to your point "MSXML3 as it is on older IE6 distribution packages is a
big security risk"... When talking about this stuff, please understand that
I mean *the lastest* avialable versions of MSXML3 - MSXML3sp7gdr, MSXML3sp8,
and MSXML3sp9 (3sp8 and 3sp9 are Windows Server 2003 SP2, and Vista
releases, respectively) -- MSXML3sp7gdr was distributed to all downlevel
Windows machines in the last several months, please see MS06-061 and
MS06-071 for information on these recent MSXML updates.

If you machine is not actively patched using Windows update, then your
MSXML3 story may be different. This is the end user and admins
responsibilty, however. MSXML3sp5 was the last version of MSXML3 shipped
ubiquitously on Windows XPSP2. MSXML3sp7 was shippined on Windows 2003 Sp1
Both these releases are more secure than MSXML4sp2.

>> You should never use MSXML5. Period.
>> You should avoid MSXML4. Period.
>
> If one has a choice to use either MSXML4 or MSXML3 then choose MSXML4.
> Period.
> Also with several MSXML libraries installed MSXML3 may get unavailable
> after updating MSXML4, so the choice will be eliminated by itself.

This is wrong advice. Personally I don't care what your field experience
lead you to believe up until this week, the MSXML4 product is nearing its
End Of Life and my team is aggressivly pursuing a plan to phase it
completely out of use in a very short time frame. Recommending someone use
MSXML4 over MSXML3 is irresponsible and uninformed.

> 2) We don't know what ProgID to use w/o fail. 6? 4? 3?
> On IE situation gets even more complicated because both JScript and
> MSXML are not build into browser but they are rather independent DLLs.

XmlHttpRequest is now natively supported by IE, actually.

> All that makes possible situations when say IE 6.0 SP1 on Windows 2000
> is running JScript 5.1 instead of 5.6 with just-installed MSXML4
> security update that made unavailable the default MSXML3. That is not a
> mind game: that is just one of practical situations - and not even out
> of the most complicated ones - in my support history.

Thats intersting.

> As we do agree that MSXML6 is up-to-date the best choice, we'll try
> first this library. If no luck then we will try consecutively all other
> libraries from top to bottom. Jumping from MSXML6 right onto MSXML3 is
> not an option: as it was explained earlier it can be Windows 98
> SE/Windows 2000 platform with MSXML4 update so MSXML3 unavailable. Thus
> by going from 6 right to 3 you are cutting off without any reason some
> part of potential users.

You have to realize that while your current line of argument may be true, it
is not relevant. The OS and security and Web landscape has moved along quite
a bit since the bad old days of Windows 9x, and anyone runing these OSs on
the Internet has much much larger problems than their version of MSXML. But,
just briefly, lets address your points: Win95 and Win98 are long out of
support now. Windows NT 4 is as well, except for large shop CSAs that get
special support from my group and others. Talking about these platfoms in
the context of security and development is like talking about ...we'll VAX
or Lisa, or something inane. The first relevant platform we could
legitimately address in the MSXML context is Windows 2000 sp4, which is the
only version of Windows 2000 still in support. If you are REALLY doing web
development for Win9x, then I suggest you update your scripts and if you are
getting hit by an OS verson thats older than NT5, do your client and
yourself a favor and serve them some static content.

> P.S. Here is it, Your Majesty. Our trip to the real world is finished,
> I'm leaving you in front of the gates of Versailles :-)

Thanks that was a nice tour! Wheres the cake??

[Alex Krawarik [MSFT]]

One additional comment around MSXML3 and MSXML6, actually.

The JScript issue you described (which is interesting, I'd like to see a
repro of that) notwithstanding, MSXML3 is the *only* version of MSXML
guaranteed to be on a Windows machine. As of the updates MS06-061 and
MS06-071 in late 2006, as I said, all Windows machines have the latest
non-Vista publically available versoin of MSXML3 now on-box. If your users
are not using Windows update, then they have MSXML3sp5 (XPSP2) or MSXML3sp7
(W2k3sp1).

MSXML6 is shipping on Windows Vista, and we are actively pursuing all
available channels to push it downlevel too; but with all OS releases that
process takes time. As part of the Xml Core team's MSXML4 EOL messaging, we
are pushing downloading the MSXML6 redist and developing against MSXML6 for
new software. As developers you can definitely look forward to MSXML6
becoming more available as the year progresses.