Since Microsoft did bring the Public User folder to its operating system a Software Developer has officially two locations available to install
files for all users for editing pruposes. But there is one big difference that will make one of them obsolete for the future.

First Location – Old school location %ALLUSERSPROFILE%

Default Location: C:ProgramData<Vendor><Product>

Second Location – The youngest %PUBLIC% location

Also konwn as CSIDL_COMMON_DOCUMENTS
Default Location: C:UsresPublic<Vendor><Product>

The Big Difference since Windows Vista

An application is usualy executed with standard user rights, therefore the Program Files folder is not a location to creating or modifying files.
In fact the Public and All Users folders are used when a central location for create/modify files aktion for an application is needed. 

But did you know that files created in All Users folder can not be modified by a second user? That’s right you can test it easily by creating a file in All Users folder and then try it to modify it with another user account with standard user rights – it will not be possible to overwrite it because only the creator/owner of the file has change/full rights. In fact this is not  well known, as all users will be able to create new files, but modifying a file with another user account is not possible.

How ever this behaviour is valid for Windows Vista and newer Windows Operating systems but not for Windows XP. In Windows XP there is no location available that would make it possible to modify a file for all users. In Windows XP you have to use a tool like SetACL.exe or using Flexera InstallShield – Application Data – Files and folders View

In Files and Folders view you can edit the permissions for Files and Folder. The following setting will make it possible that all ‘Users’ will be able to modify the files in All Users location.

When using InstallShield Editor make sure that Locked-Down Permissions are set to Custom InstallShield handling:

The Public folder instead will also allow you to modify the files created by other users, and this fact will make the All Users folder obsolete for the future. If you are a software developer, the public folder will be your preferred location for files that needs to be modified by all users without modifying the operating systems standard security settings.

Regards,

SPA Team

Google Updater (Omaha) is a background program/service which keeps all installed Google products up to date. 

The Google Updater can be disabled for all Google Products by adding 2 Registry Keys:

If you want to deactivate the Google Updater for a specific Google product, use the following Registry Key:

The GUIDs can be found in the following table:

The GUIDs may change in the future. Keep yourself up to date by downloading the current ADM File which contains the corresponding GUIDs: Download.

Regards,

SPA Team

A side effect of Windows Installer Entry-Points can cause the Windows Installer to repair an application that was not even target to be run from the launched process.

If the event log shows a warning about an application that has not been launched then this article could bring some light into the dark.

A ghost repair will be started by a process that in general uses a com object like an activex object.
The binary file of this object has been installed by a windows installer based setup (MSI).
In this article I did decide to show a ghost repair based on the following windows scripting host file:

The following diagram explains in short the ghost repair in a simple way:

1. A process will call a com object in this case it’s a windows scripting host file
2.  cscript.exe is executing an activex object
3. The Dll-Loader will now handle the registry read request to inizialize the ocx or dll file
4. In the registry the HotInstaller.HotCom Programmatic Identifier will be read in order to get it’s CLASS ID
5. In the registry the InprocServer32 will be read from the related CLASS ID
6. The Dll-Loader process is detecting an InprocServer32 value in InprocServer32 Key that holds a DarwinDescriptor
7. The DarwinDescriptor holds Windows Installer Details: ProductID, Feature that Installed this file, ComponentCode
8. Enumerates all related Windows Installer Features (Feature in DarwinDescriptor and all it’s parent Features) and checks all compontents key-pahts of the enumerated features for it’s existance
9. If a key path is missing, the ghost repair will repair the product that was hold in the DarwinDescriptor.
10. If everything is fine, the Key-Path of the component found in the DarwinDescriptor will be loaded into the memory
11 and 12. cscript.exe is using the activex object that is now available in the memory

Some technical details

Point 6. where the DLL-Loader detects the darwin descriptor – this value will be genereated by using the Class table:

After running the setup, the class entry will show an additional key with the name InprocServer32 and it’s value will hold ProductCode, Feature and ComponentCode from the Windows Installer based setup.

Point 8 – checks component key paths for it existence – this is the point where the Setup Design of the installed product will cause the ghost repair. In most cases it’s the combination of Current User Registry Keys and a shared component based on COM technology. Installations where ressources in a flat feature structure are installed will cause a ghost repair because all key paths of the target feature and parent features will be checked for its existance. If one key path is missing, the windows installer will start a self repair process.

This is a simple flat feature setup desing that is able to cause a ghost repair.

How to fix the ghost repair issue:

There are muliple ways to fix this issue.

The most common way to fix this issue is to enhance the setup design with shared component awareness. Separate the shared components into a new root feature.

Another way would be to delete the darwin descriptor from each operating system that is target of the issue.

1. Deleting the InprocServer32 key with the darwin descriptor value will 2. fallback the DLL-Loader to the standard initialisation way without windows installer technology

This may only be a workaround, as a repair or reinstallation of the product will recreate the darwin descriptor.

for those who have missed the Ontrex user group meeting we are able to provide you with the slides of our presentation about windows 8 (however only available in german slides):

Continue Reading

We are glad to hear about the general availability of APP-V 5.0 RTM.

The Ontrex SPA is already prepared for this major upgrade and is happy to be able to offer you various services regarding APP-V 5.0 which includes but is not limited to:

Migration Services (from earlier APP-V Versions), Consulting Services, Trainings and of course our matchless software packaging services.

Source: App-V 5.0 RTM now released!

Today i want to take care of some very frequent traps regarding x86/x64.

Runtimes 

The question is usually very simple: Which runtime architecture do i have to preinstall for my X86 Application on a Windows x64 Operating System?

For those who dont know what runtimes are ill give some examples:

• Microsoft Visual C++ 2008 Redistributable
• Microsoft SQL Server 2008 Native Client
• Microsoft Core XML Service 6

Short answer: Usually you must match the applications architecture not the operating system ones!

But the exception proves the rule. Lets examine: “Microsoft SQL Server 2008 Native Client”:

When you actually try to install the x86 runtime on a windows x64 it will simply block the installation.

But why? i think microsoft wants to stop those confusing situation by creating packages which simply match the OS Architecture. So people dont have to care about the applications architecture.

Because if you look inside the x64 MSI you will see the following:

As you can see the x64 Installer also contains the x86 version of the SQL Native Client.

ODBC Data Sources  / Drivers

Another nightmare which leads to many inquires from our customers.

ODBC Data Sources & Drivers are seperate for each Architecture due to the Registry Redirection mechanism of “Windows on Windows64” (WOW64).

X86 Applications need x86 Data Sources / Drivers and x64 Applications need x64 Data Sources / Drivers.

In our opinion the biggest mistake microsoft has done is just to link to the x64 ODBC Administrator in the Control Panel despite the fact that the application landscape is still mostly x86.

To open you the x86 ODBC Administrator you must manually run:

C:WindowsSysWOW64odbcad32.exe

Those entries will be used for native x86 application. Bear that in mind.

Regards,
Fabio