Alright, the Windows 8 appstore is a non-starter (except for fart-apps)

The wide variety of delivery mechanisms, installation tools, and overall approaches to updates across the full breadth of applications makes it impossible to push all updates through this mechanism.  As frustrating as this might be, it is also an important part of the ecosystem that we cannot just revisit for the installed base of software.

How about a solution like this:

Expose an API in Windows that any application developer can use that:

• Allows an application developer to have their application listed in a common Add/Remove/Update list (hey, we already have 2/3 of that!). Note that the application should not need to actually have an installer. Some things like plugins often don't have installers.
• Allows the application to push its current version to the list so that it can be displayed.
• At installation, lets Windows knows which URL to use to check for the latest version.
• When the user goes into this list, Windows checks all listed applications for their latest versions from the supplied URLs.
• Allow easy filtering in the list so that for instance only applications for which there are updates available are listed.
• Allows the user to at least download the latest version via a button in the list, or (better) allows the user to click on a button that will automatically download and run the latest installer to update the application.
• Show a weekly message (or on a user-selectable schedule) of which applications are out of date.
• Is available from all frameworks, Win32, WinRT, .Net, etc.

The above should be simple for MS to implement, and they would not be responsible for having to track any 3rd party applications themselves. However it would be in the application developer's best interest to make use of this simple API so that their users can easily know when updates are available.

@BitFlipper: Just think of the fun malware writers could have with that implementation.

Not to mention that standardising the installation experience was tried years ago with MSI and even now the vast majority of applications use all manor of different installer engines still. What would be different about this one that somehow got everyone to agree?

39 minutes ago, AndyC wrote

@BitFlipper: Just think of the fun malware writers could have with that implementation.

Not to mention that standardising the installation experience was tried years ago with MSI and even now the vast majority of applications use all manor of different installer engines still. What would be different about this one that somehow got everyone to agree?

Well, with my proposed scenario the applications can still use whatever installer they want (they can call into the API to register themselves every time they run - no problem if the application registers the same values multiple times). So the requirement to use MSI is not there. In fact the application/plugin doesn't even need an installer at all in this case.

As for your malware comment, when the applications calls the API to register themselves, and Windows detects that the values passed in doesn't yet exist or is different from the previously registered values, Windows can pop a dialog saying that application XYZ wants to add/update the Add/Remove/Update list. The user would know if they didn't specifically just installed XYZ or didn't ask to have the application update itself. This is no different from how malware would trigger a similar dialog if they tried to make system changes today.

This is not rocket science. Such an API would be extremely simple. Probably two calls: RegisterApplication (Application name, URL to query latest version, current version number, installed folder, [URL for the application website that the user can click on to get latest info]). In addition there would also be: UnregisterApplication (Application name).

An example where this would be extremely useful is for instance with VST plugins. These are DSP plugins for audio applications (DAWs). VST plugins typically only consist of a single DLL that the user downloads and manually places in a folder (or subfolder) that the host audio application is configured to scan. Very few VST plugins have installers. So with my proposed solution, making one call into RegisterApplication from each DLL at startup would create a centralized list where I can easily see which plugins are out of date. I currently have more than 300 such VST plugins (and that is a small fraction of all available plugins), and with a lot of those it is a pain to track down their websites from time to time to figure out which ones are out of date.

Of course it doesn't guarantee that the applications will use it, but if such a simple mechanism is in place, application developers might see the benefit themselves and make the simple change to support it.

15 hours ago, AndyC wrote

@magicalclick: And who says you won't be able to? It's perfectly possible to write a full C++/DirectX game within the WinRT framework and the full screen behaviour is perfectly suited to games.

If they are as awesome as CoD, Battlefield, and Crysis, I am all good.

38 minutes ago, magicalclick wrote

*snip*

If they are as awesome as CoD, Battlefield, and Crysis, I am all good.

Why wouldn't they be?

3 hours ago, PaoloM wrote

*snip*

Why wouldn't they be?

Beats me. Like I said, I hope the statements are just speculations.

4 hours ago, PaoloM wrote

*snip*

Why wouldn't they be?

Uhm, easy:

If only WinRT applications get the appstore treatment that means that devs can only target Windows 8 and leave XP, Vista, and 7 in the dust (or write a "normal" and a special Win 8 version just to be listed in appstore - fun) Why should they do that? Steam is the monopoly in games distribution.

More work to cover a niche. Just look how long it took until DX 10/11 exclusive titles arrived and how few they are still.

I won't deny that there could be very well lots of WinRT+DX11 powered games in the appstore.. but it's sure this won't happen in Windows 8's time. Maybe with Win 9 or 10. Just around the time when Metro will get bastardized.

@BitFlipper: If Vista taught anyone anything it's that asking the user every time you need to make a security decision is a recipe for disaster, baking an API into Windows that fundamentally requires annoying UI just isn't a good idea.

13 hours ago, wastingtimewithforums wrote

*snip*

Uhm, easy:

If only WinRT applications get the appstore treatment that means that devs can only target Windows 8 and leave XP, Vista, and 7 in the dust (or write a "normal" and a special Win 8 version just to be listed in appstore - fun) Why should they do that? Steam is the monopoly in games distribution.

More work to cover a niche. Just look how long it took until DX 10/11 exclusive titles arrived and how few they are still.

I won't deny that there could be very well lots of WinRT+DX11 powered games in the appstore.. but it's sure this won't happen in Windows 8's time. Maybe with Win 9 or 10. Just around the time when Metro will get bastardized.

Point. Set. Match. Well said.

6 hours ago, AndyC wrote

@BitFlipper: If Vista taught anyone anything it's that asking the user every time you need to make a security decision is a recipe for disaster, baking an API into Windows that fundamentally requires annoying UI just isn't a good idea.

Bitflipper I like your idea. The price of an extra prompt for getting a single place for people to get and maintain their apps is cheap. I wouldn't put much stock in what Andy is saying; IMO, back in the Vista days he'd be the one saying what a great thing UAC was.

7 hours ago, AndyC wrote

@BitFlipper: If Vista taught anyone anything it's that asking the user every time you need to make a security decision is a recipe for disaster, baking an API into Windows that fundamentally requires annoying UI just isn't a good idea.

You will only get the popup right after you explicitly request to have the application update itself, so I fail to see what the big deal is. You won't see it while running the applications normally.

@BitFlipper:

I think most people will just click install anyway. So, it is not about asking user whether to make the registry change or not. Instead, the registry should be easily recoverable. For example, the value is never ever modified unless it is the value's owner. If it is not the value owner, then, it is only appended. If you delete the malware, it simply just remove the appended value and return back to normal. If you like, you can also remove all appended values to clean out everything.

5 minutes ago, magicalclick wrote

@BitFlipper:

I think most people will just click install anyway. So, it is not about asking user whether to make the registry change or not. Instead, the registry should be easily recoverable. For example, the value is never ever modified unless it is the value's owner. If it is not the value owner, then, it is only appended. If you delete the malware, it simply just remove the appended value and return back to normal. If you like, you can also remove all appended values to clean out everything.

I see what you are saying and I agree that users would mostly click install anyway. The thing is though how does the OS know that a newly downloaded piece of software is truly the "owner" of a previous entry? For instance, let's say the user is tricked into downloading and running some malware. This malware calls the register API and claims it is some popular application. Since the OS can't tell the difference between a malicious installer and the true installer (both would be something the OS never saw before), this could be problematic. If the malware then changes the application settings with a new download URL, there is a problem.

However I'd argue that when the user was tricked into running the malware it was game over anyway so in the big picture I think this whole line of reasoning is moot.

I think one would need to demonstrate how this mechanism would make the system any more vulnerable to malware than what it already is (or isn't).

15 hours ago, AndyC wrote

@BitFlipper: If Vista taught anyone anything it's that asking the user every time you need to make a security decision is a recipe for disaster, baking an API into Windows that fundamentally requires annoying UI just isn't a good idea.

Incorrect. What Vista taught Microsoft, and what the users already knew, was that changing the time zone, defragmenting the hard disk, and intentionally clicking start -> control panel, and then double clicking on a control panel applet are not security breaches.

The prompts aren't a recipe for disaster. Throwing them up in someone's face for no reason is.

6 hours ago, BitFlipper wrote

*snip*

I see what you are saying and I agree that users would mostly click install anyway. The thing is though how does the OS know that a newly downloaded piece of software is truly the "owner" of a previous entry?

They just need the application digitally signed and verified online (including revoking the compromised signature). The installer with out-dated signature will append the value instead of modifying the value.

Anyway, that would be a big topic for sure. Those things are certainly not easy.

@Craig_Matthews: But it's the exact same problem, it leads to Windows confirming something you just told it you wanted to do e.g.

User: Go into Firefox and turn off AutoUpdate
Windows: It looks like you're trying to turn off updates for Firefox, Are you sure you want to do that?
User: Stupid Windows!

(doubly so if this a system-wide application setting, as it then gets followed up by a UAC prompt!)

It doesn't matter if, as IT professionals, we know that Windows has to do this kind of thing to prevent malicious changes, end users think it's stupid.

And yes, for the record, I do think UAC was and is a good idea and I keep mine on the highest setting. The difference is that there is a very clear line the delineates when I, as someone experienced, should say No to a UAC prompt. By contrast I'd never know if one of these updates prompts came up if it were genuine or not - did it just ask me about Firefox updates because they've now moved over to using the central update system or is it just some pesky malware pretending?

And that's to say nothing of the applications that would inevitably end up abusing a system like this to get Windows to nag you into buying the latest version.

10 hours ago, magicalclick wrote

*snip*

They just need the application digitally signed and verified online (including revoking the compromised signature).

OMG! Microsoft are ripping off developers with the Verisign tax, etc....

15 hours ago, magicalclick wrote

*snip*

They just need the application digitally signed and verified online (including revoking the compromised signature). The installer with out-dated signature will append the value instead of modifying the value.

Anyway, that would be a big topic for sure. Those things are certainly not easy.

I think once you require certificates you might as well forget about something like this ever being successful. The whole point is to keep it simple so that developers don't balk at implementing the minimal amount of work needed to make it useful for both themselves and for end users.

On the OS side things could be made more complex, but this should be transparent to developers and users. For instance, once a new version is registered, MS might provide a service back at the mothership that automatically downloads a copy of that file from the supplied download URL and does a security scan on it. Only after it passes does it allow Windows to actually download/install that file.

I would like to see ClickOnce applications install through the App store...

Also the current model seems to create problems for people who want both Immersive and Desktop versions of their apps, where the two versions would switch between each other. You would have to tell the user to download two separate apps in two separate places, leading to a complicated install process. I think the "full screen mode" metaphor that Apple is using is basically a good idea, and all of these steps in the middle would break that type of metaphor.