Closed pljones closed 3 years ago
However, I think the installer is likely built as a 32bit program
Yes, it must be a 32 bit binary, otherwise you could not install Jamulus on a 32 bit Windows anymore. We would need two variants of the Jamulus setup which I would like to avoid.
So, the initial install location should always be taken from %PROGRAMFILES%.
What I do in the NSIS installer script is:
${If} ${RunningX64}
File "${BINARY_PATH}${APP_EXE}"
${Else}
File "${BINARY_PATH}x86\${APP_EXE}"
${EndIf}
So, I thought that these code lines would put the binary at the correct place. But I have to admit that I am no NSIS expert at all.
It's a long time since I wrote an installer... but it was 32/64 aware... https://github.com/pljones/pjSTBLEditor/blob/master/mknsis.nsi
Please note that there is a branch where someone has already improved the Windows installer a lot. Unfortunately, I have not yet got this running on my PC. Here is the branch: https://github.com/corrados/jamulus/tree/improve_win_ci
Edit: Didn't take the last comment into account, editing and testing took too long sorry.
Hmm - without having changed any default setting during installation, on my 64 bit Win8.1 and Win10 PCs I find the application at C:\Program Files (x86)\Jamulus\jamulus.exe which is correct for a 32 bit application, so when and on what OS does the problem occur?
The installer installs both 32bit and 64bit instances.
I think this should read "The installer is able to install both 32bit and 64bit instances.". Actually the installer contains different jamulus.exe file versions for 32 bit (..\release\x86\) and 64 bit (..\release\) OSs. Similar for QT DLLs. So we need to differentiate between destination folder and source files (contained in the installer).
Destination folder The NSIS 'File' instruction writes the specified file to the folder $OUTDIR. In windows\installer.nsi, this global variable is implicitly set by the instruction 'SetOutPath $INSTDIR'. INSTDIR is initialized by 'InstallDir "$PROGRAMFILES\${APP_NAME}"'. PROGRAMFILES is an NSIS constant which is set by the installer at runtime to the value of the environment variable "ProgramFiles" (default = "C:\Programs") on 32 bit OS, or "ProgramFiles(x86)" (default = "C:\Program Files (x86)") on 64 bit OS. (According to the NSIS manual, the actual values are fetched from the registry.) So there is no need to "manually" differentiate between 32 or 64 bit OS in the NSIS installer script to use the correct destination folder.
Source files I do not have a Jamulus build environment, but there are two different sets of files contained in the installer which are selected according to the macro RunningX64, expanded at runtime of the installer. This appears to work correctly. I only have 32 bit WinXP PCs and the installer copied the correct files to the correct destination folder. My problem is that when I start the application, I get an error "C:\Programs\Jamulus\jamulus.exe is not a valid Win32 application.". Therefore I cannot judge if the installation is correct because I do not know which OS versions are supposed to be supported. If WinXP is not supported, I propose to introduce an OS version check in the installer (!include WinVer.nsh) and abort if the requirement is not fulfilled.
C:\Program Files (x86)\Jamulus\jamulus.exe which is correct for a 32 bit application
And that's the problem. It's installing to the same location regardless of whether it's installing a 32bit or 64bit application. Once upon a time, it only had to cope with a 32bit application. Now it has both to worry about and can't cope.
OK, thx, now I understood.
So depending on RunningX64, on x64 systems the installer must not use 'InstallDir "$PROGRAMFILES${APP_NAME}"' but instead 'InstallDir "$PROGRAMFILES64${APP_NAME}"' (does not work within a Section).
My question regarding older x86 versions still remains ...
Is this now solved? The only issue I see here is Windows XP.
Windows XP is not supported by the Jamulus software so we can close this now.
The installer installs both 32bit and 64bit instances.
Windows 64bit has two separate install paths for these -- %PROGRAMFILES% for the "native" binaries and "%PROGRAMFILES% (x86)" for the 32bit binaries as the system is 64 bit. (If the latter does not exist, the system is 32bit.)
So, the initial install location should always be taken from %PROGRAMFILES%.
However, I think the installer is likely built as a 32bit program -- so, because Windows isn't running in native mode, it gets told "%PROGRAMFILES%" is "%PROGRAMFILES% (x86)". That, of course, is then wrong on a 64bit system.
In addition, even if I manually tell the installer where I want it to install, the next time it runs, it doesn't bother to read the install location (that the uninstaller uses, so the installer set and should know how to read) -- it just defaults back to that incorrect location again.