Roderich Schupp wrote: [...]
> The Windows standards suggest to make exectuables write protected. > > Bullshit advice. If the files are owned by the user, the malware can > unprotect them. with the correct ACL, a restricted user cannot modify the files unnoticed (needs at least to confirm in the UAC dialog). > Unpacking the runtime files in a dedicated step seems to be a natural > solution to me. That's how most (portable) programs are "installed". > > If they can be installed by the user (i.e. without "admin" rights), this > gains you nothing. The user needs to run the installer with elevated rights, which requires confirming the UAC dialog or logging in as admin. On my machine, I can't write to "C:\Program Files" from my working account. I need admin rights to write there. Well, you can weaken the UAC settings. In business environments, it can be even enforced by a SRP that executables can be executed only from protected locations. > A PAR archive seems to contain (nearly?) everything to run the program > (Perl interpreter, libraries, DLLs etc.) > > What do you consider a "PAR archive"? In PAR lingo this is a .par file, > actually a zip file Sorry for using the wrong terms... > If you don't to use the standalone executables generated by "pp -o ..." ...I actually mean the content of the executable created by pp -o. As far as I see, this exe contains an archive with all dependencies including the Perl interpreter, the unpacker and a small stub to call the interpreter, correct? On the first run, the archive contents are unpacked somewhere. Alternatively, I can use my preferred unpacker to extract the files directly from the exe. What would be wrong with executing this unpacked stuff directly, without the "auto unpacking to temp" magic? What do I need to run it? Oliver
