Upgrading Vista Non-compliant installed apps

[NewsArchive]

Hopefully this has been addressed and I just couldn't find the
messages....<g>

I have an app that we are finally making Vista compliant. We are modifying
the installer to install data into Common_Appdata for VISTA & 2008 ONLY and
ONLY when installing into ProgramFiles. XP and the like will remain as
before.

I have this resolved in the application. But not in the Setup....

If I detect a Vista and if installed in Program Files I want to install into
CommonAppData.
I also want to move existing datafiles from Program Files to Common Appdata
so the users don't lose anything.
How can I detect this situation?
How can I move the data files?

paul macfarlane

[NewsArchive]

Hi Paul,

This is absolutely no problem. It can be done with a few lines of
SetupScript code.

You say "only for Vista and 2008" (and I assume also for Win7). What do you
do on XP (and prior). Where is the application (configuration) data stored
at the moment (in your non-Vista-aware product)?

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

The data is currently with the EXE and a Data folder under the program
install folder.

Some Vista users have installed the app to C:\ ..... So their data is in
C:\MyApp and C:\MyApp\Data

Other have installed to a network drive (ie G:) ..... So their data is in
G:\MyApp and G:\MyApp\Data

In these cases (especially the network drive case) I do not want to move the
data.

In my app the test is (is it Vista and are we running in CSIDL Program
Files)....

paul macfarlane

[NewsArchive]

Hi Paul,

See what Arnór posted. I thought you wanted to copy application
configuration data to CSIDL_APPDATA and you accidentally wrote
Common_Appdata. If you really meant CSIDL_COMMON_APPDATA, then this will
definitely not work. CSIDL_COMMON_DOCUMENTS is the way to go (and to make
it work from XP in a locked-down environment, you have to give write access
permission to your subdirectory).

Please see:
http://www.lindersoft.com/forums/showthread.php?t=11410

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

> definitely not work. CSIDL_COMMON_DOCUMENTS is the way to go (and to make
> it work from XP in a locked-down environment, you have to give write access
> permission to your subdirectory).

Is there an iron clad reason NOT to use a folder in APPDATA and just set the
write access? I know that using everyone for the write access is probably
not a smart thing to do, but that will ONLY give (write) access to that
particular folder.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> Is there an iron clad reason NOT to use a folder in APPDATA and just set
> the write access? I know that using everyone for the write access is
> probably not a smart thing to do, but that will ONLY give (write) access
> to that particular folder.

CSIDL_APPDATA (part of the User profile) can only be used to store
user-specific application preferences (per-USER).

CSIDL_COMMON_APPDATA can be used to store application preferences or data
that is not user specific (per-MACHINE). The only "disadvantage" is that
this folder is, by default, hidden (the "Do not show hidden files and
folders" option is enabled by default). You can enable "Show hidden files
and folders" to make it visible. If an application requires Standard Users
to write to that folder, the recommended approach is to create a
subdirectory under CSIDL_COMMON_APPDATA at install-time and give write
access permission to that particular subdirectory. The modified security
should always be documented in the manual.

The advantage of CSIDL_COMMON_DOCUMENTS is that it is *always* visible.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

>
> The advantage of CSIDL_COMMON_DOCUMENTS is that it is *always* visible.
>

And that we do not have to manipulate the ACL for a subdirectory under the
above CSIDL_COMMON_DOCUMENTS (no need to give write access permission) when
running under Vista/2008/Win7.

Friedrich

[NewsArchive]

Not under Vista, but yes (need to change permissions) under XP for ordinary
users :(

Jane Fleming

[NewsArchive]

Hi Jane,

> Not under Vista, but yes (need to change permissions) under XP for ordinary
> users :(

I thought we had solved that by setting the permission for the folder under
COMMON_DOCUMENTS to write for everyone?:) I'm doing that now and so far so
good.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Yes, that's what I meant... in response to Friedrich's saying that not
having to change permissions for Vista users is some kind of advantage to
Common Docs.

You do have to set those permissions for XP users if using Common Documents.
You have to set permissions if using Common Appdata.
Es gibt no free lunch <G>

Jane

[NewsArchive]

Hi Jane,

> You do have to set those permissions for XP users if using Common Documents.
> You have to set permissions if using Common Appdata.
> Es gibt no free lunch <G>

Understood!<g>

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

> CSIDL_APPDATA (part of the User profile) can only be used to store
> user-specific application preferences (per-USER).

I know, sorry I was thinking COMMON_APPDATA.

> CSIDL_COMMON_APPDATA can be used to store application preferences or data
> that is not user specific (per-MACHINE). The only "disadvantage" is that
> this folder is, by default, hidden (the "Do not show hidden files and
> folders" option is enabled by default). You can enable "Show hidden files
> and folders" to make it visible. If an application requires Standard Users
> to write to that folder, the recommended approach is to create a
> subdirectory under CSIDL_COMMON_APPDATA at install-time and give write
> access permission to that particular subdirectory. The modified security
> should always be documented in the manual.
>
> The advantage of CSIDL_COMMON_DOCUMENTS is that it is *always* visible.

Exactly - which _might_ be an issue for stuff that users really shouldn't be
messing with<g>

I see that I'm understanding this correctly:)

Best regards,


--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Friedrich,

> CSIDL_COMMON_APPDATA can be used to store application preferences or data
> that is not user specific (per-MACHINE). The only "disadvantage" is that
> this folder is, by default, hidden (the "Do not show hidden files and
> folders" option is enabled by default).

Looks like there are some disadvantages I am going to like very much ;-)

Bernard

[NewsArchive]

Hi Bernard,

>> CSIDL_COMMON_APPDATA can be used to store application preferences or data
>> that is not user specific (per-MACHINE). The only "disadvantage" is that
>> this folder is, by default, hidden (the "Do not show hidden files and
>> folders" option is enabled by default).
>
> Looks like there are some disadvantages I am going to like very much ;-)

You can also place things into COMMON_DOCUMENTS and hide the folders there.
As far as I can tell, it kind of comes down to the same thing.

Best regards,


--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Friedrich,

Actually, I do want CSIDL_Common_Appdata for Vista installs. For XP I'm
going to continue the "old ways" (Data folder under program install folder).

I want the Vista data to go into: C:\ProgramData

I do not want it in the User or Documents and Settings trees.....

CSIDL_Common_Appdata was recommended by Capesoft and others.....

Paul

[NewsArchive]

To quote from one of my clarionmag articles:

"Two things make CSIDL_COMMON_APPDATA, which on a Vista machine resolves to
C:\ProgramData, less than ideal. First, it's a hidden folder. Second,
default folder permissions give a user the ability to create and modify a
document; but for anybody other than the creator, permissions to that
document are read-only."

Before you settle on this, install your app on a Vista machine. Create TWO
(or more) ordinary user accounts. See whether BOTH of them can use your app
to update data files.

Jane

[NewsArchive]

I am re-thinking after reading all the items in this thread.

I may go to Common_Documents for Vista (2008/Win7) and remain with my DATA
folder under the program install folder for everything else.....

One word: Messy....<g>

paul macfarlane

[NewsArchive]

A lot depends on your audience and whether you're concerned about Microsoft
certification.

For users of my "consumer" software, I create a separate data folder off the
root of the C: drive on Vista installations. This makes it easy for users
to find and back up the data (or more likely, copy it to another machine).

For my own tech support sanity, I have a "File Locations" item on the Help
menu. This window displays the data location, any command-line switches
used to start the program, and a few other bits of information I find useful
when doing telephone support.

Jane Fleming

[NewsArchive]

I was planning to add that to my info screen as well. Glad it's not a crazy
thought..<g>

Vista certification isn't necessary.....

paul macfarlane

[NewsArchive]

> One word: Messy....<g>

Time kills all old computers and OS's...

The odd occasional unprotected power surge helps<g>.

:-)

Charles




--
-------------------------------------------------------------------------------------------------------
Charles Edmonds
www.ezchangelog.com - "Free ChangeLog software to manage your projects!"
www.setupcast.com - "A revolutionary new publishing system for software
developers - enhanced for SetupBuilder users!"
www.pagesnip.com - "Print and Save the Web, just the way you want it!"
www.clarionproseries.com - "Serious imaging tools for Clarion Developers"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms!"
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------

[NewsArchive]

Hi Paul,

> If I detect a Vista and if installed in Program Files I want to install into
> CommonAppData.

If I'm not mistaken COMMON_APPDATA does not allow write access to files so
you will need to set the access to the folder that you create under
COMMON_APPDATA. There have been threads recently about how to give
everybody write access to a folder using SetupBuilder.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Thanks......

paul macfarlane

[NewsArchive]

> Es gibt no free lunch <G>

ROFL


> You do have to set those permissions for XP users if using Common
> Documents.
> You have to set permissions if using Common Appdata.

<headscratch>

I did not have to to that under XP on my machine!

Now I checked it with other XP machines and these others are not shared -
that means I myself must have set this permission sometime in the past.....

And I was sooooooo convinced it would work fine - based on wrong facts!

Thank you again!

As a reply to Paul I will post a script that covers your remarks and your
example of granting permissions to JEDER ;-)

I was confused about the targeted OS by the fact that you made the
screenshot on Vista, so I falsely believe I have to grant permissions for
COMMON_DOCUMENTS in Vista, not in XP.

Now I see that it is XP that has to be altered.

Please see my post to Paul where I have attached a script that should
solve his attempt.

The next problem is running a program on a shared folder on a LAN.

What COMMON_DOCUMENTS will be looked at by the EXE? The one on the
"server" or the one on the calling machine.

And it will be even better if we have the "server" running XP where the
data are not under COMM_DOC but in the subfolder of the program - and the
calling machine is a Vista.

<sigh>






--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

Sorry for the confusion, Wolfgang.

In the earlier thread, I posted a couple of excerpts from the Vista Resource
Kit.
One explained why Common_Documents is now wonderful for Vista, but has
permissions issues for XP users.
The other explained the permissions of that folder under Vista.

The XP screen shot showed that the SB installer successfully set permissions
on XP to the folder it created within the Shared Documents folder
(common_documents on XP).

Jane

[NewsArchive]

Hello Paul,

maybe this script helps a bit

attached: Both_Vista_and_XP.zip

At install time it decides a datapath for either Vista etc or XP etc.

It sets a custom variable for this path and has the permission setting for
XP based on Jane Flemings postings.

One problem I see for the future is when a program is not only run on a
single machine but in a network.

When stored on a shared folder of XP the data sit in a subfolder below the
program.

But when data sit in COMMON_DOCUMENTS on the "server" what will a Vista
machine access then? The COM_DOC on the "server" or on the local drive?

This has to be caught in advance - its not part of my script, just to
avoid misunderstandings.

I discussed this with David Swindon before and we both have the opinion to
have an Adminprogram that will check the paths directly after the install
and store them in an INI or XML close to the main EXE. This main EXE then
checks at startup these settings an then has the correct paths.

In the app itself you have to set the SYSTEM{PROP:DATAPATH} = accordingly

hth
Wolfgang

--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

Wolfgang,

Thanks for the feedback and script....

Right now my problem is the installer side.

In my Application I do one of 2 things:

IF the client is Vista/2008/Win7 AND the program is in the "Program Files"
structure THEN I set the Datafolder to: CSIDL_Common_Appdata (reconsidering
this to Common_Documents)
ELSE
I do nothing......

So, in the installer I need to be able to detect the (Vista+/Program Files)
condition and install a group of files there.
Otherwise it all goes into the Program install folder.....

I have customers who have installed the APP into: C:\MyApp...
Now, if I can't determine the above condition, when these people run a
WebUpdate, they will get the EXE properly updated in that folder, but the
data I need to update will get installed to Common_AppData. When they run
the APP it'll ignore the new files in Common_AppData (because my app detects
the above condition)....

So, I guess this issue is CONDITIONAL INSTALLS for things OTHER than OS.....

Paul

[NewsArchive]

Arnor,

> You can also place things into COMMON_DOCUMENTS and hide the folders
> there.
> As far as I can tell, it kind of comes down to the same thing.

Yes, it's an idea, thanks, BUT '<g>' .... Some .Net libraries put your app
settings in AppData, if you ask them, rather than in Common documents. And
even if your folder is unhiden, a search does not find the file.... I know,
I tried, as when I went from XP to Vista, I was having difficulties finding
it. The only way I had to check where the APIs were putting that file was to
popup a message with the path in it!

I admit I like that, because I sure don't want users to mess up manually
with those files, and it seems Vista is doing a good job at making it
difficult...

I am far behind you discovering Vista compliance, but I easily admit there
is a lot to like. BTW, one thing I have not seen used much, which is used
extensively in Linux, is "symbolic links", aka shortcuts (even if it's not
exactly the same). Was wondering if, in some case, to make eveyone happy, it
would not be possible to put the file where it belong, and put a shortcut in
another, more intuitive and convenient directory, so that files could be
easily found, while still being at the right place? Very common in Linux,
maybe useful in Vista?

Bernard

[NewsArchive]

Hi Bernard,

> I admit I like that, because I sure don't want users to mess up manually
> with those files, and it seems Vista is doing a good job at making it
> difficult...

Sure.

> another, more intuitive and convenient directory, so that files could be
> easily found, while still being at the right place? Very common in Linux,
> maybe useful in Vista?

I haven't tried that, but Vista _does_ use some links for example "documents
and settings" in the C: root is a link to C:\Users etc.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php