Why don't (most) windows software developers make portable apps/games?

Hardware and technical stuff
1

I’ve always wondered about this but was too embarrassed to ask for fear of looking ignorant, but I now don’t see any reason apps or games can’t be released as portable folders with a nice autorun.inf icon.

The advantages are obvious.

This is especially significant for games, since I don’t see the point of having game preferences stored in the registry, it’s not like a game is novell netware with numerous clients logging into a server…

Is it a form of crude DRM? Or maybe a way to avoid viruses corrupting user settings if they’re stored in the app’s folder?
Both don’t make sense since viruses attack the registry as well and with google, bypassing drm is trivial.

2

You have to install the game to have a link in the menu or on the desktop. You sometimes have to register COM objects to interact with system services. It also is nice to have separate savegames for different users on the same machine. So just dropping the exe and resources into a folder is not going to work.

3

you can do all the above and still keep the app portable.

EDIT: If my comment needs clarification:-
links can be generated on first launch via a message prompt.
registering a dll can also be done on first launch, a simple check to validate that a custom class or object exists can be done to make sure that the referenced COM objects/libraries exist in the client system
separate savegames can be stored in a common location as usual e.g. my documents/my games

4

I love portable apps, myself, but I don’t see them becoming the norm.

For the sake of argument: Wouldn’t writing saves to the standard OS data folders make the app decidedly non-portable? If you can’t take the save games with you, then what “obvious” advantages are you gaining by having the app portable? (I can think of some, but I would rather hear your perspective.)

Anywhoo, here are some reasons I can think of why portable is not the standard…

[ul]
[li]Portable apps are not necessarily easy for a non-technical user to install. No, it’s not that hard, but my time spent working in tech support has taught me that if there is something a user CAN do wrong, then ultimately, someone will do it wrong.[/li][li](Perhaps related…) Typically, portable apps write configuration data to the same folder that the actual program is in (or a subfolder). Starting with Windows Vista, programs are (by default) prohibited from writing data to the “Program Files” folder tree (for security/virus protection reasons, IIRC). That means that the user will need to put the portable app folder somewhere other than “Program Files”. Or, the portable app would have to write save data to a common place (hello, registry or AppData), making the whole thing a bit less portable.[/li][li]The whole ‘install components on first launch’ idea assumes that the user has permissions to install stuff. This may not be true.[/li][li]Why make it portable when you can make it in the cloud?[/li][/ul]

5

Wade basically covered all of it.

Portable apps open up all sorts of gaping security holes because it requires a user’s account to be wide-open to allowing applications to access areas of the system they’re not supposed to access. The main reason why UAC was originally such a pain in the ass was because developers created applications in ways that went directly against Microsoft’s recommendations, such as using Program Files to store user data instead of the User folders that were intended for that purpose.

6

I can confirm sloppy applications writing to the C drive tend to be the norm and not the exception.

Just this week, trying to run a Lynda.com training video course for Adobe software at work causes an error “cannot create folder in My Documents.” It’s a DVD-ROM with a Flash Player executable that runs QuickTime movies. The executable build date is 2008.

The PC is on an Active Directory based network with user data on network drives, including My Documents mapping.

Their fix? “Move your my documents folder back to C: or create the folder structure.” This is joke.

7

With the caveat that I am not a software developer…

I love portable apps, myself, but I don’t see them becoming the norm.

I do see them becoming the norm. We are using a wider variety of devices and operating systems than ever before and the trend is not slowing down. Developers looking to capitalise on broader target audiences are increasingly coding with multi-platform in mind, meaning by their very nature the apps are less tied heavily into the OS (registry settings, strict install paths, etc).

Portable apps are not necessarily easy for a non-technical user to install…

They are easier. Download an app and hit the executable. Bang, there’s your program. None of this “Where would you like to install…”, “Which components would you like?”, “Would you like a desktop icon?”, “Can I install the Ask toolbar?” crap that goes on with legacy installers. This is also what we are training new users to do with the rise of the various app stores - download an app, click on an icon, it just works.

(Perhaps related…) Typically, portable apps write configuration data to the same folder that the actual program is in (or a subfolder). Starting with Windows Vista, programs are (by default) prohibited from writing data to the “Program Files” folder tree (for security/virus protection reasons, IIRC). That means that the user will need to put the portable app folder somewhere other than “Program Files”. Or, the portable app would have to write save data to a common place (hello, registry or AppData), making the whole thing a bit less portable.

The whole ‘install components on first launch’ idea assumes that the user has permissions to install stuff. This may not be true.

Wouldn’t writing saves to the standard OS data folders make the app decidedly non-portable?

If you are downloading a portable app into your “Program Files” folder, you’re kind of doing it wrong. The average Joe Schmo user downloads everything to their “Downloads” folder, “My Documents” or the “Desktop” - all locations on Windows which the user has pretty free read/write access. Me, I have a bunch of common portable apps in my dropbox folder (which is typically on my Desktop). They follow me everywhere I go and work regardless of the machine I am on.

Also, if the portable app is storing config data in System locations, to my mind the app developer is doing it wrong and they are not really providing a portable app. Quite a few actually provide the option on first launch.

Why make it portable when you can make it in the cloud?

Absolutely, though it depends what the app is trying to achieve. Some apps aren’t good candidates for cloud service (Photoshop or Video Editing) just as some apps are not good candidates for being made portable (MS Office Suite).

Portable apps open up all sorts of gaping security holes because it requires a user’s account to be wide-open to allowing applications to access areas of the system they’re not supposed to access.

This I am not so convinced on. Sure I can download a portable app to my work desktop and run it no problems, but if that app is trying to do anything that requires elevated privileges (accessing system files, low level kernel processes or system drivers), it still won’t work unless I have the necessary admin rights, which is no different from a native install. It’s no more or less secure as it operates under the same security constraints. I’ll admit that modern OS’s are better at managing this. There are also lots of apps that you cannot install to “Program Files” if you don’t have admin rights, but will happily install to the desktop. Unless the plan is to not allow a user to run any executables at all, I am not convinced the security challenges are really all that different.

Now I say all that as user that prefers portable apps. If there is a portable version available, I’d much rather use it than the installer version. I’ve also noticed over the last year or so, many of the popular open source or freeware projects are now making portable versions available, or portable versions can found very easily - CPU-Z, Xnview, Q10, ADOM, DF, Gimp, 7-Zip, FileZilla, Blender, Audacity to name just a few.

8

But the norm is approaching a point where the way most people will use apps is to go to the official OS store/marketplace/whatever, click on what they want, some stuff happens in the background, and the app runs. The case where they download SomeApp.exe to an arbitrary location and run it from there will likely become less common, and certification requirements and best practice recommendations from the OS itself will make it even more difficult.

9

Because Windows programmers don’t have a culture of write portable software.

Microsoft itself have a strategy of breaking compatibility with other systems, so the people using Microsoft software are trapped in it, and can’t move to other products or companies.

It work both ways,… windows dev’s don’t know how to do it, and Microsoft make it harder on purpose. Writing portable code is not hard but is not trivial, you have to learn what to do and how to do it, and what assumptions to not make. Similar to 32 bits vs 64 bits.

Code that is portable (runs everywhere and compiles everywhere) odds are that are better programmed that code that only compile in Visual C++ 6 in a Windows XP service pack 2 and only runs on Windows XP service pack 2.

“Self-contained” programas that can run on a single folder are a different issue, but related. Again, odds are that a app that runs everywhere, also can run by just copying around a folder. But is a side effect of good portability culture. Sometimes a program may written in a particular way that is a good idea but completelly break the idea of “self-contained” program. Breaking “self-contained”-ibility I don’t think is a indication of bad code. You could just follow the “best practices” adviced by the creator of the OS (Microsoft) and the result is not portable softare and not self-contained. But you are still following the best practices proviced by the OS maker. Here the odds are against you, the perversion is on choosing Windows, so you can’t win.

“Self-contained exe apps”. Windows (NT) has ben built for a strange reason very dependant on the NTFS filesystem… this is just anecdotical but hilarious, the idea of having a OS so fixated in a filesystem is stupid. Like having a car that only runs on a particular brand of tires. Ridiculous. Anyway a particular problem with NTFS and how Windows work, is that a opened file is locked, can’t be reoponed using standard C library functions. If you try to fopen ARGV[0] it fails, a program can’t open itself. You must use some alternate API functions that are “windows-only” to make so a exe open itself. This is important because a practical way to build self-portable software, is to build a EXE file that include in itself all data it needs embeded. Windows / NTFS / Microsoft make this unnecesary complex for bad design decisions. Its like some important Windows architecture decisions where taken by a random dice generator, or looking at how other OS work, and doing different for the sake or doing different.

10

quite the opposite since game saves are not “program asset files” (in the sense that these files are not critical for the app to run) but are user generated content in a way. Keeping game saves in a common folder allows users the chance to easily locate and backup these files.

that’s true, but a programmer can write an application in the same way a cracker writes a trojan: everything is automated. So simply clicking the app folder can lead to the following:

  1. install .sdb file into system to disable UAC for app
  2. install dlls and register them on system
  3. run app
    another example of automated actions:
    Dragging the folder to the desktop creates a shortcut to the exe automatically

some apps don’t make sense in the cloud e.g: OS tweaks, system utilities, media players, games etc.

I’m talking about self-contained mind you, not code portable.

Personally I feel that talking about security and such does not make sense, since Mac OSX apps have been deployed as a folder with an icon for 12 years now.

11

It also is nice to have separate savegames for different users on the same machine. So just dropping the exe and resources into a folder is not going to work.

I’m probably being dim here, but why is this a remotely challenging issue? Just allow multiple savegames, and allow users to name them, and it doesn’t matter where they’re stored.

12

Self-contained have system wide effects on how is supported on the OS level.

Suppose two apps, one Taxes.exe uses collage.dll, and other Evil.exe uses collage.dll. If you are the designer of the OS, theres different things you can do. You could try to load collage.dll only once. So you save memory. Memory on the processor (L1) cache means pure delicious speed, too. Having less stuff in memory, means less “page miss”, so having to load less things from slower places. So using less memory means the whole OS can be faster.
But you can’t quite do that, if Taxes.exe and Evil.exe are self-contained. If Evil.exe comes with collage.dll, and you load in memory collage.dll, maybe it will be a bad idea to use collage.dll with Taxes.exe, because maybe Evil.exe version of collage.dll is hacked to leak information to a remote server.

What a self-contained app do to your system, is to have a waste of resources. You have to link everything to his copy, so you can have multiple collage.dll files loaded in memory. Wasting memory.

Ideally, you want programs to be stripped of as much libraries as possible, and have all the libraries already on the OS, and shared with other programs.

If a self-contained app loads, and have 200MB of dlls, the system have to load 200MB from the disc. If these files where shared, the OS could just load the ones that are not already in memory. So the self-contained OS will load very slow, and will waste a lot of memory.

None of this is a concern to a user that really want that for some motive (like a dude with firefox in a USB). But systemwide, you want the system to be as fast as possible, smooth and agile. Building the whole thing in the slowest and most resources wasting way, would be a bad idea.

I don’t know how Mac do it. Maybe is a facade and in a Mac “disc” theres a lot of linking, and “self-contained” thing is achieved “cheating” with clever tricks. Or Mac just waste resources that way. I don’t know.

13

I have a lot of old GOG games on a stick now, they will happily play from their folder and are self-contained. It’s actually brilliant to be able to play them on any computer.

14

Microsoft decided to stick your saves in mydocs rather than a subdirectory of the games folder. This creates all kinds of problems if you install in /program files/ of any sort.
Then there’s the various places they want you to stick config data, and…

Oh and of course they save stuff by user not by…

15

This is probably the right way to do it. Data in one place, executables in other place. Have the logued user write in the data place (his data place) and have to need a superuser to write in the executables place.

For a selfcontained app, the way to do this, is to have a “Programs files” in the Home folder. So you can install the selfcontained app in the data area. That way it will be possible to store the savegames and executables in the same area.

To do this well, a way to do it, would be to have a enviromental variable, or something that work like that, that point to the savegame area. Normally it will be "c:\program data\applications\app data", but could be temporally changed to "c:\home\John\bin\mygame\saves"

Then launch the selfcontained launcher with something like this :

----- launch.bat ----
rem change the storage place only for this process to my personal home bin folder
set app_data_storage="c:\home\John\bin\mygame\saves"
c:\home\John\bin\mygame\my_selfcontained_app.exe

Doing something like this would allow the OS designer to separate data and executables, that is a good thing, and for some users to have selfcontained apps, that is a good thing again. I don’t know if Windows allows something like this, probably yes.

16

My “program data” directory is 2GB and has stuff in there for things I got rid of a year ago. And yet some apps will be need setting up from scratch unless I back up the right files there. Users? 4GB, and I need both me AND the general one. Trying to hunt through the 7k folders trying to find…