Hacker News Reader

Comment by potatolicious | Hacker News Reader

Self-contained installations are an absolute critical must in the evolution of Windows. It's downright embarrassing how installing even a simple app will spray files all over your filesystem diarrhea-style, making it impossible to remove (sometimes even by using the uninstaller!)

So far Apple hasn't really enforced the app-container design pattern very strictly, though I think they ought. Adobe is the most egregious violator of this - they spew files all over the MacOS filesystem and require their proprietary installer to do anything to the app.

On top of this idea is the necessity to remove the registry altogether.

View on HN

For good or bad, Microsoft has committed to backwards compatibility. That means that all the techniques that work for installing apps now will work until Windows 7 is no longer supported.

My team has put a lot of effort into making our install more contained, but certain things still need to go in system locations. Registering a handler for a file extension means writing to the registry, as does (ironically) registering for visibility in the Add/Remove Programs UI.

I'm certainly jealous of the bundle system on OS X, but it doesn't solve everything. Device drivers still need to associate hardware devices with a handler, which we have to run code for on OS X.

>For good or bad, Microsoft has committed to backwards compatibility.

I wonder if they couldn't get around this by breaking compatibility on a new OS version and then running something akin to Wine to run apps for older OS versions.

They do. Sorta. It is called "Windows XP Mode" (XPM), but it has some fairly significant limitations: it is only available to Windows 7 Professional, Enterprise, and Ultimate editions. It also suffers from the overhead limitations of VMs - for instance, the video "card" is emulated so video-intensive programs suffer.

http://en.wikipedia.org/wiki/Windows_Virtual_PC#Windows_XP_M...

They also have an emulator for 16-bit apps on 32-bit Windows, and for 32-bit apps on 64-bit Windows.

    it is only available to Windows 7 Professional, 
    Enterprise, and Ultimate editions

That's sounds like a business issue, not a technology limitation, unless there are costs associated with it that make it impossible for them to offer it across all of the many versions.

    It also suffers from the overhead limitations of VMs

OS X was in a similar situation, twice: first with the OS 9 classic environment then with Rosetta for PPC-compiled apps. Performance with each was less than ideal, but that's what was needed to move on.

That's totally different then. WINE is just an implementation of the Windows API that also sand boxes windows applications into one area. Since windows actually has their API they could pull this off much better than WINE does.

There is no earthly way that an app-store style platform for Windows would be backward compatible, but it doesn't have to be. New apps would run in a sandbox and only those would be allowed to use the slick new distribution system, go in the app store, etc. Legacy apps would run the same way they do now. Some day, there would be no more legacy apps but until then, the two types can happily coexist.

What they need is something like ".NET App Framework" that offers a complete platform in a sandbox. They could easily leverage existing Windows and .NET functionality to the point where the platform would be considerably more powerful than iOS/Android/WWW and very difficult to clone. Making it touch-friendly would be a good idea too.

This is a far better option for them than trying to clone Google's clunky web apps or start yet-another-smartphone-platform. There are really only a few critical things that allowed those models to successfully compete with the desktop, so figure out what those things are and fix them. Contrary to Microsoft gospel, the market is clearly willing to throw everything away and start from scratch, just to fix the bloody mess they made, so do it.

> Registering a handler for a file extension means writing to the registry, as does (ironically) registering for visibility in the Add/Remove Programs UI

But it doesn't have to be that way. Microsoft can deprecate and replace those outdated mechanisms while still supporting them.

OS X's bundle system is indeed elegant, but it's been around for 20 years (!) and its benefits are well understood. You have to wonder how long it has to take for Microsoft (and others) to catch on.

The problem with mandating self-contained applications is that there are some useful features associated with applications that are INHERENTLY not self-contained. Shell integration is a good example, but basically any kind of integration or shared functionality (or even data) with the system or with other applications falls in this category.

The manifest approach described by Miguel could be a good compromise, but it's not immune to problems.

Do you know how Bash does shell integration? (E.g. program specific completion?)

It does that with a completion script, typically put in /etc/bash.completion.d. All scripts in this directory are sourced by /etc/bashrc. Each app provides its own completion script.

Thanks. Sounds relatively contained. You could probably make it even more contained with some symlink magic or so.

No, you don't understand packaging systems.

The packaging system (RPM, deb) tracks files installed anywhere on the filesystem, including ones in /etc/bash.completion.d/, and will remove all of them when the application is uninstalled. "Symlink magic", whatever that is, won't help at all.

> No, you don't understand packaging systems.

I know that the package manager keeps track of it. I did not express myself clear enough.

> The packaging system (RPM, deb) tracks files installed anywhere on the filesystem, including ones in /etc/bash.completion.d/, and will remove all of them when the application is uninstalled. "Symlink magic", whatever that is, won't help at all.

If all the files needed for a package / program are in one place, the job of the package manager gets easier.

You might want to have a look at GoboLinux. They are trying to make the file system the package manager. (Haven't used it, yet, though. Still using a Linux with a traditional package manager.)

Obviously no piece of software is self-contained. It has to make use of some sort of resources and interact with the user in some way. For a sandboxed platform, you carefully design the APIs to not grant any unintended privilege to apps. You can still do all sorts of fancy integration, you just do it through an airtight API.

Installers on OS X have a manifest of files they install. I'd be surprised if MSI didn't do the same, but I guess not everyone uses MSI. On OS X most apps still leave prefs or other files around too so it's not perfect, but it's something. Tools like AppTrap can help clean up cruft when you delete apps.

Reply on news.ycombinator.com