#ifdef constant for WIN64 build?

[Andrew Truckle]

Is there a predefined constant for using with #ifdef etc for when you are doing a win 64 install build? I know in the code section you use IsWin64 and can use it as a check function.

I refer to blocks, eg:

#ifndef IS_WIN64
        (* Delete obsolete DLL files etc. because they are now maintained in
          separate sub-folders *)
        DelObsoleteFiles(ExpandConstant('{app}'));
#endif

[Gavin Lambert]

On Monday, April 8, 2024 at 7:50:18 AM UTC+12 Andrew Truckle wrote:

Is there a predefined constant for using with #ifdef etc for when you are doing a win 64 install build? I know in the code section you use IsWin64 and can use it as a check function.

No, that's nonsensical, because #if etc runs at compile time (so refers to the machine you're building the installer on, not where you're installing).

If you're building separate 32-bit and 64-bit installers from the same source then you could define your own variable for that, but this is not the recommended way to design your installers.  See the 64BitTwoArch.iss example script for the recommended approach.  (Or the 64Bit.iss example script if you're distributing a 64-bit-only app.)

For the case you're showing, though, you can just use a regular Pascal `if` block.

[Andrew Truckle]

I am using that bit mode setting, but I only put that in my 64 bit build  and I also used ArchitecturesAlowed just in the 64 bit build. 

But I see now from the notes that I don’t need to set the allowed flag. So the docs are a bit misleading. 

So with the install 64 bit enabled the installer will install to 64 on a 64 pc. And it will install to 32 on a 32 pc. Right. 

And, instead of using a IsWin64 check clause I use a Is64bitInstallmode check. And group 64 files first. Then 32 and then common. And use that solid break. 

I can make all those changes. But:

1. If 64 bit install then I want the app name as xxx (x64). Otherwise xxx (x86). So I do need two instances of my script where the 64 bit has a constant defined. Pity Inno does have a flag to add (x64) etc so something to avoid this. 

2. The 64 bit release build files are in a different folder to the 32. And we have to set the source to something.  The example assumes all files are in the same release folder. 

The moment the sourcedir is set then one or other will need a new relative path. I guess a constant can be defined for that. Eg

Set source dir to 64

Set 32 constant relative to 64

So point 2 above will let me have all files in one script. But point 1 still implies two scripts. You see I need to let user to install both bit editions and they show as two distinct apps in add / remove.  There are reasons for this 

Maybe I could pass the build mode as a constant on the command line. /DPLATFORM_TARGET=x64 for my 64 bit build. Then the ifdef can be used. When it is not passed the 32 bit name be used.

I will try later today. 

[Andrew Truckle]

I got it working well. Although my installer has bloated by 10 megabytes or so. Never used solidbreak before.

[Gavin Lambert]

On Monday, April 8, 2024 at 1:23:18 PM UTC+12 Andrew Truckle wrote:

> But I see now from the notes that I don’t need to set the allowed flag. So the docs are a bit misleading. 

For a 32-bit-only or a dual 32-or-64-bit install, you do not need to set it (though you should, if you want to restrict precisely which 64-bit architectures are supported by your app).  For a 64-bit-only install, you should set it.

1. If 64 bit install then I want the app name as xxx (x64). Otherwise xxx (x86). So I do need two instances of my script where the 64 bit has a constant defined. Pity Inno does have a flag to add (x64) etc so something to avoid this. 

You can use a {code:...} constant in the AppName or UninstallDisplayName if you want this to vary based on runtime conditions.  (You don't need to do this if you're building separate installers for each.)

Though note that Inno actually already does append (32-bit) or (64-bit) to the UninstallDisplayName, if both have the same AppId.  IIRC the first install is undecorated and then the second install gets the appropriate suffix, so that you can tell them apart.  (This requires that one install use 64-bit mode and the other not, so implies at least separate installers, if not separate scripts.)

 

So point 2 above will let me have all files in one script. But point 1 still implies two scripts. You see I need to let user to install both bit editions and they show as two distinct apps in add / remove.  There are reasons for this 

If you want to have separate 32-bit and 64-bit installers (perhaps for download size reasons), then you still can do that from a single script, e.g. passing `/dX64` to build the X64 version and then using #ifdef to detect which case.  You can use whatever name you like for this.

If you want to have a single installer (either automatically selecting the install type or using Types/Components to provide options) then you'd need to use {code:...} in the AppId (among other things) to keep separate uninstall entries, but you also need to be a lot more careful about which checks you do to decide what to install.

[Andrew Truckle]

 have two separate installers and I have two separate app ids.  I wanted to pass the /DWIN64  parameter but I am building from visual studio with visual & installer. For some reason the symbols passed using it are only working in the code section and not at the top of the script. But maybe I can use a {code:xxx} call them as you suggested. But using :

ifdef WIN64 does not work when passed. 

[Andrew Truckle]

Whilst they are separate installers, they #include common iss  file. 

As it is they work. But I want to put it all in the one script and use the #ifdef to conditionally pick which lines to include. 

[Gavin Lambert]

On Thursday, April 11, 2024 at 12:37:45 AM UTC+12 Andrew Truckle wrote:

 have two separate installers and I have two separate app ids.  I wanted to pass the /DWIN64  parameter but I am building from visual studio with visual & installer. For some reason the symbols passed using it are only working in the code section and not at the top of the script. But maybe I can use a {code:xxx} call them as you suggested. But using :

ifdef WIN64 does not work when passed. 

I'm unfamiliar with Visual & Installer, but if it's passing /dWIN64 on the compiler command line then you should be able to use #ifdef WIN64 within the script.  You may need to debug whether it's actually doing that or if it's passing something different.  Perhaps it's spelled differently or the condition where it is supposed to pass it doesn't apply.

[Andrew Truckle]

I understand now that when I specified parameters inside Inno Setup for testing that it was for the installer. It would be great if Inno Setup had a area to specify parameters for the compiler. So I will test again. If I can get it working right with Inno Setup then I have something to compare against Visual & Installer.

[Andrew Truckle]

All sorted.

[Gavin Lambert]

On Thursday, April 11, 2024 at 6:32:33 PM UTC+12 Andrew Truckle wrote:

I understand now that when I specified parameters inside Inno Setup for testing that it was for the installer. It would be great if Inno Setup had a area to specify parameters for the compiler. So I will test again. If I can get it working right with Inno Setup then I have something to compare against Visual & Installer.

To temporarily specify preprocessor variables for the compiler while testing, you can just insert a #define at the top of your script, then remove or comment it out later.

To permanently specify a default value for a particular preprocessor variable, you can do something like:

#ifndef MYVALUE

#define MYVALUE 42

#endif

This means that MYVALUE will be 42 when compiling with the IDE or if no overriding parameter is specified on the command line, but you can pass /dMYVALUE=17 to override it for a particular build.  If you want to temporarily override it for an IDE build, then simply add a temporary extra #define as above.