FILE *arg to dll function causes error 1

[outSourced]

I am trying to consolidate some utility functions into a dll for Visual C++. Some of the functions have a FILE pointer argument. Everything compiles ok and I was able to get a small test dll to work. But, when I try to use a function that has one of its arguments a file pointer, I get an access violation error:

"First-chance exception in ludRCard.exe (NTDLL.DLL): 0xC0000005: Access Violation."

I found on the web the following statement for a plug-in example:

"Note that despite accepting a file name it must append its output to the given file. Normally, we would have made printFile accept a file pointer but it seems that Microsoft Windows have problem with file pointers being shared with dynamically linked code"

Is this true? There must be some work around?

Is it only a debugger problem? I have not tried to run outside the debugger.

 

[teriviret]

Don't trust everything you read on the web. It sounds like whoever wrote that didn't really understand the problem, and was just making a stab at it.

If you set up everything just right, there's no reason why a program and a DLL couldn't share file pointers and such. The problem is it is hard to set it up exactly right all the time.

The problem with sharing things like "FILE" objects with DLLs is both your program and the DLL have to "agree" on exactly what implementation of "FILE" they are both using. Since the "FILE" type is defined and functions that manipulate it are implemented in the standard C library, you need to make sure everyone is using the exact same version of this common library.

There are actually at least 4 (probably more) versions of the standard C library in Visual C++. The differences between versions are whether it is built for debugging or not, whether it is built as a statically- or dynamically-linked library, and also what version of Visual C++ it came with.

This makes sharing pointers to these objects dangerous, because sometimes you really can't be sure everyone is going to use the exact same version of the library.

Anyway, you're much better off not sharing things like file pointers between DLLs and programs. A better approach would be to have one module (either the main program or the DLL) handle all the file pointers, and expose an interface (a COM interface, a simple C++ class, even a rudimentary set of plain C functions) that the other module uses to access the file pointers.

This removes the restriction that both modules have to use the same common libraries. If the interfaces between modules don't depend on common libraries, the modules can select different libraries that they only use internally, and don't conflict with each other.