Force IE x86 call from script in x64 system
Dave "Crash" Dummy
website for current temperature. It uses "InternetExplorer.Application"
to create an IE object:
Set IE = CreateObject("InternetExplorer.Application")
I am running Win7 x64, and the IE object created is the 64 bit version
of IE. This is not a problem as far as the script is concerned, but if I
click on a link while the background script is running IE, the link
opens with IE x64 instead of the default IE x86. With so many sites
using Flash, this is a problem. Is there any way to force the
application object to use the x86 version of IE?
--
Crash
"Facts are stubborn things, but statistics are more pliable."
~ Laurence J. Peter ~
Mayayana
check the Registry, but you should be able to
edit it there. HKCR\InernetExplorer.Application
points to
HKCR\{0002DF01-0000-0000-C000-000000000046}
In
HKCR\CLSID\{0002DF01-0000-0000-C000-000000000046}\LocalServer32
You should find the path to IE, which you can change
to the 32-bit path. It's possible that there are two
different objects, but I doubt it. I expect the typelib,
etc. is essentially the same in both. But if you don't
find the same GUID as above under
HKCR\InernetExplorer.Application
then there might be two separate objects using the
same ProgID, in which case you'd probably need to
change the GUID there rather than the path under
LocalServer32
--
--
"Dave "Crash" Dummy" <inv...@invalid.invalid> wrote in message
news:j3av9b$jnd$1...@dont-email.me...
Dave "Crash" Dummy
> I don't have access to any Win64 machines to check the Registry, but
> you should be able to edit it there. HKCR\InernetExplorer.Application
> points to
>
> HKCR\{0002DF01-0000-0000-C000-000000000046}
>
> In
>
> HKCR\CLSID\{0002DF01-0000-0000-C000-000000000046}\LocalServer32
>
> You should find the path to IE, which you can change to the 32-bit
> path. It's possible that there are two different objects, but I doubt
> it. I expect the typelib, etc. is essentially the same in both. But
> if you don't find the same GUID as above under
>
> HKCR\InernetExplorer.Application
>
> then there might be two separate objects using the same ProgID, in
> which case you'd probably need to change the GUID there rather than
> the path under LocalServer32
I found the path, but Regedit will not allow me to edit it, even if I
run it as administrator. :-(
--
Crash
"Patriotism is the last refuge of a scoundrel."
~ Samuel Johnson ~
Mayayana
| run it as administrator. :-(
Vista/7?
I think you can use Takeown and CACLS. I wrote
a program that takes ownership of a file/folder
and then changes permissions. The Windows API
works the same for Registry keys. (I should probably
update the software to do Registry keys, but I haven't
at this point.) I don't know much about Takeown and
CACLS, but my impression is that they are command
line programs to do the equivalent of taking ownership
and then changing permissions.
Another possibility is to log in as a *real* administrator:
I run XP on FAT32. I can't be bothered with all that
permissions nonsense. So I don't know much about
the details of these options.
Dave "Crash" Dummy
Sorry. I should have been more specific. I am running Windows 7 Ultimate
x64. I tried to change permissions within Regedit and was unsuccessful,
even logged on as the "real" administrator. I have changed permissions
elsewhere to make registry changes, but not this time.
This is really only a minor annoyance. I was hoping for a quick fix,
like changing the path without taking a hammer to the operating system.
--
Crash
I always thought Mensa was a Japanese import.
Mayayana
Export the CLSID key and the HKCR\Typelib key
Create a new key HKCR\InternetExplorer32.Application
Set a new CLSID under that key
Edit the REG files to use the new ProgID, CLSID
the 32bit path, and a Typelib value
Re-import the REG files
You'll then end up with a registered object for the
32-bit version of IE.
Dave "Crash" Dummy
A few questions. Why export the whole CLSID (almost 6MB) and TypeLib
key? Why not just create new subkeys? Where do I get CLSID and TypeLib
values?
Incidentally, I think I could use the same TypeLib for both versions:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}]
[HKEY_CLASSES_ROOT\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1]
@="Microsoft Internet Controls"
[HKEY_CLASSES_ROOT\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1\0]
[HKEY_CLASSES_ROOT\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1\0\win32]
@="C:\\Windows\\SysWOW64\\ieframe.dll"
[HKEY_CLASSES_ROOT\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1\0\win64]
@="C:\\Windows\\System32\\ieframe.dll"
[HKEY_CLASSES_ROOT\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1\FLAGS]
@="0"
[HKEY_CLASSES_ROOT\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1\HELPDIR]
@="C:\\Windows\\System32"
Mayayana
|
| A few questions. Why export the whole CLSID (almost 6MB) and TypeLib
| key? Why not just create new subkeys?
I didn't mean HKCR\CLSID. I meant
HKCR\CLSID\{0002DF01-0000-0000-C000-0000000046}\
| Where do I get CLSID and TypeLib values?
As you note below, you shouldn't need to change the
typelib key. (That's kind of neat. Finally there's a purpose
for that "win32" key. :)
For the rest, I created the following by exporting my
HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-000000000046}
key, then going to http://createguid.com to get a new GUID:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{4192C835-1DAC-43B9-B991-740740F5923E}]
@="Internet Explorer(Ver 1.0)"
"AppID"="{4192C835-1DAC-43B9-B991-740740F5923E}"
[HKEY_CLASSES_ROOT\CLSID\{4192C835-1DAC-43B9-B991-740740F5923E}\LocalServer32]
@="\"C:\\Program Files(x86)\\Internet Explorer\\iexplore.exe\""
[HKEY_CLASSES_ROOT\CLSID\{4192C835-1DAC-43B9-B991-740740F5923E}\ProgID]
@="InternetExplorer32.Application.1"
[HKEY_CLASSES_ROOT\CLSID\{4192C835-1DAC-43B9-B991-740740F5923E}\Programmable]
@=""
[HKEY_CLASSES_ROOT\CLSID\{4192C835-1DAC-43B9-B991-740740F5923E}\TypeLib]
@="{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}"
[HKEY_CLASSES_ROOT\CLSID\{4192C835-1DAC-43B9-B991-740740F5923E}\VersionIndependentProgID]
@="InternetExplorer32.Application"
(I'm not certain about the exact syntax of the x86 path.)
The other minimum settings required would be like so:
[HKEY_CLASSES_ROOT\InternetExplorer32.Application]
@="Internet Explorer"
[HKEY_CLASSES_ROOT\InternetExplorer32.Application\CLSID]
@="{4192C835-1DAC-43B9-B991-740740F5923E}"
To create a COM object instance, Windows just needs to know
what to load. It does that for a ProgID by looking up the
CLSID, which then tells it where the library/executable is.
So as long as you have a distinctive ProgID, with a unique
CLSID, and an appropriately filled-out CLSID key/subkeys,
it should work.
My original thought was to change permissions on, and edit,
HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-0000000046}\LocalServer32\
I wonder how this works on Win64. Maybe you have both
LocalServer64 and LocalServer32 subkeys under your
HKCR\CLSID\{0002DF01-0000-0000-C000-0000000046}\
key? If so, then the one called might depend on the calling
process? Does one need WScript32 to load IE32? I don't know.
Anything in-process has to correspond, but I don't know
about out-of-process. (A LocalServer is out-of-process.)
I haven't really done anything with 64-bit. But even if you
already have a LocalServer32 key there's no way to pick
that one that I can see, if the two versions share the same
ProgID, and I see now that even with permission it would
do no good to edit the LocalServer64 path, because a 32-bit
process is not going to look there.
I don't mean to confuse things here. I just don't have a
Win64 Registry to look at, so I'm sort of "thinking out
loud" about how it works.
Dave "Crash" Dummy
> | | A few questions. Why export the whole CLSID (almost 6MB) and
> TypeLib | key? Why not just create new subkeys?
>
> I didn't mean HKCR\CLSID. I meant
> HKCR\CLSID\{0002DF01-0000-0000-C000-0000000046}\
> | Where do I get CLSID and TypeLib values?
>
> As you note below, you shouldn't need to change the typelib key.
> (That's kind of neat. Finally there's a purpose for that "win32" key.
> :)
>
> For the rest, I created the following by exporting my
> HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-000000000046} key,
> then going to http://createguid.com to get a new GUID:
<snipped and copied. Thank you.>
> (I'm not certain about the exact syntax of the x86 path.)
There is a space between "Program Files" and "(x86)"
@="\"C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe\""
> The other minimum settings required would be like so:
>
> [HKEY_CLASSES_ROOT\InternetExplorer32.Application] @="Internet
> Explorer"
>
> [HKEY_CLASSES_ROOT\InternetExplorer32.Application\CLSID]
> @="{4192C835-1DAC-43B9-B991-740740F5923E}"
>
> To create a COM object instance, Windows just needs to know what to
> load. It does that for a ProgID by looking up the CLSID, which then
> tells it where the library/executable is. So as long as you have a
> distinctive ProgID, with a unique CLSID, and an appropriately
> filled-out CLSID key/subkeys, it should work.
>
> My original thought was to change permissions on, and edit,
>
> HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-0000000046}\LocalServer32\
>
That was my thought, too, but I am denied permission to make any changes.
> I wonder how this works on Win64. Maybe you have both LocalServer64
> and LocalServer32 subkeys under your
>
> HKCR\CLSID\{0002DF01-0000-0000-C000-0000000046}\
>
> key?
No. This is what you get:
[HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-000000000046}]
@="Internet Explorer(Ver 1.0)"
[HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-000000000046}\LocalServer32]
@="\"C:\\Program Files\\Internet Explorer\\IEXPLORE.EXE\""
[HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-000000000046}\ProgID]
@="InternetExplorer.Application.1"
[HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-000000000046}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-000000000046}\TypeLib]
@="{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}"
[HKEY_CLASSES_ROOT\CLSID\{0002DF01-0000-0000-C000-000000000046}\VersionIndependentProgID]
@="InternetExplorer.Application"
<snipped>
Okay, the good news is that I was able to install the registry
information and the 32 bit version of IE shows up in Task
Manager>Processes when I run it from a test script. The bad news is that
it doesn't work.
Error: ActiveX component can't create object: InternetExplorer32.Application
--
Crash
Committed to the search for intraterrestrial intelligence.
Mayayana
I'm trying this myself and can't find a variant that
works. I guess that it needs the exact ProgID in order
to initiate the class. That makes sense. I hadn't
thought of it. So I tried putting the normal ProgID
under the new CLSID key, but that doesn't work. It
doesn't check
HKEY_CLASSES_ROOT\CLSID\{4192C835-1DAC-43B9-B991-740740F5923E}\VersionIndependentProgID
presumably because it already has the [fake] ProgID. So
I guess it's trying to load an InternetExplorer32 class
from the lib and of course it's not there.
It seems like this should still work if one could load
from the CLSID, but I don't know any way to do that.
The other way would be to have something else
call LoadLibraryEx directly and return the object.
Such a tool is available, but I don't know of anything
like that that script can use.
There is another way, but it's a hack:
Dim IE, IEPath, SH, ShAp, Wins, Win, Doc
Set SH = CreateObject("WScript.Shell")
IEPath = Chr(34) & "C:\Program Files\Internet Explorer\iexplore.exe" &
Chr(34)
SH.Run IEPath, 0
Set ShAp = CreateObject("Shell.Application")
Set Wins = ShAp.Windows
For Each Win in Wins
If Win.LocationURL = "about:blank" Then
Set IE = Win
Set Doc = Win.Document
Exit For
End If
Next
Set Wins = Nothing
Set ShAp = Nothing
'-- now IE is running and referenced:
IE.visible = True
IE.Left = 0
Doc.Write "eeeee"
'-----------------------------------
That method gets you an IE instance to use, along with
the Doc object. Though there could be a catch in getting
the right window if you have multiple IEs open. And I don't
know whether Win7 restricts the Run method.
Dave "Crash" Dummy
> Sorry, but I'm afraid I might have wasted your time.
Not too worry. I appreciate your time.
<snipped>
You're right. It's a hack. :-)
Shouldn't that be: chr(34) &
"C:\Program Files (x86)\Internet Explorer\iexplore.exe" & chr(34)?
That might work for creating a web page, but in my application I am
navigating to a remote web site:
Set IE = createobject("InternetExplorer.Application")
IE.navigate "http://booneweather.com/Current+Conditions/" & station
and extracting information from the page.
I will fiddle with your hack, but I don't see it filling my need.
Thank you for your extensive efforts. It has been a Learning Experience,
and I think we have learned that the answer to my original question is "NO!"
--
Crash
"It is not necessary to change. Survival is not mandatory."
~ W. Edwards Deming ~
Mayayana
| "C:\Program Files (x86)\Internet Explorer\iexplore.exe" & chr(34)?
|
Yes. I was just testing the script on my own machine.
| That might work for creating a web page, but in my application I am
| navigating to a remote web site:
|
I don't think it should matter. Once you get the window
you have the IE object.
| Thank you for your extensive efforts.
Even though I don't expect to be using Win64 anytime
soon, it's an interesting question that I expect we haven't
heard the last of.