I am trying to communicate with an oscilloscope over USB with NI-VISA 5.1.1. My 32-bit application is written in the Qt framework using C++ and the MinGW compiler (standard Qt 4.7 SDK).
My application has no problems communicating with the device when I statically link to visa32.lib. My dynamically linked code also runs fine on a Windows 7 64-bit platform, but crashes on two different computers running on Windows XP SP3 (32 bit). I have traced the line of code that causes the crash (it is the first call to viWrite).
The issue seems to be related to setup of global variables in the DLL itself. This might explain why it works in Windows 7 since in that case the 32-bit DLL file is only a stub which calls a 64-bit VISA DLL file.
This is how I dynamically link to the exported functions:
typedef long (*tviRead)(ViSession, ViPBuf, ViUInt32, ViPUInt32);
typedef long (*tviWrite)(ViSession, ViBuf, ViUInt32, ViPUInt32);
QLibrary visa32("visa32"); // Qt wrapper for LoadLibrary
if (!visa32.load()) throw "Unable to load visa32.dll";
pviWrite = (tviWrite) visa32.resolve("viWrite");
pviRead = (tviRead) visa32.resolve("viRead");
If I call the following (where the vi prefixed function are statically linked and pvi ones are runtime linked),
status = viOpenDefaultRM(&rm);
status = viFindRsrc(rm, query, &list, &itemCnt, desc);
status = viOpen(rm, desc, VI_NULL, VI_NULL, &vi);
status = pviWrite(vi, (ViByte*) idn, 5, &retCnt); // Crash right here
status = pviRead(vi, (ViByte*) id, sizeof(id), &retCnt);
everything works perfectly. However changing any of the three setup function to runtime linked causes a segmentation fault when calling pviWrite. There aren't AFAIK any other functions exported by the DLL to "setup global variables", in fact I can't see DllMain exported using the Dependency Walker tool. Has anyone ever runtime linked to visa32.dll successfully? I can't find any examples on the Internet.
I suspect you have the following problem:
http://msdn.microsoft.com/en-us/library/ms684179(v=vs.85).aspx
Scroll down to the remarks section, and look for "Visual C++": if the DLL contains _declspec-style thread local storage you can only load it dynamically in Vista or later.
I'm trying to achieve the same thing but apparently, for XP, we are simply out of luck...
Related
This code will run on your machine, but not on mine:
#include <iostream>
#include <vector>
using namespace std;
int main(){
vector<int> vv;
vv.push_back(1); //<--- without this, everything works
cout << "X\n";
return 0;
}
The reason, is that it appears my windows machine is missing a (or has a conflicting) specific DLL related to Vectors which is causing my other projects to crash without a report if I use vectors.
However, what's even more entertaining is:
If I comment the push back line, it executes normally without a crash.
Other programs work completely fine as long as they avoid vector, as in using list or an array.
GDB Reports "During startup program exited with code 0xc0000139." Which means it couldn't find the dll it wants. Looking through the dependencies of my executable with Dependency Walker is rather inconclusive, I can't tell what is wrongly missing and what is normally missing among the dlls.
It could also be that there is a second dll that is conflicting with it (like I downloaded two different compilers). Investigating with Process Monitor informs me that instead of using the MinGw64 files located in the MSYS2 folder, the process uses the dlls inside of my ProgramFiles/Git/mingw64/bin location.
So it could be an issue? But Process Monitor doesn't tell me why or what is causing the process to exit unsuccessfully...
How would I get Windows to use the dlls in MSYS2 instead of the Git location? The solution that the post I linked above says is to remove the "erroneous dlls." But I can't just remove dlls that git uses?
Also, how am I guaranteed that switching to the dlls within MSYS2 is going to fix my problem? I just want to use vectors lol, how hard does this have to be?
Other solutions include leaving this spyware infested OS and enter the world of Linux, but that's a huge change.
i have a program that loads dlls, all dlls have only one simple c function "run". one dll contains call to CreateProcessAsUserW and when i try to load it, LoadLibrary reports error 127 "ERROR_PROC_NOT_FOUND". when i comment it out, dll loads normally and is callable. i was running dependency walker on this dll and CreateProcessAsUserW is marked red with error:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
this problem does not occur when using CreateProcessAsUserA, only when using CreateProcessAsUserW.
my setup:
xp sp3 updated to max
mingw64, gcc 4.9.1
i also have static libs and static runtime turned off
whats the source of my problem? how can i fix this so CreateProcessAsUserW will work?
How can I debug Lua 5.2.2 code that is embedded inside of my C++ application?
I have already taken a look at this question and all the IDEs provided in it deal with 5.1 and lower and when I try to use them with 5.2.2 they crash.
You should be able to debug your application using ZeroBrane Studio by following instructions for Lua 5.2 debugging. Note that you'll need to have luasocket compiled against Lua5.2. (The crash you see is likely because your application loads luasocket that is compiled against Lua5.1, which in turn loads Lua5.1 DLL or fails to find required symbols.)
If you don't want to compile luasocket, you can get binaries for Windows/OSX/Linux from this folder and its subfolders; just make sure that these libraries are in LUA_CPATH before any folders that may have luasocket compiled against Lua5.1.
[Updated based on chat discussion] The reason you may be getting multiple VM issue is that your app is probably statically compiles Lua interpreter. You then load luasocket (directly or through mobdebug), which is compiled against lua52.dll, which loads another copy of the interpreter. To avoid this you have two choices: (1) compile luasocket into your app the same way you include lua interpreter itself; you won't need anything else except one mobdebug.lua file to debug your app, or (2) use proxy dll; it will look like lua52.dll, but will actually proxy your calls to your statically compiled lua library, avoiding problems with multiple VMs. The proxy dll is for Lua 5.1, but you can tweak the script to make it work for Lua 5.2.
(If your interpreter is not statically compiled, you may still get two interpreters if the Lua DLL you load is named differently from lua52.dll.)
In response to OP's commented request, here's how you should open the lua standard library "base" from C++:
#include "lua.hpp"
//...
int main ()
{
lua_State* L = luaL_newstate();
luaL_requiref(L, "base", luaopen_base, 0);
// ...
int error = luaL_loadfile(L, mainLua);
lua_call(L, 0, 0);
lua_close(L);
}
Note that you can open all the standard libraries at once by replacing:
luaL_requiref(L, "base", luaopen_base, 0);
with
luaL_openlibs(L);
The Lua 5.2 reference manual Section 6 has more info about this.
UPDATED: Added what RoInitialize looks like in roapi.h
I am in the process of writing a pure C++11 WinRT library. I do not use WRL or C++/CX (Obviously if I want pure C++11).
I got my code to compile and run on MSVC, but I want to see if I can get the code to compile and run on Mingw Gcc. Specifically, I am using GCC 4.7.2 obtained from nuwen.net.
What I need at this point is a way to call the Windows API Functions RoInitialize, RoUnitialize, RoGetActivationFactory and the HSTRING Functions WindowsCreateString, WindowsDuplicateString, WindowsDeleteString.
I tried compiling this program in G++ but got the error
extern "C"{
__declspec(dllimport)int __stdcall RoInitialize(int);
}
int main(){
RoInitialize(1);
}
I tried to compile but got:
c:\Users\jrb\Desktop>g++ gccwinrt.cpp
C:\Users\jrb\AppData\Local\Temp\ccy7y1V9.o:gccwinrt.cpp:(.text+0x1e): undefined
reference to `_imp__RoInitialize#4'
collect2.exe: error: ld returned 1 exit status
If anybody can point me in the right direction on how to declare these functions and what libraries I need to link to, I would appreciate it. Even if it requires LoadLibrary/GetProcAddress I would still be ok with that
Update: Here is what RoInitialize looks like in the header roapi.h
ROAPI
_Check_return_
HRESULT
WINAPI
RoInitialize(
_In_ RO_INIT_TYPE initType
);
ROAPI is just a define for __declspec(dllimport)
_Check_return_ is part of SAL (Secure Annotations Language?)
HRESULT maps to int32
WINAPI is a define for __stdcall
RO_INIT_TYPE is an enumeration so int should cover it
The import library for these functions is runtimeobject.lib (which the MSDN documentation fails to mention). It can be found in the Windows SDK for Windows 8.
The library you need to link against is windowsapp.lib (and only this lib, remove all others).
This topic lists the Win32 APIs that are part of the Universal Windows Platform (UWP) and that are implemented by all Windows 10 devices. For convenience, an umbrella library named WindowsApp.lib is provided in the Microsoft Windows Software Development Kit (SDK), which provides the exports for this set of Win32 APIs. Link your app with WindowsApp.lib (and no other libraries) to access these APIs.
APIs present on all Windows 10 devices - Microsoft Docs
See that page for a complete list of functions that implements; it includes RoInitialize, RoUnitialize, RoGetActivationFactory and WindowsCreateString, WindowsDuplicateString, & WindowsDeleteString (among many, many others). If you need other functions, you may need to link extension APIs also.
Similar guidance was originally on
https://msdn.microsoft.com/en-gb/windows/uwp/get-started/universal-application-platform-guide#writing-code but is no longer present:
Windowsapp.lib is an "umbrella" lib that provides the exports for the UWP APIs. Linking to Windowsapp.lib will add to your app dependencies on dlls that are present on all Windows 10 device families.
For delay loading, you will need to load api-ms-win-core-winrt-l1-1-0.dll, which is an API set, a collection of APIs that Windows can load regardless of where the actual DLLs are. This specific set is listed as a Windows 8.1 API set, however if you check the documentation for RoInitialize it says the minimum supported client is Windows 8. Assuming you use LoadLibrary and GetProcAddress, it shouldn't matter.
The actual DLL that the method is implemented in is combase.dll, but they use these API set DLLs as a level of indirection so that they are free to change or update that original DLL in the future.
For future reference, the API sets for Windows 10 (UWP) are listed on a separate page to the API sets for Windows 8 (and 8.1). The stub DLL (for delay loading) is the same. https://msdn.microsoft.com/library/windows/desktop/mt186421
Many other APIs also list their corresponding API set in their own documentation. For example, MSDN gives AllowSetForeground as an example.
If you don't have the import lib that contains RoInitialize, you'll need to use LoadLibrary/GetProcAddress to resolve the types.
Run-time link it like this:
#include <roapi.h>
namespace
{
FARPROC LoadComBaseFunction(const char* function_name)
{
static HMODULE const handle = ::LoadLibraryA("combase.dll");
return handle ? ::GetProcAddress(handle, function_name) : nullptr;
}
decltype(&::RoInitialize) GetRoInitializeFunction()
{
static decltype(&::RoInitialize) const function = reinterpret_cast<decltype(&::RoInitialize)>(LoadComBaseFunction("RoInitialize"));
return function;
}
}
HRESULT RoInitialize(RO_INIT_TYPE init_type)
{
auto ro_initialize_func = GetRoInitializeFunction();
if (!ro_initialize_func)
return E_FAIL;
return ro_initialize_func(init_type);
}
Source
I am converting my project to use DLLs and am trying to break apart my Singleton class to avoid using templates.
My class, LudoMemory, originally inherited from Singleton. I am trying to give it the functions to destroy and create itself now and have my main engine not rely on the Singleton.
I have written a simple destroy method like such:
LudoMemory *memory_Singleton = NULL;
void LudoMemory::Destroy()
{
LUDO_SAFE_DELETE(m_Singleton)
}
and upon running the program (no compiler errors) I recieve this error:
The procedure entry point
?Destroy#LudoMemory##SAXXZ could not
be located in the dynamic link library
LudoCore.dll
LudoCore is the project that LudoMemory belongs to. Why is this happening? How can I solve it?
you don't have multiple versions of ludocore.dll on your system, do you?
Procedure entry points errors usually mean: you compiled your project against ludocore.lib version x, and when running the program, it uses ludocore.dll version y, and version y does not define LudoMemory::Destroy().
Jacob's answer about multiple DLL versions seems likely.
Also, with some build systems, you must explicitly list which functions will be exported in a DLL.
Research your build environment, and see if you must provide a list of methods to be exported as an entry-point.
In Visual Studio build environment, also you could try by disabling the References in Linker Optimization Settings [ No(/OPT:NOREF)]