I am just working on my bachelor thesis... It is a VST plugin (DLL library), which have dependency on libfftw3-3.dll (FFT library). When testing on my Laptop (64bit Win7 ultimate), i found a problem... I cant import this VST to any of Music Studios...
As on my PC, i have copied VST plugin dll and libfftw3-3.dll in the VstPlugins directory, but when i try to import this VST, system tells me that libfftw3-3.dll cannot be found.
This is not COM object, so i cant register it using regsvr32...
Can you please help me, what i am doing wrong? And how i can get this to work?
A VST is a COM component. It is loaded by the client program , the underlying call is CoCreateInstance(). The problem here is that Windows will only look in the directories that are relevant to the client program for the DLL you use. You surely didn't copy the DLL into the directory of the EXE, nor should you.
This is a generic problem with COM, solving it cleanly isn't easy. The Windows side-by-side cache is a solution but you'll graduate before you get that sorted out. You can punt the problem by modifying the system PATH environment variable. Or the desperate move, copying the DLL to c:\windows\system32 (syswow64 on the 64-bit version of Windows). Just to get you graduated, mind you.
If you still have trouble then you might have additional dependencies you don't know about. The CRT dll is a typical one, you'll get that when you compile your code with /MD in effect. You can chase those dependencies down with SysInternals' ProcMon utility, you'll see the client program searching for the DLL. Or DependencyWalker in Profile mode (F9).
Related
How do I install zlib?
I'm having a major headache trying to get zlib working on my computer. I need it for setting up a SFML Tiled map loader, but don't really have a clue what I'm meant to be doing.
I've read the brief documentation that came with the zlib DLL download, and have put the zlib1.dll in my System32 folder, but the test programs that came included with the download keep giving me "The program can't start because zlib1.dll is missing from your computer. try reinstalling the program to fix this problem." errors.
I think I've set it up right in Visual Studio 2012 as I get no compiling errors, just that error when I try to run the program.
They work fine when I copy the .dll into the same folder as the .exe. Why does what I read about installing zlib tell me to put the dll in System or System32? What is the System32 folder even for?
Will I have to pack the .dll in with any programs that I make? Can zlib be statically linked into my program?
I had a look around before asking but all other questions I found were too specific to be useful for me. D=
I've written a Windows program using the C API of Tcl/Tk to create a nice GUI. I've installed ActiveState ActiveTcl for the dependencies and everything compiles and runs fine. Compiling required me to link against the import libraries provided by ActiveTcl.
Now that i want to distribute this program i have to make a choice on how to handle the dependency on ActiveTcl. One option is to require ActiveTcl be installed before my program, while another is to just distribute the ActiveTcl DLL's that my program actually uses.
If i view my program using a Dependency Walker i can see that three ActiveTcl DLL's are used. tcl86.dll, tk86.dll and zlib1.dll. So then i tried to move the DLL's.
If i moved these DLL's to the C:\Windows folder or to the program's folder, the program no longer functions. After moving the DLL's and viewing the program in the dependency walker, i can see the DLL's are being found in these alternative locations but the program refuses to start. I don't even get an error.
Do any of you guys know why this might be the case? That the only time my program runs is if the DLL's are located in the installation directory of ActiveTcl (C:\Tcl\bin).
The DDL's had dependencies of other files that should exist in the same folder.
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?
I have a VB6 app that utilizes a non-activeX DLL (non-registering).
It's declared via the classic Public Declare Function "Function Name" Lib "Library.DLL" syntax.
On my dev machine (XP) it works fine but when I deploy to Vista or Win7 I'm constantly greeted with a Run Time Error 48 - File Not Found for the DLL in question.
I have tried copying that DLL to every directory I can think of including every environment path on the test machine and the app path too.
These are all 32-bit test environments so it's not a SysWow64 issue.
Possibly throwing a wrench into the mix is the fact that the application in question is an Outlook COM Addin.
I managed to install VB6 on Win7 and was able to run a tiny sample app that utilizes this DLL (outside of the Outlook process) so I know it works PROVIDED the DLL is located in App path. If I call App.Path from my DLL when I run it on the test environment it shows, to no surprise, my installation directory however the DLL is there.
I tried turning off UAC. I tried making the App.Path directory permissions open to everyone, still no dice.
According to the details you give, it looks like placing the DLL in the path of standard Add-in locations would help.
I believe the first place a DLL search looks is the directory that the EXE loaded from, so your DLL's App.Path won't be used.
Are you sure that you tried installing this DLL into System32? Into Windows?
Aside from that you should be ble to create a PATH (messy) or an isolation manifest for the calling code (VB6 if I'm following you) that specifies DLL Redirection to a relative path (i.e. a subfolder under the folder with your VB6 code in it).
See Dynamic-Link Library Search Order
You may want to check the DLL's own dependancies. You will get the same error if it couldn't load the DLL in question or some DLL 20 levels deep in the dependancy chain.
I have a mex64 dll compiled on my machine. I used Matlab 2009b with VS2008 Pro to compile the dll. The dll works fine on my Matlab installation.
I want a colleague to use the dll so I sent it to him and he gets the following error message when trying to use the dll:
??? Invalid MEX-file 'filename.mexw64': The specified module could not be found.
My current assumption is that this is caused because he uses an older Matlab version or missing a dll that I have. I ran dependency checker and asked him to check that he has all the listed dlls.
I am still waiting for him to confirm his Matlab version.
What other reasons can cause this and can the Matlab version make a difference? (I mean R2009a when I have R2009B and not a huge version diff)
The other person has Matlab R2009a. Shouldn't the mex just work if I compile it on my computer and deliver it to him?
Does this only leave a missing dependent dll?
The issue is strange, but I can confirm it exists.
Using pre-built libraries for matlab that are correctly installed and in the path, I sometimes get the same error. If I type in the function name at the command-line, the function is visible and will auto-complete. However, the function will not initialize until I 'cd' into the directory with the .mexw64 library file.
>> AndorInitialize('')
Invalid MEX-file 'C:\Program
Files\MATLAB\R2011b\toolbox\andor\AndorInitialize.mexw64': The
specified module could not be found.
>> path
MATLABPATH
C:\Program Files\MATLAB\R2011b\toolbox\andor
C:\Program Files\MATLAB\R2011b\toolbox\andor\camera files
C:\Program Files\MATLAB\R2011b\toolbox\andor\m files
... etc
It turns out this is due to missing dependencies, which shouldn't be missing. To resolve the issue, use dependency walker (free, lightweight) to identify what's missing. The mathworks explains this.
http://www.mathworks.com/support/solutions/en/data/1-2RQL4L/
In my case, two DLL's weren't showing up properly, even though they were on my system and in the path. I copied the DLL's into the windows/system32 folder and the library functions now work correctly. What's particularly strange is that the same library worked on my computer a few days ago (prior to the moving the DLL's).
In general, MEX files should work across different versions of Matlab; in particular, they should be forward-compatible. You're right; sounds like a dll problem.
If you built it with Visual Studio, it may be linked to the Visual C++ Runtime. This is a set of libraries that is not installed on Windows by default. The "redistributable" for it can be downloaded here; having your coworker install that could resolve the problem. If that doesn't work, you can use Dependency Walker to check for other unsatisfied DLL dependencies.
Normally, configuring Matlab's "mex -setup" to use the Lcc compiler that's distributed with Matlab could be a way around this, but it's not supported for 64-bit Windows AFAIK.
Also, are you sure he has the 64-bit version of Windows?
Another possible source of the problem could be that you compiled in debug mode. The Visual C++ redistributables only support release mode.
The Dll was a wrapper for MySql access. We ended up using Matlab's ODBC and the MySql Connector.