Under Visual C++ 2017, I have a on a side a project DLL, with the core GLFW 3.2.1 routines (like glfwInit(), glfwWindowShouldClose(), glfwTerminate()...). Theses methods are encapsulated in a static class named RenderLoop. It uses GLAD and GLM too.
On the other side I have an EXE project application which calls the RenderLoop methods, in the same solution.
Everything works fine, I launch the exe, the window is created, the loop is running etc...
Yet I try to call within my EXE some gl function (like glGenVertexArrays), after Initialization. I can't get rid of Access Violation Exception.
If I put this gl function in the DLL, everything works fine. If I put it in the EXE, it crashes. Is there a "trick" to share OpenGL between the DLL and EXE ?
As suggested Robinson, I added a call to gladLoadGLLoader in the dll after Initialization
Related
My application store some data in data only dll files. Those dll files are loaded with LoadLibrary() when needed at runtime and then discarded with FreeLibrary() after finish using them. The main application access the data stored in the dll files using GetProcAddress(). The program is written in C++ and uses WinAPI calls, no MFC or other libraries. It has two versions x64 and x86. It works fine on most systems. My dll files do not call other libraries or depend on anything else. Each is a stand alone file.
Recently, I discovered the program does not work on one machine. this specific one has Windows 10 x64 installed on it. After investigations I found the following:
LoadLibrary() fails with error message "Could not find module". The dll is in same directory with main program.
I replaced the call to LoadLibrary() with LoadLibraryEx() and tried the following falgs:
LOAD_IGNORE_CODE_AUTHZ_LEVEL did not work. The dll could not be loaded.
DONT_RESOLVE_DLL_REFERENCES ... works?? But, Microsoft strongly recommends not to use it.
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ... loading the dll succeeds?? But, the call to GetProcessAddress later fails. the program could not access the data in the dll file. So this is not actually working.
I could not find anything wrong with this machine. All other programs are working fine.
I tried the x86 version on this machine and it worked fine using original LoadLibrary().
My installer is dual system and automatically installs x64 version when it finds x64 windows. Normal user can not simply switch to x86 when he gets such error.
My question is how can I eliminate this error and make my program works on any machine:
Should I call LoadLibraryEx() using DONT_RESOLVE_DLL_REFERENCES flag and ignore Microsoft warning?
Is there any way I can get my library loaded with simple call to LoadLibrary()?
If I call LoadLibraryEx() with LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE flag, as recommended by Microsoft, how can I access the data without calling GetProcessAddress()?
Thank you in advance.
I am new to DLL development and appreciated for any help.
I have an existing c++ project and am trying to build it into dll using visual studio 2012. I changed the target extension and configuration type to be dll. I also excluded my main function. When I rebuilt it, the compiler complains:
LINK : fatal error LNK1561: entry point must be defined
When I moved the main function back, I could build the project successfully.
I want to make a dll only because there are functions and objects I need to use for another project, so i don't think I need a main function for the dll. Is having a main function the only solution for this error? Thank you in advance.
Just like a program requires main, DLLs require DllMain, a place to start and handle loading and unloading of the DLL.
Rather than a DLL consider a static library. There is far less overhead, no DllMain and supporting loaders and unloaders, and they are built directly into the compiled executable so you don't have to carry an extra file around and run the risk of clients with out of date DLLs or some malicious tool replacing your DLL with theirs. If you don't need the ability to swap out the the library with a replacement, a DLL is probably overkill.
I am working on an AIR Native Extension (ANE) for Windows desktop. The point of this extension is to be able to call out to a third-party C library, which consists of two .h files defining the method signatures/typedefs, and a .lib file.
Before including the third party library in the project, I first confirmed that I set up everything correctly by building the ANE with a simple "sayHello" function in the dll that just creates and returns a string.
Having verified that I can call sayHello from my AIR application and get a response, I proceeded to add a function that initializes the third-party library. This is where things went sideways. My dll compiles just fine, and I'm able to package the ANE without error, but when I try to call any ANE function from AIR, I get the following error:
"The extension context does not have a method with the name..."
In AIR, the call to createExtensionContext() succeeds and returns an ExtensionContext object, but I'm not able to call any native functions. What's more, Visual Studio's debugger no longer loads symbols for my dll - the dll does not appear in the modules window and I cannot set breakpoints in the native code.
If I comment out the line where I call the third-party library's initialize function, then everything works fine again - I can call all my functions and hit breakpoints in Visual Studio.
So basically, it appears that If I compile this library into my dll, then AIR will fail to load it. What could cause this?
Using ProcessMonitor, I found that the the third-party library has a dependency on an external dll, which it was not finding. At the time the ExtensionContext is created, the runtime apparently attempts to resolve the dependencies of the ANE. Since it could not find this dll, the ANE's initializer function was failing. AIR still creates an ExtensionContext object in this situation, but since it is never successfully initialized, it does not know the names and locations of its functions.
I'm using Visual Studio 2010 to create a 32-bit DLL as a plug-in to a 3rd party app (AviSynth). The DLL was being correctly loaded by the 3rd party app until I tried to use the FFTW (http://fftw.org) DLL. I took the 32-bit FFTW DLL, ran "lib /def:libfftw3-3.def" to create a .lib file, added that as a resource in the project. Made some calls to the functions. It compiles fine, but when I try to load it in the third party tool, it fails.
I've tried putting the FFTW DLL alongside my DLL, and I've also tried using LoadLibrary from inside my DllMain, but it's still not working.
I am able to stop the debugger in the DllMain function and in the function called by AviSynth (AvisynthPluginInit2), but AviSynth claims to be unable to load the DLL after that, and breakpoints at the tops of functions that were called before are no longer hit.
The AviSynth error message is:
LoadPlugin: unable to load "C:\Program Files (x86)\AviSynth 2.5\plugins\xxxMYPLUGINxxx.dll"
Thanks for your help.
The first thing I try when I get something like this is Dependency Walker:
http://www.dependencywalker.com/
It won't catch every possible problem, but it's very quick to check for simple problems (missing DLLs, missing exports). You can also set it to open any number of file-extensions by double-clicking them. I usually set .dll, .ax, .ocx, .sys, .exe.
IMO one of the essential tools for any Windows developer.
ps: if Dependency Walker doesn't find any problems, try to load your DLL with LoadLibrary() and see what GetLastError() returns.
BTW:
and I've also tried using LoadLibrary from inside my DllMain, but it's still not working.
You cannot call LoadLibrary() from DllMain().
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order.
(The entry-point function is your DllMain)
Turns out that the FFTW DLL had to be in the same directory as the AVS script, not the AVISynth plugin directory. I guess that's the working directory for Virtual Dub.
Anyway, it works now. Thanks for the help!
I want to use GLEW with Qt under Windows (7 if that matters).
What I did was go to the GLEW website, download the package for windows, then put the glew.dll in System32 folder. In my pro file, I referenced the .lib files with LIBS += .../path_to_the_libs/glew32.lib and the same for glew32s.lib (not sure what the latter's for). In my QGLWidget subclass, I made sure that glew.h is included before <QGLWidget> and therefore before gl.h and glu.h. In the main() function the first thing I do is call glewInit and call glGetError but my application exits with some weird code, like a very large negative number.
I have a suspicion that there are very may thing I do wrong(I am relatively new to Qt and OpenGL and absolutely new to GLEW), but I also have a suspicion that one of the major errors is that the libs, I suppose, were built with MSVC and therefore cannot be linked against with MinGW... Anyway, can anyone please provide a step-by-step instruction how to install GLEW with Qt and use it? I would much appreciate it. Thank you in advance
Edit:
Guys, maybe I am asking for too much, but I would really really like a step-by-step instruction :)
You're not supposed to call glewInit() before you have your OpenGL context ready. Call it just before your first gl* calls, not at the beginning of main. That should do the trick.
Also, don't use glew32.lib and glew32s.lib simultaneously - the former is to use along with the DLL file and the latter is static (your .exe gets bigger but you don't have to distribute your application with the .dll). Decide and use either.
Qt 4.7 can create any OpenGL Context. Use QGLFormat.setProfile() and QGLFormat.setVersion()
The only disadvantage is that you still do not have OpenGL 3+ bindings.
Step by step solution:
Make new subclass of QGLWindget.
In constructor of new class set up new QGLContext with proper OpenGL numbers.
Call glewInit().
Pass context to constructor QGLWidnet.
If I remember correctly it should do! GLEW dll should be placed in proper system folders, and compiler options attached, but they are the same as for GLEW without QT.