freopen() in a DLL
Dan Jeffrey
I have a DLL that is loaded by an EXE that is using a re-directed stout and
stderr. When the DLL starts, it redirects stdout yet again. When the DLL
function returns the DLL is unloaded. Then the EXE reports an invalid
handle.
For the sake of discussion, assume I cannot live without the redirection in
the DLL. I am trying to encapsulate some existing code into a DLL without
reverse engineering the entire thing.
So, my question is:
Does freopen() behave like a stack?
I mean, what happens when you call fclose() -- does the previous handle "pop
up" to take the place of the closed file or is this the cause of my problem
above?
Important note: On NT there is no side effect! On Windows 95, the
application hangs. On both, the redirection fails to work anyway.
Jim Marshall
When you call Close the stream is closed, you can't use it anymore.
Additionally you've got a complication added by the DLL. You freopen will
only (really) work if both the exe and the dll are using the DLL version of
the RunTime library (by default VC++ statically links dlls to the CRT, so
you need to change this). This is because the FILE* is relative to the CRT
being used (I'm intentionally being vague here, sorry), hence it is specific
to each copy of the Runtime. If the DLL statically links to the runtime
then it is using a different copy of the runtime then the EXE and it really
can't use the FILE* passed from teh EXE (probably the cause of your crash)
--
Diplomacy is saying 'nice doggy' until you find a rock
------------------------------------------------------------
| Author for Pinnacle Publishing "Visual C++ Developer" |
| http://www.pinpub.com/ |
| http://lucifer.lotus.com/jim/main.htm |
------------------------------------------------------------
Bernd Luevelsmeyer
This is more a matter of C than of NT.
freopen() closes the old handle, then opens a new one. You can't get the
old handle back.
Not knowing what you want to achieve, I can't suggest an alternative to
freopen().
John A. Grant
Dan Jeffrey wrote in message <35886...@news.sac.bfp.net>...
>I have a DLL that is loaded by an EXE that is using a re-directed stout and
>stderr. When the DLL starts, it redirects stdout yet again. When the DLL
>function returns the DLL is unloaded. Then the EXE reports an invalid
>handle.
>
>For the sake of discussion, assume I cannot live without the redirection in
>the DLL. I am trying to encapsulate some existing code into a DLL without
>reverse engineering the entire thing.
>
>So, my question is:
> Does freopen() behave like a stack?
>I mean, what happens when you call fclose() -- does the previous handle
"pop
>up" to take the place of the closed file or is this the cause of my problem
>above?
>
>Important note: On NT there is no side effect! On Windows 95, the
>application hangs. On both, the redirection fails to work anyway.
Since fopen() returns a FILE *, I assume it does a malloc()
somewhere in there. It is reasonable to assume that fclose()
then does free() on the FILE *. freopen() does an fclose(),
followed by a fopen(), so there's a free(), followed by a
new malloc(). Well, something like that anyway.
The .exe and .dll use separate heaps and that includes
the FILE * pointers. Therefore you can't malloc() or fopen()
in the .exe and then free() or fclose() those pointers
in the DLL.
If the DLL does freopen(), on a FILE * created in the .exe,
it will cause 2 problems:
(a) it will abort while attempting to fclose (free)
the FILE * that was created on the .exe heap
(b) it will try to do another fopen (malloc), returning
a new FILE * that is only valid in the DLL, and not
the .EXE
You need to structure your program so that these things
are created/used/destroyed/accessed only in the DLL
or in the .EXE.
--
John A. Grant * I speak only for myself * (remove 'z' to reply)
Airborne Geophysics, Geological Survey of Canada, Ottawa
If you followup, please do NOT e-mail me a copy: I will read it here