+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2)
+--- Thread: Looking for 32/64 bit installer aka packager (/showthread.php?tid=3253)
Looking for 32/64 bit installer aka packager - doppler - 12-07-2024
Insane amount of results with google. Either a special dev environment for a company to package there stuff. Or descriptions of what a packager does. (really no help there)
My need: A packager (in 32 bits) that would determine the systems operating base 32 or 64. Then would install in a special directory my qb64 32 or 64 compiled program. A plus benefit would also install common data files as well in both environments. A real plus benefit, if the packager could determine a previous installation and only overwrite old with new code.
Unlike qb64pe which is a zip file unloaded (complete), I need an installer/packager. Maybe somebody here uses or knows where I can find this gem.
Thanks
ps. Others would love this too. When they see the advantage.
RE: Looking for 32/64 bit installer aka packager - JRace - 12-07-2024
Off the top of my head, Inno Setup can select 32-bit or 64-bit installs. The Inno installer uses a config file. I've never used Inno, so I don't know what is involved in creating that config file.
If you don't need a one-size-fits-all installer then you could have a seperate installer for each word size. You could then use an easy, wizard-based installer like InstallForge or InstallSimple to create those installers.
RE: Looking for 32/64 bit installer aka packager - SMcNeill - 12-07-2024
Write a quick QB64 installer for this.
$IF 32BIT THEN
SHELL "7z -extract 32bit_archive.7z"
$ELSE
SHELL "7z -extract 64bit_archive.7z"
$END IF
RE: Looking for 32/64 bit installer aka packager - doppler - 12-07-2024
(12-07-2024, 06:19 PM)JRace Wrote: Off the top of my head, Inno Setup can select 32-bit or 64-bit installs. The Inno installer uses a config file. I've never used Inno, so I don't know what is involved in creating that config file.
If you don't need a one-size-fits-all installer then you could have a seperate installer for each word size. You could then use an easy, wizard-based installer like InstallForge or InstallSimple to create those installers.
Ok, some interesting ideas. Investigation commences now ...
Edit:
Installforge: Anti-virus alarms set off. Don't trust it enough to ran anyways, even if the site says it might happen. They don't explain why it happens, I don't run it.
Installsimple: Program crashed at file creation stage. Just disappeared. Had to go through system logs to find out what happened. Mysterious crash, no reason logged.
RE: Looking for 32/64 bit installer aka packager - JRace - 12-08-2024
I wonder if your A/V killed InstallSimple?
What may be happening:
I suspect both InstallForge and InstallSimple are too insignificant for A/V creators to care about. The makers of the installers could submit their installers to the A/V creators (and probably have) to get safelisted, but that would take developer time (which is money) on the part of the A/V creators, and they won't bother with obscure or uncommon software.
A/V and antimalware looks for certain activities, instruction sequences or system calls that are commonly used by the bad guys, such as decompressing and immediately running executables (especially from unusual places like Windows Temp folder). Also, software which hooks into Windows keyboard and mouse functions often gets flagged, which may be a reason QB64PE & AutoHotkey often generate false positives. Gung-ho antimalware may be classifying them as keyloggers (they are not, although they could be used to create such things).
Malware executables are often compressed with EXE packers to hide their intentions from security software. The malware executable (the "payload") appears to A/V software as just so much random nonsense, so many A/V brands are suspicious of packers like UPX or MPress.
Malware is often hidden inside archives, both to obfuscate its purpose and to speed download times. Many A/V brands will examine files inside any archives they can open, and flag as suspicious any archives that they cannot get into.
I suspect your A/V doesn't recognize those installers and is therefore playing things safe by classifying them as "droppers" which unpack malicious executable code on a target machine. It's a "false positive". False positives are frustratingly common in A/V software, but A/V developers are more concerned with catching malware, or at least appearing to catch malware. The big A/V players like Norton & McAfee are mostly concerned with locking down their corporate customers' machines so that they can only run official, approved software.
Now back to business:
Leave it to Steve The Great to provide a simple PE-centric solution. You could even use self-extracting archives (.EXEs) so the user doesn't need to have 7Zip itself.
If you're feeling adventurous you could $Embed those archives into a 64/32-bit selector program: https://qb64phoenix.com/forum/showthread.php?tid=3145&highlight=files+more+portable:
Code: (Select All)
Code: (Select All)
'This is a thrown-together QB64PE 32/64-bit "archive carrier".
'v2024.12.09b by JSR.
'Public Domain. Free to a good home.
_Title "ExtractRun3264"
$Console:Only
'Change archive names below as needed....
$Embed:'./32bit_archive.exe','emb32'
$Embed:'./64bit_archive.exe','emb64'
'You might think that the PROCESSOR_ARCHITECTURE environment variable,
' which can have a value of x86 or AMD64 would tell us if we are
' running on 64-bit Windows.
'You would be wrong. You KNOW Microsoft wouldn't make it that simple!
'If PROCESSOR_ARCHITECTURE is set to x86, then we also need to check for the
' existence of PROCESSOR_ARCHITEW6432, which will reveal the truth.
'(Another Dubious Design Decision(tm) by Microsoft.)
'Start by assuming 32-bits...
o$ = _Embedded$("emb32")
'Now see if we need to change our assumption...
If ENVIRON$("PROCESSOR_ARCHITECTURE")="x86" _
And ENVIRON$("PROCESSOR_ARCHITEW6432")<>"" Then o$ = _Embedded$("emb64")
'On my 64-bit Win7 system PROCESSOR_ARCHITEW6432 is set to AMD64,
'so I guess we could check for that explicitly:
'And ENVIRON$("PROCESSOR_ARCHITEW6432")="AMD64" Then o$ = _Embedded$("emb64")
Cls
Print "Copyright (c) (this_year) by The Co. You Keep."
Print
Input "Press ENTER to continue installation...", t$
_WriteFile "./INSTALL_ARCHIVE.EXE", o$
If _FileExists("./INSTALL_ARCHIVE.EXE") Then
Shell "START /WAIT ./INSTALL_ARCHIVE.EXE"
Kill "./INSTALL_ARCHIVE.EXE"
End If
Print: Print: Print "Toodles!"
Print
'Input "Press ENTER to end installer.", t$
End
Of course, an over-eager A/V may still classify this behavior as bad, even though we, its frickin' creators, know it's not.
NOTE: Self-extracting archives won't create Desktop icons, Start Menu shortcuts, or uninstallers. You would have to devise a way to do those things.
Or try Inno. It's the heavyweight among installer creators, so most anti-productivity anti-virus software should give it a pass.
EDIT:
The original, untested version of ExtractRun3264.BAS that I listed above used the $IF method from @SMcNeill's post.
Buuuut... $IF is a compile-time thingie so, if I understand the WIKI, it will decide which archive to decompress based on the compilation environment, not the runtime environment.
So I updated ExtractRun3264.BAS above to use a method of detecting Windows word size at runtime.
Tested it, too, and it works (on Win64 anyway; I don't have a PE-compatible Win32 version to test on).