Category Archives: Tools

Another breaking news did hit the Software Packaging market.

Citrix Enters into agreement to acquire App-DNA.

App-DNA will operate as a new product group in the Citrix Desktop and Apps team.

This information has been shared by an info email from Mike Welling from App-DNA.

Read the full story at http://www.citrix.com/English/NE/news/news.asp?newsID=2317537

Somestimes our customers require us to package the software that way that it automatically sets the language according to the Windows UI Language.

Now the big question is, which is the best way to determine the language during a windows installer “transaction”?

Here you are:

dim dezUI,hexUI,language
dezUI = GetUILanguage
hexUI = hex(dezUI)

do while len(hexUI) < 4
	hexUI = "0" + hexUI
loop

If hexUI = "0404" Then
	language = "T_Chinese"

ElseIf hexUI = "0804" Then
	language = "S_Chinese"

Elseif right(hexUI,2) = "07" Then
	language = "german"

Elseif right(hexUI,2) = "09" Then
	language = "english"

Elseif right(hexUI,2) = "0C" Then
	language = "french"

ElseIf hexUI = "0411" Then
	language = "Japanese"

ElseIf hexUI = "0412" Then
	language = "Korean"

ElseIf hexUI = "0416" Then
	language = "B_Portuguese"

Elseif right(hexUI,2) = "0A" Then
	language = "spanish"

Else
	language = "english"

End If

Session.Property("ONTX_LANGUAGE") = language

First we get the “decimal format” of the current UI language. The returned string is e.g 1033 which actually means “English – United States”.

Thats the first challenge: We usually only want to match a language and not a region at all. The next step is to convert that string into a hexdecimal value. And after that we have a value like this ‘409’. This value however must be 16Bit and therefore we add leading zero’s till we have a 4 digit hex value.

Now its quiet simple: the last 2 digits always(*) represent the language and the first 2 digits are for the region.

Examples:

• All english languages end with 09
• All french languages end with 0c
• All german languages end with 07

Bear in Mind: UI Language is a per user setting and you cannot therefore “ask” the operating system for it during a initial installation. this will run in system context and will always return english as language. you can however abuse the self repair or activesetup mechanism to run this script in per user context and then write the corresponding registry key/files.

(*) No rules without exceptions, you should anyway consult the following microsoft article:

Locale IDs Assigned by Microsoft: http://goo.gl/vjjst

(this is an english rewrite of the popular german article “Zusätzliche Special Folders”. However it includes some new findings regarding this topic)

The windows installer technology provides the most frequent needed special folder directory properties out of the box.

However sometimes you need to reference a directory which isnt directly supported (yet).

The following VBScript uses the “Shell.Application” object to get the actual path of the requested special folder. (in our example for “CSIDL_COMMON_DOCUMENTS”)

Insert this action as ““Call VBScript From Embedded Code” Action directly after “CostInitialize” in both “User Interface” and “Execute Immediate”.

Const CSIDL_COMMON_DOCUMENTS = &h2e

Set objShell = CreateObject(“Shell.Application”)

Session.Property(“ONTX_COMMON_DOCUMENTS”) = objShell.Namespace(CSIDL_COMMON_DOCUMENTS).Self.Path

Set objShell = nothing

Afterwards, insert the following line into the directory table:

Bear in mind to add all those properties into the “SecureCustomProperties” Property.

You may use then this property as any other known directory property (eg. SystemFolder, ProgramFilesFolder)

By following the link at the end of the article you will get all known CSIDL’s which can be used for this script.

Continue Reading

Symantec has entered a partnership with Flexera Software, introducing a new solution, “AdminStudio for Symantec”, based on Flexera’s industry leading technology.

Flexera AdminStudio for Symantec includes integration with Symantec technologies and full support for all of the latest Windows operating systems and installation-related technologies, including the ability to capture both 32-bit and 64-bit applications. In addition, AdminStudio Virtualization Pack, an optional add-on pack, offers advanced packaging support for the application virtualization technologies from Microsoft (App-V), VMware (ThinApp) and Citrix (Xen App).

A Wise Package Studio 8.0 maintenance release is planned for late 2011 or early 2012. The release is expected to include critical bug fixes, and 64-bit support for the WiseScript Editor and SetupCapture tools. Flexera plans to add the enhanced WiseScript Editor to AdminStudio for Symantec and will continue to develop and support the tool going forward.

Therefore as of November 7, 2011, all versions of Wise Package Studio and the Wise Connector, including any Maintenance Packs and/or patches for each version, in all released languages will reach their End of Life (EOL).

Please visit www.wise-migration.com for more details!

Regards,

SPA Team

In some rare cases a vendor setup checks for a pending restart.

During setup capture this will bring a lot of junk into a snap-shot, so the question will be, how can I clear a pending restart in order to install the vendor setup without doing a reboot.

The following registry will is the root of the problem. Renaming the key or clear out the value will solve this issue.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetContro lSession ManagerPendingFileRenameOperations

Ever wondered with which version of Wise Package Studio a msi has been built?

For this reason we have setup a comprehensive list of all known Wise Package Studio builds since 6.0:

The Version used to compile the MSI will usually be saved in the “WiseEditorVersion” property:

Symptom

A software package which is non virtual may perform very slow.

Solution / Workaround

Even non-virtual application are being redirected through the SVS/SWV Filesystem Minidriver while at least 1 virtual layer is active on the system.

This may significantly slow down applications with many registry/file system I/O operations. (e.g bad performance at startup)

To work around this issue you can add those application to the SVS Program Ignore list which you may find at the following location:

HKLMSystemAltirisProgramIgnoreList (REG_MULTI_SZ)

However bear in mind that those applications will no longer see any virtualized resources.

Our Ontrex Best Practices series continues with a very underestimated topic.

We are talking about the ProductVersion Property today.  As many of you already may know the property has to be formatted as follows:

major / minor / build 255.255.65535 (Source: http://goo.gl/Dj3l2)

Usually when we are repackaging we try to adapt the original Product Version as good as possible. But Unfortunately sometimes the vendor’s intended product version does not really fit in this schema which causes several problems like

• Not possible to take over the version at all (eg. 2010.10.10) because it simply doesnt fit into the maxium values of 255.255.65535
• They only increment the fourth field which is simply non-existent in Windows Installer
• They add some strange leading zeros into some fields (Why?)

We have now enforced some general guidelines regarding this to encounter any problems which may be caused by those strange vendor habits:

1. We only keep the first three  fields of any original product version (e.g 10.3.181.14 becomes 10.3.181), Major Upgrade is still possible (however limited) but causes an ICE error. Joining 2 fields together is strictly forbidden.
2. Leading zero’s have to be eliminated from any field (e.g 1.09.10 becomes 1.9.10)
3. Any non fitting Product version will be resetted to 1.0.0 (eg. 2010.23.1)

To conclude my blog article i really want to appeal to all developers out there:

Please try to adapt the windows installer product version schema. And avoid, at all costs, having only incremented the fourth field for any reasons. The fourth field should, if present, be used as build number only.

Therefore my recommendation for a versioning schema is as follows:

Major Release(255) . Feature Enhancements (255) .  Bugfixes / Patches (65535) . Build Number (Unrelevant and ignored by Windows Installer anyway)

And, of course, do not use any kind of date for the versioning schema! 🙂

At first most customers insist of keeping the cabinet files inside the Windows Installer Database.

It may sound reasonable for the time being because you have to deal with lesser file count, but if you have a deeper look into the windows installer mechanics you will soon see some big disadvantages.

Its faster!

When deploying/installing/repairing a msi file/installation with multiple cab files it will be much faster than with only one file. Why? Its simple: Only the required cabinet files will be accessed and this results in less file i/o & less traffic (network share)

It will be cached from Windows 7 onwards

As many of you already may know microsoft introduced a new caching behaviour with Windows Installer 5.0.

Due to signing/certification issues cabinet files will no longer be stripped out before being placed into the Windows Installer Cache directory (C:WindowsInstaller).

This results in much more useless occupied disk space by Windows Installer Packages which are mostly cached anyway by the Deployment System.