.

[Ath]

Oh, and to pull this thread back on track:

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

[TaoPhoenix]

Oh, and to pull this thread back on track:

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

-Ath (November 26, 2014, 02:55 AM)

I  agree with your objections and second your questions.

-Ath (November 25, 2014, 04:10 PM)

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

-TaoPhoenix (November 26, 2014, 02:35 AM)

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"

-Ath (November 26, 2014, 02:53 AM)

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?!"

[pillbug]

.

[mouser]

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

[pillbug]

.

[mouser]

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?

[pillbug]

.

[mouser]

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.

[pillbug]

.

[pillbug]

.

[mouser]

yep, i use inno setup.

hmm, that's tricky that inno runs from temp directory..

[pillbug]

.

[Ath]

The temp 'copy' I mentioned above is actually an unpacked extraction of a completely different setup exe, not the one I created. It contains multiple identifiable exes within it, including 2 of 64 bits, a copy of MS's shfolder.dll (licensing violation?), some sort of registration dll, plus all sorts of other Delphi crap.

-pillbug (December 23, 2014, 01:18 PM)

That is the way Inno Setup 5 works, indeed. Not widely documented though.

NB: The shfolder.dll is no licensing violation, but (AFAIK) an allowed/supported way of (easily) supporting known Windows folders for older Windows releases. If it wasn't allowed it wouldn't have been there in the first place.

[mouser]

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?

[pillbug]

.

[pillbug]

.

[mouser]

The problem is that it's going to require the app dev to create the Inno setup exe and then run a little app I provide that will mark the Inno setup exe. At runtime, after determining it is being used within an Inno setup, the plugin will locate its process's parent process's exe file and then determine if that's the original setup exe. If so, the crap wrapping testing will proceed from that process upward, back to the shell or original launching app.

that's an interesting idea, but should be avoided if at all possible because of the extra work involved on behalf of developer..
the thing is, if that would work then surely an easier approach would work too, no? I mean if you can locate the inno setup exe then you can inspect it and check out its exe name and company info, and that will surely be able to tell you whether its INNO or not, no?

[pillbug]

.

[pillbug]

.