I need to create self-extracting archives that, once extracted, run different executables depending on the bitness of the Operating System.
Until now, I have done this by use of WinRAR and BAT files but the quick flash of the Command Prompt window prior to the main application's window looks suspicious.
So, I'm looking for a better option but have yet to find one.
You could code a 32-bit GUI application in C/C++/C# not opening a window which for example determines with getenv_s or getenv if variable ProgramFiles(x86) exists (only on 64-bit Windows) and starts next the appropriate main application. This executable is compressed into the SFX archive and executed by the SFX archive.
Or you code your own SFX module. The sources for unpacking a RAR archive can be downloaded from RARLAB.
Or you code a Windows script for determining bit width of Windows and starting the appropriate main application and execute this script by the SFX archive with wscript.exe which does not open a console window like its counterpart cscript.exe.
Or you create a 64-bit SFX which can be run only on 64-bit Windows and a 32-bit SFX which can be run on 32-bit and also 64-bit Windows and offer both for download. Most users of 64-bit Windows will most likely download the 64-bit version.
Related
I made 25KB exe file with installsimple,
and 28KB exe file with 7-zip sfx module
But i believe what installer can be smaller for several 1-2KB files
What i need from installer:
one executable file for deploy
smallest possible size of result exe file
launch my program after install
silent work - dont show any windows
What will be great(but optional):
change icon of install exe file
Which of these files( in setup folder), if execute can install a program on windows 7 ?
1- setup.com
2-setup.ini
3-setup.inf
COM files are executable in Windows. You should be able to run setup.com from the CMD prompt by cding to the directory setup.com is in, and running setup or setup.com.
Keep in mind, COM files cannot be executed on 64-bit versions of Windows, since these editions lack NTVDM, the MS-DOS-emulating subsystem that handles COM file execution. You would instead need to emulate the 32-bit environment using an emulator like DOSBox.
setup.inf can be used to file copy and installation. I cannot remember setup.com installers for Windows programs.
msdn inf description
When I create a file called hello.txt in C:\Windows\System32 with the text "hello" in it, gVim for some reason will not find this file. Can someone explain why this happens?
Here you can see I created the file in Notepad.
Now I'm trying to find the same file in gVim using :E. hello.txt is nowhere to be found. :e hello.txt opens up a new file. I feel like I'm getting trolled by my computer.
If you're using a 32-bit Vim (both Bram's installer and the "Vim without Cream" installer often recommended are 32-bit) on a 64-bit Windows, then you've fallen victim to the WOW64 redirection in Windows. Since 32-bit applications are not compatible with 64-bit libraries, C:\Windows\System32 when accessed from a 32-bit application actually gives you the content of C:\Windows\SysWOW64.
But don't despair, you can actually access the C:\Windows\System32 on most 64-bit systems from within Vim, you just need to use the special path C:\Windows\Sysnative (which only seems accessible by 32-bit applications and maps to the 64-bit C:\Windows\System32 directory).
Using Advanced Installer, I have created and run a simple installer that contains a single .exe.
This .exe started as an executable jar (w/ splashscreen) and was built into a Windows .exe using Launch4j.
Once the application is installed (in C:\Program Files (x86)...), I can't execute it from the installation directory. However, if I copy the .exe to anywhere else, Desktop, or any other directories created by other installers, the .exe will start perfectly.
This appears to be a folder or application permissions issue. Comparing the permissions between this folder and the one created by Advanced Installer, the permissions and settings are identical.
The ONLY difference I see, between the installed .exe and the same .exe copied to another folder, is that the "Edit Permissions" button has an admin shield on it (one originally installed by AI).
Is there a setting in Advanced Installer that will allow my .exe to run once installed, or is this just trickery employed by AI to get you to pay for a more robust version? I am unable to make any changes in the OS that enable this file to run in the directory created by AI.
If the executable fails to run from Program Files but does works from another folder it most probably happens that your EXE needs write access to that folder. If you launch it with the option "Run as administrator" it should work. This is not caused by a limitation from Advanced Installer.
Starting with Vista onward you can embed a manifest file into an executable file, that specifies for the OS the execution level, so you can set the level to "RequireAdministrator", thus your will EXE will always behave as you launch it with the option "Run as administrator" when launched from a shortcut or double-clicked.
The cause of this error was that the target directory included an exclamation mark. "!".
I had switched to using InnoInstaller and it was working in an initial version, until I later switched the target dir to include the exclamation mark, and it was broken in the same way. (Removing it fixed.)
Have no idea why this was causing the problem, just an fyi.
What is the "correct" way for a 32-bit application to find the "Program Files" folder on 64-bit Windows? For example, I am running a 32-bit application with a VBScript engine, and want to launch 64-bit Excel (using ShellExec, or similar). In the 32-bit world, I would check the environment variable "ProgramFiles" to get the base folder. My understanding is that as a 32-bit app on a 64-bit Windows, that environment variable will point to the 32-bit program files folder - eg: C:\Program Files(x86). But my 64-bit Excel will be under C:\Program Files.
I want to avoid hard-coding a reference to "c:\program files".
You can check the environment variable "ProgramW6432". It should exist and point to Program Files, without the x86, when running a 32bit application on a 64bit Windows.
Documentation: MSDN
Depending on the version of windows, you should be using the known folders apis.
http://msdn.microsoft.com/en-us/library/bb776911%28v=VS.85%29.aspx
Specifically you can use FOLDERID_ProgramFilesX64 in conjunction with SHGetKnownFolderPath.