The overall goal is to isolate our flash based application from the version of flash installed on the windows system. This allows us to regression test our application with a particular version of flash independent of version of flash pushed out to client desktops by IT departments.
To accomplish this, we generate an executable using the Adobe AIR SDK and install on client desktops. This package includes a particular version of the flash DLL. So far so good (with the exception that the packaging of the flash DLL. in the AIR SDK changed
Re: File Size Of NPSWF32.dll In Adobe AirSDK ). I was able to swap out that DLL that was packaged with the full version and that appears to be working as desired.
Now we are investigating some communication issues that happen different between the application in Adobe AIR and Internet Explorer. So I was trying to see what differences might be and how to make changes to the configuration of the flash environment in the Adobe AIR container. The one I was investigating in particular was:
NetworkRequestTimeout=30
But the change never gets picked up.
About isolating the Flash Player distributed with Adobe AIR from the Flash Player installed on the system:
- You can isolate the runtime the same way you can have different Flash Player versions
installed under different browsers - but you can not isolate the mm.cfg / mms.cfg configurations which apply to all Flash Players whatever their origins
- also since Adobe AIR v22 you have this new feature
"System level Flash Player support for AIR desktop applications" which is described as
| Starting in AIR 22, applications that play swf content via the HTML control (WebKit) will now load the system level NPAPI Flash Player provided by Adobe. If this plugin is not available on the system, the end user will be prompted to download and install the plugin from Adobe. |
You're saying you are monkey patching the NPSWF32.dll , my guess is you do that so you can keep distributing your own Flash Player from within Adobe AIR, but still even with that, this "custom" Flash Player will use the system configuration files.
The only straightforward way to provide and apply your own mms.cfg is to provide a Windows installer for your Adobe AIR,
that will probably require administrator credentials to be installed.
see Generating a Windows installer for your AIR captive runtime application
the AIR app will be installed in its own directory
and you will need to script the installer to instal your own mms.cfg
into either %WINDIR%\System32\Macromed\Flash
or %WINDIR%\SysWow64\Macromed\Flash, or other path depending of WIN7, WIN8, WIn10, etc.
Also note that whatever options you enable/disable in this mms.cfg will be applied globally to the system,
some IT departments may not like that and not allow it.
Alternative 1:
The Adobe Flash Player Administration Guide for Flash Player 24 indicate that for Google Chrome the location of mms.cfg is different and under %USERNAME%/AppData/Local/Google/Chrome/User Data/Default/Pepper Data/Shockwave Flash/System
You could install an HTML page running a SWF in kiosk mode under a specific USERNAME (to isolate it) and override that "different" mms.cfg, the config would not apply system wide to other browsers, only to Google Chrome.
In the same logic you could install an Electron app (which reuse Google Chrome),
provide your own Flash Player DLL, see Using Pepper Flash Plugin and your own mms.cfg in the application path
app.getPath('appData') /electron-app/Pepper Data/Shockwave Flash/System/ |
In both case, you would have to use the PPAPI Flash Player plugin, and not the NPAPI.
Alternative 2:
You could embed the NPAPI Flash Player ActiveX into its own executable in C++/C# etc.
From the executable you could probably override the %WINDIR% environment variable
and so put your own mms.cfg file into a "custom" directory without affecting the whole system with those changes.
In all cases, you would need to provide a Windows installer, at this point you could see it is a bit useless and risky
to patch your own NPSWF32.dll, just install the Flash Player you want from your installer it's imho safer and simpler,
look into the admin guide for such tools as uninstall_flash_player.exe if you need to uninstall a previously installed version, any installer will be able embed this exe and run it during the installation process.
There is also the "obvious" option to simply port your SWF app to an AIR app or some part of it,
so instead of using the mms.cfg property NetworkRequestTimeout you could use instead
URLRequestDefaults.idleTimeout see the documentation and being an AIR app you would
then have full control on the update process and not be dependent on AutoUpdateDisable.
AdChoices