deploy/src/plugin/share/classes/sun/plugin2/os/windows/Windows.java

has some code that handles when a plugin2 aware applet tag has requested
to run the applet in an earlier (1.4 or 1.5) JRE. That code needs to
load jp2native.dll - from the same JRE as the invoking plugin2 to
make sure it gets the right version. As near as I can tell it does
this by pre-pending its plugin jar location to the boot class path
of the invocation of that 1.4 JRE. Then some code in NativeLoadLibrary
will look relative to that first for the jp2native.dll

It also knows that the earlier 1.4 JRE will not have the
VS2003 runtime : msvcr71.dll, and jp2native.dll will have
that as a dependency so in that case it also looks for that C runtime
and loads it.

A problem arises when JDK upgrades to VS2010. Then jp2native will
instead be dependent on msvcr100.dll and all earlier JRE's
(1.4, 1.5, 1.6) will need to locate that.

But if I make that code change now, so long as JDK 7 promoted
builds are using VS2003, then this will break.

I could put in some "smarts" which attempts to use boot class
path in a similar way to the code described above and look
to see which dll is actually in the plugin's jre\bin directory
and load the right one.

However after some consideration, it seems like its best to leave this
referring only to msvcr71.dll. As soon as JDK 7 upgrades to
use VS2010 we'll need to switch this over to load msvcr100.dll
if its anything earlier than JDk 1.7

What tipped this was the realisation that the logic is actually
GENERATED CODE. And the real source is in
deploy/make/plugin/plugin2/gensrc/windows.cfg

So the fix is to make the changes there, and regenerate Windows.java

Note that if JDK 6 ever switched over to VS2010 something similar
would need to happen there.