very troubling s running vista beta

If this is the wrong NG to post this please point me to the correct place...
I've had a few people try my VB app on Vista Beta installations. One of the problems I'm seeing is that my app can't seem to write information to the installation folder. Yet no error is being raised when it tries to write out information. As far as the app is concerned there's no problem. I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.
This really has me troubled. I don't have a Vista Beta installation of my own to test with. My app writes both a log file and the user's data file to the installation folder by default. Not only that, my app frequently needs to be updated. I handle this through a utility that downloads the newer ..exe and deletes the old. If it can't download and write out the new .exe then my app can't be updated! I can handle (though not be happy with) the need to write both the log and data file to the \Documents and Settings\(user name)\Application Data\ folder if Microsoft forces me to do so. But if the app can't be updated I'm really in a world of hurt.
Has anyone else encountered this problem? Anyone know why an app would not be allowed to write data to its installation folder yet not get an error from Vista when it isn't allowed to do so?

This is really a developer issue, its best if you post it at the following link: http://forums.microsoft.com/msdn/showforum.aspx?forumid=120&siteid=1 -- -- Andre Windows Connect | http://www.windowsconnected.com Extended64 | http://www.extended64.com Blog | http://www.extended64.com/blogs/andre http://spaces.msn.com/members/adacosta
"Dan" wrote in message

If this is the wrong NG to post this please point me to the correct place...
I've had a few people try my VB app on Vista Beta installations. One of the problems I'm seeing is that my app can't seem to write information to the installation folder. Yet no error is being raised when it tries to write out information. As far as the app is concerned there's no problem. I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.
This really has me troubled. I don't have a Vista Beta installation of my own to test with. My app writes both a log file and the user's data file to the installation folder by default. Not only that, my app frequently needs to be updated. I handle this through a utility that downloads the newer .exe and deletes the old. If it can't download and write out the new .exe then my app can't be updated! I can handle (though not be happy with) the need to write both the log and data file to the \Documents and Settings\(user name)\Application Data\ folder if Microsoft forces me to do so. But if the app can't be updated I'm really in a world of hurt.
Has anyone else encountered this problem? Anyone know why an app would not be allowed to write data to its installation folder yet not get an error from Vista when it isn't allowed to do so?

It could be related to File (and Registry) Virtualization.
Quote from http://windowsconnected.com/blogs/jerry/archive/2005/12/19/86.aspx :
When an application attempts to do something "bad" like write to an INI file like "C:\Program Files\PoorlyBehavedApp\Options.ini", Windows will detect that the user's token does not grant them access to save to that location. Instead, it will copy the existing file (if it already exists) to "C:\Users\<your_account>\AppData\Local\VirtualStore\Program Files\PoorlyBehavedApp\Options.ini". It will then allow the write operation to succeed to this new file in the VirtualStore folder. Subsequent read operations for that file will always preferentially use the copy in the VirtualStore. Here's a simplified flow chart outlining these read and write operations.
"Dan" wrote in message

If this is the wrong NG to post this please point me to the correct place...
I've had a few people try my VB app on Vista Beta installations. One of the problems I'm seeing is that my app can't seem to write information to the installation folder. Yet no error is being raised when it tries to write out information. As far as the app is concerned there's no problem. I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.
This really has me troubled. I don't have a Vista Beta installation of my own to test with. My app writes both a log file and the user's data file to the installation folder by default. Not only that, my app frequently needs to be updated. I handle this through a utility that downloads the newer .exe and deletes the old. If it can't download and write out the new .exe then my app can't be updated! I can handle (though not be happy with) the need to write both the log and data file to the \Documents and Settings\(user name)\Application Data\ folder if Microsoft forces me to do so. But if the app can't be updated I'm really in a world of hurt.
Has anyone else encountered this problem? Anyone know why an app would not be allowed to write data to its installation folder yet not get an error from Vista when it isn't allowed to do so?

Hopefully though, someone might have an answer here, so stick around, Zack might be able to help. :) -- -- Andre Windows Connect | http://www.windowsconnected.com Extended64 | http://www.extended64.com Blog | http://www.extended64.com/blogs/andre http://spaces.msn.com/members/adacosta
"Dan" wrote in message

If this is the wrong NG to post this please point me to the correct place...
I've had a few people try my VB app on Vista Beta installations. One of the problems I'm seeing is that my app can't seem to write information to the installation folder. Yet no error is being raised when it tries to write out information. As far as the app is concerned there's no problem. I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.
This really has me troubled. I don't have a Vista Beta installation of my own to test with. My app writes both a log file and the user's data file to the installation folder by default. Not only that, my app frequently needs to be updated. I handle this through a utility that downloads the newer .exe and deletes the old. If it can't download and write out the new .exe then my app can't be updated! I can handle (though not be happy with) the need to write both the log and data file to the \Documents and Settings\(user name)\Application Data\ folder if Microsoft forces me to do so. But if the app can't be updated I'm really in a world of hurt.
Has anyone else encountered this problem? Anyone know why an app would not be allowed to write data to its installation folder yet not get an error from Vista when it isn't allowed to do so?

Dan wrote:

If this is the wrong NG to post this please point me to the correct place...
I've had a few people try my VB app on Vista Beta installations. One of the problems I'm seeing is that my app can't seem to write information to the installation folder. Yet no error is being raised when it tries to write out information. As far as the app is concerned there's no problem. I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.
This really has me troubled. I don't have a Vista Beta installation of my own to test with. My app writes both a log file and the user's data file to the installation folder by default. Not only that, my app frequently needs to be updated. I handle this through a utility that downloads the newer .exe and deletes the old. If it can't download and write out the new .exe then my app can't be updated! I can handle (though not be happy with) the need to write both the log and data file to the \Documents and Settings\(user name)\Application Data\ folder if Microsoft forces me to do so. But if the app can't be updated I'm really in a world of hurt.
Has anyone else encountered this problem? Anyone know why an app would not be allowed to write data to its installation folder yet not get an error from Vista when it isn't allowed to do so?

Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.
I don't know about application updates - but I imagine that MS have something in place for this scenario too.
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

"Andre Da Costa [Extended64]" wrote in message

This is really a developer issue, its best if you post it at the following link: http://forums.microsoft.com/msdn/showforum.aspx?forumid=120&siteid=1

Thank you for the link!

I don't know about application updates - but I imagine that MS have something in place for this scenario too.

You can do this using Visual Studio 2005, and the "Publish" settings of your application. You can configure your applications to look on a web server to download the latest build of your product - it's really easy to set up, and with Windows Server 2003 running with IIS, work's an absolute treat.

It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.

Couldn't have said it better myself :o) So yeh, if you can get TechNet or TechNet Plus, you can then get yourself a copy of Vista to test with. If you check out the UAP Guidelines, http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx - you might find that useful.
All the best :o)
-- Zack Whittaker Microsoft Beta (Windows Server R2 Beta Mentor) » ZackNET Enterprises: www.zacknet.co.uk » MSBlog on ResDev: http://msblog.resdev.net » ZackNET Forum: www.zacknet.co.uk/forum » VistaBase: www.zacknet.co.uk/vistabase » This mailing is provided "as is" with no warranties, and confers no rights. All opinions expressed are those of myself unless stated so, and not of my employer, best friend, mother or cat. Let's be clear on that one!
--- Original message follows --- "Steve Foster [SBS MVP]" wrote in message

Dan wrote:
If this is the wrong NG to post this please point me to the correct place...
I've had a few people try my VB app on Vista Beta installations. One of the problems I'm seeing is that my app can't seem to write information to the installation folder. Yet no error is being raised when it tries to write out information. As far as the app is concerned there's no problem. I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.
This really has me troubled. I don't have a Vista Beta installation of my own to test with. My app writes both a log file and the user's data file to the installation folder by default. Not only that, my app frequently needs to be updated. I handle this through a utility that downloads the newer .exe and deletes the old. If it can't download and write out the new .exe then my app can't be updated! I can handle (though not be happy with) the need to write both the log and data file to the \Documents and Settings\(user name)\Application Data\ folder if Microsoft forces me to do so. But if the app can't be updated I'm really in a world of hurt.
Has anyone else encountered this problem? Anyone know why an app would not be allowed to write data to its installation folder yet not get an error from Vista when it isn't allowed to do so?
Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.
I don't know about application updates - but I imagine that MS have something in place for this scenario too.
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

Is it that thing called Click Once? I remember Microsoft pushing it a lot at PDC 2003. -- -- Andre Windows Connect | http://www.windowsconnected.com Extended64 | http://www.extended64.com Blog | http://www.extended64.com/blogs/andre http://spaces.msn.com/members/adacosta
"Zack Whittaker (R2 Mentor)" wrote in message

I don't know about application updates - but I imagine that MS have something in place for this scenario too.
You can do this using Visual Studio 2005, and the "Publish" settings of your application. You can configure your applications to look on a web server to download the latest build of your product - it's really easy to set up, and with Windows Server 2003 running with IIS, work's an absolute treat.
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
Couldn't have said it better myself :o) So yeh, if you can get TechNet or TechNet Plus, you can then get yourself a copy of Vista to test with. If you check out the UAP Guidelines, http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx - you might find that useful.
All the best :o)
-- Zack Whittaker Microsoft Beta (Windows Server R2 Beta Mentor) » ZackNET Enterprises: www.zacknet.co.uk » MSBlog on ResDev: http://msblog.resdev.net » ZackNET Forum: www.zacknet.co.uk/forum » VistaBase: www.zacknet.co.uk/vistabase » This mailing is provided "as is" with no warranties, and confers no rights. All opinions expressed are those of myself unless stated so, and not of my employer, best friend, mother or cat. Let's be clear on that one!
--- Original message follows --- "Steve Foster [SBS MVP]" wrote in message Dan wrote:
If this is the wrong NG to post this please point me to the correct place...
I've had a few people try my VB app on Vista Beta installations. One of the problems I'm seeing is that my app can't seem to write information to the installation folder. Yet no error is being raised when it tries to write out information. As far as the app is concerned there's no problem. I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.
This really has me troubled. I don't have a Vista Beta installation of my own to test with. My app writes both a log file and the user's data file to the installation folder by default. Not only that, my app frequently needs to be updated. I handle this through a utility that downloads the newer .exe and deletes the old. If it can't download and write out the new .exe then my app can't be updated! I can handle (though not be happy with) the need to write both the log and data file to the \Documents and Settings\(user name)\Application Data\ folder if Microsoft forces me to do so. But if the app can't be updated I'm really in a world of hurt.
Has anyone else encountered this problem? Anyone know why an app would not be allowed to write data to its installation folder yet not get an error from Vista when it isn't allowed to do so?
Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.
I don't know about application updates - but I imagine that MS have something in place for this scenario too.
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.

I sure hope this can be disabled - what a stupid idea.
--
Randy Birch MS MVP Visual Basic http://vbnet.mvps.org/
Please reply to the newsgroups so all can participate.

"Steve Foster [SBS MVP]" wrote in message

It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.

Oh yes, we can't let applications write to their own folder. Why if we let them do that... Actually, I don't see much reason why that should be a problem. Frankly, I don't see how it makes the system more secure. Just more difficult for developers like me. Sigh...

"Zack Whittaker (R2 Mentor)" wrote in message

I don't know about application updates - but I imagine that MS have something in place for this scenario too.
You can do this using Visual Studio 2005, and the "Publish" settings of your application. You can configure your applications to look on a web server to download the latest build of your product - it's really easy to set up, and with Windows Server 2003 running with IIS, work's an absolute treat.

Unfortunately I'm not developing with .NET. But how does this help even if I were? Are you saying the "publish" settings of my .NET app causes Vista to allow it access to write to the installation folder?

It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
Couldn't have said it better myself :o) So yeh, if you can get TechNet or TechNet Plus, you can then get yourself a copy of Vista to test with.

Unfortunately, I don't have a spare PC to install it to. I guess I'll have to cough up the money for a new development machine just to test Vista on.

check out the UAP Guidelines, http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx - you might find that useful.

Thanks! I'll have a look.

"Randy Birch" wrote in message

Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.
I sure hope this can be disabled - what a stupid idea.

Which is stupid? The idea of turning it off or the idea that it needs to be turned off? I honestly don't see how allowing an application that the user installed to write to the installation folder is a problem.

I honestly don't see how allowing an application that the user installed to write to the installation folder is a problem.

Exactly. My remark was aimed at the concept that the OS would prevent an installed app from writing to its own folder, ini file or whatever, and transparently relocate that file to another location.
--
Randy Birch MS MVP Visual Basic http://vbnet.mvps.org/
Please reply to the newsgroups so all can participate.

Kinda yeh... I didn't want to say it because it's not directly that as such... but weaves into it yeh.
-- Zack Whittaker Microsoft Beta (Windows Server R2 Beta Mentor) » ZackNET Enterprises: www.zacknet.co.uk » MSBlog on ResDev: http://msblog.resdev.net » ZackNET Forum: www.zacknet.co.uk/forum » VistaBase: www.zacknet.co.uk/vistabase » This mailing is provided "as is" with no warranties, and confers no rights. All opinions expressed are those of myself unless stated so, and not of my employer, best friend, mother or cat. Let's be clear on that one!
--- Original message follows --- "Andre Da Costa [Extended64]" wrote in message

Is it that thing called Click Once? I remember Microsoft pushing it a lot at PDC 2003. -- -- Andre Windows Connect | http://www.windowsconnected.com Extended64 | http://www.extended64.com Blog | http://www.extended64.com/blogs/andre http://spaces.msn.com/members/adacosta
"Zack Whittaker (R2 Mentor)" wrote in message I don't know about application updates - but I imagine that MS have something in place for this scenario too.
You can do this using Visual Studio 2005, and the "Publish" settings of your application. You can configure your applications to look on a web server to download the latest build of your product - it's really easy to set up, and with Windows Server 2003 running with IIS, work's an absolute treat.
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
Couldn't have said it better myself :o) So yeh, if you can get TechNet or TechNet Plus, you can then get yourself a copy of Vista to test with. If you check out the UAP Guidelines, http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx - you might find that useful.
All the best :o)
-- Zack Whittaker Microsoft Beta (Windows Server R2 Beta Mentor) » ZackNET Enterprises: www.zacknet.co.uk » MSBlog on ResDev: http://msblog.resdev.net » ZackNET Forum: www.zacknet.co.uk/forum » VistaBase: www.zacknet.co.uk/vistabase » This mailing is provided "as is" with no warranties, and confers no rights. All opinions expressed are those of myself unless stated so, and not of my employer, best friend, mother or cat. Let's be clear on that one!
--- Original message follows --- "Steve Foster [SBS MVP]" wrote in message Dan wrote:
If this is the wrong NG to post this please point me to the correct place...
I've had a few people try my VB app on Vista Beta installations. One of the problems I'm seeing is that my app can't seem to write information to the installation folder. Yet no error is being raised when it tries to write out information. As far as the app is concerned there's no problem. I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.
This really has me troubled. I don't have a Vista Beta installation of my own to test with. My app writes both a log file and the user's data file to the installation folder by default. Not only that, my app frequently needs to be updated. I handle this through a utility that downloads the newer .exe and deletes the old. If it can't download and write out the new .exe then my app can't be updated! I can handle (though not be happy with) the need to write both the log and data file to the \Documents and Settings\(user name)\Application Data\ folder if Microsoft forces me to do so. But if the app can't be updated I'm really in a world of hurt.
Has anyone else encountered this problem? Anyone know why an app would not be allowed to write data to its installation folder yet not get an error from Vista when it isn't allowed to do so?
Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.
I don't know about application updates - but I imagine that MS have something in place for this scenario too.
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

Well, it depends on what you're devloping in. Most software building applications have an "auto-update" feature in it... so it just depends on whether you can find it or not.
-- Zack Whittaker Microsoft Beta (Windows Server R2 Beta Mentor) » ZackNET Enterprises: www.zacknet.co.uk » MSBlog on ResDev: http://msblog.resdev.net » ZackNET Forum: www.zacknet.co.uk/forum » VistaBase: www.zacknet.co.uk/vistabase » This mailing is provided "as is" with no warranties, and confers no rights. All opinions expressed are those of myself unless stated so, and not of my employer, best friend, mother or cat. Let's be clear on that one!
--- Original message follows --- "Dan" wrote in message

"Zack Whittaker (R2 Mentor)" wrote in message I don't know about application updates - but I imagine that MS have something in place for this scenario too.
You can do this using Visual Studio 2005, and the "Publish" settings of your application. You can configure your applications to look on a web server to download the latest build of your product - it's really easy to set up, and with Windows Server 2003 running with IIS, work's an absolute treat.
Unfortunately I'm not developing with .NET. But how does this help even if I were? Are you saying the "publish" settings of my .NET app causes Vista to allow it access to write to the installation folder?
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
Couldn't have said it better myself :o) So yeh, if you can get TechNet or TechNet Plus, you can then get yourself a copy of Vista to test with.
Unfortunately, I don't have a spare PC to install it to. I guess I'll have to cough up the money for a new development machine just to test Vista on.
check out the UAP Guidelines, http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx - you might find that useful.
Thanks! I'll have a look.

Randy Birch wrote:

Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.

I sure hope this can be disabled - what a stupid idea.

Well, applications saving user-specific information in the application folder is also a stupid idea. That's what the users profile folder space is for.
Applications that assume they can do whatever they like is *so* Win31...
Really, this concept is not new - it's been around since NT4 and probably even NT3. In a sense, it would almost be better simply to fail the writes, except that application vendors would carry on with the current lazy answer "make your users local administrators", rather than getting with the program and making their applications well-behaved. At least MS are trying to provide a graceful (ish) solution that lets applications work, without forcing the administrative privilege escalation.
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

Dan wrote:

"Randy Birch" wrote in message Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.
I sure hope this can be disabled - what a stupid idea.
Which is stupid? The idea of turning it off or the idea that it needs to be turned off? I honestly don't see how allowing an application that the user installed to write to the installation folder is a problem.

Then why not set the ACLs accordingly during installation - 99% of applications that want to write to their own folder don't do this, they simply expect that users would be local administrators (and indeed if you call Tech Support the response is "oh yes, make users local administrators").
It's this abject failure on the part of developers that UAP is trying to help with.
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

Randy Birch wrote:

I honestly don't see how allowing an application that the user installed to write to the installation folder is a problem.
Exactly. My remark was aimed at the concept that the OS would prevent an installed app from writing to its own folder, ini file or whatever, and transparently relocate that file to another location.

Why should the application have the privilege of writing to its' own folder? It runs in the context of the user account that starts it, and inherits their permissions. Users should not generally have privileges to write to installation folders, only their own profile space. Ergo, that's where applications should be storing user data.
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

Dan wrote:

"Steve Foster [SBS MVP]" wrote in message
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
Oh yes, we can't let applications write to their own folder. Why if we let them do that... Actually, I don't see much reason why that should be a problem. Frankly, I don't see how it makes the system more secure. Just more difficult for developers like me. Sigh...

I expect that you use HKLM to store user information too, rather than HKCU when using the registry, right?
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

"Randy Birch" wrote in message

I honestly don't see how allowing an application that the user installed to write to the installation folder is a problem.
Exactly. My remark was aimed at the concept that the OS would prevent an installed app from writing to its own folder, ini file or whatever, and transparently relocate that file to another location.

I completely agree!

"Steve Foster [SBS MVP]" wrote in message

Randy Birch wrote:
I honestly don't see how allowing an application that the user installed to write to the installation folder is a problem.
Exactly. My remark was aimed at the concept that the OS would prevent an installed app from writing to its own folder, ini file or whatever, and transparently relocate that file to another location.
Why should the application have the privilege of writing to its' own folder?

Why shouldn't it? You need to have a good reason to take something away that was previously allowed. What's the good reason?

Users should not generally have privileges to write to installation folders only their own profile space.

Why shouldn't they? Again, you need a good reason before you take something away from the user.

"Steve Foster [SBS MVP]" wrote in message

Then why not set the ACLs accordingly during installation - 99% of applications that want to write to their own folder don't do this, they simply expect that users would be local administrators (and indeed if you call Tech Support the response is "oh yes, make users local administrators").
It's this abject failure on the part of developers that UAP is trying to help with.

When the user installs my app they are given the option to give either just their user account access to the software being installed or "any user on this machine" (I'm using Install Shield to build my setup). Yet regardless of which the user selects the app can't write to the installation folder when running on Vista. And that's the developer's (i.e. my) fault?

"Steve Foster [SBS MVP]" wrote in message

Randy Birch wrote:
Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.
I sure hope this can be disabled - what a stupid idea.
Well, applications saving user-specific information in the application folder is also a stupid idea. That's what the users profile folder space is for.

Then applications storing application specific information in the application folder must be a stupid idea too since that isn't being allowed either. Somehow the idea doesn't strike me as stupid. Scattering application related files to various locations on the hard drive when they could just as easily be stored in the application folder strikes me as stupid.

Really, this concept is not new - it's been around since NT4 and probably even NT3. In a sense, it would almost be better simply to fail the writes, except that application vendors would carry on with the current lazy answer "make your users local administrators", rather than getting with the program and making their applications well-behaved. At least MS are trying to provide a graceful (ish) solution that lets applications work, without forcing the administrative privilege escalation.

It isn't graceful(ish). It's a creator of confusion. I don't find confusion graceful at all. If an app tries to write to the installation folder than let it do so or don't let it. But don't trick it and the user into *thinking* the write worked when in fact it did not.

"Steve Foster [SBS MVP]" wrote in message

Dan wrote:
"Steve Foster [SBS MVP]" wrote in message
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
Oh yes, we can't let applications write to their own folder. Why if we let them do that... Actually, I don't see much reason why that should be a problem. Frankly, I don't see how it makes the system more secure. Just more difficult for developers like me. Sigh...
I expect that you use HKLM to store user information too, rather than HKCU when using the registry, right?

No, I don't. What's your point? That saving non-user related application data in the application folder is comparable to storing user specific information in the local machine node of the Registry? How's that?

Dan wrote:

"Steve Foster [SBS MVP]" wrote in message Randy Birch wrote:
I honestly don't see how allowing an application that the user installed to write to the installation folder is a problem.
Exactly. My remark was aimed at the concept that the OS would prevent an installed app from writing to its own folder, ini file or whatever, and transparently relocate that file to another location.
Why should the application have the privilege of writing to its' own folder?
Why shouldn't it? You need to have a good reason to take something away that was previously allowed. What's the good reason?

It's not allowed now, unless the user is a local administrator.
What's the good reason for allowing it? Users are supposed to be running applications, not installing them. Administrators install applications.

Users should not generally have privileges to write to installation folders only their own profile space.
Why shouldn't they? Again, you need a good reason before you take something away from the user.

It's not being taken away, ordinary users do not have privilieges to write to applications installation folders now. The question is why should an ordinary user have privileges to write to application installation folders?
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

Dan wrote:

"Steve Foster [SBS MVP]" wrote in message
Then why not set the ACLs accordingly during installation - 99% of applications that want to write to their own folder don't do this, they simply expect that users would be local administrators (and indeed if you call Tech Support the response is "oh yes, make users local administrators").
It's this abject failure on the part of developers that UAP is trying to help with.
When the user installs my app they are given the option to give either just their user account access to the software being installed or "any user on this machine" (I'm using Install Shield to build my setup). Yet regardless of which the user selects the app can't write to the installation folder when running on Vista. And that's the developer's (i.e. my) fault?

They probably can't in XP either, if the user is not a local administrator.
It's down to you (or InstallShield) to set ACLs appropriately if you really need an ordinary user to be able to modify the application installation.
Of course, the question then should be "why does an ordinary user need to modify the application installation?"
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

Dan wrote:

"Steve Foster [SBS MVP]" wrote in message Randy Birch wrote:
Vista has mechanisms to automatically redirect writes to an application folder to a folder within the user's own space. So you should find the log files have been auto-relocated to somewhere deep within \Users\<username>.
I sure hope this can be disabled - what a stupid idea.
Well, applications saving user-specific information in the application folder is also a stupid idea. That's what the users profile folder space is for.
Then applications storing application specific information in the application folder must be a stupid idea too since that isn't being allowed either. Somehow the idea doesn't strike me as stupid. Scattering application related files to various locations on the hard drive when they could just as easily be stored in the application folder strikes me as stupid.

Wouldn't this information be written at installation time, when the administrator credentials would support writing to the application installation?
If it's really necessary for an ordinary user to be making global changes that will affect other users (which is your implication), then set the ACLs accordingly during installation to allow ordinary users write privileges. Don't rely on them being granted wide-ranging administrative privileges (which is not a wise assumption).

Really, this concept is not new - it's been around since NT4 and probably even NT3. In a sense, it would almost be better simply to fail the writes, except that application vendors would carry on with the current lazy answer "make your users local administrators", rather than getting with the program and making their applications well-behaved. At least MS are trying to provide a graceful (ish) solution that lets applications work, without forcing the administrative privilege escalation.
It isn't graceful(ish). It's a creator of confusion. I don't find confusion graceful at all. If an app tries to write to the installation folder than let it do so or don't let it. But don't trick it and the user into thinking the write worked when in fact it did not.

That's the point - the write succeeds. And the application gets to read back what it wrote, exactly as expected. And yet the application installation is protected. Of course, application-specific changes that would impinge on other users don't get seen by them - effectively each user now gets their own set of global settings (but then, that comes back to should users be changing global settings that affect other users - isn't that work for administrators).
As fas as I can tell, if your application runs into trouble on Vista because of UAP, it probably runs into trouble on XP if the user is not a local administrator too. Do your applications run properly on XP without administrative privileges?
Have you come across http://www.threatcode.com ?
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

Dan wrote:

"Steve Foster [SBS MVP]" wrote in message Dan wrote:
"Steve Foster [SBS MVP]" wrote in message
It's all part of the UAP/LUA stuff - since users generally should not be running with administrative privileges, they don't have the right to write to an application's own folder, ergo an application loaded by them has the same restriction.
Oh yes, we can't let applications write to their own folder. Why if we let them do that... Actually, I don't see much reason why that should be a problem. Frankly, I don't see how it makes the system more secure. Just more difficult for developers like me. Sigh...
I expect that you use HKLM to store user information too, rather than HKCU when using the registry, right?
No, I don't. What's your point? That saving non-user related application data in the application folder is comparable to storing user specific information in the local machine node of the Registry? How's that?

Oh, it was really meant as a light-hearted rejoinder - you already have the position that ordinary users don't have the necessary privileges to write to an application's installation folder (unless the ACLs were set to allow it during installation), and that's been the case since the early NT days. Only the Win9x line allowed free rein (and that line ended some 5 years ago) since there was no security in Win9x.
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

"Steve Foster [SBS MVP]" wrote in message

Dan wrote:
When the user installs my app they are given the option to give either just their user account access to the software being installed or "any user on this machine" (I'm using Install Shield to build my setup). Yet regardless of which the user selects the app can't write to the installation folder when running on Vista. And that's the developer's (i.e. my) fault?
They probably can't in XP either, if the user is not a local administrator.

They almost always are a local administrator. I have a very large user base and almost never have reports of a problem in this area with XP users. But every Vista beta tester who tested my app had this same problem.

It's down to you (or InstallShield) to set ACLs appropriately if you really need an ordinary user to be able to modify the application installation.
Of course, the question then should be "why does an ordinary user need to modify the application installation?"

To update the software when an update is available. That is a fairly standard option in software today. Lots of software products have a "Check for program updates" option under their Tools or Help menus. And when a new free update is available the user is offered to automatically update. My anti-virus application does this frequently (not only virus definitions updates but also updates to the base application).
I have to wonder about this "why does the ordinary user need to..." line of reasoning. The real question is why the ordinary user should NOT be allowed to do it, not why they should. You don't take access away from a user without an explicit reason for doing so.

A possible solution for the update problem. Download your update as a msi or a setup.exe to your AppData folder then run it. I think Vista should then ask for admin rights at that point and your msi can do the update.
"Dan" wrote in message

If this is the wrong NG to post this please point me to the correct place...
I've had a few people try my VB app on Vista Beta installations. One of the problems I'm seeing is that my app can't seem to write information to the installation folder. Yet no error is being raised when it tries to write out information. As far as the app is concerned there's no problem. I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.
This really has me troubled. I don't have a Vista Beta installation of my own to test with. My app writes both a log file and the user's data file to the installation folder by default. Not only that, my app frequently needs to be updated. I handle this through a utility that downloads the newer .exe and deletes the old. If it can't download and write out the new .exe then my app can't be updated! I can handle (though not be happy with) the need to write both the log and data file to the \Documents and Settings\(user name)\Application Data\ folder if Microsoft forces me to do so. But if the app can't be updated I'm really in a world of hurt.
Has anyone else encountered this problem? Anyone know why an app would not be allowed to write data to its installation folder yet not get an error from Vista when it isn't allowed to do so?

"Chris Altmann" wrote in message

A possible solution for the update problem. Download your update as a msi or a setup.exe to your AppData folder then run it. I think Vista should then ask for admin rights at that point and your msi can do the update.

I've had another developer recommend that I add a manifest to my updater utility stating that it requires admin access. The user will get a warning asking whether or not to grant the app access every time it runs (which would only be when an update was being performed) and if they user says OK then it will work as it presently does now on all other Windows systems. I'm not thrilled with my users having to get past an OS warning but it looks like I'll have to go that route.

Dan wrote:

"Steve Foster [SBS MVP]" wrote in message Dan wrote:
When the user installs my app they are given the option to give either just their user account access to the software being installed or "any user on this machine" (I'm using Install Shield to build my setup). Yet regardless of which the user selects the app can't write to the installation folder when running on Vista. And that's the developer's (i.e. my) fault?
They probably can't in XP either, if the user is not a local administrator.
They almost always are a local administrator. I have a very large user base and almost never have reports of a problem in this area with XP users. But every Vista beta tester who tested my app had this same problem.

Exactly, so what happens if a user on XP is not a local administrator? I'm willing to bet that your application fails, and probably in exactly the same fashion as with Vista.
If your application was deployed in any organisation where I run the network, the users would most certainly *not* be local administrators (it's simply bad practice). Assuming or expecting users to have administrative privileges is extremely poor practice (though common!).

It's down to you (or InstallShield) to set ACLs appropriately if you really need an ordinary user to be able to modify the application installation.
Of course, the question then should be "why does an ordinary user need to modify the application installation?"
To update the software when an update is available. That is a fairly standard option in software today. Lots of software products have a "Check for program updates" option under their Tools or Help menus. And when a new free update is available the user is offered to automatically update. My anti-virus application does this frequently (not only virus definitions updates but also updates to the base application).
I have to wonder about this "why does the ordinary user need to..." line of reasoning. The real question is why the ordinary user should NOT be allowed to do it, not why they should. You don't take access away from a user without an explicit reason for doing so.

It's callled the Principle of Least Privilege. Security 101. You don't give users more privileges than they need without good reason.
You wouldn't routinely give employees access to absolutely everything in an office, would you? Why should the computer be any different?
-- Steve Foster [SBS MVP] --------------------------------------- MVPs do not work for Microsoft. Please reply only to the newsgroups.

"Steve Foster [SBS MVP]" wrote in message

Dan wrote:
"Steve Foster [SBS MVP]" wrote in message Dan wrote:
When the user installs my app they are given the option to give either just their user account access to the software being installed or "any user on this machine" (I'm using Install Shield to build my setup). Yet regardless of which the user selects the app can't write to the installation folder when running on Vista. And that's the developer's (i.e. my) fault?
They probably can't in XP either, if the user is not a local administrator.
They almost always are a local administrator. I have a very large user base and almost never have reports of a problem in this area with XP users. But every Vista beta tester who tested my app had this same problem.
Exactly, so what happens if a user on XP is not a local administrator? I'm willing to bet that your application fails, and probably in exactly the same fashion as with Vista.

Yet with over 35,000 users I hardly ever hear from a user who is having access rights issues. My product is a consumer product that 9 times out of 10 is used on a computer the user owns. For those who install it to a work PC reports of these problems are very very rare. So clearly Vista is different since now everyone is having these problems.

If your application was deployed in any organisation where I run the network, the users would most certainly *not* be local administrators (it's simply bad practice). Assuming or expecting users to have administrative privileges is extremely poor practice (though common!).

Expecting my users to have administrative access to theirs PCs is not a poor practice since it isn't an application that people would install on an company PC. If expecting an application to be able to write to it's installation folder is "extremely poor practice" then I suppose you are right. I need to bow to Microsoft's ridiculous limitations. I'm yet to hear a good reason why an application should not be permitted to write to its installation folder other than because Microsoft decided that is a bad practice.

It's down to you (or InstallShield) to set ACLs appropriately if you really need an ordinary user to be able to modify the application installation.
Of course, the question then should be "why does an ordinary user need to modify the application installation?"
To update the software when an update is available. That is a fairly standard option in software today. Lots of software products have a "Check for program updates" option under their Tools or Help menus. And when a new free update is available the user is offered to automatically update. My anti-virus application does this frequently (not only virus definitions updates but also updates to the base application).
I have to wonder about this "why does the ordinary user need to..." line of reasoning. The real question is why the ordinary user should NOT be allowed to do it, not why they should. You don't take access away from a user without an explicit reason for doing so.
It's callled the Principle of Least Privilege. Security 101. You don't give users more privileges than they need without good reason.

You are mis-stating the principal. The PLP "requires that each subject in a system be granted the most restrictive set of privileges (or lowest clearance) needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use." (http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/luawinxp.mspx). Since there are applications that have valid reasons for writing to the installation folder and there is no compelling reason to prevent them from doing so the practice reasonably falls within the parameter of "needed for the performance of authorized tasks".
Once again, you don't bind the hands of users without *reason*. The reasoning "Well *I* can't think of a reason why the user would need to do that so in the absense of any reason why they *shouldn't* be able to do so I'll restrict them anyway based on a blind application of the PLP." Being able to write to an application's installation folder used to be a standard for Windows. There was no security related reason I can think of for for changing that standard. In the absense of a good reason for causing problems with existing software Microsoft has done so anyway.

You wouldn't routinely give employees access to absolutely everything in an office, would you? Why should the computer be any different?

Do you lock each and every door in your building 24/7? I mean, you wouldn't routinely give employees access to absolutely every room in an office building, would you? No? Then by your reasoning you must keep every single door locked and issue keys only to those who have a reason to go through the doors. I've never worked in such a corporate environment. Where I have worked there were rooms that had reasons to be locked and those that didn't. The ones that needed to be kept locked were kept locked. That's a sensible application of security. Why should the computer be any different?