I've got some ideas on extending PortableApps.comLauncher. I was just wondering how I go about getting my ideas out.
One of my ideas is something like:
In the PortableApps.comLauncher.nsi file:
;=# Define where the custom.nsh file is.
!define NSH `${PACKAGE}\App\AppInfo\Launcher\custom.nsh`
;=# Defines the RequestLevel for use with the manifest
; See http://softables.tk/docs/advanced/uac#manifests
!searchparse /noerrors /file `${NSH}` `;!define RequestLevel ` RequestLevel ``
!if ${RequestLevel} == USER
!define /redef RequestLevel USER
!else if ${RequestLevel} == ADMIN
!define /redef RequestLevel ADMIN
!else
!define /redef RequestLevel USER
!endif
In the custom.nsh file:
;!define RequestLevel USER
or
;!define RequestLevel ADMIN
Now this is just one of the ideas I have. I feel like it would be advantageous on your guys part if we tried to implement some of these ideas within PAL.
Okay... How about this one? I'm not sure where you guys are on the dotNET feature but here's a function which could help. As it is written right now it only checks for 4.5 to 4.7..
In the PortableApps.comLauncher.nsi file:
Okay, so first this snippet of code will check the AppInfo.ini file for a key (UsesDotNetVersion) for it's value which should be the required version number. If the key exists it will set a !define (
${dotNET_Version}
) to whatever the key's value is. Afterwhich it'll call the function to check the host PC to see if .NET is even installed and if so what version the PC is compatible with. The function usesIntCmp
to see if${dotNET_Version}
and the value found in the registry are a match. $0 will hold true if the host PC meets the requirements otherwise $0 will be set to false and an error flag is set which is checked for. If any errors occur when launching the portable application it will alert the users of the required .NET version the system needs, calls Unload and quits. If when compiling the portable application and the compiler finds the key UsesDotNetVersion and it's empty, the compiler will stop immediately with an error message saying if the PAF does not require the .NET Framework to omit the key entirely.daemon.devin
For DotNet support, I refer you to the existing planned support: https://sourceforge.net/p/portableapps/launcher/ci/default/tree/Other/So...
(Note to self, I need to pull this into the github repo)
Is this not already set when using RunAsAdmin?
That was just an example.. more of a concept really.
Allow me to elaborate further. For instance, let's act like registering DLLs or Services were supported in PAL. Using the above concept we could simply write the following in
custom.nsh
—;!define REGISTERDLL true
and/or;!define SERVICES true
;let's go ahead and do;!define REGISTRY true
as well. This would be written in thecustom.nsh
file and commented out so it's not executed in the launcher.I hope you're still following me. Now inside the
PortableApps.comLauncher.nsi
file you could have something similar to this:Anyway, I'm sure you can see the gist of what I'm getting at. Basically, by doing something similar as above you could reduce the workload and bloat when the compiled PAF is launched. This will mean that the code is only included/compiled if the specific
!define
is set. This will decrease the installer overhead in theory, but in practice there is little change I believe (I have no evidence to support this though ..lol.).daemon.devin
I'm not following what you're trying to accomplish with this. These things are defined in the PAL ini and then handled in PAL itself. We won't be basing usage on defines within custom.nsh at all. We'll be adding features to PAL to discourage custom.nsh usage eventually.
Sometimes, the impossible can become possible, if you're awesome!
Okay.. then forget the
custom.nsh
file. It's not necessary to use this withcustom.nsh
anyway. I was just brain-storming. You could just use theLauncher.ini
for the code above. Instead of using:You could use the
AppInfo.ini
with a new section; something like[Dependencies]Services=true
and/or[Dependencies]RegisterDLLs=true
. So you'd instead have this inPortableApps.comLauncher.nsi
:You really don't see the potential here? It think it's a brilliant on/off switch mechanism. Even more so you could drop the command line call within
GeneratorWizard.nsi
and use this concept instead like the following:How about automatic code signing? (Needs NSIS3 because of
!finalize
)daemon.devin
I responded to the issues posted on the PA.c Launcher's GitHub repo page (https://github.com/PortableApps/Launcher/issues).
I suggested a means for handling/checking .NET 4.5 and above as well as 4.0 and below. (I've outlined two possible usages for the `DotNet` segment)
I also suggested a means to help with the Windows Shutdown issue. It's not a full solution, but it is a start towards something.
daemon.devin
@Gord Caswell
dot net checking I suggest change to DotNetChecker plug-in (http://nsis.sourceforge.net/DotNetChecker_plug-in) and (https://github.com/ReVolly/NsisDotNetChecker) which currently can check upto 4.6.2 and is currently actively develope.
The function I shared has a means to check for 4.5 all the way to present times and can easily be extended to support any future versions within a mere 10 seconds. It is also the recommended means of checking for 4.5 and later by Microsoft themselves (refer to this article for more information). Not to mention it doesn't depend on using a pointless DLL plugin which is probably using the same method I used in my function within it's source code anyway.
daemon.devin
I checked it out, and it doesn't look like the current maintainer has touched it in a while, despite there being good Pull Requests that fix major issues with it, so I'm not sure it can really be said to be "actively developed" at the moment.
~3D1T0R
May be the words I used are not correct. But this one is much newer than the one Gord Caswell used.
Thanks for the feedback, guys. I'm not in front of my computer for the next couple days, but will respond fully to comments here and/or on GitHub at that time.
I'm exploring using defines in PortableApps.comLauncher.nsi to speed up compilation time, but not to give users any custom control, nor to add any extra features to launcher.ini.
I can tell you that using defines for certain things is beneficial. I've accomplished a lot of really cool things with amazing results.
Good luck to with your development.
daemon.devin