Re: Deployment under Vista
- From: "BeastFish" <no@xxxxxxxx>
- Date: Sat, 28 Jul 2007 16:10:10 -0400
Usually, top posting is appreciated in technical groups because one does not
need to scroll down to see the reply. But when replying to a reply that was
bottom posted (or vice versa), the appropriate courtesy is to "go with the
flow" as to not be confusing.
"Sally" <me@xxxxxxxx> wrote in message news:46ab94f6@xxxxxxxxxxxxxxxxxxxx
Thanks. That's made CDSIL clearer to me. BTW, your top post actuallylogged
confused me! Was it your way of teaching me that it's best not to?
"Randy Birch" <rgb_removethis@xxxxxxxx> wrote in message
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
aon 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
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
extremelyper-machine basis. Similarly the user's name must also be determined in
Thankfully Windows provides a mechanism - which I warn will look
Technicallycomplicated to a newbie - to determine these types of things.
andthe roots used to be called namespaces in Windows parlance; we (users
thereespecially developers) typically call them "special folders". In Windows
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
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,
a CSIDL is backwards compatible. IOW, your app can call CSIDL values and
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
definedare 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
(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)
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
admin rights (under Vista), is off-limits for the day-to-day record
a file might do. So is the Windows folder, which was traditionally
obtainby 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
folderthe correct paths - a demo of this is presented at
http://vbnet.mvps.org/code/browse/csidl.htm. (Check out the parent
codetoo for some other cool things that CSIDLs can be used for. And for
withthat just get's the name of the currently logged on user - not needed
oftenthe above since the user name is included in the data returned, but
http://vbnet.mvps.org/code/core/getusername.htm).useful nonetheless, see
** Qualification: you don't *have to* -- one could potentially consent
level of flagellation that would astound even Silas, by blurting out
path.another possibility might be considering the use of the shell object to
this info. But I am not one to enjoy suffering, especially given the
of adverse, severe (and possibly fatal but definitely deserved) ridicule
abuse that would come forth from the more knowledgeable participants of
group for making such a sacrilegious suggestion. So please note that I
not advocated nor supported that you undertake this self-destructive
MS MVP, Visual Basic
Please respond to the newsgroups so all can benefit.
"Sally" <me@xxxxxxxx> wrote in message
Firstly, many thanks to those who replied in previous threads in an
(inevitably)to guide this idiot along.
Unfortunately the sheer volume of information and some of the
mediffering opinions made me even more confused. People who have pointed
what to them are obvious things understandably get annoyed when I appear
to have noted them, but in some cases their assertions have been
threadwith by others. Added to that is my habit of replying on the fly, when
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
just(literally). I am using CTRL-U to advance through unread messages and my
Outlook (NOT Outlook Express) apparently does not easily allow me step
As for VB, I've learned a few things, I hope, and I'll summarise here
Wizardhow 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
Anyway, this app works perfectly under XP Home. I have used the PDW
wasto deploy it, and the result is
1) The Install suggests that the app is placed in C:\Programs. I accept
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
install my app and use it. BUT, I don't want to risk messing up his
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
install mine some files or settings on his Vista were messed up. That
So far, I think I have gleaned that
A) Any files apart from my app that PDW bundles on the deployment disc
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
Perhapsand maybe I'll go back to my crochet (sniff)... no knitting here.
downthat challenge will encourage the experts who have difficulty coming
a newbie's level not to reply. At times I felt like a 6 year old trying
resonantunderstand how subtraction works being given the formula for the
aboutfrequency of an LC combination by a learned professor who knows all
electronics and nothing about 6 year olds.
- Re: Deployment under Vista
- From: Sally
- Re: Deployment under Vista
- Prev by Date: updating vbasic files
- Next by Date: Re: Deployment under Vista
- Previous by thread: Re: Deployment under Vista
- Next by thread: Re: Deployment under Vista