Vista and CSIDL_COMMON_DOUMENTS

[NewsArchive]

I know that Friedrich has produced some excellent information on the use of
this folder in Vista.

I have also read many articles on the Internet both within MS and other
forums.

I need to make a final decision on where to start installing my applications
to for Vista and above (Longhorn) operating systems from now on. I do NOT
wish to be MS accredited.

I have never heard a full explanation of why I cannot simply use the
C:\Application Name approach instead of using CSIDL_COMMON _DOCUMENTS other
than accreditation for MS.

Just one final requirement - I will require my users to be able to access
data over a network and both approaches would work.

So is there any real reason why the C:\Application Name appraoch is not a
good idea?

I simply feel that users would be more "comfortable" using the access to the
root folder approach rather than public/users/documents on a Vista box. It's
not very intuitive. That is my only reason for not wanting to use
CSIDL_COMMON_DOCUMENTS.

Many thanks

John Fligg

[NewsArchive]

John,

That is exactly what we are going to do. As you know, we have 3,500 sites.
We can't have a program installed under Program Files, and then serve up
server data within the same directory. More importantly, we can't have the
user create two shared directories (data and app) as the users would get
themselves in a mess constantly and create huge amount of support calls.

Then, there is the issue of clients installing multiple versions of the
program and then you have to worry about which data goes with which program.

Vista seems to be very single user oriented.

We are detecting VISTA from within SetupBuilder and forcing the installation
into c:\roomMaster - then, when the user decides to go live, then can share
the directory and all workstations see it on the network.

I don't see how (without an IT staff onsite) for users to be able to figure
out how to manage this. Our users have no computer knowledge at all ....
they have problems sharing one directory yet alone two.

-Robert

[NewsArchive]

Robert - yes precisely my scenario. My users tend to be pretty computer
illiterate yet want to use networking to some degree from time to time.

It is just that every time I raise this issue, someone usually says "it can
be done but not recommended" and I never know why it is not recommended. It
just seems such an obvious workaround if MS accreditation is not required.

John

[NewsArchive]

John,

PS: With this added multiple directory issue, it would create additional
support calls. Microsoft doesn't answer my support line at 3AM, nor do they
pay my support departments salary expenses.

If I were to ask all my customers, would you rather have additional yearly
support costs or have roomMaster installed off the root directory, I'd bet
$1000 that 100% of those customers wouldn't give a crap where RM is
installed, so long as it works all the time with less issues. They know my
program is not prone to attacks and viruses.

The issue is not an issue with single user/single workstation installations.
Vertical Market applications are COMPLETELY different. Many Vertical Market
applications do things which are not the norm. I have one that we use
(Shift4) that writes all their work files to the root directory of C on the
server all day long. Sure, it's ugly and sure it's not a standard, but that
application makes me money, so I deal with it.

Most users are the same way. The IT people will make a comment, and the
end-users know THAT is the application they need to run their business to
make them money, regardless of whether or not it complies with Microsoft's
desires.

I had an IT department just yesterday tell a user community that they
couldn't buy our application because they didn't have DBA authority to the
DB. They listed concerns and I answered each one showing how DBA wasn't
needed ... the answer was "we have dba authority to all our SQL DB's so we
need it otherwise, you can't install it". Guess what, they just got their
own server at the hotel portion of this very large organization and told the
IT department where to go. Bottom line ... in Vertical Market ... if the
application is what does the job, it doesn't have to follow Microsoft
certifications or IT's wishes all the time. I think in your case, there
isn't many applications which do what you do ... if it were single
workstation driven, then yes, you do need to write to the proper Vista apps
folders. But, if it is server driven with multi-users, I don't see it being
an issue at all.

That is only my opinion.

-Robert

[NewsArchive]

> I have never heard a full explanation of why I cannot simply use the
> C:\Application Name approach instead of using CSIDL_COMMON _DOCUMENTS other
> than accreditation for MS.


John,

The real question here is:

"How many times do you want to have change your app because it is not
working within MS guidelines?"


You and Robert (and all of us) need to just suck it up and fix the code
right this time!

It is NOT hard to do (using Setupbuilder and WinEvent).

1) Install your program under Program Files

2) Put your common data (that needs network access) in
CSIDL_COMMON_DOCUMENTS (or other suggested location) as Microsoft
recommends.

3) Use HKLM (from the installer) to tell the app where it was installed

4) Use HKCU for other user specific settings (created at runtime - not
during the install).

5) Use Clarion's ability to set the datapath to where your data is
installed.

6) Live a longer and happier life because your apps ARE compliant.


The C:\MyProgram bit is just not going to cut it in the future and while I
can find it as an attractive of an idea as the next guy - I'm NOT going
there with any new apps.

As an aside, I did use a path like this when I took my old EZRound program
and built a Vista installer for it, but that was because the new version
WILL be Vista compliant and I did not want to rework the old app.


If you think security is bad now with Vista - just wait a year.

IIRC - MS has already indicated that the C:\MyProgram type of install is
deprecated, so why on this green earth would you want to tie yourself into
some "non-standard" install and then we have to listen to you cry again one
of these days when MS changes it.


If you adopt the standard, then it not only shows that you are paying
attention to the standards (like them or not), but that you are bent on
running your company like a professional software house.

It is time for everyone to drop the backyard coding standards and step up
to the plate.

The results will be that your software runs as expected and with less
problems than it will if your trying to do an end pass on the standards.


As far as level of sophistication for a user to find the data ... phooey.

You can create a button in your app that opens a Windows Explorer session
right to the CSIDL path where your data is. TaDa - problem solved.


I can tell you for certain that I am fixing my apps now with a new set of
standard procedures that DO use the expected MS standards.

As a result - I won't ever have to play this game again (because even if
the CSIDL changes - the path follows it).

Meanwhile instead of all this hand wringing and explaining to customers why
my programs are NOT standard - I will be coding the next great thing that
actually puts money in the bank.


BTW - I am definitely NOT picking on you or Robert by any means, but this
is a tired old argument that all of us need to stop complaining about and
just fix.


I am as lazy as the next guy (after all - I do have my own Capesoft.com
email address<g>), but it is time to put this question to rest by doing the
right thing and fixing our code.

Just my $.02

;-)


Charles





--
-------------------------------------------------------------------------------------------------------
Charles Edmonds

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]

Point taken Charles and very sensible. I agree totally and probably why I
asked actually as although I am not someone who rubbishes MS for the sake of
it, I just could not see the point. Now I do! Thanks.

Just one question (which I should know <g>) ....

All my files in the dct are currently set to a Full Pathname of
Data\filename. How do I set the data path in the app so that the app is
always pointing to the correct place? I assume all my dct definitions need
to change and allow the app to do the dirty work.

I assume that this will not afect any code in my app. Changing my existing
apps might be a bit of a nightmare but any new apps can have this criteria
designed in from day 1.

TIA

John

[NewsArchive]

On 25 May 2007 10:06:14 -0400, John Fligg wrote:

> Point taken Charles and very sensible. I agree totally and probably why I
> asked actually as although I am not someone who rubbishes MS for the sake of
> it, I just could not see the point. Now I do! Thanks.

Well I have no particular love loss for Microsoft, but like to think I am
smart enough to read the handwriting on the wall<g>.


> All my files in the dct are currently set to a Full Pathname of
> Data\filename. How do I set the data path in the app so that the app is
> always pointing to the correct place? I assume all my dct definitions need
> to change and allow the app to do the dirty work.
>
> I assume that this will not afect any code in my app. Changing my existing
> apps might be a bit of a nightmare but any new apps can have this criteria
> designed in from day 1.

I think you can solve (for your setup) that by setting
SYSTEM{PROP:Datapath} early in the app.

You can use WinEvent to get the location for CSIDL_Common_Documents and
then set the SYSTEM{PROP:Datapath} with that.

Something like:

MyDataPath = CLIP( ds_GetFolderPath( WE::CSIDL_COMMON_DOCUMENTS )) &
'\MyApp'

Then your "Data\Filename' would be prepended to that.


Of course you could also create the folder with SB6.5 and store the
location in HKLM (along with the path to the app in Program files), then
just read that value at startup and set SYSTEM{PROP:Datapath} with it.


I **think** that since you are creating the app's data folder under
CSIDL_COMMON_DOCUMENTS that it would be OK to do it in the installer - but
you'd need to test to be sure.


All this is a PITA to be sure, but if we sort it out now and document it
well, then it should be just a normal part of the clockwork as we create
new apps.

;-)

Charles





--
-------------------------------------------------------------------------------------------------------
Charles Edmonds

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]

Excellent Charles. Thanks. That is what I will do.

Just got to start learning SB now <g>

John

[NewsArchive]

On 25 May 2007 10:42:41 -0400, John Fligg wrote:

> Excellent Charles. Thanks. That is what I will do.

Glad to help.

> Just got to start learning SB now <g>

Well the good news (for you or anyone else who is not yet using
SetupBuilder 6.5), there is no better time to do it!

SetupBuilder has been great all along, but the new stuff is even easier
than before.

Friedrich just keeps making it better and all the tools you need to succeed
with a minimal amount of effort on your part are in there.

With SB 6.5 - there is simply no reason for any developer to have to
struggle to have a Vista compliant installer or get complaints from their
customers for installer related issues.

;-)

Charles


--
-------------------------------------------------------------------------------------------------------
Charles Edmonds

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]

I just wanted to say in addition to the great comments...

I just found out my upgrade to my old installer (now owned by Symantec) is
going to be more expensive that purchasing the setup builder program... it
looks like everyone seems to be happy with that installer.... and it has a
reasonable price. I thought it came with the enterprise edition, but I guess
that was a demo or limited version... besides, I don't have a problem paying
for decent software.

I would hope our friends at SV or some very smart individual who makes
classes and templates will give us a tool to check a button and have the
apps do this for us.... we shouldn't have to hand code (not that that's a
bad thing) a piece of code that is evidently as important as this... for
Vista. It should be at a very low level (like that upgrade to fix the help
files that Carl Barnes made). One piece of code and my whole app used the
winhelp or chm help... now that's what I'm talking about!

However, my main app which is running in many many businesses will probably
stay in the root folder... I can barely get my customers to upgrade.... I
suppose if I could figure a completely automatic way of copying the data
from where it is (in the app folder) to the data folder... it would probably
be worth it... someday. Fortunately because I did install into the root
folder.... when my clients who ran out and bought a Vista computer (before
I'd even seen Vista)... and ran it on a LAN.... it worked great.

Ray Rippey
VMT Software

[NewsArchive]

Ray - if it helps ....

I upgraded to SB just recently for the same reason. I am also taking Charles
and friedrichs advice (on another thread) and creating new installers to run
in Program Files and putting the data in CSIDL_COMMON_DOCUMENTS.

I have existing clients who have a variety of setup locations. XP users
would have the app in Program Files, Vista would be in C:\appname and others
have custom locations.

Fortunatley I store the installation path in a registry key (HKCU) which
now needs to be changed to HKLM. I am writing a script to check the HKCU
location and copy everything across to Program Files (if not already there).
As my data is always in the subfolder I will then simply use Winevent (or
SB) to get the CSIDL folder and copy the data there then patch a small
upgrade to change the data folder path in my app.

The only thing I have to worry about is the INI file location which I will
now pose in another thread.

HTH

John Fligg

[NewsArchive]

> You can use WinEvent to get the location for CSIDL_Common_Documents and
> then set the SYSTEM{PROP:Datapath} with that.
....
> I **think** that since you are creating the app's data folder under
> CSIDL_COMMON_DOCUMENTS that it would be OK to do it in the installer -
> but you'd need to test to be sure.

Charles,

I found these:

WE::CSIDL_COMMON_APPDATA equate(023h) ! C:\Documents and Settings\All
Users\Application Data

WE::CSIDL_COMMON_DOCUMENTS equate(02Eh) ! C:\Documents and Settings\All
Users\Documents

WE::CSIDL_LOCAL_APPDATA equate(01Ch) ! C:\Documents and
Settings\username\Local Settings\Application Data


What makes the difference?

- (All users / username = logged-in single user) thats not the problem

Isn't CSIDL_COMMON_DOCUMENTS what we know as "My Documents" in the windows
explorer?

A user can fiddle around there - and as they tend to pouch all their DOC
and XLS and PPS and .... over there it soon gets crowded.

APP_DATA is not that easily accessible for the sprightly user wouldn't it
be a safer place?

What if the data should be stored at another drive? (I personnaly love to
store data on not-C: as I can simply push the entire drive onto a CD-R as
a backup. Programs can be installed easily after a crash, but spreaded
data [and data in a data-folder determined by the OS I would call
lost-by-design as they are out of my control]...!

tia
Wolfgang



--
Grüße / Regards
Wolfgang Orth

http://www.odata.de


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

[NewsArchive]

> I found these:
>
> WE::CSIDL_COMMON_APPDATA equate(023h) ! C:\Documents and Settings\All
> Users\Application Data
>
> WE::CSIDL_COMMON_DOCUMENTS equate(02Eh) ! C:\Documents and Settings\All
> Users\Documents
>
> WE::CSIDL_LOCAL_APPDATA equate(01Ch) ! C:\Documents and
> Settings\username\Local Settings\Application Data
>
>
> What makes the difference?

You have to ask yourself the question "Does the user ever need to access
the data directly?"

If this answer is YES (maybe for backup or copying a file to send to you or
for ANY other reason) then the APPDATA folders are not what you want.



CSIDL_COMMON_AppData is a hidden system folder on Windows Vista which means
users can't see our installation directory or any files in it.

CSIDL_LOCAL_APPData is a personalized data folder for applications that do
not ROAM.

CSIDL_APPDATA is a personalized data folder for applications that do ROAM.



I posted these links a while back in the SetupBuilder NG. They are from
MSDN.

They have a good cross reference on the CSIDL entries (along with the new
REFKNOWNFOLDERID values introduced with Vista). They also show what
existed where (and on older OS's too).

Per machine values
http://msdn2.microsoft.com/en-us/library/aa370810.aspx

Per user values
http://msdn2.microsoft.com/en-us/library/aa370813.aspx




> Isn't CSIDL_COMMON_DOCUMENTS what we know as "My Documents" in the windows
> explorer?

Not really<g> - although they seem to be at first glance.

CSIDL_COMMON_DOCUMENTS points to:

C:\Documents and Settings\All Users\Documents (note the "All Users")


CSIDL_PERSONAL points to:

C:\Documents and Settings\Username\Documents (note the "Username")


When your logged in - your "My Documents" points to CSIDL_PERSONAL - for
the account your logged in as.



> A user can fiddle around there - and as they tend to pouch all their DOC
> and XLS and PPS and .... over there it soon gets crowded.

If you create a folder structure below that and warn your users to leave it
alone then your within your rights to charge big fees if they mess it up!



> APP_DATA is not that easily accessible for the sprightly user wouldn't it
> be a safer place?

See above - yes, but only if you do not need them to have access to it "at
all" except under the app control.

They will not be able to get to it in Windows Explorer.



> What if the data should be stored at another drive? (I personnaly love to
> store data on not-C: as I can simply push the entire drive onto a CD-R as
> a backup. Programs can be installed easily after a crash, but spreaded
> data [and data in a data-folder determined by the OS I would call
> lost-by-design as they are out of my control]...!

;-)

It is a tough call.

I'd say that the first stumbling block there is that you have no guarantee
that your users will have another drive.

When a new machine arrives today, it has a hard drive with ONE partition
and lots of preloaded software.

IMHO - users are NOT going to reformat their drives (or buy extra external
ones) just to run our programs.



A point worth considering here is that computers have changed.

A few years ago, we could "insist" that users reformat a drive to set
things up the way we want them.

Maybe you still can if your supplying the hardware.

But given that most OS installs (and subsequent program installs) could
take days to get in place and configured, it is not at all reasonable to
think that you can "force" the end user to your preferences.


Consider your own development machine.

What if buying Clarion7 required you to reformat your OS, install all your
programs again and give C7 its own "drive D" (or whatever)?

There would be a terrible outcry of "foul" and "what sort of crap is this?"

See what I mean?

;-)



Another thing to consider is that most of us developers "cheat" on our
network installs.

They are not really on "servers", but usually on a shared directory on one
of the machine drives (or on a non-server OS machine).

In that case, we have to play by the rules and from what I have seen in
threads at MSDN - the CSIDL_COMMON_DOCUMENTS is one that will share and
work in a LAN environment.


Of course the best solution for server data is to either get a real server.
Novell is still my #1 pick, but there are a lot of developers doing quite
well with a Linux box running SAMBA. It is fast, has no OpLocks problems
and beats the pants off a MS server for performance.



All of us have decisions to make - no doubt about it.

But by all means you should believe that our caviler days of sharing a
folder of our choice as the network drive for our apps are pretty much
over.

Microsoft has been weak on security for too long, but now that they are
fixing it - they are going to be typical Microsoft and go off the deep end
with how they do it.

All of us developers are simply adrift on their waters. So the best thing
that we can do is adopt their standards as our own and roll with the flow.

At least that will keep us out of harms way and allow us to concentrate on
the part of our development that we DO get paid for<g>.

Take care,

Charles





--
-------------------------------------------------------------------------------------------------------
Charles Edmonds

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]

> You have to ask yourself the question "Does the user ever need to access
> the data directly?"
>
> If this answer is YES

The answer is "you better get your fingers off that folder or I come with
the big clubber"


My main product is hospital software which has to be able to run on a
single non-network dopey-user machine as also on a network (Win / NovellNW
/ Citrix).

I serve a more or less anonymous market - I do not know anything about the
target systems.

Story beside the thread: my prog runs for 30 days in test-mode, sort of
shareware. After that period it needs a licence key, I guess you know what
I mean.

Step 1: type in the hospital address data

Because it might be installed on a single, non-network and therefore
non-internet machine I have a "Print Order" button.

Step 2: "Print Order to paper"

Step 2 (alternative) A: "Print Order to PDF"
Step 2 (alternative) B: "Send PDF-Order via E-Mail"


One IT-professional did this: he *_printed_* the order, *_scanned_* it,
*_saved_* it as PDF and then sent it as E-Mail..........

Now you know what sort of users I have to deal with! ;-)


You can imagine that under those circumstances I am glad that Vista is not
on the top of the list of the IT-departments over here as it is too
expensive.


and yes, next time we meet I owe you a beer




--
Grüße / Regards
Wolfgang Orth

http://www.odata.de


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

[NewsArchive]

Wolfgang
CSIDL_PERSONAL is the MyDocuments folder
Regards
Randy