[Dead Project] Adobe Flash Player Portable Beta 7

You should not have deleted the previous Topic.
All the history and comments have now been lost.
In the future just start a new Topic.

Tim

You can not repackage and redistribute Firefox without permission from Mozilla. Our permission to repackage it in Mozilla Firefox, Portable Edition does not extend to 3rd parties.

I have a topic in the Firefox Support forum for finding Addons that aren't portable. (Found here)

Now, as of now, for Flash, I am linking here. But, not only is this a little indirect, but the version linked to, made by John T. Haller himself, will leave "Local Shared Objects" behind, due to it just being a "functional test release".

If this version is fully portable, I'll start linking here instead, but I'm a little reluctant, considering PA already has a help section dedicated to this exact problem. But, if yours fixes that known problem, I'll link here instead.

Hi. So I've tried the beta4, and I have to say, I wasn't impressed. But it's nothing that can't be easily fixed

First, let me congratulate you for an effort to make something useful. I endorse the future development of this project, and possible incorporation of it's features in the official FirefoxPortable.

Now that that is out of the way, I can start criticizing

.
1) You use absolute paths (this one deserves a few numbers, not just one, but I'm being good here )
2) bat2exe conversion
3) doesn't work!

Ok. So, I've tried it inside Sandboxie, as I suggest everybody should when developing and/or beta-testing any software. Installation went good. No problems there. But it doesn't work (and can't) on any other computer except your own! Explanation? Here goes...

.
1) Absolute paths. The way Microsoft wants their average Win user to think, inside a very small box... Go relative! BAT files are extremely useful in automating ones everyday, repeated tasks. As such, they are invaluable to anyone who likes to run things portably, and keep their data with them. But, even though MS "officially" endorses only the use of absolute paths, and relative ones "should be avoided as much as possible", they are a necessity for portable uses.
Note: I know it's bad thing not to back up ones claims, but I can't seem to find a Google page linking to MS saying that, but I remember that they did, and the main reason was because if you move a BAT file with relative paths to any other folder, it will cease to work; that is only true for a local system calls, and only to some extent!

In your "exes", your paths are pointed as

C:\Documents and Settings\pcpl\Application Data\Macromedia

wrong because this assumes that Windows is installed to C: drive, (b) assumes that it is Win XP or older due to "Documents and Settings", and (c) worst of all, it is only limited to a user named "pcpl"!
You should avoid such limitations simply by using

"%APPDATA%\Macromedia"

, as that takes you right to the necessary locations ON ALL WINDOWS MACHINES! Note the use of " at the begining and the end. This is necessary in case a system is XP or older, and might be necessary for Vista and Win7, as it takes care of eventual spaces in the path.

As I'm a little lazy to write more about these paths, here is a link about the environment variables on Wikipedia. It will help your computing skills a lot to learn some of them

.
2) bat2exe conversion. Again, a big NO-NO. This can only result in trouble for users, and not being of any practical help and use. The main thing is to understand how a bat2exe actually works. It takes your BAT file, puts it inside an "outer" executable (to which you may "give" an icon for better looks), and kinda encrypts your BAT file. That makes many AV programs recognize such "executables" as viruses! False positives? Yes. Do people around and AV program know it? No, and they probably won't even wanna listen. Especially a problem if a user doesn't have the rights to add an exception in the AV program. Ok. Now, remember that "outer executable" in which your BAT file is stored? If it passes the AV control, the only thing it does is COPY the BAT file to system's %TEMP% directory and run it from there! (of course, adding %1 at the end so it would affect the directory where that "exe" is stored). When the BAT executes, that "executable" you made removes it (most of the time) from %TEMP%, and most users don't even realize it.

So, you are possibly sacrificing a lot just by trying to make it look good (i.e: adding that icon), and "the executable" even works slightly slower due to having to be extracted to %TEMP% first... but you can't notice the difference (much) in the speed aspect...

.
3) Doesn't work. Well, this is due to above mentioned... But it can easily be fixed I hope you follow the suggestions, and improve it, as it will be a great addition to FFP! So, even the local LSOs can be unaffected by the portability of FFP!

Cheers

[EDIT]: The "Doesn't work" is about it not being able to do what it is advertised to do. Otherwise, it works just as a regular FFP, only a little bit slower at the start, and asks for a user intervention ("press any key to continue").

Change line 446 from:
StrCmp $R0 "0" "SomeWeirdLoop" "NextAction"
to:
StrCmp $R0 "0" SomeWeirdLoop NextAction

Putting quotes shouldn't be needed, as labels can't have spaces anyway.
As far as I know, it shouldn't affect the script anyway (i've search through the source code to NSIS), but just to be on the safe side.

There is also no need to change the .bat file to exe's. It just adds to the size. Besides, if the original .bat files aren't provided (no worries there, as they are there), all a user has to do is un-upx the exe and use a hex editor to retrieve the batch script.