Vista - Shockwave and Flash on 64-bit Vista Service Pack 2

Fresh off a brand-spanking Vista SP1 install, an SP2 install, and an install of 64-bit Firefocks (Shiretoko 3.5 Beta 4), I am going to now try and install Shockwave and see if it works with my 64-bit Firefox and IE8 browsers.

If the ordinary install routine doesn't make the Flash content show up on the test page then I'm going to try this suggested method from the Techarena Forums.

From the people at Adobe Labs:

  Quote: Originally Posted by Adobe Labs (click on this box to Hyperlink there)

Release versions of Flash Player 10 for Windows, Macintosh, and Linux are now available from the Flash Player Download Center.

We get leftovers for dinner again.


Oh, well. I'm going to see if the Shockwave jerry-rigging works in SP2 and if it does or doesn't I'll edit this post. The method recommends doing Shockwave first. I'm installing V 11.5.0.596 of Shockwave. I'll be using IE 64-bit to do it.


And then I'll try jerry-rigging Flash and report back. I'll be installing V 10.0.22.87.

Weird.

In IE8 the install prompt came up both on this page here and this page here as well as the test page, and then I pressed the "Install" button and three things happened:

1) Shockave didn't install;
2) an application called NETWORK FLYOUT appeared and then disappeared quickly from Task Manager;
and 3) now my Adobe Reader 8 software shows up in Add/Remove Programs (which it didn't before though I didn't notice until now).

There is no report in Control Panel's "Problem Reports and Solutions," so something registry-wise happened but nothing got installed, it looks like.

I'm going to Disk Cleanup, reboot, and try with Firefox/Shiretoko. It's my primary browser, anyway.

Shockwave successfully installed using Firefox:

Output folder: C:\Windows\system32
Skipped: msvcp71.dll
Skipped: msvcr71.dll
Skipped: msvcrt.dll
Output folder: C:\Windows\system32\Adobe
Output folder: C:\Windows\system32\Adobe\Director
Extract: M5drvr32.exe
Extract: M5if32.dll
Extract: SwDir.dll
Extract: np32dsw.dll
Output folder: C:\Windows\system32\Adobe
Output folder: C:\Windows\system32\Adobe\Shockwave 11
Extract: Control.dll
Extract: DynaPlayer.dll
Extract: Plugin.dll
Extract: Proj.dll
Extract: SYMCCHECKER.DLL
Extract: SwHelper_1150596.exe
Extract: SwInit.exe
Extract: SwLogo.bmp
Extract: SwMenu.dll
Extract: dirapi.dll
Extract: gi.dll
Extract: gt.exe
Extract: gtapi.dll
Extract: iml32.dll
Extract: shockwave_Projector_Loader.dcr
Output folder: C:\Windows\system32\Adobe\Shockwave 11\Xtras
Extract: CBrowser.x32
Extract: INetURL.x32
Extract: Multiusr.x32
Extract: Netfile.x32
Extract: Netlingo.x32
Extract: Speech.x32
Extract: autodownload.txt
Output folder: C:\Windows\system32\Adobe
Created uninstaller: C:\Windows\system32\Adobe\Shockwave 11\uninstaller.exe
Registering: C:\Windows\system32\Adobe\Director\SwDir.dll
Execute: C:\Windows\system32\Adobe\Shockwave 11\SwHelper_1150596.exe /regserver
Successfully Completed

Take note that it says it installed the files that it didn't skip (some were already installed in my CyberCam software suite) in C:\Windows\system32. It didn't; it's lying. It actually installed its files in C:\WINDOWS\SysWOW64, in 2 directories, "Director" and "Shockwave 11."

And Shockwave tests null in both Firefox and IE8 64-bit versions. Shockwave does, however, work in 32-bit IE.

Now... how to make it work in Firefox and IE. Hmmm...

I'm wondering...

if I reversed my install and went "back in (System Restored) time" and then installed Shockwave brand-new using IE8 32-bit instead of 64-bit Firefocks, would the files have installed into the same folders?

I am going to cook dinner, eat dinner, and then fly back in time and reinstall.

EDIT: I tried it with IE 32-bit, which works btw. It saved the .dll's in the same location.

I simply copied all the DLLs and Shockwave programs that were installed in those other folders and pasted them into the Firefox folder Plugins (except for gt.exe which is just an installation program for Google Toolbar). So, two copies of all those files reside on my computer now.

Firefox recognized the existence of Shockwave immediately when it started up; it is now the only other plugin except for the Default and it can be Enabled and Disabled like a plugin.

Browsing to Adobe's Shockwave and Flash test page brings up a plain, empty field where a picture used to be saying 'you need yo'self some Shockwave, son' or something like that. So, something happened. However, there's no Shockwave thingie, the wave-looking thing that's supposed to come up.

ExploreLearning's test page says that Shockwave is "installed and enabled." However, no test animation shows.

I'm going to try the same thing with the latest Flash (V 10.0.22.87) and see if that does the same thing to the browser: show an enabled plugin yet not work completely.

Okay. After some playing around, I have the order you should install Flash into your system if you want Flash capabilities for more than one browser. Firefox or Opera should definitely go first, and then IE should come last. The reason why is because, though the Shockwave installs for both IE and Firefox are really alike, with much the same files, the Flash install for IE is way different than then one for Firefox.

Moreover, when you install the Firefox Flash, the install doesn't write anything to registry about the location of the files the uninstall program is supposed to look for; the program is probably just programmed to look only in folder the program itself is in. This makes the files portable, and you should move them to your 64-bit Firefox "Plugin" folder in its "Program Files" folder, anyway, because that's where they're supposed to go, anyway.

IE Plugins, on the other hand, they go wherever, and that's not a good thing. Check this out; the IE 32-bit Flash install went into the C:\WINDOWS\SysWOW64 folder! and like the Shockwave install mentioned above it claims the output folder as C:\Windows\system32\Macromed\Flash! Liar! Plus, now there's a registry entry pointing to Flash.

So, an IE Shockwave install should be done last, behind other browsers' Shockwave installs; and then after that the IE Flash install should also be done last, behind other browsers' Flash installs.

And, yet...

The 32-bit IE Shockwave and Flash actually work, while my 64-bit Firefox (Shiretoko 3.5 Beta 4) recognizes both Flash 10.0 r22 and Shockwave 11.5.0.596 as Plugins yet here on the Adobe Shockwave/Flash test page all I see are two white spaces where there used to be "get yo'self some Adobe, homeboy."

Hmmph... there's gotta be a way to force those two Plugins to show on the page! They're obviously there, as in: the browser knows they're there!

Hi there,

I think there's a big misconception and lack of understanding here. You're venture is quite in vain in case you're trying to "port" the x86 Shockwave/Flash to x64.

No, it is NOT lying! This has to do with WoW64 and folder/file virtualization or redirection. A 32-bit process knows nothing about the x64 world and is "tricked" to think that:

• %systemroot%\syswow64 actually was %systemroot%\system32
• %ProgramFiles% not expands to "C:\Program Files" but "C:\Program Files (x86)"
• HKEY_LOCAL_MACHINE\Software\Wow6432Node actually was HKEY_LOCAL_MACHINE\Software

From the perspective of the 32-bit process/programm it only "sees" \system32 or HKM\Software or the like. It's some kind of "sandbox", like some 32-bit subsystem.

It's like your parents would have told you that your room was painted green, whereas all other people would see/know that the color actually is blue :-)

There is another reason for this stuff going on - binary compatibility! As you might know, Windows programs are usually split in the programs itself (.EXE) and various libraries (.DLL, .OCX, ...). Browser-ActiveX-plugins (.OCX) are like libraries as well. Libraries help to re-use code (you write a lib once and use it for many products) and reduce size. They make things modular and maintainable. But there is also the "DLL hell" which is a totally different story, together with side-by-side assemblies, but that's not the point here.

WoW64 rules are:

App | Lib | allowed
----------------------
x86 | x86 | yes
x64 | x64 | yes
x86 | x64 | NO
x64 | x86 | NO

This is totally logical, you can't mix binaries of different architecture! A x86 process can't handle x64 DLLs and vice versa! This is just impossible in regard to machine code, width of memory registers and CPU execution mode.

The only thing what x86 processes might do is use APIs for indirect hardware access (and hardware is solely supported by 64-bit drivers) - but as they use the 32-bit DLLs of the API provided by Windows, everything is in order. But you can't mix architecture in the same process space.

As a result, you will never be able to load any 32-bit OCX into IE8 x64! It is just impossible. The compatibility statement of the manufacturers like Adobe ("compatible with Vista") usually just means "compatible with the x86 subsystem".

Adobe and the like would have to write own, specifically compiled x64 plugins in order to support/work with IE x64! But even the big companies are usually lazy and they say, the number of x64 computers is just negligible - and people can still use their IE x86 and WMP x86 under Vista x64 anyway, so why care?

Microsoft did very well with their 32-bit subsys and separation from Vista x64 onwards. They knew the problems that would arise with 3rd party manufacturers and included IE x86 and WMP x86 and made them default!

So copying around from SysWow64\Macromed to System32\Macromed is pointless and even dangerous especially when starting to copy from root to root (SysWow64 to System32 or vice versa)!

Attention: I know the Shockwave 10 install issue! And I know that you have to copy the gi.dll or like that from SysWow64\Macromed to System32\Macromed - but this is just because the installer, even though 32-bit, behaves so badly it "breaks free" of redirection and manages to access the real C:\windows\system32 instead of Syswow64 - which it actually should see. But that still doesn't change the fact that we're talking about a x86 process here looking in the wrong folder for another x86 DLL in order to install - which still fulfills the rules set up above.

But putting x86 DLLs/OCXs into System32\Macromed and thinking IE 7/8 x64 will load them is an illusion.
(Btw you would also have to check HKLM\Software\Classes in addition to HKLM\Software\Wow6432Node\Classes, just copying would never suffice for an OCX; let alone that we would actually use something like regsvr32 which in turn adheres to the same binary architecture rules ... But COM and CLSIDs is a whole other story for itself)

http://en.wikipedia.org/wiki/WOW64
http://support.microsoft.com/kb/896456/en-us

Know your x64 systems architecture! And tell the manufacturers you want REAL x64 software! So say we all ;-)

Regards,

Markus