Hello

My app installs and runs on XP, and Vista, even when Vista UAC is turned on. The config file is located in {commonappdata}\CompanyName, where {commonappdata} resolves to C:\ProgramData in Vista & Win 7, and C:\Documents and settings\All users\Application data\ in XP. The database is in {commonappdata}\CompanyName\Database.

In Vista (not XP), if I fail to share the local folder in {commonappdata}\CompanyName, then my app won't run under UAC, whether or not the computer is the server or configured as a workstation. The problem is that the local CompanyName.ini file cannot be read, so it doesn't know where to find the config file.

I have Inno setup share the folder at creation time; the share is created in Win 7 with the same arguments.

The installer creates the CompanyName.ini file in {commonappdata}\CompanyName, then a database installer app either creates a new database, migrates an existing DBISAM database, or points the app's EDBEngine to the database on the server, by editing the local CompanyName.ini file.

When a user opens my app, they start a loader app first that checks for the presence of certain elements in the database, checks the version of the main app against any downloaded upgrades etc, then opens the main app.

The loader app and the main app use identical code to read from the local {commonappdata}\CompanyName\CompanyName.ini file, and identical code to get the path to that ini using CSIDL_COMMON_APPDATA.

There is no problem in XP or Vista, but when Win 7 is running as a workstation the CompanyName.ini file is not read by the loader, which then pops open an EDB password dialog to which there is no right answer, but after the EDB dialog is closed the main app starts up Ok!

Both apps have the same Manifest, with TrustInfo details.

I'm concerned that Win 7 virtualisation has kept an original copy of the ini file, as the default value that is loaded by Inno is the path that the loader tries to use. The ini file that I can open has a UNC path to another machine in the config file path. I even changed the default value in the ini reading method...
Result := myIni.ReadString('Database', 'EngConfigPath', 'rubbish');
...but the local app always reads the value that Inno wrote to that string, not 'rubbish', and when I examine the ini, that value is the UNC path.

Has anyone seen or heard of this mysterious situation?

Regards & thanks for reading all this

Peter

Peter,

Can't really help with the specific issue you're seeing but I've often found the SysInternals Process Monitor utility invaluable in tracking down what exactly takes place.

It can log all your app file and registry access - just filter on the loader utility and see what it tries to open and from where.

http://technet.microsoft.com/en-ca/sysinternals/bb896645.aspx

Raul

Raul

Thanks for your help, I have used that tool as a result of your suggestion but I haven't worked out exactly what the problem is yet.

In the meantime, the simple fix is to tell Win 7 to run the loader app in 'XP compatibility' mode.

I wish I could see how to do that programmatically....

Regards

Peter

The compatibility values are stored here in registry :
(for user)
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
(system-wide)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

Entry is a REG_SZ with value as path to your executable and data being compatibility level (e.g. WINXPSP3).

I don't recommend using this - I still your issue is virtualization - but as a last resort you could update the values here during install and thus make sure your apps run in compatibility mode after.

Raul

Peter,

<< I'm concerned that Win 7 virtualisation has kept an original copy of the
ini file, as the default value that is loaded by Inno is the path that the
loader tries to use. The ini file that I can open has a UNC path to another
machine in the config file path. I even changed the default value in the ini
reading method...
Result := myIni.ReadString('Database', 'EngConfigPath', 'rubbish');
...but the local app always reads the value that Inno wrote to that string,
not 'rubbish', and when I examine the ini, that value is the UNC path. >>

I'm having a hard time parsing the above description.  Perhaps you could
break down exactly what steps you're taking with Inno Setup, including what
Inno Setup is writing to the .ini ?

Also, are you running the setup program as an Administrator ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Raul wrote:

<<I don't recommend using this - I still your issue is virtualization - but as a last resort you could update the values here during install and thus make sure your apps run in compatibility mode after.>>

I'm still trying to find out why the loader is treated differently than the main app, but the reason isn't obvious to me. Yet.

I cannot find another ini of the same name on the Win 7 system, but I'll install Agent Ransack & see if it reveals something.

Thanks again

Peter

Tim

Inno puts the loader app, main app & 6 utilities, ReadMe.txt, and a chm help file in {pf} (Program files), then creates folders under {commonappdata}\CompanyName and puts the csv files from which I import data into the as yet uncreated tables. There is also a sub-folder under {commonappdata}\CompanyName into which some java Jar, ini, and dlls go.

It creates the folders that EDB uses later as Stores, which I do because I want to set the uninsneveruninstall flag. Too many users un-installed all their data as part of an upgrade in the past! I also create a share for the {commonappdata}\CompanyName folder.

The script also has...

PrivilegesRequired=admin

[INI]
Filename: {commonappdata}\CompanyName\CompanyName.ini; Section: Database; Key: IsRemote; String: 0; Flags: createkeyifdoesntexist
Filename: {commonappdata}\CompanyName\CompanyName.ini; Section: Database; Key: ApplicationPath; String: {app}; Flags: createkeyifdoesntexist
Filename: {commonappdata}\CompanyName\CompanyName.ini; Section: Database; Key: EngConfigPath; String: {commonappdata}\CompanyName\; Flags: createkeyifdoesntexist
Filename: {commonappdata}\CompanyName\CompanyName.ini; Section: Database; Key: UseTrainingData; String: False; Flags: createkeyifdoesntexist; Tasks: ; Languages:

I hope that this is helpful. and thanks for reading

Peter

Tim & Raul

The problem appears to be an ini file left over from an earlier installation.

I used the Process Monitor that Raul suggested, and I could see where the loader was first opening the correct ini, but then on the next line opening the virtualised ini.

CreateFile : C:\ProgramData\CompuDoc8\CompuDoc8.ini to which the response was REPARSE.

Date & Time:   9/04/2010 3:11:13 PM
Event Class:   File System
Operation:   CreateFile
Result:   REPARSE
Path:   C:\ProgramData\Company\Company.ini
TID:   5540
Duration:   0.0087289
Desired Access:   Generic Read
Disposition:   Open
Options:   Synchronous IO Non-Alert, Non-Directory File
Attributes:   n/a
ShareMode:   Read, Write, Delete
AllocationSize:   n/a
OpenResult:   Superseded

So it then looked somewhere else
CreateFile : C:\Users\Greg\AppData\Local\VirtualStore\ProgramData\Company\Company.ini

..and found it, read out the incorrect value from the EDBConfigPath, and hit me with an EDB Remote login dialog.

I deleted the path in the EDBConfigPath in the ...VirtualStore\ProgramData\Company\Company.ini and ran the loader, without compatibility, and it ran as it should.

Reasoning that the ini must be left over from an old test, I deleted the whole folder, uninstalled the app, ran the installer again & this time it didn't put anything in the ...VirtualStore\ProgramData\ folder, and all went well.

One day I'll worry about the logic behind it....

Thanks

Peter

Peter,

<< Reasoning that the ini must be left over from an old test, I deleted the
whole folder, uninstalled the app, ran the installer again & this time it
didn't put anything in the ...VirtualStore\ProgramData\ folder, and all went
well.

One day I'll worry about the logic behind it.... >>

It's definitely virtualization.  I wasn't aware that Windows Vista and 7
were virtualizing the ProgramData folders (I thought they were just
access-constrained), but they are, and that's the cause of the issue - you
originally created that .ini without admin privileges, and it was
virtualized with what amounts to a symbolic link back to a user-specific
folder.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

<<you originally created that .ini without admin privileges, and it was
virtualized with what amounts to a symbolic link back to a user-specific
folder.>>

Scary stuff, because by what logic would Windows find the ini at the path that it was requested to look in, ignore it, then look for the virtualized version?

With regard to the admin privileges, you are correct. The only code that the Inno script contained regarding the ini was that code that I included earlier, in the [INI] section. I now have a blank Company,ini in the [FILES] section that is installed with "Permissions: users-modify", and the existing [INI] lines just fill up that ini file. There may be a flag that would set the file's permissions (in the [INI] section, but the blank file seems to do the trick.

Peter