Question for programmers

[farmkid]

In order to run properly, most computer programs require being "installed", at which time files are put in the correct places, shortcuts are created, changes to the registry are made, etc. However, some programs are also available in a "portable" version which is totally self contained. "Portable" versions have everything required in a folder somewhere which can be put on a flash drive and run on any computer without installation. My question is, why aren't most programs built to be self contained like that?

Here are my thoughts on the question, which I'm hoping someone here can tell me where I'm right or wrong. I think it is preferable for programs to run this way because it would keep the computer cleaner and running better. One of the biggest complaints people have with their computers is that they slow down over time and become more unstable. I believe that is because of the frequent changes to the registry and other OS files by programs being installed and removed. If programs could be self contained as described above, many of those problems could be avoided. Computers could run much longer without needing cleanup and optimization and upgrading.

I know some programs have certain file types associated with them, and I understand that requires changes to the registry. Okay, that's fine, but what about all the rest? Do we really need services to be running in the background all the time? Do we really need those icons in the system tray that the vast majority of people completely ignore? I also understand that many settings are stored in the registry. Why not keep those settings in a file in the program's own directory instead?

I can see a couple of reasons that programmers do this. (1) It makes piracy more difficult. If programs were self contained and didn't require installation, it would be very easy to just copy the program from one computer to another. I'm sure there are other ways to solve that problem. (2) Having services running at startup may make the program start quicker when launched. Personally, I would rather wait a little longer when I launch the program than wait longer every time I boot the computer. (3) Those icons in the system tray make it easier to access certain functions. Okay, fine, but most people don't use them. Why not tell me what they do and then ask whether I want them or not?

My point is, I would rather have my computer start with the minimum OS components needed for proper operation and nothing else, except maybe AV software. If I have programs I want to run every time at startup, like Google Desktop or something, I can specifically tell the OS to start it. Don't make automatic startup the default. Also, I would rather that programs were as self contained as possible, so that when added or removed, they don't make any changes to the OS, other than perhaps file associations.

Okay, programmers, why can't I have my perfect computer world?

ETA: As I understand it, Macs don't have some of these issues. If so, okay, fine. but, I'm too cheap to get a Mac and I can't stand the superiority complex of many Mac users, so please no snarky comments suggesting I get one.

 

[Lindley]

Macs have some of the issues. They don't have a "registry" per se, but there are files generated (such as preferences files) at various places in the system. The big innovation there is that OSX has a concept of a "package", which is essentially a folder containing all necessary files which looks like an application because it auto-runs the primary exe when you double-click it.

It all comes down to shared vs static libraries. If a given bit of code is going to be used identically by 100 different programs, there's no reason to bloat all 100 programs with it; just put it in a shared library (.so on Unix, .dll on Windows, .dylib on OSX).

I *could* link in that functionality as a static library; it would make the program bigger, but also less dependent on installation. Given the trends toward larger hard drives, this may actually be a more desirable option in the future.

As for why background daemons may be required....usually that's program-specific functionality. It's not a general requirement.

 

[Jadzia]

I hate shared libraries. I'm all for portability. Avoid registry wherever possible. Use .ini files for configuration settings. Have all non-standard dependencies included in the application directory.

Some things that are basic system components, like directx, obviously, keep it shared. Codecs I'm not sure about. They're a bane either way.

 

[Lindley]

I'm assuming you mean shared?

 

[Jadzia]

yes I am

 

[TEH BABA]

Program thats only executable is more difficult to mod.

 

[Robert Maxwell]

Pretty much what the others have said: most apps aren't "portable" (that is, they require installation) because of piracy issues, and shared libraries.

On an OS like Windows, if your application requires registering certain components with Windows itself, this is not something a portable version could do--it would require installation. Programs that need to make changes to some part of your OS environment are also not portable for this reason. Your typical application does not require any of this, though, and can be more or less self-contained.

On Windows, this is also an issue because a "portable" app won't show up in the Add/Remove Programs list, and most people won't understand how to uninstall it--even though uninstalling would just involve deleting its folder!

Personally, I think the days of the "installed" application are numbered. A lot of businesses are moving toward zero-footprint applications, the proliferation of netbooks signals a shift toward thin clients and "cloud computing," and services like Steam demonstrate a way to make an application you've purchased portable between all the systems you have access to. I'm fine with making everything use static libraries, considering how often something is liable to break because program A needs library version 1.1, and program B requires 1.2, and 1.2 is not backwards compatible.

I know I've found myself having to drop a DLL into a specific location in order to make a program use that version, because some other program updated said DLL and broke its compatibility. If everything just had its own static version, sure, there'd be more files to worry about, but it would be much easier to avoid dynamic library hell.

 

[Robert Maxwell]

Pretty much what the others have said: most apps aren't "portable" (that is, they require installation) because of piracy issues, and shared libraries.

On an OS like Windows, if your application requires registering certain components with Windows itself, this is not something a portable version could do--it would require installation. Programs that need to make changes to some part of your OS environment are also not portable for this reason. Your typical application does not require any of this, though, and can be more or less self-contained.

On Windows, this is also an issue because a "portable" app won't show up in the Add/Remove Programs list, and most people won't understand how to uninstall it--even though uninstalling would just involve deleting its folder!

Personally, I think the days of the "installed" application are numbered. A lot of businesses are moving toward zero-footprint applications, the proliferation of netbooks signals a shift toward thin clients and "cloud computing," and services like Steam demonstrate a way to make an application you've purchased portable between all the systems you have access to. I'm fine with making everything use static libraries, considering how often something is liable to break because program A needs library version 1.1, and program B requires 1.2, and 1.2 is not backwards compatible.

I know I've found myself having to drop a DLL into a specific location in order to make a program use that version, because some other program updated said DLL and broke its compatibility. If everything just had its own static version, sure, there'd be more files to worry about, but it would be much easier to avoid dynamic library hell.

 

[farmkid]

On an OS like Windows, if your application requires registering certain components with Windows itself, this is not something a portable version could do--it would require installation. Programs that need to make changes to some part of your OS environment are also not portable for this reason. Your typical application does not require any of this, though, and can be more or less self-contained.

So, other than file associations, what other things would be required to be registered with Windows? What else might a program "have" to change in the OS?

 

[Robert Maxwell]

On an OS like Windows, if your application requires registering certain components with Windows itself, this is not something a portable version could do--it would require installation. Programs that need to make changes to some part of your OS environment are also not portable for this reason. Your typical application does not require any of this, though, and can be more or less self-contained.

So, other than file associations, what other things would be required to be registered with Windows? What else might a program "have" to change in the OS?

Shell extensions, for one thing. I think there are some kinds of libraries (OCX?) that require registration before they can be used. I could be wrong--there may be ways around it. But I've had a fair number of programs that wouldn't work unless all their wacky registration stuff was done, too--even if you stuck the libraries right in the program's folder, it didn't work.

 

[Hermiod]

Not being modular, in these days of patch patch patch is dumb.

You fix a small bug in one library, so the user has to download a few hundred kilobytes.

You fix a small bug in an entirely self-contained .exe and the user has to download multiple megabytes.

Not to mention, if you install Microsoft Office, for instance, Word, Excel, Outlook, PowerPoint, Access and everything else are sharing code. The footprint if they were all just one .exe each would be about five times larger.

 

[farmkid]

^I understand your point. However, I wasn't talking about a single self-contained .exe file. The "portable" versions of software I was talking about function by putting everything needed in a single folder, and not requiring any changes to the OS to operate. The ones I've used as a portable version are Firefox, OpenOffice, and Glary Utilities. There are many more such programs, but those are the only ones I've used. They work just as well as the regularly-installed version, except that the install procedure only creates a folder with all the necessary files in it. It doesn't change the registry or any other OS component. Such software can be updated just the same as any other software.

What started the whole thing was I was wondering why more software isn't of the self-contained variety. It seems to me that most of the complaints people have with their computers is attributable to the OS bloat and corruption that occurs as a result of changes to the OS caused by installation and removal of software. I was just wondering why programmers don't limit their software to such integration with the OS to instances when it is necessary. The portable application issue is simply an example to show that many programs can run just fine under such a model.

 

[Jadzia]

Some components are more naturally shared: directx libraries, audio codecs, video codecs, picture formats, zip libraries, file type descriptions and icons, and fonts, plus things like start menu entries, right click menus, and desktop shortcuts are all installation type things.

I agree with your post that portability is good. In fact things at one time were more portable than they are now, in the DOS days, and games in particular were entirely contained as files in single directory. No installation needed.

unix on the other hand has relied more on sharing, because applications there are traditionally modular, being built simply up as assemblage of smaller component applications that work in sequence. Everything is shared.

There's something to be said for that software ideology, because it is potentially very powerful, but it doesn't upgrade well.

 

[Noname Given]

As a Programmer and someone who's been tinkering with them simce 1975 (yes, I started on Mainframes):

1) In the 'old days' most programs were self contained; and th only reason yhou put them in a single directory wasd so you could easily find the files and change/update/recompile as needed.

2) In the days of DOS; some programs had self running install routines; and others just said:

"Create a directory. Copy these files from the floppy to that directory. Run file 'programname.exe.

Hell, in those days, if the program diretory and it's files were small enough to fit on a floppy (or CD) and you were running DOS; just copying the direcory and transferring it to a different PC meant you could run the software.

3) The 'Windows Registry' was NOT created to optimize your operating system; and make it run smoother per se; it was created as a way that Microsoft could peek at your setup, and see what was installed; AND it was also a way software developers could better protect their work from just being 'directory copied' and pirated.

Even in the early days of Windows, most developers STILL wrote their own install roputines because while MS offered an intigrated installer that (if you followed MS instructions) would install your spftware on a Windows OS and provided check/validation info IF you wanted it; BUT MS charged a pretty penny for that tool, so most developers stuck with writing their own.

Then, with Windows 95; MS instituted 'specs' that all apps were supposed tp follow; and if you did, you were able to put a 'works with Windows' logo on the box; the primary thing that MS was looking to dfix was - that while developers did write install eroutines, they often did not bother to write unistall routines; and usiually, just deleting teh program dorectory left unwanted entries in the Windows Redistry file, which sometimes caused problems; and also offered a scaled down versuin of their install utility for free; so that at worst, one could always have teh capacity to install or uninstall software.

But, make no mistale - the Windows Registry was originally a 'piracy combat' tool for MS first and foremost.

 

[plague]

It's my understanding that the windows registery was designed to store program settings all in one place and with one method. I doubt that it was an anti-piracy tool, as it doesn't prevent one from copying Windows or any Microsoft software.

It's still used today because why reinvent the wheel? If you're developing for windows, and need to store a setting, there's already a method to do it. Even for portable software, it still makes sense to store settings relevant to that workstation in the registry.

 

[Robert Maxwell]

The registry can be used for anti-piracy purposes but it's unfair to say that's explicitly why it was created. It isn't. The vast majority of what it stores has nothing to do with piracy. It's largely configuration and option data. Any smart program will go back to defaults when it can't find registry entries for its settings, though. I know I make an effort to do that to account for a "portable" or "non-installer" situation.