Recently I ran into trouble when I discovered that vista restricts what can be installed into the system32 directory even though I am the administrator for this computer. It will not allow me to register dll files so I can use programs like wget globally like how programs "nslookup" etc are used. Keeps giving me this error.
Regsvr32: The module "C:\Windows\System32\libeay32.dll" failed to load.
make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.
The specified module could not be found.
Moving the required DLL files to system32 prompts me to confirm administrator privileges are needed to move these files, So I give the permission, copy the files to system32, and run wget to confirm. This is where it tells me it cannot find the DLL's required to run and when using regsvr32 it says it cannot find the entry point so it will not load the DLL asking me if it is a valid DLL or OCX file.
If I leave the DLL's that came with wget in the same folder as wget outsite of system32 they work vice adding them to system32 with the exe it will not work saying it cannot read the those dll files.
Is there a way around this or Do I need to Upgrade to Windows 7 to get away from these problems/restrictions?
Try Dependency Walker on wget.exe and see it it gives you more info about the problem
Could it be a permission problem when you copy the file to system32? Make sure your user has read/execute rights to it
Put it (and wget.exe) in some other folder that also is in %path%. c:\windows (Ugly) or a custom folder like c:\tools that you add to the system variables.
Use a version of wget that does not depend on that dll
Note: regsvr32 is not required for dlls in system32, it only works when the dll exports the DllRegisterServer function
Related
I'm building a program Using Qt Creator 5.2.1 (32 bit) with Mingw. One of the dependencies of this program is the libcurl library.
QT was building the file properly, however, when running, it would throw an error 139.
After running the dependency walker on the binary, I noticed that the libcurl dll in turn depends upon another dll called "libeay32.dll".
I did the following:
Copied the my program along with all required libraries(including
libeay32.dll) externally to Qt and ran it (this was successful).
After that I tried running from within QT, but having the libeay32 library in the build before running (this was successful)
Logically, I presumed afterward, that if I put the path to the libeay32 prior to any other paths within my PATH variable, that It would pull the correct version of the lib (re: answer to question here). However this did not work, throwing the same error 139 (it's apparently not finding the library)
I know I could run and test my program by simply copying the file into my working directory, however, for information purposes, I was wondering;
Is there any way of doing this without having to copy this DLL?
My instinct would have been that fixing the Path to point to this firstly would have helped as this would ensure that the DLL is pulled used before any other occurrences that may be there in other dirs.
Note: In referring to the PATH variable, I mean both the SYSTEM path and checking for the PATH Qt uses (Qt adds a few dirs to the path)
Thanks in advance for any help.
Either you link static, or you have to ensure that your library is located in one of the following locations (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx#standard_search_order_for_desktop_applications):
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
Using Advanced Installer, I have created and run a simple installer that contains a single .exe.
This .exe started as an executable jar (w/ splashscreen) and was built into a Windows .exe using Launch4j.
Once the application is installed (in C:\Program Files (x86)...), I can't execute it from the installation directory. However, if I copy the .exe to anywhere else, Desktop, or any other directories created by other installers, the .exe will start perfectly.
This appears to be a folder or application permissions issue. Comparing the permissions between this folder and the one created by Advanced Installer, the permissions and settings are identical.
The ONLY difference I see, between the installed .exe and the same .exe copied to another folder, is that the "Edit Permissions" button has an admin shield on it (one originally installed by AI).
Is there a setting in Advanced Installer that will allow my .exe to run once installed, or is this just trickery employed by AI to get you to pay for a more robust version? I am unable to make any changes in the OS that enable this file to run in the directory created by AI.
If the executable fails to run from Program Files but does works from another folder it most probably happens that your EXE needs write access to that folder. If you launch it with the option "Run as administrator" it should work. This is not caused by a limitation from Advanced Installer.
Starting with Vista onward you can embed a manifest file into an executable file, that specifies for the OS the execution level, so you can set the level to "RequireAdministrator", thus your will EXE will always behave as you launch it with the option "Run as administrator" when launched from a shortcut or double-clicked.
The cause of this error was that the target directory included an exclamation mark. "!".
I had switched to using InnoInstaller and it was working in an initial version, until I later switched the target dir to include the exclamation mark, and it was broken in the same way. (Removing it fixed.)
Have no idea why this was causing the problem, just an fyi.
I primarily develop on Linux where there is /usr/bin and /bin directories. I know that Windows does not have any real equivalent of either of these besides C:\Windows and C:\Windows\System32. Many command line programs that I port to windows, I simply will write an installer that will copy them to C:\Windows, because I do not feel like having to set a PATH variable. I know that the proper way is to set a PATH variable, but to me C:\Windows is == to /usr/bin. What do Windows programmers have to think about this? Is this a good habit, is there any real disadvantages, and should I actually install to Programs Files and set a path variable via the registry instead?
Install to Program Files (or even the user's AppData folder for user-specific installs), and provide an option to add the directory to %PATH%.
Installing to Program Files has a number of advantages:
Won't conflict with any other files that happen to be in C:\Windows
Won't override some other tool already on the user's PATH
Makes the components of your program more obvious, instead of a random scattering of files in C:\Windows
Avoids dependency conflicts (DLL hell) if you need to include your own DLLs
Giving users the option to add to %PATH% allows users to skip that step if they run into some other kind of conflict with your app (which is less likely with Program Files, but still possible). If you installed into C:\Windows, you'd have no way to avoid such conflicts.
You should install applications to the proper Program Files directory, generally; there are exceptions though. And there are numerous Environment Variables already set for numerous paths on Windows, %PROGRAMFILES% being one of them (and %PROGRAMFILES(X86)% being another, hence 'appropriate' path).
Using Advanced Installer. When I build and run my install project, after the install there is a folder called MyCompany (equivalent to [Manufacturer]) located within the ApplicationData folder (which resolves to C:\Users\Joey\AppData\Roaming\ on my system).
Within that particular folder is another folder called MyProgram 1.0.0 (equivalent to [ProductName] [ProductVersion].
And within that folder is another folder called install. And within that folder is a file called setup.msi with a size of 1.17MB
I have no understanding of why this file and these folders are being created. Further, after I uninstall my app, they get left behind on the system, which means my app is creating garbage.
Can someone please explain why this is happening? And also...if I can't cause this to not be present in the file system while my app is installed, how can I avoid leaving it behind on the file system after I uninstall?
Thanks.
When you are building an EXE setup file, that is the default extraction folder for the EXE, where you can find all the resources during the installation. You can change it from Media page, "Extraction folder".
It is not deleted after uninstall due a bug in Advanced Installer, you can find more details and a workaround on the forums.
On Windows Server 2008 64-bit, I need an .msi installer file to write some files to \windows\system32\inetsrv folder. (The files are some XML Schema validation files, that C# XmlReaderSettings.Schema.Add() expects to be in that folder).
When the installer runs, the files end up in \windows\SysWOW64\inetsrv folder, not where they need to be.
I attempted to have the installer then write to \windows\Sysnative folder, and the installer created a folder with that exact name, which I didn't expect to be possible. See this page for a good discussion on suppressing SysWOW64 redirection.
How should I get the .msi to write my files to the \windows\system32\inetsrv folder on Windows 2008 64-bit?
Here are the system folder properties you can use. I know it is counter-intuitive, but have you tried System64Folder? Read the remarks.
If that doesn't work, try just tacking System32 on to the end of WindowsFolder.
Edit-1: Try setting the Win64 attribute on your Component element and see if the redirection behavior changes.
I tried to use Sysnative in wxs file but I got the same result: create a Sysnative folder under Windows instead of using System32.
So I used Sysnative in a vbscript CA: found the Windows folder (&H24&) and append \Sysnative. This works, but a second CA is needed to delete the files during uninstall.
I solved my problem by writing the files to \windows, rather than \windows\system32.
It turns out that the C# XmlReaderSettings.Schema.Add() will work with a fully qualified path under the \windows directory. It just defaults to the system32 folder if the path supplied is not fully qualified.
This isn't really an answer to the question, but it is a work-around for my immediate needs.