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...e+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).
