ini in app.pth works for xp, best practice for Vista/W7?
in [Visual Basic]
|
Prev: RegClean Revisited
Next: Make a Backup
From: Mayayana on 6 Aug 2010 09:04 | For 32 bit VB, they read/write the Registry; | specifically, to subkeys under "HKEY_CURRENT_USER\Software\VB and VBA | Program Settings". | I understand that. I just meant that the way the methods work is designed in a similar way to the INI APIs: Saving string data by grouping and value (*PrivateProfileString), returning all values in a grouping (*PrivateProfileSection), etc. The OP is using INIs, so I thought the VB methods might be a reasonable substitute. | > But if you need it per-machine | > you need to take a different approach and change | > permissions somewhere. | | I cannot agree with that at all. A program has no business changing | permissions just to satisfy its own shortcomings (i.e. bad programming). | I know that several people here have an odd knee-jerk reaction about that issue. I'm speaking for everybody else. Your approach is designed for use with corporate employees who have no rights to the PC they use and need per-user settings. That's fine. App data is good for that. In a SOHo environment it often works differently. Per-machine settings often make sense. Also, people own their PCs. It's a matter of common courtesy to be as transparent as possible with software installed, not hiding program files off in a bizarre, convoluted hierarchy of user folders where the average person cannot find them. Many people will never know or care about those files, but that's not for us to decide. They should have access to the files if they want it. People shouldn't need to be expert tweakers just to figure out where the files for my software are stored. (The first time I discovered that the app data method was being used was with Firefox, when I installed a new version and found that all my old settings were still there. After using Filemon/Regmon to figure out what was going on I was amazed that Mozilla had seen fit to take that liberty -- storing all that stuff on my system when the software was uninstalled -- without asking me. That's what I'd call bad programming practice.) If you want all people to be reading/writing to settings then they have to be public. The popular way to do that seems to be using a company subfolder under all users app data. Personally I create a folder under app.path, set permissions r/w for all users during install, and then just store settings files in there. It's clean and easy. It's safe. I'm not messing with any public folders. And it's all gone when my software is uninstalled. But however you do it, there has to be a restriction-free folder somewhere. The whole point here is to serve the needs of the end-user. Part of that is transparency. Part convenience. And of course there should be a healthy respect for security issues. But I think there's a tendency to get carried away with the letter of the law and to forget the spirit. The app data folder is Microsoft's "best practice" recommendation because Microsoft does not acknowledge the SOHo scenario. Despite selling 2/3 of their PCs to non-corporate customers, WinNT is basically a corporate workstation OS. (Even the so-called "Home" version.) The same problem happens on Linux. Most of the people who are doing professional programming are doing it for corporate customers. So while you or Kevin will answer a query by saying "put it in app data where it belongs", I'm trying to provide an answer that will help the questioner to understand the whole situation. Then they can make their own decision.
From: Paul Clement on 6 Aug 2010 09:45 On Thu, 05 Aug 2010 20:40:07 -0700, Mike S <mscir(a)yahoo.com> wrote: � I use an ini file in the app.path for a program that runs on XP. What is � considered the best practice for deciding where to save the ini file on � Vista or W7? � � I read this thread which recommended this approach: � � http://www.codenewsgroups.net/group/microsoft.public.vb.general.discussion/topic16789.aspx Yes, get it out of the application path and into APPDATA. Relying on the virtualization mechanism can get you into trouble if you put a data file into the system area. Paul ~~~~ Microsoft MVP (Visual Basic)
From: Mike S on 6 Aug 2010 21:53 On 8/6/2010 4:32 AM, Mayayana wrote: > |> Leave it in the app datapath for Win 2000 and up. They should have been > |> there all along. > | > | Sounds good, very easy fix. > | > You realize that's a per-user method and what > you were doing is a per-machine method? You > can also just use the VB SaveSetting/GetSetting > functions if it's per-user. Those are designed to > mimic INI files. But if you need it per-machine > you need to take a different approach and change > permissions somewhere. Per-user will work perfectly, thanks for pointing that out. Thanks Again, Mike
From: Nobody on 8 Aug 2010 15:38 "Mike S" <mscir(a)yahoo.com> wrote in message news:i3g06q$3cb$1(a)news.eternal-september.org... >I use an ini file in the app.path for a program that runs on XP. What is >considered the best practice for deciding where to save the ini file on >Vista or W7? Actually, it's not fine on XP or even Windows 2000, although it seems to work fine. That's because most developers are logged in as Administrators. In Vista+, you are treated as a member of the limited "Users" group even if you are an Admin, unless you turn off UAC, or use "Run As Administrator". So, if you left the INI in App.Path, a member of the "Users" group would complain that the settings are not saved in 2000/XP/2003 Server, and no problem in Vista and after(Because in Vista+, INI files that are left in Program Files are redirected to a per user location). If you want your settings per user, then use CSIDL_APPDATA, or GetSetting/SaveSetting. If you want per machine settings, use CSIDL_COMMON_APPDATA, but you also need to change the permissions on your subfolder to allow all users to write to the folder.
From: mscir on 8 Aug 2010 18:30
Nobody wrote: > "Mike S" <mscir(a)yahoo.com> wrote in message > news:i3g06q$3cb$1(a)news.eternal-september.org... >> I use an ini file in the app.path for a program that runs on XP. What is >> considered the best practice for deciding where to save the ini file on >> Vista or W7? > > Actually, it's not fine on XP or even Windows 2000, although it seems to > work fine. That's because most developers are logged in as Administrators. > In Vista+, you are treated as a member of the limited "Users" group even if > you are an Admin, unless you turn off UAC, or use "Run As Administrator". > So, if you left the INI in App.Path, a member of the "Users" group would > complain that the settings are not saved in 2000/XP/2003 Server, and no > problem in Vista and after(Because in Vista+, INI files that are left in > Program Files are redirected to a per user location). > > If you want your settings per user, then use CSIDL_APPDATA, or > GetSetting/SaveSetting. > > If you want per machine settings, use CSIDL_COMMON_APPDATA, but you also > need to change the permissions on your subfolder to allow all users to write > to the folder. I'm reluctant to use the registry because I don't know anything about how the various versions of Vista or W7 will handle permissions. Do you know if it is the case that a VB6 program running under those OS's as an Admin, or as a user with limited rights, in any mode available, will always be able to write to the registry with no problems? I want the simplest solutions that will require the least maintenance and run on any version of XP or later, so I'm using CSIDL_APPDATA. This program will be run by only one user on any given machine, and speed is not an issue (I think registry reading is probably a lot faster than INI reading) so I just want to keep this as robust an approach as possible. Mike |