Re: Deployment under Vista
- From: "Sally" <me@xxxxxxxx>
- Date: Sun, 29 Jul 2007 05:11:46 +1000
Thanks. That's made CDSIL clearer to me. BTW, your top post actually
confused me! Was it your way of teaching me that it's best not to?
"Randy Birch" <rgb_removethis@xxxxxxxx> wrote in message
news:0D5687C7-622C-4AB0-BC3E-BC14C1B5796C@xxxxxxxxxxxxxxxx
Under the user security model of Vista, applications can not write to
folders outside the folders assigned to the user's profile. This is a
combination of a special path designated by Windows and the current logged
on user's name. For example, my app-friendly folder is rooted at
c:\users\birchr\application data\<program name>.
Now, note I use drive C for my Windows drive, as do a good number of
people
but not all. So while in my case it would be safe to presume the initial
path is c:\users\, this is not always the case so must be determined on a
per-machine basis. Similarly the user's name must also be determined in
some
fashion.
Thankfully Windows provides a mechanism - which I warn will look extremely
complicated to a newbie - to determine these types of things. Technically
the roots used to be called namespaces in Windows parlance; we (users and
especially developers) typically call them "special folders". In Windows
95
through XP, each special is represented by and accessed using a special
constant and a Windows API or two, and these constants are prefaced with
the
letters CSIDL, which stands for "constant special item ID list". Under
Vista the name was changed (somewhat gratuitously I might add) to become
"known folders" - I guess "special folders" was too technical for users.
Consequently, under Vista CSIDLs were changed into KNOWNFOLDERIDs,
although
a CSIDL is backwards compatible. IOW, your app can call CSIDL values and
get
the expected results under Vista, which is a Good Thing since I've not
updated my site with the KNOWNFOLDERID constants.
Anyhow, once you get your head around this you have to realize that there
are two types of "special" (or "known") folders - those that return disk
paths (such as CSIDL_MYDOCUMENTS), and those that return non-physical
locations that can not be accessed by simply using standard path/file
syntax
(such as CSIDL_BITBUCKET - aka the recycle bin).
So ... this is a long introduction to the point: Under Vista it is your
app's responsibility to only create working files in the folder(s)
assigned
to the user and marked as accessible for read/write by applications. The
Program Files, while it can be used as an installation path by someone
with
admin rights (under Vista), is off-limits for the day-to-day record
keeping
a file might do. So is the Windows folder, which was traditionally defined
by Microsoft as *the* place for saving INI files (application settings
files - ini standing for initialization).
In order to ascertain the correct path to write to under any Windows
version, and especially Vista, you have to use** the Windows API to obtain
the correct paths - a demo of this is presented at
http://vbnet.mvps.org/code/browse/csidl.htm. (Check out the parent folder
too for some other cool things that CSIDLs can be used for. And for code
that just get's the name of the currently logged on user - not needed with
the above since the user name is included in the data returned, but often
useful nonetheless, see http://vbnet.mvps.org/code/core/getusername.htm).
** Qualification: you don't *have to* -- one could potentially consent to
a
level of flagellation that would astound even Silas, by blurting out that
another possibility might be considering the use of the shell object to
get
this info. But I am not one to enjoy suffering, especially given the
torrent
of adverse, severe (and possibly fatal but definitely deserved) ridicule
and
abuse that would come forth from the more knowledgeable participants of
this
group for making such a sacrilegious suggestion. So please note that I
have
not advocated nor supported that you undertake this self-destructive path.
--
Randy Birch
MS MVP, Visual Basic
http://vbnet.mvps.org/
Please respond to the newsgroups so all can benefit.
"Sally" <me@xxxxxxxx> wrote in message
news:46aa4934$1@xxxxxxxxxxxxxxxxxxxx
Firstly, many thanks to those who replied in previous threads in an effort
to guide this idiot along.
Unfortunately the sheer volume of information and some of the (inevitably)
differing opinions made me even more confused. People who have pointed me
at
what to them are obvious things understandably get annoyed when I appear
not
to have noted them, but in some cases their assertions have been disagreed
with by others. Added to that is my habit of replying on the fly, when
there
are more posts to come. Also, I haven't figured out a way of going back
through a thread, so once I've replied to the last post I lose the thread
(literally). I am using CTRL-U to advance through unread messages and my
Outlook (NOT Outlook Express) apparently does not easily allow me step
back.
As for VB, I've learned a few things, I hope, and I'll summarise here just
how far I've got and see if there's a way forward that's uncomplicated.
Let's call my app Fred.exe and it uses say two random access files,
Ledger.Dat and Transact.Dat. (not difficult to fathom out what the app
does!).
Anyway, this app works perfectly under XP Home. I have used the PDW Wizard
to deploy it, and the result is
1) The Install suggests that the app is placed in C:\Programs. I accept
that
default.
2) As for the data files, I have hardcoded within my app to create a
directory C:\FredsData, and then lines like this
Open "C:\FredsData\Ledger.Dat" For Random As #1 Len=255
As I said, it all works under XP Home.
Now, a colleague is running Vista and I want to post him a CD so that he
can
install my app and use it. BUT, I don't want to risk messing up his
system,
which runs many critical applications. It is not so serious if he has
trouble running mine. But it would certainly be serious if in attempting
to
install mine some files or settings on his Vista were messed up. That was
my
anxiety.
So far, I think I have gleaned that
A) Any files apart from my app that PDW bundles on the deployment disc
wail
not overwrite any of his that might be later (that cures one worry... IF
I've got that right.
B) The app should not go in root (meaning C: direct). In that respect
perhaps Vista makes a similarly appropriate default suggestion to the
Programs directory in XP Home?
C) The data files should not go in root. In that respect, perhaps my
hardcoded C:\FredsData\... will do the trick?
A, B and C really encapsulate my concerns.
If anyone has the time and patience to reply in as uncomplicated way as
possible, I would be grateful. For those who are fed up with this stupid
bird please do not reply! I guess if no-one replies the message is obvious
and maybe I'll go back to my crochet (sniff)... no knitting here. Perhaps
that challenge will encourage the experts who have difficulty coming down
to
a newbie's level not to reply. At times I felt like a 6 year old trying to
understand how subtraction works being given the formula for the resonant
frequency of an LC combination by a learned professor who knows all about
electronics and nothing about 6 year olds.
.
- Follow-Ups:
- Re: Deployment under Vista
- From: BeastFish
- Re: Deployment under Vista
- References:
- Deployment under Vista
- From: Sally
- Re: Deployment under Vista
- From: Randy Birch
- Deployment under Vista
- Prev by Date: Re: Deployment under Vista
- Next by Date: Re: Show graphics form like in Access
- Previous by thread: Re: Deployment under Vista
- Next by thread: Re: Deployment under Vista
- Index(es):
Relevant Pages
|
Loading
