Options for local storage for Vista applications

[Bern Ertl]

I'm designing a client/server application that I would like to be Vista compatible. The client application will be installed in the \Program Files folder.

I would like for the client application to store the connection information (server name and port) so the end user doesn't have to type it in every time s/he uses the program.

What would you recommend for storing this local data? Registry? Application data folder? How do you decide on a path/location that works on XP, Vista and other flavors of Windows?

[Michael Mattias]

>Registry?
Sure
>Application data folder?
Sure.
> How do you decide on a path/location that works on XP, Vista and other flavors of Windows?

For folders, use the CSIDL constants with SHGetFolderPath. Works on everything.

BTW, it's not really the operating system which prevents writing to say, a root folder or anything subordinate to Program Files, it's the UAC Security.

The "Vista" operating system fixation is likely related to the fact that UAC is disabled by default prior to Vista, on which it is enabled by default.

[Bern Ertl]

For folders, use the CSIDL constants with SHGetFolderPath. Works on everything.

Thanks Michael. I'll look into it.

[Michael Mattias]

Using CSIDL constants with PB:

Move That INI File!and Get That Ini File Name!

[Edwin Knoppert]

I have an INI file and i had no problem with UAC.
Can someone tell when i get ann issue?

Manual copying a (lic) file into the folder is less simple.
Usually an in between copy like, from USB or network onto the desktop and then to the target PF folder.

[Kev Peel]

I have an INI file and i had no problem with UAC.
Can someone tell when i get ann issue?

Windows Vista will "virtualize" the path (basically redirect it to a "safe" folder) when UAC is in use. The downside of this is you never really know where that file was saved.

Windows XP in limited account mode is actually worse, it will bail with "permission denied" with the following down 'n' dirty sample code:

#Compile Exe
#Dim All
 
$filename = "c:\program files\abc123.txt"
 
Function PBMain
   Open $filename For Output As #1
   If Err Then ? Error$,, "1": Exit Function
   Close #1
 
   Kill $filename
   If Err Then ? Error$,, "2": Exit Function
End Function

It's in the developer's best interest to use the Windows-provided folders for local data storage. All you need to do is create a subfolder under CSIDL_APPDATA (current user) or CSIDL_COMMON_APPDATA (all users), and stick to creating/editing/deleting files therein.

[Edwin Knoppert]

But maybe INI files are different since Windows itself maintains these.
Hmm...

[Michael Mattias]

>But maybe INI files are different since Windows itself maintains these

They are not.

However, to use the GetPrivateProfileString(), WritePrivateProfileString() and related functions, you must fully-qualify your INI file path, or those functions use their own rules.

MCM

[Cliff Nichols]

Ok I will bite (since I have been avoiding the enforcement of where the file lies (instead of with the app itself) and where it may be located???

I really need to do comparisons from OS to OS but think the results will prove themselves and the question of if the same holds true of a *.Inf instead of a *.ini???


Maybe reinventing, but worth persue for the idea of learning

[Edwin Knoppert]

INI files are updated in very different way compared to writing something by your own app.
While your app gives an instruction to update an INI element, Windows put's it there.
So far i did not experiance an issue.
but then, i have limitted experiance.

[Michael Mattias]

Cliff, the file extension (.INI, .INF, .TXT, .DOODAD) does not matter to the "xxPrivateProfilexxxx" functions, what matters is the format of that file...

[SECTION_NAME]
;comment
Key=value
key=value
...

MCM

[Bill Scharf]

more on Vista

I will add a few more ideas:

1. NEVER, NEVER store anything in the root of a drive. UAC will often not let you. You will not get an error; the functions will operate like normal. No files will end up in the root. THis is not a smart thing to do anyway, but with UAC it makes it worse.

2. We found that certain things with send alerts to Vista when you install your program. One of these was running executables with the word setup or install in them. Another one I believe was messing with a certain part of the registry. I think another one was using the program files folder. I can't find the documentation on this, but I know it does exist.

3. Writing to certain parts of the registry is now not a safe way to store data between sessions or between applications. Many big apps like Intuit's Quickbooks (American bookkeeping and accounting software) had *major* problems with this. What was bad practice in XP according to MS...but with Vista (uac or not) it will result in disaster.

Oh, and has anybody figured out how to use the PBwin debugger with UAC on? It seems to kill it for me?!?

[Tyrone W. Lee]

Lol

^ ^ ^

And what part of the computer is actually *mine* now? I'll never use another MS operating system. (I'm a Windows 2000 Professional User and loving it!)