Why write non-portable software?

[webfork]

(To avoid a thread hijack, I moved this response from m^(2) to a new topic.)

I too think there's too little portable (across various platforms) software and portability deserves more attention and promotion.

I'd go a step further to say I don't understand why Windows developers write non-portable software. Unless its commercial software where there's per-seat licensing issues or writing software specifically for novice users, it just doesn't make sense.

• Starting over too often means you lose settings. Reinstalling Windows every 6 months because of registry buildup and other weird problems that develop over time means you have to reinstall programs anyway. Saving and restoring settings/preferences in 20 or 30 programs is just not something I'm willing to do. Google Apps, Ninite, and many other 'web desktop' systems are currently trying to solve this.
• Backup problems - Backup programs going back as far as I can remember can't back up both the registry and \Program Files directory together. Those program that can seem to insist on backing up the entire OS, which really shouldn't be necessary. Additionally, a full OS restore could carry over problems from the previous install.
• Start Menu clutter - Even if you escape registry problems, at some point you can't find anything in your Start Menu, as there's just too many programs. You can rename it and put things in subfolders, but after the 3rd or 4th reinstall, I'm not interested.

In contrast to no-install portable software:

• No starting over
• Backup is ultra-easy
• I add my portable programs once. I might need to re-organize them sometimes but that's a lot easier than re-adding them over and over again.

I can remember when Win95 originally came out how pleased everyone was to have installers that would tie nicely into the OS, since Win 3.1 and DOS handled this poorly. Now I cringe at having to run any installer.

[m^(2)]

(To avoid a thread hijack, I moved this response from m^(2) to a new topic.)

I too think there's too little portable (across various platforms) software and portability deserves more attention and promotion.

I'd go a step further to say I don't understand why Windows developers write non-portable software. Unless its commercial software where there's per-seat licensing issues or writing software specifically for novice users, it just doesn't make sense.

• Starting over too often means you lose settings. Reinstalling Windows every 6 months because of registry buildup and other weird problems that develop over time means you have to reinstall programs anyway. Saving and restoring settings/preferences in 20 or 30 programs is just not something I'm willing to do. Google Apps, Ninite, and many other 'web desktop' systems are currently trying to solve this.
• Backup problems - Backup programs going back as far as I can remember can't back up both the registry and \Program Files directory together. Those program that can seem to insist on backing up the entire OS, which really shouldn't be necessary. Additionally, a full OS restore could carry over problems from the previous install.
• Start Menu clutter - Even if you escape registry problems, at some point you can't find anything in your Start Menu, as there's just too many programs. You can rename it and put things in subfolders, but after the 3rd or 4th reinstall, I'm not interested.

In contrast to no-install portable software:

• No starting over
• Backup is ultra-easy
• I add my portable programs once. I might need to re-organize them sometimes but that's a lot easier than re-adding them over and over again.

I can remember when Win95 originally came out how pleased everyone was to have installers that would tie nicely into the OS, since Win 3.1 and DOS handled this poorly. Now I cringe at having to run any installer.

I was talking about cross-platform portability, not USB one.
But answering your question, the reason is MS wants it this way.
Example:
http://msdn.microsoft.com/en-us/library/ms995853.aspx

BTW I wonder, how is it in Linux.

[SYSTEM]

I can answer webfork's question as well.

Most pieces of software are installed into the Program Files directory, and under Windows NT operating system family, writing to that directory requires administator rights.

If an application stores its settings within its own directory, changing settings (and usually even running the program) requires admin rights. That requirement may be acceptable for home users, but for enterprises it's completely unacceptable.

By contrast, storing settings within %APPDATA% or HKEY_CURRENT_USER doesn't require administator rights. In addition, storing settings there doesn't cause any harm to any user... except that it breaks portability.

Moreover... http://en.wikipedia.org/wiki/Talk:Porta ... t_registry

As a result, all serious software development companies create non-portable software. After that, other companies pay $5000 each for VMware ThinApp licenses...

----

An interesting discussion about Windows registry: http://discuss.joelonsoftware.com/defau ... .264513.27

Funny. Win 3.1 used INI files for everything. This led to INI file hell, where all these INI files resided in the SYSTEM directory for their applications to find them.

Their solution? Registry Hell. This has all the drawbacks of INI hell, except that it is mostly invisible to casual users. And makes backing up and restoring your root drive problematic.

How to upgrade the operating system and preserve all settings of individual applications:

GNU/Linux: move the /home directory to its own partition (assuming you haven't done it earlier). Tell the new version of the distribution to mount the new partition as /home.
Windows 3: look at countless directories in order to find INI files. Backup the files somewhere and create a list of their original locations. Finally, restore everything back after the upgrade.
Windows 9x/NT: forget it.

Microsoft tried to make reinstalling/upgrading Windows easier, but failed spectacularly. A tool called Files and Settings Transfer Wizard exists, but I doubt it copies the settings of rare applications. (I'll find out when I upgrade to Windows 7.)

----

Starting over too often means you lose settings. Reinstalling Windows every 6 months because of registry buildup and other weird problems that develop over time means you have to reinstall programs anyway. Saving and restoring settings/preferences in 20 or 30 programs is just not something I'm willing to do. Google Apps, Ninite, and many other 'web desktop' systems are currently trying to solve this.

BTW, my copy of Windows has worked for two years without reinstall. Problems are minor (such as Event Log warnings) and caused by too extreme tweaking.

[m^(2)]

I can answer webfork's question as well.

Most pieces of software are installed into the Program Files directory, and under Windows NT operating system family, writing to that directory requires administator rights.

If an application stores its settings within its own directory, changing settings (and usually even running the program) requires admin rights. That requirement may be acceptable for home users, but for enterprises it's completely unacceptable.

By contrast, storing settings within %APPDATA% or HKEY_CURRENT_USER doesn't require administator rights. In addition, storing settings there doesn't cause any harm to any user... except that it breaks portability.

Application developers can go around it simply by not installing to Program Files. Total Commander does so.

[SYSTEM]

Application developers can go around it simply by not installing to Program Files. Total Commander does so.

Correct, and I think it's a good idea. Unfortunately most applications don't do that by default.

[carbonize]

Why can't all software be portable? How about we start with the basics such as if all software had to be portable we wouldn't be using .NET software. If they had to be portable they could not be tied in to the system context menu nor set to be the default program to use when opening a particular file type. Also, as SYSTEM pointed out, you need admin writes to make any changes to the Program Files directory meaning no malware can hijack your software unless you're stupid enough to allow it.

As to the argument about the start menu getting cluttered and full just how much software have you got installed and I'm pretty sure you could get rid of some of it if you put your mind to it.

[lyx]

I think carbonize takes too many premises for granted.

If portable software were the norm, a lot of things on a windows system would work differently. Applications would not need to "register" themselves permanently into some startmenu - rather, they would be detected automatically at runtime. .NET wouldn't be such a big beast and instead be designed to be integrated into the application distribution (only the parts necessary for that app). And so on, and so on. All those things are not the way they currently are, because it has to be done this way - rather, the infrastructure currently is the way it is, BECAUSE most software is assumed to be non-portable. Thus, the infrastructure is no justification - it is just the consequence of a decision to promote non-portability.

In my opinion, the original reason was a technological one. Hard drive space was limited - applications would quickly eat up free disk space. Yet, there was the need to have different settings per user - but not the diskspace to have the whole application once per user. And thus, the thought was "Let's seperate applications from their settings. The big apps are only in one central location, but the small settings are saved per user."

Of course, nowadays this for most applications has nothing to do anymore with practice. Hard drive space is wasted for trivial things all the time, while applications are still split from their settings to save diskspace. I am not an advocate of the "memory is cheap, lets waste it"-mantra, but i do think, that with applications, there is are very good reasons to not cut diskspace by seperating them from their settings. When in other areas, diskspace is wasted for things of little benefit, but with apps, we're suddenly stingy, i think something went wrong.

Some of the benefits were already mentioned. Another benefit i mentioned a while ago regarding security (and was ridiculed for it by people who didn't understand it). Another benefit is roaming. If all apps would reside in the users profile, then there is little left to do, to have entire portable user profiles, without the need for any magic.

[carbonize]

If portable software were the norm, a lot of things on a windows system would work differently. Applications would not need to "register" themselves permanently into some startmenu - rather, they would be detected automatically at runtime.

And how would they do that unless they added themselves to a list somewhere? You know, something like the registry or windows.ini ? How would your anti virus program work seeing how, if it's not built in to Windows, you would have to manually start it at each boot? Even then being a portable app would mean it wasn't integrated in to your Windows thereby reducing the protection it would offer.

.NET wouldn't be such a big beast and instead be designed to be integrated into the application distribution (only the parts necessary for that app).

Resulting in bloated apps because instead of just having the gui components once on your system each app would have to come with them.

Another benefit is roaming. If all apps would reside in the users profile, then there is little left to do, to have entire portable user profiles, without the need for any magic.

This is why browsers now come with server side syncing same with certain messenger programs. If we used portable apps on our computers then we would have to copy the folder to our USB stick every time you left the PC just in case you ended up using a PC somewhere else.

[webfork]

.NET wouldn't be such a big beast and instead be designed to be integrated into the application distribution

Resulting in bloated apps because instead of just having the gui components once on your system each app would have to come with them.

Absolutely. The increased size of applications is the most damaging argument against what I'm suggesting: its inefficient and can slow down a computer as it reads more files from more directories to complete tasks. I've spent some time and effort to try to solve this by allocating libraries, but computers are fast enough that I don't seem to notice a dramatic speed increase.

Another benefit is roaming. If all apps would reside in the users profile, then there is little left to do, to have entire portable user profiles, without the need for any magic.

This is why browsers now come with server side syncing same with certain messenger programs. If we used portable apps on our computers then we would have to copy the folder to our USB stick every time you left the PC just in case you ended up using a PC somewhere else.

I actually prefer the "copy to a USB stick every time" method in most cases simply because I'm in control of my data. I've seen too many programs -- including a Google browser sync -- just come and go at the whim of the service operators.

I'm pretty sure you could get rid of some of it if you put your mind to it.

You can go through your toolbox and throw out a few things you never seem to use, but you're handicapping yourself if a situation comes up where you'll need it. Keeping track of applications and downloading them on an as-needed basis doesn't work if those applications or their names escape you, or the company that produces them decides to quit.

[SYSTEM]

.NET wouldn't be such a big beast and instead be designed to be integrated into the application distribution

Resulting in bloated apps because instead of just having the gui components once on your system each app would have to come with them.

Absolutely. The increased size of applications is the most damaging argument against what I'm suggesting: its inefficient and can slow down a computer as it reads more files from more directories to complete tasks. I've spent some time and effort to try to solve this by allocating libraries, but computers are fast enough that I don't seem to notice a dramatic speed increase.

I think lyx was talking about static linking (storing libraries within executables). Static linking actually increases performance a bit (there are less files to read) but increases usage of memory and disk space.

AFAIK, storing DLLs in a central location doesn't increase performance. There are two ways to speed up library loading:

• cache: Prefetch or Superfetch causes Windows to read libraries at the same time as the executable itself, even before the application attempts to load the libraries. The libraries are already in cache when the application loads them.
• defragment: reading any file is faster if the file is not fragmented

The effects are almost nonexistent on Flash-based drives, however.

Another benefit is roaming. If all apps would reside in the users profile, then there is little left to do, to have entire portable user profiles, without the need for any magic.

This is why browsers now come with server side syncing same with certain messenger programs. If we used portable apps on our computers then we would have to copy the folder to our USB stick every time you left the PC just in case you ended up using a PC somewhere else.

I actually prefer the "copy to a USB stick every time" method in most cases simply because I'm in control of my data. I've seen too many programs -- including a Google browser sync -- just come and go at the whim of the service operators.

What? I always run applications from my external hard drive even when I use my own computer (for example right now). I don't need to copy anything.

[m^(2)]

Resulting in bloated apps because instead of just having the gui components once on your system each app would have to come with them.

Absolutely. The increased size of applications is the most damaging argument against what I'm suggesting: its inefficient and can slow down a computer as it reads more files from more directories to complete tasks. I've spent some time and effort to try to solve this by allocating libraries, but computers are fast enough that I don't seem to notice a dramatic speed increase.

I think lyx was talking about static linking (storing libraries within executables). Static linking actually increases performance a bit (there are less files to read) but increases usage of memory and disk space.

AFAIK, storing DLLs in a central location doesn't increase performance. There are two ways to speed up library loading:

• cache: Prefetch or Superfetch causes Windows to read libraries at the same time as the executable itself, even before the application attempts to load the libraries. The libraries are already in cache when the application loads them.
• defragment: reading any file is faster if the file is not fragmented

There's one more thing. When you start a program and there's another that has the library loaded already, Windows doesn't read it from disk again.
And BTW it is the only reason why there's memory usage reduction that I'm aware of.
Another BTW, (UPX or so) compression breaks the mechanism.

[lyx]

And how would they do that unless they added themselves to a list somewhere?

Please do not make technical arguments, when do lack basic understanding about said technology. FYI, a basic concept in programming, when an object should interact with another one, is that there are a few possibilities how to do it: A can "call" B. B can "poll" A. A can leave a note in B's memory, and B then polls that memory. A can leave a note in its own memory, and then B polls that memory.

Even then being a portable app would mean it wasn't integrated in to your Windows thereby reducing the protection it would offer.

This is so screwed logic that i cannot even bother to reply. Hmm, i just have a deja vu - weren't you the same person that replied to my security model thread, with questions that showed that he did not understand what i was talking about? I see a pattern repeat here.

.NET wouldn't be such a big beast and instead be designed to be integrated into the application distribution (only the parts necessary for that app).

Resulting in bloated apps because instead of just having the gui components once on your system each app would have to come with them.

Once again, you do not know what you're talking about. The above is a myth. It's a calculation that sounds nice in theory and on some programmers OSes, but which in practice DOESNT ADD UP BY A MILE. In practice, the "savings" of this approach are usually eaten up by:

1) The buerocracy of said dinosaur (its own infrastructure gets bloated) because of so much glue-code and "managing management"

2) Version hell. Sooner or later, backwards compatibility needs to broken, but the apps installed on a machine will depend on different versions, so that the one-time-initial-cost actually multiplies, since you need to have the framework installed multiple times (one per major version).

3) The fact that most people do not have enough applications installed running on such a framework, to compensate the initiall cost. It only adds up when a VERY high percentage of applications use it. Framework developers like to imagine, that they are the only framework on the planet, and that everyone will love it so much, that everyone will write for that framework. In 98% of cases, that doesn't happen. It doesn't even happen for perhaps the most commonly used framework of all: DirectX in the end requires MORE memory, because of #2 - version hell.

Once again, here techfreaks argue against portability, in an i'll directed sense of conserving memory. Memory saving matters, but you're doing it wrong, sir! To do it "right", you cut costs where there are practical savings (not just imaginary theoretical ones), and you cut costs where the resulting disadvantages are minor.

Yes, i know, i basically just said that the linux architecture (regarding dependency hell) was made by morons. I fully stand by that. Linux made a few very interesting and nice choices in its evolution, but it also mostly was developed by, what in germany we call "Fachidioten". People who are the best at coming up with theories, and the worst at understanding practice.

Another benefit is roaming. If all apps would reside in the users profile, then there is little left to do, to have entire portable user profiles, without the need for any magic.

This is why browsers now come with server side syncing same with certain messenger programs. If we used portable apps on our computers then we would have to copy the folder to our USB stick every time you left the PC just in case you ended up using a PC somewhere else.

Again, you advocate the status quo, for the sake of keeping life miserable for everyone.

Your offer:
1) Sync everything manually by copying
2) Install one vendor-controlled sync-app for EVERY F*CKING APPLICATION IN YOUR PROFILE - and then let them do it automagically on start

I offer:
- F*ck this inefficient insanity. How about you just put a SINGLE filesynchronizing application on your usb-drive, immediatelly accessable upon launching it's desktop, and able to sync with just 2 mouseclicks?

[carbonize]

And how would they do that unless they added themselves to a list somewhere?

Please do not make technical arguments, when do lack basic understanding about said technology. FYI, a basic concept in programming, when an object should interact with another one, is that there are a few possibilities how to do it: A can "call" B. B can "poll" A. A can leave a note in B's memory, and B then polls that memory. A can leave a note in its own memory, and then B polls that memory.

Wrong. My argument is sound. How can the OS now what to load at start up without either having a list of files that it needs to start or for all the files it needs to start being stored in the same directory. Given we are talking portable apps that can be installed in ANY directory how would any program interact with any other program with out knowing where that program is?

Even then being a portable app would mean it wasn't integrated in to your Windows thereby reducing the protection it would offer.

This is so screwed logic that i cannot even bother to reply. Hmm, i just have a deja vu - weren't you the same person that replied to my security model thread, with questions that showed that he did not understand what i was talking about? I see a pattern repeat here.

The only repeat pattern I see is you basically calling anyone who disagrees with you an idiot.

.NET wouldn't be such a big beast and instead be designed to be integrated into the application distribution (only the parts necessary for that app).

Resulting in bloated apps because instead of just having the gui components once on your system each app would have to come with them.

Once again, you do not know what you're talking about. The above is a myth. It's a calculation that sounds nice in theory and on some programmers OSes, but which in practice DOESNT ADD UP BY A MILE.

SO that's both webfork and I that are idiots according to you.

Another benefit is roaming. If all apps would reside in the users profile, then there is little left to do, to have entire portable user profiles, without the need for any magic.

This is why browsers now come with server side syncing same with certain messenger programs. If we used portable apps on our computers then we would have to copy the folder to our USB stick every time you left the PC just in case you ended up using a PC somewhere else.

Again, you advocate the status quo, for the sake of keeping life miserable for everyone.

Your offer:
1) Sync everything manually by copying
2) Install one vendor-controlled sync-app for EVERY F*CKING APPLICATION IN YOUR PROFILE - and then let them do it automagically on start

I offer:
- F*ck this inefficient insanity. How about you just put a SINGLE filesynchronizing application on your usb-drive, immediatelly accessable upon launching it's desktop, and able to sync with just 2 mouseclicks?[/quote]
1 - Where did I mention using a single vendor controlled app for syncing everything?
2 - How about not having to leave your USB stick plugged in to your PC 24/7


In the end most people just use the one PC and that has all their apps and profile data on it so have no need for portability. It is only the few who feel the need to carry a bunch of software around with them. I personally store my required portable apps online so I can access them from anywhere and I sync my local profiles with them about once a month or more often if I know I will be using them that day or week.

[lyx]

Wrong. My argument is sound. How can the OS now what to load at start up without either having a list of files that it needs to start or for all the files it needs to start being stored in the same directory. Given we are talking portable apps that can be installed in ANY directory how would any program interact with any other program with out knowing where that program is?

Okay, autostarting indeed is a different matter, but not for technical reasons, but instead because it should be specific to the host-OS, not to the application. IMO, apps that actually need autostarting privileges should not reside on a portable media, but instead be on the host-PC and marked to run automatically.

Notice that this does not require an application to be non-portable. The app can be portable, it just needs to contain a file that details which of its files should be autostarted, with that file only being read, if one copies the application to an autostart-directory of the OS (the app can of course provide an option, to copy itself there, so that the user doesnt need to copy it manually)

That way, one and the same application can be run manually, or automatically, and managing the list of autostarting applications would be as simple as looking at a single directory.

P.S.: Thinking about it, one may actually need two autostart directories. One that is specific to the host machine. And then another one inside the user's profile. The first would be for applications which's autostart behaviour is machine specific, and not affected by the user. The second would provide a *portable* way to autostart applilcations depending on which user profile is currently active (which may be stored on an usb-drive).

[carbonize]

One other issue that does arise from using only portable applications would be that of file association. Without a central source saying which program is used to open which file type we would have to run each program and then use it to open the file. Only fix I could think of would be a portable program that creates a drop target and opens whatever program you have assigned when a certain file extension is dropped on it. I'm actually pretty sure such a program does exist but it does add an extra layer of complexity.