Full Control to Users programmatically

Most programs (at least before Vista) use this design.
There should be some other solution not related to change the design, I
hope.
Thanks

Vovan

"Jack" wrote in message

>I guess you need to change the design.
> Do not use c:\program files folder.
>
> "vovan" wrote in message
>
>> My VB6 program is installed by setup created in InstallShield 12.
>> Before Vista everything was working fine.
>> On Vista one of the operations (replace file located in c:\program
>> files\my program with another file) fails - my research showed me than
>> there is an error 70, 'Access denied'
>> After I set manually Full Control to Users of that machine everything
>> works fine.
>> Any advice how to set Full Control to Users programmatically from VB6 or
>> from InstallShield project.
>>
>> Thank you
>> Vovan
>>
>
>
 >> Stay informed about: Full Control to Users programmatically 

I need a full control for Users on "C:\Program Files\My Program" folder.
I had it for more than 10 years with no problem (before Vista). What's wrong
with my wish now?
It looks like you lived your live with 2 legs, you drove many cars. Now
somebody created a new kind of car requirening you to have 3 legs. And they
say that it's much better for you not allowing you to have any choice. They
are going to replace all existing models with new ones.
I found some way (using Windows script) to give Users full control on
"C:\Program Files\My Program", not on entire "C:\Program Files\". Just on my
folder.
It looks like adjustment will take much less time than full redesign.
What is wrong with this approach?

Thank you
Vovan

"vovan" wrote in message

> My VB6 program is installed by setup created in InstallShield 12.
> Before Vista everything was working fine.
> On Vista one of the operations (replace file located in c:\program
> files\my program with another file) fails - my research showed me than
> there is an error 70, 'Access denied'
> After I set manually Full Control to Users of that machine everything
> works fine.
> Any advice how to set Full Control to Users programmatically from VB6 or
> from InstallShield project.
>
> Thank you
> Vovan
>
 >> Stay informed about: Full Control to Users programmatically 

> I found some way (using Windows script) to give Users full control on
> "C:\Program Files\My Program", not on entire "C:\Program Files\". Just on
my
> folder.
> It looks like adjustment will take much less time than full redesign.
> What is wrong with this approach?

That sounds like a good idea to me.
How do you achieve that?

(My best idea for a solution so far is a note saying
something like: "If you have the misfortune to be using
Windows Vista, and you want to use this software,
then you will need to give yourself permission to
fully use your PC."
 >> Stay informed about: Full Control to Users programmatically 

I created a function:
Public Function SetUsersPermission(strFolder As String) As Integer
'Call this function when a new folder is created in Coordinator Folder
'to give a Full Access to Users
Dim objShell As Object
Dim intRunError As Integer
On Error Resume Next
intRunError = 1 'in case of error that value will be returned
Set objShell = CreateObject("Wscript.Shell")
'objShell.Run returns 0 if success
intRunError = objShell.Run("cmd /c cacls " & strFolder & " /e /g
Users:F", 0)
SetUsersPermission = intRunError
End Function

I call it every time I'm creating a new folder which is going to be accessed
by my program to save there some file.

Vovan

"mayayana" wrote in message

>
>> I found some way (using Windows script) to give Users full control on
>> "C:\Program Files\My Program", not on entire "C:\Program Files\". Just on
> my
>> folder.
>> It looks like adjustment will take much less time than full redesign.
>> What is wrong with this approach?
>
> That sounds like a good idea to me.
> How do you achieve that?
>
> (My best idea for a solution so far is a note saying
> something like: "If you have the misfortune to be using
> Windows Vista, and you want to use this software,
> then you will need to give yourself permission to
> fully use your PC."
>
>
 >> Stay informed about: Full Control to Users programmatically 

That's interesting. Thanks. I assume that needs to be
run by Admin., but it seems like incorporating such
a thing into setup would be a good approach. (Hopefully
shelling to cacls rather than invoking script.)

I'm inclined to partly agree with the rather vociferous
Vista MVPs who are piping up here: People should
be informed and given an option about changing their
settings. But your idea makes a lot of sense to me
for adapting a Vista setup. Rather than moving eveything
to All Users App. Data (which doesn't make much sense)
maybe a checkbox option could be provided in setup.
Something like:

|_| Make this program fully available to all users.


> I created a function:
> Public Function SetUsersPermission(strFolder As String) As Integer
> 'Call this function when a new folder is created in Coordinator Folder
> 'to give a Full Access to Users
> Dim objShell As Object
> Dim intRunError As Integer
> On Error Resume Next
> intRunError = 1 'in case of error that value will be returned
> Set objShell = CreateObject("Wscript.Shell")
> 'objShell.Run returns 0 if success
> intRunError = objShell.Run("cmd /c cacls " & strFolder & " /e /g
> Users:F", 0)
> SetUsersPermission = intRunError
> End Function
>
> I call it every time I'm creating a new folder which is going to be
accessed
> by my program to save there some file.
>
 >> Stay informed about: Full Control to Users programmatically 

> Look guys,
>
> It has *never* been acceptable to MODIFY files in Program Files.
>
> Just because it WORKED in earlier version of Window doesn't mean it was
*OK*
> to do so!
>

We all know Microsoft's party line. What Microsoft
decides is "OK" is not particularly relevant here. They
designed a product. They sell it. Now people writing
software need to decide the best way to deal with it.

You know perfectly well that Program Files has always
been where most software worked out of until recently.
(After all, what point would there be to VB's App.Path
property if nothing there could be accessed? And very
few people other than corporate lackeys on workstations
run XP as anything other than admin.

It's not as simple as just "going along with the plan".
Even if you think that Microsoft's general plan makes
sense, it's only geared toward corporate users. Home
and small office users want functionality...they don't want
frivolous warnings...and they usually don't want settings
changing between users. So the challenge is to work
out the simplest way to seamlessly allow people to run
software that way, as unrestricted for all users.

I think that everyone wants to try to do that in a
standard way that makes it easy for users, but the
options in Vista for all-user-accessible software seem
to come down to either cutting the security in Program
Files or moving everything to All Users App Data. There
doesn't seem to be an option that's in accord with what
MS officially defines as "OK".
 >> Stay informed about: Full Control to Users programmatically 

Stefan Berglund wrote in


>
> microsoft has made the decision that your computer is no longer yours
> so your little rant looks really silly in light of the above ~VERY
> WELL DOCUMENTED~ articles. So blow it out your bilge pipes there
> mister mvp brown or whoever you are.
>
> If anything, the class action lawsuits are just beginning to brew so
> please stay posted for further developments. I thought it was my
> computer and not theirs but apparently they changed the rules and
> forgot to tell everyone which is not fair.

Let's look at this piece-by-piece....

Does the computer belong to you ?.........

Yes, the physical PC hardware does belong to you....you have/had a
receipt for it.

> Are they so arrogant that
> they think their OS
> can do whatever it wants to anyone's computer or
> are they just too lazy to lean how to do things properly?

Well it IS their OS. You have never 'owned' any version of a MS OS since
Bill Gates introduced software 'licensing' when MS-DOS was introduced.

You are purchasing the 'privilege' (sic) to use the OS on your own PC
hardware, but you do not 'own' the OS. You have already agreed that MS
still really owns the copy of the OS you are using, and since it is their
property, they can change things in it.

MS Windows is a commercial product, and therefore, as every commercial
product, it goes thru changes in it's product lifetime. It can actually
relate well to a long-life automobile line....there's the initial release
of the model, for a few model years there are some refinements, maybe
some trim changes, option pacakges maybe....little things. Then after 4
or 5 years, there's a new model of 'Whatever', with a 'new' body
style....same name though. Like the change from the late '70s Camaro
style, to the 80's version in '82. Still generally looks like a Camaro,
but a lot of the same parts don't fit. I couldn't use the same maintenace
regimen on the '82 fuel-injected system vs. the '76's carburated engine,
so the procedure must adapt.

Same principle...product design is driven by whatever is 'hot' at the
time. Some may see it as improvements, some not, but very rarely, can a
product be commercially successful if it never undergoes any change ?

While it's true there are commercial products that may haven't changed in
100 years or more, like salt, or beer, any complex product must evolve,
whether perceived good or bad, or it would not be able to exist in the
long-term. Let's see, for the same price, I can buy this new style car,
with options, fuel-injected, air-bags, ABS, etc., or a 1974 AMC Matador
replica, while still being brand new, lacks all newer technology. My
choice would be with the new technology.

(As a note, I am NOT defending MS on this matter, merely pointing out
that there's nothing you can do about it, it's just the basic principles
of marketing.)



>They will
> potentially alienate their customers at best and possibly set
> themselves up for a lawsuit at worst.

Alienate...sure...tick off...yes...but that doesn't matter...at this
juncture anyway, since there is no 'real' alternative for another OS.

Yeah, let's get Grandma to install Linux.....

User's made a choice back in the early '90s at the 'true' start of the
home PC boom, to go with Windows. If IBM would have been successful at
marketing OS/2 and IBM was now the PC OS king, everyone would feel the
same way about them as MS. Windows was the VHS and OS/2 the BetaMax.

The OEM's will continue to push Windows on the cheap PC market, and it
will spread, there's no way to stop it. It all starts at the OEM's....

> I just can't wait until Paul Clement has a go at this. Let's hear
> something cogent for a change, mister Paul, please.

> ---
> This posting is provided "AS IS" with no warranties and no guarantees
> either express or implied.
>
> Stefan Berglund
 >> Stay informed about: Full Control to Users programmatically 

On Sun, 11 Feb 2007 11:10:02 -0600, "Ralph"
wrote:
in

>Its over Stefan.
>
>-ralph
>

Sorry to see you go. Bye.
 >> Stay informed about: Full Control to Users programmatically 

"Jimmy Brush" schrieb im Newsbeitrag


[writing to Program Files]
> You do not "work around Windows" by subverting it!
> Software that does this is called 'malware'.
So MS-Office (prior 2007), MS VisualStudio (.NET too), etc.
is malware - good to know.

> Again, the problem here is that your are NOT FOLLOWING SPEC, ...
Ok, that is one point, but as everybody knows, exactly following
a SPEC in daily work comes near to go on strike.
That's one reason why people in their work always follow a
'common practice', wich is (more or less) based on the SPECs.
The OS-Vendor himself is responsible for great parts of those
"practical standards".
And if I look into \Program Files\Microsoft Office\Office\...
I find e.g. a 'System.mdw' there, wich stores security-related
things regarding the usage of Accesss-Databases (for all Users).

From my point of view there's no reason, to blame any developer
who was following MSs-"practical standards" and not MSs-
"SPECs" (SPECs can be changed the same way as practical
standards - but normally one is more secure, if he "does it the
same way as the vendor").

Now MS decided, to go the hard route (following their own
SPECs), wich means they have to pay the price (as well as all
other adopters of their earlier common practice) - e.g. VS 2005
had/has many problems to run under Vista.

> It's easy ... store data in per-user locations .
No that's not so easy.
Imagine an app (e.g. a FamilyAddresses.exe with a
'CommonAddresses.mdb') for wich every user of the
machine (the whole family) has to have Read *and*
Write-Access.
Where should the file 'CommonAddresses.mdb' has to
be placed?
In "AllUsers"?! - ok - but then only the owner (creator) of
this file has write-access to it.
This means, either FamilyAddresses.exe has to run under
an Admin-Account or an Admin allows write-access to
this single file in (and for) "AllUsers" explicitely.

Olaf
 >> Stay informed about: Full Control to Users programmatically 

"Jimmy Brush" schrieb im Newsbeitrag


> You're right about not all MS teams following SPEC
> in some circumstances, of course. And they are as
> much at fault (if not moreso!) than third party
> developers not following spec.
Yep - and my point was, that developers are somewhat
lost nowadays - should they follow MSs-SPECs/Rules/
Recommendations, or are they better advised, to follow
MSs own practice, to protect their (time-intensive)
investments best?

> As for a common addresses example, you could allow
> each user to add common addresses to the "common
> address list" ...
It was just an example for a Common-Writable-File (for
all users). There are many other examples for programs,
wich require write-access on a common used (DB-) File
for all users on a machine.

> ... however, as you mentioned the isolation between user
> accounts is enforced. One user's data cannot be modified
> by another user, unless the user is an admin and is running
> an administrative program.

And that "kicks out" a whole class of programs (unless they
are not "elevated" somehow), because there are many, many
scenarios, where more than one user wants to change Data
on the same Document- or DB-File.

I'm missing some clear recommendation for this special
case of "Collaborative-Apps".
Where to put those commonly used Data-Files on Vista
(wich need common Write-Access), so that Admin-Rights
for that class of Applications are not required.

Olaf
 >> Stay informed about: Full Control to Users programmatically 

"Jimmy Brush" schrieb im Newsbeitrag

> <snip>
> > Yep - and my point was, that developers are somewhat
> > lost nowadays - should they follow MSs-SPECs/Rules/
> > Recommendations, or are they better advised, to follow
> > MSs own practice, to protect their (time-intensive)
> > investments best?
>
> ... I think the example is clear: Follow SPEC and your App
> will be as future-proof as possible...

But that's exactly the problem (from a more general point
of view)...
SPECs, APIs, whole Programming-Languages can be
declared as "depreciated" by MS from one day to the other.

That's why developers have to make difficult decisions
these days.
IMO they are good advised, to look carefully, what MS
is saying they have to or should do and what MS itself is
doing regarding their own apps.

Olaf
 >> Stay informed about: Full Control to Users programmatically 

"Jimmy Brush" schrieb im Newsbeitrag


> If the user wants a document to be collaborative,
> they will put it in the Public Documents folder, sine
> that folder is shared (read/writable) with all
> the users on the computer.

Just tried exactly this (one or two weeks ago) on XP -
and it was *not* working for the normal/reduced
UserAccounts (works only for the XP-Advanced-Users).

Olaf
 >> Stay informed about: Full Control to Users programmatically 

"Jimmy Brush" wrote in message

> Look guys,
>
> It has *never* been acceptable to MODIFY files in Program Files.
>
> Just because it WORKED in earlier version of Window doesn't mean it was
> *OK* to do so!

Interesting, I wonder why MS SQL Server stores its database files in
C:\Program Files\Microsoft SQL Server\MSSQL$<instance name>\Data
They change a lot, one tune for the piper and one tune for everybody else!

Regards
Dave O.
 >> Stay informed about: Full Control to Users programmatically