You are here

StartPortableApps.nsi for testing environment

5 posts / 0 new
Last post
rab040ma
Offline
Last seen: 4 months 3 weeks ago
Joined: 2007-08-27 13:35
StartPortableApps.nsi for testing environment

I have been experimenting with some things, using StartPortableApps. So far I've found them useful, so I figured I'd post them here in case they might be useful to others. I'm posting them as .nsi source rather than an executable, because I don't want anyone mistaking this for a production or reliable version. Someone with NSIS installed can probably get this compiled in a couple of minutes (you'll need an icon file -- any will do -- or comment that line out).

It was estimated in another topic that StartPortableApps was just a five line script. I found one more line needed (the RequestExecutionLevel line for Vista). Then I added a few other things, including comments.

The environment variable changes are part my preference and part so I can more easily see what other tested apps are doing. Note that these changes are inherited by programs started by the PAM, but don't make any lasting changes on the host computer. One result is that temporary files are isolated in one place; I understand John will do something like this in a future version. If this were production usage, one could use a file wiper easily on any leftover files in that temp directory. Or one could force the temp directory (by changing this program a bit) to be on the portable drive.

The most useful thing I've tried is using the Sysinternals "psexec.exe -l" program to run things with limited privileges (the lines are commented out below, but easy to put back). I started using psexec with the -l option in a lot of my regular shortcuts as a way to improve security; it removes all administrative tokens and specifically denies the Administrators group, so what you are left with is what privileges your regular user account has, including file permissions. I'm not suggesting this for John's release, just saying that I find it useful for my own testing and such. Note that the limited privileges are inherited -- if PAM is started with limited privileges, then if it starts FireFox Portable, FireFox will also have limited privileges, as will anything Firefox starts (e.g. Acrobat).

For example, if I am testing a program launched with "psexec -l" I'll get immediate complaints about needing admin for something or other, if admin is needed. (Not quite the same as UAC on Vista, but similar enough that a developer on XP can get a head start.) The same with trying to write files in one of the system areas, like %systemroot%, if it is limited to Administrators, or registry entries in HKLM. It gives me a quick way to test running portably on a guest account without actually switching to one. It's not a replacement for testing on a guest account, but catches a lot of things first. Plus 0-day malware will have a harder time getting a foothold if it inherits no Admin privileges. (Psexec, for some reason, briefly opens a CMD window when it runs, which is annoying, but fleeting.)

Another thing this script does is start two programs. More could be added, for a specialized startup sequence. If one wanted, say, five specific programs launched, one could add a few lines at the end of this script and compile it into an .exe. I chose 10 seconds delay between starts, but it's easy to have more or none.

The other reason to post this is in case some of those with more NSIS experience can offer suggestions for better ways to do things. Again, I'm in no way suggesting this as a substitute for the startup program in John's suite, just as something that might be useful for a few developers.

!define NAME "StartPortableApps"
!define FULLNAME "StartPortableApps"
!define APP "StartPortableApps"
!define VER "1.0.1.1 experimental"
;!define WEBSITE "PortableApps.com"
;!define DEFAULTSETTINGSDIR "settings"

Name "${FULLNAME}"
OutFile "${NAME}.exe"
Caption "${FULLNAME} | PortableApps.com"
VIProductVersion "${VER}"
VIAddVersionKey ProductName "${FULLNAME}"
VIAddVersionKey Comments "Allows ${APP} to be run from a removable drive.  For additional details, visit ${WEBSITE}"
VIAddVersionKey CompanyName "PortableApps.com"
VIAddVersionKey LegalCopyright "John T. Haller"
VIAddVersionKey FileDescription "${FULLNAME}"
VIAddVersionKey FileVersion "${VER}"
VIAddVersionKey ProductVersion "${VER}"
VIAddVersionKey InternalName "${FULLNAME}"
VIAddVersionKey LegalTrademarks "PortableApps.com is a trademark of Rare Ideas, LLC."
VIAddVersionKey OriginalFilename "${NAME}.exe"
;VIAddVersionKey PrivateBuild ""
;VIAddVersionKey SpecialBuild ""

;=== Program Icon
Icon "${NAME}.ico"


SilentInstall Silent
RequestExecutionLevel user
OutFile "StartPortableApps.exe"


;=== Main section ===
Section "Main"

      System::Call 'kernel32::CreateMutexA(i 0, i 0, t "${NAME}") i .r1 ?e'
      Pop $0
      StrCmp $0 0 SetTempEnv
         ; already running; two might interfere with each other
         MessageBox MB_OK|MB_ICONEXCLAMATION "Another instance seems to be running. Please wait a moment and try again."
         Abort
      
   SetTempEnv:
      ; let's set special environment variables for the PA run-time environment
      ; first TEMP ... make sure our directory exists
     CreateDirectory $TEMP\papps
     ; ignore errors in case it already exists or something
     ; put %TEMP% into $1
      ReadEnvStr $1 TEMP
      ; set TEMP, TMP, and TEMPDIR to point to papps
      System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("TEMP", "$1\papps").r0'
      System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("TEMPDIR", "$1\papps").r0'
      System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("TMP", "$1\papps").r0'

      ; some programs need to know what drive they are on
      System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("pdrive", "$EXEDIR").r0'

      ; now start menus and things that will inherit this environment
      ; the next lines show how to start with limited privileges
      ;Exec `"$EXEDIR\PortableApps\Sysinternals\pstools\psexec.exe" -l -d "$EXEDIR\PortableApps\PortableAppsMenu\PortableAppsMenu.exe"`
      ;Sleep 10000   ; 10 seconds * 1000 milliseconds
      ;Exec `"$EXEDIR\PortableApps\Sysinternals\pstools\psexec.exe" -l -d "$EXEDIR\PortableApps\PStart\PStart.exe"`
      Exec `"$EXEDIR\PortableApps\PortableAppsMenu\PortableAppsMenu.exe"`
      Sleep 10000   ; 10 seconds * 1000 milliseconds
      Exec `"$EXEDIR\PortableApps\PStart\PStart.exe"`
      
SectionEnd
Ryan McCue
Ryan McCue's picture
Offline
Last seen: 14 years 6 months ago
Joined: 2006-01-06 21:27
Erm...

Though I haven't tried it, I know it won't compile. Version must be only numbers, in the format v.x.y.z, or else Windows will blow up (NSIS won't let you compile, so that doesn't happen).

I've also added/removed other stuff to make it better. Changed version number to 1.1.0.2. In future, add to the last number only (well, until a new version is released). Therefore,

!define NAME "StartPortableApps"
!define FULLNAME "Start PortableApps"
!define APP "StartPortableApps"
!define VER "1.1.0.2"
;!define WEBSITE "PortableApps.com"
;!define DEFAULTSETTINGSDIR "settings"

Name "${FULLNAME}"
OutFile "${NAME}.exe"
Caption "${FULLNAME} | PortableApps.com"
VIProductVersion "${VER}"
VIAddVersionKey ProductName "${FULLNAME}"
VIAddVersionKey Comments "Starts the PortableApps Platform.  For additional details, visit ${WEBSITE}"
VIAddVersionKey CompanyName "PortableApps.com"
VIAddVersionKey LegalCopyright "John T. Haller"
VIAddVersionKey FileDescription "${FULLNAME}"
VIAddVersionKey FileVersion "${VER}"
VIAddVersionKey ProductVersion "${VER}"
VIAddVersionKey InternalName "${FULLNAME}"
VIAddVersionKey LegalTrademarks "PortableApps.com is a trademark of Rare Ideas, LLC."
VIAddVersionKey OriginalFilename "${NAME}.exe"
;VIAddVersionKey PrivateBuild ""
;VIAddVersionKey SpecialBuild ""

;=== Program Icon
Icon "${NAME}.ico"

SilentInstall Silent
RequestExecutionLevel user
OutFile "StartPortableApps.exe"

Section "Main"
	System::Call 'kernel32::CreateMutexA(i 0, i 0, t "${NAME}") i .r1 ?e'
	Pop $0
	StrCmp $0 0 SetTempEnv Run
      
	SetTempEnv:
	; Set PADRIVE and PATEMP variables for special cases (i.e. tie-in apps)
		System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("PADRIVE", "$EXEDIR").r0'
		CreateDirectory "$TEMP\PortableAppsTemp"
		System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("PATEMP", "$1\PortableAppsTemp").r0'

	Run:
		Exec `"$EXEDIR\PortableApps\PortableAppsMenu\PortableAppsMenu.exe"`
SectionEnd

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

rab040ma
Offline
Last seen: 4 months 3 weeks ago
Joined: 2007-08-27 13:35
Thanks Ryan. My NSIS (v 2.3)

Thanks Ryan.

My NSIS (v 2.3) compiles it just fine, and the text "experimental" shows up as part of the version number in the Explorer "properties" view. Or were you just suggesting that the version should only consist of the 4 numbers as a matter of custom or policy?

I would have set it to 1.1 except I didn't think of it as a potential release version, and didn't want to have a version kicking around that might end up with the same version as a release. Perhaps I should have renamed it completely rather than trying to come up with a minor version number change.

You said that I should change the last number only, yet you changed the second (version) number as well. Is there a 1.1 from which this would be a second compile (perhaps distributed with the 1.1 version of PAM, though I didn't see it)? If so I missed that. It would make sense, if the StartPortableApps.exe is closely linked to PortableAppsMenu.exe version 1.1. Or maybe you were suggesting your version as a 1.1?

I thought I remember seeing a discussion note from John about version numbering, but can't find it, the closest I can come is this (quoted here to make it easier to find):

Also, a suggestion on version numbering. It's usually major 
version, minor version and then bug fix version in terms of 
most apps. So 2.0 would be a major release. 2.1 would be a 
minor update with improved functionality, etc. And 2.1.1 would 
be a bug fix on 2.1. The 4th version number is usually just 
used for build tracking (for example, I have Delphi 
auto-increment it for each successive build of the 
PortableApps.com Menu). This is artificially incremented 
to release-version.0 when the actual stable release is 
made. A few apps break this pattern (like the Mozilla apps).

I tend to leave the common or system-defined environment variable names uppercase, and temporary or custom variables lowercase. I know it doesn't matter much.

There are a number of other changes you made, but the only comments are "to make it better". But you didn't say why or how your changes made it better.

-- How does removing (or having fewer) comments make it better?

-- I set it so it fails with a message box if another instance is running. You changed it so it continues running the second instance (though skipping the environment variable initialization). If it were not something mostly for my own use in testing, I might have removed the message box, so it fails silently. Is your version of the mutex test just to prevent the setup work involving directories and variables, or do you think there is something wrong with my decision to Abort if another instance is already running (in the process of starting PortableAppsMenu.exe)?

-- You removed my setting of the TEMP environment variable, substituting PATEMP. Is that your version of "preference for your own testing", left in as an example of how to set an environment variable that gets inherited, but would otherwise accomplish nothing at all (since nothing else currently uses it)? Or are you saying that there is something less than helpful about my changing the TEMP variable? I'd point out that setting the TEMP environment variable to be a subdirectory of the system-defined (user) temp directory means that I am in fact using that TEMP directory. (I do like the idea of having any temp files for PAP concentrated in a separate subdirectory tree of the user TEMP directory.)

It looks to me like yours is a bit closer to being a "production/release" version. Mine still has some features I like for my personalized or "test" environment, like the use of psexec, or starting two (or more) programs. I'd definitely remove some of them if I were working on a release version (which I haven't been invited to do).

I look forward to any further enlightenment you might offer.

MC

Ryan McCue
Ryan McCue's picture
Offline
Last seen: 14 years 6 months ago
Joined: 2006-01-06 21:27
Hmm

My NSIS (v 2.3) compiles it just fine, and the text "experimental" shows up as part of the version number in the Explorer "properties" view. Or were you just suggesting that the version should only consist of the 4 numbers as a matter of custom or policy?
Well, it never used to compile for me. Meh. (Using 2.33)

I would have set it to 1.1 except I didn't think of it as a potential release version, and didn't want to have a version kicking around that might end up with the same version as a release. Perhaps I should have renamed it completely rather than trying to come up with a minor version number change.
You said that I should change the last number only, yet you changed the second (version) number as well. Is there a 1.1 from which this would be a second compile (perhaps distributed with the 1.1 version of PAM, though I didn't see it)? If so I missed that. It would make sense, if the StartPortableApps.exe is closely linked to PortableAppsMenu.exe version 1.1. Or maybe you were suggesting your version as a 1.1?

Well, what I meant was, major.minor.bug.build, and since we aren't actually making releases here, you'd increment the build number.
I set it to 1.1.0.2, meaning that it's build 2 (based on build 1, by you) of 1.1. I'd say that while it probably won't become SPA.exe v1.1, as the features will be built into the Menu, it still might be useful for John.

I tend to leave the common or system-defined environment variable names uppercase, and temporary or custom variables lowercase. I know it doesn't matter much.
I prefer to have them uppercase. It's just personal preference.

There are a number of other changes you made, but the only comments are "to make it better". But you didn't say why or how your changes made it better.
-- How does removing (or having fewer) comments make it better?

Only comment when necessary. For example Section "Main" pretty much states what it is and doesn't need commenting, but something like

		${ConfigRead} "$PROFILEDIRECTORY\prefs.js" `user_pref("browser.startup.homepage", "` $0
		${StrReplace} $1 'file:///$2' 'file:///$3' $0
		${ConfigWrite} "$PROFILEDIRECTORY\prefs.js" `user_pref("browser.startup.homepage", "` $1 $R0

(from the FFP launcher, 3.0b1) needs to be commented to say what it is.

-- I set it so it fails with a message box if another instance is running. You changed it so it continues running the second instance (though skipping the environment variable initialization). If it were not something mostly for my own use in testing, I might have removed the message box, so it fails silently. Is your version of the mutex test just to prevent the setup work involving directories and variables, or do you think there is something wrong with my decision to Abort if another instance is already running (in the process of starting PortableAppsMenu.exe)?
If the PAM/PAP is already open and you execute it again, it simply shows the already running instance. Since you've opened it before, the variables should already be set up, so you don't need to set them again.

-- You removed my setting of the TEMP environment variable, substituting PATEMP. Is that your version of "preference for your own testing", left in as an example of how to set an environment variable that gets inherited, but would otherwise accomplish nothing at all (since nothing else currently uses it)? Or are you saying that there is something less than helpful about my changing the TEMP variable? I'd point out that setting the TEMP environment variable to be a subdirectory of the system-defined (user) temp directory means that I am in fact using that TEMP directory. (I do like the idea of having any temp files for PAP concentrated in a separate subdirectory tree of the user TEMP directory.)
I do agree with having all the portable temporary files under one directory. However, I changed the name for future use, say if you're building an app from scratch and you want to check if you're running from a portable drive. (I'm thinking outside companies here, that want to release Platform compatible apps)

[...]I'd definitely remove some of them if I were working on a release version (which I haven't been invited to do).
Who needs invitations? Biggrin

I look forward to any further enlightenment you might offer.
I feel like Buddha now Blum

Note @ John: We really need the <blockquote> tag. Seriously. Now.

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

rab040ma
Offline
Last seen: 4 months 3 weeks ago
Joined: 2007-08-27 13:35
re blockquote

Blockquote would make a lot of sense.

MC

Log in or register to post comments