Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrade.
Please accept our apologies in advance for any inconvenience this might cause.

Core runtimes to include in a new operating system build

Created: 16 Jul 2010 • Updated: 16 Feb 2012
EdT's picture
0 0 Votes
Login to vote

In order to make the corporate application packaging process as straightforward as possible, it is important to engage with the operating system build architects so that the standard user platform contains all the core runtimes that otherwise have to be packaged and deployed separately.
Here is my standard list, and I would invite contributions from other forum members as to anything I have missed that you consider should be in the list.

Adobe Reader
Adobe Flash
Adobe Shockwave
Adobe Air
Microsoft Silverlight
Microsoft Windows Media Player (Latest version)
Latest Sun Java Runtime  (32 bit and 64 bit if appropriate)
Installshield ISScript.MSI runtimes 7, 8, 9, 10, 10.5, 11, 11.5
Microsoft Visual C++ runtimes 2005, 2008, 2010
MSXML runtimes V3 V4 and V6 at latest service pack levels
Latest Microsoft DirectX runtime  (check compatibility with video systems supported)
All available Microsoft .NET frameworks (inc V4) and service packs/updates
Microsoft Windows Installer 3.x (if not already present in service packs) or higher depending on O/S
Microsoft Windows Update Agent ( (32 bit and 64 bit if appropriate)
Microsoft Visio Viewer 2010
Microsoft Primary Interop Assembly 2005
Microsoft Office Primary Interoperability Assemblies 2003 and 2007
Latest MSN messenger if appropriate
Winzip client if site license available
A/V client with Antispyware if available
Notepad++  (free and much better than Notepad)
Apple iTunes/Quicktime (if appropriate)

If your company is using any other development platforms, and there are runtimes or redistributables associated with these platforms, then these should be included as well, unless there are cost implications which preclude site-wide deployment.

There is also a strong argument to include a utilities folder on a build as well. MSI technology does not handle permissioning very well, so a selection of permissioning utilities can be placed in a utilities folder to avoid having to deploy them from your packages.  The utilities folder can be given permissions and attributes that make it invisible to standard users.

Typical utilities I would place in my folder would include:

xcacls.vbs  (not the exe as it has various problems well documented on google)

No doubt there are many more candidates for the Utilities folder, including home grown apps, so again, suggestions for this folder are welcomed.