This content has been marked as final. Show 5 replies
The 10.1 update has nothing to do with Vista. It is recommended that
you update it, since it is free and has a bunch of bug fixes. But it
does not address anything relating to Vista.
On that subject, what problems are you having with Vista? I installed
Director just fine on Vista and have had very few issues...
The only issues I have come across were due to programs trying to write
to places that normal users do not have access to (program files,
Hkey_Local_Machine in the registry, etc). Vista virtualizes most of
those things, so apart from my initial inability to find where things
were being stored, most of the programs I have ported to Vista have
required very little changing.
The Shockwave plugin in Vista has a few problems, specifically centered
around 3d. The next version of Director is slated to come out toward the
end of this year and it is supposed to have full Vista compatibility, so
I would assume that any problems there are now will be addressed in that
I’m curious about your statement:
The only issues I have come across were due to programs trying to write to places that normal users do not have access to (program files,Hkey_Local_Machine in the registry, etc).
I’ve got a project waiting for large scale duplication that for various reasons never got tested thoroughly on Vista. It uses Buddy API to read/write a fairly complex ini file saved wherever bsSysFolder(“prefs”) points. On XP and earlier this has been the Windows directory, have you seen any hints of trouble with this? My client found a Vista machine very late in development and did a quick run through and reported everything OK but I’m fairly sure they were primarily concerned about the video and audio and didn’t pay much attention to the large amount of data i/o this project relies upon.
On Vista, baSysFolder("prefs") will also be the Windows folder, and
unless the program was run with administrative privileges, it will not
be able to write there.
The thing is that Vista virtualizes any illegal file writing. The
command will run without errors, but if you look in the windows folder,
the file will not be there. If your program reads from that same
location, it will find it. Confused yet?
Any illegal writing (illegal here means without admin privs) will get
put into the following folder:
Thus, you will find your file in this folder...
I am not 100% sure about the inner goings-on, but I am pretty sure that
whatever is in the virtualStore folder will override whatever is in the
real Windows folder. So, you may come across problems where your
installer (which will have admin access) puts a file into the actual
windows folder, but the program itself reads/writes to the VirtualStore
version. Most of the time, the whole thing works pretty well,
transparently. Sometimes it doesn't. And MS has released some
documents (I don't have a link, but if you search they knowledge base,
you'll find them) explaining how file I/O should operate from a
developer standpoint. The main thing is that you should avoid writing
to Program Files or Windows folder (or a few others) for any user data.
All user data should go into the user-writable folders (like
baSysFolder("personal") which is the Vista version of My Documents).
By the way, there is a whole lot of info out on the web about this, but
most of it is way too technical for me to understand, and a whole lot
deeper into the guts of Vista than I care to go. The most
comprehensible explanation of all this that I have found is actually on
the website for BuddyAPI where Gary (the guy that wrote BuddyAPI)
explains how to deal with Vista from a Director developer standpoint.
Yikes, what a mess. Fortunately I think I might be safe. My program doesn’t actually install, it simply looks for the ini file at run time and if the file doesn’t exist it copies from the CD. (it has a fail safe where critical data can be read from the CD ini file if the copy fails but the data storage features will be disabled) From what you and Gary have said it looks like for standard users with UAC enabled (it sounds like this is the default) the path will always be virtualized so even if it’s not in the Windows directory my app will still be able to find it with r/w permission. If the user is logged in as admin or if UAC is disabled the ini file will end up in the Windows directory as before and will still function. Problems arise if the user logs out of admin and returns as a standard user or if UAC is toggled on after the ini has been copied. In these cases the ini file won’t be found and it will be as if they are starting over, I can live with this.
Hopefully we’ll have a Vista machine in here soon for testing. We just purchased a high machine from Dell for development and I lobbied hard for Vista but the Dell sales rep talked my boss out of it and convinced him to go with another XP Pro saying it was more stable … that may be true but now we still don’t have a Vista test platform.