All,
While removing the $Bits variable setting code from Custom.nsh files, I discovered that the only remaining portion of Custom.nsh for many apps is the chunk setting %FullAppDir%.
I'm thinking of adding $FullAppDir by default, using ${AppName}64 and ${AppName} as the directory names referenced.
The normal use appears to be AppName64 and AppName, with two apps using AppNamex64 and AppName, and two others using AppName\x64 and AppName\x86.
Moving forward, I recommend we standardize directory names as per the first option.
This would remove the need for Custom.nsh from:
- AkelPad Portable
- Daphne Portable
- RapidCRC Portable
- VirtualDub Portable
- WaveShop Portable
- WinMTR Portable
Additionally, it would leave only custom code for the following apps, rather than this relatively common code:
- 7-Zip Portable
- Avidemux Portable
- Blender Portable
- Krita Portable
- TEncoder Portable
- RawTherapee Portable
- UltraDefrag Portable
This would cover all official applications using FullAppDir, with the exception of Listary.
Thoughts?
Well, you're trying to eliminate the need for the custom.nsh file so I would say move forward. If I'm understanding you correctly, the first method is what I did within my code.
daemon.devin
I was under the impression that the 32-bit and 64-bit app directories were generally named after the way the publisher of the base app distributes official releases, so as to make repackaging easier for the developer(s) involved. If this is going to change, then I think a better way to standardize the hybrid IA32/AMD64 apps'
FullAppDir
would be to use theAppName$Bits
format, making the 32 & 64 bit variants be "AppName32" and "AppName64" respectively. However, I'm not sure this is the best way to go about it.I would like to propose that instead of defining
FullAppDir
directly in NSIS, we duplicate the functionality ofProgramExecutable
andProgramExecutable64
asFullAppDir
andFullAppDir64
so that they can be manually decided by the developer, perhaps giving them sensible defaults so that the de facto standard is already in place for the developers/apps that follow it.~3D1T0R
I vote for this (for the defaults), and if any dev releasing a portableapp doesn't like that structure (for whatever reason) allow for setting it how they would prefer.
Something like:
AppDirectory, AppDirectory64
or
ProgramDirectory, ProgramDirectory64
in the [Launch] section.
This would also mean that the directory no longer needs to be set in ProgramExecutable, ProgramExecutable64.
Though, thinking about it, that is probably how you would of done it anyway. (More or less)
I was thinking about that, and while it might be good to base
ProgramExecutable
&ProgramExecutable64
on the location ofFullAppDir
, it would require changes to a number of app's configurations.Note: I'm not saying it should or shouldn't be done this way, just that this is a factor to consider.
I think this might be good:
matching this structure:
Note: This is a simplified view of the structure, not showing unnecessary files & folders.
Note2: This is intentionally a slightly unusual app in order to show how both
FullAppDir
/FullAppDir64
andProgramExecutable
/ProgramExecutable64
may be needed in some apps.Note3: After writing this all out I think I might preferProgramDirectory
/ProgramDirectory64
as opposed toFullAppDir
/FullAppDir64
, but I need sleep so I'm going to stop writing. Goodnight.Edit: I altered my example to use
ProgramDirectory
/ProgramDirectory64
.%FullAppDir%
would be built by adding the contents ofProgramDirectory
to the end of the%PAL:AppDir%
environment variable, and the execution string would be based on the contents ofProgramExecutable
being added to the end of%FullAppDir%
~3D1T0R
I add the following 2 lines to the end of ${SegmentInit} in Core.nsh, ver. 2.2.1 of PAL. Seems work. Pls test.
${WordFind} $ProgramExecutable "\" "+01" $0
StrCpy $FullAppDir "$AppDirectory\$0"
Thanks for looking at it.
I've got an implementation in place for this already, it just may need tweaking depending on feedback in this thread, particularly from John.
I was just looking through the source of the PAL Manual in the repository, and the
%PAL:Bits%
environment variable stood out to me. Isn't the purpose of this effectively to replace the need for a%FullAppDir%
, in that the directory should be able to be defined asAppName%PAL:Bits%
, which by default would beAppName32
andAppName64
, but could be defined via[Launch]:BitsVariable32>
and[Launch]:BitsVariable64
to bex86
&x64
if the developer wished, making thenAppNamex86
andAppNamex64
, or even by defining[Launch]:BitsVariable32
as an empty string, one could make itAppName
andAppName64
.To be honest, having looked at this again, I think
%PAL:Bits%
eliminates the need for%FullAppDir%
and thus there's little reason to add it to PAL.~3D1T0R
Good catch, looks like we're reinventing the wheel.
However, I think I'm still going to define FullAppDir, as it's already in wide use, as %PAL:AppDir%\%AppName%%PAL:Bits%.
This allows the variable to continue to be used as it is now, in multiple places in launcher.ini.
I foresee that it may also see further adoption, for example in FilesMove and DirectoriesMove sections for in-package moves.
This way, for the apps using AppName64 and AppName, BitsVariable32 can be set to an empty string. (Provided that works, I need to test it.)
For those using AppNamex64 and AppName, BitsVariable64 can also be set to x64.
Lastly, those using AppName\x64 and AppName\x86, FullAppDir can be re-defined in the Environment section as %PAL:AppDir%\%AppName%\%PAL:Bits% after setting BitsVariable32 and 64 to x86 and x64 respectively.
$Bit
to check if file system redirection needs to be turned on or off by using the variable$App
and comparing it to${APP64}
. I also use it for checking a machines architecture by doing something like the following in the beginning of the.onInit
function: After all the Segments have been executed I then check and turn the file system redirection back on again: I set certain!define
instructions that never change in construct using my favorite instruction ( =P )!searchparse
. It only changes with respect for the programs name. For instance,${APP}
will always hold the applications 32-bit folder name (7-Zip or IrfanView) whereas${APP64}
will always hold the 64-bit folder name (7-Zip64 or IrfanView64). If there's a 64-bit version of a program available than${APP64}
is just the short name or theAppID
excluding the word "Portable" and appending the number 64. So now I can do something similar to the following code snippet for an application that has both a 32-bit and a 64-bit version (like in my 7-ZipPortable for example): Inside my 7-ZipPortable.ini launcher configuration file I may now do the following: I'm pretty sure the above code can be done a bit more pragmatically allowing for a much more broad spectrum of portable apps and I realize that you guys I trying to discourage the use of the custom.nsh file but I just felt like sharing anyway. Sorry for going off-topic somewhat with the file system redirection tidbit. I just meant to agree with 3D1T0R and share how I have came to deal with this concept. Lol.daemon.devin
I'd like to have it defined somehow as AppName and AppName64, not AppName32. I've been using this as a standard structure for most released app since I started doing dual mode apps. If we have to reformat apps to be AppName32 and AppName64, that's going to require custom code in the installers to move files around for several apps (plugins, added fonts, mods, etc).
Sometimes, the impossible can become possible, if you're awesome!
We'll have to check to verify that it works properly first, but with the system Gord & I are considering, you should be able set it to work that way by simply defining
[Launch]:BitsVariable32
as an empty string.I'll try to test it soon, but I'd take a wild guess that Gord can probably get to it sooner than I.
If that doesn't work, then I suppose we could consider having the
[Launch]:BitsVariable32
default be an empty string, and if you want it to be32
(or something else) you have to set it yourself.~3D1T0R
I still need to do some testing, but I currently have BitsVariable32 defaulting to an empty string, which accomplishes exactly what we're wanting:
When required, this can be overrode using [Launch]: BitsVariable32 or 64.
[EDIT] Alternatively, we can remove the BitsVariable customization function.
Wouldn't it be best to keep it so that we don't have to make custom installer code for the apps you mentioned that use x86 and/or x64 directories?
Especially seeing how the BitsVariable customization is already written, present in the repository, and needs only to be used, I don't see why we would want to not use it. Do you?
~3D1T0R
I've been looking into it, and the apps that don't meet what's becoming the standard have been placed in these other directory structures by our developers. As such, we can adjust the directories as needed.
Since the primary purpose of BitsVariable, and PAL:Bits is for FullAppDir customization (or at least that's as far as I can tell), in my opinion it'd be cleaner to implement FullAppDir directly.
Personally, I'd drop
%FullAppDir%
completely (I've thought it seemed rather out of place since I first started seeing it, and kept thinking that using%PAL:Bits%
would make more sense.) and use what has been in the PAL source since 2011:%PAL:AppDir%\AppName%PAL:Bits%
, but that's just what makes sense to me.I was thinking about how environment variables generally seem to work on Windows, and I'm wondering if perhaps you're running into an issue where empty environment variables don't get 'expanded'. Is this an issue that you're hitting? is that why you're suddenly against it when you seemed like you were for it before? If so, it shouldn't be too difficult to remove 'unexpanded environment variables' after expanding them.
~3D1T0R
I'm not running into any issues with empty environment variables.
I'm good with either way, however I'm thinking support-wise it may make more sense to use a method that's already in-use, and remove one that could replace it, but is not in use and adds further potential support problems.
That's not to say we couldn't figure out any problems as they arose - we are a smart group of folks, after all!
However, trying to alleviate the theoretical problem prior to it arising.
I suppose, if
%PAL:Bits%
will be available too so that%PAL:AppDir%\AppName%PAL:Bits%
can be used for non-standards-following apps, then it doesn't matter too much how%FullAppDir%
is implemented, as situations that need a more custom solution can use%PAL:Bits%
. After all, I still think%FullAppDir%
doesn't really fit with the rest of PAL anyway.~3D1T0R