Re: EuFLW 3.3 Released!
- Posted by Icy_Viking May 08, 2019
- 3834 views
The problem, as is often the case, starts with the dll. As far as I can ascertain the version of glfw3.dll in your distro was created for Visual C++. I, and I guess many others, tend to use dlls created for MinGW. So, for me, the distro doesn't work for any version of Euphoria!
Unfortunately, there seems to be a problem with the labelling of the various dll versions in the GLFW "Download" zip! If you try that in the lib-mingw folder open_dll returns 0, but if you try the one in the lib-mingw-w64 folder then open_dll returns a suitable value! (For the record, the version of glfw3.dll in the "64-bit" folder is actually 32-bit.) As added "proof" of its 32-bit character, Euphoria 3.1.1 can open the dll equally well.
So, problem addressed, but sadly not solved! The EuFLW examples work using v4.0.5, but they both fail when I use the 32-bit version of v4.1.0.
I have designed a step-by-step diagnosis program, which simply simulates the examples, and have moved some "pausing" code a line at a time to test all current values. This program runs, with all pauses "off" in the v4.0.5 interpreter (and also in the 3.1.1 interpreter, for that matter!) When tested using the v4.1.0 interpreter, however, although open_dll, define_c_func and define_c_proc all deliver as expected, as soon as the program calls c_proc or c_func it fails without error, but with the "flash" of a window!
Do others have this same problem with other examples of dlls?
I was having problems using Eu 4.1.0 to create wrappers, so I have stuck with 4.0.5 for the time being. For most DLLs, I use the one built with visual studio. If the library I am wrapping is cross-platform, I will add code so that it can load .so (DLLs for Linux/GNU systems). Usually this just consist of a platform check and then adding in the .so file extension when reading/opening the DLL to read the functions from.
