Currently my DLL requires that mfc80u.dll and msvcr80.dll reside in the same directory when I want to use it from a different application.
I think there is a switch in VS2013 that somehow compiles the DLL in such a way that these files are no longer required.
I am pretty sure I have once read about it.
This makes the DLL much bigger, that to me that's worth it.
Does anybody know which switch that is?
Thank you!
To remove VC runtime DLLs (not specific to MFC), use the /MT compiler switch.
If you are using MFC, you must also use Use MFC in Static Library in General page of project settings.
Related
I have a VS2017 MFC C++ application which uses a ribbon based UI. Up until now I have been using the statically linked MFC libraries but now have to move to MFC in a DLL as I need Multithreaded DLL linkage /MD in order to support another third party SDK (Vulkan). One of the reasons for using statically linked MFC is that it allowed me overcome some problems in the implementation simply by including the source for the item I needed to change in my application. e.g. to use data the edit part of a combo box to select the nearest item in the drop down. This doesn't work when I use the DLL version of MFC for obvious reasons, is there any way around this? I can't simply inherit from MFC base classes as my application is building the ribbon interface from a ribbon resource file and there don't seem to be any hooks to customise this behaviour.
My current thoughts for possibilities include building my own version of the MFC DLLs or simply adding the full MFC source as a sub-project and change my main project Use of MFC to Use Standard Windows Libraries. Both of these seem like nasty hacks.
Edit: In response to the comment below from IInspectable, I'm not entirely sure why the current behaviour doesn't work but have some ideas. Linking the static lib version of the code, if I include my own copy of a function that occurs in the lib, the lib version never gets called (possibly never even gets linked). When linking the DLL version of MFC, my modified function never gets called. This could be because it is called by another function in the same DLL which never sees my code or it has a slightly different decorated name. My thinking is that including all the MFC source in my app and not linking any MFC in the compiler options is one brute force solution, though a pretty horrible one.
I ended up recompiling a custom version of the MFC DLL based on this project, https://www.codeproject.com/Tips/5263509/Compile-MFC-Sources-with-Visual-Studio-2019 This lets me keep my MFC modifications while also using MFC in a DLL with minimal changes to my existing project
I have created a simple application in Qt5 but, when run that application in for example windows 7, tells me the dll file something is missing, and another dll and another dll.
Now I want a package that contain all dll files that any Qt application needed.
Or, What's the Important dll files that needed to work any Qt application ?
Or, What's the Important dll files that needed to work any Qt application ?
In general, the Qt modules that you are using. If you use QtSql, you need to have the corresponding dll, but it goes the same way for any module. As for a simple core application, you would need to have the QtCore dll, respectively. I could continue the enumeration, but I believe you see the pattern how it goes.
Going even a bit further, you would need to specify your dependencies in the LIBS variable if you happen to use qmake. That is also a place where you would already need to be aware of your direct dependencies.
It would be usually the single library name, but in complex cases, you can always read the documentation of the project. The main point is the fact that you need to get aware of this without debugging. The latter would be more like an after-thought.
There are no "hidden dependencies". Since you are coding the project, you know the dependencies that you use. You will need to ship them.
There are some odd and rare cases when issues come that you would not be aware of, like missing dll for a different machine having a distinct VS/MSVC setup. In that case, it is better not to ship all the dlls for each possible end machine, but the end machine is supposed to install redistributable packages.
In rare cases when the above does not suffice, you can check the error message. If that is still unclear, you can use introspection tools for debugging the issue, like dependency walker.
Disclaimer: this answer goes as broad as the question is.
I've been making a program in Visual Studio 2012, what comes with it is that when I send my application to someone, they need the VS2012 Runtime, which sometimes they don't know where to download or what they need (for normal users "xxx.dll is missing" is very misleading).
I know exactly which dependencies my application requires (fantom.dll [Lego Mindstorms stuff] and the VC++ 2012 Redist).
I would like to show a dialog when these libraries are missing on application startup and provide the user with download links for these libraries.
Is this possible to accomplish?
Yeah you could do something like:
Move all of the code in your binary into a DLL.
Create an EXE which dynamically loads the DLL using LoadLibrary and unloads it with FreeLibrary.
If LoadLibrary fails, check if its due to missing DLLs, if so then display a MessageBox/your custom message and exit.
Of course this means your EXE project must NOT depend on the runtime itself - this shouldn't be an issue since you'll only need to call 3 win32 API's.
No it's not possible but you can create an installer for your program. The error is thrown during the loading of your program, before your code execution...
You can try with that : http://www.codeproject.com/Articles/24187/Creating-an-Installer
I can't speak for testing the VS2012 Runtime dynamically, but you can certainly validate fantom.dll dynamically. Instead of static-linking to the DLL directly, you can dynamically load it instead. You can configure your project to delay-load the DLL at run-time, and then provide a delay-load callback handler that the RTL will call if the delay-load fails. Or you can simply skip the delay-load feature and load the DLL yourself manually by calling LoadLibrary() and GetProcAddress() directly.
Sure, you can verify if a dependency exists on the deployed system. A few things come to mind...
You can see if the assembly is recognized on the running system by calling AppDomain.AssemblyResolve() . Further reading here
Another more primitive option is to call a File.Exists(your assembly path here) test, but I would advise against this as it's a bad practice to require hard-pathed installation locations.
That said, and as others have stated, it's still by far the best approach to create yourself an installation distribution.
My basic issue is this: my program (MyProgram.exe) has a dependency on a DLL from another program (OtherProgram), and I'm trying to avoid repackaging a new DLL every time OtherProgram updates. I'd like to have MyProgram.exe link in OtherProgram's DLL when it launches, but I'm not completely sure that Windows allows for this. So if there is some kind of workaround that would also be acceptable.
And just for some background, the platform is Windows 7 x64, and MyProgram.exe runs fine when I create a symlink in the MyProgram.exe project directory to the DLL in OtherProgram's install directory. When I try to run it without the symlink, I get the "program can't start because OtherProgramDLL.dll is missing from your computer" error.
Any advice or links to relevant info is greatly appreciated!
EDIT: Clarification: the DLL is not linked at compile-time, this issue crops up at runtime
There are two types of dynamic linking in the Windows world:
Load-Time linking is when a DLL is loaded automatically when your program starts up. Windows finds this DLL using a specific algorithm I'll discuss below.
Run-Time linking is when you specifically load a DLL by calling LoadLibrary in your code. Similar rules apply as to how the library is found, but you can specify a fully-qualified or relatively-qualified path to control the search.
In the case of Load-Time linking, MS recommends that your program's DLLs are stored in and loaded from the same directory where your application is loaded from. If this is at all workable, this is probably your best option.
If that doesn't work, there are several other options, outlined here. One is to leverage the search order by putting the DLL in either the working directory or the directory where the application was loaded from.
You can change the working directory of an application by:
Create a shortcut to your application.
Bring up the shortcut's properties
Edit the "Start in" property with the directory where the DLL is located.
When you launch your application using the shortcut, it will load the right DLL.
Other options for load-time linking include:
Adding a manifest to your application which specifies where your dependent assemblies are, or,
Setting the PATH.
You could use LoadLibrary, but you would need a way to guarantee the DLL's location. This Wikipedia article provides good example on how to use the DLL after it has been loaded.
You can add the directory where the dll is located to the PATH environment variable.
I have struggled with the same problem and also found a dead end with the suggested methods like LoadLibrary, SetDllDirectory, Qt's addLibraryPath and others. Regardless of what I tried, the problem still remained that the application checked the libraries (and didn't find them) before actually running the code, so any code solution was bound to fail.
I almost got desperate, but then discovered an extremely easy approach which might also be helpful in cases like yours: Use a batch file! (or a similar loader before the actual application)
A Windows batch file for such a purpose could look like this:
#echo off
PATH=%PATH%;<PATH_TO_YOUR_LIB>
<PATH_TO_YOUR_APP_EXE>
/edit: Just saw #SirDarius comment in Luchian's answer which describes that way, so just take my batch code bit as a reference and all credits go to him.
I have the same problem with one application I am working on.
I do not want to use runtime loading because there are tens of functions I would need to manually create function pointer for.
Mr Dibling's mention of manifest file opened a new door for me but I sadly found out that the oldest version of windows that supports the feature is Windows 7. It won't even work on Vista.
Long story short, a friend familiar with Windows Application development told me to look up Delay-Loaded DLL, which turns out to solve the problem perfectly with minimal effort. It delays the loading of DLL library to either the point you manually do, or the first time its function is called. So you just need to add your DLL path to the search path before that happens, where SetDllDirectory helps.
Here is the steps to make it work:
1) Specify the DLL to be delay-loaded to linker, either through your makefile, cmake or VS property page (Linker->Input of VS2015)
2) Call SetDllDirectory at the beginning of your program, before any call to the DLL is made.
Delay-loaded DLL is supported all the way back to VC6.
SetDllDirectory is supported after XP SP1.
Use Symbolic Links to the 3rd Party Executables
I found the approach advocated by Aaron Margosis useful. See:
Using NTFS Junctions to Fix Application Compatibility Issues on 64-bit Editions of Windows
Essentially, create symbolic links to each of the dependent 3rd Party executables. Place these symbolic link files in and amongst your own dependent executable files. Except for filename changes to the targets, the 'soft' symbolic links will resolve the load-time dependencies even as the target of the links are changed by future updates.
I'm teaching myself OpenGL and I'm implementing ttf text rendering using FreeType 2. I downloaded the library from
http://gnuwin32.sourceforge.net/packages/freetype.htm
and after a couple of minor issues I got it running properly. The thing that's bothering me is that I have to place a copy of freetype6.dll in the directory with my executable in order for the thing to run. I generally try to avoid a bunch of unnecessary dll files floating around. I'm sort of new to windows programming, but from what I understand most libraries can be built to run fully from a lib rather than requiring a dll at runtime. Looking through the documentation from FT is making my brain melt, so I thought I would ask here to see if there were any devs that have worked with FT before and if so, do they know how to build the library such that no dll is required at runtime.
Thank you in advance for any advice or support.
Check out this link. See the section Optional: Installing FreeType (by compiling it yourself)
Follow the instructions and you'll be good to go.
you can generate static lib by getting source code of it... then you won't need dll...and i think freetype2's source is available...
It is something DLL generic. All your DLLs should be in PATH similarly to LD_LIBRARY_PATH. Also under Windows (unlike Unix) the current directory is always in the PATH. So you just need to set your PATH variable to point to location of this dll.
Now, for Unix... you probably just have this library installed by default like hundreds of other useful libraries that are not present under Windows by default.
So... No unless you link statically you should use DLL somehow. And my suggestion - use dll.