Development Outline

I. Brainstorm

The first thing is having an idea to implement. A lot can go into just what to consider with creating a stand-alone portable application. What would be good software to be made portable? You might think about how much use an application may be before bothering with it. Or how much interest there will be from the end-user who will be using them; unless of course you're just making it for yourself in which case go nuts. Another thing to look into would be if your software already has its own PAF counterpart. If so, just use that one. We're not trying to reinvent the wheel here. Although, you might find the developer of that PAF just did a piss-poor job. In that case, rewrite their code with whatever you deem it needs and just remember to cite the original developer for his contribution or work. Oh and you might want to let them know about it too as a professional courtesy.^?From one programmer to another, it is considered proper etiquette to give someone credit for their work as well as to assist in the development of said source code by contributing to its betterment.

II. Licensing

All software is licensed, in some way, no matter what, regardless. There is the standard commercial licenses like you'll see with Microsoft's software or with Adobe's Creative Suite. There's also the open source licenses with which you'll find in Mozilla's software or in the OpenOffice.org applications. Commercial licenses, as a rule-of-thumb, doesn't permit an end-user in any fashion the ability to alter their respective application or even redistribute it for that matter. Free software with a commercial license, however, does permit you to redistribute an application, but not to modify it like with Internet Explorer and Opera.

Now with open source licensing there's a lot more leniency in this aspect for it allows you to both freely modify an application and redistribute with your new and/or improved version. So in regards to PortableApps.com and their moral-compass, this is the only way to go when making software portable. Which is fine and understandably so and is as it should be for they are a public service. A free, open source llcThis is an acronym for Limited Liability Company. (I.E. Rare Ideas LLC— which is the parent company of PortableApps.com) at that and for all legality purposes should not partake in any sort of high-profile, pirating-Ponzi scandal or whatever the media/judicial system would make of it. However, the software that you pay for should arguably be yours to do with what you will. So in the confines for your own 127.0.0.1your local domain; home., port and let portable!

III. The Analysis

To start the implementation of your PAF would be to study your software thoroughly. I mean, really get to know any and all ins-and-outs of the inner workings of the application. What makes it tick and what allows it to tock, you know? Look at it's clockworkThis is just my way of saying look at the source code. I.E., like taking a look under the hood of a car to see what makes it run.. so on and so forth. if you can. All this rigmarole to determine what needs to be altered, managed, and maintained to make this program portable. For instance, does said program store its settings in the registry or with an XML or INI file or even more convoluted, both along with the registry? Does it communicate with folders like %DOCUMENTS% or %PUBLIC% or even %SYSDIR% in some cases. Does it make use of a database like SQlite to store it's configuration like with AIMP Portable?

Another good habit you should get into is visiting the software developer's website and it's documentation before you release your PAF. I say this for the simple fact that it can have invaluable little gifts for your PAFs end result. Like finding little Easter eggs in forum posts or running across a bit of information in which will set your version apart and give it that little "je ne sais quoiIt's French for, "A quality which can't adequately be described otherwise."". For instance, with my version of RegOrganizerPortable you'll notice in the root directory it holds two portable executables. In my research I found a topic in which the developer disclosed a command-line switch to enable a user to just launch the Registry Editor instead of launching the main program. Thus, I was able to incorporate this switch to my PAF. Hence RegistryEditorPortable.exe as well as RegOrganizerPortable.exe for the end-user's convenience and preference. I'd have never ran across this tidbit of information if I wasn't dedicated to a PAFs completeness in it's entirety.

IV. The Code

After getting a real good idea of the programs functionality. You'll want to set up your environment/workspace; you're workbench or a manual-labourer's tool-belt or whatnot. You still following me? If not, no worries my ever-so-vigilant, little friend. I wasn't either for the last 15 minutes or so. Heh. Moving on.. Next, you'll want to set up the proper configuration settings the launcher will be using to make the application's ability to run without dependencies.

Now here's where we can get a bit overwhelmed with using FGs builds. You'll find to make something work with his launcher, you have to edit the PortableApps.comLauncher.nsi file directly, unlike in the official builds of PAL, it's not discussed or mentioned even. Same thing if using FG's build of the installer. That being said, it's to be noted that you cannot reuse that edited PortableApps.comLauncher.nsi and/or PortableApps.comInstaller.nsi file with any other program; each program will call for different !defines or so on. You'll see later on in more detail what I'm referring to but for now just know that each PAF made with FG's Launcher is more involved than it's official predecessors.

V. Compression

One of the things that you should be aware of is the size of your PAF. Portable applications should be relatively small in nature considering it'll consume less space on the portable device and launch more quickly as a result. Most, not all, but most EXEs and DLLs can be compressed using upxAn executable packer for several executable formats. Visit their GitHub project for more.. Most applications will compress fine. Some, occasionally, will have issues. Many Java based programs use JARs, which are actually just ZIP files with a different extension. Using an application like 7-zip to re-compress these to their maximum level can save even more space.

VI. Hosting

If you're sharing you PAFs with the public you'll need to house your releases somewhere for the end-user to download them. What I use is file hosting services which provide you with free space for holding and sharing files with people. I tend to use services that don't make the user do surveys or shove a lot of advertisements at a person. It would be a good idea for you to have cloud storage to keep your releases safe just in case the download links are deleted or broken. This way you may upload the PAF again and update the download link.

Another option would be to use peer-to-peer file sharing like BitTorrent. However this would require you to have a dedicated system which has continuous access to the internet. If you're hardcore enough you could set up your own Torrent Server with one of your old dinosaur computers. You know the one that helped you through college and you were too reluctant to throw away because you've had many good times in kilobytes on it.. It might not be able to run any bleeding edge OS, but you can use it as a centralised file server to download and share files on your network and the web.

VII. Testing

You'll want to thoroughly test your PAF for any possible scenario so that you can fix and work out all the bugs and have a solution before there's a problem for the end-user. A good way to do this would be having a virtual machine with a clean install of Windows XP all the way to Windows 10 or whatever is current right now. I test on Windows XP, Windows 8.1, and Windows 10.