We would like to ensure that when our application is loaded, it uses only Windows system DLLs and not any DLL from the folder containing the exe file for the application. The application is a standalone executable and can be run, for an example, from Download folder, hence the reason for the restriction. Unfortunately one of DLLs is not on KnownDLLs registry setting mentioned in Microsoft documentation.
The same documentation mentioned that one can use exe manifest to control the search order, but it is not clear how to do that to restrict the search path only to system libraries.
Related
If I'm not wrong, if an application specifies dependency in its manifest, Windows loader will load the specified version of the DLL from C:\Windows\WinSxS\xxx\ folder.
While I was researching on C:\Windows\System32\dccw.exe - which is the "Display Color Calibration" app on windows, I saw this weird behavior:
Application manifest has only one dependency - "Microsoft.Windows.Common-Controls"
which is basically the - comctl32.dll
However when you run dccw.exe, it loads two DLL from WinSXS folder; comctl32.dll as expected and also GdiPlus.dll.
Isn't a dependency for GdiPlus.dll should have been present in the manifest. Or did I not understand how WinSxS works correctly?
It is not required that all dependencies be specified in the application manifest. You can add some but leave out others.
As Hans mentioned in a comment, gdiplus under WinSxS is a hardlink to the same file in system32:
> C:\Windows\system32>fsutil.exe hardlink list GdiPlus.dll
\Windows\WinSxS\amd64_microsoft.windows.gdiplus.systemcopy_31bf3856ad364e35_10.0.
19041.1645_none_5b73408eab60fd9c\GdiPlus.dll
\Windows\System32\GdiPlus.dll
So functionally it doesn't matter which 'copy' of that file gets loaded.
As to WHY the process seems to load from WinSxS ... the two hard links are indistinguishable. There is nothing documented to suggest that WinSxS would be used as a DLL search location by default.
This may just be how Process Monitor chooses to report the file's location (?). If you compare to other tools like (archaic) Dependency Walker or Dependencies you get different results. One shows the WinSxS location, the other shows system32:
I have a small SWT based java application. On installation swt-win32-*.dll is installed with my application in C:\Program Files\myapp\win32.
When I looked at my application in process explorer I noticed that the dll is loaded from:
C:\Users\[Username]\AppData\Local\Temp\swtlib-32\swt-win32-*.dll
On Windows XP it ends up in:
C:\Documents and Settings\[Username]\Local Settings\Temp\swt-win32-*.dll
Whenever I delete it from the temp folder and restart my application the dll is copied there again. The other dlls my application depends on don't show this behaviour.
Who copies the dll (my application doesn't)?
What's the reason behind it?
I don't know Java very well, but if it's inside the JAR (or any kind of archive, really), then it has to be extracted into real file before it can be loaded (because OS provides no other supported way to do it).
I have a driver which can be installed on Windows (XP/Vista/7). It's accessed via a native C++ DLL that 3rd-party applications link to, and which is also a Winsock Provider (WSP). It used to be installed under System32, but having seen advice not to, I changed it to install under ProgramFiles instead.
Now, the problem is that people are having to either copy it back into System32 or copy it into the application directory whenever they want to use it in their own applications, because Windows won't search the install directory under ProgramFiles when the application tries to load the DLL.
I've been unable to find any Microsoft documentation discussing this issue, so if System32 shouldn't be used then where should shared DLLs be installed?
The Windows side-by-side cache. Backgrounder info is here, technical reference is here.
I haven't seen anybody actually do this yet, other than Microsoft. Quite notable is that MSFT gave up on winsxs deployment for the C/C++ CRT and MFC runtime DLLs for VS2010, it was causing too many problems. They're back in c:\windows\system32. The managed equivalent of this (the GAC) is going strong though. Better tool support, probably.
I'm fairly sure that by a large margin everybody chooses app-local deployment.
Since it's a DLL linked to your driver maybe it's less of an issue, but I'd be wary of trying to share the DLL and would instead try to get all developers of client apps to keep their own version of the dll in their applications folders.
I've had too much fun in DLL Hell to want any more weird bugs because AppX overwrote the DLL with an old version that breaks AppY etc.
Anywhere on the path would work.
If this is only to be used with your set of apps (eg Qt4.dll) then in the root of "c:\program files\my company" would be good, or have a 'shared' folder below that.
If it's to be used by other apps that you don't know about (eg a video codec) then system32 makes sense (you will need admin rights when you install)
Fixed filesystem location
One possibility would be to install them in a sub-directory of Program Files, as already suggested by #Martin Beckett.
Variable filesystem location, fixed entry in Registry
If you don't want to install them at a fixed location, you could also store their location in the Windows Registry. You'd install some keys under HKEY_LOCAL_MACHINE\SOFTWARE that your applications could read to find out where the DLLs are located. Then the DLLs can be loaded at run-time.
P.S.: Preventing orphaned DLLs
You could go one step further and use the Registry, or some other storage (a file, say), to store information about which of your applications uses which of your DLLs. For example:
FooCommon.dll <- FooApp1, FooApp2, FooApp3
FooBar.dll <- FooApp1, FooApp3
FooBaz.dll <- FooApp2, FooApp3
Whenever one of your applications is un-installed, it removes itself from this map. Any uninstaller can then safely delete a DLL that is no longer in use by any application. That method is akin to reference-counting, and the idea is to prevent orphaned DLLs from accumulating on users' filesystem.
Native DLLs can be stored as side-by-side assemblies. See this reference for more information. This is separate from the .NET Global Assembly Cache, but it uses similar concepts. This blog post also has quite a few useful details about how DLLs get resolved as side-by-side assemblies.
We have an installer for our application that must be downloaded and run with administrator privileges, like many other installers. However, the installer isn't named "setup.exe", so Windows doesn't automatically detect it as requiring elevation to run.
Changing the installer name to make things elevate properly sounds pretty messy, frankly. This article talks a lot about UAC and elevation, and it says that you can use a manifest to make something require authorization.
So, we'd just love to create a manifest for our installer. However, how do we ensure the manifest is present? If the user just downloads our_application_v13.exe, how do we ensure they get the manifest too? AFAIK the manifest would have to be a file named "our_application_v13.exe.manifest" in that case.
Since they're just downloading a file from our web site, how do we make sure they get the manifest too? Can we build it into the executable in some way, or otherwise flag the executable as requiring elevation? We are using an installer tool from hundreds of years ago that we can't change, so it doesn't have any capabilities relevant to this.
Thanks!
If the installer tool allows you to change/attach/edit the resources of the generated EXE file, you can add the manifest file as a resource with a resource type of 24 (RT_MANIFEST in the windows headers) and a resource id of 1.
If The installer tool does not have the built in facility to insert resources, then you might have to write a tool to post-process your install.exe file to insert the resource. Look up the Windows APIs BeginUpdateResouce and EndUpdateResource. They have some limitations - they tend not to work if the EXE doesn't already contain any resource files at all, but most install tool generated exe files contain at least a version info resource.
Also, if the install is digitally signed that will have to be done after insertion of the manifest resource.
Also, mt.exe included with the Platform SDK and most versions of visual studio has options to embed, extract and merge manifest resources.
The manifest can also be in the application's native resource section (inside the EXE).
There is Resource Tuner Console from Heaventools Software.
Resource Tuner Console is a command-line tool that enables developers to automate post-processing of your install exe file and insert the manifest resource. See specifically the Adding Application Manifest page for greater details:
http://www.heaventools.com/rtconsole-embed-manifest.htm
I want to put my dependent files in the app directory.
I seem to remember that you can force VB6 to use the files in the local directory only.
Any hints?
You may also want to try setting up Reg-Free COM for your project. There's a freeware called Unattended Make My Manifest that will do most of the work for you.
Placing component libraries in the EXE folder (with or without .local files) can be deleterious to the hygiene of target machines too.
VB6 programs will register the components here via the self-reg entrypoint behind your back if they are not previously registered. Then if the application is moved or removed you leave the user with a broken reigistration - possibly fatal to subsequently installed applications using some of the same components. This is probably fine though for application specific components, i.e. your own DLL or OCX that will never be needed by another application.
The .local trick was really not meant for use with VB6 programs and if it is used your installer needs to be aware and properly install and register the components if they are not already on the machine. It was meant as a manual hack to get around DLL version compatibility problems on individual machines, not a deployment strategy.
Move up to SxS application and assembly manifests (Reg-Free COM and more) for a better solution. DLL/COM Redirection (.local) was a good try but it has many warts.
Clay Nichol's answer about the search order is not quite correct. That search order only applies to non-COM components. I.e. only some DLLs, and not OCXs. If you register your COM objects, they will be used from the directory where they are registered regardless of what's in the local directory, unless you use reg-free COM or a .local file.
EDIT:
MakeMyManifest is well spoken of as an automatic tool for creating manifests for VB6 projects, haven't tried it myself.
DirectCOM also has fans, again I haven't tried it.
EDIT The MMM website is down. I see here that the author was having trouble with their hosting and has provided another location to get Make My Manifest - download it here.
There is a semi-automatic technique to generate reg-free COM manifests. You can create the manifests with Visual Studio 2008 (you can use a free version like Visual Basic Express Edition). Then make a couple of edits by hand to make the manifests suitable for use from VB6. See this section of this MSDN article for step-by-step instructions - ignore the rest of the article which is about ClickOnce.
It can be sort of confusing because every version of windows, the rules change. Older versions of Windows search the path before the current directory.
A simple solution without manifests:
If your executable file is A.EXE, add a (0-byte, empty) file in the same directory named A.EXE.local -- for older versions of Windows this puts the app directory ahead of the path in the search order.
Found it myself:
Windows does look in the App Directory first:
If SafeDllSearchMode is enabled, the search order is as follows:
The directory from which the application loaded.
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 current 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.
If SafeDllSearchMode is disabled, the search order is as follows:
1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. 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.
according to : http://msdn.microsoft.com/en-us/library/ms682586.aspx
But you can redirect where it looks for .dll's using a Manifest:
http://msdn.microsoft.com/en-us/library/aa375365(VS.85).aspx