Hacker News Reader

Comment by zozbot234 | Hacker News Reader

> The Ruby application would behave like a native application, with its own identity in the Start Menu/Task Manager

You've always been able to achieve this by changing settings/properties on a .LNK file - or a .PIF file for MS-DOS based applications, as far back as Windows 3.x. (With the 'canonical' .LNK file for an app being precisely the one that's linked in the user- or system-wide Start menu). This stuff has worked just fine for the last 25+ years. Sandboxing is of course new, but MS-DOS applications linked in .PIF files used the same strategy to define sandbox-like properties, and .LNK properties could be extended for the same purpose.

View on HN

A LNK/PIF doesn't give a coherent view of the whole "app" from the user's point of view, though.

If you delete the LNK, you don't uninstall the app -- you just can't access it easily any more. If you create a second shortcut to the app, then uninstall the app, the second shortcut lingers but doesn't work.

If you install an app, it might put two or three shortcuts onto the start menu -- lets say it's a video game, and it installs a shortcut for the game itself, and another for a settings tool. (If it's an old game, it'll probably install a shortcut for the uninstaller, too). Which of those shortcuts should the start menu highlight as the newly installed app, to help the user discover it?

You can make the argument that an abstraction based on files, paths, individual executables and command line arguments (which is what LNK/PIFs support) is superior, and I think a lot of people on HN would agree -- but it's not the abstraction that new computer users being trained on mobile devices are internalizing.

It should also be emphasized how game changing proper packing is in itself. Historically Windows scripts, installers, applications, etc could liberally spray the filesystem and registry with their content. Cleaning this up was rarely easy as it relies on each script (or uninstaller, etc) to do the job right.

Proper packing gives more control to the user in this regard. Changes to the filesystem or registry will (by default) be contained. It's worthwhile to make this type of packaging easier and better integrated.

> Historically Windows scripts, installers, applications, etc could liberally spray the filesystem and registry with their content.

They could do this, but suggested standards have always existed, e.g. system-wide files in a sub-directory of $PROGRAM_FILES, user-specific data in $APPLICATION_DATA and the like. Then, in principle, a general uninstalling procedure can figure out what it needs to delete. It's not clear what all the extra complexity in these newer standards is adding.

Suggested standards have existed but they are routinely flouted in practice. These packaging systems make it much easier for developers to do the right thing and harder to do the wrong thing. And it gives the user confidence that they can easily remove an application in its entirety.

It was left up to application developer to implement, and each software house could fuck it up.

Just think about computer games, I have one that saves savegame files in app data, one that saves it to my documents, and an older one that saves them into program files.

Now the 'container' is managed by the os, and the OS can actually tell me how much space an app is taking, and update/delete it with all the residual files

Reply on news.ycombinator.com