The Old New Thing

Another plausible explanation: the function has a nice name that seems related to the problem the programmer was trying to solve and its API is very simple.

I would bet the programmer though it was his *own process* foreground window that the function returned.

That's what you get for keeping backward compatibility. You can't only have the good sides. You also get bad relic API that no one should ever have a reason to call just so some old program that is arguably bugged can continue running.

/me grumble. :)

I remember seeing an API which allows to flash the taskbar button of an application requiring attention of the user. Why developers not using that API instead of stealing focus?

Why developers are not using FlashWindow? They don't have to. If you pop a modal dialog, and it's not a foreground application, that will flash your taskbar button.

@Alexander Grigoriev:

The installer database isn't kept in the registry at all.  Those strings are referred to by the MSI team as Darwin Descriptors and are used for a different purpose altogether:

http://msdn.microsoft.com/en-us/library/aa302344.aspx

The Windows Installer copy of the database is stored in C:\Windows\Installer and the full MSI is stored in an arbitrary location chosen by the installer itself.

The real question is:  why do you care?  And generally speaking, hashing together multiple components of data in a programatically easy fashion is not usually my definition of a moron.

@Bryan

"why do you care?"  I've often wondered myself where the installer database is kept.  But never wondered strongly enough to go and find out.  And why do I care? Because sometimes uninstalls fail to complete.  The application still appears in the list of installed programs but is actually no longer installed (I hope).

I've often wondered if I can manually remove all those half-uninstalled apps from the list on my machine.

It's really amusing that even Windows Vista has to keep supporting APIs that make its user interface as single minded as using a command line. A command line that can arbitrarily decide the directory that it's "cd"'ed into.

The whole wellspring of multi-threading is nearly useless while a single app can hijack the entire windows UI and dance around laughing and slapping its bum. Please for the love of Bill, modal dialogs should not disable the minimize button of the windows that launched them!

There is about 3 different solutions to the problem, from firefox search bar, to IE's own windows update activex's progress indicator, to mac-os-kitty's dialogs that are pinned to windows that launched them. Just pick one and go with it.

@Bryan:

In the article you refer to:

"Shortcuts. Windows Installer introduces a special type of shortcut which, while transparent to the user, contains additional metadata that Windows Installer uses through its shell integration to verify the state of the specified application's installation prior to launching the application."

Unfortunately, also, you cannot drag and drop a file to those half-assed shortcuts, as you could with old good ones. And they always delay the app startup quite a bit.

Those "Darwin Descriptors" are a kludge, anyway. Why a critical file should get removed? Instead you should: prevent users from messing up your installation, by employing the right security practices; provide means to clean your installation unconditionally (should NOT require the original installer to be present anywhere), AND should NOT depend on any of the installed files for uninstallation if you run an external setup.exe (from your original CD). We've all seen examples of the contrary, including those of MS software.

And PLEASE, don't do any "check for updated components" behind our backs. Like VS2005 SP1 supposedly does, which is why its installation can take HOURS. And PLEASE, don't try to use doubly-bulletproof file copy while installing non-critical files. There is no reason that uncompressing and writing 50 MB of files should even take 1 minute (while it usually takes at least 5 minutes).

The issue with Windows Installer setups is that people don't integrate with it properly, usually because they don't know how. It doesn't help that it's rather arcane. Classic example: if you want to display a message you don't call MessageBox - you call MsiProcessMessage.

Turn off advertised shortcuts in your product installs if you don't want them. What's the big deal?

People remove files from installed products accidentally, sometimes deliberately. You might be surprised at the number of people that remove files from an installed product, only to be shocked that it repairs itself. I don't see how you could clean up missing files without access to the original install source.

Phil: The problem is it isn't "my install", my frustration (and I suspect Alexandre's) is from a user perspective. I would very much prefer a shortcut which actually runs the exe file and can receive drop events, rather than an "advertised" one which adds extra hoops to jump through every time. If an application is damaged, I'll run a repair operation using the setup utility. Similarly, I hate sitting waiting while an installer keeps me waiting ten minutes while it undoes the ultra-hyper-steroidal-megapacker compression which shaved a megabyte off the ten megabyte ten second download: it might seem like a really clever algorithm, and I'm sure the authors pat themselves on the back a lot for it, but the end result is substantially worse than any of the alternatives!

(Not to mention that there is definitely something profoundly wrong when I can download the Vista install images from MSDN in less time than the older XP machines take to list the available updates from MS Update. That really infuriates me.)

@James:

The MSI team foresaw that not everyone would like this:

http://msdn.microsoft.com/en-us/library/aa368297(VS.85).aspx

Non-advertised shortcuts regardless of the original installation author's intent are only a command line switch away :-)

To verify, I found a blog that would send you to this page on the first page of basically any search engine's result for "Disabling Advertised Shortcuts".

James:

That megabyte of savings might not seem like a lot to you, but consider the savings over the lifetime of that file download.  A significant download (say, XP SP3) might get downloaded millions of times. Suddenly your 10% savings has turned into petabytes of unnecessary bandwidth. Last time I checked, bandwidth still costs money.

Bryan,

"disable advertized shortcuts" should not be a command line option, but a default. "enable advertized shortcuts" should be an option. That's a thing that should be explicitly enabled by the site admin, instead of being done behind home user's back. And, yes, there is no reason an installation should ever get corrupted. If it does, you haven't configured your site correctly - your users are given too much privileges.

I do hate it when start menu shortcuts don't appear to point to anything. They just magically start whatever program they magically point to.

Why can I not use "find target" on these (Office is an example, so is Adobe acrobat).

This just makes spyware easier to hide itself.

I much prefer dragging over an icon from a disk image.  

@James:

"I hate sitting waiting while an installer keeps me waiting ten minutes while it undoes the ultra-hyper-steroidal-megapacker compression which shaved a megabyte off the ten megabyte ten second download".

That's Acrobat 7 - after download it was running some obscure "optimizer" which was supposed to uncompress the files. That "optimizer" took like forever to complete.

@Nick:

There's no way you can save 10% by a different compression. 1% maybe. And no, even a super pooper decompressor should not be slower that 10 MB/s on a modern processor. Which they still appear to be slower...

@Alexandre:

Compare 7zip and normal LZW-related zip. A 10 % vs. 1 % difference is far from absurd.

7zip, zip, zlib, bzip2 all suffer from quite short windows for searching for redundancy (e.g. 1MB max).

One can easily get more by searching further. e.g. xdelta.

Propably these guys from this optimizer just used that...

Heh, I wrote a really cool installer compressor once. We had a whole bunch of patches (around 40) and there was an optimised delta patch to the current version for each of the earlier versions. There were about a million users, and a surprising number were on really slow dial-up (not all of Australia has DSL or even 56k). Of course the people on 14400 generally also had slow computers, so it took them forever to decompress and apply the patch.

Adobe's current updater (and a few others, like Paint.NET) can't handle proxies properly, they baulk at authentication.

I also wrote the server-side installer using a really awesome (cough) bunch of BATch scripts, woo! I hear they've just thrown it away and now use a real installer. :-)

""disable advertized shortcuts" should not be a command line option, but a default. "enable advertized shortcuts" should be an option."

Why? Install on First Use would probably not work without advertised shortcuts.

> I remember seeing an API which allows to flash the taskbar button of an application requiring attention of the user.

This is what SetForegroundWindow is supposed to do when a sibling process calls SetForegroundWindow.

e.g. Once, I wrote a utility providing an optional show/hide global hotkey. I never managed to pop the window up when the hotkey is pressed. Fortunately, there's this flashing visual effect which is ok for me.

I don't know how most applications really manage to steal the focus, but they do. I don't see how to do that without injecting its own code into Microsoft Windows Explorer.

From James:

> Please for the love of Bill, modal dialogs should not disable the minimize button of the windows that launched them!

I agree, the parent window recieves WM_PAINT messages. Why wouldn't it recieve resize, minimize and maximize messages?

>7zip, zip, zlib, bzip2 all suffer from quite short windows for searching for redundancy (e.g. 1MB max).

7-zip allows dictionary size up to 1GB (though you need to use the command-line version to get that, the GUI only exposes up to 64MB).

BTW, on the subject of compression ratio: using zip (zlib) instead of lzma compression in the installer for Gimp (117MB installed) results in 37,7MB installer instead of 17,8MB (bzip2 achieves 28,6MB).

> I don't know how most applications really manage to steal the focus, but they do. I don't see how to do that without injecting its own code into Microsoft Windows Explorer.

It's easy - make your window always on top, then focus it. Had to do this with an internal application which needed to display an alert when a DOS program was running in full-screen mode.

@Alexandre Grigoriev:

You live in a fantasy world.  Most users don't drag & drop files on to a shortcut ( most don't even know you CAN drag & drop a file to a shortcut ) and given the choice, would rather their applications "just work".  Like Yuhong Bao said, disabling that would break a large portion of the functionality provided by Windows Installer.

Advertised Shortcuts are typically desired.  The situations where they are not (as rare as those are), they provide a command line parameter to get around it.  Disabling advertisement would also affect your ability to roll out applications using Windows Installer deployment technologies.  It's quite common practice to advertise commonly used applications that everyone might not always need.

Yeesh, you complain for the sake of complaining.  If you're a site admin of a corporation, you already have a slathering of command lines - one more isn't going to matter.

@Bryan:

You live in fantasy "corporate only" world, where the users are clueless and should be herded. Most of home users are clueless, too, but not all.

I'm not sure, though, why in this age of multigigabyte hard drives anybody would need to have install by demand. Just install it. If you want to save some disk space, use disk compression.

Have you never seen an application that will do that stupid "install" every time you run it, AND wanted the installation CD? I saw; one of old MS Office apps. It would be great if all those great features just worked, without excessive delay and without confusing the user. Unfortunately, we don't live in an ideal world, and Microsoft screws up more often than we ever wanted.

@SuperKoko:

James> Please for the love of Bill, modal dialogs should not disable the minimize button of the windows that launched them!

"I agree, the parent window recieves WM_PAINT messages. Why wouldn't it recieve resize, minimize and maximize messages?"

Parent window doesn't receive any keyboard and mouse messages, because it's disabled. You cannot click any button. You can provide a minimize button in your dialog, though, and forward the minimize command to your main window.

Raymond says: "And that's how the installation program ends up disabling Task Manager."

As a security developer, I cannot fathom why Microsoft has not yet given the Task Manager a protected environment to execute in.

Two things are sorely missing in Windows:

(1) The ability to suspend all executing processes except Task Manager (and other trusted system processes) at the press of a key.

(2) The ability to run Task Manager even when everything else is crapping on the desktop.

As it is, the easiest way for any Windows user to create a DoS condition is to keep launching new child processes (or threads!) in a loop. Launch enough, and this will completely cripple the machine. Intervention is hardly possible.

This is so annoying, apps should never steal the focus unless as a direct result of a user action.

Related, and just as annoying are applications with large, always-on-top splash screens. Sure I've got a multi-core multi-gigabyte multitasking monster under my desk, but who needs multitasking stuff anyway if you can have the pleasure of watching product X start up.

Most annoying is the time tracking application I have to use at work. I always forget to enter my hours so I have scheduled a task at 17:00 sharp that starts the application. I usually work until 18:00 but it varies so I set it an hour early to be on the safe side. This application pops up this very annoying always-on-top screen while it loads. Why the heck a simple app like this needs a splash screen and why it takes 10 to 20 seconds to start is a complete mystery to me, but because it starts an hour before I leave I'm usually just in the middle of something when it pops up. It also has the most boring splash-screen picture ever.

On the Mac there's at least the bouncing-dock-icon startup indicator,  which is still distracting but at least not always-on-top in the middle of the screen. Unfortunately, Office::Mac still feels the need to display this pretty, but useless and annoying partially-transparent splash screen thingy. Fortunately, I hardly use Office at all.

I hate those advertised shortcuts because I can't use RunAs (and DnD, as somebody mentioned).

Why can't the shell be smart enough to handle them like regular shortcuts?

@Raymond:

"The "anybody" who wants install-on-demand are the corporate fantasy-world folks. "

I'm sure the corporate folks would know the magic command line switch to enable install by demand and advertised shortcuts. Unfortunately, a lot of consumer grade software (and MS Office, too) is by default using those evil shortcuts, which we, lowly home users, don't want, thank you very much.

@Aargh:

"Unfortunately, Office::Mac still feels the need to display this pretty, but useless and annoying partially-transparent splash screen thingy"

Also add to the list of annoying things Microsoft thinks we should not live without:

Alt+LButton opens that "Research" pane. Unfortunately, I'm not one of those 10 people that use Research. If I hold Alt (for Alt+Tab) and then want to dismiss that AltTab window by clicking away, it often end up in in Outlook, and opens that annoying tab. THERE IS NO WAY TO DISABLE THAT MOUSE SHORTCUT.

"THERE IS NO WAY TO DISABLE THAT MOUSE SHORTCUT"

How about you don't install the "Research" feature when you install Office? It's underneath "Office Tools" and it's called "Research Explorer Bar".

In fact, because the .msi files are kept right there on the disk when you install Office, you don't even need the CD to remove it. Just select "Change" from the toolbar in "Programs & Features" and then deselect it.

What an age we live in!

Thank you everyone for reminding me how advertised shortcuts SUCK!

I once tried uninstalling application and the original installer was corrupt. Then I tried to remove it manually by deleting files.

But no... RIGHT-CLICK on a desktop lauched the installer which tried to repair the application and it couldn't because it was corrupted effectively standing there hanging my computer completely so I could barely bring up the Task Manager and kill msiexec.exe.

That's not all... wait for it... another accidental click and it re-lauched the setup! I couldn't stop the menace from re-lauching itself until I somehow managed to start Total Commander and killed both msiexec.exe _and_ explorer.exe and then deleted all crap from that application thoroughly by using msizap which of course required me to dig into the registry and find the damn product code.

God how I wished to know which shell extensiong was responsible for that re-launching "feature" so I can nuke it into the Sun!

Keeping those MSI (and MSP!) files as a requirement for uninstallation is downright crazy. They eat space, can become corrupted just like the application itself, and when they do they wreak havoc with those stupid advertised shortcuts.

If the installer was smart enough to figure out that it can't repair the application or when I don't want it to repair it automatically, then it might have been usefull. This way it sucks.

Corrupted Files Make Your Applications Run Incorrectly, film at 11.

[I thought Office defaulted to normal install; install on demand is an option. The "evil shortcuts" are there for the people who choose install on demand. -Raymond]

I have yet to see a MSI package that doesn't default to advertised shortcuts, and I agree that they're annoying. I stopped counting how often Windows Installer decided that something is wrong with the application and tried to reinstall it (requesting the original CD in the process), then failed because some updates were installed that made the original .msi files somehow incompatible with what was installed (this most commonly happened with Office 2000 after SR-1a was applied, but I've seen it with some other programs). Of course, launching the .exe directly made the application work without any apparent problems.

Also, good work on requiring the original install source when uninstalling.

And while I'm whining about MSI: why does it display progress bars at all when they're totally and completely useless, since they'll fill up several times (my personal favourite in this regard is the Office 2000 SR-1a update, which would fill the progress bar 17 times before reboot, and then 5 more times after reboot - yes, I installed it manually enough times that I counted).

Raymond said: "Hey, Igor, long time no see! Good to see that you're sticking to your rule that every comment must include the word 'suck'."

Hey there Raymond, it's good to be back, thank you.

But you are right, I should improve my comment writing skills -- I'll start using the word "blow(s)" as well from now on :)

Nitpick note: this post unintentionally includes the problematic word because it is a part of the quoted text.

>>Corrupted Files Make Your Applications Run Incorrectly

You say that as if I am the one responsible for file corruption when I am not.

In short, application which does not safeguard against invalid input data is not something I want running on my computer. Proper input validation was the first thing I learned when I started learning programming.

File checksums and data range checking have been invented so that responsible developers can write applications which fail gracefully instead of taking down the whole system if and when they really have to fail.

Igor: >>File checksums and data range checking have been invented so that responsible developers can write applications which fail gracefully instead of taking down the whole system if and when they really have to fail.

[I can't tell any more whether you are in favor of or opposed to MSI shortcuts. You hate them yet you argue for their features. -Raymond]

How about stopping doing involuntary things behind our backs? Don't do stupid reinstallation automatically; if your super smart Microsoft Installer detects that an installation is possibly corrupted, how about asking an user whether he wants to fix it or erase the damn application from the face of Earth completely? Don't create "evil shortcuts" by default; only if the site administrator wants them.

[I thought Office defaulted to normal install; install on demand is an option. The "evil shortcuts" are there for the people who choose install on demand. -Raymond]

But they are used even if you choose normal install.

BTW, the first version of the Windows Shell to support MSI shortcuts was I think the version that came as part of IE 4 SP2.

Raymond wrote [MSI is doing what it does because the install package asked for it. Or are you saying that MSI should ignore what the programmer requested and the documentation should be changed to read "DISABLEADVTSHORTCUTS: This setting is ignored. Advertised shortcuts are never created."?]

No, I think what we are all suggesting is that there should be one registry setting ("Installer Expert Mode"), with an appropriately buried GUI (like the disable UAC setting), that causes Windows Installer to display a dialog with all the override options (and a "remember these options as default" button) every time it starts. Then we power users could hit "Disable Advertised Shortcuts" and whatever other nifty options the installer team intended us to have, with the possibility to change them on a per-application basis, without having to pass command-line arguments. A setting to globally disable advertised shortcuts would be good too.

Raymond, my point was that MSI does an EVIL thing -- it attempts to auto-repair an application over and over again even though the installer cache is corrupted.

In my opinion, what is wrong is that the MSI offers some potentially usefull but at the same time dangerous options when not used responsibly.

One example is auto-repair launched by shell extension and advertised shortcuts.

If it is offering such an option to the setup maker, then it should be smarter -- it should check the size of the install package, checksum it and if corrupt give an option to remove the remnants and not bug the user again.

Another example is auto-defragmentation launched after the setup.

I have seen a lot of vendors using those options irresponsibly.

When someone is using something irresponsibly there has to be an override.

Here is a scenario for you and please do not anonymize it -- I want to read a XYZ document on a freshly installed computer and I am in a hurry. I launch XYZ Viewer installer, it installs the application, and it then proceeds to use Windows built-in defragmenter to defragment its files even though I use another one with completely opposite file sorting strategy, and there is nothing to defragment on a freshly instaleld system.

So it wastes my time (I can't use the application immediately), it does things I don't want it to do (messes up my file layout), and it doesn't give me an override === EVIL.

@Igor

"If it is offering such an option to the setup maker, then it should be smarter -- it should check the size of the install package, checksum it and if corrupt give an option to remove the remnants and not bug the user again."

I like your idea of CRC checking, but how do you present the user who isn't capable of making such decisions (for security or knowledge reasons) a dialog on that topic?  I think if there's a good way to do something like this then it would be a good thing.  Perhaps send your suggestion to msiwish@microsoft.com, since Raymond isn't the MSI team.

"Another example is auto-defragmentation launched after the setup."

Windows Installer doesn't support or deal with defragmenting anything.

But the truth is that you do have options.  You have simply chosen to ignore those options or you have chosen to not seek them out.  If you are a power user / administrator type user then use the power user / administrator type tools provided by the MSI team.  For example, start with the Windows Installer Cleanup Utility:

http://msdn.microsoft.com/en-us/library/aa370523.aspx

Also, if you don't investigate why you're getting auto repair it's going to be really hard to just solve the problem on your own or "fake" the MSI engine in to thinking nothing is broken.  Try out http://www.installsite.org/pages/en/msifaq/a/1037.htm

But mucking about with an application vendor's deployment strategy is not likely going to endear them to you and it's often times a violation of their EULA.

> Here is a scenario for you and please do not anonymize it

Come on, Raymond! I'm special, I shouldn't have to obey the rules of the blog as they apply to everyone else.

Bryan said : "I like your idea of CRC checking, but how do you present the user who isn't capable of making such decisions (for security or knowledge reasons) a dialog on that topic?"

User doesn't need to know about CRC or other technical details, all he should get is a dialog saying:

"XYZ's installer cache has been corrupted. As a result, installation auto-repair may not be possible. Would you like to"

( ) Attempt auto-repair anyway (may hang your system)

( ) Remove XYZ's remnants from your system so you can re-install it later

(*) Just leave me alone until the next reboot!

[x] Remember my choice for future installation issues with this product.

Would that be so hard to implement? I don't think so! Would it improve user experience? Tremendously!

One thing I agree with you though -- it is not Raymonds fault in any way. The reason I am bringing it up is MSI's tight shell integration which causes the problem and there is no override.

Bryan said : "Windows Installer doesn't support or deal with defragmenting anything."

I am not sure which interface is used for defragmentation (it appears to be using built-in defragmenter), but in the XYZ.msi in a Property table there is an entry called XYZ_OPTIMIZATION and it is set to "YES".

Bryan said : "You have simply chosen to ignore those options or you have chosen to not seek them out"

That is not true. I often use Orca to fix irresponsible use of MSI features when I am aware of it in advance.

However, in a situation when the installer hangs my computer repeatedly re-launching itself in a brain-dead attempt to repair from broken installation source what options do I really have?

Bryan said : "But mucking about with an application vendor's deployment strategy..."

You call that strategy?!? Oh man...

Anonymous Coward said : "Come on, Raymond! I'm special..."

I never said I am special, I just asked Raymond not to anonymize application name because I am not criticising the application but the deployment system, and I am giving an example everyone is already familiar with.

Oh, I forgot my fauvorite gripe with MSI installs: why won't they stay on non-primary monitors?!

> I never said I am special

Raymond's ground rules state:

"You can talk about a program, but you have to call it "Program X" or something like that."

You're saying you should be allowed to ignore the ground rules, unlike everyone else who posts on this blog. I call that "thinking you're special". Sorry if you disagree with the terminology.

Raymond said: "And that flag is custom to product XYZ. It's not part of MSI."

Raymond, you are right. This functionality is a part of XYZInst.dll which is included in the .msi file. It exports two functions -- DefragmentFiles() (from a proprietary table in the MSI database) and SetOptimizationStatus().

I am not ashamed to admit when I make a mistake -- I incorrectly believed that this functionality is offered by the Installer.

But there is still an issue with auto-repair.

Anonymous Coward said: "You're saying you should be allowed to ignore the ground rules..."

I believed that Raymond's rule:

"You can talk about a program, but you have to call it "Program X" or something like that."

Actually means:

"You can talk about a program (describing its bad behavior), but you have to call it "Program X" or something like that."

Since I wasn't talking about the program X's bad behavior but about what I believed was bad Windows Installer behavior I thought it was ok to mention the program name. Since it isn't Windows Installer fault in that particular case (thanks Raymond for clearing that up) I can now post a rant on my website bashing corporation's XYZ deployment strategy.