View Full Version : How I Forced An Install Into Vista

05-04-2007, 03:59 PM
This is going to drive some of the hard core folks that think Microsoft is doing the exact right thing in how and where we can place files.

I do not disagree with Microsoft. If you have a perfect world, the latest tools, and fully trained developers, and tons of time, it is a good approach. But, not everyone does.

I realize that this is not the right way to make the installs happen. But, considering there was going to be no major change in our applications to work in the Vista world, including manifest files, I was told to make it happen.

I know I broke some rules, but, considering Microsoft’s restrictions, extremely poor support from Macrovision, and a lack of support for anywhere in regards to how to make it happen, I decided to make it happen. I am sure there are many other ways to make this happen, I just took what I found that would work.

With that said, here is what I had to do.

I have to build installs for about 10 legacy applications that use that old Borland Database Engine. Yes, I know it is old, and should be replaced. We are doing that, but, it takes time. Between Microsoft forcing the issue with Vista, and Macrovision’s poor attempt at providing Express users with supposed Vista compatible installation tools, I have been forced to get very creative to meet deadlines. Some of our applications run on single local desktops, and some are in domains. Some are local, and some are on client server as well as peer to peer networks.

I am installing and customizing BDE, and placing applications and data in the traditional “program files” folder, and subfolders. Here is what I do.

On Summary Information, Require Administrative Privileges is Yes

On Windows Installer 4 Properties, Create MSI Logs is Yes

On Specify Application Data, Files

I place about 15 different folder and subfolders in [ProgramFilesFolder], including the data folder for the application. On every folder I have modified the permissions, by adding the users Users, and Everyone. Then turned on all permissions for these 2 users.

In Files and Features, Redistributables, and Dependencies. BDE and all other redistributables are handled the way they always have been

Now for some fun stuff. To find out what was broke, and where it was broke, I downloaded and setup Microsoft Application Compatibility Toolkit 5.0. I also setup Microsoft Virtual PC 2007, with virtual machines for XP Pro, 2000 Pro, Vista, and 98SE.

With these tools, I would create installs, and run them again and again in a clean test environment. Find out where the problems were, and walk through it. Every time I knocked down one wall, I found another. (Do not forget each custom action can be setup to run on whatever operating systems you need it on)

I created a mitigation that forced BDE Administrator to run as administrator, and executed this as custom action 1.

I created another mitigation that forced every executable I was placing on the system to run as administrator, and executed this as custom action 2.

Discovered I had to create a default idapi32.cfg file, and place it in the [supportdir]. Then I executed the following as custom action 3:

filecopy idapi32.cfg c:\progra~1\common~1\borlan~1\bde\idapi32.cfg

Discovered the following 2 users needed full control of the idapi32.cfg file: Users and Everyone. I placed cacls in the [supportdir]. Then I executed the following as custom action 4:

cacls "c:\program files\common files\borland shared\bde\idapi32.cfg" /E /C /G Everyone:f

Then I executed the following as custom action 5:

cacls "c:\program files\common files\borland shared\bde\idapi32.cfg" /E /C /G Users:f

Now, I wanted to be sure my users had full control of my application.

Then I executed the following as custom action 6:

cacls "c:\program files\my application" /T /E /C /G Everyone:f

Then I executed the following as custom action 7:

cacls "c:\program files\my application" /T /E /C /G Users:f

Now, how to deal with the restrictions on HKLM

Then I executed the following as custom action 8:

setacl.exe -on "hklm\software\borland" -ot reg -actn ace -ace "n:Users;p:full"

Then I executed the following as custom action 9:

setacl.exe -on "hklm\software\borland" -ot reg -actn ace -ace "n:Everyone;p:full"

On Prepare for Release, Build Your Release, Single Image
Required Execution Level is Administrator
Location for Copying Media is [LocalAppDataFolder]

In summary, I can install this application as new or an upgrade in Vista, XP, 2000,
9x. My Vista users are required to be Administrators to use the application. I am not replicating these same steps to all of our applications, while I wait for the developers to get caught up, and the applications re-coded!

There is no guarantee this will work for you, but, it will be very close. You can handle it from there with some of the ideas I have planted.

Now, the hard cores can beat me to death. But, some of you like me, might be able to get it done now.

08-27-2007, 05:48 PM
You mentioned that custom actions 6 and 7 are:

cacls "c:\program files\my application" /T /E /C /G Everyone:f
cacls "c:\program files\my application" /T /E /C /G Users:f

These should be able to be combined into one command:

cacls "c:\program files\my application" /T /E /C /G Everyone:f Users:f

Also, a caution I found when doing something similar (I'm using ISXv4):
The [DATABASEDIR] always ends with a "\", resulting in a command like:

cacls "c:\ProgramData\my application\" /T /E /C /G Everyone:f Users:f

... which fails. I found a good solution by using the "." directory entry, like this:
Location: [SystemFolder]
File & command: cacls "[DATABASEDIR]." /T /E /C /G Everyone:F Users:F Administrators:F

Which extrapolates to:
C:\Windows\System32\cacls "c:\ProgramData\my application\." /T /E /C /G Everyone:F Users:F Administrators:F

and this DOES work on my testing on Vista!!