We are using a really old Intel math library (nsp.dll and family) and it's location must be specified in the Windows PATH variable. Previously we installed these dll's in the Windows/System32 folder so everything was fine. Now we would like to install these dll's in another folder, the reason is we are migrating to Windows 7 and do not want to place dll's in the System32 folder. I found the SO answer as to how to change the PATH variable (thanks for that) and that does work. After installing I checked the PATH and our folder was NOT added to the PATH, I check the reg key and our folder WAS added. But....it appears that when we register our OCX that uses those dll's, the path is not changed yet. When I rebooted the PATH has our added path.
So, it seems I'm in a catch-22, I need to change the PATH and also use the new PATH during the install. Do I need to require a reboot and some how register that OCX after the reboot? Or is there another way?
After the reboot, running cmd as Administrator allowed me to register the OCX in the new folder. But I would like to have the installer do this automatically.
Thanks.
Make sure that you have the following setting in your script:
[Setup]
ChangesEnvironment=yes
This will allow the PATH change to take effect without a reboot.
However it will only affect new processes started by the shell. If you have an existing cmd window, or you try to start the application at the end of the install without using the shellexec flag, it will still see the old PATH.
And double-however: you cannot legally change the path where a COM DLL or OCX file is installed and registered. These must without exception be installed in the location specified by the vendor. Hence you must continue to install it in {sys} anyway. (At least if you're still using system-wide registration. There is an alternative that does let you move it, if you look up "registration-free COM", but it comes with a lot of caveats and is seldom worth the effort.)
Also note that "because Windows 7" is not a valid reason to move something anyway.
Related
We are using an earlier version of a commercial application, doors.exe. The latest Windows 10 update broke it. Using msftedit.dll from Windows 7 restores it. Below are three scenarios I have tried. I don't understand why the first and last function the way they do rather than the way the documentation seems to say they should. Questions are in the first and last bullet.
If I create a directory doors.exe.local in the same location as the doors.exe executable and put the win7 dll into that directory, it is ignored and the one in SysWOW64 is used. Why isn't it using the .local directory?
If I put the win7 dll in the same directory as doors.exe, the win7 is used, whether or not I have an empty file named doors.exe.local.
If I put win7 dll into the doors.exe directory but don't create doors.exe.local redirect file, I expect that doors.exe would use whatever dll is loaded and only use the win7 dll if nothing was loaded. If I first start WordPad, which also uses msftedit.dll, and then start doors.exe, doors.exe still uses the local msftedit.dll. Why isn't it using the same dll as wordpad?
I am using Process Explorer to see exactly which dll is used by which process.
The above behavior seems contrary to what I have read in the MSDN documentation. https://learn.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-redirection
What am I missing/not understanding?
Thanks,
Daniel
Do you know if the msftedit.dll is loaded with relative path? Or simpler, just by name? What you describe matches the standard LoadLibrary search order. First is the current working directory.
I am struggling with local redirection too. I have 3 PC where it works and 1 where doesn't.
I found how Dynamic-Link Library Redirection/Dot Local works. It uses some sort of caching per .exe instance to mark if redirection is used or not.
When you have an app.exe, first time when you run it on your PC it marks if it will use Redirection or not. Later this decision remains regardless if you put or remove the app.exe.local file/folder. I do not know yet where the cache value is stores. I searched the registry for the cache but haven't fount it.
Example 1: If you have app.exe and you do not have app.exe.local next to it and you run it first time, later never will use redirection. If you add app.exe.local redirection will not work.
Exsmple 2: If you have app.exe and you do have the app.exe.local next to it and you run it first time, later always will apply redirection. If you remove app.exe.local it still applies redirection.
I do not see the motivation for this confusing behavior.
Useful: if you want to reset the cache for an exe to use redirection or not, you can run in cmd:
touch app.exe
I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.
I'm trying to copy a file to System32 folder. I tried;
System.Environment.ExpandEnvironmentVariables("%windir%\system32")
Environment.GetFolderPath(Environment.SpecialFolder.System)
It didn't work. It always returns to C:/Windows . What should i do to get System32 folder ? Thanks.
Both of those work. You can verify you have the proper directory by setting a breakpoint on line 2 of your Button1_Click method and then inspecting the value of dir.
That being said, you really shouldn't be writing to the System32 folder (or really anything from the Windows folder down, with the exception of Temp). If you're trying to install an application on the end-user machine, you should be using an installer (and writing to the Program Files folder) instead.
Writing directly into the System32 folder isn't normally allowed (unless you've turned off access control and a lot of security features) as it introduces a huge security risk. You're also not guaranteed that it will even work on all systems because of different security controls that may (or may not) be in place.
I have a Wix installer which is designed to install (uninstall) a Windows service and another .exe file. When I uninstall the software using this installer, and enabling extra log, I see some error messages about unable to remove my installation folder, although it is indeed empty. The first message that appears on the log is like this:
DEBUG: Error 2911: Could not remove the folder MY_INSTALLATION_FOLDER.
The following errors are all about the same problem. My first guess is of course that there are some resources that were being used during the uninstallation. However, like I mentioned, all components in this folder were indeed removed and this is an empty folder by now. Also, this error is the first error in the log, meaning there was no error prior to removing this folder. For example, from the log I can see a series of FileRemove actions were taken right prior to the folder removal and they all succeeded. So it's gotta be that this folder itself was being used. But I really can't figure out why and what is holding this folder. By the way the software was indeed uninstalled since the final product removal returns 0 and every thing related to our software was removed (Windows service list, shortcuts, registries...) excepted this empty folder. It is not crucial but we definitely don't want to hear from our customer asking about this kind of error anyway(they are using auto-installation and the log is by default enabled and checked)
Please help. Thanks!
Possible causes:
Other process is locking that folder. Use Unlocker to
verify if that's the case.
Some folders have restricted permissions
by Windows (e.g. C:\Windows\system32). Generally, you should avoid creating files under Windows own folders (unless it's required, I.e.: your'e installing a device driver).
Did you properly set folder permissions?
I have added a config file (myapp.exe.config) that is deployed to the device after installation. But the problem is that this file gets read-only attribute. I have tried adding some stuff in the setup project in "codeINSTALL_EXIT" function. On emulator it works ... it removes the read only attribute, while when installing on the phone the attribute stays.
SetFileAttributes(szPathConfig, FILE_ATTRIBUTE_NORMAL)
Any ideas?
It's not completely clear from your question how the file is getting deployed (though I think from a CAb only). Things to check/know:
If you install via CAB, but then deploy from Studio (i.e. Debug) the file will get overwritten and the file studio pushes may well be read-only, especially if your SCC mechanism locks local files that aren't checked out (like VSS does).
When you build a CAB file, the file attributes get inherited from the source, meaning that if the file is read-only on the PC when you create the CAB, it will be read-only coming out of the CAB. One woudl think that the EXIT of the installer would be late enough to alter the attributes, but I've never tested it. Following your current path, you might check that the attributes before setting and also check to see if the Set call is actually succeeding. Personally I'd just make sure all files were read/write enabled before building the CAB to avoid the whole problem in the first place.