I need to find all Visual C++ runtime installed on a machine. The exe will be run by a user who is not in the administrator group.
All solutions I've found rely on registry keys or scanning the c:\Windows folder (which I don't think is very reliable). In addition, if user cannot read the registry, chances are they don't have permission to access the system folder either.
Q1. Is there a 3rd method?
Q2. If multiple versions of VC++ are installed, is there a way to determine which one is used when an application is executed?
A1: Depends on what you mean by "installed". If you mean "used by some application", then even those methods won't tell you. If you mean "automatically found during application loading", then you really have to check the registry settings used by the loader.
A2: Sure, check whether the application imports MSVCRT80.DLL or MSVCRT90.DLL, etc.
Related
I have a windows desktop application which is currently available on a Linux server for download on user's machine. I want to automate the process of MSI packaging on the same Linux server using any EXE/DLL.
I have an App.exe and App.txt file. Some information should be read from text file and injected into exe before creating an MSI package. This entire process has to happen dynamically in the Linux server only after the user clicks on download.
Can anybody point me in the right direction as to how i can achieve my goal? I want to achieve the same by having minimum dependencies on any additional/3rd party tool. TIA for any time and effort.
p.s - I have done some R&D about various installers but none of them were matching the criteria as they have too many dependencies.
False Positive Risk: Creating a new binary for every user would seem to be very unwise because of malware scanners and their ability to recognize "known" versions of binaries (by hash).
If you create a new binary for each user, the malware suite might suddenly start to quarantine your setup without any warning or sense. This problem is not trivial anymore as malware control is hardened everywhere and setups that run with elevated rights are "prime suspects for risk management".
Digital signatures can help, but they are merely a guarantee that you made the setup, and not a guarantee that the setup doesn't contain anything harmful. Nothing worse than signed malware vectors. In fact it is proof positive that the malware came from you :-). Note: some people even manage to tamper with signed executables. The combination of the latter two fact is very troubling.
Application Setup: I like to eliminate such features and details from the setup and make the application itself responsible for it own configuration on first launch after installation. I find this more reliable and easier to debug.
Custom Configuration: You can apply custom configuration information at runtime via various mechanisms. You should add in a transform, or you can create a batch file next to the setup with this information embedded and pass to the MSI or the setup.exe.
Batch File?: The msiexec.exe command line supports passing parameters to the MSI. You can generate a batch file that will run the setup with such parameters if you design your setup to support these "incoming" parameters.
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn
Transform: You can also create a transform to contain the parameters (a transform is a tiny MSI fragment with settings and changes to the original MSI):
msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn
A transform would be difficult to create on a Linux box, seeing as they are COM-structured storage files native to Windows only. I am not sure if it is even possible, but maybe.
Some Links:
Can the resulting command line be determined after running an .msi installer?
Change Program Name and Shortcut Title during installation
How to make better use of MSI files
We have had some success with wixl from msitools.
Also WiX will run under WINE.
However, in both cases we have not had EmbedCab="yes" work, which may or may not affect you.
i have a .msi file . i want to add functionality in the installer.
i want to add
License Key Condition ,when someone try to install the application.
i don't want others to use this application. Only for those who have key for this software.Please help me if you can. Thanks
This question needs some improvement and clarification I think, but I will attempt an answer.
The application itself should be designed to allow license keys to only be accessible for certain users. Generally this involves storing the license in HKCU rather than HKLM. You cannot really change this in the setup, it is the application that will expect to read the license key from a predetermined source. Some applications are able to store license keys both per-user or per-machine - it all depends on its design. What application is this?
One way to "emulate" this for applications that only register the license key per-machine (for all users), is to remove the shortcuts to launch the application for users who do not have rights to use the application. This can involve installing the MSI "per-user", but it doesn't always work as intended.
It also depends on how you will distribute this software. Does it get installed remotely from a deployment system such as SCCM, or will you install interactively on every computer? If the latter is the case, you can install as the user who will use the application, and check if there is an option called "Install for current user" (or equivalent). If you deploy remotely you should create a transform to set the same option (install for current user) and invoke the install via SCCM whilst that user is logged in.
Where does Linux fit into this equation? Are you running Wine or some emulation software?
I have in hands a third party msi installer that requires to be executed by an administrator. Im trying to change that so it could be installed by a regular user.
I managed to open it with installshield and changed some obvious settings like:
"Require Administrative privileges"
But in your perspective is that even possible? I´m having a hard time changing settings and configurations and until now i´m not having any success.
Im working with InstallShield 2013 Professional and if it is possible, in wich settings do you think i should be focusing?
For instance, running as regular user im now having a 1925 error.
"You do not have sufficient privileges to complete this installation for all users of the machine"
And i feel if i correct the error, others will appear.
Thank you guys!
It's highly unlikely you can do this because it depends on too many things in the MSI package that can change the system. Any files going to restricted locations (program files, common files etc) or changes to HKLM registry keys will require elevation. MSI installs don't violate security - they don't allow a limited user to change areas of the system that are restricted.
If the environment has group policy/Active Directory you can arrange for the MSI to be deployed from a central location via Group Policy, that's the way people get around this. Otherwise on UAC systems the MSI may offer an elevation prompt that allows admin credentials to be entered.
Otherwise the vendor needs to create an install that can be used by limited users.
Well, Yes i need administrative privileges to write to locations that are shared by multiple users. In the filesystem, this means folders like \WINDOWS or \Program Files. In the registry, this means all of the hives which aren't per-user. That´s ok, i don´t need any of this.
Therefore, i thought it could be possible to change the filesystem to something like [userprofile] and rewrite the program to only use the HKEY_CURRENT_USER.
But i suspect it could be more to it than only this.
Is there a NoUninstall=Y or similar option I can put into Setup.ini for a program?
I want to compare the behaviour of a patched and non-patched version of some software. To do that, I need 2 copies installed in different folders.
When I run setup.exe the second time, I am prompted to uninstall.
If I change DoMaintenance=N -> DoMaintenance=Y, I get the option to Modify, Repair, Uninstall.
I do not have access to the original InstallShield project files.
I'd like to avoid having to use Virtual PC.
Otherwise can I change the GUID of the first install within Windows/Regedit?
I don't sure regarding changing GUIDs of installer in registry, but I guess it's possible, but the better will be change your setup. As I understood you have access to setup.ini, and perhaps you have access to msi? If so, you could change GUIDs of components, PackageCode, UpgradeCode, ProductCode and ProductName or ProductVersion.
P.S. For editing MSI you can use Orca, or more useful and also free InstEd.
I've written some unmanaged C++ COM DLLs that rely on native C++ DLLs not in the system path. When I build the associated projects without copying the DLLs into the Debug/Release directories I get the infamous PRJ0050 compiler error.
Clearly I could copy required DLLs all around the solution, but I'd like to avoid this. I know I could set project properties Linker->"Register Output" to No and then run regsvr32 directly during a post build step.
My question is if there's a better way to do this. Is there a way to use the automatic "Register Output" option with a custom path controlled at the project level? What am I missing here?
Edit: Originally I'd been thinking "Register Output" did some magic like un-registering on a clean, but that isn't the case. The only thing special it seems to do is pick out the proper way to register different types of projects.
I am not sure what you are asking - but there are post build steps you can do. For example - if these are 3rd party libraries/DLLs you can have them located in a known relative path or in a directory named by an environment variable.
This is not an unusual scenario from what I can tell of your situation.
Can you add a DLL as part of the project (wherever it is located) and as the build step for that do the registration. Or you can make the build step for that a file copy and registration
Again - I am not exactly sure what you are asking and why your 2nd paragraph is not acceptable to you if it works