Expand an x86 .exe to 'C:\Windows\System32' under both Windows x86 and x64?

Question

I would like to make my installer compatible under both x86/x64 windows, this means portable.

I did the innosetup installer only to expand an x86 CLI executable file, and I need to expand it to C:\windows\system32 directory even if the installer is running under a Windows x64 because otherwise if I expand it to C:\Windows\Syswow64 directory then the exe is not recognized under a Windows x64 CMD.

So how I should set this property to make it portable with the specified condition above?:

ArchitecturesInstallIn64BitMode= ???

And what flags I should use when expanding the file here?:

Source: {sys}\My_x86_application.exe; DestDir: {sys}; Flags: ???

I've played a little bit with some flags like 32Bit, 64Bit, and Is64BitInstallMode, but I can't get the expected result because if I know that restricted constants as {syswow64} throws an installation error under a Windows x86...

UPDATE

This is the relevant part of my installation script, but it is wrong, it should be compatible with x86 and x64 windows (portable) and only expand the Source: {sys}\* files to C:\Windows\System32 under both windows (using the constant {sys} to detect the dir path, of course).

[Setup]
DefaultDirName={pf32}\{#AppName}
ArchitecturesAllowed=x86 x64
ArchitecturesInstallIn64BitMode=x64

[Files]
Source: {app}\*; DestDir: {app}; Flags: ignoreversion
Source: {sys}\*; DestDir: {sys}; Flags: ignoreversion 64bit

but... why I receive two downvotes?, I think that my question is well structured and with all the required info for helpers. haters for no reason... — ElektroStudios, Nov 24 '14 at 16:43
Are you sure you want to install a 32-bit application into a 64-bit system folder ? I see that a 64-bit command prompt cannot see it, but that's what a 32-bit one is for. [also don't get the downvotes; ++] — TLama, Nov 25 '14 at 12:07
Yes @TLama I'm totally sure of what I want to do because two reasons: 1) As you know `System32` and `SysWow64` such as `Program Files(x86)` and `Program Files` are dirs to properly install and distinguise different architectures of the same app, but since my app is only x86 (I don't have the same app as x64) I can't enter into any conflict installing it in the `System32` dir, then I should not worry about where of both directories I choose to install my exe, but here comes the problem 2) — ElektroStudios, Nov 25 '14 at 12:44
2) The CMD can't recognize the exe If I install it into `Syswow64` (my `PATH` environment variable is right with default values),just I need to install it in the `System32` dir.Thanks for comment and sorry for my English. — ElektroStudios, Nov 25 '14 at 12:48
@Sertac Akyuz True, but not this: https://sourceforge.net/projects/mp3gain/files/mp3gain/1.5.2/mp3gain-dos-1_5_2.zip/download — ElektroStudios, Nov 26 '14 at 22:48
@Elektro - I don't see anything special about it. I have mp3gain. Just tried and it runs from syswow64, either from 32bit cmd or from 64bit cmd. I have no idea why you want to put it in system folder. I mean any system folder, it's not a system file. — Sertac Akyuz, Nov 26 '14 at 23:14
@Sertac Akyuz to save time and automate some tasks under CMD, If I add the mp3gain.exe into System32 I'm avoiding expanding mp3gain.exe to other location then updating the PATH environment var, it's just a more clean installation. the mp3gain.exe don't works for me in SysWow64 folder If I try to call it from CMD, I'm under Windows 8.1 x64 — ElektroStudios, Nov 27 '14 at 01:33
@Elektro - You don't need to fiddle with the system path variable. All you need to do is to add a registry entry in the ["App Paths"](http://msdn.microsoft.com/en-us/library/ee872121%28v=vs.85%29.aspx#appPaths) key. ... This is what happens if you ask about your solution instead of your problem. Your solution is wrong, making it work will not make it right. You should be asking what to do in order to be able to run a program from a command prompt without entering full path. — Sertac Akyuz, Nov 27 '14 at 02:16
@Sertac Akyuz Whoaa! That seems very useful, 10 years touching Windows and I didn't knew that internal so I just assumed things when asking. but really this is what I need for my intentions?, I've added this reg value but when I enter to CMD and I wrote "app.exe" the app is not recognized...: `[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\app.exe] @="C:\\app.exe"` If this really works and I'm missing something then please write an answer if this work I will mark it as accepted, thanks for your help — ElektroStudios, Nov 27 '14 at 04:06
@Elektro - It doesn't seem to work directly from the command prompt, wonder why... If you can use ["start"](http://stackoverflow.com/a/154090/243614) though, it seems to be OK. — Sertac Akyuz, Nov 27 '14 at 10:06
@Sertac Akyuz please see this: http://stackoverflow.com/questions/27179818/detect-commandline-application-from-cmd-without-messing-with-path-variable-or-sy — ElektroStudios, Nov 27 '14 at 23:08

score 2 · Accepted Answer · edited Dec 28 '14 at 14:09

2

Answered in parts like your question:

ArchitecturesInstallIn64BitMode

Valid values: One or more of the following, separated by spaces:
- x64
- ia64

Default value: (blank)

Description: Specifies the 64-bit processor architecture(s) on which Setup should install in 64-bit mode. If this directive is not specified or is blank, Setup will always install in 32-bit mode. Normally, you should not change this directive from its default value unless your application contains native 64-bit binaries.

You have a x86 exe binary so leave the field blank.

Source (Required)

Description: The name of the source file. The compiler will prepend the path of your installation's source directory if you do not specify a fully qualified pathname.

Example:

Source: "My_x86_application.EXE"

Leaving it without any path like the entry above might be optimal (for small projects, because it messes the files to be deployed with the setup script). Also, beware that Constants may only be used when the external flag is specified, because the compiler does not do any constant translating itself. So, the following entry:

Source: {sys}\My_x86_application.exe; DestDir: {sys}

actually expects to have the binary stored in the {sys} subfolder of a directory with the setup script. If that would not be so, the compilation fails.

DestDir (Required)

I think you can specify System32 always using {win}\System32. Since both x86 and x64 version of Windows contain the System32 directory.

For the Flags and further doubt clarification visit this page.

EDIT: Save the iss file in the same folder where your x86 exe binary exists. Then Run it.

edited Dec 28 '14 at 14:09

TLama

75,147
17
214
392

answered Nov 26 '14 at 18:44

Anirban Sarkar

796
6
14

`You should have gone there in the first place. It's just one google search ("inno setup") away. All sentences in italics are an exact copy from there.` I already know the flags and other values that you've mentioned also I know (most of) the description/details of each one, but google doesns't says how to properly combine them for this specific scenario. – ElektroStudios Nov 26 '14 at 18:55
1

@ElektroStudios Have you tried to run the setup? Leave the flags for defaults anyway. Since it was **DestDir** you had problem with. – Anirban Sarkar Nov 26 '14 at 19:04
@Anirban, this answer is what ? You've just copy/pasted excerpts from documentation and you're speculating what it does. Your final note *"You should have gone there in the first place. It's just one google search ("inno setup") away"* is rude in my view. And your note *"Have you tried to run the setup ?"* is useful for what ? If it runs, it's OK or something ? You should always understand what you are doing... – TLama Nov 27 '14 at 10:16
1

@Tlama As you see in your previous comment, if ElectroStudios knew all about the flags in the first place, then there is nothing left other than description. I also have posted answers to the specific questions deduced from the documentation itself. Lastly, is it wrong to ask the user to try out the solution? – Anirban Sarkar Nov 27 '14 at 10:27
@Anirban, then why are you consulting `Source` parameter for instance ? How does it involve the problem asked here ? Moreover, you said *"leaving it unchanged, without any constant like the example above is optimal since Constants may only be used when the external flag is specified, because the compiler does not do any constant translating itself."* In what way is it *"optimal"* ? – TLama Nov 27 '14 at 10:28
1

@Tlama The installer assumes the path from where it is run. It is thus better to leave the field devoid of constants like {sys} specified in the question. – Anirban Sarkar Nov 27 '14 at 10:30
@Anirban, nonsense. The `Source` parameter is the source for the file which is used at compilation time (unless you specify `external` flag). It has nothing to do with the system where the setup will run, and thus nothing to do with the question. You could read that in documentation if you mentioned it. – TLama Nov 27 '14 at 10:32
1

@Tlama So that the setup file compiles in a folder other than `%SystemRoot%\System32`. (I don't know where the exe source is so I assumed it will be somewhere other than `System32`). Run refers to run at compile time (compiler runs the scripts). Execute Inno Setup compiler t find out. I thought it would have been clear to ElektroStudios. – Anirban Sarkar Nov 27 '14 at 10:59
@Anirban, no, sorry, I won't execute the compiler :) Anyway, why would one compile setup into the system folder ? Or copy it there as a user ? Still, the `Source` parameter is used at compilation time (in this case). This question is about runtime. – TLama Nov 27 '14 at 11:08
1

@Tlama, your first question is the reason why I prevented ElektroStudios to use `{sys}` in `Source` in the first place (See the question). The second one is the output ElektroStudios expects. However, `DestDir` is created at runtime of the compiled installer, so the question is about both compile-time and runtime. – Anirban Sarkar Nov 27 '14 at 11:25
@Anirban, ok, so in what manner is it *optimal* as you say ? Is it optimal in that the script even compiles (since it fails if one uses constant there) ? – TLama Nov 27 '14 at 23:47
1

@Tlama File organization. I believe it's better to keep files of the same project under the same folder rather than the Windows folder. And the script does not fail to compile, it only expects the binary exe to be present in the Windows folder (which is not there in the first place but some other folder - see the edit.) When the iss file is run from the same folder as the exe, `Source` expects to find the exe there itself. And since the exe is there already, it works! – Anirban Sarkar Dec 08 '14 at 15:51
@Anirban, unless you use the `external` flag, the `{sys}` constant won't expand to the Windows system folder when used in the `Source` parameter (it would be the folder named `{sys}` being a subfolder of the folder with your script). So to my comment question I've been expecting answer like, it is optimal because you don't need to have `{sys}` subfolder (of the folder with your script) with your deployed files. Never mind. I'm done here ;-) – TLama Dec 12 '14 at 05:59
1

@Tlama Why would you use constants otherwise, although I your scenario would apply to anybody who didn't set the `external` flag. And _a bit late_, but advice taken, answer re-edited upto standard. – Anirban Sarkar Dec 26 '14 at 14:13
@Anirban, I don't get your last comment, but again, there is nothing *optimal* on not using constants in the `Source` parameter. They won't expand as long as you use the `external` flag. If you use `{sys}` in your source path, then either you have the `{sys}` subfolder in your deployment directory, or the compilation fails. And if you are serious with deployment, you separate deployment scripts from files to be deployed, so not using any folder structure is not *optimal* as well. But thanks for the update! Sentences like *"you could Google it"* might be taken as rude here. – TLama Dec 26 '14 at 15:06
1

@Tlama Its was not talking about being optimal but doesn't using constants without expanding them kinda defeat the purpose of using them in the first place? And yeah small typo in the previous... – Anirban Sarkar Dec 27 '14 at 01:54

Expand an x86 .exe to 'C:\Windows\System32' under both Windows x86 and x64?

1 Answers1

Linked