What is your take on the way programs install ?

[Modelworks]

Most windows programs install the program in somewhere like program files, and then proceed to install files into the windows directory, the registry, documents folders, etc. This causes several problems like, DLL version mismatch, files that are not removed, settings stored in places the user can't find.

The whole thing with shared files started because of lack of storage space. You didn't want every program bringing along another 2MB of system files that were already on the hard drive, when your hard drive might only hold 40MB.

Even linux is not immune to the problem. There are often many times conflicts caused by the wrong version of a file being installed. If the files that were needed were brought along with the program then that issue goes away.

The trend is to go towards portable apps. Applications that run from only the directory they are installed into. I like the idea , in that it is easy to track what a program installs. Everything that program needs is in that directory and there is no chance of another program interfering with the one I am using.

The current system would have to be changed slightly to make it work well but I do think this is the future.

Until then :
http://portableapps.com/
http://www.pendriveapps.com/

It works well most of the time, but startup time for applications and sometimes performance of the application itself can be slow.


The only drawback I can see is when something like a security flaw is found in a dll, distributing the fix might be a problem.

I think application developers, myself included , would love it . Imagine the install process being just unzipping to a directory and the user clicking the program to run it. No more setup and install programs.

 

[Nothinman]

Even linux is not immune to the problem. There are often many times conflicts caused by the wrong version of a file being installed. If the files that were needed were brought along with the program then that issue goes away.

That shouldn't happen, if it does then just file a bug with whoever made the package that's causing the problem.

The only drawback I can see is when something like a security flaw is found in a dll, distributing the fix might be a problem.

Which is a pretty major drawback these days. People are already terrible at keeping their systems patched and now you want to make it worse by having dozens of copies of the same files on their system?

 

[Modelworks]

Originally posted by: Nothinman

Even linux is not immune to the problem. There are often many times conflicts caused by the wrong version of a file being installed. If the files that were needed were brought along with the program then that issue goes away.

That shouldn't happen, if it does then just file a bug with whoever made the package that's causing the problem.

What about having to hunt down packages just to get a program to run ?

The only drawback I can see is when something like a security flaw is found in a dll, distributing the fix might be a problem.

Which is a pretty major drawback these days. People are already terrible at keeping their systems patched and now you want to make it worse by having dozens of copies of the same files on their system?

That can be dealt with though fairly easily. It would just require an updater program that scans folders for the files and makes note of them . Think of the benefit to security. If an application that uses a certain DLL for interfacing with a mouse only, that DLL does not have to be updated because a flaw was found that allowed someone to use that same DLL in a program that used it for interfacing to a nic.

It is going to be the future of applications. The whole portable apps scene has gone into overdrive. People I think are tired of the current methods and the hassles that come with it. They want plug and play with little to no configuring.

 

[Nothinman]

What about having to hunt down packages just to get a program to run ?

Outside of one or two oddities like VMware I stick to what's in Debian's repository so I haven't had to hunt down a package in a very long time.

That can be dealt with though fairly easily. It would just require an updater program that scans folders for the files and makes note of them . Think of the benefit to security.

That would require that developers properly tag and version their libraries which I can tell you right now isn't the case. And if the flaw was a problem with how the library works updating it could very well break apps expecting the old interface and your updater app just broke lots of people's systems. You can't just blindly update things without takikng into account what the update changes and how apps use that library. And if you're updater is running around keeping them all at the latest version anyway why not just have them all use the same copy?

If an application that uses a certain DLL for interfacing with a mouse only, that DLL does not have to be updated because a flaw was found that allowed someone to use that same DLL in a program that used it for interfacing to a nic.

And how is that different from what we have now?

It is going to be the future of applications. The whole portable apps scene has gone into overdrive. People I think are tired of the current methods and the hassles that come with it. They want plug and play with little to no configuring.

And AFAIK all of those portable apps are for Windows which suggests to me that the problem is with how Windows handles things, nothing more. I already have plug and play installs with little to not configuring with Debian.

 

[AnonymouseUser]

Cedega has a system where every game install has it's own virtual windows install. If only this could be done in Windows...

 

[bruceb]

The real issue is program installers should not be able to change or modify factory Microsoft .dll files in any way.
They should either be written to work properly with the Microsoft .dll files, or if they need their own, then they should
be in the program directory where the program installs.

 

[Nothinman]

They should either be written to work properly with the Microsoft .dll files, or if they need their own, then they should
be in the program directory where the program installs.

Which is easily doable with the tools currently available, but most Windows developers are idiots.

 

[bsobel]

Originally posted by: Nothinman

They should either be written to work properly with the Microsoft .dll files, or if they need their own, then they should
be in the program directory where the program installs.

Which is easily doable with the tools currently available, but most Windows developers are idiots.

Windows SXS already handles this.

 

[pcgeek11]

I know we can just go back to DOS.

Seriously. It has been a Very Long time since I have had a problem with this. I know it does happen, but it is usually a very crappy application that causes thes types of problems.

pcgeek11