Specify delay loading dll with #pragma in the cpp file - c++

I have a static-linked library which uses some functions from a dll which i need to delay-load. So in my executable's properties i've added this dll under Linker/Input/Delay Loaded DLLs. I can't add this option in the lib itself since it doesn't have the Linker property pages (because it's a static lib)
So now whenever i use this lib in another executable tool i need to add the delay-loading option over and over again, which i want to avoid. I know there used to be a pragma for this
#pragma comment(linker, "/DELAYLOAD:mydll.dll")
However it doesn't work for me because it says
warning LNK4229: invalid directive '/DELAYLOAD:mydll.dll' encountered; ignored
Is there a way out, other than LoadLibrary?

Did some research on google (guess as you) as I am alway interested in such matters. The obviously link is:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/807606af-f7d7-4d9b-a9f3-062b23fddb2b/using-the-delayload-linker-switch-with-a-custom-dll
Unfortunately it is from 2004, that' nine years and some VS versions before.
But it get worser, I found also this:
http://bytes.com/topic/net/answers/280580-delayload-pragma-fixed-whidbey
which is a year late and sounds very plausible:
No, this never worked reliably. It was a bug to allow it in 6.0. One
that we fixed later by adding the warning.
Ronald Laeremans
Visual C++ team
I knew, beside your three suggestions no additional, other way.

Related

How to get wxWidgets working in Visual Studio 2012

I've got a problem for which I would very much like a solution please:
All I'm trying to do is use wxWidgets in Visual Studio 2012 (in C++), and make it accessible to my code project. That shouldn't be so hard, should it? But as usual, even though there are programming tutorials for it, wxWidgets is evidently one of those things that has no proper documentation just to simply get it running, or if it does then I sure can't find it.
I downloaded the installer for Windows and installed it. When it finished, it gave me a message that said:
wxWidgets was installed successfully!
Please note: before using wxWidgets in your application,
you must build the library using the same compiler you
use for building your program.
Please see docs/msw/install.md file in the installation
directory for the detailed instructions about how to build
wxWidgets and use it from your application.
It should be noted that I think I remember something on the website or somewhere saying that I can just include a header file into my project and forego the DLL altogether (which is what I'd prefer to do, if possible), though I may possibly be misremembering that or confusing it with something else.
Anyway, when I opened the docs/msw/install.md file, I found (amongst other things) these instructions:
--- From the IDE
Ready to use project files are provided for VC++ versions 8, 9,
10, 11, 12, 14, 15, 16 and 17 (also known as MSVS 2005, 2008, 2010, 2012,
2013, 2015, 2017, 2019 and 2022 respectively).
Simply open wx_vcN.sln (for N=8, 9, 10, 11, 12, 14, 15, 16 or 17) file,
select the appropriate configuration (Debug or Release, static or DLL)
and build the solution. Notice that when building a DLL configuration,
you may need to perform the build several times because the projects
are not always built in the correct order, and this may result in link
errors. Simply do the build again, up to 3 times, to fix this.
Of course, it doesn't even say WHERE the "wx_vcN.sln" files are, but I ran a file search and found them in C:\wxWidgets-3.1.6\build\msw and I opened the one called wx_vc11.sln, because that seems to be the one that corresponds to VS2012, right?
Anyway, it took a LONG time to load, because it had to keep scanning through thousands of files and so forth, but when it was finally finished, I did the "Rebuild All" command thrice in a row, like it says to do (which also took a while).
But I'm not sure where it even put the actual DLL file. It says that it's in C:\wxWidgets-3.1.6\build\msw....\lib\vc_lib\wxmsw31ud_xrc.lib, but where the hell is "...."? It doesn't even bother to specify the entire path! What kind of nonsense is that?! I just want the file so that I can put it into my project! Or better yet, just a .h file that takes care of everything would be great. Supposedly there's one to include called "wx/wx.h", which then includes everything else, I think, but I don't know if that one indirectly also requires a DLL.
I always have problems with DLLs, anyway, though I'll use one if I absolutely have to. You'd think it would be the easiest thing to import a DLL into a project, but for some reason, I've never been able to find any sort of tutorial that explains a specific, step-by-step way to do it which is guaranteed to work, so on the rare occasion that I actually need to use a DLL (99% of the time I can just rely on my own code and the .h files included with Visual Studio), I always end up muddling through it until it FINALLY works by sheer accident (if I'm lucky). Mostly, it just reports errors for one reason or another, that it's not properly included or compatible, or that the header files that I'm using which reference it keep showing the same errors, as though I hadn't even imported the DLL file at all! I've been programming for about 30 years, and I work on things like AI and compression and cryptographic algorithms. I don't say this to brag, but to point out that if someone as experienced as me has trouble getting a DLL to attach properly to a roject, then there's something severely wrong with the whole process, or the documentation for it! I HATE using DLLS, because it's always a HUGE chore, but I'll do it if there's absolutely no other way (though I'd appreciate step-by-step instructions, if you don't mind).
But enough about that. In any case, I have an example project in which wxWidgets is being used in conjunction with Vulkan, and though it has compilation errors (because Vulkan didn't properly install on my machine (when I try to run the sample programs it says they're missing DLLs - big surprise) and as it turns out, I don't think it's compatible with my video card, anyway (which might possibly be why it didn't install properly), so I think I'll have to resort to OpenGL instead - PLEASE tell me that's compatible with wxWidgets!), but even in that example project, it has errors where it's trying to include and use wxWidgets stuff (like "wx/wx.h"), even though that's supposed to be a complete and already working project! I can't find any DLL files or the header files in question anywhere in the project directories!
So anyway, there's got to be an easier way to get this all set up, just to the point that I can make a simple test program using wxWidgets, and compile it. I'd REALLY like to be able to get at least that much working sometime tomorrow morning, so I'd greatly appreciate any help you can give me! Thank you.
#ThisIsMe,
First of all you need to educate yourself on properly using C++.
When you acquire the C++ code it contains of 2 portion - header file and source code.
Header file is what you call a declaration you declare you classes there - class name, member variable and method.
In the source files You define what you declared and you put an actual code there.
Now with that in mind:
wxWidgets contains both header and source files. When you downloaded the installer and did the installation it just copied the "text file" (headers and sources) into the folder of you choice.
Now as you can imagine text files are not executable - you need to compile them into the binary files And that is exactly what you did. (I don't know why you did it 3 times though - I guess you got an errors after building 1st and 2nd time).
Now, you said you have a project that (either uses wxWidgets or you want to incorporate wxWidgets into - which one is it, BTW?). The answer to this question will help direct you to a proper solution.
Now, you said that you tried the Vulkan and it fails to run the demo. How did it fails? Did it produce an error? What was it? Did it even run?
Now wxWidgets does support OpenGL as can be seen by looking at the documentation and checking the different samples that comes with the library, but I'm just curious if what you are seeing from Vulkan is really an incompatibility with the Video Card.
So, we need you to answer the questions I put and so we can help you further. Just keep in mind - C++ is not for the beginner programmers and if you are struggling with understanding the difference between compilation, installation , headers and sources - it will be very hard for you.
Maybe you should start with something simpler - like wxPython and forget about C++ for now.

VS 2017 C++ static lib compiled with /MD project dependency issue

I'm a unix backend dev that has a small roll in maintaining a visual studio project. The vast majority of my code runs on Linux, with a small Windows footprint. There is a proprietary project-specific rule in play here that states all system dependencies must be dynamically linked, but all other dependencies not already installed on the systems, which I thankfully don't control, must be static. In other words, I can use boost, poco, mysql++, zeromq, etc, but those have to be linked statically. I also can't create my own DLLs. My Linux brain is guessing that rule is my Windows problem.
I have a large static library as part of the projects with lots of common code linked into other programs. That static library is compiled /MD, which appears to be what I have to do on Windows to dynamically link system libraries. However, I need that library linked into other programs statically. When I add a reference to the library in VS 2017 to other projects, nothing happens and the symbols aren't resolved and I get lots of link errors. To fix that, I hard-coded my library into the various other projects via Linker->Input->Additional Dependencies and that "works" after a fashion, the code links and runs but VS doesn't resolve the static library dependency. While I can go forward with this solution, it's hardly ideal. Rebuilding the solution always results in failure (or links in old code into a new build) because the big static library always takes the longest and none of the other projects know to wait for that build to complete. The workaround is to build the static library first, then build the entire project.
Does anyone better versed in Visual Studio know the best way to proceed?
Can someone help me understand why this got down-voted? This isn't a troll and I'm hardly a student trying to get someone to do my homework, it's a real problem I'm trying to figure out in a professional setting. I thought that was the whole point to stackoverflow?
So this was something simple. When I went to add the reference I didn't actually click on the check box. Robert Andrzejuk's second comment helped, I had read that before but didn't notice the little check box the first time.
On the add a reference page (right click project in solution browser, Add->References...), the check box next to the item has to be selected.
Add reference widget

Setting up files to compile on any computer in Visual Studio

Question:
Once my code is working how should I prepare my files so that a stranger on a different computer can compile it without difficulty?
Additional Details:
I am sending a code sample to a company as part of an application so obviously an elegant solution would be better (i.e. minimise number of files required etc) and no work should be necessary by the stranger at the other end.
Although I am only using one simple library, even so I need to set include directories, include lib files, images, dll files etc so that it all compiles correctly.
If it matters, I am using Visual Studio 2015 and the simple library is SDL.
Sorry if this is a duplicate, I was sure that this question would have been asked before but if it exists I just don't know the correct terminology to find it amongst the noise.
Apologies if this is overly simplistic, but you might want to bound the scope of your project by deciding which computers you want to support, and build your code yourself on those platforms, in advance, just to be sure.
List the supported platforms in your release notes, including any platform-specific instructions or information (which VC++ versions, which C++ versions, which OS versions, which DLLs, directory structure, etc.).
You may have to stick some "#ifdef"s and such in your code, but only by building on a particular platform/configuration will you really know for sure.
You can use properties/props files in your VS solution which sets the paths to includes and precompiled libs, then reference the build variables in your project files.
To compile on another machine, you just need to change the values in the properties files.

Why can't a "procedure entry point could not be located in dll" when I definitely put it in?

I have a really vague problem, but I hope someone can help with it. I was modifying a C++ project and yesterday it was still working, but today it's not. I'm pretty sure I didn't change anything, but to be completely sure I checked the project out from SVN again and I even reverted to a previous system restore point (because this is a work computer, it sometimes secretly installs updates etc.). After succesfully compiling it, the program can start up, but after I interact with it, I get this error:
The procedure entry point ?methodName#className##UAEXXZ could not be located in the dynamic link library libName.dll.
I've searched the internet, but most people's problems seem to be caused by an older version of the DLL being used. I searched my computer and there is no older version. If I delete the correct version, the application doesn't start. If I then recompile the project, the DLL is created again, so I'm both pretty sure that the application is using the correct DLL and that the compilation is creating it. If I introduce syntax errors into the method that the error refers to, the project refuses to compile, so I guess this means that it is also compiling the files that contain the method.
Basically I don't know anything about DLL's, linking, etc. so I would greatly appreciate it if anybody has an idea as to why the functions that are very clearly defined in the project are all of a sudden not making it into the DLL anymore. I know this is vague and if any more information is required I will gladly provide it. Thanks!
Update: I have tried the given suggestions, but I'm still stuck. __declspec(dllexport) is apparently not used in the entire project. Opening the DLL with Dependency Walker shows me an empty top right section and the section below it lists the function from the error message. If I check Undecorate C++ Functions it looks fine, but if I don't I get the weird question marks and #s from the error message and there appears to be a difference at the end:
?methodName#className##UAEXXZ
?methodName#className##UAEXH#Z
Perhaps this is the problem, but I have no idea what it means, what may have caused this and what I can do about it.
Are you actually using __declspec(dllexport)? My guess is no -- without that declaration, that function will not be exported by the DLL (or in other words, programs loading that DLL will not have access to functions without that declaration).
Also, try using Dependency Walker to see exactly which functions your DLL has made available.
The fact that __declspec(dllexport) isn't used in function declarations is okay -- most of the time, it will only be used once in a single header file, like
#ifdef MAKING_DLL
#define FOO_API __declspec(dllexport)
#else
#define FOO_API
#endif
So that if you have #define MAKING_DLL before that section, all functions that are declared like FOO_API int BakeACake() will be exported based on whether MAKING_DLL was defined. It's possible that the project was expecting MAKING_DLL (or its equivalent) to be defined on the command line, depending on the project type built (something like /DMAKING_DLL; or you might even need to define FOO_API yourself like /DFOO_API=__declspec(dllexport).
The empty top right section in Dependency Walker just means your program isn't linking against the DLL's corresponding .lib file. That's okay, it just means you are using LoadLibrary or LoadLibraryEx to access functions in the DLL.
Another fairly likely scenario (based on the fact that the mangled names are different) is that the program was built using a different version of Visual Studio than 2008, which you used to build the DLL. Unlike plain C, there's no standard binary interface for C++, which means that you have to use the same compiler to build the program and the DLL when you are using C++ classes in the DLL. If you can, try rebuilding the program in VS2008, or try rebuilding the DLL in the same version of VS as the program was built.
Download dependency walker and open your dll using this tool. It will show a list of exported functions from your dll. Check whether the above said method is part of the expected functions. If it's not, then it means you accidentally removed __declspec(dllexport) for one of the classes in that dll.
I feel a bit stupid, but I found the answer. The application (exe) I was using apparently loaded a second, different dll which had a dependency on the one mentioned in my original post. This second dll was still expecting the old functions and also needed to be recompiled against the updated dll.
Many thanks to the people who tried to help me here!
Using information of the posts above I found simple general solution. All you need to do is open programs executable with dependency walker, look for the missing functions, look what dll's are using it, find the project which builds that dll and rebuild it.

creating a DLL in Visual Studio 2005

I am developing a C++ library that I want to pass on to my team. The library has just one class with a bunch of methods.
So, I have developed the class definition file (X.cpp) and a corresponding class declaration file (X.h).
Here are my questions --
In Visual Studio 2005, whats is the most straight forward way to build this library as a DLL, such that I get the following files:
X.lib : which I can pass to my team so they can link against my library
X.dll : which I can pass to my team for run-time
Instead of a DLL, should I rather be going the static library way ?? If so, how do I go about doing this in Visual Studio 2005 & will this give me a X.lib file that I can pass on to my team ?
Any explanations or references are very welcome.
Thank you very much.
The easiest way to build a DLL, is New->Project->Win32 Console Application. Then on the dialog select DLL and select "Exports Symbols". This will synthesize a dll with a .h, and .cpp file which demonstrate how to export your classes. You can get rid of this .h/.cpp but first import your class add the appropriate #ifndef statements. Now as far as DLL versus Static library if its a single small class, that doesn't change particularly often you might be better off with a static library, its simple, its concise, it doesn't add another dependency which needs to be shipped with your product. A DLL is nice if the code in the .cpp file changes often (ie. the function implementations) because you can just swap in the new DLL.
From your description, it looks like you already have a Visual C++ project (correct me if I'm wrong). If so, when you go into project properties, under "General" you can find "Configuration Type" - switch it to "Static library" or "Dynamic library" as needed.
If you choose "Static library", then you will just get a .lib file that can be immediately used.
If you choose "Dynamic library", and you export any functions from your DLL (e.g. by marking them with __declspec(dllexport)), an export .lib will be generated automatically.
It's hard to tell which option is preferable without knowing the specifics of what you're doing. In general, I'd recommend defaulting to static libraries, because it's usually good enough, and there are more traps when dealing with DLLs (especially ones that export C++ symbols).
I think that, in most cases, a dll is a better choice than a static lib because your team will not have to recompile their code when you distribute a new version of your library.
I struggle with this too sometimes.. because I can't find where the elusive setting is within C++ Project Properties.. So I decided to jot it down for my own sanity as a blog post.
HTH