Writing into stream passed to a DLL - c++

I have an issue writing into a stream, passed as a FILE* to a function which is contained in a DLL. Compiler: Visual C++, all versions 2005 to 2015. The precise errors vary; the VS 2015 version is given below. The problem is identical for Win32 and x64 targets.
Trying to boil down the problem, consider this function:
#include <stdio.h>
void TestPrintf(FILE *TestFile)
{
fprintf(TestFile, "Hello World");
}
Now, another function will be calling the above function in the following way:
#include <stdio.h>
void TestPrintf(FILE *TestFile);
void AnyFunction( void )
{
FILE *TestFile;
fopen_s( &TestFile, "PrintTest.txt", "wt");
TestPrintf(TestFile);
}
The first function is part of a DLL. Depending on the settings in
Properties / C/C++ / Code Generation during compilation of both the DLL and the program containing the caller, I get the following error messages:
Caller compiled for Multithread Debug (static):
DLL compiled for either Multithread Debug (static) or Multithread Debug DLL:
Debug assertion failed
File: minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp
Line: 980
Expression: __acrt_first_block == header
DLL compiled for Multithread (static):
Debug assertion failed in the same file as before, but now
Line: 892
Expression: is_block_type_valid(header->block_use)
DLL compiled for Multithread DLL:
Again another variant of the same. Now it is:
Line: 888
Expression: _CrtlsValidHeapPointer(block)
Caller compiled for Multithread Debug DLL:
DLL compiled for either Multithread (static) or Multithread Debug (static):
same messages as above
DLL compiled for Multithread DLL:
Yet another variant of the same. Now it is:
HEAP[FilePrintTest.exe]: Invalid address specified to RtlValidateHeap(
01060000, 0107B7A0 )
DLL compiled for Multithread Debug DLL:
This is error-free.
Caller compiled for Release (either Multithread or Multithread DLL):
all four versions of the DLL go error-free.
The difference between VS versions seems to be that VS 2015 first writes the output as intended and crashes afterwards, whereas VS 2005 crashes already while writing the output.
If the function TestPrintf is not in a DLL, but in a static library, there is no such problem (of course, there will be linker messages about library collisions, but the test program works nonetheless). However, unfortunately, I do need the writing function inside the DLL, and I must be able to call it from anywhere.
All of the above applies also to the case that the caller is in a console programme and the stream is stdout.
So my question is: Is there a stupid mistake on my side? If not, is there a way to work around this problem?
I would be grateful for suggestions!
Martin

Please review the fopen_s syntax. You are passing a FILE * * by using the & in front of the pointer.
Try removing the & symbol:
fopen_s(TestFile, /*...*/);
Your TestFile is already a pointer:
FILE * TestFile;
Your usage doesn't match the syntax presented by cppreference.com

Related

LabVIEW call library node error 1097 for c++ dll

I have a c++ library that I'm calling via the standard call library node in LabVIEW. I'm using 2017 VS to edit the c source files and 2020 32 bit version of LabVIEW. Consequently I've made sure to build new versions of my library in x86. I have not been able to nail down why I keep getting a 1097 error after the node call (I've included pictures of the function prototype that I'm attempting to call in the c header file, the node configuration interface, as well as a picture of the block diagram).
Additionally, LabVIEW reported these errors in the log when I restarted my development system:
DWarn 0x0E697B77: Caught exception in ExtCode call!
DWarn 0x50CBD7C1: Got corruption with error 1097 calling library Multilane_ML4039_Interface.dll function GetEyeDimensions
I've read that with this combination of errors, LabVIEW is catching an exception thrown by the .dll and this will prompt the library node to generator error 1097. This is often because of improperly configured parameters but as far as I can tell, my configuration is ok.
Any help is much appreciated.
Function prototype in .h file
Library configure node in LabVIEW
Block diagram containing library node
Got it resolved. My tired eyes didn't see I had one of my parameters in the prototype entered as a pointer instead of a value. Check those parameters people!

Cygwin 64-bit cannot early-bind to DLL created by MSVC , giving __cxa_atexit error

Here is the C++ program compiled by up-to-date Cygwin64 (gcc/x86_84-pc-cygwin/9.3.0):
extern "C"
__declspec(dllimport) void foo(void);
int main(void)
{
foo();
return 0;
}
with commandline:
g++ -o mre.exe mre.cc /f/temp/simpledll/x64/Debug/simpledll.lib
For SimpleDLL I created a new Windows C++ DLL using VS Community 2019, switched to x64 target, disabled PCH, and added simpledll.cpp:
extern "C" __declspec(dllexport) void foo(void);
void foo(void)
{
MessageBoxA(NULL, "In simpledll foo", "Title", MB_OK);
}
leaving the rest of the DLL boilerplate unchanged.
The compilation in Cygwin64 runs successfully, but then running the executable under the Cygwin shell exits with no output. Running the executable in command prompt (and the cygwin1.dll and simpledll.dll in the same directory as the executable, to eliminate any path errors) produces a message box with the text:
The procedure entry point __cxa_atexit could not be located in the dynamic link library F:\temp\mre.exe
Via a debugger (WinDBG) and ProcMon64 I can see that during startup, simpledll.dll is opened correctly and read; and then this error appears (with a C0000139 error code visible in WinDBG when the __cxa_atexit messagebox appears). This happens even if the main() function never calls the function (e.g. I change it to if (argc > 1) foo(); and provide no commandline arguments).
However the following work correctly, showing the messagebox from foo:
The exact same procedure under a mingw-w64 standalone (either from MSYS2 shell, or command prompt).
The exact same procedure under MSYS2 (x86_64-pc-msys2).
Under Cygwin or MSYS2, loading the same DLL via LoadLibrary and GetProcAddress, instead of linking to the .lib file. That is, late binding works fine whereas early binding crashes.
I've been unable to figure out what is happening differently in the Cygwin targets versus any of the above bullet points. Using -fuse-cxa-atexit makes no difference (I think this is on by default anyway), and strings mre.exe shows __cxa_atexit and __imp___cxa_atexit existing. Furthermore, in the standalone mingw-w64 builds, strings does not find any cxa at all, and yet the code runs correctly.
My question is: what is going wrong and how do I fix it (i.e. how can I call a function in the MSVC-created x64 DLL from a Cygwin64-target build).

Fatal error LNK1168: cannot open filename.mexw64 for writing

I am writing a c++/CUDA code with Visual Studio 2015 to generate a mex file to integrate with MATLAB.
When I run the mex file through the MATLAB console and then try to compile it again on VS I get this error:
LINK : fatal error LNK1168: cannot open filename.mexw64 for writing
Closing the MATLAB and opening the programme again solves the problem.
Does anyone know any solution which not involves closing the MATLAB?
MEX-files are DLLs (on Windows, shared objects on other systems). When first run, MATLAB links to them, but doesn't unlink unless explicitly told to (or quitting MATLAB of course).
Typing
clear mex
in MATLAB will unlink all MEX-files. See the relevant documentation.
But note that your MEX-file can call mxLock, which will cause it to be locked in memory and then it will not be cleared by clear mex. If you use this function in your MEX-file, you need to include a facility to have your MEX-file call mxUnlock. I usually add a syntax such as mymexfile --unlock: the MEX-file checks to see if it is called with one argument, and that argument is a string, and the string matches "--unlock", then it calls mxUnlock.

Loading DLL fails on Windows

As a Xcode developer I have to use my written code on windows, too. I think I have successful master all cross platform issues but now I have a real problem understanding the DLL hell on Windows.
I used my code with Xcode and Gcc (Ubuntu) successful. On Windows I get a error message:
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
I read much about this uses but I have my problems to understand the issue.
Normally on windows I have something like
#define MYLIB_API __declspec(dllimport)
I cannot find this inside the header of the Bass Library (bass.h). There is only one line
#define BASSDEF(f) WINAPI f
Now, I try to dynamic load the DLL functions in my code. You can see the dynamic loading header as link on bottom. To much to copy here. This dynamic loading is working for .dylib and .so libs well, not for .dll
My target is to load the DLL dynamic and not static with an additional lib.
In my code I use the bass.h and the bassdecode.h. In my code I call as sample:
bool returnVar = _BASS_SetConfig(BASS_CONFIG_DEV_DEFAULT,1);
And here I get the calling convention message.
What I have to do in my header file to successful import DLL functions on Windows?
You can download the files at: header files to download
Ok, for all who run into the same problem, the solution is the Answer from Hans Passant. I cannot mark this answer as solution so I want to give him the reputation.
My original typedef of the function:
typedef BOOL (*BASS_SetConfig_Type)(DWORD option, DWORD value);
Was searched in DLL
_BASS_SetConfig = (BASS_SetConfig_Type)DllFindSym(m_hMod, "BASS_SetConfig")
Where DLLFindSym is defined as:
#define DllFindSym(handle,name) (GetProcAddress(handle,name))
Now changed the typedef to
typedef BOOL (__stdcall *BASS_SetConfig_Type)(DWORD option, DWORD value);
Now everything works like a charm in Windows. Many thanks to the quick hint from Hans Passant.

Using a function defined in a DLL from C++ code

I built Qt from source (dlls) and am trying to build an application that uses the Qt dlls. I don't have a lot of experience with C++ so I'm running into what I'm sure is a very basic issue.
My builds are failing on the includes with errors like so:
Fatal error: QNetworkProxy: No such file or directory
Here is the g++ command I am using (I also used -L to add the correct folder to the lib path, but that also didn't work):
g++ -l..\..\wkqt\bin\QtCore4.dll -l..\..\wkqt\bin\QtNetwork4.dll -l..\..\wkqt\bin\QtWebKit4.dll -I..\include -Ishared -Ipdf -Ilib -Iimage -o ..\bin\wkhtmltopdf.exe pdf\*.cc lib\*.cc image\*.cc shared\*.cc
I tried in Visual Studio as well (assuming it wouldn't build, but I wanted to see if I could at least include the Qt dlls from there properly) and I am getting the same errors. Am I doing something wrong with the way I am compiling with g++? If I am linking with the Dlls properly then what is the proper way to use Qt functions from my code?
To clarify, I am not looking for how to properly use Qt. My question is: what is the proper way to use functions defined in any Dll from native C++ code? I apologize if this is a very basic question, but I'm unable to find a clear answer on Google and I don't have any experience with C++ and including third party libraries for use from C++ code.
DLLs can be used by dynamicly loading them and calling their used functions.
to call the exposed functions first define their syntax in the begining
suppose function is syntax is
BOOL MyFunction(int a,char* pszString)
then define syntax
#typedef BOOL (WINAPI *PMYFUNCTION)(int a,char* pszString)
then make object
PMYFUNCTION pfnMyFunction;
and get valid pointer by calling GetProcaddress after loadlibrarycall
HMODULE hlib= Loadlibrary("c:\\Mylib.dll");
if(hlib)
{ pfnMyFunction = (PMYFUNCTION)Getprocaddress(hlib,"MyFunction"); }
Hope this helps...