Re: Where To Put Data?
- From: "expvb" <nobody@xxxxxxx>
- Date: Wed, 21 Jan 2009 00:40:32 -0500
"mayayana" <mayaXXyana@xxxxxxxxx> wrote in message
news:%231nXCExeJHA.1860@xxxxxxxxxxxxxxxxxxxxxxx
See these posts:
http://news.jrsoftware.org/news/innosetup/msg75561.html
VB6 Sample:
http://news.jrsoftware.org/news/innosetup/msg69444.html
Those are very informative links. But they still
leave that pesky all-users issue unresolved. Jordan
Russell's solution is to change the permissions on
all users app data (apparently without asking) so
that that can be used for global storage. That's better
than nothing, though as with using the user app data
folder, it has the disadvantage of making program config.
files very difficult for the average person to locate. But
another issue is that the Inno approach is only for people
using Inno. If someone has some nice, compact API code
for changing folder permissions that would be helpful
to see here. (Without anything hokey like shelling out
to xcacls.)
Here is a VB6 approach to change the permissions on an NTFS file system:
How to use low-level access control APIs from Visual Basic
http://support.microsoft.com/kb/316440
Also, in older MSDN Libraries, search for Q240176: "HOWTO: Set Security on a
NTFS Folder Programmatically", but the article above maybe easier to use.
I use my own updated version of the PDW and still
put config. files in App.Path. If I were to eventually decide
to accomodate Vista users more then I think my
preferred approach would be to do something like:
1) Call GetVolumeInformation to check the file system.
(XP originally shipped as FAT32. For SOHo PCs the
whole issue of permissions is still really just a Vista
issue, and therefore quite limited at this point.)
2) If the file system is NTFS then change permissions
on the all users app data folder and create a subfolder
there. And having done that, why use Program files at
all? I might just as well make the default install path to
all users app data. If the file system is FAT32 then
I could install everything as usual to Program Files.
Changing the permissions on your "C:\Program Files\MyApp", or wherever the
EXE is installed is not a good idea because it would open a security hole. A
limited user can overwrite the EXE, or the EXE can be infected by a worm,
and when an Admin or Power user logs in, he or she may use the same program
and think that the EXE has not been altered, leading to privilege escalation
making the worm do more damage. If you put your data in a subfolder, such as
"C:\Program Files\MyApp\Data", then that's better.
Some Windows 2000/XP home and business users log in as a limited user and
right click installers and use "Run As" to run installers as Administrator,
so not to expose their system to infections. Linux/Unix have used that model
for a long time, and MS was just catching up slowly starting with Windows
2000, and enforced that model in Vista.
Personally, I think it's Microsoft's fault for not campaigning hard enough
to alert both developers and computer builders to not use Administrator
account by default. Computer builders sold computers that made the
Administrator the default user instead of making instructions on how to use
administrative privileges only when needed. Developers usually run as Power
Users or Administrators, this is especially needed if you develop ActiveX
components. However, those who were looking for certifying their software
for the Windows Logo program were aware of these security related changes in
Windows 2000, unfortunately, these were in the minority. Again, Microsoft
didn't campaign hard enough to alert software developers.
Some corporate admins might not like that approach,
but they can change the install path if they want to...
and they probably don't care about global settings.
Meanwhile, it's an approach that tries to respect the
expectations of the average SOHo person, who expects
two things:
1) Their software should be in Program Files and not leave
behind a big pile in App Data at uninstall.
Advantage of 1):
- Data files can be removed during uninstall.
- Easier on the developer, and there is no need to have an NT system to test
with.
Disadvantage of 1):
- Every user use the same settings. While you can save the user logged on
name along with his setting, so every user can still have his or her own
setting. This approach doesn't work well with roaming users. When an
application use this method, the roaming user will see the setting as he
left it on that particular computer. If the application used AppData(per
user), the roaming user sees his or her setting and data the exact same way
on every computer. That's because when he logs on or off, per user data is
saved/restored to/from a central server.
- Less sales.
Note that the first advantage in item 1) above can be duplicated when you
follow the AppData approach.When you use AppData(per user), you can remove
it during uninstall, you just can't remove other users' AppData because in
some cases they are in a central server(as explained above) and the computer
may not be connected to during uninstall. So the only advantage I see of
using your own program folder or a data subfolder within it; is that it's
easier on the developer and you don't have to have access to an NT system if
you are still developing using Windows 9x.
2) When Dad installs a new program and configures the
settings, he shouldn't have to go through that whole
process again for each login, saving the same config.
for Mom, Sis, and Junior. (Outside of corporate workstations,
having different "users" generally boils down to little more
than choosing the Desktop background picture.)
Advantage of 2):
- Dad can configure the app for the whole family.
- Easier on the developer, and there is no need to have an NT system to test
with.
Disadvantage of 2):
- Same issues in item 1).
The first advantage in item 2) above can be duplicated when you follow the
AppData approach. At install time you can make the user choose between "All
users use the same settings" or "Each user has his or her own settings", and
use All Users/Per User AppData accordingly. In your application, it checks
All Users AppData first and look for a flag that indicate
AllUsersUseSameSettings or not. You can also do this from the application
instead of the installer(if you set the permissions on your All Users folder
at install time). In that case, your application can update the
AllUsersUseSameSettings flag. So the only advantage I see of using your own
program folder or a data subfolder within it; is that it's easier on the
developer and you don't have to have access to an NT system if you are still
developing using Windows 9x.
I know that you may be still using Windows 9x for development, but you can
download Windows 7 Beta. You can also download a 60 Day trial
version(expandable to 240 days) of Windows 2008 Server, which is not a beta
and is almost identical to Vista.
http://www.microsoft.com/windowsserver2008/en/us/try-it.aspx
You will need 512MB minimum to run either Vista or 2008 Server, and at least
10 GB disk space.
.
- Follow-Ups:
- Re: Where To Put Data?
- From: mayayana
- Re: Where To Put Data?
- References:
- Where To Put Data?
- From: Bee
- Re: Where To Put Data?
- From: expvb
- Re: Where To Put Data?
- From: mayayana
- Where To Put Data?
- Prev by Date: Re: Compiling VB6 project without upgrading to VS2008
- Next by Date: Re: Compiling VB6 project without upgrading to VS2008
- Previous by thread: Re: Where To Put Data?
- Next by thread: Re: Where To Put Data?
- Index(es):
Relevant Pages
|
Loading
