On 3 Feb 2007 at 16:36, Phil Daley wrote: > At 07:02 PM 2/2/2007, David W. Fenton wrote: > > >> But, since this was not a problem in XP, whose fault is it??? > > >It's the fault of the software maker for not updating the > application >to work in Vista. Or, your fault, if you've chosen to > install on >Vista an app that hasn't been upgraded for > Vista-compatibility. > > But, Microsoft has not allowed for people who do not "install" > programs, but copy everything into the correct folders.
Er, why should they allow for that? Any app that is intended to be installed that way should handle placing its own configuration files in an appropriate location (and the app directory is not it, and never was). > You may say, why would anyone do this? > > I know hundreds of software developers who do this every day. > > They have no "installer". After writing program code, you compile and > link it into program modules. > > Then you copy those modules into Program Files and run the program. > > You have to register all of the files (more than 50 in my case) in the > Local Machine registry section. > > We have a .bat file that does this. I have not done this in Vista, > but I expect it won't work. I believe Local Machine registry is now > protected. Not completely protected, it just requires that you do specifict things to be able to write to it. And, if you read the article that someone cited in a post replying to you (was that Aaron?), then you'd know about registry virtualization. > And, before that will work, you have to copy all of the user files > into Documents and Settings, like icons, menu files, modifiable files, > etc. Not any more. You would now copy them to the Users folder. > But, there is no way (outside of Eric's suggestion to log in as > administrator and change the security settings) to copy files into > Documents and Settings. > > I can do this on a test machine that I install Vista on, because I > know the administrator password. > > Once the company starts installing Vista on users' machines, this will > not work. Only IT has the administrator password. > > I can't imagine how PO'ed the IT people will be to have to modify a > thousand machines to allow write access to Documents and Settings. Why would they be? If they are using software that was not designed to run on Vista (and the software you describe wasn't designed to run on WinXP or Win2K, either), then this is their own fault. > Also, since we put user modifiable files there, many users just use > our program to modify them. If they go to the actual folder (\Users), instead of through the symbolic link, they should still be able to modify them. > Advanced users normally make modifications with a text editor (they > are just ANSI text files). > > That is no longer allowed. And that is a A GOOD THING. My guess is that IT is likely to be *happy* about this, because it means users have less chance of screwing up their machines. Any decent IT department I've ever worked in puts user profiles on a file server, anyway, so lacking write/modify/delete access to the C: drive on the local workstation won't be an issue. > I have already filed one bug against Vista (DLLs not named ".DLL" do > not show version information). I believe I now have a second. Did they in previous versions? What you are otherwise reporting is *not* a bug at all -- it's all by design. And that design is A GOOD THING. It fixes architectural mistakes made in Windows back in the mid-80s, mistakes that were the reason for "DLL hell," Windows' vulnerability to viruses and other exploits, as well as the instability that resulted from allowing installers to modify the OS. Win2K began to address this (by putting profiles outside the Windows folder) and WinXP did even more (by protecting the Program Files folder), but Vista takes it the rest of the way, and now religiously segregates user data from system and software components, and gives different rights on them. Vista is the wake-up call for software makers who have ignored the requirements of NT-based Windows, where all apps should be written to function fully when run in LUA mode, i.e., with the lowest user-level permissions. UNIX has been that way since the beginning, and OS X is the first consumer-level OS to have implemented the same architecture. OS X users don't have any problems, and after Visa- compatible software is released (I assume MS has a certification program that has LUA as a prerequisite to earning the certification; but is that OS X has the same), Vista users won't have the problem any longer, either. The issue is mostly going to be with backward compatibility with older software. Some security adjustments will be required, and those adjustments will require admin-level permissions to implement. But any application that was actually properly designed for Win2K or WinXP should work well with Vista's compatibility sub-systems. The problem is that so many major software makers have completely ignored the requirements of multi-user NT security for so long. If you have problems, blame it on the software makers. I've been "screaming" about this issue for many years now (since Win2K came out), because I want my clients to run with LUA logons, instead of admins. Yet, companies like Quickbooks still insist on being running with elevanted permissions (unless you tweak registry and file permissions). It's unconsionable. It's incompetent. With Vista, it's now going to end. And that is A GOOD THING. -- David W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
