A-cotton-pickin'-men! (Amen, with feeling) I'm a systems admin and
productions application support specialist for a large printing firm. I have
been threatening the people who vend bindery production software with a
Louisville Slugger for YEARS. The idiots keep on storing any damned thing
they want any damned where they want and then try to blame Microsoft (or me,
if they don't value their lives) when their CRAPware fails because I make
the end users live with restricted user permissions.

I'm so tired of waging this little war that I'm about to throw in the
towell. I should just give everyone local admin and let 'em have at it so
that management could see how long their network will last under the
circumstances the software vendors are trying to create. Heh. The only two
malware detections we ever had on this network came from the vendors
technical field reps sticking infected CDs written on their notebook's
burners into machines on the network. We weren't infected, but we were
notified. Of course the same morons also tried plugging their notebooks INTO
THE NETWORK WITHOUT PERMISSION after they were notified that their CDs were
infected.

These same geniuses write their software from such a perversely
self-centered point of view that it often simply disables other important
software or system functions. They seem to think that any computer on which
their junkware is installed must be devoted SOLELY to running the junkware.
They seem genuinely puzzled when anyone takes exception to that point of
view.

All I can say to Microsoft, regarding UAC and the better (but not yet
perfect) security model in Vista -- it's about time! Now, if you'd just grow
a pair and turn off the ability to disable UAC...


"Jimmy Brush" wrote in message
...
snip
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.

Nonsense.

You are writing software that BUILDS ON TOP of Windows. You are REQUIRED
to follow the specifications of that system ("What Microsoft decides is
'OK'"), whether you like it or not. If you find some way to do something
that is "out of spec" (such as writing to Program Files) that works (as it
did in XP when the user was admin), it is AT YOUR OWN PERIL that you
perform such behavior.

The fact that a non-compliant behavior may have worked before certainly
does not make the behavior OK, and definately doesn't justify you TRYING
TO FORCE IT TO WORK when Windows changes.

You do not "work around Windows" by subverting it! Software that does this
is called 'malware'.

You know perfectly well that Program Files has always
been where most software worked out of until recently.

Rediculous. "My Documents" and other special shell locations have been set
up for application's usage SINCE WINDOWS 98.

Only broken apps saved state to Program Files.

The current Windows filesystem security structure has been in place with
little modification since Windows 2000. It is now 2007. This isn't a big
secret - look on MSDN and there is MUCH DETAIL on each system location in
Windows, what goes there, who can access it, and how much access they
have.

(After all, what point would there be to VB's App.Path
property if nothing there could be accessed?

The stuff there can be accessed. You just can't write to it. There are
API's to determine what access you can get to files; Use them

And very
few people other than corporate lackeys on workstations
run XP as anything other than admin.

Your point here is that "well, since most people are admin, why should I
worry about following the spec... I'll just do it this non-compliant way,
since it will work most of the time".

Again, the problem here is that your are NOT FOLLOWING SPEC, and if you
release code that doesn't follow spec you run the risk of Microsoft
breaking your program every time they release a hotfix, service pack, or
new version.

Well, it finally happened ... you bet and lost ... now you have to deal
with it.

In Windows Vista, ALL non-admin programs are running in a limited account,
even if the user that started them is an admin.

Non-administrative applications that follow spec are not affected by this
change.

Administrative programs only need to be changed to prompt the user for
permission, and they will work fine.

Non-administrative applications that DO NOT follow spec MUST BE MODIFIED
TO CONFORM to the already well-published spec in order to run on the new
OS.

It's not as simple as just "going along with the plan".

Of course it is. Your application must interface with Windows the way
Microsoft requires it to.

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.

Ignoring the fact that you are making a wide, sweeping claim about ALL
USERS which, besides being unsubstantiated, cannot possibly be true...

The reality of the situation is:

1) The people that only want to use ONE ACCOUNT, will only USE one
account.

2) The people that want to use MORE THAN ONE account, will.

In *ALL* cases, your app WORKS CORRECTLY if it ONLY writes data to
per-user locations.

You have NO REASON to store data in Program Files.

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".

It's easy ... store data in per-user locations .

In Windows, each user account is completely isolated from the next. One
user cannot mess with another user's or the system's stuff. Only ADMINS
can do that. Any program that wants to do this MUST be allowed to run by
an admin, or must be running as part of the operating system (like a
windows service does).

This is the way Windows is architected, and so your app MUST follow this
design pattern.

If your program has a legitimate need to be mucking around in Program
Files, then it is an administrative program, and must require admin
permission from the user before mucking around with those files.

Or, if the chunk of your program that is needing access to the program
files folder is really an extension to the OS, then it needs to be written
as a Windows Service.

The days of Windows ME where applications did whatever the heck they felt
like at the expense of stability, user control, and security are over.

Sorry .

--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

Yes, indeed! I responded in kind to Jimmy Brush and wished to record my
approval of your message, too. "Programmers" take note. Users who have any
sophistication at all in matters of system behavior and security can tell
the difference between programmers who know what they're doing and all of
the slop-shot artists. If you think you own an system directory or anything
which lies below it in the file structure -- think again! That belongs to
the OS and to the user who uses the OS, and it is NOT up to you to decide to
screw with security settings there! (or any danged where else, for that
matter)

"Kerry Brown" *a*m wrote in message
...
"mayayana" wrote in message
.net...
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".




Who's computer are you writing the program for yours or your customers? If
it's yours do whatever you want. If it's a customers then if you want to
keep the customer you don't mess up their computer. Windows programmers
are lazy and have learned many bad habits over the years because it
worked. It no longer works. There are shims in Vista to allow you to
quickly get your program working. Once you have it working rewrite it to
work properly. Note that anyone who did this from the start wouldn't be
having these problems. If you program around the OS your program will
break again and again as service packs and new versions of the OS are
released. If you hard code paths you will always have problems. You should
be querying environment variables which have remained consistent since NT.
You should expect that your program doesn't have complete control of the
computer as in most OS' this is true. You should expect that your program
may be used by multiple users and may be networked. There is a reason
Microsoft officially defines "OK". It's to make sure programs run as the
OS is updated. Take a look at a user profile on an XP computer and see
where most programs store their settings and data. If you had done this
using environment variables to get the path you wouldn't be having
problems now. What it comes down to in the end is how many times do you
want to fix your program. Do it right and it won't break. Do it wrong and
it will break inconveniencing you and your customers.

--
Kerry Brown
Microsoft MVP - Shell/User
http://www.vistahelp.ca

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

"Stefan Berglund" wrote in message
...
On Sat, 10 Feb 2007 10:46:32 -0800, "Kerry Brown"
*a*m wrote:
in

Why would you want to risk doing this? What will happen when some user
finds
out you modified their system needlessly and lowered their security. It
is
their computer not yours. Are you so arrogant that you think your program
can do whatever it wants to someone else's computer or are you just too
lazy
to lean how to do things properly? You will potentially alienate your
customers at best and possibly set yourself up for a lawsuit at worst.
Vista
is here. Learn to program for it.

--
Kerry Brown
Microsoft MVP - Shell/User
http://www.vistahelp.ca

Ha ha ha. That wouldn't normally be so offensive but for this:

http://hairyears.livejournal.com/101843.html

and this:

http://www.cs.auckland.ac.nz/~pgut00...ista_cost.html

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. 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? They will potentially
alienate their customers at best and possibly set themselves up for a
lawsuit at worst.

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

"I thought it was my computer and not theirs but apparently they changed the
rules and forgot to tell everyone which is not fair."

Actually Microsoft has been writing the message on the wall in clear glowing
letters for quite some time now. I can say that now, as hind-sight is always
twenty-twenty. Unfortunately most of us either ignored it or didn't want to
believe it.

[I for one, with perhaps far less excuse than anyone in this group, found
myself outside the door asking "Tell me it ain't so Joe" when they killed
VB. Yet in looking back I realize I had a front-row seat at the death bed
when they called for the undertaker. (The fact they never even seeked
medical assistance should have been enough.) So I definitely place myself in
the majority.]

I consult for a company that prides itself on "vendor-independence". Carries
it to a religious dogma. Yet there isn't a single project in the joint that
isn't tied to at least 3 to 5 major subscription or licensing agreements.
Just for grins I sat down one day and taking a project that was easily
within the ability of a small ISV to reproduce, I calculated the amount of
money she would have to pay out for just software/hardware licensing, to
recreate it. I was close to two hundred thousand and still counting. In
comparison the few hundred you pay to have it bundled within a single O/S is
chump-change.

It isn't YOUR computer and it isn't YOUR software. And hasn't been for a
very long time. Read the EULAs, about the only thing you ever had any
"rights to" was when to turn the computer on and when to turn it off.

"If anything, the class action lawsuits are just beginning to brew so please
stay posted for further developments"

Pure wishful thinking. Ain't going to happen. People said the same when they
killed VB - and we all have seen what "further developments" have brought.

It is all being driven by billion-dollar companies, their little blackboxes,
and petty turf wars. Take heart that you will be able to some day boor your
grandchildren with stories about kernal hacks and assembly, much like I boor
my children today with talks about building super-hetrodyne receivers out of
oatmeal boxes. With an equal amount of relevance to their world.

Its over Stefan.

-ralph

Hello,

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.

As for a common addresses example, you could allow each user to add common
addresses to the "common address list" or remove addresses that they
themsleves added, but not modify addresses that other people have added.
This could be accomplished technically by having a seperate data file for
each user in the per-machine storage area (%allusersprofile%, or
C:\ProgramData in vista).

Sharing data between users on the system is possible using the per-machine
storage area, 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.

--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

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

Its over Stefan.

-ralph


Sorry to see you go. Bye.

"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

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.


--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

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?

Well,

Since the groups in MS that did NOT follow SPEC now have to hussle and
bussle to get their app IN SPEC to work with Vista, I think the example is
clear: Follow SPEC and your App will be as future-proof as possible. DON'T
follow spec and you're up a creek, just like some groups in MS were.

It may appear to be "time saving" to do whatever works without regard to
SPEC; but, this is only true in the short term, as both MS and the OP found
out.


--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

"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