We are using install4j version 9.x and found that there are possibilities for DLL hijack. Is there any way we can configure install4j to avoid DLL hijack issue while creating installer?
Which actions take by install4j to avoid DLL hijack while generating installers?
Related
I am trying to create an installer which will work as an installer in normal cases and if application is already installed it will update the existing installation.
I created an add-on installer with the new files. It works fine when executed independently.
To integrate it with the original installer, i merged this add-on installer with main installer .Then i checked if the app is already installed and added the "Add link to.." add-on installer.
But this installs all the files of the "Add on " as well as the main installer. Is this expected? As i am not even executing "Install Files" action of main installer. It installs the unnecessary files of original installer.
Is there any way to just execute the "Install files" action of only "Add-On" installer?
I am trying to create an installer which will work as an installer in normal cases and if
application is already installed it will update the existing installation.
Do not use an "Add-on installer" for that purpose. This is exactly what the regular installer does.
Assume I install a JRE, and run the createbundle tool of install4j version 7 on it.
Does the bundle contain artifacts made by EJ Technology?
If yes, what license do these come with?
(The bundle would also be under the license of the original JRE, obviously.)
Background:
This question is about what additional licenses I might have to observe if I redistribute a bundle as part of my application.
Also, some configuration and integration tasks will be easier because I can skip the red tape for license checking, but I need an official statement from the Copyright owner to open that easy route.
There are no additional artifacts in a JRE bundle created by install4j. Only the license of the bundled JRE applies.
what you call a software that requires no installation only unzipping like eclipse where it has no installation only we have to unzip and also for uninstalling just delete the Workspace.
That's typically called a portable application.
Sorry for asking a question so similar to the last install4j question, but I have a similar problem. I need to package third party installers with my install4j installer that need to run before my application is installed. I'm currently unable to host the other packages, so the only option I see is to package them with my installer. Is there a way to do this?
Add the third-party installers on "Installer->Custom Code & Resources"
Add "Run executable" actions in your installer and reference the third-party installers with ${installer:sys.resourceDir}/executable.exe
I am in the process of upgrading our development environment at work. One of the features is to get our developers using Eclipse as their IDE. However for security reasons we do not want our developers to be able to install plugins in Eclipse.
Is there a way to install Eclipse such that a regular user will need to obtain admin privileges to install a plugin?
Regrettably I am only familiar with *nix type permissions, and I would have thought windows would be somewhat similar. I believe I have installed Eclipse under C:\Program Files\eclipse with just read/execute permissions, but when a regular user comes along and tries to install a plugin it appears that Eclipse installs it under the user's directory. Is there a way to prevent that?
Basically after the initial installation of Eclipse the developer should NOT be able to install plugins. What's the best way to do this?
Ultimately this will need to work on a WinXP system. But for my home computer I test on a Win7 machine. Hopefully the procedure for the two platforms are the same, but when it comes to MS who knows.
There is no obvious way to prevent plug-in installation on eclipse. Even the eclipse installed under C:\Program Files\ on windows 7, eclipse also allows installing the plug-ins into the user's home directory for each user. It's designed for share install that has same behavior on linux as well.
I'm not sure what's kind of security concerns to make such a decision, one possible way is removing the org.eclipse.equinox.p2.ui.* plug-ins from your eclipse to disable the ui entry of eclipse's install menu.
FYI: the full description of the behaviour you are seeing is described in multi-user installs [1]. If you check out that and the Runtime options available as a link from that page, maybe you can set the osgi.configuration.area system property to something read-only as well.
[1] http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/multi_user_installs.html