Vista docs

[NewsArchive]

Hi Friedrich,

I feel that a much more practical approach in documenting how to
install for vista are needed for SB6.5. I have been through the help
in 6.5 and Jane's articles on ClarionMag and I can not find ANYWHERE a
recommendation on where and how to install datafiles for programs that
have a manifest asInvoker. To me this looks like a pretty common
thing to figure out so I would strongly suggest that you get some step
by step guides on how exactly to do this. It would save everybody,
including you, a lot of time and money chasing this down. Jane knows
this pretty well and writes pretty well about it, so why not hire her
to do some whitepapers or whatever for SB? How about a step by step
guide to create and deploy an install with 1 exe, 1 datafile and 1
registry entry that has to go into HKCU, where the installer runs
elevated but the exe needs to run asInvoker.

I've spent about a week of solid work on just chasing down Vista
installs. For an install that has 1 exe, 1 tps file and 5 or so RTF
files! While I'm no high-end geek, I know my way around computers
pretty well and I hate to think how people who are new to this feel
when they attempt this for the first time. It's taken me a week to
figure out an extermely simple demo install and I'm NOT there yet:(

IMO this needs much better documentation and a step by step
instructions to set up a simple install. What to do, where and why.
I'd be more than happy to do it if I could get a SINGLE install to
WORK correctly!!!<bg>

Sorry for the frustration, but I've spent close to $10K in time on
getting simple installs to work. THAT is rediculous!

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Could not agree more. "Chasing" is basically a great description......
and testing and testing and testing (or should I say trying).

I think in general the SetupBuilder docs need a lot more explanation
and clarity. Perhaps us users can contribute what we have found to
assist ?

Mike

[NewsArchive]

Michael,

> Could not agree more. "Chasing" is basically a great description......
> and testing and testing and testing (or should I say trying).

I would like to discuss this in more detail here on the NG (perhaps others
can also share their ideas). SetupBuilder is an installation system to
*install* applications. There is already a "Best Practices for Well-Behaved
Vista Application Installations" quick guide in the manual. There is also a
"Design Vista Applications and Installations with SetupBuilder" topic.

On Vista, you need a mixed-mode application that works in Administrator and
Standard User mode. I think it would be an overkill for our installation
system documentation to describe how to write a mixed-mode Vista
application. I have answered uncountable messages on the newsgroups with
regards to the optimal database location. Jane did the same. Even
Microsoft cannot (or does not) answer a "where to install my data files"
question. And there is no general answer to this question.

> I think in general the SetupBuilder docs need a lot more explanation
> and clarity. Perhaps us users can contribute what we have found to
> assist ?

Could you give a few examples. #1 priority is to have a top-notch product.
That includes the documentation. So any hint on where to start improving
the documentation is highly appreciated :)

Thanks,
Friedrich

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

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

I didn not mean ANY insult about the docs. I jsut find that I could use a
lot more conversational information on many of the items I am reading.

Please appreciate that we are all extremely busy. I think we all know that
it is important....and implied...that we sit down with the docs and learn
the system. But all the diverse areas of coding that we need to do is
overwhelming. In addition to design of our application we need to fully
understand each and every tool we have. It takes so much time.

I have asked you many questions which you have always more than generously
answered....as you ahve to everone who posts here. Those responses are
invaluable information and should be added into the docs.

I don't send all my questions because I am afraid I haven't read the docs
enough, and if I have I don't want to overload you.

You package is so amazing (I find more every week). There are just a lot of
areas where it would be nice to have more conversational type comments about
where and when you would want to use such and such.

There is a lot fo that already but more would be helpful.

With best regards,

Mike

[NewsArchive]

Hi Friedrich,

>*install* applications. There is already a "Best Practices for Well-Behaved
>Vista Application Installations" quick guide in the manual. There is also a
>"Design Vista Applications and Installations with SetupBuilder" topic.

Neither one of those topics discuss where to actually put data during
installation. The "Best practices" talks about C:\Users\UserAccount,
which is misleading because you cannot do that with your install, or
you'll end up with the mess that I'm in. I actually follwed that
advise exactly and it causes the problems that I had with data that
was not accessible by my program!

You also talk about mixed-mode applications. There are two references
found in the help, both state "recommended for mixed-mode application"
(#embed Vista manifest and Design Vista Applications and installs" and
neither explains it further. I did some research on the web and came
up with this page:

http://msdn2.microsoft.com/EN-US/library/bb325654.aspx
http://www.microsoft.com/downloads/details.aspx?FamilyID=ba73b169-a648-49af-bc5e-a2eebb74c16b&displaylang=en

That last one is a 92 page word document about application development
requirements for UAC.

Hope this helps:)

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> That last one is a 92 page word document about application development
> requirements for UAC.
>
> Hope this helps:)

Yes, I read the documents two years ago and then it took 15 more month to
make the SetupBuilder IDE "mixed-mode". I still have two minor Vista
compatibility issues in the latest build.

Friedrich

[NewsArchive]

Arnór,

I also linked to that 92-page article in my clarionmag pieces.

One (of many!) problems I've encountered is a certain "boneyard" element on
MSDN. It's hard to know during which iteration of which beta what was
written. Even though that article has a Feb 2007 revision date, it doesn't
even mention CSIDL_COMMON_DOCUMENTS.

Although I think the Vista Resource Kit has the best
post-release-to-manufacturing information, even it has one contradictory
statement about data storage locations.

Jane

[NewsArchive]

Hi Friedrich,

Here is another link:

http://msdn2.microsoft.com/en-us/library/aa905330.aspx

This page has quite a bit of useful information.

http://download.microsoft.com/download/d/9/b/d9beb875-bc1d-4338-a655-251f4f353b2e/top10wave.exe

This downloads an installer that installs a chm file with a lot of
interesting vista information and links.

While I certainly agree that most of this is _application_ stuff, not
installer stuff, I think it would be very beneficial to have those
links in the SB 6.5 docs to provide reference. This is something that
a lot of people will have to deal with and I think every bit of
help... helps<g>

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

First of all, Jane is a brilliant writer and she is the #1 Vista Guru.
Period <g>. She already wrote excellent Vista papers.

But I fear an "installation guide" would not be enough (we already have a
Vista installation guide in the manual). We all have to stop thinking in
XP - we have to think in Vista.

Don't get me wrong, but your installation works correctly! But your
application logic is suboptimal. For example, what happens if you run your
application ("asInvoker") under the JoeUser Standard User account 1)
un-elevated and 2) elevated.

Well, if you run it un-elevated (JoeUser just starts your app) then your
application has access to the JoeUser profile. No problem. What happens if
it is run elevated? That means, JoeUser decides to run it "as
administrator" under the Standard User account? Well, in this case, your
app has access to the Admins profile (and not the JoeUser profile)!

And again, you cannot write to HKCU from the installer. Not any
"requireAdministrator" application can write to HKCU. No, wrong!!! You
*can* write to HKCU, but the data will not end where you would expect it.
It's written to the administrator profile, not in the JoeUser profile! If
your "asInvoker" application (un-elevated) tries to access the data written
to HKCU, what surprise, it's not there. Because it's in the Admins HKCU.

So it's not an installation problem at all! You really have to provide a
"mixed-mode" application that works fine on Vista/Windows Server 2008 in
both Admin and Standard User modes.

Does the above make sense? If no, just ask.

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

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>So it's not an installation problem at all! You really have to provide a
>"mixed-mode" application that works fine on Vista/Windows Server 2008 in
>both Admin and Standard User modes.
>
>Does the above make sense? If no, just ask.

Sorry if I sound frustrated, I am<g> Mostly at myself for not being
careful to uninstall my original demo install from my admin account on
Vista which would have revealed this problem much sooner and it would
have been so much easier to deal with:(

It makes perfect sense, but IMO it doesn't really address the question
about where to put the installed datafiles. That IS an installation
issue IMO that is not dealt with in any of Jane's articles or in your
help that I can find. In your "Best practicse for well behaved
Vista..." you say:

"User data, templates, and application-created files all have proper
location in the \Users\Username directory" To me that translates to
the CSIDL_LOCAL_* folders

But if I put the files there, they are not there because of the
elevated installer and there is no way for me to get to them from the
non-elevated program.

I'm _not_ blaming you for this<bg>, this is a Vista mess, but I feel
that you could _help_ in some ways by addressing these issues better
in your help. I do not find this addressed _anywhere_ and even that
thread you pointed to is kind of wobbly and Matt states for example
that CSIDL_COMMON_Documents does not work on Server 2003, so where
should I put those files if the user is running that OS???

I also think that a simple example of a vista install would help - I
don't see any in the example folder...

After ripping through my CSIDL values, I wonder if the best place
wouldn't be CSIDL_COMMON_APPDATA, rather that CSIDL_COMMON_DOCUMENTS.
In Vista this resolves to C:\ProgramData

That way I could find it with my program and copy it to a local folder
if needed.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

>>Does the above make sense? If no, just ask.
>
> Sorry if I sound frustrated, I am<g> Mostly at myself for not being
> careful to uninstall my original demo install from my admin account on
> Vista which would have revealed this problem much sooner and it would
> have been so much easier to deal with:(
>
> It makes perfect sense, but IMO it doesn't really address the question
> about where to put the installed datafiles. That IS an installation
> issue IMO that is not dealt with in any of Jane's articles or in your
> help that I can find. In your "Best practicse for well behaved
> Vista..." you say:

Yes, perhaps an installation related question, but even Microsoft does not
answer it! I sent 20 emails to Microsoft support (during the last 20
months) and they always told me that they cannot answer that specific
data storage location question for Vista! "It's all on MSDN" they told
me.

Jane visited a Vista "Roll-Out Event" and she asked the very same data
storage locations. NO ANSWER!!! Let me repeat that. NO ANSWER!!! So what
can I, a person who has to reset and low-level format his brain twice an
hour, suggest? Even Microsoft does not have an answer.

> "User data, templates, and application-created files all have proper
> location in the \Users\Username directory" To me that translates to
> the CSIDL_LOCAL_* folders
>
> But if I put the files there, they are not there because of the
> elevated installer and there is no way for me to get to them from the
> non-elevated program.
>
> I'm _not_ blaming you for this<bg>, this is a Vista mess, but I feel
> that you could _help_ in some ways by addressing these issues better
> in your help. I do not find this addressed _anywhere_ and even that
> thread you pointed to is kind of wobbly and Matt states for example
> that CSIDL_COMMON_Documents does not work on Server 2003, so where
> should I put those files if the user is running that OS???

Matt is using SetupBuilder and of course, SetupBuilder can
CSIDL_COMMON_Documents on Server 2003 and Server 2008 <g>

> I also think that a simple example of a vista install would help - I
> don't see any in the example folder...

To be frank, it does not make a difference whether you are creating a 2000,
XP, or Vista installation. Only the data storage locations for Vista is
problematic. And even Microsoft... Okay, already said that.

The installation is absolutely no problem with SetupBuilder. Our own
SetupBuilder installer to install the SetupBuilder product does noting
magic. It installs on 98, NT, 2000, XP, 2003, Vista, 2008, 32-bit and
64-bit. The SetupBuilder compiler handles all this automatically. It's the
Clarion application that is mixed-mode. There is no Vista specific script
code in our own installation projects.

Friedrich

[NewsArchive]

Hi Friedrich,

>Jane visited a Vista "Roll-Out Event" and she asked the very same data
>storage locations. NO ANSWER!!! Let me repeat that. NO ANSWER!!! So what
>can I, a person who has to reset and low-level format his brain twice an
>hour, suggest? Even Microsoft does not have an answer.

Which is kind of scary when you think about it, but what the hey, it
makes it interesting<g>

>Matt is using SetupBuilder and of course, SetupBuilder can
>CSIDL_COMMON_Documents on Server 2003 and Server 2008 <g>

Cool! So I can forget about that:)

>The installation is absolutely no problem with SetupBuilder. Our own
>SetupBuilder installer to install the SetupBuilder product does noting
>magic. It installs on 98, NT, 2000, XP, 2003, Vista, 2008, 32-bit and
>64-bit. The SetupBuilder compiler handles all this automatically. It's the
>Clarion application that is mixed-mode. There is no Vista specific script
>code in our own installation projects.

That's exactly where I want to go as well so I'm trying to get this as
compatible with anything out there are possible, but I definitely DO
want it to work on Vista;)

Thanks for the help and I'll dig into this over the weekend and
hopefully have some solutions that will work - at least for me. Then
I'll try to write something up to put on Icetips and you'll be welcome
to have it if you want or put a link to it or...<g>

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Arnor,
Much as I sometimes get flak here for reference to Clarionmag articles (mine
or otherwise), I think you actually WILL find this addressed in my articles.
(Along with some detailing of my own struggle looking for answers to the
"where to put the data" question.) The last article was entirely devoted to
that issue...but I don't think Dave has updated his Vista e-book yet.

My trip to L.A. for a Microsoft Vista developers "rollout" event in February
was primarily so I could try to get some answers to "where to put the data".
"Go look on MSDN," said the 3437&**(S#$WvwX## woman! Argh!!

Anyway... back to your two installs.
Both evinced the same issue with over-the-shoulder. I skimmed your
back-and-forths with Friedrich in the other thread. Let me try to explain
in my words.

We are looking at two separate issues here.

One is permissions (being able to install to Program Files, being able to
write to certain areas of the registry, being able to write to certain data
folders)

Another is user profiles. (If I'm logged onto this computer under XP, "My
Documents" doesn't show the same things that Betty will see if she's logged
onto this computer. That's because I'm directed to "C:\Documents and
Settings\Jane\yadada" and she to "C:\Documents and Settings\Betty\yadayada."
Same thing under Vista.) CSIDLS exist to help programs and the OS reference
those specific locations generically.

When Betty, who is not an admin user, tries to install your demo, Vista
detects the requireAdministrator installer manifest (so far, so good). It
pops up the UAC screen.
In that Betty is not an admin, she can't just click "Continue". She needs
to supply an administrator name and password to authorize the installation
to continue. So I reach over her shoulder and type in Jane (goddess of
admins) and my password. Now the installation can continue.

But in that your installation program installs its sample data files within
a user profile rather than to a common area on the computer, the data gets
installed into Jane's profile rather than Betty's. That's what the CSIDL
you've chosen tells it to do.

Then when Betty tries to run your app, CSIDL\yada points to her profile.
There are no sample data files there in C:\users\Betty\yada. Because they
got installed into C:\Users\Jane\yadayada. Your program reads the CSIDL and
looks in Betty's profile (where there's no data). Even if somehow your
program did look to manipulate the data in Jane's profile, Betty doesn't
have permissions to do so.
This path issue would be the same on an XP machine if, say, Jane had been
logged on when the demo was installed and then Betty logged on and tried to
run it.

Likewise, if this were not a demo and Betty and Jane ever worked on the same
data, they would not see each other's changes. Jane's would get written to
a data folder inside Jane's profile, Betty's into hers.

So one determination a program needs to make is whether the data it uses is
specific to the logged-on user (in which case it should be within that
user's profile, to which the user has all needed permissions) or needs to be
accessed regardless of who's logged on. In the latter case, Vista's new
"Public" folder structure (which you find using CSIDL_COMMON_DOCUMENTS is
the preferred choice.) Pages 596 and onward of the (April 2007) Vista
Resource Kit address that. (At least, I'm able to read that into those
pages...LOL...)

One gotcha with the public folder is that Vista treats sharing it or any of
its sub-folders differently (again, illustrated in excruciating detail in my
last 2-part article). I find that a lot of people don't have a comfortable
understanding of how NTFS and share permissions interact (on Windows in
general, not just Vista).

You've written a CSIDL program. I wrote a crude one before I started my
Vista articles in February. But Randy Rogers posted a more elegant utility
in his Clarionmag article on dealing with INI files under Vista, so I now
just use his. When you're thinking of using a CSIDL for any reason, I'd
suggest that you run your CSIDL program and get the actual path on several
machines (at least one Vista and one XP). Then use Windows Explorer to
examine the permissions (both share and NTFS) on those folders. That's the
process I went through in trying to figure out what works and what doesn't.

BTW... thanks for trying to get me a job working for Friedrich <G>. I'm
honored to be mentioned in such company!

Jane

[NewsArchive]

> Hi Friedrich,
>
> I feel that a much more practical approach in documenting how to
> install for vista are needed for SB6.5. I have been through the help
> in 6.5 and Jane's articles on ClarionMag and I can not find ANYWHERE a
> recommendation on where and how to install datafiles for programs that
> have a manifest asInvoker.

Arnór,

I have read this whole thread (well, as of August 30 2007 - 1:38 PM EST),
and I would sum it up as follows:

"I've spent close to $10K in time"

Think about creating a commercial E-Book with your knowledge WITH practical
examples (practical Clarion app examples, practical SetupBuilder examples,
practical Armadillo examples, applying for Code Signing certificate
process, etc) AND make some money from going through the process!

Does it help if Friedrich includes some extra documentation about the
process - yes - but on a practical level - there is an extraordinary number
of issues to deal with with Vista installs - what should he cover, what
depth, how to illustrate, what example method...

Honestly, I think you could use your expertise, with others willing to
contribute to your product, and create a wealth of information, first and
foremost - helpful to Clarion Developers -

using your Icetips Utilities (to prepare Clarion Apps for better AppData
locations for Vista use - READ MORE sales in addition to the E-Book sales
potential!)

And ENHANCED utility programs such as a commercial version of Icetips
Special Folders to make the E-Book package more attractive to developers in
general - NOT just Clarion developers.

Just as LinderSoft has greatly benefitted by being at the forefront of
Vista Aware installers, and attracting others to their Setup Tools by
offering the discounted Code Sign certificate process (As Friedrich as
pointed out - "NOT a money maker for them" - but it sure doesn't hurt
drawing more in to look at and buy LinderSoft setup tools!)

- Your company could be at the forefront of helping developers transition
to Vista without the enormous learning curves you've gone through AND make
some profit by it!

JAT,
David


--
From David Troxell - Product Scope 32 PRO - Encourager Software
Clarion Third Party Profile Exchange Online
http://encouragersoftware.com/profile/clarlinks.html
http://www.encouragersoftware.com/
http://www.profileexchanges.com/blog/

[NewsArchive]

Hi Mike,

I really appreciate all the feedback. It's the most effective way to
improve the SetupBuilder product line.

Unfortunately, the SetupBuilder application is improving faster than the
documentation. We are still working hard one the "SetupBuilder Tips and
Tricks, How-To, and Beyond" papers and source code examples.

BTW, posting questions here on the community, so others can benefit from the
answers, is better than not asking ;-)

Thanks,
Friedrich

[NewsArchive]

Hi Jane,

>Much as I sometimes get flak here for reference to Clarionmag articles (mine
>or otherwise), I think you actually WILL find this addressed in my articles.
>(Along with some detailing of my own struggle looking for answers to the
>"where to put the data" question.) The last article was entirely devoted to
>that issue...but I don't think Dave has updated his Vista e-book yet.

The last article I'm seeing is about shares "Coping With Vista -
Creating Directory Shares" and most of it is about that topic, not
where to put data files. Am I missing something?

>accessed regardless of who's logged on. In the latter case, Vista's new
>"Public" folder structure (which you find using CSIDL_COMMON_DOCUMENTS is
>the preferred choice.) Pages 596 and onward of the (April 2007) Vista
>Resource Kit address that. (At least, I'm able to read that into those
>pages...LOL...)

What is really interesting is that on my 2 year old XP machine that I
have most of my tools installed on, including some new vista installs,
there is ONE folder there, Adobe PDF from about the time I bought the
computer. Nothing else has been installed into this folder.
CSIDL_COMMON_APPDATA is used byu some software, but the one that is
used most is CSIDL_APPDATA.

>just use his. When you're thinking of using a CSIDL for any reason, I'd
>suggest that you run your CSIDL program and get the actual path on several
>machines (at least one Vista and one XP). Then use Windows Explorer to
>examine the permissions (both share and NTFS) on those folders. That's the
>process I went through in trying to figure out what works and what doesn't.

Like I said, part of the problem I had was because I forgot to
uninstall the silly program installed under the admin account so it
left the datafiles there and the regular user installed program could
read them there. I compare the CSIDL on 3-4 machines but that doesn't
give me any information about what elevation is required on Vista to
read/write. I guess I could add an option to check read/write access.
And none of that helps in deciding really what is correct and since
not even MS will commit to stating what is correct, no wonder fools
like me can't figure it out<g>

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

I like that! Has the makings of a catchy tune.
"Fools like us... ".

You're right, Arnor... most of the article involved dealing with the Public
folder.
But the *point* of the document ("Executive Summary #1 at the beginning) was
"yes, use COMMON_DOCUMENTS AKA the Public folder for data that's not
specific to one user account." Everything else followed from that.

>I compare the CSIDL on 3-4 machines but that doesn't
> give me any information about what elevation is required on Vista to
> read/write.

Well... actually, it does. That's how I discovered, for example, that
default permissions within C:\ProgramData (on Vista, CSIDL_COMMON_APPDATA)
are that the creator/owner of a specific document or folder has full control
but other users are read-only.
I used the CSIDL to find what that path actually translates to on a given
OS, then looked at the default permissions on the folder(s).

Yes, a LOT of commercial software hasn't been following the "oh yeah we've
been telling you to do it this way for ten years, dummy" folder paths. Ever
notice where the default and sample data files go when you install MS SQL
Server? (c:\program files\ohBadBadBad) <G>

Jane

[NewsArchive]

Hi David,

>- Your company could be at the forefront of helping developers transition
>to Vista without the enormous learning curves you've gone through AND make
>some profit by it!

If you keep beating me over the head like this I'm going to either
have to do something about it or do something about you<vbg>

Wish I had an extra week in each day<g>

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

You've got a deal.

M

[NewsArchive]

Hi Jane,

>You're right, Arnor... most of the article involved dealing with the Public
>folder.
>But the *point* of the document ("Executive Summary #1 at the beginning) was
>"yes, use COMMON_DOCUMENTS AKA the Public folder for data that's not
>specific to one user account." Everything else followed from that.

But that is the whole thing and what confuses. I'm talking about
LOCAL data, not COMMON. I don't think it has been made very clear
(anywhere) that in an elevated installer you must plant in common
ground and then tell the poor peasants where to dig for their seed<g>

>Well... actually, it does. That's how I discovered, for example, that

Brilliant! Thank you for kicking my behind on that one. Don't know
why I didn't think of getting the properties of the folders!

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Arnór ... do I sense the slightest frustration level?? <G>

Now, let's not start bringing "local" into the conversation. That often,
but not always, means on a specific computer, in contrast to a "roaming user
profile" which is stored on a server so the user gets his same desktop and
same "my documents" folder regardless of which workstation he's logged onto.

I think we're still talking at cross-purposes, Arnór. This is not an
installer issue per se. It's a matter of dealing with Vista. It doesn't
matter whether stuff gets into places by a signed installer, a batch file,
unzipping an archive, or whatever. It comes down to access rights - what an
ordinary user can read and write to.
The elevated installer just lets you play parent for a few minutes, and put
stuff wherever you want it to be.
The one additional gotcha involves the "over-the-shoulder" matter I
described in this and your "access denied" thread. That situation is one in
which any user-specific CSIDL will be wrong during the time the setup
program is running, because it will be the CSIDL for the OTS admin rather
than for the intended user. But much of that individual user setup "should"
be configurable by your app, because the user has permissions to folders
within his own profile ("my documents", etc.) and within HKEYCurrentUser.
And I see Charles has posted another thread with an interesting approach.

Telling the peasants where to dig for their seed... ?? LOL... I
personally put the seeds somewhere and then say "press the Seeds button" <G>
I think there are a few decisions you need to make for each app before you
decide where to put the seeds. Err... data and stuff...
1. Is the data personal to each user? If so, use something within My
Documents or equivalent.
2. Is the data common to everybody who logs onto the computer? If so, use
COMMON_DOCUMENTS in Vista. This is the type of data many (most??) of us
would formerly have put into c:\Program Files\MyApp\MyAppData.
3. If the data is common to everybody who logs onto the computer, does
anybody on another locally networked computer also need access to it? If
so, there are a few gotchas with sharing and permissions for the Vista
"Public" folder that I chewed through in the latest CMag article.

BTW, there are those who advocate using cacls or icacls to create your own
permission structure on the folders your app uses. Depending on your target
audience (home users, corporate IT setups, military customers, whatever),
your ability to do that may be limited.


Jane

[NewsArchive]

Hi Jane,

>1. Is the data personal to each user? If so, use something within My
>Documents or equivalent.

Well it seems that _nobody_ uses My Documents! I have NO installs
(and I have installed a lot of software) that puts data there.

That is why I feel that CSIDL_LOCAL_APPDATA is a much better choice.
I can't install there, so I'll install into CSIDL_COMMON_APPDATA and
the first thing my program does is to copy the contents from
COMMON_APPDATA to LOCAL_APPDATA preserving the same folder structure
so it's easy for my installer and my app.

>2. Is the data common to everybody who logs onto the computer? If so, use
>COMMON_DOCUMENTS in Vista. This is the type of data many (most??) of us
>would formerly have put into c:\Program Files\MyApp\MyAppData.

See above. Why not COMMON_APPDATA? Everybody _should_ have access to
it and it seems the most logial choice to me.

>3. If the data is common to everybody who logs onto the computer, does
>anybody on another locally networked computer also need access to it? If
>so, there are a few gotchas with sharing and permissions for the Vista
>"Public" folder that I chewed through in the latest CMag article.

What about COMMON_APPDATA? That resolves to C:\ProgramData. Can you
not share that folder? (I have not gone through sharing on Vista at
all)

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

1. Not nobody uses My Documents.
See attached shot of my XP laptop (lots of subfolders in it).
And I mostly do my own thing. I make a separate c:\wordfil folder for my
Word docs, c:\excel for my .XLS docs, d:\setup for my SB projects, etc.
Most MS apps (everything in Office, Notepad, Wordpad, Paint, etc) default to
storing their data files there. Network Group Policy has special settings
so admins can transparently redirect My Documents to a network share. Makes
for easier backup (users backing up their desktops?? c'mon!) and less
network traffic than regular roaming user profiles.

2. "should" is my absolute least favorite word in the English language.
And there's access and there's access.
If you have a Vista box you haven't modified permissions on, right-click
C:\ProgramData. You'll find it's a hidden folder.
Create a folder in it.
Create two non-admin users (Tom and Harry). Log on as Tom. Create a text
document in c:\ProgramData\ArnorsFolder. Log off. Log on as Harry. Try to
read Tom's document (which you managed to find in that hidden folder... ).
No problemo. And the fact that it's hidden doesn't inhibit our apps because
we can find them ("we have the technology!")
Now try to modify Tom's document. Oops, Harry only has read-only access to
it.
Have Harry create a text document. Switch users and have Tom try to modify
it. No go.
Right-click C:\ProgramData . Go to Properties | Security. Note that
ordinary users have Read\List\Execute privileges. Creator Owner has full
control (click the Advanced button). Harry was the creator owner of the doc
he created. Tom of his. Each is just an ordinary user for documents
created by anybody else.

3. Yes, you can share C:\ProgramData. In fact, a bit more
straightforwardly than the Public folder.

Jane

[NewsArchive]

Hi Jane,

>1. Not nobody uses My Documents.

Sorry, I was referring to the COMMON_DOCUMENTS. I only have 1 folder
there "Adobe PDF". In LOCAL_DOCUMENTS (i.e. My Documents) I have
several folders, most notably from Adobe, SetupBuilder and Visual
Studio.

>Now try to modify Tom's document. Oops, Harry only has read-only access to
>it.
>Have Harry create a text document. Switch users and have Tom try to modify
>it. No go.
>Right-click C:\ProgramData . Go to Properties | Security. Note that
>ordinary users have Read\List\Execute privileges. Creator Owner has full
>control (click the Advanced button). Harry was the creator owner of the doc
>he created. Tom of his. Each is just an ordinary user for documents
>created by anybody else.

Makes sense. What I'm talking about is a temporary storage for
installed data files. I needed to figure out WHERE I can place them
so that no matter what user runs my program, my program (manifested
asInvoker) can grab those files and copy them. My guess is that when
copying they can not be copied with the NTFS permission. I'll be
using the SHFileOperation to copy and I think it copies without the
NTFS permissions by default so I think that should not cause problems.
Remember that ALL those installs are for Clarion programmers, so at
least some level of computer literacy is expected<g>

I think this is pretty much what Charles was describing and I think we
are all getting onto the same page, even though it may be starting to
get a bit torn at the edges<g>

How normal (well, relatively at least) people are supposed to figure
this mess out is beyond me;) I think my next computer is going to be
a Mac:)

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

> Hi Jane,

>>You're right, Arnor... most of the article involved dealing with the Public
>>folder.
>>But the *point* of the document ("Executive Summary #1 at the beginning) was
>>"yes, use COMMON_DOCUMENTS AKA the Public folder for data that's not
>>specific to one user account." Everything else followed from that.
>
> But that is the whole thing and what confuses. I'm talking about
> LOCAL data, not COMMON. I don't think it has been made very clear
> (anywhere) that in an

> elevated installer you must plant in common
> ground and then tell the poor peasants where to dig for their seed<g>

Arnór,

This is quite scarry actually, you and Jane are starting to sound quite
alike in your metaphors!

She recently told someone:

Open the refrigerator.
Then the crisper.

Then check c:\users\MyName\AppData\Roaming\Microsoft\Windows\ Cookies\Low

Perhaps a "Vista for Developers Dummies" book co-authored, and both of you
will have them rolling on the floor! :-D

David


--
From David Troxell - Product Scope 32 PRO - Encourager Software
Clarion Third Party Profile Exchange Online
http://encouragersoftware.com/profile/clarlinks.html
http://www.encouragersoftware.com/
http://www.profileexchanges.com/blog/

[NewsArchive]

> Hi David,
>
>>- Your company could be at the forefront of helping developers transition
>>to Vista without the enormous learning curves you've gone through AND make
>>some profit by it!
>
> If you keep beating me over the head like this I'm going to either
> have to do something about it or do something about you<vbg>

Arnór,

(as I always say - what good are your friends if you can't abuse them once
and a while...)

;-)

Charles


I think Charles has it just about right! :-D

David


--
From David Troxell - Product Scope 32 PRO - Encourager Software
Clarion Third Party Profile Exchange Online
http://encouragersoftware.com/profile/clarlinks.html
http://www.encouragersoftware.com/
http://www.profileexchanges.com/blog/

[NewsArchive]

>
>> I think in general the SetupBuilder docs need a lot more explanation
>> and clarity. Perhaps us users can contribute what we have found to
>> assist ?
>
>Could you give a few examples. #1 priority is to have a top-notch product.
>That includes the documentation. So any hint on where to start improving
>the documentation is highly appreciated :)

It's been a while since I worked with it so I don't recall specific examples.
As I recall so many times (most times) the help was very terse. You look up the
help for XYZ and it basically says "this is where you enter XYZ". There are few
other hints as to why, when or what XYZ is used for. Almost never examples or
example code. Again, it's been a while. The developer I had doing this (I just
helped solve problems) jumped into it without reading the docs. That's a poor
way to learn a new tool and not what I would have done, but I would guess its
fairly typical for installer software.

I recall having trouble figuring the code signing configuration. I just viewed
the help for "code-sign application" which documents the dialog. I think this
dialog is NOT used for signing the setup.exe, but it does not mention that any
where, nor have a link to info on that.

E.g. "file name" says "String that specifies the path and file name of the file
to code-sign." That's somewhat terse. What file typically is used here? The
Setup.exe or the shipping MyApp.exe.

"Web URL" says "Enter your company's web address." why??? what's is used for?
It gets embed into the certificate and displayed to the viewer.

"Permanent" a good example says "Mark this box to process after script compilation"
Why / when would this be used?

There is no link to a general topic describing code siging and the files and
methods required.

-----------
Carl Barnes
www.carlbarnes.com
Maker of CW Assistant, Clarion Source Search,
CHM4Clarion - Add Html Help to C5, 5.5, 6 and 7 with just 4 lines of code

[NewsArchive]

Hi Carl,

Hmm, not sure, but I think you have an outdated manual or online help?

Just for the records. The "#code-sign application" function says that it
can be used to add an Authenticode® digital signature to an application
file. It does not say "installation file".

And the documentation for "Permanent" states:

If this checkbox is not marked, the compiler leaves the original File Name
file untouched. The compiler creates a temporary copy of File Name and after
script compilation restores it to the original. If you wish to permanently
code-sign an application (File Name stays code-signed after the compilation
process), mark this this checkbox.

Then here is a direct link to "Security Services". This gives a brief
description of code-signing certificates.

And in the "Windows Basics" topic there is a full Authenticode article.

But I fully agree that there is still enough room for improvements. Thank
you for your feedback!

Friedrich