You are here

Packaging applications specifically built to be Portable already

14 posts / 0 new
Last post
adamk
adamk's picture
Offline
Last seen: 12 years 5 months ago
Joined: 2008-06-10 23:21
Packaging applications specifically built to be Portable already

Hi there

I'm responsible for the creation of the Strawberry Perl distribution ( http://strawberryperl.com/ ) and for three months during 2008 I was funded by the Perl Foundation to natively implement Portability into Perl.

I'm happy to report that (a few beta bugs notwithstanding) it was a complete success. But now I've got a bit of a problem when it comes to doing the portableapps.com packaging...

We have deep support in the Perl binary now and the CPAN client, and even the regular File::HomeDir->my_document style APIs natively report portableapps.com-compatible paths when they detect they are running in a portable context.

We even have a beta of a zip-packaged Portable Perl distribution being automatically spat out of the distribution build scripts (http://strawberryperl.com/download/strawberry-perl-5.10.0.3-portable-bet...).

My problem now, unusually, is how the hell do I build the ACTUAL portableapps.com package out of the .zip file directly?

This is a slightly unusual build (compared to what seems to be the normal process) in that I just need 100% of all the existing files, unmodified, with no registry hacks or changes of any kind, and I can't find any obvious documentation on taking this direct unmodified path to an installer.

Everything I can find to read seems to be based around converting existing non-Portable applications over into Portable form...

Got any pointers or URLs on how to go from .zip to NSI installer direct?

BuddhaChu
BuddhaChu's picture
Offline
Last seen: 6 years 3 months ago
Joined: 2006-11-18 10:26
Welcome Adam. You've come to

Welcome Adam. You've come to the right place. Wink

To answer your question, you need to extract the zip file and put it's contents in the \Data subdirectiory. That or you'd need to find a way to extract the contents of the zip file somewhere, run your code, compile, whatever (do the user's PERL stuff), and the then clean it all up at the end.

Strawberry PERL differs for other apps in that it doesn't have a main executable (or does it?). In the root directory of a portable app is an executable that launches the main exe and does all the setup/cleanup/storing of settings need to make it portable.

Look in the \Other\Source subdir of one of the new official portable apps and you'll see the latest launcher & installer (the latest VirtualDub just came out so try that one).

https://portableapps.com/development

If your question is, "Where do I start?"...start by decompiling one of the simpler apps' installer and launcher and coding your own stuff in their to make your own.

Hopefully someone with a little better clue comes along and answers your question too. Good luck!

Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!

adamk
adamk's picture
Offline
Last seen: 12 years 5 months ago
Joined: 2008-06-10 23:21
There is no primary program, correct

Correct, it doesn't have a "main executable" as such.

Perl (it's not an acronym) is a language platform, in the same sense as Java or .NET doesn't have a "main executable".

The packaging process is really a test for me at this point. The distribution generator has the ability to "portablise" any variant that it builds, so once I work out how to automate the zip -> PA Installer process, what I'll probably do is move to bundling a Perl/CPAN-installed IDE on top of the base install.

http://padre.perlide.org/wiki/Screenshots

So at that point, you would end up with a "main executable" that would serve as a suitable point for a production release.

adamk
adamk's picture
Offline
Last seen: 12 years 5 months ago
Joined: 2008-06-10 23:21
Should it go into Common Files?

I've also noticed in that URL you mention that there is discussion of using a common run-time Perl in a Common Files directory, should I be investigating doing that?

BuddhaChu
BuddhaChu's picture
Offline
Last seen: 6 years 3 months ago
Joined: 2006-11-18 10:26
The \CommonFiles directory is

The \CommonFiles directory is going to be where common libraries of files will go so we don't have multiple copies of libraries needed to run programs (at least that's my perception). For example, OpenOfficePortable needs the Java libraries to run it's built-in Wizards. The launcher redirects the calls to java.exe to the CommonFiles directory so it doesn't matter if the user has the Java runtime installed or not. If someone made another Java-based app portable, they should point it to \CommonFiles directory in their launcher to use the JRE installed there as well.

As far as you putting your files there, John Haller will have to comment on that so I don't give you wrong info and then you waste work/time on a dead end.

Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!

Ryan McCue
Ryan McCue's picture
Offline
Last seen: 13 years 4 months ago
Joined: 2006-01-06 21:27
Revisiting.

I thought I'd revisit this for you and take a look at what you want to do.

Correct me if I'm wrong, but Strawberry Perl is more than just a Perl interpreter, isn't it?

So, here's what you need to do:

  1. Put as many executables as you would like to show in the menu in the root directory (StrawberryPerlPortable, I assume), but don't include any other application files in this directory. Put them instead in a subfolder of App (such as App\StrawberryPerl).
  2. Create an AppInfo subdirectory of App, and put an appinfo.ini and appicon.ico in there, as per the current specification (available from the development forums)
  3. Make sure that your executable stores user data *only* in Data\ and nowhere else. Assume that this is the only directory that users will backup (because it is).
  4. Create Other\Source, and put your license and a readme informing users where to get your source into this directory
  5. Grab a copy of the PortableAppsInstaller.nsi and PortableAppsInstallerConfig.nsh and stick those both into Other\Source
  6. Edit PortableAppsInstallerConfig.nsh to your liking.
  7. Compile PortableAppsInstaller.nsi with NSIS, and this will compile your entire StrawberryPerlPortable\ directory into a PortableApps.com Platform installer.

If you've got any questions, feel free to ask.

"If you're not part of the solution, you're part of the precipitate."

adamk
adamk's picture
Offline
Last seen: 12 years 5 months ago
Joined: 2008-06-10 23:21
Resolving this with the Portable implementation

There's a couple of minor issues with your suggestions.

The main one is that the way the whole native portability bootstraps.

The perl.exe will resolve it's own location in absolute terms. It will then localize it's internal (default) library search path. So moving Perl itself around isn't an option.

Once bootstrapped to this point, there's hooks in three or four modules that are essentially universal dependencies for anything filesystem related.

When these module are loaded, they start from the Perl binary location and search upwards to locate a file called portable.perl, which is known to sit in the root path of the installation. Portable.pm is loaded to read and process the contents of this file, which consists of a set of named relative paths that override certain in-memory locations for the duration of the current executable invocation.

So within the Portable tree, I need to establish a distribution root.

I assume this means the dist root is going to be App\StrawberryPerl, which means we end up with App\StrawberryPerl\perl\bin\perl.exe as the location of the actual compiler/interpreter. A typical language install has dozens of binary things anyway, so I'm assuming we DON'T want those visible.

The Data\ thing should be fine, as the File::HomeDir module is also Portable-aware and will obey whatever portable.perl tells it is the relative path to the user data directory File::HomeDir->my_data.

Other\Source looks fine

That leaves the root directory. I assume I'll have to do something like creating a specific batch script for each thing I want to be specifically runnable, which will then point into the dist root.

I guess that also likely means that I need to find a bat2exe converter and hack in icon support etc manually? Or is there a better way?

m2
Offline
Last seen: 11 years 11 months ago
Joined: 2006-12-12 12:00
There are few things worse

There are few things worse than Bat2Exe converters when it comes to portable use because they all have one bug - don't support paths relative to the executable.
Normally one would use %0 in batch to refer to the script or it's surroundings, but such converters spawn the to temp, so %0 gets irrelevant.
You can still use paths relative to the current directory, but it's a bad idea for general purpose programs and very bad for a scripting engine.

"Those people who think they know everything are a great annoyance to those of us who do." Asimov

adamk
adamk's picture
Offline
Last seen: 12 years 5 months ago
Joined: 2008-06-10 23:21
Is that a reason not to use it?

Surely that just means we need to find one without the bug? Or file bug reports against them until they fix it.

m2
Offline
Last seen: 11 years 11 months ago
Joined: 2006-12-12 12:00
The bug is unfixable unless

The bug is unfixable unless you make a full blown compiler or interpreter. There was one. But generated 16 bit code.

The current "compilers" just wrap the script to an exectutable stub and at runtime unpack it to temp and call the command line interpreter.

Choose another language. Any that can be compiled or "compiled" I know except for MS batch, Java, C#, *.NET (*1) should be ok.

Ad. (*1): There is a compiler for .NET, but not free.

"Those people who think they know everything are a great annoyance to those of us who do." Asimov

OliverK
OliverK's picture
Offline
Last seen: 1 year 7 months ago
Developer
Joined: 2007-03-27 15:21
What does you bat script do?

What does you bat script do? I'd be willing to try generating NSIS code for you.
Then you won't have to hack anything.

Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world

adamk
adamk's picture
Offline
Last seen: 12 years 5 months ago
Joined: 2008-06-10 23:21
I should note that I'm not using %0

I should note that we don't actually use %0 in the batch scripts, instead we're using %~dp0.

I've been experimenting with Bat_To_Exe_Converter.exe from http://www.f2ko.de/English/b2e/ and it seems to work just fine when combined with %~dp0.

m2
Offline
Last seen: 11 years 11 months ago
Joined: 2006-12-12 12:00
Yes, sure %~dp0 is just a

Yes, sure %~dp0 is just a variant of %0 Wink

I tried this converter now:
echo %~dp0
pause

Saved as c:\e.bat
Result:
// Long wait
C:\DOCUME~1\M\LOCALS~1\TEMP\A.tmp\

So I don't see how can it be fine for you.

"Those people who think they know everything are a great annoyance to those of us who do." Asimov

adamk
adamk's picture
Offline
Last seen: 12 years 5 months ago
Joined: 2008-06-10 23:21
I'll see what I can do with that...

Thanks for the sample, I'll make up some test cases to trap this stuff and see if I can work out why it's working for me.

Log in or register to post comments