| Date: | October 2, 2007 / year-entry #363 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20071002-00/?p=24933 |
| Comments: | 52 |
| Summary: | One "optimization" I've seen from some programs is to defer a bunch of system configuration work to the first time the program is run or the first time a feature is requested instead of doing it at install time. The problem with this is that the first person to run your program is not guaranteed... |
One "optimization" I've seen from some programs is to defer a bunch of system configuration work to the first time the program is run or the first time a feature is requested instead of doing it at install time. The problem with this is that the first person to run your program is not guaranteed to be an administrator. For example, there is one popular media program that doesn't install its CD AutoPlay handler until you run it for the first time. If the first person to run the program is not an administrator, then their AutoPlay handler doesn't get installed and consequently never works. This problem became more acute in Windows Vista, where users do not flex their administrative rights by default, even if they are administrators. Consequently, when run on Windows Vista, this program never installs its AutoPlay handler. It fell to the application compatibility folks to see what they could do to rescue this program from the "not compatible with Windows Vista" pile. It's frustrating having to "fix" something that was broken when you got there. |
Comments (52)
Comments are closed. |
While I’m thankful for all of your posts, I think things like these are my favorite. It amazes me the kind of braindead things application developers think they can get away with.
Although…there is something elegant about a program that requires nothing more than a copy to "install". Mark Russinvich’s utilities are a great example of that. I agree it doesn’t work well for something like Microsoft Office.
Yeah, I kinna have to agree. I’m beginning to be of the mindset that Any Good Program runs by just copying it. I.e. no evil registration of DLL’s or other horrendeous windows system stuff… just .exe, everything linked in, and it just freakin’ runs… aaah….. ;)
the other thing I’d like to flag as wrong are those apps -you know who you are- who do some installation for every user (like deciding whether to add exchange support or not), installation actions that only work if the install CD is there.
so, months later, when you create a new user account, you run the app and suddenly it grinds away then complains the disk is missing, even if other users are correctly set up already. Or worse, I’m on a laptop and the content is not even reachable for days.
Maybe its the idea of late-binding installation that is at fault here.
If this blog teaches anything is that thinking things through is important. If every program were to be copy-installed the size of the binaries would likely be MUCH larger. On the order of O(N*M) with N binaries with M dependencies each. I am sure that cost would have seemed especially ridiculous in the earlier days of Windows.
Dijkstra’s observation strikes again:
The clever way to do something earlier is VERY OFTEN a huge burden later on. In fact an early (must-have) optimization often shuts many obvious avenues to future improvements. We really are terrible at planning for the future…
Microsoft Office copy-installs on Mac, as do many applications. The typical way to install a Mac application is to simply drag it to the Applications folder.
Wow, the rest of the world is coming to appreciate the mindset we’ve been espousing since like, 1994. "Flat" apps. Just an application EXE. There is an optional couple of DLLs for a third-party functionality that we can’t by-license static-link into our EXE, but the program late-binds those so it runs fine without them.
And the program keeps its settings in a file. Not in the registry. You can manage the file yourself without insanity or administrator permissions. You can back it up or replace it. Some times I think Windows 3 had it right, with INI files. At least those you could get a grip on.
The only time we ever touch the registry is to associate our file extension association with the current location of our EXE. We repeat this re-associating each time the app runs, in case the user moved the EXE (yes, we allow THAT too!) and we tolerate this operation failing if the user doesn’t have the rights to do so.
Basically, try to be NICE to the poor bugger who has to use your software and OS. If you can make their life easier, DO.
Ever since I’ve started going non-admin on my work PC in June, I’ve been noticing some programs do this. I run the install as admin, but if I manually click the app’s icon, of course I’m a non-admin.
Although in the defense of programs that do this, many of them have a checkbox checked for "Run x now" which would run as admin because it’s being launched from an admin process.
But an autoplay EXE is the perfect example where the devs assumed incorrectly as there’s no user intervention to run it as admin.
As far as copy-install goes, I have to say that as far as system utilties go (not user applications), I like those that don’t have to be installed.
The "System Information for Windows" (siw.exe) tool by Gabriel Topala’ is incredibly useful, very small (1386 K), and doesn’t need to be installed.
It doesn’t even need to be copied — I can run it right off the USB flash drive that I have on my keychain (where I also carry around Windows XP SP2). Of course, if you want to be able to run it frequently on your own system, you would need to copy the EXE somewhere. (There are no supporting DLLs, either, at least none that don’t already appear on my system.)
Now THAT’S convenient.
Acrobat Reader 6 through 8 ask you to agree to the license when you first use the program. I hope you don’t have to be an admin for that.
I wonder why you can’t agree to the license when you install. (Also, I don’t know if it asks each new user to agree to the license or not.)
Word and Excel, at least back in Office 2000 days, ask for your initials. This is probably the per-user setup that doesn’t require admin, but since I used to always run as admin, I don’t really know.
James said: "There’s one application I often fight with…"
What you mention is the fault of Windows Installer, not the particular application. It needs the original MSI file in order to uninstall the application.
I don’t know whose bright idea was that over there at Microsoft, but I would like Raymond to smack them in the teeth for me.
Yes, I know the installer needs that MSI to be able to "undo" the install but couldn’t that be in a separate log file somewhere instead of whole f*cking MSI or MSP file?!?
If you don’t understand what I am talking about check your C:WINDOWSInstaller folder.
If you have by any chance installed SP1 for Visual Studio 2005, then you will have 455 MB (yes, MEGABYTES!) of wasted space in there just to be able to uninstall it later.
Mind you, those aren’t backup copies of the replaced/updated files, just the darn stupid installer cache.
455 MB install log… way to go geniuses!!! Was your brain in the fridge while you were designing Windows Installer?
Same goes for Office 2003 SP3 — 115 MB wasted. And another 50 MB for three .Net framework patches.
All summed up with Microsoft’s applications being biggest (literally) offenders, Windows Installer has wasted 1.5 GB of my hard drive space just so I can uninstall some applications.
Delete those files and you lose ability to uninstall them and what is even worse, you lose the ability to install newer versions unless you clean up the registry manually. Truly amazing software design, NOT.
Igor, I’ve used installshield as a dev and it is just as picky. It uses logs which get very prone to breaking. Of course, the behavior has changed so much between versions of IS that things are going to be confusing. Of course, one of the output types of IS is MSI, so I could be remembering the wrong thing.
Sometimes I miss the bad old days when you just stick the floppy in the drive. Take it out and put it away when you are done.
As a developer who has had to manage interns fresh from (and in some cases still in) college, I’m more of the mind set that things like this (requring administrator first run) is simply because the developers don’t know any better. When I look back on my career and try and think of all the things I didn’t know two, five, or even ten years ago, I’m amazed that people let me still work in this field.
One of the difficulties I have with working on the Microsoft platform (as opposed to UN*X-like platforms) is that MS must constantly innovate to sell product, and that innovation comes at a cost: constant training. There is so much MS technology out there that it is impossible to keep up, let alone figure out which stuff is deprecated or determine what the Best Practices are for developing an application. Heck, it wasn’t even until last year that I found out there are MS APIs to perform FTP! (http://msdn2.microsoft.com/en-us/library/aa383766.aspx)
Not to point fingers, but I think the MSDN help is part of the problem. First, I have to say that I don’t like the new help layout since they started the re-write — it seems to make it ten times harder to find what I’m looking for; I especially don’t like the fact that the new help browsers have removed the Sync TOC button. Second, there isn’t anything in the documentation that says the functions are deprecated or, at the very least, “not recommended”. Things like DDE should be so marked. Also, if there are Windows Logo requirements or other sets of best practices, these should be grouped together so they are easier to find instead of spread out over different areas of the API. I don’t care if there are multiple references from different areas to the same document (think symbolic links) as long as the complete collection can be navigated, browsed and read.
Finally, there are some groups, like the Windows Installer group, who spend as little time as possible working on documentation with the reason being they’d rather spend time working on features. To me, this is a cop-out: how useful can your features be if nobody can figure out how to effectively use them? The Windows Installer has been particularly challenging for me as it seems the help authors assume you already know how msiexec.exe works and that you just need a refresher.
I realize it’s probably too big of a task to hope for, especially considering the number of Microsoft technology books on the shelves of your local book seller, but I would love to see improvements to the MSDN that highlight deprecated functions with pointers to the replacements, provide some more background on the APIs, and annoint some methods as “best practices” for developing software on the Windows platform.
Igor: needing the MSI is one thing – shipping that MSI in a wrapper which uses then deletes it, making MSI look in the wrong place for a file I haven’t got, is another.
Remember MSI has a ‘repair’ facility – presumably it needs to retain the full MSI file rather than just the metadata in order to support that. It is irritating, though!
There is a solution available which allows for xcopy deployment of just about any application, see http://thinstall.com. It will take all the individual executables, dlls and support files making up an application and stuff it into one big executable. You can then just copy that "Thinstalled" executable to your target machine and run the application there, without any further installation.
Full disclosure: I work for Thinstall.
Excellent point. I look forward to the day when Vista and future versions of Windows finally persuade developers to minimize dependencies on administrative privileges.
[I take issue with the claim that DDE is "not recommended". DDE works just fine and if you want to use it, then go ahead. Of course, if you don’t want to use it, feel free as well. "Not recommended" carries the connotation "Microsoft recommends that you rewrite any programs that are using this feature." -Raymond]
Perhaps my words are too strong. I am a fan of the "Raymond Chen Camp", as Spolsky likes to say, so the fact that technologies available since Windows 3.0 — like DDE — still work today is impressive. However, there are likely suitable replacements for the older technologies that are more interoperable with other systems or that have improved security, enough so that the older technology should probably be avoided.
P.S. Sorry to pick on DDE — it was the first thing to spring to mind. Thinking about it after hitting the ‘Submit’ button, it’s probably a technology you created. :)
"And the program keeps its settings in a file. Not in the registry. You can manage the file yourself without insanity or administrator permissions. You can back it up or replace it."
I’m agreed that generally files are better. However, the permissions problem isn’t a registry problem. For a well-written program, if you need admin permissions to modify the settings in the registry you would need admin permissions to modify the same settings in a file.
Programs don’t have to use HKLM.
Igor: Thanks for pointing that out, I did indeed have nearly 1.5GB of msi’s in that folder.
This practice of doing administrative work on first run seems remarkably silly to me – I’m willing to wait for a slow installer (it can’t possibly take longer than Visual Studio) but if your program takes a minute to start up the first time I run it, it’s getting a black mark. I don’t care if it’s faster next time, first impressions count.
But then I guess whoever’s writing these programs isn’t bothered about what users might think of their software, or they’d have made more effort in the first place, right? :-)
I remember that Visio 4.0 could run of the CD, without any local installation. This was before Microsoft bought the company that produced it. Isn’t no-installation-required one of the U3 USB stick innitiative’s goals?
Uh, clearly they *can* get away with it.
one still needs to keep in mind that there are servicing problems with "local copy" applications. if you ship with local copy of, well, shell32, then if there is a bug found and fixed in real shell32 nobody’s going to update your local copy.
What makes you think this sort of thing is intended as an optimization?
This happens when the application development environment is well-documented and familiar, and the installer toolset is neither. Devs implement installation tasks in the app because that is the path of least resistance.
I am not defending the practice–but a certain company who failed to deliver an easy-to-use MSI authoring tool should bear some responsibility here.
@Chris
Bingo!
Many years ago, when I wrote an app that had to register a file extension, I shoveled the code for it into the program instead of the installer because I couldn’t figure out how to make it happen during the install process.
Looking back, I realize that it would run quite well in LUA because the registration does not automatically happen; the user has to ask for it later. 1 less program for Microsoft appcompat to worry about. :)
(Yes, I realize that if the user did try to register the extension, he would have to elevate the app for a moment.)
Steve: I’d say that’s just about fair enough *if* that dependency has changed (for example, if you’ve installed an Exchange server since the app was originally installed, so installing Exchange support makes sense now where it didn’t before) – but in most cases, that’s a big pain for me as well.
There’s one application I often fight with which ships as an EXE file containing an MSI package; after anything changes, it wants that MSI file – in the original location, a randomly-named subdirectory of %TEMP% which has long since been deleted. Weird, not to mention infuriating!
There’s another application here which appears to do exactly what Raymond is complaining about, too: first, it "installs" (fair enough; I run the installer as Administrator when first setting the machine up) – then the first user to run any component triggers some other MSI action. For now, I’ve worked around that by taking an InstallRite snapshot of that first-run activity and running that as part of the system setup, but it’s a bit of a nasty hack!
(There also seems to be a nasty interaction with mandatory profiles: something for that app needs to be done every single time a user tries to run it having just logged on, presumably a user-specific registry thing which gets overwritten every login, thanks to the mandatory profile. Irritating.)
"path of least resistance" is an optimization for shipping a product.
I don’t mind apps that you have to install, but only if they allow you to install into your profile directory if you are not an administrator and thus don’t have access to Program Files.
There are lots of apps which fall into this category, though it’s often accidental. To satisfy this requirement you must:
* Allow the user to choose an installation path in the setup process.
* Only install files under the user-selected installation path.
* Only save ancillary information such as settings in the HKEY_CURRENT_USER registry key or in the user’s Application Data directory.
I would like it if in the future per-user non-administrator installation was the *default*, and system-wide installations were a crazy option that administrators could twiddle in the installation process.
Of course, users would always have the option of running the installer themselves to install their own local copy to use in place of the supplied one, so apps would have to be designed to keep the settings for these separate instances distinct. No reason really why per-user installations can’t just keep their settings in the application’s own directory.
This doesn’t seem like too hard a problem to solve technically: just have alongside each installation a path to the directory where its configuration settings live. The global one will use %%USERPROFILEDIR%% (or similar), while the local ones would just have a path relative to the directory the executable is in. It’d be up to the installer to set the correct value depending on whether it’s doing a user-local or global install.
In fact, now that I’ve written that all out I don’t really know why more apps aren’t designed this way.
[Whenever you find that programming is hard, it’s always safe to blame Microsoft for not making it easier. -Raymond]
Programming in general isn’t that hard. It requires getting used to; but isn’t hard. Now, programming to Microsoft APIs is a whole ‘nother can of worms.
James said: "If every program were to be copy-installed the size of the binaries would likely be MUCH larger"
Erm… I don’t get it. Why care? I mean, my system partition is already filled with gunk as Igor says so space is wasted anyhow. Why not waste it productively? Besides, at the price gigabytes are going at now I really wouldn’t mind apps taking up a ton of space if it meant their behavior was predictable – the extra cost would be insignificant compared to the price tag of most serious software. Put it on separate USB keys even, JUST MAKE IT WORK! Autoplay *has* to be good for something… (remember, you saw it here first ;-) )
Programs which require admin rights were already incompatible with Windows XP, in my opinion, but I guess the authors never tested it with a non-admin account. (Or, in this case, ran it at least once with an admin account after installation.)
I think a lot of developers (and users for that matter) have only used machines like their own, where they are always the administrator, so they don’t appreciate how much stuff was *already* broken for corporate (or security conscious) users running with limited accounts.
It bugs me when people (not here) complain about having to change their apps for Vista. They moan about both the effort and the fact they can no longer save settings files into Program Files, ignoring the fact that doing so has been a bad idea since NT4, both in terms of shared vs private configuration and in terms of non-admin accounts.
I for one am glad Vista has forced people to get this stuff right since it now affects so many machines (and probably their own machine unless they turned off UAC, which is another rant entirely) that it’s impossible to ignore.
I agree that it is frustrating. However, since the problem does not lie with Microsoft, I do not think that Microsoft should try to “fix” this.
Sure, people will try to blame Microsoft. So publish a detailed document describing the reasons why it fails and let the original developers handle it. If they are not around anymore, then the application was never designed or verified for Vista and should not be supported in the first place.
I’ve just buy a thinkpad with vista, it has the vista logo and all that but when i turn it on i get a message saying that a program(system update of thinkpad) is trying to show a dialog in session 0…
David Walker: Remember, some of us uses clone system that you don’t necessary have gone through the install process, and some company have I.T. people to install the software for you, so you users don’t necessary have clicked "I Agree" at the EULA page of installer. (It’s sensible to think we should get the User to click on an "User Agreement")
I guess a lot of people miss the fact that you can just extract a small program during/after install to do all of the heavy lifting for you. It even works with repair, although it took some research.
Dan, InstallShield makes MSI much less painful, I assume most software that doesn’t use VS’s built-in support will use a 3rd party. It’s more of a case of Microsoft supplying the technology and other companies supplying the interface and integration, just like volume shadow copy.
I know exactly what XYZ you mean, though, and it’s frustrated me repeatedly.
Given there’s something call regedit in Windows, which can export and import registry settings through text files, I’m not sure it’s really *that* much easier to manage settings kept in a text file vs. in the registry.
Windows Installer has always struck me as being broken somehow. Maybe it’s just me, maybe it’s the individual application devs who are using it wrong. But the problems I have had with programs using Windows Installers? With NSIS I can only recall one installer problem, which was clearly caused by whoever made it (the installer checked for a prerequisite incorrectly. I had it, but the installer didn’t think I did) Just observation here.
Product XYZ. The devs are at least partly responsible for my misery there. A Windows Installer packaged INSIDE an NSIS installer? PICK ONE for heaven’s sake! Plus it suffers from the problem Igor describes… it places the MSI installer in a folder on the desktop. Why would I NOT delete such a folder once it was done? Whenever I went to upgrade it asked for the old MSI… fortunately I found Microsoft’s Windows Installer Clean Up. It makes Windows Installer forget a program is installer… very handy in these cases.
But it gets worse. Product XYZ used to do some late configuration with Windows Installer on it’s first run, which required the MSI! So I’d have to download the entire thing AGAIN if I forgot and deleted it before running it the first time.
Now a more recent example. .NET 2.0 exploded or something. Probably Product ABC‘s fault (I’m not gonna use that ever again.) .NET 2.0 apps would crash when run. Visual Studio… the only .NET 2.0 app NOT to crash… would cheerfully tell me it’s main component had crashed and then disable every useful function.
.NET 2.0 repair/uninstall? Crashed as soon as I tried to repair or uninstall. Downloading the .NET 2.0 installer and trying to use THAT to uninstall/repair produced the same result.
Fortunately I found an MS KB article on how to manually rip out .NET 2.0. Reinstalled, updated, and everything magically works again.
It doesn’t help my feelings about MSI that with NSIS all you gotta do is download NSIS and you get everything you need to build installers out of scripts (granted, I’m a programmer so I picked up their scripting language easily). With Windows Installer… well I’m sure there are comparative ways to make Windows Installers (I was just reading a blog entry about WiX, which sounds about right) but I dunno… I suppose I just don’t *know* of any standard way (well, apart from Visual Studio, but considering that’s not a free*, separate tool I won’t count it in my comparison) so I’m not going to say anything more. I suppose final judgment has to wait until I work someplace that forces me to learn MSI.
PS: Every installer for every Windows hotfix and service pack doesn’t even go into Installers… check C:Windows$*
* – I know about express but you don’t want to get express if you just want to build an installer for something you already made.
reader said: "Given there’s something call regedit in Windows, which can export and import registry settings through text files, I’m not sure it’s really *that* much easier to manage settings kept in a text file vs. in the registry."
You obviously haven’t used the Settings Designer in .net.
“[Choose one: “There goes Microsoft, blaming other people for its own problems.” or …]”
You (Microsoft) just can’t win. Most of us don’t want you to. :=)
The people who take cheap shots at you will continue. You can’t change that. The rest of us ding you because there are layers of *hidden* APIs and compat fixes that we don’t see or understand.
If you at least publish a list of offending apps and root causes (you’ve already done the debugging work, right?) then at least we can ding you (or the vendor) for the right reasons, instead of thinking MS is full of incompetent VB weenies. :=)
You’re going to get bashed no matter what you do… so at least ruffle some vendors, name some names, so those of us with a clue get a chance to learn how *not* to do things.
It’s surprising how many people who don’t actually know how to program try to create installers. I use a certain freeware installer and frequent it’s newsgroups, and there’s at least one person a month asking how to install a program they have no idea how it works (and at least 1 person a week asking how to not install the program to Program Files on Vista because that breaks their program).
"I’ve just buy a thinkpad with vista, it has the vista logo and all that but when i turn it on i get a message saying that a program(system update of thinkpad) is trying to show a dialog in session 0…"
Then return the product as faulty and get a refund. OEMs producing custom machine builds that don’t work or don’t work well is a big problem, and only because people put up with it.
This sort of problem shows up quite well with machines that are centrally managed on a large network with software distributed by policies, or whatever.
In fact quite a lot of programs fall down quite badly in this sort of scenario.
Newsflash… Developers: Hoping that your product will be picked up and purchased by large "thousands of seats" corporations? Then try actually testing your product in the typical locked down deployment and usage scenarios typically in use in such businesses. Remember, it doesn’t matter how much I like your product, if I can’t automatically install it onto my thousands of PCs from one central console I’ve got no choice but to reject your product in favour of the one from your competitor that is a bit more considerate…
Installation programs have had these issues long before there was a registry or COM, or even OLE.
What about setup programs for DOS apps that might try and set up extended ram in your autoexec.bat? Bet you hated those because it would be incompatible with some other program.
Copy-and-it-runs installs are great. If you can make that work with your application, then that’s fantastic. Sometimes you can’t. Plenty of people write fantastic installers and uninstallers, too.
Unfortunately, the ones that don’t are usually the ones that don’t have to. Seems to me the most popular products tend to perform the worst at proper installation, uninstallaion, and running as non-admin. This is not because it is hard to code this way (it is actually simpler). It is more because they don’t have to care. You’ll use the app no matter what and MSFT will have to support it.
Cheong: "Remember, some of us uses clone system that you don’t necessary have gone through the install process, and some company have I.T. people to install the software for you, so you users don’t necessary have clicked "I Agree" at the EULA page of installer. (It’s sensible to think we should get the User to click on an "User Agreement")"
Why do you think that’s sensible? In such a case as you describe, it’s the company not the individual users who are agreeing to the terms of the EULA. It shouldn’t matter whether or not the end user sees them.
Also, I see no reason to believe an EULA shown after installation is legally enforceable. An EULA is a contract, and contracts require consideration (i.e., something of value that is given in exchange for agreement). The consideration would normally be the license to install the software on your computer (an act protected by copyright), but if the installation has already taken place I don’t really see what consideration can be given. You don’t need a license to use software, only to make copies of it…
It’s easy to see how this happens. Here is how it happened to me. Our install requires admim privileges. After you install the app, you test it, right? And during that first test MFC is adding OLE/file associations, which requires admin mode. I had expected admins to always do a quick test before handing the machine over to the user, so the app was running when the admin logged out.
I did not notice this until Vista. Only the install EXE gets the elevation prompt, and the app is left running as a standard user. Now those admin operations were failing! Ouch.
Moral: because of Vista’s elevation prompt feature, the only admin mode opportunity you are likely to see is in the install.
[Whenever you find that programming is hard, it’s always safe to blame Microsoft for not making it easier. -Raymond]
When you find app compatibility is hard, it’s always safe to blame *those stupid developers* for not implementing your obscure MSI technology.
Pot, have you met kettle?
When smart people want cooperation, they make it easy to do the right thing and hard to do the wrong thing. So, I guess we both wish more programmers were smart.
MS said: "Of course, one of the output types of IS is MSI"
James said: "Remember MSI has a ‘repair’ facility – presumably it needs to retain the full MSI file rather than just the metadata in order to support that. It is irritating, though!"
Yes, but there is an option of not putting everything into the MSI.
I am not against MSI in particular, just against its misuse.
It is irritating when an application has a single gigantic MSI/MSP file and you have to keep a complete copy in C:WINDOWSInstaller just to be able to uninstall or repair.
Remember, I HAVE NOT ASKED IT TO CACHE THOSE FILES. Furthermore, I wasn’t presented with an option during setup which says "[x] DO NOT BLOAT MY WINDOWS FOLDER".
I believe that fundamental problem here is that people expect setup.exe to be a swiss army knife with a GPS, pocket calculator, and a flashlight when in reality the only thing setup.exe should do is provide INSTALL and UNINSTALL features.
One particular MSI feature I am extremely pissed off with is what Adober Reader setup is doing — optimizing performance by defragmenting during setup!!!
Who in their right mind decided that defragmentation should be exposed to setup programs?!?
It may take a long time depending on the current fragmentation level and the machine load.
It supposedly defragments only its own files (haven’t checked this).
It uses built-in defragmentation algorithm. What if I want to defragment on my own using 3rd party defragmenter?
It wastes my time, I either ran the setup to be able to use the program immediately or I ran it while installing bunch of other things and I plan to defragment when I finish installing everything.
It actually tries to cover for Adobe Reader bloatness and slowness by defragmenting.
There is no way in hell you could look at it positively, and yet someone thought it was a "nice feature" and decided to enable it.
In my opinion, it shows long-term software industry trend — "do as much as you can at the expense of the user".
Adobe got complaints from their customers, they wanted faster startup time. Instead of trying to improve application startup performance they decided to defragment our HDDs. Talk about brute force.
bcthanks: "You (Microsoft) just can’t win. Most of us don’t want you to. :=)"
Most of us? Really?
You want MS to go away completely? The world would be worse off then.
Paul Doughtery:
"After you install the app, you test it, right? And during that first test MFC is adding OLE/file associations, which requires admin mode."
The RIGHT time to do file associations is during the install! You’re setting the associations at the wrong time.
“The RIGHT time to do file associations is during the install! You’re setting the associations at the wrong time.”
The right time to do per-user file associations is during the install phase? Really? How exactly do you expect the installer to manage that, when it only has access to the registry for the currently-logged-in user?
Chris ‘Xenon’ Hanson:
I hope you only "update" the association when it is already pointing at an "old" path to your app.
If not, it will (incorrectly) clobber any changes the USER has made to THEIR file associations.
(whether this is an extension that you think is only used by your app is irrelevant)
Raymond, I didn’t take that statement out of context. There was no other context. That was David’s entire comment. It’s the one right before mine (since you told us recently that you see our comments in isolation on the moderation page, I assume this was the cause of your confusion.)