Oh, and to pull this thread back on track:

Yes, please devise tooling to avoid Crapware and Installer-wrappers

Quote from: Ath on November 25, 2014, 10:10 PM

I  agree with your objections and second your questions.

Quote from: TaoPhoenix on November 26, 2014, 08:35 AM

This feels like a lawsuit-avoidance tactic. "Starting with version ...

The above combination makes me really wonder why in earth's name a big multinational, like Oracle pretends to be, has to include crapware for some infamous minority like "Ask"

We might BE on track.

In a great world, such a tool would notice junkware from official sources as well as raw "bundling".

This was one of those test cases I think is useful. "Why is Ask-anything involved with a Java upgrade?!"

The unchecky thing is fine for half of this problem, but the dll is still very much needed.

Really looking forward to this.

Some quick thoughts:
What about checking what directory the installer is being run from?  If it's wrapped i'm guessing that its being dumped in a temp directory before being launched -- that would be a big clue, and perhaps the only one you actually need?

What have you found for these common adware wrappers? Are they exiting when they launch the real installer, so you don't have access to their info? or can you get the filename of the parent process that launched the installer?

My gut feeling tells me the safest, last resort, way to approach this sort of issue is to prompt the user for the installer file used, compare that with what the system says your installer's exe path is, and proceed accordingly.

i don't like that.. too confusing.. BUT you could certainly give the developer who is calling the dll some options to pass to the check function to tell you what they want to do.

the safe thing might be instead of REFUSING to install (which is what i want), displaying a big warning to user but still giving them the OPTION to proceeed.

.

.

But there are no identifiable versions of not only the app I told it to install but also the crap-wrapped plugin dll and the setup script. Apparently those are still packed up and thus inaccessible by the plugin.
Given all that, I'm at a loss as to how to tag the exe running the plugin dll as 'okay', given that its parent is another Inno Setup process/executable, giving it all the markers of being crap wrapped.

i'm not sure exactly what you are saying -- i do know that with inno you can call your dll's early during installation -- if you need help with that step let me know.

perhaps you are saying something else -- that it's hard to figure out how to detect whether it's been launched by a crapware installer or not?

.

.