A tad paranoid when it comes to installing software?

[lanux128]

found this humorous image mashup via HowToGeek. when it comes to installing software, better safe than sorry..

[Renegade]

-

[nosh]

Your purposeful *Le Click*2 on the main checkbox has been accepted.
This dialog box is meaningless now.
Thank you for choosing NCH Herpa Derp!

[Deozaan]

I do that too.

[edrez]

I do not get why some installation force you to take software included changes like this.  I mean, you would download and install one when you need it but they should not incorporate it with another software.

I understand that could only be their way of getting installs but if they do not, they should live with it. Probably go venture on another field you can do better not forcing yourself on something that would cost others.

[wraith808]

Your purposeful *Le Click*2 on the main checkbox has been accepted.
This dialog box is meaningless now.
Thank you for choosing NCH Herpa Derp!

-nosh (July 31, 2011, 12:11 PM)

Hilarious!  And I wouldn't put it past them.

[dhuser]

Me too, I do it also

[kyrathaba]

The only software I'm usually not paranoid about installing is software recommended by multiple DC members.

[justice]

Who ever thinks this is a good idea, to make people more paranoid about installing (your) software.

[Renegade]

Who ever thinks this is a good idea, to make people more paranoid about installing (your) software.

-justice (August 01, 2011, 05:23 AM)

Good point.

I certainly don't want people to be scared to install my software, but then again, I program in .NET, which lets me be minimally intrusive with ease. I like the XCOPY model.

It's the C++/Delphi crowd that scares me. Installing things into system folders and all that...

I don't like my system modified. Too much software does that, and especially in the multimedia area.

Then there's the security area and the the authoring tool circuit... Drivers, etc. etc.

I'm more willing to trust a small developer than a large dev house for the simple reason that large dev houses can afford to create bigger messes.

Still, with the entire "uncheck everything" paranoia, I'm on board. I uncheck it all because even if they're not being dicks, they could still be incompetent. Cover all bases. So that they still belong to you.

[wraith808]

It's the C++/Delphi crowd that scares me. Installing things into system folders and all that...

-Renegade (August 01, 2011, 09:20 AM)

Ummm... what?  What is this you say?  Almost all of my apps up until 2005 were in Delphi.  And *none* of them used the system folders.  Just as with *everything* else, it depends on the developer, even with .NET.

[Renegade]

It's the C++/Delphi crowd that scares me. Installing things into system folders and all that...

-Renegade (August 01, 2011, 09:20 AM)

Ummm... what?  What is this you say?  Almost all of my apps up until 2005 were in Delphi.  And *none* of them used the system folders.  Just as with *everything* else, it depends on the developer, even with .NET.

-wraith808 (August 01, 2011, 10:46 AM)

I've found that the C++ and Delphi crowd are more eager to install things willy nilly. That's not everyone, but just my own observation. .NET just makes it easier to NOT do those things.

[Stoic Joker]

I don't recall C++ ever needing additional files, unless it's an MFC app (which I never use).

While I'm not sure about the Delphi part, I have seen several mainstream production applications (like Sage BusinessWorks) that were created using Borland's (CBuilder) IDE that insisted on dumping a ton of .bpl files in the system32 folder.

But it's my understanding that these .bpl (Break Point Library) files are only used for debugging and should never under any circumstances be used/required by release version production software. So this would be a developer boo boo as I understand it.

[Renegade]

I don't recall C++ ever needing additional files, unless it's an MFC app (which I never use).

While I'm not sure about the Delphi part, I have seen several mainstream production applications (like Sage BusinessWorks) that were created using Borland's (CBuilder) IDE that insisted on dumping a ton of .bpl files in the system32 folder.

But it's my understanding that these .bpl (Break Point Library) files are only used for debugging and should never under any circumstances be used/required by release version production software. So this would be a developer boo boo as I understand it.

-Stoic Joker (August 01, 2011, 11:45 AM)

Maybe distant bad memories...

[wraith808]

I don't recall C++ ever needing additional files, unless it's an MFC app (which I never use).

While I'm not sure about the Delphi part, I have seen several mainstream production applications (like Sage BusinessWorks) that were created using Borland's (CBuilder) IDE that insisted on dumping a ton of .bpl files in the system32 folder.

But it's my understanding that these .bpl (Break Point Library) files are only used for debugging and should never under any circumstances be used/required by release version production software. So this would be a developer boo boo as I understand it.

-Stoic Joker (August 01, 2011, 11:45 AM)

Ummm... no.  BPL doesn't stand for break point library.  It stands for Borland Package Library.  They can either be compiled into the executable, or separated out as supporting assemblies.  And the only reason to separate them out is if you're going to load your own packages at run time.  See http://edn.embarcadero.com/article/27178.

They are the same as the atl/vc libraries, and contain system level functionality.  But they can be for the most part compiled into the executable, and in the case that they can't, they can be put alongside the application.  This is a practice of some developers, just as you could do the same in .NET.  It's not a difference or a weakness in the language, but the developer and how they distribute.

[Stoic Joker]

I don't recall C++ ever needing additional files, unless it's an MFC app (which I never use).

While I'm not sure about the Delphi part, I have seen several mainstream production applications (like Sage BusinessWorks) that were created using Borland's (CBuilder) IDE that insisted on dumping a ton of .bpl files in the system32 folder.

But it's my understanding that these .bpl (Break Point Library) files are only used for debugging and should never under any circumstances be used/required by release version production software. So this would be a developer boo boo as I understand it.

-Stoic Joker (August 01, 2011, 11:45 AM)

Ummm... no.  BPL doesn't stand for break point library.  It stands for Borland Package Library.  They can either be compiled into the executable, or separated out as supporting assemblies.  And the only reason to separate them out is if you're going to load your own packages at run time.  See http://edn.embarcadero.com/article/27178.

-wraith808 (August 01, 2011, 12:03 PM)

Hm... Okay, that makes a bit more sense (it's been a few years since I last delved into it). Although it is still a bit annoying to see the installer spewing these things into the system folder. And it makes it easier to crack the application when they're done that way.

They are the same as the atl/vc libraries, and contain system level functionality.  But they can be for the most part compiled into the executable, and in the case that they can't, they can be put alongside the application.  This is a practice of some developers, just as you could do the same in .NET.  It's not a difference or a weakness in the language, but the developer and how they distribute.

-wraith808 (August 01, 2011, 12:03 PM)

So they are Borlands specific .lib type libraries?

I gave up on Borland years ago and went with MSVS C++ as it fit better with (my budget) what I was doing/looking for at the time.

[wraith808]

So they are Borlands specific .lib type libraries?

-Stoic Joker (August 01, 2011, 03:17 PM)

Sort of, though that's not a direct analogy.  They are statically linked, but can be dynamically loaded (and if .lib files can be dynamically loaded, then the answer is just yes).