[wpkg-users] MSIs, install paths and different architectures

[Stefan Pendl]

Am 05.12.2011 18:29, schrieb Steve Kersley:
> This is probably more of a 'share the frustration' post than anything specifically wpkg-related, but very keen to hear if anyone has a workaround?
>
> I have an application (Samsung MagicInfo Premium Authoring tool - the user tools for our digital signage system) that needs to be installed in the same folder on each machine as the data files that it creates contain hardcoded paths to content files stored in the local install directories.  If you open these files on a different architecture to the machine that created them, the files aren't in the same place ("Program Files" vs "Program Files (x86)") so won't open correctly.
>
> Most of our PCs are currently running x86, but a couple of us (myself included, and I'm the one who creates the initial content template and then hands off to other people to maintain and edit) are running x64 and the intention is that in future staff PCs will be replaced/migrated from XP to Windows 7 x64.
>
> I have extracted the MSI from the InstallShield installation source, and it does support the INSTALLDIR property via the msiexec command line.  However, Windows is being too clever.  It will let me install to c:\foo, but if I tell it to install to c:\Program Files\foo, it silently modifies that so that it installs to c:\Program Files (x86)\foo instead.
>
> Is there any way to forcibly install a 32-bit app into c:\Program Files on an x64 machine?
>
> Is the only option going to be the slightly messy approach to install to a new directory in the root of c:?  That will mean having to modify the existing data files that have already been authored, but will only have to be done once, before we create too many more.
>
> I have also considered creating a symlink or junction within \Program Files to point to the subdirectory in \Program Files (x86) - that works in that it would allow a data file created on an x86 machine to be opened on an x64 machine but still won't work the other way round unless I create an unnecessary "Program Files (x86)" directory tree on all of the x86 machines too.
>
> Has anyone dealt with a similar problem?  I think the fault is largely with the application, but really it would have made more sense if Windows always used the same standard path for existing 32-bit apps which may or may not be aware of architecture issues, and created a new path for 64-bit apps which would always have been expecting to be 'special' and architecture-aware.  But that's a rant for another occasion.
>

As I see it the "Program Files" folder contains the native applications, 
which means 32-bit for x86 and 64-bit for AMD64.

If you need a consistent path and since it seems the application is 
saving data files to the installation folder, you should install into 
the root folder like "C:\MyApp".
This would allow the application to work properly and you to use default 
settings files.


--
Stefan P.

Top-posting:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?